Bonjour,
suite à la discussion dans cette
file, je vous livre un petit retour d'expérience sur le développement d'un produit électronique autour de linux. En me relisant, je me rends compte que la suite va faire un peu "spot publicitaire", je précise que ce n'est pas le but. Il est évident que beaucoup de choses que je décris ici peuvent être faites avec d'autres systèmes : windows CE, ou bien d'autres OS embarqués. Je ne les cites pas parce que je n'ai pas expérimenté, c'est tout. Je serais heureux d'entendre des retours d'expérience sur d'autres systèmes.
Le produit est un système de commande employé dans des bâtiments industriels ou tertiaires. Il se présente sous la forme d'une unité centrale qui pilote un réseau de capteurs et d'actionneurs sur un bus de terrain.
En guise d'introduction, voila un exemple d'une opération que j'ai effectué cette semaine, et que je n'aurais jamais imaginé pouvoir faire avant de travailler avec un linux embarqué. Notre système étant équipé d'un MODEM, j'ai pu me connecter par téléphone sur une de nos machines installée sur site (à 500 km de mon bureau). Dès lors je me retrouve dans la même configuration que lorsque je développe dans mon laboratoire via une liaison Ethernet. Je dispose d'un terminal (un peu comme une fenêtre DOS ou invite de commandes windows, pour ceux qui ne connaissent pas linux), via un protocole sécurisé bien sur (ssh pour les intimes). J'ai donc pu mettre mon programme à jour sans quitter mon bureau.
Rien d'extraordinaire pour un informaticien. Fabuleux pour le petit électronicien que je suis (j'étais ?).
Au niveau hard
nous avons utilisé une "carte processeur", c'est à dire une petite carte qui supporte le processeur, de la RAM, et de la flash. Plusieurs avantages : c'est livré tout installé, avec quelques exemples, et ça concentre tout ce qui est technique au niveau conception PCB (les BGA, le multicouche...). Evidemment, selon les volumes produits, on peut avoir intérêt à tout intégrer directement sur sa carte.
la carte que nous avons choisie :
PXA255 DIMM Module Pro du fabricant slovaque
voipac
En résumé :
- Processeur intel PXA255/400MHz (un ARM destiné à l'origine aux PDA)
- 32MB FLASH
- 64MB SDRAM
D'autres fabricants de ce type de cartes existent. Quand nous avons commencé en 2004, voipac était un des rares à livrer avec linux pré installé. Plusieurs fabricants affichaient un pingouin sur leur plaquette, mais quand on appelait le service technique : "Ah oui, linux, .... euh ... ça doit être possible de le faire tourner oui. Si vous y arrivez vous nous tiendrez au courant !
" Depuis de nombreux fabricants s'y sont mis. Notez qu'il y a aussi d'autres "form factor" : PC104, pc industriel en boitier, etc.
Voir des exemples
ici, ou encore, le champion du low-cost : un PC sans pièce mobile, en boitier pour 85 $ (à l'unité)
ici.
Si le choix devait être refait aujourd'hui, je prendrais un processeur x86, pour avoir un maximum de compatibilité avec les outils existants. Nous n'avons pas eu beaucoup de problèmes avec le ARM, mais un point nous a gêné : c'est l'absence de support de RTAI (cf paragraphe soft). De plus les avantages du ARM (moins de conso et un meilleur coût) ne sont pas décisifs pour notre projet.
Sur notre carte mère, nous avons rajouté autour de la carte processeur : un MAC Ethernet (Asix AX88796L), un transceiver RS485, un MODEM 56k (la aussi un module tout fait), une RTC sauvegardée (DS1335) et pour l'interface graphique, un codeur rotatif + une dalle TFT 640x480 (le contrôleur est intégré au processeur, je me contente de sortir un connecteur). La carte est 4 couches à cause du MAC.
Au niveau soft pourquoi utiliser linux ?
Dans notre cas, nous avions besoin : d'une interface graphique évoluée, de communications TCP/IP, de programmes de contrôle de MODEM, d'une batterie d'outils pour se connecter et diagnostiquer/déboguer à distance. Et bien sur d'un ordonnanceur pour que tout ce petit monde fonctionne en parallèle de notre application. Tout ça est déjà fait (et bien fait) dans linux. Il y a des tas d'autres raison : coût, diversité des applications disponibles, support de type communautaire (comme le forum futura, quoi
) qui me convient mieux (et fonctionne pas plus mal qu'un service technique dans l'expérience que j'ai eue). Enfin il y a la disponibilité des sources. C'est un argument classique des pro-open source, qui n'avait jamais retenu mon attention en tant qu'utilisateur de PC de bureau. Mais pour mon développement embarqué, j'en ai eu besoin à deux reprises. J'ai pu écrire un driver en modifiant des sources existantes, en moins de temps qu'il n'en faut pour le dire. Et j'ai pu comprendre le détail du fonctionnement d'une sous-partie du système qui nous posait problème à un moment donné (le port série).
les outils de développement
nous utilisons la aussi du logiciel libre.
compilateur : gcc. Pour ARM, un compilateur croisé (tourne sur PC mais produit des exe ARM) est disponible chez
gnuarm.
Nous utilisons un éditeur de texte et make pour gérer le processus de compilation. Pour les fans des IDE, il est possible d'utiliser Eclipse, Codeblocks, Kdevelop...
déboguage : gdb (pas à pas, points d'arrêts...). C'est un outil en ligne de commande. Il est possible de faire tourner gdbserver sur la cible, et gdb sur le PC de développement, le tout en liaison Ethernet. Nous l'utilisons très (très) peu. Notre code outillé avec quelques fonctions de report et log d'erreurs nous apporte un confort suffisant pour la mise au point.
les noyaux / librairies
- noyau que nous utilisons actuellement : 2.4.19. La nouvelle version de notre machine en cours de développement aura un 2.6.xx, qui devrait bénéficier d'un meilleur temps de réponse grâce à l'amélioration de l'ordonnanceur.
- nous utilisons la libc standard, la prochaine version aura uclibc optimisée pour les systèmes pauvres en ressources.
les drivers
c'est le point qui peut parfois bloquer, même si de gros progrès ont été faits. Dans notre cas, les drivers standards ont du être légèrement modifiés (par le fournisseur de la carte processeur) pour faire fonctionner le MAC Ethernet (AX88796L, qui est un clone de NE2000) et la RTC (DS1339). Il m'a fallu écrire un driver (simplissime) pour un codeur rotatif en quadrature qui nous sert d'interface utilisateur.
les distributions
Nous n'avons pas trouvé de distribution dédiée à l'embarqué satisfaisante. Dans la version actuelle du produit, il y a une distribution pré installée (apparemment basée sur une debian). Pour la prochaine version, nous avons monté notre système à partir de
BusyBox "le couteau suisse de linux embarqué". busybox compile la toolchain, le noyau, et les outils que l'on souhaite placer dans notre distribution "maison".
temps réel
Attention : avec un système de ce genre on a pas la même réactivité qu'avec un processeur programmé "directement" (sans OS). Actuellement avec notre noyau 2.4 on a un temps de réaction de 10 ms.
Si on a besoin de faire du "temps réel", il va falloir utiliser des outils appropriés. Selon les besoins, il existe des
patchs qui permettent d'augmenter la réactivité, ou de véritables OS temps-réel qui cohabitent avec linux :
RTAI ou
Xenomai. Attention, le support des ARM annoncé chez RTAI était de la publicité mensongère quand je m'y suis intéressé il y a environ un an
. Je n'ai pas regardé récemment.
conclusion : Je suis parti du niveau 0 sur linux. Quand j'ai commencé ce projet, j'avais installé linux sur mon PC perso 15 jours avant "pour voir". bien sur, il faut adapter ses ambitions à son niveau, c'est pourquoi j'ai commencé avec des systèmes "tout prêts", il n'était pas question au départ de jouer avec busybox ou RTAI. Mais c'est la preuve qu'il existe des solutions à la portée d'un électronicien...
Albums photos
Jeux d'arcade
Poursuivez votre recherche :
Aujourd'hui
Liens sponsorisés 
Re : retour d'expérience linux embarqué 
Mode linéaire
