Gestion de la mémoire dynamique.

Bonjour les copains, Depuis quelques temps je me "cogne" à la gestion de la mémoire par l'ATmega328. En particulier je cherche à comprendre la façon dont le compilateur gère les différentes données, qu'elles soient statiques ou dynamiques. J'ai lu, relu, cherché une foule d'informations sur Internet, mais l'os à ronger est un peu dur dur pour moi. :) Naturellement pour chercher à comprendre je soumets au compilateur divers petits programmes. En particulier, l’un d’eux effectue le listage sur la ligne série des zones mémoires caractéristiques. Il contient l’instruction :

SRAM_LIBRE = (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);

Je crois avoir compris que dans cette instruction certains identificateurs de pointeurs sont des « mots réservés ». Par contre j’ai beaucoup de mal à cerner ce que fait exactement cette instruction. Pouvez-vous s’il vous plait me faire une interprétation MOT A MOT de cette instruction, ce qui me permettra de pousser plus avant mes recherches sur la gestion dynamique de la SRAM.

La fonction complète est:

int freeRAM() 
{ 
   extern int __heap_start, *__brkval; 
   int v; 
   return (int) &v - (__brkval == 0 ? (int) &__heap_start: (int) __brkval); 
}

? : opérateur ternaire d'affectation conditionnelle: resultat = condition ? retourné_si_condition_vrai : retourné_si_condition_fausse;

Allocation de la mémoire et définition des variables Détail ici

 (__brkval == 0 ? (int) &__heap_start: (int) __brkval)

si (brkval == 0) alors la fin du heap = __heap_start; sinon la fin du heap = brkval;

Comme v est la dernière variable allouée elle représente le haut de la pile __brkval (ou heap_start) représente la dernière adresse sur le heap La différence entre les 2 donne la RAM disponible.

Bonjour les copains,
Merci pour ta réponse fdufnews
Je vais analyser tout ça point par point.
Pour ce qui est du lien, j’y ai déjà galéré pas mal, mais vu que c’est en Anglais je suis loin de tout comprendre.
En particulier, quand je pousse les expérimentations, la SRAM semble talonner à la valeur de 08FF où commence la PILE. Mais sauf erreur de ma part 08FF traduit en décimal donne 2303. Hors la SRAM fait 2Ko donc devrait s’arrêter à 0800. Je rencontre ainsi une contradiction.
Je suis donc confronté à plusieurs questionnements, mais j’avance lentement. Faut dire que la gestion mémoire et les pointeurs, c’est assez indigeste. :blush:
Pour le point d’interrogation, je ne comprenais pas du tout sa signification. Bon il me faut vois ce que tu entends par opérateur ternaire. J’imagine que c’est un « triplon » d’un opérateur de comparaison, mais quand j’ai cherché dans les références de syntaxe, je ne l’ai pas trouvé.
Bon, j’ai du grain à moudre, je vais pousser plus avant mes études à lisant en détail et en décortiquant entièrement ta réponse.
Merci encore.

P.S.
Juste une petite précision :
Dans ce code spécifique, on utilise des identificateurs particuliers qui commencent par des “__”.
Je suppose que ce sont les mots réservés pour des pointeurs spécialisés.
Peux-tu s’il te plait confirmer ou infirmer mon hypothèse ?

nulentout: En particulier, quand je pousse les expérimentations, la SRAM semble talonner à la valeur de 08FF où commence la PILE. Mais sauf erreur de ma part 08FF traduit en décimal donne 2303. Hors la SRAM fait 2Ko donc devrait s’arrêter à 0800. Je rencontre ainsi une contradiction.

Faut lire les doc. La RAM commence en 0x100 et elle fait 2048 octet soit 0x7FF donc 0x100 + 0x7FF = 0x8FF En dessous de l'adresse 0x100 c'est les registres internes.

nulentout: Dans ce code spécifique, on utilise des identificateurs particuliers qui commencent par des "__". Je suppose que ce sont les mots réservés pour des pointeurs spécialisés. Peux-tu s'il te plait confirmer ou infirmer mon hypothèse ?

Variables utilisées par le "noyau" C.

Faut lire les doc.

Ben ... tu n'imagines pas le nombre de liens que j'ai consulté sur le sujet. Pas forcément les bons, je te l'accorde. Ceci dit, ton rappel à l'ordre public est un peu "raide" je trouve. N'oublies pas que j'ai 66 ans, donc pas forcément l'aisance d'esprit des jeunes qui sont en pleine possession de leurs moyens. Par ailleurs, j’en suis à mon 22 ième µP. Tous ont des spécificités. J’ai tendance à mélanger un peu. Je suis donc tombé dans le piège qui consistait à imaginer que « la page zéro » était réservée aux variables fondamentales. Sur beaucoup de µP les vecteurs et les registres du µP sont dans le haut de la mémoire, pas en page zéro. Sur ce point, je plaide « non coupable ». :grin: :blush: Quoi qu’il en soit merci, ton information m’est précieuse, car je vais pouvoir préciser certains points dans ma documentation personnelle. Amicalement : Nulentout.

nulentout: Ben ... tu n'imagines pas le nombre de liens que j'ai consulté sur le sujet. Pas forcément les bons, je te l'accorde.

Trop d'info tue l'info.

C'est dans la datasheet de l'ATmega que j'ai trouvé ça. C'est le premier doc que je prends quand je cherche une info. Google c'est seulement si je ne trouve pas dans les doc constructeur..

fdufnews:

nulentout:
Ben … tu n’imagines pas le nombre de liens que j’ai consulté sur le sujet. Pas forcément les bons, je te l’accorde.

Trop d’info tue l’info.

C’est dans la datasheet de l’ATmega que j’ai trouvé ça.
C’est le premier doc que je prends quand je cherche une info. Google c’est seulement si je ne trouve pas dans les doc constructeur…

Et j’abonde (sur le principe :grin: )
Quel que soit le compo, du plus insignifiant au plus consequent , la base est le datasheet , c’est meme un “outil” prealable aux redactions de contrats .

@nulentout

  • La langue pivot quasi encore souvent admise est (encore) l’anglais, les autres derivés ne sont que “des traductions” susceptibles d’imperfections de traductions.

De plus en plus , des datasheets de compos “asia” n’existe/ne sont dispo qu’en “chinois/mandarin” , l’expression ancienne “ça c’est du chinois pour moi” est de plus en plus pregnante. :grin:

Mais finalement consulter un DS en anglais ou en mandarin , ne changera pas les lois de la physique , il ne s’agit que d’une adaptation du lecteur au medium. :grin:

Pour prendre un peu sa défense il a clairement expliqué qu'il n'était pas à l'aise avec l'anglais. Donc la datasheet c'est pas un support qui lui est adapté.

Concernant les notices constructeur du Google trad fera le plus souvent l'affaire, surtout si as de très bonnes bases techniques ;). Allez bon courage dans ta quête nulentout. ( au passage, c'est triste comme pseudo)

derder9161:
Pour prendre un peu sa défense il a clairement expliqué qu’il n’était pas à l’aise avec l’anglais.
Donc la datasheet c’est pas un support qui lui est adapté.

Concernant les notices constructeur du Google trad fera le plus souvent l’affaire, surtout si as de très bonnes bases techniques ;).
Allez bon courage dans ta quête nulentout. ( au passage, c’est triste comme pseudo)

et pour te prendre à contrepied :grin:
J’adore la langue française, et j’en suis un defenseur et propagateur :grin:
mais dans la vie, il faut aussi etre pragmatique
là et ici , nous discutons de composants electroniques
la base de discussion/reflexion (le juge de paix) est toujours le datasheet dispo (ou pas :grin: )sur le site de son “proprio” à l’instant T.

la resolution est simple pour tous et tout un chacun , et ce quelle que soit la langue de redaction
Sois tu sais le lire … ou pas :grin:

Je suis entièrement d'accord avec toi. Dans ce domaine l'anglais est primordial. Mais tu peux pas dire cela à une personne de 66 ans qui a finis sa carrière depuis quelques années. Encore tu dirais "vas lire la datasheet" a des personnes comme le phénomène qu'il y a eu dernièrement sur le forum. (On se comprend ;) ) je comprendrai . Mais je me suis sentis obliger de prendre un peu sa défense . Car je trouve que le post a une démarche irréprochable auquel on ne peut se permettre de répondre ---> datasheet

Je ne veux pas lance de débat hein ^^ moi j'aime tout le monde !!!!! 8)

derder9161: Je suis entièrement d'accord avec toi. Dans ce domaine l'anglais est primordial. Mais tu peux pas dire cela à une personne de 66 ans qui a finis sa carrière depuis quelques années. ...

bof ! :grin: Je pense que fdufnews et moi meme sommes plus proche de l'age de nulentout que du tien. Mais l'adaptation n'est pas qu'une question d'age :grin:

Je pense que fdufnews et moi meme sommes plus proche de l'age de nulentout que du tien.

Oui c'est sur :P et c'est d'autant plus affolant de voir comment les générations se sert les coudes ...

Donc très bien, ta prochaine réponse a nulentout sera : "mets toi a l'anglais" ... Bonjour l'entraide

derder9161:

Je pense que fdufnews et moi meme sommes plus proche de l'age de nulentout que du tien.

Oui c'est sur :P et c'est d'autant plus affolant de voir comment les générations se sert les coudes ...

Cit : "Le temps ne fait rien à l'affaire" :grin:

derder9161:

Je pense que fdufnews et moi meme sommes plus proche de l'age de nulentout que du tien.

Oui c'est sur :P et c'est d'autant plus affolant de voir comment les générations se sert les coudes ...

Donc très bien, ta prochaine réponse a nulentout sera : "mets toi a l'anglais" ... Bonjour l'entraide

non Je lui repondrais avec plaisir comme l'a fait fdufnews dans la mesure de mes moyens,possibilités,connaissances, etc Mais celà n'empechera pas qu'il ne pourra se prevaloir d'un defaut de comprehension de lecture d'un document qu'il n'assimile pas directement.

Ma réponse n'était pas méchante (peut être cela a-t-il été mal interprété).

Pour ce qui est des doc en anglais, voilà un bon bout de temps que je fais de l'électronique (je suis effectivement pas très loin derrière nulentout) et franchement à part feu SESCOSEM (et peut être SGS Thomson mais je ne suis pas complètement sûr) je crois bien n'avoir jamais vu de datasheet en français. Il faut se faire une raison, tu fais de l'électronique ==> tu fais de l'anglais. Si tu fais pas de l'anglais alors il faut connaitre google translate. Je m'en sers de plus en plus parce avec l'arrivée des composants chinois.

Hou lala, je vois que le sujet passionne !
Bonjour les copains,
Fondamentalement, cette discussion n’est absolument pas relative à un « conflit de génération ». Le seul handicap dû à l’âge réside dans un conditionnement de toute une vie qui peut parfois générer une gène sévère dans nos activités.
Bon, de par ma formation, toute ma vie a été consacrée à la formation de techniciens ce qui implique déjà deux items :

  • Toute activité technique consiste à analyser en détail (Avant d’agir si il y a des risques) les données constructeur, peu importe la langue dans laquelle elles sont fournies.
  • Pratiquement toutes les données constructeur dans le monde de la technique sont en Anglais, il faut faire avec.

SVP, arrêtez de me le rappeler comme si je ne le savais pas, c’est du temps perdu car vous prêchez un convaincu.

Le VRAI PROBLEME, c’est que d’une part je n’arrive pas à lire autre chose que ce qui est écrit. A l’école primaire j’ai été formé comme ça, c’est devenu un réflexe conditionné. Si la phrase est contradictoire, je suis perturbé et ma sagacité est mise à mal.
Les documents constructeurs, les SYNTAXES mises en ligne pour le langage Arduino etc, ne sont pas autre chose que des informations rédigées par des humains. Elles ont le grand mérite d’exister, mais sont forcément entachées de maladresses, d’erreurs, d’incohérences etc.
IL FAUT FAIRE AVEC, c’est dans l’ordre des choses.

Mais si je suis parfois victimes de ce fait, je continue à plaider non coupable.

Exemple typique du « DATASHEET » sur l’ATmega328.
Naturellement que j’ai lu et relu ce document, et que j’y recherche souvent l’info avant de venir sur ce forum pour demander de l’aide. Mais sauf erreur de ma part il s’y trouve plusieurs contradictions. Tout particulièrement celle issue de ce sujet :
Il est affirmé que la SRAM interne à ce µP fait 2 kilo octets. (Page 18) Pour ma part elle doit donc contenir 2048 cellules mémoire, pas une de plus, pas une de moins. Vrai ou faux ?
Après je me suis fait un peu tirer l’oreille parce que je n’avais pas vu que les « vecteurs » du µP étaient placés dans la page zéro. FAUX, dans mes documents j’ai parfaitement situé les premiers octets, et conformément à la documentation j’avais compris que le TAS et la PILE sont plus haut.
Banal tout ça.
Mais ce que je n’avais pas saisi, c’est la butée haute de début de pile en 08FF qui manifestement dépasse les 2Ko. Problème !
ET OUI, il suffisait de savoir qu’en réalité, après les 256 octets réservés aux registres du µP on a réellement 2048 octets de plus pour les variables !
Franchement, est-ce facile à repérer ça dans la documentation de l’ATmega328 ?
Il y a donc une contradiction dans la documentation qui devrait annoncer non pas 2Ko de SRAM, mais une valeur égale à 2048 + 256. (Hé hé, je vous laisse le soin de faire le calcul)
Même si l’anglais avait été un domaine de prédilection pour moi, j’aurais rencontré exactement la même incompréhension.
Bon, j’ai été très bavard, et toute cette narration ne fait pas vraiment avancer le débat relatif à l’utilisation de la SRAM, aussi je vais écourter. (Si, si …)

Pas de conflit de génération, pas de regrets à voir le franglais envahir tous les domaines, tout ça c’est du temps perdu.
Par contre, ne supposez jamais que celui qui vient poser ici des questions parfois naïves le fait par paresse, qu’il ne s’est pas donné le mal de lire les DATATRUCs. On ne raisonne que par « sois même ». C’est le malhonnête qui ne fait pas confiance, c’est celui qui passe régulièrement au feu rouge qui vous gratifie d’un coup de klaxon parce qu’il à peur que vous ne vous arrêtiez pas quand il « déboule ». Je suis persuadé que tancer en public ne dévalorise que celui qui se montre un peu (Parfois beaucoup) « chef chef qui recadre son inférieur ».

Enfin, si vous trouvez qu’un Internaute exagère, ce que je conçois parfaitement, je crois qu’il est plus souhaitable de le lui dire par courrier personnel qu’en public, ce qui n’est jamais bien agréable, surtout si c’est justifié.
STOPPPPPP … j’arrête. :blush:
Amicalement : Nulentout.

Eh papy avec tes tout juste 66 ans tu es encore un jeunot ! Je file sur 68 et je me sens toujours comme à 20 ans. Bon c'est vrai il faut peut être relire les textes plus de fois que les jeunots de 50 balais pour être sur de bien avoir compris et le miroir, qui est vraiment désagréable, ne me renvoi plus l'image de la mèche noire qui tombait en permanence sur le front mais un grand vide bordé de blanc. Mais ce n'est pas grave en retraite tu as tout ton temps pour lire les datasheets et en cas de doute lors de la lecture du pdf : hop un copié collé dans Google Translator et l'affaire est jouée.

nulentout: Mais ce que je n’avais pas saisi, c’est la butée haute de début de pile en 08FF qui manifestement dépasse les 2Ko. Problème ! ET OUI, il suffisait de savoir qu’en réalité, après les 256 octets réservés aux registres du µP on a réellement 2048 octets de plus pour les variables ! Franchement, est-ce facile à repérer ça dans la documentation de l’ATmega328 ?

Oui et non la doc est touffue et on ne la lit généralement pas de bout en bout. Par contre lorsqu'on se pose une question particulière on trouve y généralement la réponse. Typiquement là, on trouve l'information relativement vite.

Pour être honnête, voilà plusieurs années que j'utilise la plateforme Atmel et je ne me suis jamais intéressé à l'adresse de la RAM. L'information en soi n'est pas vitale. Je veille à ne pas créer de variables de taille trop importante pour ne pas exploser la RAM. J'évalue la mémoire consommée par les fonctions que j'écris toujours dans le même soucis. Et lorsque j'ai un programme un peu trop instable sans raison apparente j'utilise la fonction freeRam pour vérifier si je ne dépasse pas les bornes. Pour répondre à la question que tu posais, je suis allé voir dans la doc d'AVR GCC où j'ai trouvé l'illustration de la gestion de la RAM. J'ai vu que l'illustration faisait démarrer la RAM en 0x100. Pour confirmer l'information j'ai ouvert la datasheet de l'ATmega328 chapitre "AVR memories" où l'on trouve une illustration du découpage mémoire.

En fait si tu n'avais pas posé la question, je n'aurais pas su la réponse. Comme je l'ai dit plus haut l'information n'est pas vitale. En C on ne bricole pas trop en mémoire RAM directement. On manipule les adresses mémoire de manière "transparente" via les pointeurs. Il n'y a guère que pour accéder aux registres du processeurs que l'on peut éventuellement se poser des questions. Et encore, comme il y a des variables prédéfinies dans les librairies du compilateur pour accéder aux registres de manière symbolique on n'a pas besoin de connaitre leur adresse. Je conclurais en disant que ta curiosité est un réflexe hérité de ta période "assembleur" où il fallait allouer la mémoire à la main. J'en ai fait pendant pas mal d'année et je comprends ton questionnement.

nulentout: Il y a donc une contradiction dans la documentation qui devrait annoncer non pas 2Ko de SRAM, mais une valeur égale à 2048 + 256. (Hé hé, je vous laisse le soin de faire le calcul)

Je me permet de ne pas être d'accord avec cette vision de la chose.Il ne faut pas assimiler les registres internes à de la RAM. Ce sont 2 choses distinctes. Il y a 256 octets de registres internes et 2K octets de RAM. Ce qui est inhabituel, c'est que le début de la RAM n'est pas aligné sur un multiple de 2k ce qui aurait fait démarrer la mémoire sur une adresse se terminant en ..000.

nulentout: Les documents constructeurs, les SYNTAXES mises en ligne pour le langage Arduino etc, ne sont pas autre chose que des informations rédigées par des humains. Elles ont le grand mérite d’exister, mais sont forcément entachées de maladresses, d’erreurs, d’incohérences etc.

Concernant la doc Arduino elle est très superficielle. Mais il ne faut pas oublier que le "langage Arduino" c'est du C et du C++. Il y a une quantité astronomique de doc sur le C. On trouve des cours pour débuter, des livres de référence sous forme de fichiers pdf, des cartes de référence du langage pour se faire des aide-mémoire. Il faut fouiller un peu et lorsqu'on trouve un site, un livre dont les explications sont claires on met l'info de coté.

Je me permet de ne pas être d'accord avec cette vision de la chose.Il ne faut pas assimiler les registres internes à de la RAM.
Ce sont 2 choses distinctes. Il y a 256 octets de registres internes et 2K octets de RAM. Ce qui est inhabituel, c'est que le début de la RAM n'est pas aligné sur un multiple de 2k ce qui aurait fait démarrer la mémoire sur une adresse se terminant en  ..000.

Ben … les registres sont explicités dans le chapitre SRAM, par ailleurs les adresses sont contigües avec celles de la SRAM. Donc, même , si fondamentalement les registres ont une spécificité propre au µP, dans le cas de l’ATmega ils font partie intégrante de la SRAM. C’est dans la documentation de référence.
Oui, si l’on choisit de programmer en langage évolué, en principe c’est pour faire abstraction de la “machinerie”. Dans cette optique on peut ignorer somptueusement la façon dont le compilateur se débrouille pour stocker les données. On peut ignorer les pointeurs etc.
Mais ayant voulu travailler les pointeurs, je suis bien obligé d’aller “lire” les octets en mémoire pour vérifier si j’ai bien compris leur fonctionnement.
Enfin, savoir comment fonctionne le compilateur est un incontournable si l’on désire l’utiliser “avec intelligence”.
Je n’ai aucune raison d’apprendre le C, et de faire l’apprentissage d’Arduino. C’est un jeu de l’esprit, comme d’autres font des mots croisés ou jouent aux échecs. Mais quand je me pasionne pour un domaine, en général je pousse toujours le plus loin possible mes expérience. Le but n’est jamais le résultat obtenu, mais le chemin parcourru pour y parvenir.
Vla, c’est dans cette optique que je m’égare dans des sentiers tordus qui n’ont rien de “rentable”.
Compte tenu de la difficulté que présente cette approche, je n’ai pas fini de reposer des questions sur ce forum.
NA … XD

P.S : Au fur et à mesure que j’avance dans mes études, je me fais des livrets au format A5. J’en ai un de 48 pages sur la syntaxe, un en cours d’écriture sur les bibliothèques. Je me fais aissi des fiches au format A5. J’imprime au format A4, je coupe au centre. Je colle tête bêche les deux cotés et j’ai une fiche Recto/verso. Je joins mes deux fiches actuelles sur la mémoire d’Arduino. Je vous invite à les critiquer pour toute information qui ne serait pas correcte. Merci à l’avance.

FICHES gestion mémoire.pdf (109 KB)

Bonjour,

J'ai l'impression que tu rends les choses très compliquées...

Si tu veux étudier les tripes de l'Atmega, passe à l'assembleur.

Pour le reste, je me souviens d'un excellent bouquin sur les compilateurs, écrit dans les années 90 (un dragon); il existait même en Français, ça devrait t'intéresser ! Je pense que c'est ceci: http://www.amazon.fr/Compilateurs-principes-techniques-outils-%C3%A9dition/dp/2744070378 EDIT: oui, c'est bien ce livre, dont la première édition date de 1977: https://en.wikipedia.org/wiki/Principles_of_Compiler_Design

Pour le reste, je ne comprends pas trop pourquoi tu parles de "C de l'Arduino". C'est du C/C++ standard avec les bibliothèques standard + la partie spécifique AVR.

Par exemple, mon jeu "Pong", je l'ai écrit en C++ sans me soucier que ce soit pour Arduino, PC ou poubelle à pédale. Et il a fonctionné du premier coup sur Arduino.

Donc je pense que tu devrais séparer tes recherches : l'une sur le langage, que tu pourrais continuer sur un ordi, en jouant avec la puissance et rapidité de ton ordi (et la facilité de jouer avec stdin et stdout), et de l'autre, les tripes de l'AVR, en assembleur.