Hello.
Depuis un moment déjà, je m' "amuse" à programmer la micro:bit en bare-metal et en assembleur. Je ne tiens pas à développer un truc hyper complet mais juste à comprendre d'un peu plus près les processeurs ARM et leur mode de fonctionnement. Je dois dire que de ce côté c'est assez réussi : l'architecture ARM Cortex M0 qui est utilisée sur le SOC de cette carte est suffisamment simple pour appréhender le monde ARM (jeu d'instruction restreint THUMB, pas de MMU …). Ca permet de 'mettre le pied à l'étrier' relativement faciloement, et de comprendre l'archi ARM "de base", tout en sachant qu'un ARM de raspberry pi est bien plus complexe (mais la base reste la même).
J'aimerais cependant aller un peu plus loin que deux ou trois exemples "basiques" et tenter de mettre en place une petite appli de pilotage d'un robot simple ( un suiveur de ligne par exemple ou autre). Une partie de mes développements/tests nécessiteront du matériel, mais je peux aussi utiliser QEMU pour certaines autres parties (initialisation du hardware, utilisation du timer, communication série, etc …).
Je voudrais pour celà avoir un système un peu plus automatisé qu'un build + lancement manuel de qemu + lancement de gdb + mise en place de points d'arret manuels + contrôle pas à pas que tout ce que je voulais se soit bien passé. J'aimerais mettre un peu plus d'automatisme dedans (par exemple vérifier les valeurs de certaines zones mémoires de façon automatique, et ne lancer le mode trace que lorsque la valeur attendue n'est pas présentée par exemple).
Aussi je me tourne vers vous pour savoir comment vois faites/feriez pour mettre en place des tests automatisés pour la programmation "bas niveau", mais aussi pour satisfaire ma curiosité : comment fait-on ce genre de chose dans le monde industriel : via des outils libres ou du proprio ? Quels outils libres si c'est le cas ?
Merci d'avance.
Quelques infos à propos de la micro:bit :
- en mode qemu, il est possible d'utiliser le moniteur intégré pour inspecter la mémoire (je n'ai pas encore approfondi cette piste mais les commandes ont l'air d'être très proches de gdb).
- la micro-bit intègre une puce dédiée ( MKL26Z128 MCU ) qui permet d'utiliser OpenOCD/GDB pour le debug hardware (DAPlLink protocol).
C'est ce genre de raison qui me font largement préférer la Micro:bit à l'Arduino : pour beaucoup de cartes arduino, en dehors du moniteur arduino, c'est assez difficile d'en faire quelque chose (je pense notamment à la Teensy 4 que j'ai achetée mais qui me sert à rien car le debug n'est possible qu'à coup de printf - et si on veut faire du vrai bas niveau, c'est mort).
# Après quelques heures de réflexion ...
Posté par totof2000 . Évalué à 1. Dernière modification le 18 juillet 2021 à 13:38.
.. je me dis que le CD n'a pas forcément de sens dans le monde de l'embarqué (en tout cas pas tout le temps) … En effet ça nécessite d'avoir un accès réseau à tous les périphériques qu'on veut mettre à jour. Possible sur des équipements connectés en continu tels que des box internet, smartphones mais pas forcément de sens pour des équipements non connectés (et ça existe encore - et j'espere encore pour un bon moment) ou il faut quelqu'un qui aille mettre manuellement à jour l'équipement (firmware d'équipement embarqué dans une automobile, firmware d'unb chauffe-eau, etc …)
# Oscilloscope ?
Posté par Olivier Esver (site web personnel) . Évalué à 3.
J'ai du mal à voir ce que tu veux tester automatiquement en bas niveau…
Lorsque je faisais de l'embarqué et donc du bas niveau au début du projet sur un nouveau processeur, je commençais par faire bagoter une pin (ou plusieurs) pour vérifier les fréquences des différentes horloges du processeur et je vérifiais cela avec un oscilloscope.
Ensuite je rajoutais une liaison série pour les traces de debug (pour le haut niveau et afficher l'état des registres) et puis les autres protocoles dont j'avais besoin (SPI,I2C…)
Mais pour moi, l'oscilloscope est indispensable pour résoudre les problèmes bas niveau, ou pire un analyseur logique.
Après je n'ai jamais automatisé de tests sur le bas niveau car je n'en vois pas l’intérêt.
Pour les printf des registres, il faut bien se dire que c'est l'état du registre au moment ou tu récupères la variable, pas au moment de l'affichage, par exemple si je veux voir l'état du registre de démarrage pour savoir si j'ai redémarré à cause du watchdog, une sous tension ou autre.
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
[^] # Re: Oscilloscope ?
Posté par totof2000 . Évalué à 1. Dernière modification le 18 juillet 2021 à 14:18.
Par exemple, l'affectation de valeurs de variables ou état d'un registre après exécution d'une routine, ou vérifier que certains registres IO sont bien initialisés …. Il y a certains calculs qui ne peuvent être facilement testés juste par du 0/1 sur des ports I/O.
Oui, déjà fait également. Mais je pense qu'il y a moyen d'automatiser ça aussi, mais je ne sais pas encore comment je vais faire (une autre carte avec un timer pour vérifier la fréquence des IT ?).
L'affichage de l'état des registres peut se faire via GDB et OpenOCD sur ma carte, donc pas besoin d'interface supplémentaire ni de print ….
L'osciloscope, j'ai. L'analyseur logique j'ai (pas encore). Si un analyseur logique assez basique … si je trouve un truc meilleur pour pas trop cher j'achète !!!
Ca ça doit être possible en gérant les breakpoints via GDB.
Refactoring de code moins risqué par exemple …
Sinon, pour tester une routine de réception de données sur port série ou I2C, ça permettrait d'aller voir que le buffer de réception contient bien la chaine émise sur le bus …
[^] # Re: Oscilloscope ?
Posté par Olivier Esver (site web personnel) . Évalué à 3. Dernière modification le 19 juillet 2021 à 09:48.
J'ai peut être faux mais il me semble que parfois GDB est plus intrusif et sur du bas niveau il pourrait y avoir des comportements différents avec et sans GDB (avec des print aussi c'est sur)
Pareil pour qemu, il est possible que sur du bas niveau il y ait de petites différences, des bugs hard par example.
Pour effectuer des tests automatiques, peut être que sigrok sait faire, je l'avais testé vite fait avec un petit analyseur logique à 5€ mais je le faisais à la main. Je n'ai pas encore testé avec mon oscillo mais il est dans la section "Mixed-signal devices".
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
[^] # Re: Oscilloscope ?
Posté par totof2000 . Évalué à 1. Dernière modification le 19 juillet 2021 à 12:02.
C'est clair, et c'est quelque chose que l'on doit avoir en tête quand on fait des tests de toute nature. Il est clair qu'un GDB ou un printf ne peuvent pas tout tester mais pour certains types de tests ça peut être intéressant (notamment quand on écrit des routines qui n'ont pas d'effet physiquement propageable vers l'extérieur de la carte, et que dans ce cas la seule solution est d'aller voir l'étatdes registres ou de la mémoire).
Merci pour l'info, je vais creuser cette piste. L'analyseur logique que j'ai a dispo est un analyseur du même ordre de prix (il a quand même un boitier). S'il est compatible ça pourra m'aider.
Après comme dit plus haut je sais qu'i y a des trucs que je ne pourrai pas tester facilement, mais je voudrais quand même automatiser ce qui est automatisable. Et dans mes réflexions, j'ai été un peu curieux de savoir comment on faisait dans le monde industriel (a mon avis il doit y a voir des bancs de tests dédiés ). Je ne pourrai probablement pas mettre en place ce genre de grosse artillerie avec mes faibles moyens, mais peut-être que j'y trouverai de l'inspiration pour bricoler quelque chose qui pourrait m'aider a fiabiliser mes développements).
[^] # Re: Oscilloscope ?
Posté par Olivier Esver (site web personnel) . Évalué à 5. Dernière modification le 19 juillet 2021 à 13:25.
Pour info, travaillant dans l'industrie électronique (chez un EMS), nous testons les produits de différentes façons.
Voici quelques tests qui sont fait sur un produit :
Sur le PCB à la sortie du four de la ligne carte il y a parfois une machine rayon X pour vérifier les non court-circuit sur BGA, ensuite une AOI qui vérifie les soudures et le placement des composants (en 3d maintenant)
Ensuite il peut y avoir du test In Situ, qui est une machine avec des sondes déplaçable et donc souvent on test les non court-circuit avec et des mesures de résistances.
Puis ça peut passer sur un Banc JTAG pour de la programmation et du Boundary-Scan.
Enfin (et c'est sans doute ce qui t'intéresse le plus) ça passe sur un banc de test fonctionnel, et là on pilote des alims, multimètres, DAC, Oscillo, Géné RF, Analyseurs de spectre et autres. Nous utilisons les logiciels propriétaires de National Instrument dont TestStand. Mais c'est souvent pour tester le produit, avec un soft de test ou un mode test, et c'est pour tester l'électronique et le produit complètement assemblé et non le logiciel du client ou des non régressions.
Mais je dois être trop bas dans l'échelle de la conception du produit pour pouvoir te répondre ;-)
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
[^] # Re: Oscilloscope ?
Posté par totof2000 . Évalué à 1.
Merci, en tout cas pour la réponse.
# Les AVR sont sympa
Posté par cg . Évalué à 1.
Je te trouve un poil dur avec ces pauvres AVR.
En fait, il faut avoir un matériel en plus. J'avais un JTAG ICE pour AVR, je pouvais faire du pas à pas, mettre des breakpoints avec avr-gdb, afficher et modifier la mémoire. Et programmer les firmwares sans bootloader, changer les fuses avec avrdude. Le programmeur AVR JTAG n'est pas donné, et ne fonctionne que sur les AVR, certes.
Mais les puces AVR restent des matos assez rustiques et faciles à utiliser en direct. Et ces puces pardonnent pas mal d'erreurs quand même (5V tolerant, récupération par DebugWire, etc…).
[^] # Re: Les AVR sont sympa
Posté par Olivier Esver (site web personnel) . Évalué à 2. Dernière modification le 19 juillet 2021 à 23:59.
J'ai déjà réussi à programmer un avr (AT90USB128, mais j'avais fait ça en Quick and dirty) avec openocd et un FTDI FT2232, il est donc sans doute possible d'utiliser avr-gdb avec, ce qui serait moins cher qu'une JTAG ICE.
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
[^] # Re: Les AVR sont sympa
Posté par totof2000 . Évalué à 1.
Je nai rien contre les aVR, j'ai joué avec (et je le faisd encore à l'occasion). Je pensais plutôt à Arduino, et surtout aux cartes non avr développées spécifiquement pour l'IDE Arduino (Teensy) ou les broches permettant le debug ne sont pas cablée.
Sinon j'ai pas utilisé mais il me semble qu'il est possible de débugger de l'AVR avec un protocole sur 1 fil …
Quel est l'intértet d'avoir une norme (jtag) alors ?
Voilà c'est ça : debugwire. En plus j'aime bien les min i avr à 8 pattes : parfois je trouve que l'arduino pour certains montages est largement overkill et ça me donne une impression de gaspillage.
[^] # Re: Les AVR sont sympa
Posté par cg . Évalué à 1.
Ça c'est une bonne question ! Je suis très loin d'avoir approfondi l'utilisation du JTAG (mes programmes et mes cartes étaient très simples, et souvent quelques
printf()suffisaient pour comprendre les bugs). Si j'ai bien suivi, JTAG définit un protocole et des méthodes pour faire des tests, mais rend possible d'autres applications.Extrait de Wikipedia :
Donc, ces dernières nécessitant un protocole particulier… Ce doit être la raison pour laquelle le AVR JTAG ICE ne sait programmer que les AVR.
Les petits durs de l'électronique pourront préciser/confirmer/infirmer.
[^] # Re: Les AVR sont sympa
Posté par totof2000 . Évalué à 1.
Peut-être que ma question est stupide, mais pourquoi faire porter le protocole au niveau du programmeur ? Il y a probablement une raison que je ne connais pas et si quelqu'u na la réponse, je suis intéressé (je me dis - peut-être bêtement, que l'aspect protocolaire pourrait certinement être géré par le soft qui contrôle le programmeur … - en gros j'ai l'impression qu'on a ici un verrouillage artificiel qui permet aux fabricants d'enfermer les clients dans leur écosystème).
[^] # Re: Les AVR sont sympa
Posté par flavien75 . Évalué à 2. Dernière modification le 23 juillet 2021 à 11:41.
Non, la question mérite d'être posée,
En général le protocole n'est pas géré par le hardware, par contre :
- la plupart des programmeurs ne sont pas documentés et il est donc difficile de faire un driver (de ce côté là l'USB Blaster d'Altera avait bonne réputation)
- on a peu (voire pas du tout) de documentation du côté des micro-contrôleurs
Tout ça fait qu'en général on se retrouve à utiliser la suite du fabricant avec sa sonde. Et leur prix fait souvent peur (60€ c'est pas cher, souvent c'est au moins 300).
Les vrais naviguent en -42
# HIL, ne pas confondre avec HAL
Posté par TheBreton . Évalué à 3.
Hello, dans le monde pro effectivement on utilise des systèmes HIL (Hardware In the Loop) qui permettent une automatisation des tests unitaires et la génération de rapport de conformité du logiciel. Autant dire que la mise en place des test est aussi lourd en charge de travail que l'écriture logiciel. C'est uniquement des logiciels proprio et des bancs de tests HIL créer pour chaque produit et souvent c'est la liaison jtag qui permet l'execution des différents test.
Quand on est dans une petite boite, on fait des plans de validation et des plans de non-régression fonctionnelle que l'on déroule avant chaque livraison au client en utilisant des capteurs et actionneur en charge réel.On utilise de quoi controler les performances attendues (oscillo, multi, analyzer de spectre si on fait de la radio).
Les printf ce n'est pas assez fiable, la plupart des devices n'ayant pas de port série en sortie et d'autre part les printf changent les séquences temporelle de ton logiciel (sauf si ils sont présent dans la version livrée) et j'ai déjà vu des bugs n'apparaitre que parce que les printf était fait et disparaitre en release ou l'inverse, tu as le bug tu mets de printf pour le trouver mais il ne se produit plus…c'est souvent du coté des interruptions qu'il faut allez voir dans ce cas la.
[^] # Re: HIL, ne pas confondre avec HAL
Posté par totof2000 . Évalué à 1.
Hello.
Merci pour ces précisions … J'imagine que le matériel en questiopn doit couter plus qu'un bras … ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.