Discussion :

[mith06]

Bonjour,

Je développe actuellement en C une application embarquée sans OS. Celle-ci n'est pas "life critic" mais "$ critic" donc hors de question que ça plante.

Mon choix d’implémentation utilise les méthodes standard de la libC malloc et free. En discutant avec des gens qui ont autrefois codé de l'embarqué, ils m'ont annoncé que dans leur cas, l'utilisation de ces méthodes était proscrite pour des raisons de fiabilité. J'aimerais avoir votre avis là-dessus.

J'ajoute que pour le moment l'utilisation de malloc et free dans mon application de pose pas de problème. Les seules problèmes rencontrés étaient dues à une
une mauvaise utilisation de ces méthodes, donc au développeur, donc moi...

Merci.

[fregolo52]

Mon choix d’implémentation utilise les méthodes standard de la libC malloc et free. En discutant avec des gens qui ont autrefois codé de l'embarqué, ils m'ont annoncé que dans leur cas, l'utilisation de ces méthodes était proscrite pour des raisons de fiabilité. J'aimerais avoir votre avis là-dessus.

Je n'ai jamais fait d'embarqué pur, mais c'est ce que tout le monde dit : faire des allocations statiques et surtout pas dynamiques.
Fiabilité, je pense que ça veut dire aussi : éviter les fuites mémoire

[bpy1401]

Bonjour à tous

En effet, l'allocation dynamique de mémoire est prohibée dans le logiciel embarqué.
Le Misra (jeu de règles d'écriture à respecter dans l'embarqué) donne la règle suivante:

Rule 20.4 (mandatory) Dynamic heap memory allocation shall not be used

voici leur justification:

There is a whole range of unspecified, undefined and implementation-defined behaviour associated with
dynamic memory allocation, as well as a number of other potential pitfalls. Dynamic heap memory
allocation may lead to memory leaks, data inconsistency, memory exhaustion, non-deterministic
behaviour.

Il est possible que cela fonctionne bien pour le moment sur ton application, mais rien ne prouve qu'elle fonctionnera toujours bien.

Cette règle a été adopté pour les raisons suivantes:

• La taille de la RAM embarquée est limitées, son utilisation doit donc être parfaitement maitrisée. L'allocation dynamique n'est pas déterministe sur la taille de la RAM utilisée, donc dangereux
• L'allocation dynamique nécessite de la ram pour mémoriser les tables d'allocation, donc couteux en embarqué.
• les fuites mémoires sont aussi une cause de bug, car c'est la consommation RAM perdues jusqu'a plantage

Comme tu es dans une application critique, je pense que tu doit avoir des règles de codages à respecté. je serais surpris qu'il n'y en ai pas une qui t'interdise l'utilisation de l'allocation dynamique de mémoire.

En espérant avoir pu répondre à ta question.

[mith06]

Merci pour ta réponse.

J'utilise l'allocation dynamique uniquement dans un mecanisme de type FIFO pour faire du monitoring de données (sauvegarde des N dernières données en mémoire).

Ce mecanisme est actuellement très pratique pour le dev/debug de mon application donc je ne vais pas le supprimer. Par contre je pense le désactiver une fois l'application livrable, et laisser la possibilité de le réactiver pour raison de maintenance sur le terrain.

Est-ce que tu as un lien vers le document Misra que tu cites STP.

Merci.

[bpy1401]

Bonjour mith06

voici le lien
MISRA C 2004

Mais c'est payant

[ram-0000]

En général, ce qui se faisait avec du code embarqué, c'est:

• Au lancement/initialisation du programme, tu alloues des pools de blocs mémoire de différentes taille (suivant les besoins prévisibles)
• Quand tu as besoin d'un bloc, tu le demandes
• quand il n'y en a plus de disponible, soit tu peux t'en passer, soit l'application reboot, c'est que tu as mal dimensionné tes pools.

C'est un peu "barbare" mais c'est comme cela que fonctionnait "vrtx32"