Dimensionner son microcontrolleur

Une des premières recommandations lors du choix d'un microcontrolleur est de porter une attention particulière à la mémoire dont il dispose. La plus contraignante importante est la mémoire Flash, qui stocke le code du programme mis en place.

Mais comment estimer la mémoire nécessaire pour un programme? Pas de secret, il faut le coder! Il est en effet très important d'essayer de réfléchir à l'avance au nombre de librairies externes à importer, de fonctionnalités à implémenter et à la volumétrie de code que cela pourrait représenter. En se donnant évidemment une grande marge d'évolution.

Pour cela, des IDEs comme Atmel Studio peuvent vous indiquer, après compilation, la taille de votre programme (via notament l'outil GCC avr-size). Prenons un exemple :

Un projet ayant choisi un Arduino UNO (ATmega328 - 32Ko Flash) et nécessitant :

  • Une librairie pour carte SD
  • Une librairie pour modules radio XBee
  • Quelques centaines de lignes de code

Voici le résultat de la compilation :

Comme vous pouvez le voir, nous sommes déjà bien au delà de la taille limite...

Quelles sont les pistes d'amélioration? Parmi les plus courantes :

  • réduire au maximum tous les types de données : gain rarement au dessus de 2%
  • jouer sur les optimisations du compilateur (option -O) : gain espéré autour de 2 à 3% (avec l'effet pervers de souvent nuire au debug)

Certains vous diront qu'il faut se passer au maximum des librairies externes pour n'implémenter que le code nécessaire... Je laisse cela à ceux qui aiment réinventer la roue! :)

Donc nous sommes encore loin du compte... Ainsi, sauf si je ne m'abuse, la seule solution est bien de changer de matériel! La famille Atmel propose des microcontrolleurs allant jusqu'à 256 Ko de mémoire Flash, ce qui laisse déjà plus d'amplitude.

Il existe donc d'autres plateformes basées sur ce matériel :

Petite précision : pour continuer à s'amuser sans se ruiner, n'oubliez pas qu'il existe d'autres marques que Arduino, souvent moins onéreuses mais tout à fait compatibles, tant du point de vue matériel que logiciel, puisqu'utilisant les mêmes composants.

Et pour les plus courageux, vous pouvez même essayer de fabriquer vous-mêmes votre plateforme :

Tout cela pour vous dire que si l'Arduino Uno est excellent pour démarrer, si vous avez l'intention d'aller plus loin que faire clignoter quelques LED, il ne faudra pas hésiter à se diriger vers du matériel un peu plus généreux!


Fichier(s) joint(s) :



Présentation de l'AVR Dragon

Comme évoqué dans mon précédent article, la carte AVR Dragon de Atmel permet de débugger et monitorer du code s'exécutant sur les microcontrôleurs AVR.

Mais commençons par le commencement, où se le procurer? En effet, ceci est bien moins simple qu'il n'y parait. Seuls quelques sites proposent de le commander à des prix corrects :

  • Radiospares : le meilleur prix trouvé mais semble-t-il réservé aux professionnels... Impossible de le commander autrement.
  • Digikey : cette fois, c'est plutôt les détails sur la livraison qui font défaut : prix, délais... Reconnu mais pas très clair à mon goût.
  • Enfin, Farnell : un prix de base à peine plus élevé, des frais de transport assez chers, mais une livraison garantie en 24h (j'ai testé).

L'intérêt principal de cet outil est qu'il est largement présenté et décrit sur le net, régulièrement utilisé dans les tutoriels et forcément très bien intégré à l'environnement Atmel, notamment au debugger de Atmel Studio.

Mais avant d'en arriver là, il faudra transpirer encore un peu!

La carte c'est bien, mais comment l'utiliser? Là encore, fouillis sur la toile : ISP, JTAG, HE10... Ouf! Alors pour faire clair, voici ce que j'ai pu en tirer :

Pour un Arduino UNO, la seule interface disponible est l'ISP, composé de 2x3 broches. Malheureusement, ce type de cable est assez difficile à trouver, même sur le net. Et franchement, payer 5€ de frais de port pour un cable à 30cts, non merci! Alors oui, incroyable mais vrai, il va falloir se FABRIQUER le fameux cable...

Voici comment j'y suis parvenu : des connecteurs type HE10 femelle, un nappe de 10 connecteurs, des gaines thermo-rétractables et du courage. Voici ce que cela peut donner (je ne suis pas expert en soudure...) :

Et voici le branchement espéré :

C'est parti? Eh non! Car en l'état, l'interface ISP ne pourra pas reprogrammer le micro-contrôleur : en effet, la carte Arduino possède un capaciteur branché sur le système de RESET, utilisé pour réinitialiser le bootloader lors de la programmation par USB. Et ce capaciteur interfère avec l'usage des modes de debug ISP et DebugWire. Il va donc falloir désactiver ce capaciteur!

Vous trouverez ici une excellente explication de la marche à suivre : Adam Hilltop

Après cette opération, la programmation automatique via la prise USB ne sera plus possible. Il faudra penser à actionner manuellement le bouton RESET de l'Arduino juste avant chaque nouvel upload (ou reconstituer le capaciteur!).

Un autre exemple pour le Duemilanove : Awtfy

Cette fois-ci, normalement, vous avez tout le nécessaire pour commencer à débugger votre code! En attendant mes propres tests, voici encore un peu de lecture :

Go ahead!


Fichier(s) joint(s) :



Debugger avec Arduino

Cet article (un peu long) a pour but de donner un point de vue global sur l'environnement Arduino et les différents outils disponibles, fruit de longues heures de recherches. Aucune vocation à être exhaustif, mais plutôt de permettre de se situer et savoir par où commencer selon vos besoins.

Ayant passé le cap du newbie avec Arduino et ayant donc atteint les limites de l' "IDE" fourni, je cherchais maintenant un moyen d'utiliser un VRAI IDE afin de pouvoir développer de manière plus complexe en C++ (créer des structures, jouer avec le pointeurs) et bénéficier des avantages habituels d'un tel outil : coloration syntaxique, auto-completion, optimisation et... DEBUG!!

Mais tout d'abord, quelles sont les limites de l'outil de développement proposé par la distribution Arduino? En réalité, son intérêt est d' "arranger" le code saisi afin de le rendre compatible à un environnement classique C/C++ (car c'est bien ce qui se cache derrière). Mais on arrive vite au point où cela ne nous "arrange" plus du tout : des erreurs de compilation apparaissent alors que le code est bon (compilable par ailleurs).

De la même façon, l'outil permet de faciliter la programmation de la platine en masquant le travail de la "toolchain". D'ailleurs, petite parenthèse, car souvent sur le net ceci semble inné, mais voici une petite explication de ce qu'est cette AVR Toolchain :

La toolchain AVR — Chaque outil de la chaîne de développement possède un rôle spécifique. Les productions de chaque outil intermédiaire servant à alimenter le suivant:
  • Le compilateur traduit en assembleur les fichiers sources écrit dans un langage de haut niveau;
  • L'assembleur transforme le code assembleur (issu de la compilation ou écrit manuellement par le programmeur) en fichier objet contenant uniquement du code binaire;
  • L'éditeur de liens (linker) rassemble les différents fichiers objets binaires et les bibliothèques en un seul fichier exécutable. L'exécutable peut être directement lancé sur un simulateur ou servir pour le débogueur;
  • Pour la programmation d'un micro-contrôleur, le programme object copy extrait de l'exécutable le code machine sous un format prêt à télécharger sur la cible;
  • Le programmeur est chargé de transférer le code vers la cible.
source : http://www.chicoree.fr/w/USnooBie#GNU_AVR_Toolchain

Mais rentrons dans le vif du sujet, quelles sont les possibilités qui s'offrent à nous pour développer en C/C++ orienté AVR (microcontrôleurs)?

Commençons par le commencement...

Comme nous l'a montré la présentation de la Toolchain, l'outil de base qui va nous permettre de debugger notre projet est donc AVR-GDB (la spécialisation pour AVR du debugger C/C++ nommé GDB).

Après lecture de quelques docs explicatives (pas si faciles à trouver) sur son fonctionnement ici et , on comprend vite qu'il est assez complexe, pouvant être lancé directement à partir d'un fichier compilé ou en mode serveur pour se connecter à un simulateur démarré séparément (voir plus bas).

Les IDEs

Comme tout bon développeur Java, je me suis tout d'abord demandé si mon bon vieux compagnon de route avait de quoi répondre à mes besoins : après quelques recherches sur le net, cette option semble assez complexe. De bonnes connaissances sont à prévoir avant de réussir à bien configurer Eclipse.

Puis, en continuant mes recherches sur le net, je rencontre Code::Blocks, un IDE Open Source, qui semble rencontrer un petit succès auprès des amateurs d'Arduino, surtout grâce à son plugin spécialisé. Après un test rapide, il semble un peu "léger" et je n'ai pas vraiment envie d'essayer de prendre un main un nouvel éditeur.

Continuons les recherches... Voici maintenant Atmel Studio : un IDE entièrement dédié au développement sur microcontrôleur puisque édité par la société qui fabrique un grande majorité des plus usités (notamment la famille ATMega que l'on retrouve sur les Arduino). Génial, oui, mais pas des plus simples à appréhender puisque très spécialisé. De très bon tutoriels un peu partout sur le net donnent heureusement souvent des informations essentielles pour s'en sortir. Gardons le dans un coin et essayons autre chose.

La dernière possibilité restante, Netbeans. Déjà très efficace pour le développement C/C++, sa configuration pour AVR semble plus aisée et largement explicitée comme ici ou ou encore par ici.

Cette piste semblant intéressante, allons plus loin. Après avoir passé quelques heures à m'arracher les cheveux pour faire fonctionner le compilateur C++, le linker, l'auto complétion etc (pourquoi tant de haine?!!!), et alors que la lumière surgissait au bout du tunnel et que j'allais enfin pouvoir commencer à coder, voici que Netbeans semble ne pas être très ami avec AVR-GDB... Quand ce dernier arrive à se lancer, aucun de mes points d'arrêts ne fonctionnent dans Netbeans... Tant pis, essayons d'avancer.

Petit aparté : une alternative aux IDEs classiques est Codebender, un outil de développement collaboratif en ligne. A essayer.

Les simulateurs/émulateurs

Une autre question me vient à l'esprit : plutôt que remettre en place tout mon montage chaque fois que je veux tester mon code, ne serait-il pas possible de simuler le comportement de l'Arduino sur le PC et ainsi gagner du temps?

Sur ce sujet là il existe pléthore de solutions, difficile de s'y retrouver.

Tout d'abord SimulAVR. Il est embarqué avec WinAVR et même présent dans la suite d'outils Arduino. Il se lance à partir d'un fichier ".elf" (produit par la compilation du projet C++) et sert de "serveur" sur lequel peut se connecter AVR-GDB pour exécuter le code, comme expliqué ici. Sa présentation très séduisante (spécialisé AVR...) laisse miroiter des fonctionnalités intéressantes mais très vite après quelques recherches on apprend qu'il n'est en réalité plus maintenu depuis quelques années et très limité...

Nous retrouvons ensuite Atmel Studio : il dispose également d'un simulateur, très souvent décrit et clairement expliqué. Après quelques tests et diverses galères, cette solution semble la plus probante : c'est bien le seul outil qui jusqu'ici m'a permis de dérouler pas à pas mon code. Mais (il en faut bien un), une fois encore les possibilités offertes par ce simulateur sont limitées : impossible de gérer une carte SD ou autre périphérique.

Il existe bien d'autres possibilités, mais hors IDE, comme le simulateur de Virtronics, payant mais pas excessif et très prometteur, ou encore Virtual Breadboard. Mais chacun avec ses inconvénients, souvent trop orienté Arduino ou pas assez, restreignant les possibilités de gérer un gros projet.

Comme vous pouvez le constater, l'écosystème Arduino est très complexe et il est assez difficile de savoir par où commencer et quels sont les bons outils pour des besoins bien précis.

Donc, si vous avez réussi à lire jusqu'ici et pour résumer, que faire? : pour rappel, mon besoin premier étant d'avoir la faculté de suivre l'exécution de mon code pour le débugger, il ne me reste plus qu'une solution, du côté matériel.

Voici donc AVR Dragon! Il s'agit d'une carte créée par la société Atmel elle-même afin d'offrir des fonctionnalités de debug et monitoring du code s'exécutant sur AVR. Toute une histoire!

Pour ne pas faire trop long, je présenterai cette carte dans un prochain article. D'ici là, n'hésitez pas à me faire des retours sur vos diverses expériences avec le développement pour Arduino.


Fichier(s) joint(s) :