Le code compile en corrigeant l'erreur de la lib : return NULL; au lieu de return false;
Il y a une autre erreur dans votre code :
Votre fonction setup() appelle DebutEtatInit() à la dernière ligne.
Or dans votre source, la fonction DebutEtatInit() est définie APRES le code de setup()
Au moment de compiler setup() le compilateur ne connait pas le symbole DebutEtatInit() et ça pose probleme.
L'ordre d'écriture des fonctions dans un source, en compilation stricte, a une importance, aussi je vous invite à corriger cette erreur.
Une fois ces deux points réglés j'arrive à compiler de mon coté (mais il reste beaucoup de warnings inquiétants....)
5:43:06 Build Finished. 0 errors, 32 warnings. (took 2s.519ms)
Au délà de ces remarques, prenez en compte que l'utilisation dynamique de la mémoire n'est pas spécialement une bonne idée sur un "petit arduino". Avec ses 2 Ko de RAM, un NANO / UNO ne dispose que de très peu d'espace, qu'il doit consacrer à la pile et au "heap".
La fragmentation de ce dernier intervient rapidement et sans un peu d'air, le heap manager n'est pas capable de gérer.
L'utilisation de structures complexes utilisant beaucoup de pointeurs amène à une consommation de mémoire supplémentaire pour les liaisons inter-objets qui vient rapidement à bout de ce faible espace mémoire.
J'ai moi-même éprouvé cette limite récemment : une partie de code que j'avais écrite, qui utilisait des structures très dynamiques, fonctionnait bien sur MEGA (8 Ko de RAM) mais venait rapidement à bout d'un UNO, non parce que je consommais trop de données, mais parce que les allocations / suppression d'objets aboutissaient rapidement à un heap fragmenté saturé. Je n'avais pas ce problème sur le MEGA, et pourtant mon usage global de la RAM restait sous la barre des 1.5 Ko.
A voir si l'usage de structures telles que des listes chaînées est opportune pour votre code...S'il s'agit de stocker peu d'objets, un tableau a peu près bien dimensionné est peut-être préférable.
