Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Affichage des résultats 1 à 13 sur 13

Discussion: Choix d'architectures

  1. #1
    Yop les gens qui parlent la même langue mais pas le même langage (Celui qui a la ref lis de bonnes BD ^^).
    D'abord merci pour l'accès au Graal du forum !
    Comme écrit dans ma lettre de motiv' pour poster ici (), j'ai 2o ooo questions mais je sais pas trop comment organiser tout ça ... Halp.

    Allé, comme j'ai lu que certains ici font du design de CPU/SoC/µC, je regroupe les questions à ce sujet, en mode copier-coller des forêts
    1. pour ma moto et l'astronomie, j'ai besoin de systèmes peu gourmands en énergie, sur quelle(s) plateforme(s) partir ? Arduinos trop light en RAM (cause libs non optimisées), Raspis trop gourmands/lourds (pas besoin de tout un OS).
    2. ce qui m'entraîne sur : c'est rentable et/ou utile de partir sur une solution à base de FPGA ? Quels sont les avantages/inconvénients ?
    3. j'ai récup une poignée d'Intel 8080 (1979) et autres chips sortis du futur chez mon revendeur local d'électronique, je peux en faire quoi, enfin surtout comment ?! Bon ok y'a les datasheets, mais le 8080 c'est un dico ...

    Dans le même esprit "architectures" mais moins technique :
    4. dans le dossier CPC-HW "les PC de l'espace" (sur-kiffé d'ailleurs), paraît qu'il y a un SPARC EU, le LEON. Pourquoi c'est pas forké/démocratisé pour les manants/utilisé comme base pour quelque chose de plus public (aux sens institutionnel et particulier), histoire de ne pas dépendre des US (Intel/AMD) ou de l'UK (ARM) ? (PS: DTC Spectre et Meltdown).
    5. sinon on se forme comment quand on veut aller plus loin que "click-click, hoplà ça marche" ? Je parle surtout de l'embarqué/micro-controlleurs. J'ai lu "Code" de Petzold, ça m'a bien plu

    Merci pour vos retours, j'espère que ce n'est pas trop indigeste !
    PS: n'hésitez pas à me faire éditer ou scinder ce post en plusieurs si vous pensez que ce serait plus lisible

  2. #2
    Question énergie, je peux répondre : le plus simple si t'as besoin de peu de conso et simple à programmer, ça reste un Raspberry Pi, c'est accessible, pas cher et y a une communauté pour les soucis. Un Zero, ça consomme très peu.

    Pour les Leon, et plus généralement les architectures "alternatives" on a quand même le souci de la compatibilité (tout récompiler, c'est un souci) et le Leon, c'est pas très performant.

  3. #3
    Tiens, salut ô rédac-chef ! ^^

    En fait, même un Raspi Zero consomme vraiment trop, et n'est pas adapté pour plusieurs raisons, c'est pour ça que j'ai fait mes premiers tests sur Arduino Uno, mais que je cherche autre chose (d'où les pistes FPGA ou 8080, mais territoires inconnus pour moi) !
    Le système doit tenir au moins un mois sur une batterie, ne pas reposer sur une carte SD (plutôt une EEPROM), être assez proche d'un RTOS et être le plus "fail-safe" possible.
    J'utilise des modules GPS et GSM (tous deux mis en repos tant qu'un accéléromètre ne capte rien, "mode garage"). Et ces deux modules fonctionnent en Serial, or le raspi si je n'm'abuse ne propose pas plusieurs ports Serial en Hard, et en Soft c'est bancal (d'où le pré-requis "RTOS").
    S'il faut je peux donner plus de détails, mais en gros c'est pour une moto enduro que j'utilise seul, donc ça doit me servir à la fois de balise de détresse (quand je me suis vraiment bourré) et d'anti-vol pistable.
    Et accessoirement me donner ma vitesse instantanée, j'ai pas de tachymètre ...

    Pour le LEON, c'est une archi SPARC, encore utilisée de nos jours et pas sur des petits systèmes ! Et finalement, la recompilation c'est une fois par plateforme, non ? Par exemple Debian est "go" sur SPARC.
    Et 1.5Ghz quad core c'est pas aussi bien que certaines puces ARM de téléphones ? Quant à la gestion de l'énergie, elle doit être encore plus peaufinée non ?
    Bon d'accord, j'oublie le segment du milieu, nos PC ...
    En fait derrière ma question, y'avait aussi cette remarque : le programme Apollo a plus ou moins propulsé l'informatique moderne (US), et pas mal de technos sont "parties" dans les entreprises high-tech.
    Et en Europe, on développe un CPU mais on le cantonne à l'ES(p)A(ce) (j'ai tenté un jeu de mots, enfin de lettres ...) !

    Je crois que j'aurais dû scinder les sujets ^^

  4. #4
    ESP32. Et si c'est pas suffisant, une batterie de scooter sur un rasp0 fera le job.

    Pourquoi on utilise plus les autres archi ? Parce qu'elles font pas le taff.
    Pourquoi on les utilise dans l'espace, les missiles etc ? Parce que c'est pas le même taff.

    Aujourd'hui, t'as le choix entre ARM pensé pour l'économie d'énergie le plus souvent d'où des difficultés pour monter en perfo (des difficultés, pas des impossibilités), x86 (cas inverse) et les autres, inadaptés dans la plupart des cas et si t'étais dans l'un des cas où ils sont adaptés, tu les connaitrais probablement déjà en détail.
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  5. #5
    Le nombre de coeurs et la fréquence, c'est très variable.

    Que ce soit en SPARC, en ARM ou en x86, on a pleins de trucs en quad/1,5 GHz avec de (grosses) différences de performances.

    Et même si l'OS est compilable sur SPARC, c'est pas nécessairement le cas des logiciels, et généralement, on perd les optimisations. Le fait qu'on puisse mettre Debian dessus rend pas le truc viable pour un usage large (et je parle même pas du grand public). Y a d'autres architectures plus intéressantes (genre RISC V).

    Sinon, pour le début, le FPGA, faut être vraiment calé, et de toute façon, c'est pas nécessairement intéressant d'un point de vue consommation.

  6. #6
    Merci pour ces réponses, qui, désolé, vont appeler encore plus de questions (je suis le type relou de la pub "cé koi cette bouteille de lé". Pourquoi ? Ah, mais pourquoi ?) !

    ESP32 m'a l'air intéressant, mais damned y'a pléthore de modèles, et c'est une archi qui m'est inconnue, c'est facile de s'y mettre ? T'as des recommandations pour se renseigner/apprendre là-dessus ?
    Et "3615 mavie", la batterie de ma moto (KTM 450 EXC 2oo6 si y'a des motards) est à plat depuis des années faute d'entretien, vive le kick. En plus pas envie de mélanger les circuits ! Je veux utiliser une batterie autonome/indépendante tant que je noobise.

    si t'étais dans l'un des cas où ils sont adaptés, tu les connaitrais probablement déjà en détail
    Ben non, c'est tout l'intérêt de la question ! Je suis sysadmin/chef de projet IT de formation donc l'électronique, l'embarqué et tout ça, c'est l'inconnu. J'ai découvert ce monde grâce aux Raspi, Arduinos, adafruit, Demerliac et consorts.
    Pareil, preneur de toute information me permettant d'évoluer dans ce domaine (livres ou numérique).

    Sinon, compris pour les différences d'archis, même si l'histoire a montré que ce ne sont pas forcément les caractéristiques techniques qui ont sabordé les archis prometteuses. "Le mainstream m'a tuer".
    D'ailleurs, c'est une légende que des CPU Motorola étaient dans des Macs ET dans des missiles ? Si je dis pas d'la merde, au temps des interdictions d'import/export dans certains pays de Macs (G4 ?).

    Et même si l'OS est compilable sur SPARC, c'est pas nécessairement le cas des logiciels, et généralement, on perd les optimisations. Le fait qu'on puisse mettre Debian dessus rend pas le truc viable pour un usage large (et je parle même pas du grand public). Y a d'autres architectures plus intéressantes (genre RISC V)
    J'essayais de titiller ton appétance, car dans l'édito du numéro sur les PCs de l'espace, tu étais présenté comme "le type qui essaie d'installer ie4 sur Solaris" J'ai d'ailleurs maintes fois fail à compiler des outils GNU ou Linux sur Solaris 11 (bon ok, x86-64) ...
    Les procs SPARC sont d'ailleurs pas mieux étudiés pour la virtualisation par exemple (mon dada actuel), avec un compartimentage "à l'intérieur" du CPU ?
    RISC V je viens de découvrir, merci. On arrive enfin aux archis ouvertes sur un format plus gros qu'une carte de crédit. D'après ce que j'ai lu, c'est pour l'indépendance EU, mais ce sera pas pour le grand public (supercalculateurs).
    D'ailleurs un dossier récapitulatif CPC-HW sur les archis alternatives (mortes ou actuelles) serait top moumoute !

    Sinon, pour le début, le FPGA, faut être vraiment calé, et de toute façon, c'est pas nécessairement intéressant d'un point de vue consommation
    Ok pour la conso, mais calé comment ? Je lis de temps en temps "Open silicium", et j'avoue être dépassé plus souvent qu'à mon tour ...

  7. #7
    Une architecture Xtensa.

    Et pour le reste, c'est pas une agression : si ce que tu veux faire nécessitait de connaitre en détail le SPARC, le MIPS et quelques autres, ce serait déjà le cas. Apprends d'abord avec les plateformes qui ont des outils utilisables en générique, tu spécialiseras ensuite.

    Pour finir, c'est pas l'architecture qui consomme, c'est la façon dont on s'en sert. Entre un Quark X1000, Core i9 10900k et un Xeon Phi 7250, c'est tous des x86, mais ça fait 1,9W, 125W et 215W en full. Et en cherchant, je peux trouver des x86 encore plus économe, je pense. Genre le Quark D1000 à 0,025W en peak (32MHz) et 0,0016W en creux (1MHz).

    Donc mon conseil, c'est commencer avec une architecture qui dispose d'outils, par exemple une possibilité de compatibilité Arduino (les ESP32, les Quark X1000, ... l'ont), quitte à tourner sur une seconde batterie pour commencer. Et une fois que ça tourne, optimiser. Rien qu'en continuant via Arduino, t'as des marges d'optimisations énormes...

    Mais si tu préfère SPARC à LX6, ARM ou x86... Pas de problème Longan nano, et là t'auras du Sparc-V. Si ma mémoire ne me joue pas trop de tours, il y a même une board à pas très cher avec Longan Nano et FPGA (Tang qqch).

    Des archi actuelles, mortes ou à venir, il y en a eu des tétrachiées. Je ne suis même pas sûr qu'on puisse vraiment les dénombrer. Jusqu'à il y a 1h, j'étais convaincu que les ESP8266 comme j'en ai une dizaine dans la maison, étaient des cortex M0 et j'ai donc, en vérifiant découvert une nouvelle architecture. Et leur décès provient assez souvent du fait qu'elles ne faisaient rien de mieux que les concurrentes. Et occasionnellement du fait qu'elles étaient trop chères. Mais le plus souvent c'est le premier point.


    Aujourd'hui, les outils priment de loin sur l'architecture hardware, jusqu'à un stade très avancé de développement.
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  8. #8
    Citation Envoyé par zithro Voir le message
    1. pour ma moto et l'astronomie, j'ai besoin de systèmes peu gourmands en énergie, sur quelle(s) plateforme(s) partir ? Arduinos trop light en RAM (cause libs non optimisées), Raspis trop gourmands/lourds (pas besoin de tout un OS).
    2. ce qui m'entraîne sur : c'est rentable et/ou utile de partir sur une solution à base de FPGA ? Quels sont les avantages/inconvénients ?
    3. j'ai récup une poignée d'Intel 8080 (1979) et autres chips sortis du futur chez mon revendeur local d'électronique, je peux en faire quoi, enfin surtout comment ?! Bon ok y'a les datasheets, mais le 8080 c'est un dico ...

    Dans le même esprit "architectures" mais moins technique :
    4. dans le dossier CPC-HW "les PC de l'espace" (sur-kiffé d'ailleurs), paraît qu'il y a un SPARC EU, le LEON. Pourquoi c'est pas forké/démocratisé pour les manants/utilisé comme base pour quelque chose de plus public (aux sens institutionnel et particulier), histoire de ne pas dépendre des US (Intel/AMD) ou de l'UK (ARM) ? (PS: DTC Spectre et Meltdown).
    Ca part un peu dans tous les sens et je ne suis pas certain de ce que tu cherches.

    1. SPARC est mort autant laisser tomber
    2. le FPGA n'a aucun interet sauf si tu veux faire ton propre CPU ou si tu as des besoins tres particuliers (et alors il faut connaitre Verilog/VHDL)
    3. entre l'Arduino et les Raspberry il y a tout un spectre tres large. Chez ARM tu as tous les microcontroleurs a base de Cortex-M4 (STM32, NXP, etc.) qui consomment beaucoup moins. Il commence aussi a y avoir des petites cartes sympas a base de RISC-V.

    Concernant ce que tu cherches. Tu veux une board toute faite ? Tu as besoin de quoi en capacite de calcul ? En capacite d'IO ? En RAM ? En stockage ?

    5. sinon on se forme comment quand on veut aller plus loin que "click-click, hoplà ça marche" ? Je parle surtout de l'embarqué/micro-controlleurs. J'ai lu "Code" de Petzold, ça m'a bien plu
    Y'a pas mieux que de mettre les mains dans le cambouis : tu achetes une board pas chere et tu joues

  9. #9
    Citation Envoyé par newbie06 Voir le message
    Y'a pas mieux que de mettre les mains dans le cambouis : tu achetes une board pas chere et tu joues
    Et j'irais sur de l'ESP8266 et de l'ESP32 : il y a un nombre incalculable de boards existantes, une documentation pléthorique, des lib pour l'utiliser avec arduino, avec NodeMCU, des chaines de build, ... Le tout avec des board pour quelques € (J'utilise la Wemos D1 mini pour faire des essais, et pour les quelques trucs que j'ai "en prod", c'est de l'adafruit), y compris des shields pour à peu près tout et n'importe quoi (avec du coup des docs plus ou moins propres), notamment gérer un accu Li-ion.

    Et ça coute tellement rien qu'au moins tu peux en mettre 2 si t'as 2 fonctions à gérer et que ça rentrait pas dans la ram d'un seul.
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  10. #10
    Citation Envoyé par Neo_13 Voir le message
    ESP32. Et si c'est pas suffisant, une batterie de scooter sur un rasp0 fera le job.

    Pourquoi on utilise plus les autres archi ? Parce qu'elles font pas le taff.
    Pourquoi on les utilise dans l'espace, les missiles etc ? Parce que c'est pas le même taff.

    Aujourd'hui, t'as le choix entre ARM pensé pour l'économie d'énergie le plus souvent d'où des difficultés pour monter en perfo (des difficultés, pas des impossibilités), x86 (cas inverse) et les autres, inadaptés dans la plupart des cas et si t'étais dans l'un des cas où ils sont adaptés, tu les connaitrais probablement déjà en détail.
    Pour avoir bien connu des sociétés travaillant avec l'armée, je peux dire que l'armée (et même la DGAC) de voudra jamais d'un système grand public vendu sur étagère. Si les CPUs peuvent parfois être des architectures connues, ce sont toujours des versions + robustes sur des cartes mères/circuit conçus pour une certaine solidité (principalement écarts d'humidité/température mais parfois crash). La plupart des circuit sont conçus spécialement au moins pour une raison : l'armée (au moins la française) demande toujours un support pièce détachées de 25 ans. Donc le fabricant ressort régulièrement des plans des archives pour le support qui reçoit des radars, radios, etc d'époques différentes pour réparation/refabrication. L'entreprise dont je parle fabrique aussi bien de l'équipement de détection, des radios, des transpondeurs, des IFF, des systèmes de commandement complets (là on peut trouver des PC "classiques"), des systèmes anti-contremesures électroniques, etc. et vend aussi bien aux civils qu'aux militaires.
    Dans ce tableau, aucune archi publique sur les systèmes critiques, pour des raison de sécurité et de fiabilité en plus des raisons évoquées par Neo_13. On est dans le "sur-mesure". Après tu as des trucs intéressant comme Space-X qui est parti sur du Linux dans se dernière navette, donc probablement du ARM ou x86. Mais on ne parle là que des IHM...

    C'est plutôt dans l'autre sens que ça se passe, par exemple les lecteurs magnéto-optiques (Iomega...) des années 90 avait été conçus à la base pour l'armée qui voulait éviter qu'un système soit en panne juste à cause d'un choc (HDD head crash).
    Je joue sous Ubuntu ! Abandonnez les OS de Raymond !

  11. #11
    Merci pour toutes vos réponses !
    Bon, pas malin de regrouper toutes mes questions autour d'architectures, ça fout le bordel ^^
    Pour les questions génériques, j'ai ouvert un autre topic : https://forum.canardpc.com/threads/1...-architectures
    Du coup je vais continuer mon problème ici.

    Pour l'instant je bidouille sur Arduino Uno, avec un module GPS et un module GSM, en utilisant les libs fournies, mais je sature la RAM en les utilisant ensemble sur le même Uno.
    J'ai essayé de modifier les libs pour virer ce qui ne me servait pas, j'ai aussi trouvé une lib GPS optimisée en usage RAM (NeoGPS), mais ça suffit toujours pas.
    C'est possible d'ajouter de la RAM et la piloter en SPI (jusqu'à utiliser de la vieille EDO ^^), mais j'aboutis au même problème : il faut modifier les libs pour utiliser la RAM ajoutée, ça devient contraignant !

    Citation Envoyé par newbie06 Voir le message
    Tu as besoin de quoi en capacite de calcul ? En capacite d'IO ? En RAM ? En stockage ?
    Pour le calcul, je sais pas trop, à mon avis pas grand-chose.
    L'IO, de quoi relier les deux modules GPS+GSM, une carte SD/µSD, 2-3 boutons et 2-3 LEDs de fonctionnement/statut, et quelques broches pour l'affichage (3 modules 7 segments voire un module LCD i2c)
    La RAM je ne sais pas trop comment dimensionner ! Faut que les libs GPS, GSM et SD tiennent, durant quelques semaines.
    En stockage, j'ai pas encore testé, mais l'idée serait d'enregistrer mon parcours lors d'une sortie, sur support amovible (SD/micro SD).

    Citation Envoyé par Neo_13 Voir le message
    Et j'irais sur de l'ESP8266 et de l'ESP32 [...] Et ça coute tellement rien qu'au moins tu peux en mettre 2 si t'as 2 fonctions à gérer et que ça rentrait pas dans la ram d'un seul.
    J'ai regardé les ESP et effectivement il y a une myriade de possibilités ! Du coup je suis perdu ^^ Et quasi toutes ont le Bluetooth/Wifi qui ne me servent à rien et pompent du jus (à moins qu'on puisse les désactiver complètement ?)
    Pour des raisons de consommation et d'encombrement, je préfère une carte "plus grosse" que plusieurs. Faut que je planque tout le système dans un endroit sûr, et y'a pas beaucoup de choix sur ma bécane ...
    Et puis il faudrait aussi développer un système de communication entre les deux.

  12. #12
    J'arrive après la guerre, mais j'ai eu une bonne expérience sur les cartes de STMicroelectronics (les nucleo).
    C'est basé sur du Arm et c'est très bien supporté par la suite logiciel Mbed (IDE en ligne avec possibilité de flasher la carte, nombreuses librairies) : ça se rapproche de l'écosystème Arduino avec une gamme de µc plus variée.

    Pour l'ajout de Ram via SPI, c'est quand même pas évident à mettre en place d'un point de vue logiciel (le plus simple serait de l'utiliser comme une zone allouée dynamiquement à mon humble avis), mais en terme de vitesse ça ne va pas aller très vite et il va peut être falloir fabriquer une abstraction logicielle pour te faciliter la vie. À noter que je n'en ai jamais utiliser donc je raconte peut être des salades.

    Pour ton histoire de consommation, à l'initialisation d'un µc, en général les périphériques (tout ce qui est autour du coeur : timer, uart, etc.) sont désactivés et il faut les configurés à la main. Je suppose que c'est pareil pour les ESP.

    Enfin, ça me semble un choix judicieux de tout garder sur une seule carte.

    Pour finir, si tu fais ce projet pour autre chose que l'apprentissage, pourquoi ne pas utiliser un smartphone avec une application d'enregistrement de trace GPS, voir même un GPS dédié ?

  13. #13
    Hello,+1 pour les cartes nucleos.
    Elles embarquent des mcu arm du m0 à 0.3€ jusqu'au gros H7 (480Mhz, I&D cache, DMA chiadé pour un mcu graphique, 1MB de ram).
    Tu peux les 'tweeker' pour optimiser la conso, enfin tu as une pletorde de choix.
    Si vraiment besoins de plus de ram tu as les cartes discovery qui embarquent une petite sdram ou lpram, mais plus à vocation de stockage que d'extension de la pile je suppose.
    Le système de lib proposé est a peu prés aussi facile à utiliser que chez arduino et tu as freertos qui peut être inclus et donc utilisé facilement.
    Salutations,

    Flo

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •