Discussion :

[untipy]

Bonsoir

Je suis désolé cela fait longtemps que je n’ai pas posté … mon activé m’a temporairement éloigné du C et de l’informatique … mais de retour (yes)

Apres des recherches, notamment sur notre ami Google, je n’ai pas trouvé de tuto ou cours spécifiques complets. En effet, je recherche du C appliqué a l’embarqué (micro process) cad les précautions a prendre sur la gestion de la mémoire, watchdog, rappels … ect.
Etes-vous tombé sur un page, pdf…. de ce gout la ?

Voilou !
Merci d’avance

[bpy1401]

bonjour untipy

Je connais un guide de bonne manière qui s'appelle le MISRA. Le document n'est pas gratuit hélas, mias tu pourras déjà trouver quelques idées sur le site suivant

http://www.parasoft.com/jsp/products...bel=Misra-User

Cela ne concerne que le C embarqué, tu n'y trouveras pas d'informations sur la gestion des périphériques d'un micro controleur.

Pour tout ce qui est gestion de périphérique embarqué , c'est plus difficile à trouver sur le net. Peut être une bonne idée de tutoriel pour ce site.

Cordialement

[Emmanuel Delahaye]

Apres des recherches, je n’ai pas trouvé de tuto ou cours spécifiques complets. En effet, je recherche du C appliqué a l’embarqué (micro process) cad les précautions a prendre sur la gestion de la mémoire, watchdog, rappels … ect.

Bah, le C, c'est le C. Il n'y a pas vraiment de "C pour l'embarqué". Il n'y a pas plus ou moins de précautions à prendre que pour du C hébergé..

Après, il peut y a voir des contraintes liées à l'architecture, à la présence ou non d'un système, le compilateur utilisé, les bibliothèques disponibles etc. Tout cela est très spécialisé et ne peut être généralisé dans un livre...

Enfin, pour le watchdog, ça dépend de l'architecture matérielle. Si il effectivement, il est prévu une protection contre les boucles infinies par watchdog, il suffit d'appeler celui-ci dans la boucle de fond et, si nécessaire, dans les traitements que l'on sait être plus longs que la durée de watchdog... Tout cela n'est que le bons sens et ne nécessite pas de livre ou de site particulier...

[bpy1401]

Bonjour,

Travaillant dans le C embarqué depuis bien longtemps, je sais que la gestion du watchdog est toujours une problèmatique et dependant de l'architecture soft. Typiquement si on travaillle avec un OS ou bien plus simplement avec un séquenceur, le comportement n'est pas le même. Après on peut parler des watchdog simple ou à fenetre, faire de la supervision de tache , etc ....;

Pour le C, il existe bien des protections à prendre, surtout quand le logiciel embarqué doit être exécuté dans un environnement perturbé. Dans ce cas, il y a des protections à faire que l'on ne fait pas quand on fait un soft sur PC.

Si un organisme comme le MISRA a fait ces docs, cela signifie qu'l y avait un besoin derrière.


http://www.misra.org.uk/

Je l'accorde, les livres décrivant ceci est rare.

Cordialement

[untipy]

Bonjour

Tout d’abord merci pour vos réponses.

watchdog simple ou à fenetre … simple ok je connais mais a fenêtre ?? temporellement ??
Si l’on est sur un OS préemptif; on le met en tache de fond avec une faible priorité, c’est une bonne méthode ?

Pour le C, il existe bien des protections à prendre, surtout quand le logiciel embarqué doit être exécuté dans un environnement perturbé. Dans ce cas, il y a des protections à faire que l'on ne fait pas quand on fait un soft sur PC.

c'est à dire ... pour la mémoire lecture/écriture ok .... d'autres choses

bonne apres-midi

[homeostasie]

Si l’on est sur un OS préemptif; on le met en tache de fond avec une faible priorité, c’est une bonne méthode ?

Je dirais non car ca signifierait que si t'as une de tes tâches bloquées dans une boucle infini anormalement, alors tu remettrais tout de même à jour ton watchdog dans la tâche de fond. Ton watchdog ne servirait dans ce cas à rien sauf à déduire que ta tâche de fond est bloquée ou qu'elle obtient le processeur trop tard avant d'avoir pu remettre à jour ton watchdog!

Remarque: Le watchdog permet de resetter ton microcontroleur au bout d'un laps du temps que tu as préalablement fixé. Pour cela, tu dois le réinitialiser à certains endroits de ton code que tu juges adéquats afin d'éviter le reset. le reset doit avoir lieu si tu te retouves dans un état de type boucle infini.

[Emmanuel Delahaye]

Si l’on est sur un OS préemptif; on le met en tache de fond avec une faible priorité, c’est une bonne méthode ?

Oui. La tache de fond doit être non suspensive et avoir a priorité la plus faible.

[bpy1401]

Bonjour

watchdog simple ou à fenetre … simple ok je connais mais a fenêtre ?? temporellement ??

La fenetre est bien temporelle, il faut donc le rafraichir ni trop tot, ni trop tard

Si l’on est sur un OS préemptif; on le met en tache de fond avec une faible priorité, c’est une bonne méthode ?

Pour moi oui, car si tu es bloqué par une tache plus prioritaire, ta tache de fond ne s'exécute pas, et par conséquence, le watchdog ne sera pas rafraichi.

c'est à dire ... pour la mémoire lecture/écriture ok .... d'autres choses

Quelques exemples.

• Pas de pointeur de fonction en RAM
• Toujours avoir un default dans un switch.
• Ne pas utiliser la récursivité
• Ne jamais caster les pointeurs
• Ne pas faire d'opérations arithmétiques sur les pointeurs (on utilise juste ++ ou --).
• Protéger les fonctions d'interruptions contre les perturbations extérieures
• ...

bonne apres-midi

[Emmanuel Delahaye]

Quelques exemples.[*]Pas de pointeur de fonction en RAM

Bah, si la RAM est exécutable, pourquoi pas ? C'est d'ailleurs le seul moyen d'écrire en flash quand on a qu'une seule flash sur la carte.

[*]Toujours avoir un default dans un switch.

Bonne pratique, mais pas spécifique à l'embarqué.

[*]Ne pas utiliser la récursivité

A moins qu'on connaisse précisément la profondeur max.

[*]Ne jamais caster les pointeurs

Bonne pratique, mais pas spécifique à l'embarqué.

[*]Ne pas faire d'opérations arithmétiques sur les pointeurs (on utilise juste ++ ou --).

Tant que le comportement est déterminé, je ne vois pas où est le problème.

[*]Protéger les fonctions d'interruptions contre les perturbations extérieures

Qu'appelles-tu "perturbations extérieures" ?

[sgonzalez]

Bonjour,

je me suis intéréssé de près à ce thread : "http://www.developpez.net/forums/d488041/c-cpp/c/c-embarque/"

Je suis débutant en informatique embarquée mais je tiens depuis peu un poste dans ce dommaine.

Mon but est de développer un driver avec un file system pour une memoire de masse dans le domaine de l'aerospatial. ( la particularité de ce domaine est l'influence des SEU. Certains phenomènes physiques peuvent changer le contenu de la RAM ou du resultat d'une opperation du µC)

Cependant , j'ai quelques lacunes et quelques questions concernant le C embarqué en géneral.

-Dans le domaine de l'aerospatial , mon client demande que l'on respecte les regles MISRA C.

Est ce que l'utilisation des pointeurs de fonctions est interdite?

Dans le thread il est dit que le code est executé en FLASH et donc c'est pour cela que que les pointeurs de fonction sont déconseillés voire interdits. Mais il me semblait que le code était stoké en flash puis chargé en RAM pour pouvoir etre executé, donc je ne vois pas comment un pointeur de fonction peut etre stoké en flash.

-Question subsidiaire, quel est la différence entre une fonction définie par une macro et une fonction inline?

-Et pour finir , est ce qu'il existe une methode d'implémentation pour le développement de driver?

Je vous remercie par avance pour vos réponses qui me seront trés utiles.

Cordialement

[mith06]

Salut!

-Question subsidiaire, quel est la différence entre une fonction définie par une macro et une fonction inline?

Une macro est une instruction pré-processeur, cad qu'une macro va remplacer du texte par du texte. C'est dangereux, car tu peux générer du code bizarre sans t'en apercevoir.

Une méthode déclarée inline, indique au compilo que le programmeur souhaite que le contenue de la méthode inline soit directement intégré dans la méthode appelante. Cela permet de ne pas sauvegarder/faire un "branch"/restituer le contexte, comme cela serait le cas avec une méthode classique.
C'est donc aussi rapide qu'une macro (remplacement de texte par du texte), mais comme la syntaxe est la même qu'une méthode classique, il y a des vérifications de type qui sont effectuées à la compilation. C 'est également plus sure d’utilisation qu'une macro.

Personnellement je trouve ça génial

Bémol : les méthode inlines ne sont pas "inlinées" de base par le compilo, il faut mettre des options de compilation (exemple -O2).
Tu ne peux pas "inliner" une méthode récursive (normal...)
La taille de l’exécutable généré sera plus grande si les méthodes inline sont grosses.

Je me permets de te renvoyer à la doc (en Anglais...) de GCC concernant le mot clef inline http://gcc.gnu.org/onlinedocs/gcc/Inline.html

En espérant t'avoir aidé.
@+