Gestion de la mémoire dynamique.

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é.