1 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é ?
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).
2 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) ?
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.
3 Un programme C sur PIC est dit séquentiel, alors avec un OS, mon programme s'exécutera de quelle manière ?
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.
4 Et la question au-quelle je n'arrête pas de me poser : qu'est ce qu'un OS embarqué peut apporter à une application ?
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.
# quelques réponses bien incomplètes
Posté par totof2000 . En réponse au message Débuté sous Linux embarqué. É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.