Path: ...!3.eu.feeder.erje.net!feeder.erje.net!ecngs!feeder2.ecngs.de!168.119.53.7.MISMATCH!weretis.net!feeder8.news.weretis.net!pasdenom.info!.POSTED.2a01:e0a:472:70f0:4c9f:ce5c:a712:e3f!not-for-mail
From: DrPi <314@drpi.fr>
Newsgroups: fr.comp.lang.ada
Subject: =?UTF-8?Q?Re=3A_Question_structure_de_donn=C3=A9es?=
Date: Sun, 8 Oct 2023 21:57:04 +0200
Organization: <https://pasdenom.info/news.html>
Message-ID: <ufv1ig$8dp$1@rasp.pasdenom.info>
References: <ufcalc$i3v$1@rasp.pasdenom.info> <ufr2f8$28d89$1@dont-email.me>
 <ufshr8$p80$1@rasp.pasdenom.info> <uftt3o$30nq2$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 8 Oct 2023 19:57:04 -0000 (UTC)
Injection-Info: rasp.pasdenom.info; posting-account="314@usenet"; posting-host="2a01:e0a:472:70f0:4c9f:ce5c:a712:e3f";
	logging-data="8633"; mail-complaints-to="abuse@pasdenom.info"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha256:HtqjdoXibRwN+htgG7PPFLJnYwNBXiL4bfonAz3eJog=
Content-Language: fr
In-Reply-To: <uftt3o$30nq2$1@dont-email.me>
Bytes: 11645
Lines: 189

Le 08/10/2023 à 11:34, Stéphane Rivière a écrit :
> Une classe pour l'ensemble pourquoi pas (quoique un paquetage standard
> me semblerait suffisant, à moins que tu souhaites manipuler plusieurs
> ensembles à la fois) mais pourquoi plusieurs classes pour chaque niveau
> de conteneur ?
> 
Je vais y réfléchir. Je suis comme une machine à vapeur. Le temps de 
chauffe est long ;)

> 
> PS
> 
> J'ai été voir ton site, 1) j'aime bien la résistance en 'macramé' (une 
> 22 ohms 5% a priori :) 
C'est bien ça :)
C'est ma femme  qui l'a crochetée à ma demande.

2) et la réflexion de... "mais y'a pas mieux que
> le C dans ma vie de dev ?
> 
Ah oui, ça c'est un peu comme un rêve. Au boulot, j'utilise QNX comme 
OS. C'est génial. Les drivers sont des applications comme les autres 
avec "juste" le droit d'accéder au matériel en plus. Du coup le système 
est hyper stable. Sauf que les applications sont écrites en C. Un jour 
j'ai pris conscience du coté aberrant de la chose et c'est à partir de 
là que j'ai commencé à apprendre Ada.
En fait, alors que je faisais fausse route avec Rust, j'ai vu une pub 
pour GNAT Pro pour QNX sur le WEB. J'ai contacté Adacore, bien discuté, 
et je me suis dit que je devais essayer Ada avant de tenter la demande 
d'achat de GNAT Pro à ma hiérarchie. C'est comme ça que j'ai commencé à 
apprendre Ada à la maison.
Je me suis dit que je pourrais aussi utiliser Ada sur micro-contrôlleur 
mais là, je suis resté sur ma faim. Pour moi, les runtime existantes, en 
tout cas celles que je connais, ne sont adaptées à l'usage que 
j'aimerais en faire.

> Une remarque très juste : "La courbe d'apprentissage est vraiment
> raide. Le langage est vraiment complet. Du coup, ça rend son
> apprentissage plus long. Et chaque version d'Ada en rajoute une couche.
> Mais plus j'avance dans mon apprentissage, plus je trouve le langage
> intéressant."
Tout à fait.

> J'ai appris Ada ainsi : d'abord comme une sorte de 'Super Pascal', puis 
> ensuite, j'ai lu le RM (super lecture, la mère de toutes les lectures, 
> on y découvre des perles) et aussi tout ce qu'à produit Jean-Pierre 
> (beaucoup de communications) et l'autre mère de toutes les lectures :
> 
> https://fr.wikibooks.org/wiki/M%C3%A9thodes_de_g%C3%A9nie_logiciel_avec_Ada
Je l'ai lu aussi. Très instructif. Merci Jean-Pierre ;)
> 
> J'ai eu la chance de trouver une version papier, d'occasion, en très bon
> état, planquée tout en haut d'une étagère, à peine visible (mais je
> connaissais la couverture) dans un coin poussiéreux de l'ancien Gibert
> Jeunes. Celle-là, elle m'attendait !
> 
> J'ai appris "bout par bout", sans me soucier de tout comprendre
> d'un coup, en fonction de mes besoins (et je n'ai toujours pas tout 
> compris, loin de là).
> 
> Et puis la communauté Ada est extrêmement bienveillante. Ça aide pour
> progresser.
Oui, il y a des personnes très compétentes sur les newsgroups.
Je suis également abonné à des rooms Matrix mais la qualité des échanges 
n'est pas du tout la même.

> Enfin, la productivité de Ada est simplement phénoménale. Et le nombre
> de lignes actives pour un problème donné étonnamment faible. Ada est,
> sur la totalité d'une application) beaucoup moins verbeux que le C ou le
> C++ :)
Pas pour moi. Du moins, pas encore. J'ai trop de lacunes, principalement 
à cause de ma mauvaise mémoire. Il y a tellement de choses à retenir... 
que je lis... et oublie...
Mais à force d'y revenir, ça finit par rentrer dans ma tête :)

Genre, récemment, j'ai voulu utiliser un "private package". Je le code, 
je fais le "with" qui va bien et le compilo m'envoie paître. Je 
comprends que je n'ai pas le droit de faire un "with" dans la partie 
publique de la spécification du package qui l'utilise. Mais je veux m'en 
servir dans la partie privée uniquement. Normal, il est privé. Et je ne 
peux pas mettre le "with" dans la partie privée de la spécification 
alors je me dis m... je ne peux m'en servir que dans le "package body". 
Et ce n'est pas ce que je veux. Alors je défais tout et je refais 
autrement en me disant que tant pis. Mais je me dis aussi que cette 
limitation est bizarre. Ca n'est pas dans l'esprit du langage. Alors je 
me mets à chercher et je finis par trouver le précieux "private with" 
(pas facile à trouver). Et je recode tout comme je le voulais en me 
maudissant parce que je me suis souvenu que je l'avais déjà lu quelque 
part...

> Rust, j'ai regardé la syntaxe, regardé à nouveau, puis j'ai... euh... 
> écarquillé les yeux façon hiboux (chercher rust ugly syntax, y'a du lourd)
Je suis d'accord. C'est abominable.

> Tu peux pratiquer Ada également sur AVR¹ ou STM32, ainsi que plein
> d'autres microcontrôleurs... Une soluce ici avec gnatstudio et le 
> débuggueur intégré fonctionnel (dev sur uP sans debugger, je sais pas 
> faire).
Sur micro-contrôlleur, à part en baremetal, c'est pas vraiment 
utilisable pour ce que j'aimerais en faire.
Il y a longtemps que je ne fais plus de baremetal sur µP. J'utilise 
toujours tout un tas de tâches pour bien séparer la gestion des divers 
éléments logiciels/matériels. Une des grosses limitations des runtimes 
sur µP, c'est l'impossibilité d'utiliser un timeout dans une tâche. Et 
ça c'est rédhibitoire. Quand le hardware ne répond pas, il faut le 
gérer. Certes, il y a moyen de contourner le problème à peu près 
correctement mais cela complexifie beaucoup le programme. Et ça reste de 
l'à peu près. Le modèle de "tasking" de Ada est vraiment intéressant. Si 
je change de langage, c'est pour me simplifier la vie, pas pour la 
complexifier.

> Étant électronicien à la base (numérique, radio, microcontrôleurs), au
> niveau FPGA/VHDL (que je connais pas), j'aimerai bien savoir sur quelle
> base (raisonnablement économique) je pourrais me fonder pour m'initier
> (en VHDL impérativement, pas du chinois, préférablement de l'européen
> mais je sais que je rêve, avec un environnement de préférence libre et,
> à défaut, sans procédure de licence de dingue. Et sous Linux pour
> "simplifier" le choix :)
J'adore les FPGAs ! :)
Vu que l'on est hors sujet, je vais essayer d'être bref.

Des puces FPGA européennes, y a pas. Il y a essentiellement de 
l'américain et du chinois. Pour les puces américaines, il y a AMD 
(anciennement Xilinx) et Intel (anciennement Altera). Intel va 
externaliser sa branche FPGA vers une nouvelle société dont on ne sait 
encore rien.

je n'ai encore jamais fait d'open source avec les FPGA. Je suis le sujet 
d'un peu loin, mes connaissances sont donc réduites/pas à jour sur le sujet.
Pour la chaîne de développement open source, malheureusement, c'est le 
verilog qui est omniprésent. Verilog, c'est l'équivalent du C en 
FPGA/Asic (VHDL est l'équivalent de Ada). Mais tu dois déjà savoir ça.
Donc, hors verilog, point de salut. Il y a des moulinettes pour 
transposer du VHDL en verilog. Mais c'est loin d'être parfait. D'autant 
plus que VHDL est un langage complexe et les dernières normes (VHDL-2008 
et VHDL-2019) ne sont pas ou peu supportées. Ca s'améliore doucement.
Coté, simulateur, il y a GHDL (écrit en Ada) et nvc. A priori, nvc a un 
support de VHDL plus complet que GHDL. Par contre, GHDL est aussi 
utilisé pour faire de la synthèse (en transposant en verilog ?), une des 
étapes pour implémenter le code dans la puce.
Coté outil de synthèse et placement/routage, il y a yosys (verilog).
Yosys supporte certaines puces ICE40 de Lattice Semiconductor et 
quelques puces Xilinx. A savoir que le support des puces est fait 
entièrement à partir de reverse engineering. C'est un processus très 
long, ce qui explique pourquoi il y a peu de puces supportées. Sans 
parler des problèmes de légalité du procédé.
Plus d'infos sur le site de Yosys.
Renesas (japon) a une gamme de petits FPGA intéressants qui utilise 
nativement une chaîne de développement open source (Yosys ?). Je leur ai 
demandé, il y a 2 ou 3 ans, si le VHDL est supporté. Réponse : Ca va 
venir. Apparemment, les puces se font désirer.

Hors open source, les principaux fabricants de FPGA fournissent une 
chaîne de développement complète gratuite pour certains de leurs 
composants. Je n'utilise pas les FPGA de Intel, donc je ne peux rien 
dire. Chez Lattice, il me semble que les outils sont entièrement 
gratuits, quelque soit le composant utilisé. A vérifier, je n'ai pas une 
grande expérience avec cette marque (mais les composants sont très 
intéressants). Pour AMD, l'outil (Vivado en version WEBPACK) est gratuit 
pour certains composants choisis par le fabricant. Pour les autres 
composants, il faut l'outil payant (plusieurs milliers d'euros). Vivado 
existe en version Linux. Chez les autres fabricants, je ne sais pas. 
Windows est toujours supporté. Linux ? Mach OS, jamais.

De mon point de vue, pour débuter, commence avec les outils du fabricant.
Aujourd'hui, plein de fabricants de cartes vendent des cartes avec un 
FPGA, comme ils vendent des cartes avec un µP. Choisis un carte avec un 
FPGA simple et fais toi la main dessus. Ensuite, passe en open source. 
Le sujet est complexe. On ne maîtrise pas le développement d'un code 
FPGA aussi simplement qu'un code de programmation classique. Autant ne 
pas ajouter de difficultés au départ.

> L'idée serait de pouvoir me composer un FPGA avec un bloc
> "microprocesseur" compatible avec un compilo Ada et du hardware rapide
> (décodeur I/Q, PLL et autre blocs fonctionnels ou coder ne suffit plus).
> 
Là, tu as 2 voies possibles.
- Le FPGA simple dans lequel tu vas instancier un coeur micro-contrôleur 
========== REMAINDER OF ARTICLE TRUNCATED ==========