Bonjour tout le monde,
Cela fait quelques mois que j'essaye de récolter des informations sur "comment développer une application embarquée sous Linux ?" De ce fait, j'ai lu énormément d'articles sur le sujet et jusqu'à présent, ça reste flou pour moi. Pour info, j'ai seulement travaillé 2 mois au cours d'un stage hors embarqué sur un PC équipé d'une distribution Ubuntu sur un projet d'imagerie médicale (ça remonte à 3 ans). En effet, Passionné de l'embarqué, je développe en langage C sur microcontroleur PIC et j’intègre dans mes applications des interfaces de communication industrielles comme CANopen, Modbus et un protocole maison. Cependant, je souhaiterai me lancer sur du TCP/IP (je pense bien maîtrisé théoriquement le modèle en couche puis quelques exemples de sources). Personnellement, j'ai envi de basculer sur le développement Linux embarqué par curiosité et dans le but de renforcer mes compétences. Voici quelques questions permettant de m’éclaircir les idées :
Un programme embarqué classique sans OS se démarre juste après la mise sous tension de la carte au main.c, alors comment ça se passe pour un OS embarqué ?
Si je dispose d'une application sans OS communiquant par liaison série, comment pourrais-je intégrer cette même application dans un OS embarqué ? L'accès aux GPIO (ports d'entrée/sortie) se ferra aussi simplement qu'avec sans OS (par exemple piloter une led) ?
Un programme C sur PIC est dit séquentiel, alors avec un OS, mon programme s'exécutera de quelle manière ?
Et la question au-quelle je n'arrête pas de me poser : qu'est ce qu'un OS embarqué peut apporter à une application ?
Je reconnais que mes questions sont assez vagues mais je pourrai surement les préciser suivant vos différentes réponses que j'attends avec impatience !!
Merci à vous.
Cordialement,
# relire les cours, et revoir les definitions
Posté par NeoX . Évalué à 4. Dernière modification le 06 janvier 2013 à 00:38.
un OS embarqué n'est rien d'autre que le programme qui se lance à la mise sous tension de la carte,
tout comme ton PC demarre le Bios et passe la main à ton linux ou ton windows.
ton appli devra etre lancé par l'OS mais necessitera probablement d'etre adaptée pour pouvoir communiquer avec le materiel au travers des modules du noyau (dans le cadre d'un linux embarqué par exemple)
si ton programme est sequentiel il restera sequentiel
l'abstraction du materiel, ainsi que ta carte reseau soit une carte intel, une carte broadcom, ou n'importe quel autre fabriquant, ton programme n'a plus qu'à
demander à l'OS "cause à la carte reseau, ouvre une communication"
c'est l'OS qui va ensuite parler à la carte reseau et se debrouiller avec le module de la carte pour lui passer les infos.
la portabilité de ton appli
plutot que de coder ton appli en langage machine directement, tu la code pour "android" par exemple
et elle fonctionnera probablement sur tous les android sans se soucier de savoir si c'est un simple coeur ou un quad-coeur
# quelques réponses bien incomplètes
Posté par totof2000 . Évalué à 4.
Tout dépend de l'OS .. :) Mais si on s'en tientà Linux, il faut savoir que lors du démarrage, le noyau Linux est lancé, puis ensuite le daemon init est lancé (je parle des systèmes classiques qui n'utilisent pas l'horreur nommée systemd - avec systemd c'est un peu différent). Celui-ci s'occupe de lancer tout le reste via un jeu de scripts et d'un fichier nommé /etc/inittab.
Si on a assez de RAM, on peut faire tourner une distribution "classique" (on trouve des distribs Debian par exemple pour des matos embarquésà base de CPU ARM), tout se fera plus ou moins comme sur un PC standard.
Si tu n'as pas assez de RAM pour faire tourner une distrib classique, même allégée, il te faudra personnaliser la chose. Tu peux choisir de toujours lancer le processus init, et de te créer une inittab personnalisée, et de n'embarquer dans ton système que les commandes et progammes qui te serviront. Sous Linux, un outil appelé BusyBox te permet d'intégrer un grand nombre de commandes standards que l'on trouve sous GNU/Linux tout en économisant beaucoup de place par rapport aux binaires classiques. Si tu es encore plus limité, tu peux développer ton code en C, et lancer ton exécutable à la place du process init (soit tu indiques à ton noyau de lancer un autre programme via le bootloader, soit tu peux faire un lien symbolique nommé /sbin/init vers ton prog perso, soit l'appeler carrément /sbin/init).
Pour communiquer avec une liaison série, tu ne pourras pas attaquer directement les registres de ta liaison série (enfin sur certaines archi, tu peux mais ça nécessite d'être un utilisateur privilégié, et surtout c'est sale). Il te faudra passer par un plote de périphériques. La liaison série étant standard, tu ne devrais pas avoir de mal à trouver la doc qui va bien pur le faire. Après tout dépend de ce que tu veux faire avec ta liaison série. Il te faudra donc redévelopper ton code pour ça. Par contre pour du matos plus spécifique il te faudra peut-être développer un driver. Mais si tu aimes le dev bas niveau, ça ne devrait pas te poser de problème.
Sinon, pour les GPIO, il existe un système de fichers vituels sous Linux appelé /proc dans lequel tu peux aller taper les GPIO. un truc du genre "echo 1 >/proc/gpio/" te positionnera une ligne à 1 et "echo 0 >/proc/gpio/" te positionnera une ligne à 0. Pour les lignespouvant être configurées en entrée ou en sortie, tu écris un 0 ou un 1 dans le bon fichier situé sous /profc/gpio Mais la façon précise de le faire dépend de l'archi et du driver. Il y a peut-être moen de faire autement ( IOCTL), mais il faut voir le driver de ton matos pour savoir.
Tout dépend cmment tu le programmes, et tout dépend de l'OS. Sous Linux :
- soit tu le développe en séquentiel, cependant il partagera son temps d'exécution avec au moins le noyau et les autres programmes qui pourraient tourner avec
- soit tu le programmes en évenementiel en le faisant réagir à des signaux, en créant des threads qui s'endormiront en attente d'un événement, et se réveilleront à l'arrivée de celui-ci. Tu peux faire ce que tu veux, et tu n'es pas limité à un seul processus ou 1 seul programme, tu peux en faire tourner plen en parallèle.
Un tas de code qu'il serait difficile de développer et maintenir si tout était à reprogrammer : par exemple, si tu te lances dans TCP/IP, l'OS te permettra de ne pas avoir à développer les pilotes de carte réseau, la couche TCP/IP et tout ce qui tourne autour. S tu changes d'interface, tu auras juste à changer de driver, et pas à redévelopper le tout. Et si tu installe un matos spécifique, tu n'auras qu'à redévelopper le driver spécifique à ton matos qui s'intègrera au reste. L'OS te permet de te concentrer sur ce que fait ton appli, et non sur toutes les couches sous-jacentes controlant le matériel.
Si le sujet Linux embarqué t'intéresse, je te conseille fortement le bouquin "Linux embarqué" de P. Ficheux chez Eyrolles. Tu y trouveras une réponse à toutes les questions que tu as posées, et même plus encore. Il est très ben fait, très pédagogique (même si certains passages sont un peu durs à comprendre mais bon, c'est le sujet qui est parfois difficile, et l'auteur a fait un travail remarquable pour se mettre au niveau des débutants). Tout le process de démarrage d'un système Linux y est détaillé. L'utilisation de Busybox également. Sinon, si je n'ai pas été très clair et que tu as d'autres questions, n'hésite pas.
# Réponses
Posté par Xaapyks . Évalué à 3.
Je vais essayer de répondre, sans répéter les commentaires précédents:
Si ton but c'est juste d'exécuter un unique programme, peut-être que les OS embarqués ne sont pas ce que tu cherches. Surtout au vu de ta dernière question. Mettre un OS embarqué doit se justifier, les couts de production sont énormes par rapport à du micro. Après, totof2000 a bien expliqué.
totof200 a juste, même si les noeuds sont /sys/class/gpio/gpioXX, c'est ça dans le principe. Pour tous les registres de sortie tu devras passer par une API du noyau, donc réécriture de toutes tes implems de protocoles.
Séquentiel aussi bien sur mais attention, sur micros tu dois déjà penser aux interruptions mais là tu vas devoir penser au scheduler du noyau, qui va donner le temps d'execution CPU à d'autres programmes après toi. Faire des protocoles à horloge peut être impossible à cause de ça. A moins de se tourner sur des OS temps réel.
Si tu ne vois pas l’intérêt j dirais que tu n'en as pas besoin. C'est utile quand ton programme a besoin de beaucoup d'environnement et bibliothèque "style" PC, ou que tu veux des gros frameworks qui tournent que sur des OS.
Ca peut aussi te permettre de "bénéficier" des API stables du noyau que tu vas utiliser (si les pilotes sont de bonne qualité…), ça fait toujours des couches physiques en moins à écrire à la main en micro.
# Autres systèmes
Posté par jmax17 . Évalué à -1.
Bonsoir,
L'OS te fournis un ensemble d'outils déjà existant, comme un petit serveur WEB, ou SSH.
il te fournit une pile réseau TCP/IP, gestion du protocole PPP pour la mise en place de MODEM etc …
Mais si ta carte dispose d'un petit processeur et d'une faible capacité mémoire les librairie eCos ou RTos me semblent un bon compromis :
ils fournissent une couche d'abstraction, des services HTTP, SSH, une pile réseau TCP PPP etc … gestion des ports USB.
mais avec ces systèmes du link ton application avec "l'OS" et tu n'as qu'un seul processus qui tourne.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.