Bonjour!!
 
Je suis en train de rédiger mon mémoire de stage, et je dois faire une partie sur la methode générale de création de logiciels embarqué.
 
J'ai cherché sur google, et je n'ai pas trouver de lien avec une "charte"...
 
Auriez vous une idée donc des etapes à suivre pour créer un logiciel embarqué???
 
Merci!!
 
barucca

bah c'est la même méthode pour tous les logiciels hein, réspecter les contrainte
sauf que là les contraintes sont plus fortes c'est tout

oki, donc en fait, rien de special mis a part des contraintes sur la taille du logiciel, le temps d'execution etc..?

la contrainte temps réel j'imagine non?

oui aussi effectivement...

 
en pratique ca veut dire quoi ?

en pratique ça veut dire:
developpement selon les contraintes temps réel

ah, coule, merci

Ca veut simplement dire que tu dois t'assurer que ton soft réponde à un évènement dans un délai court et prédéfini, quelque soit son etat et sa charge de travail.
("répondre" signifie ici que tu as un certain délai pour finir le traitement de l'évènement et pas plus).
 
Bons cas :
instant t : évènement
instant t+x : traitement évènement
instant t+y : fin traitement
instant t+z : fin de la période de traitement autorisé
 
mauvais cas :
instant t : évènement
instant t+x : traitement évènement
instant t+z : fin de la période de traitement autorisé
instant t+y : fin traitement

et si par malheur ton traitement est trop gros pour entré dans l'interval (t;t+z) tu fais comment ?

plus le principe de préemption des tâches les unes par rapport aux autres (priorité toussa)

si ça dépasse: watchdog
si ton système n'est pas capable de faire le travail dans le temps imparti, c'est que soit tu t'es gourré, soit un problème imprévu est survenu...
quoiqu'il en soit, prévoir une sortie d'urgence propre et secure

oué, mais question idiote, ca peut aussi dependre d'auter chose, genre une entrée E/S ? ou c'est vraiment reservé qu'a de tout petit truc ?

 
Si par malheur le traitement est trop gros ... douloureux souvenir.
Sur un OS temps reel, ton prog est flingué direct.
 
Sur un OS non temps reel, bein rien ne se passe.... tu ne fais pas du temps reel, c'est tout, puisque tu ne peux assurer que le traitement sera finit en un temps précis fixe.

bah le problème c'est que souvent ça concerne des trucs hyper critiques (aide au pilotage par ex.)
le moindre événement "imprévu", doit immédiatement renvoyer le système dans un état de secours
mais ça peut être n'importe quoi
une mesure invalide, une panne, une explosion nucléaire...

ca a l'air marrant comme tout dites donc

t'es obligé de passer par là pour certaines choses
imagine un peu les métros automatiques genre VAL fonctionner un moment sans ce genre de considérations...

ben c'etait pas ironique hein?

J'avais cru en voyant ton premier post, mais j'ai bien senti la nuance ensuite
Tu devrais essayer... ya des outils sympas genre vxworks

 
oué, tu sais que je suis en rech. d'emploi, l'embarqué reviens regulierement mais vu que j'ai 0 xp ...
 
c'est quoi exactement vx ? un emu de tps reel ? on peut dl une demo ou chaipakoi ?

gratuit je ne crois pas... faut voir pour une version démo...
j'ai une grosse doc là dessus, mais c'est en version papier

Un truc au passage : le terme temps-reel est utilisé pour désigner plein de choses différentes.
 
donc en cherchant de la doc, tu vas forcément tomber sur pleins de définitions différentes.
 
Tout ce que je peux affirmer sans risque de me planter c'est :
sur un OS temps-reel, tu peux t'assurer que ta fonction qui gère un évènement ne sera pas interrompue en plein milieu (ce qui n'est pas le cas dans un OS préemptif comme Win ou Linux). Donc tu peux t'assurer que ta fonction se terminera bien dans un délai fixe.
 
ex : une bete boucle
int j=0;
for(int i=0;i<16;i++) { j++; }
 va s'éxécuter en temps fixe, fini et mesurable. C'est du temps-reel. Si tu prends le chiffre 16 en argument ailleurs, ce n'en est plus forcément.
 
Les OS temps reels sont utilisés dans beaucoup d'applications aeronautiques, ferrovières etcetc...
 
Au passage, Linux peut etre rendu temps-reel moyennant quelques extensions (je ne me souviens plus les noms). Windows ne l'est pas (meme sous Win2000, une tache en priorité critique sera interrompue et ne respectera pas les contraintes temps-reel)
Doit y avoir de la doc sur le net à ce sujet.

je développais sur un calculateur embarqué avec un OS temps réel mais je ne me rappelle plus le nom c'est con

y a QNX comme OS temps-réel connu

Les conventions de codage sont importantes.
Comme conventions spécifiques au domaine de l'embarqué, il existe entre autres le Firmware Standards Manual (disponible ici) et les recommandations MISRA (pour l'automobile).
 
Les principales contraintes, comme cela a été dit, concernent l'occupation mémoire (ROM/RAM) et le déterminisme (temps réel).
 
Concernant la méthodologie: il faut garder à l'esprit qu'on ne développe pas un logiciel embarqué, mais un système embarqué (donc un produit); le logiciel n'en est qu'un composant (certes essentiel). Par conséquent, la contrainte matérielle est omniprésente.
 
Et, au risque de me faire flammer, je dirais que la qualité du code est prépondérante et probablement plus importante que pour d'autres logiciels. Non pas que les développeurs embarqués soient meilleurs ou moins fainéants que les autres bien sûr (d'ailleurs, bien souvent, un code d'électronicien est dégueulasse), mais cela vient du fait que certains produits ne peuvent plus être corrigés après avoir été mis sur le marché (on peut toujours corriger les séries suivantes, ou proposer une mise à jour de la FLASH pour certains produits, mais ce n'est pas tout le temps le cas).

 
VxWorks, OS temps réel commercial pour applications embarquées, avec environnement de développement. L'un des plus utilisés.

 
RT-Linux, je crois. Je ne sais pas si ça fonctionne.

 
... en 32 bits
Plutôt utilisé pour les applications "sérieuses" (industrielles, automobile, aviation, etc.). Pour les applications multimédia/télécom, Windows CE est en progression. Et pour les applications critiques, généralement ce sont les noyaux de GHS.
 
Sinon, outre Linux (qui n'est pas un véritable noyau temps-réel), il y a eCos qui est libre \o/

Ya aussi RTEMS qui est libre.  
 
Sinon, il y a RTAI qui une version de linux temps réel (RT-linux est payant)
 
La grosse différence est le fait que la plateforme de dev n'est pas la cible du dev. IL faut donc travail avec des moniteur/émulateur/crosscompilo et autre saleté bien chiante...
 
Je crois que eclipse tant à dominer le marché de l'IDE pour embarqué.

 
Heu... nan
 
Sinon, dans l'embarqué on a toujours travaillé avec des cibles différentes de l'hôte et je ne vois vraiment pas pourquoi ça poserait le moindre problème

Barucca, je te conseille d'aller voir sur le site Embedded Touch, tu devrait trouver les infos qui t'intéressent : http://www.embeddedtouch.com
 
Ils ont publié un article sur Eclipse : http://www.embeddedtouch.com/et/client/0501276225.php

Je débarque peut etre mais il ne semble pas qu'il a été fait allusion à la différence entre temps réel dur et temps réel soft.
La différence se tient -en gros- dans la gestion du dépassement de l'échéance (le temps réel soft est tolérant au dépassement, dans le cadre du temps réel dur, le dépassement peut etre catastrophique).
Niveau langage, c'est la robustesse qui prime : Ada (qui gère le temps réel et la concurrence nativement), C/Posix 1b (anciennement Posix 4)...
Comme bons bouquins il y a "Introduction aux systèmes temps réel", "Real-Time Systems and Programming Languages" dont il y a une critique là : http://linuxfr.org/2001/03/12/2712.html