Version imprimable
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
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.:yaisse2:
Cordialement
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é..Citation:
Envoyé par untipy
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...
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
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 ?
c'est à dire ... pour la mémoire lecture/écriture ok .... d'autres chosesCitation:
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.
bonne apres-midi
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!Citation:
Envoyé par untipy
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.
Oui. La tache de fond doit être non suspensive et avoir a priorité la plus faible.Citation:
Envoyé par untipy
Bonjour
La fenetre est bien temporelle, il faut donc le rafraichir ni trop tot, ni trop tardCitation:
Envoyé par untipy
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.Citation:
Envoyé par untipy
Quelques exemples.Citation:
Envoyé par untipy
- 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
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.Citation:
Envoyé par briand patrick
Bonne pratique, mais pas spécifique à l'embarqué.Citation:
[*]Toujours avoir un default dans un switch.
A moins qu'on connaisse précisément la profondeur max.Citation:
[*]Ne pas utiliser la récursivité
Bonne pratique, mais pas spécifique à l'embarqué.Citation:
[*]Ne jamais caster les pointeurs
8O Tant que le comportement est déterminé, je ne vois pas où est le problème.Citation:
[*]Ne pas faire d'opérations arithmétiques sur les pointeurs (on utilise juste ++ ou --).
Qu'appelles-tu "perturbations extérieures" ?Citation:
[*]Protéger les fonctions d'interruptions contre les perturbations extérieures
Bonjour emmanuel
les perturbations extérieurs sont généralement des parasites externes sur les entrées d'interruptions. Cela arrive par exemple quand ta carte electronique est soumise à un champs electromagnétique qui dépasse ce qu'elle est sensé supportée. Dans ce cas tu génère plein de fausse interruptions qui surcharge to CPU et qui risque de faire planter ton soft
L'execution de code dans la ram est juste autorisée pour les Bootloader ou la programmation de configuration dans la flash, autrement c'est très dangereux. ces modes de fonctionnement sont bien particuliers et très peu courant dans la vie du calculateur.
Je parlais de pointeurs de fonctions en RAM, il faut toujours les placer en flash. Je sais que certaines personnes optimise leurs code en aiguillant les traitements par des pointeurs de fonctions en RAM, mais c'est interdit dans le monde de l'embarqué. C'est une règle de robustesse.
Autrement, pour toutes les règles ou l'on pense maitriser la situation, le danger vient du faite que l'on maitrise les situations que l'on a imaginé, mais par logique pas celles que l'on n'a pas imaginées. C'est pour cela que dans le monde de l'embarqué, on s'interdit certaines choses même si elles sont tout à fait fonctionnelles, mais peuvent être dangereuse dans certains contextes ou dans la phase de maintance du logiciel.
je citait le MISRA dans mes post précédents. Les règles du MISRA ont été editées suite à un bétisier anglais sur des erreurs de programmations qui ont été découvertes parfois bien après la livraison du soft.
j'espère avoir répondu à tes remarques
Cordialement
Euh, si les règles de la CEM sont respectées (c'est obligatoire pour avoir le label CE), ça ne doit pas arriver...Citation:
Envoyé par briand patrick
Mais 2 précautions valent mieux qu'une, après tout, la CEM pourrait ne pas fonctionner suite à une mauvaise installation physique...
On pourrait aussi parler du cas de fonctionnement dégradé suite à une destruction partielle du boitier (équipements militaires...). Ca devient très spécialisé...
On est d'accord. Uniquement quand on ne peut pas faire autrement.Citation:
L'execution de code dans la ram est juste autorisée pour les Bootloader ou la programmation de configuration dans la flash, autrement c'est très dangereux. ces modes de fonctionnement sont bien particuliers et très peu courant dans la vie du calculateur.
Admettons. Tu veux dire que si les données débordent, elles peuvent casser du code... OK, sur des petites architectures sans MMU.Citation:
Je parlais de pointeurs de fonctions en RAM, il faut toujours les placer en flash. Je sais que certaines personnes optimise leurs code en aiguillant les traitements par des pointeurs de fonctions en RAM, mais c'est interdit dans le monde de l'embarqué. C'est une règle de robustesse.
C'est le problème général de la maitrise des comportements indéfinis. Ce n'est pas spécifique à l'embarqué.Citation:
Autrement, pour toutes les règles ou l'on pense maitriser la situation, le danger vient du faite que l'on maitrise les situations que l'on a imaginé, mais par logique pas celles que l'on n'a pas imaginées. C'est pour cela que dans le monde de l'embarqué, on s'interdit certaines choses même si elles sont tout à fait fonctionnelles, mais peuvent être dangereuse dans certains contextes ou dans la phase de maintance du logiciel.
Un grand merci pour l'ensemble de ces éléments
Il me renseigne bien !
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
Salut!
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.Citation:
-Question subsidiaire, quel est la différence entre une fonction définie par une macro et une fonction inline?
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 :ccool:
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é.
@+