Discussion :

[SamPirate62]

Bonjour,

Je suis actuellement de développer un programme en C sur microcontrôleur. Je suis en train d'intégrer du code que l'on m'a fournit et qui fait planter mon micro. Après quelques tests je remarque que:

- Ce code fonctionne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
typedef struct
{
       unsigned char Test_U8;
       unsigned short Test_U16;
}test_str;
 
test_str Test_STR;
test_str * PointeurTest_STR = &Test_STR;
 
PointeurTest_STR->Test_U8 = 0;
PointeurTest_STR->Test_U16 = 0;

- Ce code fait planter mon micro:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
typedef struct
{
     unsigned char Test_U8;
     unsigned short Test_U16;
}test_str;
 
test_str* Test_STR = malloc(sizeof(test_str));
 
Test_STR->Test_U8 = 0;
Test_STR->Test_U16 = 0;

A vrai dire je n'utilise jamais d'allocation dynamique de mémoire quand je programme sur microcontrôleur, et comme je programme que la dessus...je ne vois pas ce qui peut faire planter.

Sam,

[Matt_Houston]

Le programme plante-t-il sur l'appel lui-même ou sur l'une des lignes suivantes ? Ton MC permet-il malloc ? Vérifies-tu le résultat de l'allocation avant d'utiliser le bloc ?

Je ne fais pas d'embarqué, je peux donc taper à côté mais.. est-ce raisonnable de faire de l'allocation dynamique (fine) sur un MC ?

[SamPirate62]

Comme je le disais je ne fais jamais d'allocations dynamiques de mémoire sur microcontrôleur, mais là j’intègre une libraire que j'ai pas codé personnellement.

Je pense avoir trouvé le soucis, le résultat de l'allocation pointe un emplacement mémoire lié aux interruptions du micro. Je vais voir ça avec le fabricant. Je ne pense pas que ce soit le code en lui même.

En tout cas merci pour le coup de main.

EDIT : En fait il me retourne NULL...

[nnovic]

Hello,

Comme indiqué par Matt_Houston, la fonction 'malloc' n'est pas toujours supportée. Ou alors il faut des options de compilation bien précises pour l'avoir. Il faut que tu vérifies dans la documentation de ta chaine de compilation.

[SamPirate62]

OK je vais regarder ça.

Merci pour votre aide.

[Bktero]

Il est possible que malloc() soit disponible mais que ton tas (heap en anglais) soit de taille 0. Ainsi, toute demande d'allocation échouera. Il faut regarder le link script en général pour modifier la taille du tas.

[SamPirate62]

C'est effectivement le heap, je venais juste de trouver l'info.

Merci,

[Vincent PETIT]

Salut,
Même en modifiant les options de ton compilateur afin qu'il initialise la pile plus loin pour laisser un tas acceptable, c'est galère comme solution et ça l'est d'autant plus si tu n'as pas le contrôle sur le nombre d'appel à malloc.
En réduisant la pile, tu limites la profondeur d'appel des fonctions et le nombres de variables locales sans être sur que la tas sera suffisant. A moins d'avoir un gros ARM avec largement trop de mémoire bien-sur.

Moi non plus je n'utilise jamais de malloc sur un microcontrôleur mais je n'ai jamais rencontré une application qui le nécessitait.

Tu ne peux pas jouer la sécurité comme avec ton tout premier exemple ? Qu'est ce qui t'oblige a allouer des structures de manière dynamique ?

[SamPirate62]

Bonjour,

J’intègre une librairie mathématique qui a été développé par quelqu'un d'autre. Donc à vrai dire la nécessité des allocations dynamiques je ne la connais pas trop. La personne va supprimer les allocations dynamiques pour utiliser des VLA.

J'essayais surtout comprendre pourquoi mon MCU plantait, mais j'ai la réponse.

[Bktero]

Je ne vois pas pourquoi tu devrais réduire la pile pour agrandir le tas ? Sauf si tu fais en sorte que la pile fasse toute la mémoire restante une fois les globales et statiques allouées...

Je ne pense pas du tout que les VLA soient une meilleure solution. Tu peux contrôler si malloc() échoue car la fonction renvoie NULL dans ce cas ; un VLA "trop grand" va faire un stack overflow IMO.

[SamPirate62]

Je n'ai pas agrandi le tas, il était carrément à 0 par défaut.

Par contre je te rejoins sur ta dernière remarque. Je vais regarder ça.

[Vincent PETIT]

Je ne vois pas pourquoi tu devrais réduire la pile pour agrandir le tas ?

En effet j'ai parlé trop vite car ça dépend de l'architecture....par contre lorsque tu dis :

Sauf si tu fais en sorte que la pile fasse toute la mémoire restante une fois les globales et statiques allouées...

Je me demande si ce n'est pas ce qui est fait par défaut sur certaine architecture.

Chez Atmel, le ATMEGA328P de Arduino UNO par exemple, on a une architecture Harvard (mémoire programme et mémoire données sur deux bus différents) et chez Texas MSP30 on a une architecture Von Neumann avec tout dans le même emplacement mémoire (le même bus) mais dans les deux cas on retrouve dans la RAM les registres, le tas et la pile.

Donc pour moi, si on augmente le tas c'est forcément qu'on diminue la pile ? Non ?
A moins que le compilateur alloue une pile d'une certaine taille configurable, le tas est calculé lors de la compilation et le reste de la mémoire est laissé en l'état pour d'éventuelles allocation ?

Quelqu'un a déjà vérifier ça ? Moi je pensais que par défaut la pile occupait tout le reste de mémoire libre.



Par contre chez Microchip PIC18, on a aussi une architecture Harvard (mémoire programme et mémoire données séparées) mais avec une pile matérielle qui est aussi séparée et dont la profondeur est limitée. Dans ce cas de figure évidemment si on change la taille du tas, ça n'influe en rien la pile puisqu'elle est inaccessible.

[nnovic]

En règle général, la pile ne sert que pour l'allocation dynamique. C'est pour cela que, si on ne fait pas de malloc, on peut très bien se passer de la pile.

Autrement, les variables sont positionnées dans la RAM, en dehors des zones réservées (heap et stack), à une adresse fixée par le linker. C'est vrai en particulier pour les variables globales; les variables locales, en fonction des optimisations du compilateur, peuvent être placées ailleurs (voire même "disparaitre" si le compilateur peut utiliser directement les registres du MCU et se passer de la RAM).

Du coup, en fait, par défaut il n'y a pas de pile.

[Vincent PETIT]

En règle général, la pile ne sert que pour l'allocation dynamique. C'est pour cela que, si on ne fait pas de malloc, on peut très bien se passer de la pile.

Mais c'est obligatoire au moins pour les appels de fonctions ?
A chaque appel de fonction, le compteur programme ainsi que les variables qui se trouvent dans les registres de travailles sont empilés puis une fois la fonction exécutée, tout est dépilé (compteur programme + variables) pour que ça reprenne son cours ?

[ternel]

euh, c'est même clairement le contraire, malloc permet d'accéder au tas. Si on ne fait aucun malloc, c'est le tas dont on peut se passer, pas la pile.

la pile est l'âme de l'exécution.

[nnovic]

euh, c'est même clairement le contraire, malloc permet d'accéder au tas. Si on ne fait aucun malloc, c'est le tas dont on peut se passer, pas la pile.

la pile est l'âme de l'exécution.

Oulà, au temps pour moi, je me suis emmêlé les pinceaux !