Toujours plus serait certainement un titre mieux adapté ! Dans la création de PICOLAB nous avons défriché des chapitres particulièrement séduisants de la programmation orientée « mesurages » et dans la pratique du C++ d’Arduino. Nous avons considéré que notre minuscule laboratoire était aux limites du possible, car la dernière fonction ajoutée, celle de l’oscilloscope expérimental, avait engendré un problème de collision de PILE. C’est une façon « binaire » pour un microcontrôleur, de nous signaler qu’il commence sérieusement à atteindre ses limites et qu’il est temps de calmer un tantinet le frénétique compilateur. La programmation est un peu comme une sorte de drogue intellectuelle. Plus on en abuse, plus elle nous pousse pour basculer « du mauvais coté de la force ».
– PICOLAB est déjà pleinement opérationnel, que demander de plus ?
– Si, si, si, il manque le LEDMETRE, le pilotage des SERVOMOTEURS, pouvoir mémoriser des oscillogrammes dans l’EEPROM et pi tout, et pi tout,
x et pi tout sacré nom d’un labotruc …
Très mauvaise idée que d’avoir posé cette question, il y avait forcément des réponses !
Dans les nombreuses fonctions actuellement disponibles, certaines vous seront certainement très marginales pour ne pas dire inutiles. Il y aura toujours celle qui n’est pas émulée et qui « chaque jour fait particulièrement défaut ». Une solution élémentaire consiste à enlever du code source l’item du MENU estimé « parasite », mettre au point la nouvelle fonction, et la loger dans le programme complet.
Cette approche est très raisonnable, mais avant de considérer que nous avons repoussé PICOLAB dans ses derniers retranchements, il nous faut acquérir la certitude que le programme actuel a vraiment atteint les limites et qu’il n’est plus possible de repousser encore un peu les murs. Envisager le « toujours plus » impose un préalable : Libérer de la place en mémoire dynamique. Si nous n’arrivons pas à dégager de l’espace « sous la PILE », il sera illusoire d’imaginer augmenter les possibilités de notre appareil de mesures.
C’est incontournable. Nous allons dans cette optique continuer à survoler le domaine passionnant de l’optimisation des programmes. Par ailleurs, optimiser du code présente toujours deux facettes. La plus évidente est évidemment la recherche d’un gain de place, tous les artifices dans ce but étant les bienvenus. Vouloir, par exemple, ajouter dans PICOLAB la fonction CHRONOMETRE avec affichage des dixièmes de seconde va nous confronter au deuxième aspect de l’optimisation des programmes : Le gain en rapidité de certains traitements critiques. Autant dire que nous nous engageons dans un sentier qui ne va pas manquer d’intérêt. Abordons le premier but, c’est à dire la facette OPTIMISER LA TAILLE DU CODE. Plusieurs voies sont possibles :
1) Déplacer des constantes et en particulier du texte en EEPROM,
2) Diminuer la taille des textes affichés ainsi que leur nombre,
3) Repérer toutes actions de même nature et n’en écrire qu’une seule sous forme de procédure,
4) Remplacer des textes « numériques » par affichage de nombres.
5) « Compacter » au maximum certains traitements. Si par exemple une séquence est placée en procédure et invoquée qu’une seule fois, l’intégrer
x directement dans la section de code appelant.
Souvent, pour rendre le listage plus explicite, de longues séquences de traitement « visant une action plus globale » sont réunies dans une procédure. Le programme source est alors plus lisible. C’est dans ce cas, que déplacer les lignes de code sera utile pour gagner des octets.
Plusieurs pistes sont à notre disposition, on peut commencer à cheminer …
