En exiger toujours plus !

Remplir la zone programme non volatile à ras-bord :

Jamais assez, c’est l’aiguillon qui propulse le drogué informatique encore plus loin. Tant que l’ATmega328 n’est pas gavé, qu’il reste plein plein plein de place pour le programme, vouloir en rajouter une couche pousse à l’obsession. On va encore basculer du coté obscur de la force. La compilation de P13_Complet_avec_ajout_pilotage_servoMTR.ino aboutit à une occupation d’à peine 87% pour le programme et 36% dans les variables dynamiques. Impossible d’en rester là, et de se contenter d’un tel gaspillage. Nan nan et nan … on va ajouter une nouvelle fonction NA !

– Môamôa je veux le LEDmètre trukchose qui calcule tout !
– Boff, il ne sert pas vraiment à grand chose ce module !
– Non, mais Môamôa j’aime bien faire varier la luminosité des LED, ça fait Noël !
– OK, c’est bien pour te faire plaisir, mais c’est uniquement parce qu’il reste de la place.

Pour ne pas mentir, rien à voir avec le fait de faire plaisir à Totoche. Cet opus qui franchement ne m’est pas vraiment utile, a été ajouté car j’ai pensé qu’il ne serait pas trop gourmand en code, me réservant la possibilité de le congédier si plus tard un autre module plus exigeant en place pouvait arriver à se loger sans provoquer une collision de PILE avec le TAS.

Ajouter le LEDmètre à PICOLAB.

Pessimiste sur l’opportunité de pouvoir intégrer le BETAmètre, le CHRONOMÈTRE, le CAPACIMÈTRE, le choix provisoire pour le module de « saturation » s’est donc orienté vers l’item LEDmètre. On poursuit notre routine qui consiste à élaborer un démonstrateur suivi de la tentative d’ajout dans le programme complet. La liste s’allonge avec P14_LED_metre.ino qui permet d’optimiser l’écran d’exploitation montré sur la Fig.126 qui incite dans le cadre supérieur à modifier l’ajustement du potentiomètre. (Qui doit être branché et validé avec le « strap » à languette)
Tourner le bouton permet d’ajuster à convenance la brillance de l’échantillon testé. Un clic court sur l’un des deux boutons poussoir fait indiquer les diverses valeurs associées à la luminosité actuelle de la LED D en cours d’évaluation. Nous savons que mesurer la tension aux bornes de l’échantillon fausse un peu les calculs car la résistance de 1000Ω qui va de l’entrée R Ω au +5Vcc injecte un petit courant dans la LED non pris en compte

dans les calculs. Il serait possible d’évaluer ce courant et d’en tenir compte dans les équations, mais le rapport qualité/prix n’est pas favorable. La taille du programme augmenterait, alors que la précision obtenue pour cette fonction « marginale » est généralement suffisante. Par contre, pour minimiser cette imprécision, on ne va plus utiliser A2 pour mesurer ΔU sur la LED, mais A3. La résistance perturbatrice passe alors de 1000Ω à 22kΩ avec une influence bien moindre. Le schéma de la Fig.127 présente les branchements à effectuer lorsque cet item du MENU de base est sélectionné. Globalement, si les diodes LED en test présentent un fort rendement, pour des résistances calculées inférieures à 500Ω la luminosité réelle sera plus forte. Il faut majorer la valeur de cette dernière. L’incorporation d’une nouvelle fonction est toujours effectuée dans un nouveau programme pour ne pas risquer de « polluer » celui qui fonctionne correctement en cas d’abandon du projet par manque de place. P15_Complet_avec_ajout_du_LEDmetre.ino dans la liste fait suite au démonstrateur.
L’ajout se passe sans histoire, et tout fonctionne sans anicroche. Avec 90% de place occupée par le programme on commence à approcher le déraisonnable. D’un autre coté les variables dynamiques fleurtent à peine avec les 37%, avouez que c’est assez incitatif à exagérer un tantinet du coté obscur de la force. On va tenter de forcer un item de plus pour le MENU de PICOLAB, ce serait du genre assez valorisant d’y parvenir …

Ajouter le CHRONOMÈTRE à PICOLAB.

Abandonné initialement car le premier essai de développement n’arrivait pas à obtenir une cadence de comptage rapide à l’écran, tenter de contourner cette « impossibilité » constitue un défi séduisant. Une nouvelle approche va permettre d’élaborer une solution qui au final se montre tout à fait acceptable. Nous savons que l’affichage relativement lent sur OLED interdit un rafraichissement au dixième de seconde. À bien y réfléchir, ce qui importe, c’est une cadence rigoureuse et précise du comptage, soit exactement dix fois par seconde. Ensuite, si le chiffre des dixièmes ne « tourne » que trois ou quatre fois par secondes, visuellement c’est entièrement suffisant pour voir que le chronomètre est bien déclenché. L’idée retenue pour ce projet est donc la suivante :

• Le comptage dix fois par seconde sera confié à la fonction millis() associée comme c’était déjà le cas pour le capacimètre à la variable
x  Ancienne_valeur_Temps_Ecoule_depuis_RESET.
• L’affichage sera rafraichi le plus rapidement possible pour agrémenter l’impression visuelle.
x  Suite à de nombreuses tentatives laborieuses, la technique retenue la plus rapide pour afficher  consiste à calculer à chaque rafraichissement les
x  diverses valeurs des heures, des minutes et des secondes à partir du temps mesuré entre l’instant du déclenchement et l’instant présent.
x  Cette approche interdit de pouvoir remettre à zéro « à la volée » le chronomètre. Le mode de fonctionnement devient alors le suivant :
• FC- fait passer l’affichage en PAUSE. Le chronométrage se poursuit mais l’écran est figé. Un deuxième appui sur
x  FC- (Ou sur FC+ durant la PAUSE) rétablit la mise à jour des valeurs qui « font un bond » si la PAUSE a été
x  longue. Durant la PAUSE la LED jaune clignote rapidement pour informer l’utilisateur qu’à ce stade les deux
x  boutons font revenir en mode animé. Notez que la PAUSE est aussi indiquée par l’affichage de « P«  à gauche
x  des valeurs, lettre mise en  évidence par coloriage en rouge sur la Fig.128 ci-contre.
• FC+ une première fois (Hors PAUSE.) stoppe le chronomètre et l’on peut lire la durée. FC+ une deuxième fois
x  déclenche le chronomètre mais commence par sa remise à zéro.

La Fig.129 permet facilement de décrypter le principe retenu pour chronométrer. Sur un démarrage de l’ATmega328 ou sur un RESET, le système interne au microcontrôleur démarre un compteur qui s’incrémente inexorablement toutes les millisecondes. Son fonctionnement est autonome et effectué en « temps masqué ». Quand on clique sur FC+ une « première fois », il y a appel immédiat à la procédure void RAZ_CHRONOMETRE() qui recopie immédiatement la valeur actuelle de millis() dans Ancienne_valeur_Temps_Ecoule_depuis_RESET. Puis, la variable Pulse_plus est remise à zéro.

Enfin, sans urgence à partir d’ici, on peut revenir à la boucle qui teste la présence d’activation d’un B.P. et procède au rafraichissement des valeurs sur l’écran OLED. Si la PAUSE est activée, on se contente d’attendre la prochaine activation de l’un des deux boutons du clavier. L’affichage est figé et la LED jaune clignote rapidement. Le temps continue de s’écouler et le compteur millis() s’incrémente. Quand on sort de la PAUSE, à chaque rafraichissement aux instants T qui se succèdent dans la boucle, la variable Pulse_plus = millis() – Ancienne_valeur_Temps_Ecoule_depuis_RESET. Ainsi Pulse_plus contient la valeur du temps chronométré en mS. Pour afficher ce dernier, il faut transposer sa valeur en Heures, Minutes et Secondes ce que fait void Afficher_le_CHRONOMETRE().

Intégrer le testeur de continuité à PICOLAB.

Toujours aussi conciliant, la version P17_Complet_avec_ajout_du_Chronometre.ino accepte sans renâcler l’ajout de la fonction chronomètre. Les diverses optimisations réalisées portent leurs fruits. Le compilateur annonce 93% d’occupation de place pour le programme, les données dynamiques en « squattent 39% ». S’il est vrai que les affichages de textes sont très pénalisants en consommation de RAM dynamique, ajouter quelques instruction peut être envisagé, car 7% du total nous laisse encore 2114 octets possibles, largement de quoi ajouter du traitement dans le code. Hors, il suffit de « sonoriser » la fonction OHMmètre pour en faire un testeur de continuité. Quelques instructions tone() de plus ne vont pas ruiner notre « espace vital » !
Restant « frileux », pour minimiser l’impact de cette modification du programme qui maintenant devient P18_Complet_avec_test_continuite.ino, uniquement deux plages de valeurs sont distinguées en testeur de continuité. Cette sobriété réduit l’incidence à seulement 142 octets supplémentaires exigés par le code objet. Pour une application de plus dans l’appareil de mesures c’est vraiment peu.

L’intégralité des lignes source ajoutées au programme complet sont listées dans l’encadré ci-dessus. Visuellement le comportement du programme reste strictement inchangé. Ce n’est que si l’on réunit la sortie B.F. au BUZZER externe que l’on s’apercevra de la différence :
• Si la résistance mesurée est inférieure à 10Ω une tonalité de 2000Hz se fait entendre,
• Si le contact donne une mesure comprise entre 10Ω et reste < 20Ω ce sont 800Hz qui sont générés,
• Toute valeur supérieure à 19.99Ω force au silence la génération sonore.
C’est facile, c’est pas cher et ça peut rapporter gros !

Trop goinfrer peut conduire à l’indigestion !

Croiser à grande vitesse le véhicule qui arrive en face est devenu pour nous une telle habitude que l’on ne réalise plus vraiment le danger permanent que cela représente. Il arrive à 80km/h, et nous lambinons aux environs de 70km/h. C’est rien, une sensation de tranquillité règne dans l’habitacle, et ce d’autant plus que les véhicules actuels sont très bien insonorisés. Avec une vitesse relative qui frise les 150km/h nous nous croisons avec combien d’écart ? Cinquante centimètre, soixante dix centimètres ? À cette vitesse, combien de temps nous sépare de la collision fatale si par étourderie on a oublié un tant soit peu la conduite ? Avouez qu’amenée ainsi, cette narration montre que la marge de sécurité est loin d’être aussi grande que ne le laisse penser la musique sereine diffusée par l’autoradio. Il en est tout à fait pareil en programmation quand une marge de sécurité devient peau de chagrin.
Les tentatives de bourrer encore et encore ce pauvre microcontrôleur peuvent amener le programme à la frontière du déraisonnable. On va surfer sur le fil du rasoir avec une épée de Damoclès au dessus de la tête.
C’est à dire que le risque de provoquer un problème durant l’exécution augmente. La marge d’erreur diminue, et à tout moment l’incident guette.
En effet, sans que nous n’en soyons forcément conscients, une foule de phénomènes se produisent dans le petit circuit intégré. À chaque appel de procédure, l’adresse de retour est empilée. Si la procédure invoque à son tour une autre copine, c’est encore deux octets de plus consommés par le STACK POINTER. Si dans la procédure en cours, il est fait appel à une fonction avec passages de paramètres, la PILE étend encore son hégémonie et s’approche du TAS. On oublie surtout que le contexte déclenche des interruptions, sans prévenir. Par exemple le fréquencemètre fait appel à une routine d’interruptions, et comme pour les procédures, ce type de saut empile des informations pour permettre un retour correct à « la normale ». Enfin, il y a les interruptions cachées, celles que l’on déclenche sans forcément le savoir. Par exemples les instructions de l’IDE qui impliquent l’utilisation des TIMERS. Bref, ça branche, ça saute, ça empile à tout va et le bas de la PILE s’approche dangereusement du TAS. Jusqu’au jour où … PAFFF … le programme dérape. Les nombreux tests effectués durant le développement ne peuvent pas nous assurer d’avoir été en présence de l’intégralité des combinaisons possibles. En résumé : Le programme peut devenir instable.

@ Voir également les détails figurant en début du chapitre Approche « évidente » pour gagner de la place en RAM dynamique.

Ajouter la fonction de mesure des condensateurs à PICOLAB.

Comme la collision de PILE se fait encore oublier et qu’il reste plein plein plein d’octets disponibles dans l’HLM du programme, on va tenter encore une fois de pousser le bouchon un peu plus loin ! Cette tentative de bourrer encore plus ce pauvre microcontrôleur peut amener le programme à la frontière du déraisonnable. On se doute que si l’ajout est acceptable et que le comportement du programme semble correct, il faudra impérativement vérifier la marge de sécurité réelle par appel aux méthodes expliquées dans tout ce qui précède sur le sujet.
À nous la boulimie informatique !
On se coltine P19_Mesure_CONDENSATEURS.ino avec pour mission de minimiser les bavardages textuels. La Fig.130 montre la présentation retenue. Un titre dans la zone « orange », et le minimum pour l’affichage de la valeur et des unités. Dès que le démonstrateur semble bien au point, on insère le code du capacimètre dans l’ancien programme complet, on ajoute un item dans le MENU de base et le tour est joué. Enfin, pas tout à fait, car avant de téléverser la nouvelle version P20_Complet_avec_ajout_du_CAPACIMETRE.ino on procède à quelques optimisations, ça ne peut pas faire de mal. Par exemple on crée la procédure void Affiche_P() qui fait gagner huit octets. Puis, on utilise deux fois le texte « Change » disponible en EEPROM ce qui économise la bagatelle de trente quatre octets. Miam miam ! On peut encore se servir de  « Empreinte num «  également disponible en EEPROM, le programme maigrit encore de huit emplacements. Mazette, optimiser à outrance augmente la sécurité, on peut maintenant téléverse le logiciel complet dans Arduino et … ça tourne comme une montre suisse ! Toutes les fonctions semblent ronronner parfaitement, et pour nous convaincre que la marge de sécurité est suffisante, on téléverse à son tour le programme outil P21_Complet_avec_test_de_PILE.ino qui n’est que le précédent auquel on a ajouté les deux petites séquences d’exploration de la mémoire. Bien que ces dernières exigent 120 octets de code exécutable et 20 octets de mémoire dynamique, l’espace annoncé entre la PILE et le TAS fait encore 205 octets, soit une marge très confortable. Le programme actuel titille les 96% d’encombrement. C’est déjà d’une rentabilité avérée. Gnarf gnarf gnarf … il reste encore 1096 emplacements possibles pour le code, plus d’un kilo-octet.

– Scongreugneugneu, c’est du gaspillage,  faut réagir !

Ajouter la fonction BÉTAMÈTRE à PICOLAB.

S’il ne s’agissait pas d’un didacticiel visant à convaincre que l’optimisation des programme devrait confiner à un mode de vie pour les programmeurs, franchement il y a belle lurette que j’aurais considéré personnellement que PICOLAB était terminé. LEDmètre et CHRONOMÈTRE auraient largement été oubliés. Dans le cadre de ce chapitre, nous allons tenter d’ajouter encore ce complément, le but non avoué étant de pousser l’ATmega328 dans ses derniers retranchements. Bien que son utilisation me semble très occasionnelle, compléter ainsi PICOLAB n’est pas totalement stérile. Outre l’aspect pédagogique, il sera toujours possible de le remplacer par un module « original », si d’aventure vous vouliez personnaliser votre appareil. Au vue de l’originalité dont font preuve les noms des fichiers, vous avez déjà compris que P22_BETAmetre_NPN.ino était le démonstrateur chargé de la mise au point des écrans. La Fig.131 montre le message qui sera présent dans la zone « orange » s’il n’y a pas de transistor placé sur le support ou si le courant injecté

sur sa base est insuffisant pour permettre une mesure correcte. Vous constaterez que ce n’est pas le même que celui issu du démonstrateur. Nous verrons plus avant que cette différence résulte des optimisations impératives pour arriver à faire fonctionner correctement le programme complet. En rouge est symbolisée l’invitation à augmenter le courant de base en tournant le bouton du potentiomètre. En jaune il s’agit de la suggestion d’insérer un transistor NPN sur le support. Les textes définitifs ont été choisis pour employer au maximum ceux qui existent déjà ou utiliser plusieurs fois le même. Par exemple le texte NPN sert également au titre, dans lequel « BETAMETRE. » du démonstrateur à été remplacé par « Gain NPN. » en réutilisant les trois lettres communes NPN. Remarque analogue pour la Fig.132 qui présente l’écran quand un transistor est mesuré. On peut faire passer le programme en PAUSE avec FC- ou FC+ courts. Dans ce cas la lettre « P » est affichée dans la zone haute et la LED jaune clignote rapidement. (Lettre mise en évidence en rouge sur la Fig.132) Par rapport à la séquence développée pour le MINI LABORATOIRE, le code a été modifié pour améliorer la précision des mesures, et surtout présenter plus finement la caractéristique du transistor évalué. En effet, l’expérience montre que le gain en courant β augmente quand le courant de base diminue. La tension Collecteur/Emetteur n’est plus indiquée pour gagner du temps d’affichage et réduire le code objet. Par contre, Ib est précisé, ainsi on peut mieux corréler la relation existant entre gain en courant et courant de base. Analysons les modifications apportées au programme initial :

L’impossibilité de pouvoir mesurer la tension Base/Emetteur Ube pour le programme du MINI LABORATOIRE constituait une source d’imprécision importante pour évaluer le courant de base Ib. Hors c’est ce dernier qui permet directement le calcul du gain en courant. On se contentait de « croire » en une tension moyenne Ube de 0,67V. La mesure n’était au final qu’une évaluation relativement grossière. La pratique montre que cette tension varie de façon notable en fonction du transistor placé sur le support et du courant injecté dans sa base. Avec PICOLAB, nous disposons d’une entrée analogique de plus, il est donc possible d’effectuer une mesure objective d’Ube. Sur le schéma électronique de la Fig.133 la platine principale et le petit adaptateur supportant le potentiomètre sont représentés en couleurs pastels avec un encadrement bleu clair. Le petit module associé à PICOLAB pour réaliser le BÉTAmètre est dessiné dans l’encadré beige.

Examinons en détail l’agencement de l’ensemble et l’organisation du programme. La tension générée par le potentiomètre est propagée jusqu’à l’entrée analogique A1 à condition que la languette du strap S soit en place. La résistance R3 de 10kΩ n’a aucun effet étant donné que l’entrée A1 est à haute impédance. En amont du strap S la tension présente sur le curseur du potentiomètre est acheminée vers la base b du transistor T par la résistance R5 de 1kΩ. Pour visualiser la « conductance » de T on a placé en charge du collecteur c la diode électroluminescente D dont la résistance R6 de 3,3kΩ limite le courant. Pour que le transistor T puisse débiter un courant significatif, son collecteur c est chargé par la résistance R4 de 100Ω. La tension Collecteur/GND Uc est mesurée par A2. Comme cette entrée analogique est réunie au +5Vcc par la résistance R1 de 1kΩ, un petit courant supplémentaire sera drainé à la masse GND par T, il faudra en tenir compte dans les calculs. La tension Base/GND est mesurée par A3. Comme cette entrée analogique est également réunie au +5Vcc par la résistance R2 de 22kΩ, un petit courant permanent est injecté dans la base b du transistor T et ne peut être ignorée dans le traitement logiciel.

La mise en œuvre logicielle du BÉTAmètre.

Dans la mesure où l’on peut mesurer tous les paramètres significatifs et qu’un complément de calcul ne va certainement pas trop augmenter la taille du traitement logiciel, il serait absurde de bâcler les équations. Dans ce chapitre nous allons pas à pas élaborer les formules de calculs, les coder ensuite en C++ relèvera de l’évidence. Par définition, le gain en courant β d’un transistor bipolaire conventionnel est égal à :

β = Ic / Ib

Pour pouvoir effectuer cette division il faut au préalable calculer le courant collecteur Ic et le courant de base Ib.
Considérons le schéma partiel de la Fig.134 qui présente la branche électrique coté collecteur.
L’intensité ILED est égale à celle qui traverse R6 puisque ces deux composants sont placés en série.
I = U/R va encore s’imposer en divers endroits de cet exposé. Aux bornes de D la valeur de ΔULED fait au minimum 1,2V. La tension Uc ne descend pas en dessous de 0,5V. La tension aux bornes de la résistance R6 sera au maximum de 5 – 0,5 – 1,2 = 3,3V. L’intensité dans D sera donc au maximum de 3,3 / 3300 = 1mA. Comme il s’agit d’un grand maximum, cette intensité sera négligée dans les calculs. L’intensité Ic sera donc égale au courant traversant R1 plus celui traversant R4. Comme ces deux composants sont câblés en parallèle, tout se passe comme si nous étions en présence d’une seule résistance de valeur 90,91Ω.
La formule de calcul pour le courant collecteur devient : Ic = (5000 – Uc) / 90.91
Les tensions mesurées par le CAN étant multipliées par 1000, le courant calculé sera donc exprimé en mA. Traduite en langage C++ de l’IDE dans le démonstrateur la formule devient :

Examinons maintenant la Fig.135 qui établit le circuit partiel générant le courant de base. Deux sources peuvent engendrer un mouvement d’électrons vers b. Le courant de base principal Ib2 est fourni par le potentiomètre à travers R5 de 1kΩ. La branche qui mesure Upot via R3 n’intervient pas dans les calculs

car A1 présente une très grande impédance interne. L’entrée A3 a pour mission de mesurer la tension de base Ub. Sa résistance de forçage au +5Vcc R2 engendre le courant « parasite » Ib1 dont il faut impérativement tenir compte dans les calculs. Un petit « I = U/R » appliqué à R5 permet d’écrire : Ib2 = (Upot – Ub ) / 1000. Les parenthèses sont impératives pour tenir compte de la priorité des opérateurs dans une formule de calculs. Toujours avec la loi d’Ohm on peut affirmer : Ib1 = (5000 – Ub ) / 22000. Le courant de base sera égal à la somme des deux débits, soit :

Ib = ((Upot – Ub ) / 1000) + ((5000 – Ub ) / 22000).   (*)

Le schéma de la Fig.133 n’a pas été agencé librement. Nous étions sous contrainte, et en particulier nous ne pouvions nous brancher que sur l’existant. En particulier modifier l’intérieur de PICOLAB était totalement exclus. L’électronique retenue engendre un petit inconvénient pratique dont il faut naturellement tenir compte dans le programme. Supposons que l’on ajuste le potentiomètre pour fournir un courant de base nul. La résistance R2 continue à alimenter la base du transistor, assurant en b une tension légèrement positive. Le calcul Upot – Ub donne alors une valeur négative. Concrètement, ce sera le cas chaque fois qu’Upot sera inférieur à Ub. La formule de calcul du gain est alors erronée, ce qui de toute façon traduit le fait que l’intégralité du courant Ib1 ne traverse pas le transistor T mais un résidu est dérivée vers le potentiomètre. Quand cette condition est détectée, au lieu d’afficher un gain fantaisiste, le programme incite à augmenter Ib2 par le message .
Décortiquons la séquence de code qui se charge de calculer Ib.

En ligne (1) on mesure avec l’entrée analogique A1 la tension fournie par le potentiomètre.
En ligne (2) on sauvegarde dans la variable Capacite la tension Upot.
Notez au passage que l’on utilise au maximum des variables déjà disponibles dans le programme complet pour minimiser l’espace mémoire exigé par le module BÉTAmètre.
En ligne (3) on mesure avec l’entrée analogique A3 dans Tension_lue la tension Ub.
La ligne (4) n’est qu’une réécriture de la formule (*). La distribution des parenthèse s’accommode de la priorité des opérateurs pour exclure tout calcul erroné. Les tensions mesurées sur A1 et A3 s’étalent sur une plage de numérisation allant de 0 à 5000. Comme il n’y a pas de coefficient correcteur pour définir ces tensions en volts, le courant calculé sera exprimé en mA.
La ligne (5) provoque le message d’invitation à augmenter le courant dès que le courant de base Ib devient inférieur à 10µA. Cette faible valeur ménage une marge de sécurité pour lutter contre les fluctuations de numérisation tout en restant compatible avec des transistors à fort gain en courant.
Le reste du programme coule de source et n’appelle aucun autre commentaire.

Encore un petit module de complément extérieur.

Réutiliser le module du MINI LABORATOIRE serait possible, mais en ajoutant plusieurs fils un peu partout avec tous les risques d’erreurs que cela implique. Créer un petit circuit de plus n’est pas la mer à boire, quand à son prix de revient, pas de quoi non plus mettre notre compte en banque dans le rouge.
(Il y est déjà depuis des lustres !) Si vous envisagez de réaliser un tel adaptateur, la Fig.136 en donne le dessin du circuit imprimé, et la Fig 137 en montre une photographie. Il s’agit d’un tout petit module qui s’intercale entre PICOLAB et l’adaptateur potentiométrique.

Les lignes A2 et A3 sont munies de petits embouts de type HE14 de genre respectivement mâle et femelle pour se brancher directement sur les connecteurs de PICOLAB. (Voir la Fig.139)
Le connecteur A s’insère directement dans la « prise » mâle d’Arduino pour brancher le potentiomètre. En B on insère en gigogne le module potentiométrique.

Sur la Fig.138 le module supportant le potentiomètre et le BUZZER est mis en évidence par le surlignage de couleur violette. Le tout petit circuit est enfiché sur le connecteur  du circuit imprimé principal.
Passer son temps à brancher et débrancher des fils ou des petits circuits à rapidement montré une faiblesse dans la

qualité opérationnelle de notre laboratoire. Chaque fois que l’on doit brancher un fil, il faut consulter la notice d’application pour repérer l’utilité de chaque broche. La solution pour contourner ce manque de convivialité est pourtant évidente. Il suffit d’imprimer des petites étiquettes et de les coller sur les ensembles concernés. La Fig.139 montre PICOLAB avec les fils des deux liaisons en place sur les connecteurs HE14.
Sur la photographie de la Fig.140 la petite étiquette jaune définit l’utilité de chaque « borne » et complète avantageusement le petit accessoire de branchement du circuit électrique dédié à la mesure des tensions alternatives. Du reste on peut constater sur la Fig.141 que tous les connecteurs latéraux de PICOLAB bénéficient d’un traitement analogue. Chacun possède son étiquette informative. La Fig.142 montre que parfois l’étiquette est un peu décalée par rapport à l’ouverture latérale concernée, mais c’est vraiment sans inconvénient, c’est la présence de l’information qui importe. Sur toutes ces images, PICOLAB est toujours sans son couvercle et réuni à Arduino par le cordon ombilical pour téléverser les programmes.

L’intégration du BÉTAmètre dans le programme complet.

Constatant que le démonstrateur présente une taille de programme non négligeable, rien ne prouve qu’ajouter cette fonction à PICOLAB sera réellement possible. Avec toutes les améliorations que l’on a apportées durant ce didacticiel, on sent confusément que l’on a déjà poussé le bouchon un peu loin. La seule façon de savoir si l’on peut encore faire entrer un éléphant dans une boite d’allumettes, c’est d’essayer. Dans cette optique, on se risque une fois encore à créer un programme de plus par clonage de l’ancien qui accepte de fonctionner correctement.
Puis, dans P23_Complet_avec_ajout_du_BETAMETRE.ino on transporte les séquences « bétamétriques ». Partant d’un ADN qui occupait 96% de la place disponible, la tentative d’insérer intégralement les lignes propres à de P22_BETAmetre_NPN.ino dans le dernier programme complet, amène le compilateur à refuser de créer le code objet sous prétexte que l’on dépasse nettement le 100%.

– Il est un peu mesquin ce compilo !

Acculés contre le mur, nous n’avons plus tellement de choix. Soit on abdique et l’on oublie la fonction supplémentaire dans le MENU, soit on gamberge encore un peu et l’on arrive à dégager encore de la place. Vu que le tout petit circuit imprimé dédié au BÉTAmètre trône orgueilleusement sur le bureau, j’ai franchement la grogne d’en rester là et de ne pas pouvoir m’en servir.

– Bringuestormingue les copain, il nous faut encore forcer un peu le destin !

Une première optimisation consiste à utiliser une procédure void Afficher_Uegal() qui invoquée trois fois économise pas mal d’octets. On introduit ensuite la procédure void Affiche_DeltaUegal(). Ces modifications confinent à du gagne petit, mais à ce stade on passe à une occupation de 100% par le programme qui se gave de 32254 octet sur les 32256 possibles. Coté rentabilité il sera difficile de battre ce record. Les mémoires dynamiques ne sont occupées qu’à 40%.
On téléverse les octets et … PAFFFF : Collision de PILE !
OK, on se doutait un peu que l’ATmega328 n’allait pas se laisser bousculer aussi facilement.

– Remue-méninges en vrac les amis, faut cogiter un max maintenant.

On créé void Efface_cadre_jaune() qui fait économiser quatre octets. Nif nif nif, c’est pas beaucoup. Surtout on remplace le texte affiché « Ib ou placer un NPN » par « Ib / placer NPN » qui réduit encore le programme de quatre octets et surtout diminue les variables dynamiques de quatre emplacements.

WOUOUOUAAAAOUOUOUOU … le programme accepte de fonctionne correctement, l’ajout du BÉTAmètre est donc possible.

Attention, il ne faut surtout pas crier victoire, car nous sommes sur le fil du rasoir, l’épée est au dessus de notre tête. Il faut impérativement vérifier la marge de sécurité. Il est de loin préférable de renoncer à une fonction de plus, que d’accepter le risque d’avoir un programme instable. Pour pouvoir intégrer la petite séquence qui mesure la « distance » entre la PILE et le TAS il nous faut encore gagner de la place. Nous savons que diminuer les bavardages constitue une bonne « variable d’ajustement ». Le titre « BETAMETRE. » devient « Gain NPN. » avec double utilisation de « NPN ». Surtout, on « dégraisse » sérieusement le programme en abandonnant les affichages « MARCHE » et « ARRET » dans la fonction chronomètre, car on peut facilement s’en passer. Ce petit détail réduit le programme de 148 octets, il ne fait plus que 99% du total admissible. On gagne également douze emplacements en mémoire dynamique. La marge de sécurité devient raisonnable.
Le programme définitif  P23_Complet_avec_ajout_du_BETAMETRE.ino contient en remarques les séquences qui permettent d’effectuer la vérification expliquée dans le chapitre Approche « évidente » pour gagner de la place en RAM dynamique. Quand on les valide,  le programme enfle et passe de 32096 octets à 32198. Dans ces conditions plus extrêmes que sur la version normale, le programme annonce une « distance anti-collision » de 203 octets. On peut sereinement repasser les séquences de vérification en remarques. La marge de sécurité permet de croire raisonnablement et avec une forte probabilité à la stabilité du programme.
Ce dernier occupe 99% de l’espace vital, autant dire que l’on n’a pas gaspillé tellement de place disponible. On peut considérer que PICOLAB est à son terme, et l’agréable moment de débrancher le cordon ombilical et de lui rendre une totale autonomie est arrivé. Ce didacticiel nous aura montré à quel point l’optimisation des données et du programme permet d’étendre de façon significative les possibilités d’un microcontrôleur. C’est génial non ?

Servant l’introduction à l’optimisation systématique des logiciels, dans la page d’accueil de ce didacticiel, il a souligné le fait que programmer finit par ressembler à une prise de drogue, une activité intellectuelle addictive par nature. Tous les informaticiens un jour ou l’autre le ressentent. Pour ne pas verser dans la « démence », ce seuil où le codage devient nerveux et fébrile, la consommation de café boulimique, la mauvaise humeur envers notre entourage injuste, il importe en permanence de rester vigilent. Dès que modifier un source commence à déborder sérieusement du loisir délassant, il devient urgent de prendre un peu de recul, et surtout de relativiser.

À un moment ou à un autre, il faut décider, et de façon péremptoire et non négociable, que le logiciel est abouti et que le couvercle peut être refermé. On débranche le cordon ombilical qui relie PICOLAB à la carte Arduino Uno qui permet les téléversements sur site. On referme le coffret, et l’on savoure intensément ce sentiment de devoir accompli, ayant investi de nombreux efforts pour concrétiser avec succès un projet qui nous tenait à cœur.
PICOLAB en l’état est une véritable petite merveille. Il a tout d’un grand. Alors il ne reste plus qu’à lui créer un coffret confortable pour le ranger précieusement avec tous ses accessoires. Il sera disponible à tout moment pour nous seconder dans nos activités électroniques ou informatiques. C’est un auxiliaire précieux qui vous deviendra rapidement indispensable. Si vous vous êtes contentés d’avoir directement programmé le bootloader et le programme complet sans lire les didacticiels, vous serez déjà possesseurs d’un superbe appareil polyvalent répondant à vos besoins de mesurages les plus divers. Si de plus vous avez parcouru les didacticiels, il est probable que vous avez considérablement étendu vos savoir-faires en programmation avec l’IDE. C’est à mon sens la richesse la plus importante que vous apportera cet ensemble, où l’acquisition du matériel n’est pas forcément la source principale de notre motivation.

Avouons que ce dernier cheminement n’était presque qu’un prétexte pour ne pas que notre belle aventure ne soit achevée. Un moyen de prolonger encore un peu nos explorations logicielles. Une façon comme une autre de pousser encore plus loin le butoir. Vérifier que les limites étant atteintes, on peut encore gagner du terrain. Quelques octets ici et là, et l’on dispose encore d’assez de place pour loger un gros bagage binaire qui au départ n’avait pas la place suffisante pour se glisser dans le programme complet. Le programme occupe 99% de la place maximale disponible, on ne peut pas nous accuser de gaspillage. Toute l’EEPROM est occupée, plus un seul octet de disponible, coté optimisation on atteint un sommet. Quand à la mémoire dynamique, avec seulement 12 octets de marge avant la collision de PILE, le logiciel initial frisait la correctionnelle. Les améliorations ont non seulement augmenté la puissance de notre appareil, mais surtout nous avons stabilisé son fonctionnement.

Optimiser un logiciel est une habitude qui tend à se perdre sur les ordinateurs de bureau actuels, sous prétexte qu’ils disposent d’autant de mémoire que l’on veut et que tous les ans il faut presque changer d’unités pour expliciter leur taille. C’est fondamentalement pour masquer des réalités commerciales.
Il faut vendre au plus vite, et moins on consomme de temps en développement, plus le produit sera rentable. Par contre, quand on développe sur microcontrôleur, le contexte est tout autre. Gagner des octets devrait être un réflexe de Pavlov. Outre le fait que le Kilo Octet reste encore largement suffisant pour exprimer la place disponible, le gain de code se traduit aussi par un programme qui déroule plus rapidement ses instructions. À 16MHz de fréquence d’horloge, nous avons vu dans les lignes qui précèdent, que minimiser des temps de traitement est un problème auquel nous sommes relativement souvent confrontés. Il est probable que les quelques méthodes rencontrées dans les chemins explorés dans ce document vous seront certainement utiles plus tard.

Pour conclure, je suis persuadé qu’à certains aspects un programme est quelques parts une œuvre d’art. La pureté de son architecture, l’intelligence des ses procédures, l’optimisation en taille ou en rapidité de traitement sont aussi belles que les lumières ou les visages d’un magnifique tableau. Alors soyez des poètes, le binaire ne présente pas que deux états quoi que l’on puisse affirmer …

>>> Page suivante.