Développement sur processeur à base de cœur ARM7 sous GNU/Linux

1. Introduction

ARM (Advanced RISC Machines) propose une large gamme de processeurs adaptés aux applications embarquées gourmandes en ressources de calcul (téléphonie mobile, serveurs TCP/IP embarqués, consoles de jeu ...) par leur excellent rendement puissance de calcul/consommation électrique [1]. Afin de maîtriser cet outil que tout développeur de systèmes embarqués ne manquera pas de rencontrer dans ses activités, nous allons nous intéresser à une version microcontrôleur (contenant donc tous les périphériques nécessaires à son fonctionnement – notamment mémoires volatile et non-volatile pour le stockage du programme) incluant un cœur milieu de gamme de type ARM7TDMI. Le composant qui nous intéresse est simple à mettre en œuvre, ne nécessite aucun composant actif externe additionnel pour fonctionner, et est supporté par des outils de développement libres.

Le cœur ARM7TDMI [2] – TDMI signifiant la disponibilité du jeu d’instructions Thumb, d’un Debugger, de la Multiplication matérielle, ICE – propose un processeur 32 bits d’architecture RISC. Équipé de 16 registres, dont 13 disponibles pour le programmeur (les 3 autres étant réservés respectivement à la gestion de la pile, la mémorisation de l’adresse de retour lors d’un saut dans une procédure – fonction habituellement gérée sur la pile sur les autres architectures, et l’index d’exécution du programme [3, p.11]) il fournit une puissance de calcul considérable – exploitée par exemple dans l’iPod [4], Lego Mindstorm NXT [5] et la console Gameboy Advance – pour une surface occupée de l’ordre de 4 cm2 et un coût unitaire de l’ordre de la dizaine d’euros1. Cette architecture est spécifiquement dédiée pour les applications embarquées avec la capacité d’exécuter un jeu d’instructions codés sur 16 bits, économisant ainsi de la mémoire de stockage sans réduire notablement les performances dans la majorité des cas : il s’agit du jeu d’instructions Thumb (le « T » de TDMI).

ARM ne fabrique pas de processeur, mais vend l’architecture du cœur à des fondeurs : diverses sources sont donc disponibles et garantissent la pérennité du code développé sur ce type de processeur, ainsi que sa déclinaison avec une large variété de périphériques. Mentionnons, sans prétention d’exhaustivité, les sources suivantes [6, 7] :

- la série NPX (anciennement Philips) LPC2000 et LH7 ;

- la série Analog Devices ADuC7xxx que nous utiliserons ici2 ;

- série ST STR7 ;

- Freescale MAC7100 ;

- Texas Instruments TMS470 ;

- Atmel AT91SAM7A ;

- la série Cirrus Logic EP7 ;

- Samsung et VLSI qui semblent avoir acquis le droit d’exploiter le cœur pour des applications dédiées ;

- des processeurs à base d’ARM7TDMI qui sont au cœur de la console de jeu GameBoy Advance et coprocesseur de la Nintendo DS (aux côtés d’un ARM9).

Puisque gcc est capable de générer du code pour processeur ARM, nous allons compiler une chaîne de développement libre pour ARM7TDMI, fonctionnelle sous GNU/Linux et l’exploiter pour présenter quelques fonctionnalités de ce processeur. Le processeur que nous avons sélectionné ne possède pas assez de mémoire pour y loger un système d’exploitation : bien que Linux et uClinux soient fonctionnels sur ce type d’architecture [8], nous allons nous contenter de développer des applications dédiées, sans système d’exploitation sous-jacent.

2. Description du matériel

Le matériel nécessaire pour tester les concepts développés dans cet article consiste en une plateforme de développement contenant un processeur de Analog Devices de la classe de ADuC702x. Tous nos exemples ont été testés avec un ADuC7026, initialement sur la carte de démonstration commercialisée par Analog Devices3, puis rapidement sur des circuits spécialement développés pour nos tests (Fig. 1).

Les composants périphériques au microcontrôleur sont un résonateur à quartz à 32 kHz qui sera multiplié en interne pour fournir une horloge jusqu’à 41,78 MHz, une paire de condensateurs de découplage pour les tensions de référence des convertisseurs analogique-numérique et numérique-analogique, ainsi qu’un convertisseur de niveau pour la liaison RS232 ou un FT232RL si la liaison USB est préférable (cas rarement rencontré dans les applications embarquées). Une paire d’interrupteurs, sur les broches RESET (broche 37) et DLOAD (broche 20), permettront de réinitialiser le processeur et de le passer en mode programmation (DLOAD à la masse) en appuyant sur ces boutons simultanément.

Notons par ailleurs la disponibilité de platines de développements réalisées par Olimex (référence ADuC-MT7020, disponible pour 70$ chez Sparkfun) pour processeur ADuC7020 (Fig. 1).

3.Compilateur et outils associés

3.1 La chaîne de cross-compilation

Le cœur ARM7 est exploité dans de nombreuses applications commerciales. Par conséquent, une version de gcc a été portée à cette architecture, avec notamment le support de l’ensemble d’instructions Thumb (option -mthumb). Nous avons, dans notre cas, exploité la procédure de compilation de la toolchain décrite à http//paul.chavent.free.fr/gba-crosscompil.html, à l’exclusion de l’application des patchs spécifiques à la console Gameboy Advance et de l’installation de Insight dont nous n’aurons pas l’utilité. Il s’agit principalement d’exploiter les bonnes versions du trio gcc, binutils et newlib (4.0.0, 2.15 et 1.13.0 respectivement) configurées (configure) avec les options --target=arm-thumb-elf --without-local-prefix --disable-shared --enable-multilib --disable-threads --with-cpu="arm7tdmi" --enable-interwork --enable-languages="c,c++" --disable-nls sans oublier le répertoire d’installation avec --prefix.

Une alternative, pour les plus impatients, à la compilation manuelle de la toolchain est, si l’exploitation du code thumb n’est pas une priorité, d’utiliser la toolchain précompilée fournie sous forme d’exécutables pour Intel x86 par le projet uClinux à http://www.uclinux.org/pub/uClinux/dist/. Cette toolchain fournit glibc au lieu de newlib : dans ce cas, toute tentative d’exploitation de stdio sur ADuC7026 se traduit par le dépassement de la capacité de mémoire non volatile et l’impossibilité de compiler le code. Il faudra donc éviter d’utiliser tout appel aux fonctions de type printf, gestion des chaînes de caractères ou bibliothèques de fonctions mathématiques.

3.2 Compiler un programme pour ARM7TDMI

Ayant obtenu une toolchain, nous allons décrire les étapes pour générer un fichier prêt à être transmis au microcontrôleur : assemblage, linkage des objets et des bibliothèques, puis extraction du contenu de la mémoire dans un format prêt au transfert par RS232. L’ensemble de ces opérations sera classiquement automatisée dans un Makefile.

Bien que nous programmions un processeur aussi puissant que l’ARM7 en C, il est toujours bon de pouvoir revenir à l’assembleur, qu’il s’agisse en vue d’optimisations de bouts de codes ou pour vérifier si gcc a généré un code convenable et réalisant les tâches attendues : arm-thumb-elf-objdump -h -S -C fichier.elf > fichier.lst produit la séquence de mnémoniques, leurs arguments et leur emplacement en mémoire.

La compilation s’obtient, pour du code assembleur, par

et pour le code C par

Nous pourrons éventuellement ajouter l’option -mthumb pour exploiter le jeu d’instructions 16 bits. L’intérêt de ce jeu d’instructions est de réduire la taille de l’exécutable en ne fournissant qu’un sous-ensemble des fonctionnalités du jeu d’instructions 32 bits. Les gains ne sont pas aussi intéressants qu’il pourrait y paraître, car il faut souvent plusieurs instructions Thumb pour effectuer la même opération qu’en jeu d’instructions ARM. Le gain est estimé à 20-30% en espace occupé par le code au lieu des 50% attendus [9, 2].

Le fichier au format ELF n’est pas reconnu en l’état par les outils de transfert du programme vers la mémoire flash du microcontrôleur : il faut générer, à partir du binaire, un fichier reproduisant le futur contenu de la mémoire. Ainsi, le code en C aura été converti en un fichier contenant au format hexadécimal intel la séquence des opcodes et de leurs arguments. Le passage du format ELF au format hexadécimal Intel s’obtient par la version appropriée d’objcopy : arm-thumb-elf-objcopy -O ihex fichier.elf fichier.hex

Ayant identifié une toolchain de cross-compilation fonctionnelle et les éventuelles bibliothèques de fonctions nécessaires aux développements, il nous reste à configurer le processeur lors de sa mise en marche pour un fonctionnement correspondant à nos attentes. D’habitude, gcc cherche à linker un programme avec l’objet issu de la compilation de crt0.S qui effectue l’appel à la fonction main() par convention4.

Dans les exemples qui vont suivre, nous linkerons systématiquement un fichier nommé startup.S proposé par Martin Thomas à http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index_adi_arm.html#aduc_gpio, issu d’une traduction pour gcc du fichier de configuration proposé par le vendeur de compilateurs propriétaires Keil. Ce fichier est chargé de l’initialisation de registres fondamentaux au fonctionnement du processeur (multiplication d’horloge par PLL, piles, points de retour par défaut des interruptions) et des périphériques (ports d’entrée/sortie notamment), ainsi que l’exécution sur le point d’entrée par défaut d’un programme C nommé main(). Par ailleurs, le linker exploite par l’option -T le script ADuC7026-ROM.ld de Martin Thomas5 pour définir les emplacements des divers éléments du programme (pile, tas, RAM, mémoire flash). Nous profiterons de cette archive pour y trouver un exemple d’initialisation (startup.S) et de gestion des interruptions (irq.c) à linker à nos propres applications.

3.3 Transférer le programme au processeur

L’ADuC7026 est muni d’un bootloader capable de charger par le port série et de placer en mémoire non volatile (flash) un programme. Nous avons utilisé avec succès deux programmes permettant la communication avec le microcontrôleur depuis GNU/Linux :

- armwsd, court et très efficace, contient en dur le nom du port série utilisé, et lit le fichier au format hexadécimal Intel sur stdin. L’unique programme C est disponible à http://www.koka-in.org/~kensyu/handicraft/misc/armwsd.c, se compile trivialement et s’exécute par

- aducloader6, plus complet, accepte des arguments pour définir le périphérique de communication série, le nom du programme à placer dans le microcontrôleur (au format hexadécimal Intel) et la vitesse de communication : par exemple, aducloader --ttyfile=/dev/ttyUSB0 --ihexfile=blinky.hex

Dans tous les cas, le transfert du programme en mémoire flash du microcontrôleur s’obtient en appuyant sur DLOAD, puis en validant brièvement la broche de RESET et, enfin, en lançant le programme de communication sur le PC (le microcontrôleur doit donc être en attente des ordres du logiciel de communication avant le lancement de ce dernier). Plusieurs essais sont parfois nécessaires afin de vider l’UART du PC des caractères résiduels, afin que le logiciel reçoive le bon identifiant de microcontrôleur en réponse à ses requêtes.

3.4 Gestion des ports numériques d’entrée/sortie

Le premier exemple pour découvrir tout nouveau microcontrôleur consiste à faire clignoter une diode. Au-delà de la validation de la chaîne de cross-compilation, de l’outil de transfert des programmes en mémoire non volatile et du programme d’initialisation du microcontrôleur et d’appel à la fonction main(), il s’agit de la première découverte des spécificités matérielles du microcontrôleur, dont le périphérique le plus simple est le port numérique d’entrée/sortie (General Purpose Input/Output, GPIO).

Dans le cas particulier de l’ADuC7026, chaque port est représenté par un registre de 32 bits (GPxDAT), dont les 8 bits de poids les plus forts représentent la direction de chaque bit du port (1 pour la sortie, 0 pour l’entrée), les 8 bits suivants définissent la valeur en sortie, les 8 bits suivants mémorisent l’état du port au moment de la réinitialisation et, finalement, les 8 bits de poids les plus faibles donnent la lecture des valeurs des bits en entrée. Le fait qu’autant de fonctions soient réunies dans un même registre signifie que nous y ferons le plus souvent appel – après une affectation pour l’initialisation – par un masquage.

Les 5 ports sont accessibles par les registres GPiDAT, i ∈ [0..4].

Pour, par exemple, faire clignoter une diode associée à une broche du port 4, une initialisation du registre GP4DAT pour définir les broches en sortie est suivie d’une boucle infinie sur un XOR pour changer l’état des diodes à chaque itération :

3.5 Configuration et communication sur port série asynchrone

Les ports d’entrée/sortie numérique ont chacun une multitude de fonctions (au plus 4 par broche, définies sur 2 bits pour chaque broche dans le registre GPxCON pour le port x), soit comme bits contrôlés individuellement, soit en relation avec un périphérique plus complexe tel qu’un UART. Pour l’ADuC7026, cette configuration se fait par le registre GP1CON (configuration du port 1) qui, pour une exploitation des broches P1.0 et P1.1 en vue d’une communication asynchrone, s’obtient par GP1CON = 0x011.

Ayant configuré les broches, il nous faut définir la vitesse de communication en divisant par un facteur approprié l’horloge interne du processeur :

On adaptera COMDIV0 au baudrate recherché, avec 23 (décimal) pour du 57600 bauds ou 0x22 pour 38400 bauds.

Finalement, la communication se fait en vérifiant l’état de l’UART et en lisant ou écrivant un octet : il n’existe pas de pile pour accumuler les caractères transmis et toute nouvelle donnée écrase irrémédiablement la précédente :

La fonction uart0_getc() proposée ici est bloquante comme le requiert la norme de l’ANSI C : si le besoin d’interroger le port série sans bloquer l’exécution du programme jusqu’à la prochaine transmission de données, on pourra remplacer le while par un test if sur l’état du registre COMSTA0 : if((0x01==(COMSTA0 & 0x01))) return (COMRX); else return(0);.

3.6 Le problème de newlib

Nous désirions, lors de la mise en œuvre de ces outils de travail, ne pas être restreint par rapport aux outils fournis par Keil7 pour MS-Windows avec le kit de démonstration de l’ADuC7026. Cela signifie notamment disposer d’une implémentation de stdio capable d’afficher des messages sur le port série par printf(), ainsi qu’une bibliothèque mathématique capable d’émuler de façon logicielle du calcul sur des nombres flottants. Le choix par défaut d’une bibliothèque libre supportant ces fonctionnalités est newlib, dont nous allons montrer qu’il est totalement inapproprié pour ces applications fortement embarquées à faible empreinte mémoire. En effet, les performances de newlib sont dignes des besoins d’un système d’exploitation, avec la consommation de ressources associée. Par exemple, Keil a fait le choix de ne nécessiter que la redéfinition de putchar() et getchar() pour implémenter un sous-ensemble des fonctions associées à stdio. Au contraire, newlib fournit au travers de ses stubs (code Tab. 1) une implémentation complète, mais beaucoup plus gourmande en ressources de stdio, avec notamment l’exploitation de malloc.

Keil semble avoir développé ses propres implémentations de printf et autres fonctions d’affichage avec une empreinte mémoire réduite. Nous avons donc deux solutions :

- écrire nos propres routines d’affichage répondant aux besoins spécifiques de chaque programme, par exemple pour les cas les plus courants de débogage, afficher en hexadécimal des entiers de différentes tailles. Cette solution est favorisée par les auteurs, mais nécessite un investissement initial supplémentaire qui peut rebuter le développeur lors de son choix entre une toolchain libre ou propriétaire ne nécessitant pas de tels développements initiaux.

- proposer une implémentation complète de stdio, avec une empreinte mémoire aussi faible que possible, sans être nécessairement aussi performant que l’implémentation dédiée de Keil. C’est cette seconde solution que nous allons développer ici en présentant l’exploitation de newlib sur ARM7TDMI.

Dans tous les exemples qui suivent, nous linkerons nos programmes avec le code syscalls.c contenant ces stubs8 (code Tab. 1 dérivé de la description fournie à http://www.embeddedrelated.com/groups/lpc2000/show/5873.php). L’objectif de ces points d’entrée est de fournir quelques méthodes standards afin d’informer newlib comment interagir avec l’utilisateur (lire et écrire un caractère), ainsi que sur la gestion de la mémoire. Les prototypes de fonctions sont imposés et nous nous sommes contentés d’ajouter les fonctions de lecture et d’écriture sur le port série.

Une fois les stubs définis dans syscalls.c – et notamment les fonctions _read_r() et _write_r() pour la lecture et l’écriture sur le port série, nous sommes en mesure d’utiliser les fonctions de gestion de chaînes de caractères comme nous le ferions habituellement en ANSI C. Noter que la compréhension des méthodes d’interfaçage avec newlib est un investissement qui peut s’avérer utile puisque exploitable sur tout microcontrôleur suffisamment puissant pour supporter cette bibliothèque de fonctions.

L’utilisation de printf et du calcul flottant n’est pas à prendre à la légère : nous illustrons l’explosion de la taille du code lors de l’utilisation de printf() et d’une fonction de calcul flottant (atan()) dans la table 2.

4.Quelques exemples d’applications

4.1 Communication synchrone : affichage sur écran LCD graphique

La communication synchrone – SPI pour des signaux unidirectionnels du maître vers l’esclave (MOSI) et de l’esclave vers le maître (MISO), et I2C pour un signal de données bidirectionnel – partage une horloge entre les interlocuteurs et permet par conséquent un débit de communication plus élevé que la communication asynchrone. Ce protocole est par conséquent exploité dans de nombreux périphériques, dont nous allons présenter 3 exemples ici : afficheur graphique, carte mémoire SD et synthétiseur de fréquence. Un protocole synchrone est facile à implémenter de façon logicielle en manipulant les bits d’un port général d’entrée sortie, mais le résultat s’obtient au détriment des performances. L’ADuC propose une implémentation matérielle de la communication synchrone qui s’obtient par une configuration appropriée de l’UART via le registre GP1CON : comme les broches de communication synchrones (P1.4 à P1.7) et asynchrone (P1.0 et P1.1) sont distinctes, ces deux modes de communication peuvent être exploités simultanément : GP1CON=0x22220011.

Cependant, dans ce premier exemple, la communication des données avec un écran LCD graphique nécessite de communiquer une donnée sur 9 bits, format quelque peu inhabituel et qui n’est pas supporté de façon matérielle par l’ADuC7026 : une implémentation logicielle s’impose donc. Nous sommes partis de l’archive NokiaLCD_LPC21489 et nous nous sommes contentés d’adapter la gestion des ports d’entrée/sortie du microcontrôleur NXP à l’ADuC7026 (Code. Tab. 3 et Fig. 2).

Les principales modifications portent sur la définition des signaux de communication : étant donné que la communication synchrone est émulée de façon logicielle, nous n’abordons pas ici la programmation du contrôleur SPI, mais il suffit, lors du portage de la bibliothèque de fonctions de communication avec le LCD LCD_driver.c, de redéfinir les broches de communication. Nous avons, dans nos développements, exploité P1.4 et P1.6 respectivement comme broches d’horloge et de communication du maître (le microcontrôleur) vers l’esclave (le LCD), tandis que la broche d’activation du périphérique (Chip Select actif bas) est associée à P4.4. Le RESET du LCD s’obtient par manipulation de la broche P4.2. Ces divers signaux sont manipulés dans les fonctions LCD_init(), LCD_command(), et LCD_data(). Le reste du code (allumage d’un pixel, définition de sa couleur, dessin de motifs plus complexes) est portable, puisqu’il fait appel à ces fonctions qui sont les seules à accéder au matériel et donc à dépendre de la plateforme de développement.

La durée d’affichage d’un motif sur l’ensemble des 132×132 pixels de l’écran est de l’ordre de 2,5 s, soit environ 75 µs pour définir la couleur d’un pixel. Selon l’utilisation du LCD (par exemple tracer une courbe ou un sprite sur un sous-ensemble de la surface active), le taux de rafraîchissement pourra aller du hertz à quelques centaines de Hz. Un exemple d’affichage sur toute la surface du LCD est proposé dans le code 3 qui exploite LCD_driver.c. Ce programme attend en entrée des couleurs c au format 8 bits du LCD, soit RRRGGGBB : ce format s’obtient, depuis une image au format PPM classique, en convertissant chaque pixel dont la couleur est définie sur 3 octets r, g et b par le masque c=((r&0xE0)+((g&0xE0)>>3)+((b&0xC0)>>6));.

4.2 Communication synchrone : stockage au format FAT sur carte SD

Nous avons déjà présenté à plusieurs reprises, dans différents contextes, l’exploitation des cartes de stockage de masse non volatiles de format Secure Digital (SD) pour fournir un mode de conservation quasi illimité des informations acquises par un système embarqué. Dans la plupart des cas, nous nous sommes contentés de stocker les informations sur le support de stockage sans formatage : cette méthode, efficace en ressources consommées, ne permet cependant pas de définir des notions telles que fichier et répertoire, et implique de restituer les informations par le même système que celui utilisé pour le stockage.

Afin d’étendre les perspectives du stockage de masse sur système embarqué, nous nous sommes proposés d’exploiter un support formaté selon un protocole reconnu par la majorité des systèmes d’exploitation modernes, et néanmoins compatible avec les performances d’un système fortement restreint tel que proposé par l’ADuC7026. Nous nous sommes par conséquent tournés vers le format FAT, suffisamment ancien pour être compatible avec une application embarquée et néanmoins toujours supporté par les systèmes récents, en portant une de ses multiples implémentations sur ARM7. Nous avons sélectionné au hasard efsl, et en particulier sa version 0.2.8, comme bibliothèque implémentant la plupart des méthodes supportant le format FAT (création de fichier, écriture et lecture).

efsl est fourni avec le support pour un certain nombre de plateformes, définies dans le répertoire conf/ et par un Makefile approprié. Nous prendrons donc soin de renommer le fichier de configuration approprié dans conf/ en config.h et d’adapter les chemins d’accès vers son compilateur favori dans le Makefile.

Un premier essai pour se familiariser avec la bibliothèque de fonctions efsl et les exemples associés peut se faire sous GNU/Linux au moyen d’un système de fichiers virtuel obtenu par dd if=/dev/zero of=test.dd bs=512 count=1024 pour créer un espace disque virtuel de 512 KB, suivi de mkfs -t vfat test.dd pour le formatage. Ce système de fichier est accessible soit par la fonction open("test.dd",...) du C, soit par mount -o loop test.dd /mnt depuis le shell.

Un exemple d’accès à un système de fichier ainsi créé depuis efsl est proposé ci-dessous, pour une compilation et une exécution sous GNU/Linux par : gcc -I inc/ -I conf -o linuxtest linuxtest.c -L. -lefsl

Au premier accès, le ficher recherché n’existe pas et il doit être créé :

Au second accès, le fichier est créé et contient du texte qui est affiché :

Ceci continue à chaque exécution du programme de démonstration :

Le même résultat est observable sur ADuC7026, exécutant un programme similaire cross-compilé et lié à la bibliothèque de fonctions efsl convenablement adaptée (Fig. 3). Un rapide test de performances, sans prétention d’exhaustivité, montre que l’écriture de 100000 chaînes de 41 caractères (pour créer un fichier de 4,1 MB) prend 138 secondes, soit un débit de l’ordre de 29 KB/s. Un fichier de même taille, mais obtenu par écriture de 50000 chaînes de 84 caractères ne prend que 80 secondes, soit un débit à peu près double de 52 KB/s. Il semble intuitif que le bloc de données stocké sur SD étant de 512 B, les performances vont s’améliorer lorsque la donnée à stocker atteint cette taille, cas néanmoins peu représentatif du système embarqué chargé d’acquérir épisodiquement des données scalaires.

Comme dans le cas du LCD, l’adaptation du code de efsl à une nouvelle architecture consiste en la redéfinition des quelques fonctions de communication entre l’ADuC7026 et la carte SD, sans avoir à reprendre toutes les fonctions de plus haut niveau de gestion du format FAT. L’ensemble de ces fonctions se regroupe dans src/interfaces de efsl-0.2.8 : initialisation de la carte SD (sd_Init()), communication de commandes à la SD avec gestion du signal d’activation Chip Select (sd_Command()) au moyen de fonctions de base du support SPI (com_spi()). Avant de prétendre inclure toutes ces fonctions dans un environnement de travail aussi complexe que efsl, il est judicieux de valider les fonctions de base d’initialisation de la carte, lecture d’un bloc de donnée en mémoire SD (fonction MMCread_block()) et écriture d’un bloc de donnée (fonction MMCwrite_block()). Nous ne décrirons pas ici le protocole de fonctionnement de ces fonctions, qui a déjà été développé auparavant [11] et dont l’implémentation est parfaitement lisible dans le code source.

4.3 Gestion des interruptions

Les interruptions sont un élément essentiel pour une programmation efficace d’un système embarqué chargé de réagir à son environnement. Les évènements peuvent être à l’expiration d’un intervalle de temps, une transition de signal sur une broche ou la transmission de données sur un périphérique de communication. Deux points rendent la maîtrise des interruptions complexe dans l’environnement que nous décrivons : d’une part, la disponibilité de deux encodages pour nos exécutables (16 bits en thumb ou 32 bits, le premier mode n’étant pas compatible avec une utilisation dans le gestionnaire d’interruptions – ISR), et, d’autre part, un bug subsistant dans toutes les versions de gcc que nous avons utilisées (de 3.3 à 4.0.0), qui génère un code susceptible de corrompre des variables lors du retour de l’ISR. Nous avons constaté que l’assignation d’une valeur à une variable dans l’ISR fonctionne correctement, mais incrémenter ou manipuler une variable pour modifier son état antérieur ne fonctionne pas, laissant présager un problème avec la lecture de l’état de la variable lors de l’entrée dans l’ISR.

Deux ensembles d’interruptions sont particulièrement utiles lors du développement d’applications multitâches (code 4) :

- Les interruptions timer qui permettent de séquencer les opérations.

- Une interruption associée à la communication série asynchrone qui permet d’arrêter l’exécution séquentielle du programme pour recevoir un message transmis par RS232, et notamment de remplir une queue de caractères afin de ne pas perdre de caractère, puisque l’ADuC7026 ne possède qu’un unique registre pour stocker les caractères reçus. En cas d’activité au moment de la réception de ce caractère, un mode polling pourrait résulter en une perte de données si le traitement de la commande n’est pas achevé avant la transmission du caractère suivant.

4.4 Communication radiofréquence

La génération d’une interruption timer permet de déclencher un évènement à des intervalles de temps précis. Cela permet notamment de réaliser une communication asynchrone de façon logicielle et ainsi pallier la limitation d’un unique port série, mais surtout de réaliser un port série logiciel communiquant par une autre voie que la liaison filaire. En plus de simplement déclencher une transition de niveau en fonction de la valeur du bit à transmettre (fonction classique d’un UART), nous pouvons effectuer des tâches plus complexes tant que leur durée d’exécution est inférieure à l’intervalle de temps défini par le timer.

Une application qui nous a intéressé est la transmission de données numériques par liaison radiofréquence, et ce, avec le montage nécessitant le moins de composants possibles. Nous proposons ici un montage avec un unique composant numérique – le synthétiseur direct radiofréquence (DDS) AD9954. Toutes les communications entre le microcontrôleur et l’AD9954 se font en SPI, avec deux signaux additionnels de validation des informations transmises, ici implémenté par un GPIO, que nous décrirons en détail plus loin.

La stratégie qui dirige nos choix technologiques est de maintenir le nombre de composants au minimum (gain en place et en consommation) et de définir le maximum d’opérations par logiciel afin de conserver un maximum de souplesse. La transmission se fera par modulation FSK (Frequency Shift Keying) : chaque valeur de bit à transmettre sera codée par une fréquence différente. Nous travaillerons ici sur 2 valeurs possibles de bits (une fréquence pour 1 et une fréquence pour 0). La stratégie que nous nous sommes proposés d’implémenter est la suivante :

- Deux fréquences correspondant aux 1 et 0 à transmettre sont programmées par bus SPI dans le DDS : par exemple 138 MHz+1200 Hz et 138 MHz+2200 Hz.

- Une interruption timer du microcontrôleur teste si un octet est en cours de transfert et, si c’est le cas, définit le bit à transmettre et donc la valeur de la fréquence à programmer dans le DDS (par exemple interruption toutes les 833 µs pour du 1200 bauds).

- Du point de vue de la démodulation, un scanner AOR3000A est placé en mode CW pour une démodulation avec un oscillateur local à 138 MHz. Les deux tonalités issues du mélange sont alors à 1200 et 2200 Hz.

- une PLL de type XR2211 convertit les deux tons en signaux TTL, transmis au port série après passage dans un MAX232. Ce composant, obsolète, contient un exemple d’application qui correspond exactement à notre application : il mériterait cependant d’être remplacé par un composant plus récent. Une alternative intéressante – que nous n’avons pas réussi à mettre en œuvre dans ce cas – est la démodulation par logicielle après acquisition par carte son du signal audio issu du récepteur radiofréquence (par exemple par multimon).

Cette stratégie s’est avérée à l’usage peu robuste, car fortement dépendante de la fréquence de l’oscillateur local embarqué qui cadence le synthétiseur. Ce point est fondamental pour comprendre par ailleurs pourquoi une stratégie de type modulation (par exemple modulation de fréquence FM) est robuste, contrairement à notre stratégie :

- Dans une modulation de fréquence (Fig. 5, haut), une porteuse (par exemple 138 MHz) est modulée par la fréquence codant la valeur du bit à transmettre. Le spectre résultant contient 3 raies : la porteuse, et les deux raies de modulation de part et d’autre de la porteuse. Lors de la démodulation, le récepteur peut se caler sur la porteuse afin de se recentrer pour convenablement identifier les raies de modulation. La référence (la porteuse) est donc contenue dans le signal, et toute dérive de l’oscillateur embarqué se traduit par une dérive de la porteuse, sur laquelle le récepteur peut se recaler tant que la dérive est inférieure à la bande passante du filtre de réception. Dans le schéma de démodulation que nous proposons, le signal d’erreur entre l’oscillateur local et la porteuse est directement disponible en sortie du filtre passe-bas LPF2 dont la fréquence de coupure est sous la fréquence de modulation audio (filtre très lent). Le filtre LPF1 a uniquement pour vocation de retirer les raies inutiles issues du mélangeur et a une fréquence de coupure au-dessus de la fréquence audio.

- Dans notre stratégie, nous ne transmettons qu’une unique raie – l’équivalent de la porteuse dans le cas précédent – et faisons l’hypothèse de connaître la fréquence de référence que nous avons fixé par convention, et qui est la fréquence que nous programmons dans le récepteur radio. Cependant, toute dérive de l’oscillateur embarqué qui cadence le DDS par rapport à l’oscillateur local du récepteur au sol se traduit par une dérive de la sortie du mélange et donc une fréquence audio de sortie qui n’est pas une des valeurs désirées. Par ailleurs, tout biais initial d’un des deux oscillateurs se traduit par un décalage entre la fréquence théorique à programmer, et la fréquence que nous programmons en pratique dans le récepteur pour obtenir un signal audio exploitable. Nous avons constaté en pratique qu’une correction de quelques centaines de Hz est nécessaire, probablement en raison d’un décalage du résonateur faible coût embarqué aux côtés de l’AD9954 ou d’un ajustement peu précis des condensateurs de pieds de l’oscillateur.

Le synthétiseur de fréquences direct AD9954 se programme par protocole SPI et ne nécessite donc que 5 signaux de l’ADuC7026 : horloge, données du microcontrôleur vers le DDS, signal d’activation (Chip Select, actif bas), reset et un signal de validation de fin de transfert nommé LE (Latch Enable) ou FQ_UD.

Après avoir chargé le fichier de définition des symboles associés aux périphériques de l’ADuC7026, nous déterminons les deux fréquences de communication qui correspondent aux transmissions de bit 1 et 0. Un troisième état d’absence de communication est prévu, mais ne sera pas utilisé. Ces mots s’obtiennent en calcul motbits=freqvoulue/400×232 avec 400 la fréquence d’horloge interne au DDS obtenue en multipliant par 20 l’oscillateur externe (résonateur 20 MHz).

La configuration des registres du DDS se résume en l’application des valeurs proposées dans la datasheet, avec une multiplication par 20 par PLL de la fréquence du résonateur externe. Le premier octet correspond à l’adresse de chaque registre dans le DDS.

La fonction de délai par boucle vide est une façon gourmande en énergie et en ressources de faire patienter le microcontrôleur, mais tellement simple à mettre en œuvre par rapport à une interruption timer que nous ne résisterons pas à l’envie de l’utiliser. Cette fonction est d’autant plus une mauvaise idée qu’elle est programmée en C et donc sa durée dépend du compilateur, du niveau d’optimisation et donc du code assembleur généré (section 5).

Les routines de communication avec le DDS sont simples et se contentent d’exploiter la communication par interface SPI fournie comme périphérique matériel par l’ADuC7026. Les signaux de contrôle de la communication avec le DDS sont générés manuellement en plus de la communication synchrone.

En plus de la communication par liaison radiofréquence, nous désirons maintenir la possibilité de déboguer le programme par une liaison RS232 classique cadencée par UART, obtenue en définissant la valeur d’une broche de GPIO (P4.0 dans la fonction programme() de l’exemple proposé ci-dessus) en même temps que la programmation du DDS. Cette émulation logicielle d’un port série permet d’étendre le nombre de ports de communication asynchrone au-delà des UART fournis par le microcontrôleurs.

Finalement, le cœur de notre démonstration de synthèse d’UART logiciel – que ce soit en vue d’une liaison radiofréquence ou filaire – est centrée sur l’exploitation d’une interruption timer afin de changer l’état de la broche de communication à intervalles de temps réguliers correspondant au baud rate (833 µs pour 1200 bauds).

Rappelons que, dans cet exemple, l’AD9954 est cadencé par un résonateur à 20 MHz, multiplié en interne pour générer un signal d’horloge à 400 MHz – facteur de multiplication défini par logiciel dans le registre CFR2 du DDS – qui permet alors une synthèse de n’importe quelle fréquence entre 0 et 133 MHz. La fréquence qui nous intéresse dans le cadre de la communication dans un projet de Planète Sciences sur les fréquences allouées au CNES (autour de 138 MHz) sont suffisamment proches pour être exploitables tout en conservant un filtre passe bas en sortie de DDS pour filtrer efficacement l’horloge (400 MHz) et les raies parasites (400±138 MHz).

Le microcontrôleur reprogramme par le port SPI la nouvelle fréquence à émettre correspondant à chaque nouveau bit à transmettre. Du côté de la réception, un mélange avec un oscillateur à 138 MHz génère les signaux aux fréquences audio correspondant aux 1 et 0, qui sont alors fournis à un MAX232 pour mise à niveau et exploitation par l’UART du PC. Ce concept a été mis en œuvre dans diverses situations, allant d’une liaison sur plusieurs dizaines de mètres en vue directe entre émetteur et récepteur, à une communication pendant 11 h pour accumuler une statistique de taux d’erreur sur près de 500 KB transmis (Fig. 6). Dans ce second cas, il est intéressant de noter que le taux d’erreur évolue avec le temps du fait de la dérive avec la température soit de l’oscillateur du récepteur radio, mais plus probablement de la température du quartz qui cadence le DDS. Afin de tourner cette dérive à notre avantage, il serait envisageable d’observer les fréquences du signal audio reçu, en observer l’écart à la consigne (et ainsi corriger la fréquence du récepteur CW) tout en déduisant ainsi la température du résonateur à quartz fixé sur la carte du DDS. Avec un récepteur convenablement réglé, le taux d’erreur est inférieur au pourcent, nécessitant soit une redondance, soit un code correcteur d’erreurs pour être exploité dans une application autre que purement démonstrative.

Une perspective intéressante de ce travail serait d’exploiter la RAM interne à l’AD9954 qui permet de configurer une séquence quelconque de fréquences à émettre, et notamment la suite de fréquences correspondant à une modulation de fréquence. Dans ce cas, la commutation entre transmission de 1 ou de 0 en FSK serait simplement activée en modifiant la vitesse à laquelle la RAM est balayée pour mettre à jour la fréquence émise.

5. Comparaison de compilateurs

L’exemple qui suit n’a pas pour vocation de comparer les performances de divers compilateurs (gcc 4.0.0 et Keil 2.42), mais simplement d’insister sur le fait qu’un langage de haut niveau tel que le C peut résulter en des codes assembleur (et donc des occupations mémoire et temps d’exécution) très différents selon les compilateurs et options de compilation, et que seul le langage machine garantit un résultat optimal et reproductible pour définir les tâches les plus importantes d’un code : nous compilons avec arm-gcc-4.0 et la version 2.42 du compilateur propriétaire de Keil la boucle vide void delay (int length) while (length >=0) length--;. Ce type de code, bien que résultant en des délais dépendant du compilateur, se retrouve souvent dans les programmes qui nécessitent une temporisation fine (<1 ms) de leur exécution :

Nous noterons que les deux compilateurs effectuent un passage de paramètre par le registre r0, mais là où gcc se contente de générer un code limpide limité à une soustraction et une comparaison, le compilateur Keil exploite la pile (r13 sur laquelle est placée la valeur de length grâce au premier push) et le registre r1 comme intermédiaire de ses calculs. La pile est dans ce cas remise en état en fin de boucle en ajoutant 4 au pointeur de pile r13. La conséquence est un temps d’exécution considérablement plus long – pour une même valeur de length – lorsque le code C est compilé par l’outil Keil que par gcc. Nous avons observé des manipulations de registres similaires par le compilateur Keil dans des bouts de code qui n’avaient pas pour vocation à être des attentes et dont la vitesse d’exécution devait être maximale. L’élimination manuelle de ces manipulations inutiles dans le code assembleur retire tout l’intérêt de la programmation en C sur microcontrôleur : seul un bon compilateur aux performances au moins égales à celles obtenues par la programmation manuelle en assembleur justifie l’utilisation d’un langage de haut niveau tel que le C. gcc génère un code tel qu’un humain l’écrirait naturellement (cette règle ne se généralise cependant pas lors de l’utilisation d’options d’optimisation qui peuvent amener gcc à générer du code performant mais illisible).

Une façon simple d’éliminer la dépendance du temps d’exécution de bouts de code critiques avec la version du compilateur ou les options d’optimisation est d’inclure dans le code C le bout d’assembleur qui a donné satisfaction, tel que proposé soit par l’option -S de gcc ou -dSt de objdump. Par exemple, pour inclure dans gcc le code assembleur issu de la compilation par Keil de la fonction delai() proposée ci-dessus, nous utiliserons l’assembleur de la façon suivante :

après avoir constaté que le passage de paramètres à la fonction se fait de la même façon pour les deux compilateurs.

Une étude plus exhaustive, et illustrant bien la complexité de l’analyse des benchmarks, est proposée à [10].

6. Un peu de calcul utile...

Afin d’illustrer le calcul sur des flottants et d’en estimer le coût en temps de calcul (et donc en consommation électrique), nous proposons de rechercher les racines d’une fonction complexe par la méthode de Newton.

Pour rappel, il s’agit d’une méthode itérative (Fig. 7) dans laquelle depuis une estimation grossière initiale de la position de la racine, l’algorithme recherche l’intersection de la tangente à la fonction avec l’axe des abscisses et itère le processus jusqu’à réduire l’erreur en dessous d’un seuil donné. La dérivée de la fonction f(z) au point z est f′(z) : la droite de pente f′(z) et passant par le point (z,f(z)) a pour équation y=f′(z)× (x−z)+f(z), qui intersecte l’axe des ordonnées y=0 en x=z−f(z)/f′(z). La recherche de racine se réduit donc à étudier la convergence de la suite zn+1=zn−f(zn)/f′(zn).

Cette méthode peut évidemment s’étendre aux fonctions complexes en prenant z∈ ℂ : dans ce cas, nous nous proposons non seulement de trouver les racines de la fonction complexe f, mais aussi de savoir vers quelle racine converge la suite et à quelle vitesse en fonction de la condition initiale choisie z0. Cette étude est à la base de la fractale dite « de Newton » : on démontre en effet que la frontière entre les bassins des diverses racines se ressemble à elle-même quel que soit le grossissement effectué sur cette zone. Nous allons illustrer ce concept à la fonction polynomiale f(z)=z3−1 avec z∈ ℂ. Les trois racines de ce polynôme sont trivialement ej2nπ/3, n=[0..2] et avec j2=−1.

La figure 8 présente graphiquement la racine vers laquelle converge la suite zn+1=zn−z3−1/3× z2, avec le rouge, le vert et le bleu présentant les 3 racines. Nous pouvons aussi calculer le nombre d’itérations nécessaires pour atteindre cette racine à une distance inférieure à 0,1 (carré du module <0,01).

Au-delà de son aspect esthétique, ce calcul démontre que l’ARM7TDMI est suffisamment performant pour implémenter une méthode itérative de recherche d’une solution (ici racine de polynôme, mais cette stratégie pourrait s’étendre aux descentes de gradients pour identifier des paramètres optimaux de fonctions s’ajustant à des données expérimentales, ou à la phase d’apprentissage d’un réseau de neurones artificiel) et dépasser le stade du simple système embarqué de type automate capable uniquement de réagir de façon simple à un stimulus.

Les temps d’exécution de 128×128 recherches de racines dans des intervalles commençant entre 2+2,5i et −3−2,5i et dont les bornes sont divisées par 2 à chaque itération pour zoomer vers l’origine sont résumés dans le tableau 5.

Nous constatons donc que le gain d’un facteur 10 en précision sur le résultat n’induit par une augmentation significative du temps de calcul, qui augmente de 10 à 20% selon les facteurs de grossissement. Tous ces calculs se sont fait sur 128×128 itérations. Nous en déduisons un temps moyen de calcul et, connaissant la puissance moyenne consommée par le microcontrôleur d’après la datasheet (40 mA sous 3,3 V, soit 132 mW), nous en déduisons l’énergie consommée par une itération moyenne vers une racine du polynôme. La valeur obtenue varie entre 140 et 440 µJ, dépendant du nombre d’itérations qu’il a fallu réaliser pour atteindre la précision voulue. Pour rappel, une masse de 10 g dans le champ gravitationnel terrestre (9,81 kg.m.s−2) acquiert une énergie potentielle de 980 µJ/cm qui, restituée sous forme de courant électrique par une dynamo avec un rendement de 10 % par exemple, se traduit par le fonctionnement du microcontrôleur pour une recherche de racine nécessitant une chute d’une bille de 10 g d’une hauteur de 5 mm environ.

7. Compression de données

La transmission de données communément utilisée sur systèmes embarqués se fait à bas débit : RS232, bluetooth, zigbee, radiomodems... La mise sous tension d’éléments gourmands en énergie – modem et processeur chargé de la communication tel que nous l’avons vu en section 4.4 – nous incite à réduire au mieux la quantité de données à transmettre.

Une stratégie pour minimiser la quantité d’informations transmise tient en l’optimisation du codage des données ou, en d’autres termes, la compression sans pertes des échantillons acquis.

Le compromis qui va nous intéresser est le compromis entre la consommation de ressources associées à la compression (mémoire occupée et temps de calcul) et la réduction du temps de communication. Le taux de compression étant dépendant de la nature des échantillons, nous ne prétendrons pas fournir une réponse définitive à cette question, mais simplement effleurer le sujet par une analyse statistique sur quelques échantillons de données représentatives d’informations que nous serions susceptibles de collecter.

Les implémentations « classiques » d’algorithmes de compression sans pertes performants (Huffman, Lempel-Ziv) telles que fournies par exemple dans libz ne sont pas appropriées pour une exploitation sur systèmes embarqués : leur exploitation de malloc handicape leurs performances sur systèmes sans unité de gestion de mémoire (MMU) et la compilation pour ARM7 de la version 1.2.3 de zlib génère un code prêt à flasher de 83 KB environ, soit plus que toute la mémoire flash disponible sur l’ADuC7026.

C. Sadler a développé, pour un projet de réseau de capteurs mobiles, un version allégée de la compression sans pertes pour microcontrôleurs MSP430 [12] : S-LZW est disponible à http://cmsadler.googlepages.com/slzw.tar.gz. Les ressources du processeur pour lequel ce code a été écrit étant à peu près identiques à celles de l’ADuC7026, cette bibliothèque de fonctions est un bon candidat pour nos tests.

La configuration par défaut de l’exemple fourni exploite un tableau (variable globale unsigned char* write_buffer) en entrée de 500 octets. La compression fournit un nouveau tableau de dimensions a priori inférieur : unsigned char *lzw_output_file_buffer. La subtilité majeure dans l’exploitation de ce code, comme l’a indiqué son auteur Christopher Sadler, est le passage d’une architecture 16 bits pour laquelle les programmes ont été écrits (MSP430) vers des architectures 32 bits (x86 pour test sur PC ou ARM7 qui va nous intéresser ici). Les corrections à apporter consistent à remplacer toutes les références aux int par des short et, dans slzw.c, définir last_entry comme un short signé au lieu de non signé (faute de quoi la décompression ne se fera pas).

Nous avons simulé des séquences de mesures de températures en convertissant les archives quotidiennes de Weather Undergroud (http://english.wunderground.com/) en valeurs hexadécimales sur 12 bits telles que les aurait mesuré l’ADuC7026 (Fig. 9). Dans tous les cas, le tableau d’entrée est rempli de 500 octets au total, soit de données seules codées sur 3 octets, soit de 3 octets suivis d’un retour chariot. Il apparaît clairement qu’en fonction des amplitudes des fluctuations annuelles de températures, le taux de compression peut être plus ou moins favorable (Fig. 9, droite). Dans les 3 exemples sélectionnés – Libreville sur l’équateur, Cayenne en Guyane, Montbéliard en France et le Svalbard dans le cercle arctique, nous avons constaté que l’efficacité de la compression décroît avec la latitude.

Ces résultats ne sont que partiellement satisfaisant, car sachant que seuls 12 bits (tailles des convertisseurs analogique-numérique) sont utiles sur les 3 octets (représentation ASCII de la valeur de la température), les 3 octets pourraient être codés de façon optimale sur 3 quartets et donc n’occuper que 250 octets au total : nous constatons que l’exploitation d’un algorithme de compression général tel que LZW n’est pas nécessairement optimum dans ce cas particulier, même si ici 2 applications (Libreville et Cayenne) fournissent un meilleur résultat par LZW que par concaténation des données. Nous avons démontré par ailleurs que des algorithmes plus simples que Lempel-Ziv – par exemple RLE – sont plus appropriés pour les applications fortement embarquées [13].

Étant donné que le tableau de sortie de la compression n’est pas le même que celui contenant les données en entrée, nous pouvons itérer plusieurs fois la phase de compression et de décompression afin d’estimer avec précision le temps de ces calculs. Nous constatons que le temps d’exécution d’une compression de 500 octets contenant des données représentatives des problèmes qui nous intéressent se situe entre 6,8 et 8,5 ms. Sachant que chaque octet transmis à 9600 bauds prend environ 1 ms, nous pouvons aisément estimer quand la compression est avantageuse ou coûteuse en énergie. L’énergie E consommée par l’ensemble des opérations est égale à la puissance requise par chaque opération (Ptransmission et Pcompression) multipliée par le temps que prend chacune de ces étapes (ttransmission et tcompression),

avec ttransmission d’autant plus petit que la compression est efficace. Notez que dans la plupart des cas, Ptransmission >> Pcompression, donc sous réserve d’une gestion efficace de l’énergie consommée par la liaison de communication (coupure des amplificateurs radiofréquences lorsqu’ils ne sont pas utilisés), la compression sera généralement utile compte tenu des débits de communication faibles généralement rencontrés (RS232, Zigbee, Bluetooth).

8. Exploitation de la PLA

Le cœur ARM7TDMI est exploité par de nombreux constructeurs, qui chacun l’agrémentent de périphériques répondant à leurs exigences. Dans le cas de l’ADuC7026, le périphérique le plus original, qui justifie le choix de ce processeur plutôt qu’un autre, est le Programmable Logic Array (PLA). Il s’agit d’un bout de logique reprogrammable de 16 blocs capables chacun d’appliquer n’importe quelle fonction logique de base, avec ou sans mémorisation sur une bascule en sortie de la porte logique, le tout cadencé avec une horloge capable de fonctionner aussi vite que le permet la PLL du processeur qui multiplie la fréquence du quartz horloger (41,78 MHz).

À notre connaissance, seul le logiciel gratuit mais propriétaire d’Analog Devices permet de configurer la PLA : il s’agit d’une interface graphique chargée de convertir un dessin de la séquence de portes logiques en un code C (ou assembleur) prêt à inclure dans un programme à destination de l’ADuC7026. La table de conversion entre fonction logique et liaison entre les différents blocs est documentée dans la datasheet de l’ADuC7026 (pp.72-74 de la révision B), mais est quasiment inutilisable en l’état : nous allons présenter comment exécuter le logiciel propriétaire d’Analog Devices nommé PLATool sous GNU/Linux (au moyen de Wine) :

1. Obtenir le logiciel gratuit de configuration de la PLA chez Analog Devices à http://www.analog.com/Analog_Root/static/technology/dataConverters/microConverter/PLATool_v2.2_setup.zip, désarchiver dans un répertoire au moyen de unzip.

2. Au moyen d’un Wine récent (nous avons utilisé la version wine-1.0-rc2, installer les outils .NET 1.1 de Microsoft disponibles depuis http://msdn.microsoft.com/en-us/netframework/default.aspx (obtenir le fichier dotnetfx.exe contenant le Microsoft .NET Framework Version 1.1 Redistributable Package)

3. Installer ces outils par wine dotnetfx.exe

4. Installer l’outil de Analog Devices par msiexec /i PLATool_V2.2_Setup.msi

5. Compléter les bibliothèques manquantes par winetricks gdiplus après avoir acquis le script winetricks par wget http://www.kegel.com/wine/winetricks

6. L’outil Analog Devices est désormais fonctionnel (Fig. 10) : l’utilisateur peut l’exécuter par wine ~/.wine/drive_c/Program\ Files/Analog\ Devices\ Inc/ADuC\ PLATool\ v2.2/PLATool.exe

La capacité à fournir l’horloge du processeur comme signal d’horloge des bascules de la PLA signifie que nous sommes capables de générer des signaux complexes cadencés à 41,78 MHz, ce qui serait impossible de façon logicielle, puisque chaque instruction prend plus d’un cycle d’horloge. Ainsi, l’intérêt d’une matrice de portes logiques aux côtés d’un processeur généraliste est la rapidité d’exécution de fonctions logiques simples de façon synchrone ou non avec l’horloge du processeur.

9. Réalisation d’un live-CD dédié à l’enseignement

Dans le cadre des travaux pratiques d’enseignement sur le thème « Systèmes embarqués », nous avons désiré fournir aux étudiants un live-CD [14] afin qu’ils puissent conserver les outils exploités en cours. Ce live-CD, disponible avec les archives associées à cet article sur http://jmfriedt.free.fr, possède un environnement graphique, les compilateurs nécessaires aux développements sur systèmes embarqués de consommation réduite (MSP430 et ARM7), ainsi que les éditeurs de texte et outils de traitement des donnés (Scite pour l’édition de texte, GNU/Octave pour le traitement de données). wine a été ajouté pour fournir un environnement libre de développement sur la PLA (section 8), ainsi que LATEX qui n’a finalement pas pu être utilisé.

Pour générer ce live-CD, nous avons utilisé l’outil développé par la distribution Debian live-helper, décrit en détail dans [14]. Pour résumer, nous avons réalisé trois modifications principales :

- ajout de nos toolchains en les copiant dans ./config/chroot_local-includes/usr/local/bin

- ajout d’un script permettant d’ajouter l’utilisateur aux groupeslp et dialout pour pouvoir utiliser le jtag sur port parallèle pour le MSP430, et le port série pour l’ADuC7026. Pour cela, nous créons le script dans ./config/chroot_local-includes/usr/share/initramfs-tools/scripts/live-bottom/90group-user et nous le rendons exécutable avec chmod +x ./config/chroot_local-includes/usr/share/initramfs-tools/scripts/live-bottom/90group-user

- ajout du fichier ./config/chroot_local-includes/etc/profile avec ajout dans ce fichier de l’exportation des variables d’environnement nécessaires (export PATH=$PATH:/usr/local/aduc/bin:/usr/local/cdk4msp/bin et export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cdk4msp/lib)

De plus, il s’agit de ne pas oublier dans la liste de paquets à installer dans le live-CD à l’aide de l’option --packages le méta-paquet build-essential pour avoir tous les outils nécessaires à la compilation.

Une subtilité que nous avons observée avec l’exploitation de live-CD comme support de travaux pratiques est l’incapacité d’exporter par NFS version 2 le système de fichiers AUFS utilisé sur le CD. Ce problème majeur – surtout dans le cas des développements sous uClinux sur plateformes de types ARM9 ou Coldfire – est contourné par la création d’un petit (≃10 MB) loopback device10 formaté en ext3 qui peut, lui, être exporté par NFS. Nous copierons donc les fichiers à exécuter sur le système embarqué dans le répertoire de montage de ce loopback device.

10. Conclusion

Nous avons présenté une chaîne de compilation pour architecture ARM, et l’avons appliquée spécifiquement à un ARM7TDMI implémenté par Analog Devices aux côtés de divers périphériques tels que convertisseurs numériques-analogiques et analogiques-numériques rapides et une matrice de portes logiques reconfigurables. Nous avons exploité les ports de communication pour interfacer des supports de stockage de masse compatibles avec une récupération des informations sur ordinateur personnel (format FAT), écran graphique et synthétiseur de signaux radiofréquence. Nous avons rapidement survolé quelques limites de la toolchain libre (implémentation lourde de stdlib, problème de gestion des interruptions) et estimé la puissance de calculs requise par quelques algorithmes moins triviaux de compression de données ou de recherche de racines de fonctions complexes.

Ces outils fournissent, avec la famille des ARM7, une série de processeurs puissants répondant probablement aux besoins de nombreux utilisateurs cherchant à automatiser des tâches répétitives en répondant aux exigences de dimensions réduites, consommation modeste et puissance de calcul importante.

Remerciements

Nous remercions Jonathan Bennès (CSEM, Neuchatel, Suisse) pour avoir acquis une carte d’évaluation d’ADuC7026 et nous avoir démontré la puissance de ce processeur pour les applications embarquées. Analog Devices a gracieusement fourni un certain nombre d’échantillons pour réaliser les cartes de développements exploitées dans cette présentation. Olivier Sterenberg a fourni le point de départ de la plupart des routines fournies comme exemples dans ce document en développant le code pour un CanSat (http://www.planete-sciences.org/espace/spip.php?rubrique24), projet dirigé dans la cadre de Planète Sciences par Emmanuel Jolly.

Références

[1] http://en.wikipedia.org/wiki/ARM_architecture propose un résumé des divers cœurs développés par ARM dans un contexte historique, ainsi que de nombreuses références.

[2] SEGARS (S.), CLARKE (K.) & GOUDGE (L.), « Embedded Control Problems, Thumb and the ARM7TDMI », IEEE Micro 15 (5) (1995), pp. 22-30, disponible à http://www.cooper.edu/~sable2/courses/spring2004/ee453/docs/embedded_ctrl_prblm.pdf, et la description commerciale du cœur à http://www.arm.com/products/CPUs/ARM7TDMI.html.

[3] MARTIN (T.), The insider’s guide to the Philips ARM7-based microcontrollers, Hitex (2005).

[4] BODOR (D.), « Passez votre iPod sous uClinux », GNU/Linux Magazine France n° 80, Février 2006, pp. 92-98.

[5] http://mindstorms.lego.com/Overview/The_NXT.aspx ou, plus sérieusement, http://bricxcc.sourceforge.net/nbc/

[6] http://martin.hinner.info/ARM-Microcontroller-HOWTO/ARM-Microcontroller-HOWTO.htm

[7] http://www.gnuarm.com/ArmDevices_frame.html

[8] BERNARD (E.), « Linux sur ARM : introduction, compilation et configuration », GNU/Linux Magazine France, Hors-série 25 (Avril/Mai 2006), pp. 20-33

[9] Embedded Systems Academy, ARM7 Performance : Comparisons & Benchmarks, transparents disponibles à www.esacademy.com (Mars 2007).

[10] Quelque discussions concernant les benchmarks de divers compilateurs pour ARM7TDMI : GOMES AUGUSTO (S.) & ORRY (L.), C Compilers for ARM: Benchmark, Raisonance (2006), disponible à http://www.mcu-raisonance.com/~str7-arm7tdmi-stmicroelectronics__microcontrollers__support~sfp__T016:4cnyx6krfmzf.html, et http://www.compuphase.com/dhrystone.htm

[11] GUINOT (S.), FRIEDT (J.-M), « Stockage de masse non volatile : un block device pour MultiMediaCard », GNU/Linux Magazine France, Hors-série 25 (Avril 2006), disponible à http://www.unixgarden.com/index.php/embarque/stockage-de-masse-non-volatile%C2%A0-un-block-device-pour-multimediacard

[12] SADLER (C.) et MARTONOSI (M.), « Data Compression Algorithms for Energy-Constrained Devices in Delay Tolerant Networks », Proceedings of the ACM Conference on Embedded Networked Sensor Systems (SenSys), Novembre 2006, disponible à http://parapet.ee.princeton.edu/papers/csadler-sensys2006.pdf

[13] PAMBA CAPO-CHICHI (E.), GUYENNET (H.), FRIEDT (J.-M), « K-RLE: A new Data Compression Algorithm for Wireless Sensor Network », SENSORCOMM 2009, Athènes/Vouliagmeni, Grèce (Juin 2009).

[14] BODOR (D.), « Créez votre live CD Debian 5.0 Lenny », GNU/Linux Magazine France 115, Avril 2009, pp. 28-32.

Notes

1 – ADUC7026BSTZ62, référence 1162646 chez Farnell pour 17 euros ou disponible pour 9,40 euros auprès de Avnet en septembre 2007.

2 – http://www.analog.com/en/prod/0,,762_0_ADUC7026,00.html

3 – Analog Devices EVAL-ADUC7026QSZ, disponible pour 91 euros chez Farnell.

4 – http://sca.uwaterloo.ca/coldfire/gcc-doc/docs/porting_3.html

5 – http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ADuC7026_blink_20060309b.zip

6 – http://cyclerecorder.org/aducloader/, version 0.1 à la date de rédaction de ce document

7 – http://www.keil.com/dd/chip/3694.htm

8 – http://wiki.osdev.org/Porting_Newlib

9 – http://www.sparkfun.com/Code/Nokia_LCD_driver.zip

10 – l’espace est créé par dd if=/dev/zero of=/home/espace.dd bs=512 count=2000 pour un espace de 10 MB, puis formaté par mkfs -t ext3 /home/espace.dd. Finalement, cet espace de travail est accessible dans le répertoire /home/espace par mount -o loop /home/espace.dd /home/espace en supposant que le répertoire /home/espace existe. L’ensemble de ces tâches est exécuté automatiquement au boot comme décrit dans [14].