Super_Cinci:
Dans le cas de mon LCD, j'ai des tableaux de codes de caractères genre byte caractere[2][15][9]. autant donc les déclarer en volatile pour être sûr qu'ils ne "bougent" pas? Vu la moulinette que ça fait pour afficher 5 caractères (exemple : "01234"):
Si ils ne sont pas utilisés par une fonction d'interruption le "volatile" ne fera qu'aggraver les choses.
Il devrait plutôt être "static const" (static = local dans le fichier + const = constant) afin de laisser le compilateur faire son agencement de manière optimisé.
(le tableau sera toujours stocké de manière contigu quoi qu'il arrive).
Super_Cinci:
mieux vaut éviter le progmem, non?
Tout dépend du rapport taille/nombre d'appel.
Si tu as énormément de données à stocké le PROGMEM sera la meilleur option.
Si tu as peu de chose a stocker mais a appeler souvent la mise en RAM sera l'option la plus rapide.
Super_Cinci:
Dans le cas de fonctions qui utilisent des variables locales de calcul temporaire, pour gagner de la ram, j'airais intérrêt à déclarer ces variables en global et volatile en faisant attention qu'une fonction appelée ne modifie pas une varaible de calcul de la fonction appelante?
Non tu n'y gagneras rien, au contraire tu seras perdant.
L'accès à une variable globale demande 2x plus de temps qu'une variable locale.
En plus si elle est déclarée volatile (= sans optimisation) tu auras une perte de performance dans ton algo.
Super_Cinci:
Est-ce que je gagne beaucoup à utiliser des passage de paramètres en pointers plutôt que valeur, tant que ça reste compatible, j'ai certaines fonctions incompatibles du genre :
Pour l'utilisation des pointeurs c'est pas compliqué :
1 pointeur = 2 octets (sur un AVR)
Donc pour un byte (1 octet) ou un int (2 octets) cela n'a strictement aucun intérêt.
Maintenant si tu utilises des long, float, ... cela reste très moyen d'utiliser des pointeurs.
Au final tu gagnes quelques instructions lors de la copie des arguments, pour les perdre ensuite avec l'accès via le pointeur ...
A pars pour de grosses structures de données ou des cas spécifique demandant l'accès par pointeur cela n'as pas d'intérêt.
Super_Cinci:
Oui, je sais, je cherche l'optimisation à la petite bête... mais l'histoire des paramètres de fonctions, ça ferait gagner du temps aussi, non?
La meilleur optimisation ce n'est pas "static", "volatile", ... c'est de revoir ton code pour qu'il soit le plus efficace possible.
- Pas de code en double (sinon c'est le signe que le code est mal pensé)
- Jouer avec les syntaxes du C pour rendre l'optimisation plus poussé (il y a une note d'application d'atmel sur le sujet)
- Float -> arithmétique à virgule fixe (gain de perf de l'ordre de x4 mais perte de précision)
- Choix intelligent des types de données (stocker une valeur de 0 à 127 dans un int n'as pas d'intérêt, un uint8_t suffit).
- Choisir intelligemment ses options de compilation / linker
- etc ...
68tjs:
Sans doute vous connaissez l'existance de la note d'application AVR4027 sur l'optimisation du code.
http://www.atmel.com/Images/doc8453.pdf
Je joins le lien pour ceux qui seraient intéressés.
Voila c'est de cette note d'application dont je parlai, merci 68tjs pour le lien.
68tjs:
Juste une petite remarque périphérique : "avr-size -C --mcu=atmegaXXX fichier.elf" peut s'invoquer directement en ligne de commande dans un terminal, le makefile n'est pas obligatoire.
Oui mais faire un makefile t'oblige à regarder de plus prés tes options de compilation / linker 
Optimiser un code sans optimiser sa phase de compilation / link ne sert à rien 
SesechXP:
J'étais passé à côté de cette note d'application relativement récente. En plus elle utilise AVR-GCC 8)Du même tonneau, il y a aussi la note Efficient C Coding for AVR.
Je connaissait pas cette note, ça va me faire un peu de lecture tient