Bien, en attendant que le PCB arrive, j'ai commencé à regarder le software. Je vais me pencher sur le SW pour ma variante, cela va de soi.
Donc je vais partir sur du STM32L011K4, avec CubeIDE.
J'ai regardé l'implémentation
"legacy" pour voir un peu ce qui était fait et idéalement pouvoir reprendre des choses pour faire un peu de la convergence / cohérence, et, euh, bon, je pense que je vais faire à ma façon.
C'est du code orienté Arduino, utilisant un middleware (Arduino-Makefile), en C++. Moi je veux utiliser le HAL ST en C pur, donc ça ne va pas coller. A mon avis trop différent pour que ça vaille le coup de me baser dessus. Je vais tâcher de reprendre ce qui est utile (les fonctions de transfert par exemple) mais je vais refaire l'archi.
En plus, il y a des choix d'implémentation qui, hum, m'embêtent un peu. Genre il y a une fonction get_iron_temperature, et une fonction iron_get_temperature, et pareil avec set. Ces deux fonctions sont différentes, l'une traite la variable de température de la régulation, l'autre celle utilisée par l'affichage. Je ne cautionne pas ce genre de décision d'implémentation

c'est déjà bien suffisamment compliqué à comprendre et débugger pour se mettre des pièges comme ça.
Et d'une façon générale de toutes façons le C++ j'aime pas. Trop compliqué, trop implicite, et sur une application comme ça je ne vois absolument aucun intérêt à l'utiliser. Je comprend la logique de continuité avec le code Arduino - qui est fortement basé sur du C++ - mais si au final ça n'apporte aucun avantage évident, et qu'en plus il faut faire du taf d'optimisation ... Donc moi je vais faire du C.
Je vais découper le SW en trois modules principaux, comme sur le legacy : HMI, REGulation et SAVe, pour gérer respectivement l'interface utilisateur, la régulation de température en elle-même, et la sauvegarde en E²PROM.
Il y aura donc trois modules, HMI, REG et SAV, avec chacun des fonction Init, Start et Stop, et une fonction cyclique que je mettrai en callback d'un timer. Je vais donner la possibilité, comme sur le legacy, de donner des périodicités différentes pour ces trois fonctions, même si je pense que ça n'est pas vital, je pourrais très bien mettre un seul timer qui lance les trois fonctions à la suite.
Pour l'acquisition des entrées (mesure température et entrées IHM) j'hésite encore entre le faire dans les modules consommateurs, ou dans un module dédié, ce qui serait peut-être plus "propre".
Pour l'encodeur, je vais utiliser un système de machine d'état
tel que présenté ici, je l'ai déjà testé et ça marche très bien.
Pour la régulation je vais utiliser un PID classique, sur legacy il y a juste du proportionnel, mais j'ai bien envie d'aller un peu plus loin que ça.
Du classique.
E²PROM : sur le STM32L011K4 il y a une E²PROM intégrée de 512B. Enfin ... Une E²Flash en fait, faussement appelée "E²PROM" sur la fiche technique, mais ST n'est pas le seul à jouer sur les mots comme ça. En gros c'est une partie de la Flash qui dispose d'une meilleure granularité en effacement (on peut effacer par word au lieu de devoir le faire par page comme sur la Flash programme) et d'une meilleure robustesse (100k cycles contre 10k pour la Flash programme). En-dehors de ça elle se gère comme de la Flash programme. 512B ça fait 128 words, ce qui est largement suffisant vu qu'a priori je n'aurait au max qu'une dizaine de paramètres à stocker. Je peux même me permettre de faire du rolling et de re-découper en plusieurs pages pour encore augmenter la durée de vie (multipliée par le nombre de pages), et aussi avoir des mécanismes de test de cohérence et de fallback.