Salut à vous tous!
Et bien oui, si j'arrive à faire tourner des codes en hard pur et dur sur mes arduinos, je ne connais que les bases du C / C++ (j'ai fait l'impasse dessus à l'école car j'étais en plein dans le turbo pascal et je ne voulais pas mélanger les deux). Comme vous le savez, je suis en train de programmer un 168, avec sa ram de ouf de 512 octets, et je commence à avoir pas mal de variables.
Ma question : comment optimiser au mieux les déclarations de variables et comment le compilateur "range"-t-il tout ça en mémoire(s) en fonction des déclarations?
En effet, lorsqu'on code, il y a plusieurs façons de déclarer des variables selon ce que l'on veut en faire, et je commence à me perdre.
1 - les constantes : exemple d'une tempo générale...
#define tempo 150
const tempo = 150;
const byte tempo = 150;
dans mon code, j'utilise un peu partout un delay(tempo);.
Je sais que avec le #define, le mot "tempo" est remplacé par "150" avant la compilation, et le code est alors envoyé au compilateur avec des delay(150);, il n'existe pas de variable tempo.
Mais est-ce qu'en utilisant un const ou un const byte, une variable "tempo" en lecture seule est déclarée (et me bouffe de la RAM inutilement, contrairement à un #define)? ou est-ce que le pré-compilateur va traduire mon const byte tempo = 150; en #define tempo 150 et donc ne pas générer de variable?
1bis - les tableaux de constantes
const byte array[5] = {...};
Ca va me donner quoi réellement? 5 octets en RAM que le compilateur va m'interdire de modifier?
2 - le mot clé static
il me semble qu'une déclaration avec static crée une variable en ram qui ne sera accessible qu'au code dans lequel elle a été déclarée et dont l'emplacement (l'adresse) est défini et invariable.
3 - le mot clé volatile
J'ai lu quelque part qu'une variable "volatile" était déclarée en RAM de manière définitive et une fois pour toutes (un peu comme en static), mais ce mot en français me fait penser aux vapeurs comme l’éther, c-à-d que ça se promène sans dire où ça va... un faux-ami? Pour moi, une "variable volatile" en français est une variable qui peut disparaître à tout moment, et réapparaître n'importe-où, comme un oiseau (qui lui est un volatile)... mais c'est pas ça du tout.
4 - "le compilateur optimise la variable"
Qu'est-ce qu'il faut comprendre par là? le compilateur essaie de voir ce à quoi une variable sert réellement et la rend "dynamique" (stack ou après ramend) si c'est possible? (définition française du mot volatile dans ce cas, le p'tit zozio qui se pose de branche en branche...)
5 - PROGMEM
Là, il y a un compromis à trouver entre le gain de ram et le temps de lecture de la variable...
6 - Conclusion : comme vous venez de le lire, j'y comprends rien dans les déclarations de variables. Je voudrais pouvoir coder et savoir réellement avant de compiler quelle taille de RAM va être occupée, et ce qu'il reste comme place pour le stack (donc les paramètres des fonctions, variables locales des fonctions...). Je veut pouvoir imaginer si ma pile (stack) va avoir une taille qui va beaucoup varier ou si justement, cette pile va être optimisée pour ne pas venir recouvrir mes variables...
Je suis preneur de toute info à ce sujet, voire même d'un tuto s'il y a... le net n'est pas très bavard de ce côté...