Deutsch English Français Italiano |
<ufv1ig$8dp$1@rasp.pasdenom.info> View for Bookmarking (what is this?) Look up another Usenet article |
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 ==========