il y a quoi dans une pile (stack)?

[cedric300]

Bonjour,

Je programme des pic 18F sous Mplab X
Je suis de formation électronique.
Jusqu’à aujourd'hui je croyais que la RAM était pour les variables, la ROM pour le programme et la pile pour savoir ou on est dans le programme.
Or j'ai eu un débordement de la pile, je me suis arraché les cheveux pour résoudre ce problème. Je suis à trois imbrications maximum de fonctions dans mon programme... et toujours le débordement.

Je me suis aperçu que lorsque je passais mes variables locales de mon main en global, la pile ne débordait plus...

Quelqu'un connaît-il un tutoriel ou une doc... qui peut m'expliquer ce qu'il y a précisément et simplement dans la pile?
Ai je résolus le problème du débordement de la pile en sortant mes variables? ou ai-je une nouvelle bombe à retardement?

Merci.
-----

[PA5CAL]

Bonjour

D'une manière générale, sans entrer dans les particularités des PIC 18F et de Mplab X que je n'utilise pas, l'espace mémoire correspondant à la RAM contient :
- éventuellement une zone de registres spécialisés du microcontrôleur (c'est le cas du PIC) ;
- une zone fixe de mémoire contenant les variables du système et les variables globales du programme,
- le tas (heap), qui est une zone de mémoire allouée dynamiquement par le programme (par exemple au travers de la fonction malloc() du C) ;
- la pile (stack), qui est une zone de mémoire occupée dynamiquement par le système, et qui contient les variables locales et les adresses de retour des sous-routines du programme et des routines d'interruption.

Lorsqu'on conçoit un programme pour micro-contrôleur, on doit évaluer la taille occupée par ces différentes zones en RAM afin de les positionner correctement par des options de compilation adéquates, de sorte que les deux dernières (tas et pile) ne débordent jamais sur les zones adjacentes au cours de l'exécution du programme.

[gienas]

Bonjour cedric300 et tout le groupe

... je croyais que la RAM était pour les variables, la ROM pour le programme et la pile pour savoir ou on est dans le programme ...

Enfin, ce n'est pas aussi "simple" que tu as l'air de le penser.

D'abord, RAM et pile, c'est dans la même mémoire, sauf que la pile n'est pas accédée par le même bout.

C'est toi qui fixes, au départ, la position de la pile, puis chaque empilage/dépilage, que tu gères toi-même, doit te ramener au même endroit au "repos" de ton programme.

La pile ne sait pas où tu es. Elle contient les adresses de retour successives quand des appels de fonction se terminent ou des interruptions sont appelées.

Les variables que tu places en RAM sont supposées définies par toi quant à leur position dans cette RAM.

Ton pointeur de pile étant initialement tout en haut de la pile, il peut, si tu utilises trop la pile, pointer de plus en plus bas et altérer tes variables.

... Je me suis aperçu que lorsque je passais mes variables locales de mon main en global, la pile ne débordait plus ...

Hum. Là, sur un µC, je comprends moins.

Les variables locales au main, sur un PC, seront bien en mémoire vive puisque tout est en mémoire vive, mais pas sûr que le mécanisme soit le même sur un µC, où le programme compilé sera en ROM. Es-tu bien sûr que tes variables sont ... variables? Ne serait-ce pas plutôt des constantes?

... Ai je résolus le problème du débordement de la pile en sortant mes variables? ou ai-je une nouvelle bombe à retardement? ...

Je me garderais bien de trancher. Tu es le seul à détenir les clefs de ton débordement.

[Jack]

Pour contourner le problème avec des µC qui ont une taille de pile riquiqui et éviter l'utilisation massive des variables globales, il est possible de déclarer les variables locales comme statiques. Elles seront ainsi "invisibles" depuis l'extérieur de la fonction et elles seront stocké dans l'espace mémoire des variables globales puisque leur valeur doit être conservée entre 2 appels à la fonction.

A+

[A voir en vidéo sur Futura]

[cedric300]

Merci pour cette réponse rapide.
Le tas est un nouveau mot pour moi!!
J'ai trouvé un lien wiki qui m'a fait comprendre certaine chose ( enfin je croie... )
http://fr.wikipedia.org/wiki/Allocation_de_m%C3%A9moire
Donc si j'ai compris quelque chose, on peut validé que le fait d'avoir retiré les variables local de mon main a corrigé mon problème de pile. (?) (corrigé et pas déplacé).

A+

[cedric300]

Désolé j'ai répondu sans avoir lu la réponse de Jack et gienas.

Pour répondre a gienas:
De ce que j'ai compris sur les pic la pile est fixé par microchip.
Et mes variables sont bien variable.
J'ai pris une habitude (je suis pas sur qu'elle soit bonne!) de mettre mes constantes en rom pour les chaînes et #define ou enum pour le reste.

A+

[PA5CAL]

Corrigé ou déplacé le problème, on ne sait pas.

En transformant tes variables locales en variables globales, tu as modifié (et fixé) leur emplacement. Mais la quantité de mémoire utilisée n'a pas changé, et si ton problème est lié à une taille de RAM insuffisante pour ton programme, alors rien n'est réglé.

Quoi qu'il en soit, il faut que tu évalues la taille maximale des différentes zones de mémoire que j'ai indiquées afin de déterminer :
- si l'adresse qui leur est affectée par défaut est correcte, ou bien doit être modifiée ;
- si ton programme ne consomma pas plus de RAM qu'il y en a de disponible.

[cedric300]

Aller un peut de bonne volonté et on me rassure.
Le débordement de pile est il corrigé?

A+

[Jack]

Microchip a sa manière de voir la pile. Pour des raisons d'optimisation, celle-ci n'était pas stockée en RAM mais dans des registres internes, peu nombreux, ce qui rendait la programmation en C un peu compliquée.

Pour les gros pic, le problème semble résolu.

Le débordement de pile est il corrigé?

Quand il n'y a plus de place, il n'y a plus de place !

Je ne connais pas bien les pics. Peut-être y a-t-il une interruption qui est lancée en cas de débordement.

A+

[cedric300]

Oui, une interruption qui redémarre le micro.

Sûrement j'ai rien compris, mais je me dit:
Qu'en passant les variables local en globale. je les passe de la pile a la RAM, donc la pile a moins de chose.
Quand je compte les octets de variable je suis bien en dessous de la RAM annoncé.
Mon raisonnement, est il absurde?

[PA5CAL]

Microchip a sa manière de voir la pile. Pour des raisons d'optimisation, celle-ci n'était pas stockée en RAM mais dans des registres internes, peu nombreux

Je viens de jeter un coup d'oeil à la datasheet d'un PIC18F, et il s'avère qu'en plus de la pile de données manipulée par des PUSH et des POP (adresse dans le registre FSR2), il existe une autre pile, de petite taille et stockée dans des registres, et réservée aux adresses de retour des fonctions et interruptions. Mais cette petite pile n'est pas concernée par les variables locale.

[PA5CAL]

Quand je compte les octets de variable je suis bien en dessous de la RAM annoncé.
Mon raisonnement, est il absurde?

Ce raisonnement est sujet à caution.

La pile et le tas se remplissent de manière dynamique, d'une manière qu'il n'est pas possible d'évaluer automatiquement et sans erreur de façon simple. L'espace occupé par les données dans ces zones durant l'exécution n'est pas donné dans les statistiques fournies à la compilation. Pour le connaître, il faut disposer d'un outil de diagnostic oeuvrant durant l'exécution (ou la simulation) du système, ou bien le calculer soi-même sur la base du fonctionnement attendu du programme.

[cedric300]

Mon calcul est fait en additionnant toute les variables du main + toutes les globales de touts les fichiers,
Pour les locale.
Dans ma fonction qui a le plus de variable j'ai un char[8][2] + 2 int + 1 char.
Les restes j'ai en moyenne 4 int.
J'utilise beaucoup les pointeurs.
+ Rien de nouveau dans ma routine d'interruption, je modifie un pointeur.

[RISC]

Salut Cedric,

Quelques remarques importantes sur les PIC18 :

1/ Les PIC18 ont une pile MATERIELLE de 32 niveaux...
Je n'ai jamais vu un seul programme excéder cela...même sur des application de 128Ko de FLASH

2/ Le compilateur C18 construit une pile LOGICIELLE en mémoire RAM pour tout ce qui est passage de paramêtres.
La taille de cette pile minimum est je crois de 256 octets mais peut être je pense étendue en modifiant le fichier LINKER (*.gld) voir le manuel du linker

3/ Il est possible avec la version à license du compilateur C18 de choisir le mode étendu qui ajoute 8 instructions aux PIC18 pour compresser le code et ajouter l'allocation et désallocation dynamique de la pile

En résumé, je suppose que tes problèmes n'ont absolument rien à voir avec un débordement de pile mais avec un problème de sauvegarde de contexte ou de passage de paramètres.

Utilise le CALL STACK dans MPLAB X pour voir l'emboitement des fonctions.

Si tu as un message d'erreur fait le voir. Cela peut donner des renseignements.

As-tu activé le Stack Overflow et Stack Underflow ?
As-tu écris un gestionnaire d'exceptions ?

a+

[azad]

Et puis aussi attention aux interruptions : surtout quand il s'en produit plusieurs... alors la pile n'est plus à l'heure. Combien j'en ai vu de ces RTE qui se prennent pour des RTS !!

[abracadabra75]

Bonjour.
Une question au ras des pâquerettes: Tu mets des objets sur la pile, très bien. Mais les enlèves-tu quand elles n'ont plus lieu d'être? Si tu ne le fais pas, sûr que ta pile débordera tôt ou tard.
A+

[Jack]

Tu mets des objets sur la pile, très bien. Mais les enlèves-tu quand elles n'ont plus lieu d'être?

Je ne comprends pas ta remarque: en principe, en C, on n'a pas à gérer la pile directement.

A+

[cedric300]

Bonjour,
Après réflexion sur vos messages, ce matin j'ai repris mes recherches dans mon programme et sur le net pour comprendre ce qui ne va pas dans mon programme.
Problème: il redémarre sans prévenir.
Coté hard je suis bon, suivant le programme que je lui met il plante ou non.
Si je sors les variables de mon main ça remarche correctement ( a premier vu ).
J'ai analysé le registre STKPTR (que j'aurai du le faire avant...) et !surprise! la valeur maximum que j'ai réussi a avoir dans StackPointer est 9.
Ce qui m'avais mis sur la piste de la pile est STVREN.
Je ne comprends pas comment fonctionne CALL STACK de Mplab X, je n'ai pour l'instant jamais eu de message d'erreur, mais en même temps je suis pas sur d'y comprendre comment fonction cette application

.


C'est quoi un gestionnaire d'exceptions?
Comment mettre en évidence tel ou tel autre problème?

Merci a tous le monde m'aider a comprendre le problème, et le fonctionnement du bazar mémoire des pic.