Grâce à cette expérience qui va changer votre vie, (C’est une boutade !) vous allez non pas assister à une collision de deux véhicules automobiles, de deux aéronefs, de deux particules dans un cyclotron apériodique, de deux discutions qui dégénèrent, mais à une Collision de PILE ! On peut affirmer sans risquer de se tromper, que si à un moment donné votre programme ne réagit plus, qu’il reste inerte quelle que soit votre excitation nerveuse sur le clavier ou sur les capteurs, c’est que :
• Soit le logiciel est enfermé dans un traitement qui prend vraiment beaucoup de temps,
• Soit le programme est enlisé dans une boucle infinie, le test de sortie n’étant jamais positif.
• Il existe un troisième cas clinique, mais avant de le décrire il nous faut l’expérimenter :
Téléverser le démonstrateur Experience_157.ino qui constitue un automatisme aveugle.
1) Sans rien modifier au programme le faire fonctionner. Il affiche « PILE – TAS = 1787« .
2) Pour comprendre en détails ce que signifie cette information il vous faudra consulter dans le dossier <Documents> le fichier Collision_entre_la_PILE_et_le_TAS.pdf, mais seulement après avoir terminé les manipulations d’Experience_157.ino. On constate qu’à cette étape la place disponible entre la PILE et le TAS est de 1791 OCTETs ce qui est très largement suffisant.
3) Valider la ligne 73 du croquis. Le programme affiche le Tableau_1 de 6 x 6 ‘*’ et la place disponible entre la PILE et le TAS devient 1755 OCTETs soit 36 emplacements de moins. On observe ainsi que les tableaux sont biens préservés dans cette zone de mémoire vive.
4) Valider alors la ligne 75 du croquis. Le programme affiche le Tableau_2 de 32 x 16 ‘&’ avec la place disponible entre la PILE et le TAS qui devient 1243 OCTETs soit 512 emplacements de moins. On confirme ainsi que les tableaux sont biens préservés dans la RAM dynamique.
5) Repasser les lignes 73 et 75 en remarques pour ne plus afficher les deux tableaux T1 et T2. Valider la ligne 77 pour n’afficher que le Tableau_3 de 78 x 16 ‘#’. L’affichage précise 543 ce qui confirme la place prise de 1791 – 543 = 1248 OCTETs consommées par ce dernier tableau de caractères.
plus que quatre octets de disponibles. La conséquence prédite par ce message d’alerte n’est pas systématique. Je l’ai rencontrée très souvent avec des sketchs dans lesquels la mémoire programme était entièrement occupée et la RAM dynamique bien remplie. Ces derniers fonctionnent parfaitement. Toutefois, quand cette ligne orange est affichée, il vaut mieux faire « le test de collision de PILE ». Quand on téléverse cette dernière version d’Experience_157.ino qui en toute logique devrait fonctionner on obtient un affichage totalement incohérent ... PAFFFFFFffffffff !
Conclusion : Bien que la taille de PILE – TAS ne soit affichée, il est facile de la calculer. Lorsque l’on affichait Tableau_1 et Tableau_2 il restait 1243 OCTETs entre la PILE et le TAS. Le Tableau_3 s’octroie 1248 OCTETs. Au moment de la compilation les trois tableaux sont placés sur le TAS et la zone disponible devient égale à 1243 – 1248 = -5 OCTETs. De ce fait le TAS va écraser les données du bas de la PILE et le programme se met à faire n’importe quoi.
ATTENTION : Pour des raisons déjà explicitées, je développe mes logiciels avec la version 1.7.9 du compilateur. Je ne passe à des versions plus récente que si je n’ai plus assez de place disponible pour loger le programme. Comme les versions plus récentes sont mieux optimisées, le code qu’elles produisent est plus compact. Donc pour cette expérience utilisez la version 1.7.9.
Incriminer (à tort) le matériel : Lorsque l’on développe un programme, on se heurte forcément à un moment ou à un autre à des murs qui nous résistent. Parfois on est face à du code qui semble hors de cause. Obnubilé par quelques lignes que l’on vient d’ajouter on « tunnellise » et on arrive trop souvent à imaginer une collision de PILE, ou pire : On a effectué des centaines d’essais avec notre carte UNO et on commence à douter de sa fiabilité, car on sait que la mémoire non volatile est limitée à environ 100000 écritures. Alors on extrait l’ATméga328 de son support et on le remplace par un composant neuf. On interchange la carte NANO et on téléverse à nouveau le croquis … même punition. Il s’agit bel et bien d’une erreur de logiciel, sauf qu’elle est trop souvent tellement évidente qu’on ne la voit pas. Sachez que lorsque j’ai commencé à rédiger ce didacticiel, la carte Arduino UNO qui me sert de victime avait déjà servie à programmer de nombreux projets et subi des centaines de téléversement. Elle a également servie aux innombrables tentatives de développement de l’intégralité des démonstrateurs de ce didacticiel … et elle est encore en pleine forme ! Vous pouvez vous faire une idée des milliers de téléversement qu’elle a vécu. Alors ne commettez pas mon erreur qui bien trop souvent accuse la carte Arduino, et depuis des années de pratique, ça na jamais été le cas. C’EST LE PROGRAMME QUI EST EN CAUSE ou éventuellement le matériel d’interfaçage, pas Arduino. Un programmeur averti en vaux deux …
La suite est ici.
