La fin d’un long cheminement programmacoustique.
Certainement pas ! Il faut bien l’avouer, pour beaucoup d’entre nous cette saga n’a jamais eu pour but fondamental la possession d’un petit laboratoire ou d’un générateur « universel ». Ce n’est en réalité qu’un bénéfice « collatéral ». Le facteur déclenchant reste principalement le plaisir de la programmation, l’art de soumettre à ce fidèle ATmega328 des instructions en espérant que le résultat observé correspondra à ce qui était prévu. Le plaisir subtil de faire « de ses mains » un appareil sur mesure. Certains se détendent en alignant des mots croisés, d’autres tortillent des grilles de Sudoku. Ce n’est absolument pas pour posséder une matrice de lettres ou de chiffres qui sera exposée dans un cadre en or. Pour notre part, c’est dans l’algorithmique que nous prenons notre plaisir, quand après bien des « tourments cérébraux », la vérité d’une instruction absconde finit par révéler ses secrets. Aussi, si ce chapitre va marquer la fin d’un cheminement commun, il ne signifie en rien la clôture définitive de nos « cogitations ». Chacun avec sa personnalité va reprendre « dans son coin » les lignes de code pour enrichir le programme actuel. C’est le suc intrinsèque du plaisir que l’on trouve à programmer.
OUF, une fois avoir avec fébrilité intégré le code source de l’ENREGISTREUR à deux voies dans P35_COMPLET_avec_ENREGISTREUR.ino, l’occupation mémoire par le programme atteint 87% car cette dernière fonction gloutonne ses 3142 octets. C’est la plus boulimique de toutes celles qui figurent au MENU. On peut considérer que le scandale a été évité et que l’ATmega328 est correctement rentabilisé. Nous sortons de l’impasse et le moral est revenu.
Emportés par notre enthousiasme, les 4050 octets encore disponibles pour loger du programme nous incitent fortement à envisager l’ajout d’une nouvelle fonction dans le MENU de base. Et bien ce ne sera pas l’option qui sera privilégiée dans ces lignes et ce pour deux raisons :
• La liste actuelle des fonctions disponibles couvre bien plus que nos besoins estimés initialement,
• Dans l’hypothèse forte d’améliorations futures de notre appareil, il semble plus sage de ne pas dilapider les ressources, nos idées futures pourront ainsi
x s’envisager plus sereinement. Par exemple ajouter un item dans le MENU que l’offre actuelle ne couvre pas, ajouter des traitements relatifs à des capteurs
x spécifiques employés par l’enregistreur numérique …
Pour ménager cette réserve de « possibilités », dans ce chapitre nous n’allons aborder que deux ou trois petites « bricoles » pour démontrer le plus incontestable que procure un appareil de mesures programmable. Ces petites améliorations sont issues de la pratique car on peut toujours « faire mieux ».
Améliorer la convivialité de l’enregistreur graphique.
L’ensemble des écrans textuels, graphiques, les divers protocoles de mise en œuvre du générateur de signaux résultent de choix personnels globalement arbitraires. Ils sont forcément influencés par une logique consciente ou inconsciente, sachant que chacun a la sienne. Parfois, cette logique découle de critères d’homogénéité informatiques, mais pas forcément pertinents relativement à l’exploitation. Ce n’est qu’en manipulations que l’on découvre des faiblesses, ou des améliorations possibles. En particulier, lors des manipulations de validation, l’ENREGISTREUR a révélé deux détails incitant à reprendre la copie. Le premier concerne :
Faire clignoter régulièrement la LED jaune en mode VEILLE.
Pour éviter les effets d’avalanche indésirables, toutes les petites améliorations apportées à notre logiciel complet durant ce chapitre seront ajoutées dans le croquis P36_COMPLET_avec_perfectionnements.ino, sans rien changer aux autres programmes.
Lors des longues expérimentations avec l’ENREGISTREUR, en particulier pour vérifier que les échantillonnages journaliers ou par semaine respectent les délais calculés, l’économie d’énergie et la préservation de l’écran OLED invitent fortement à passer en mode VEILLE. Dans ce cas, la LED jaune d’état du système était allumée. Cet état statique ne rend pas compte de la « vie » du programme. Aussi, la première modification apportée au croquis consiste à l’éclairer durant 0,1S à intervalles réguliers. La durée entre deux impulsions lumineuses avoisine les 1,6S sans recherche de précision particulière. Du reste si vous désirez en changer la cadence, il suffira de modifier la valeur de la constante dans le test de l’instruction : if (Frequence_desiree == 6000)
Par ailleurs, à l’usage on réalise que ce clignotement est bien utile hors mode VEILLE, tout particulièrement lorsque les durées entre deux échantillonnages sont notables. Soumettre ces petites modifications au compilateur comptabilisent une consommation de 84 octets dans la mémoire de programme et laisse inchangé l’espace pour les variables dynamiques. À ce tarif, on peut envisager sans hésiter une foule d’améliorations diverses.
Changer de LED clignotante lors du passage en mode VEILLE.
C’est bien plus qu’une amélioration, car une ambigüité dans un protocole d’utilisation est absolument « intolérable ». Quand on clique sur le bouton central du capteur rotatif, on recycle en permutation circulaire de l’affichage « épuré » à celui avec les lignes pointillées horizontales. Puis, on fait afficher les valeurs des paramètres d’enregistrement. Le programme suspend alors son évolution pour nous laisser le temps de lire les diverses données. Comme il attend un clic sur l’un des deux boutons du clavier, dans l’état actuel du logiciel, c’est la LED clavier qui clignote, incitant à cliquer sur FC+ court. À cette phase du fonctionnement, cliquer sur ce bouton n’aura pas d’influence, le programme passe en enregistrement écran noir. Mais il « prévient » l’opérateur. En faisant clignoter la LED jaune d’état, on sera moins influencé à cliquer sur le clavier pour sortir de l’écran noir, alors qu’à ce stade il faudra impérativement cliquer sur le bouton central du capteur rotatif. Faire clignoter la LED jaune d’état ne consomme que 42 octets, il ne faut donc pas s’en priver.
Augmenter les possibilités du traceur X/Y.
Lorque l’on « s’amuse » avec le traceur X/Y en affichage de courbes en « mode Lissajous », la fréquence de référence sinusoïdale fournie à 150Hz par l’AD9850 est bien utile. (Signal par défaut.) On se rend rapidement compte que si l’on pouvait la modifier à convenance dans une certaine plage, l’appareil serait encore plus agréable à mettre en œuvre. Dans cette optique, seule l’expérimentation peut nous aider à définir la plage de fréquences qu’il conviendra d’agencer pour rendre cette application « parfaitement opérationnelle ». Suite à de nombreuses manipulations, la fourchette comprise entre 25Hz et 250Hz semble un bon compromis. Ces valeurs sont influencées par l’hypothèse que la déviation horizontale X est reliée à une source sinusoïdale de 50Hz, par exemple la sortie d’un petit transformateur secteur, et la déviation verticale Y directement branchée au signal issu de l’une des deux sorties SINUS de l’AD9850. Pour ne pas « encombrer » les manipulations du TRACEUR, l’option qui permettait un affichage sans effacement a été abandonnée, car au final elle ne présente que peu d’intérêt. En utilisant le B.P. FC+ court on ouvre maintenant l’option de choix de la fréquence de référence. Durant cette phase, c’est la tension positive appliquée sur A4 l’une des deux entrées de F.E. qui permet de calculer la valeur de la fréquence qui sera générée. Cette dernière est affichée en boucle jusqu’à cliquer sur l’un des deux B.P. du clavier. (Clic court ou clic long indifférent.) La valeur de la fréquence varie linéairement quand la tension évolue entre « presque zéro » et s’approche du +5Vcc. Un effet de seuil proche de ces valeurs extrêmes engendre un comportement émulant deux « butées » logicielles respectivement de 25Hz et 250Hz. Ces fréquences sont alors générées de façon précises et s’accommodent bien à l’observation des
déphasages par rapport à la tension du secteur 220V~. Ces deux « étalons » facilitent par exemple le calibrage d’oscillateurs en utilisant la technique des figures de Lissajous. On peut à notre guise, comme visible sur la Fig.109, soit brancher l’entrée A4 sur les broches HE14 voisines GND et +5V, soit sur le curseur d’un quelconque potentiomètre dont les deux extrémités seraient reliées à GND et +5V. Pour la valeur de cet élément ajustable P, ne pas descendre en dessous de 4,7kΩ pour qu’il ne prélève sur l’alimentation de PICOSYNTHÉ qu’un faible courant. Par contre on peut augmenter strictement sans inconvénient sa valeur jusqu‘à 50kΩ. Les modifications apportées à P36_COMPLET_avec_perfectionnements.ino pour cette petite évolution se résument à quatre octets prélevés dans la RAM des variables dynamiques, et à 336 octets dans la mémoire de programme. C’est nettement plus que pour les deux broutilles précédentes, mais pouvoir « s’amuser » un peu avec les expérimentations proposées dans le chapitre Réalisation du générateur reste tout à fait raisonnable. En effet, ce document propose dans ses développements, après la description matérielle, quelques manipulations simples n’exigeant que peu de composants supplémentaires ou quelques fils électriques.
Allumer la LED d’état quand un clic devient long.
Vraiment pas de quoi déranger le ministre des programmes d’Arduino, on reste dans du dérisoirement élémentaire. La modification proposée dans ce chapitre est plus un petit luxe qu’autre chose. L’idée consiste à allumer la LED jaune d’état dès que l’enfoncement de l’un des deux boutons du clavier est considéré par sa durée comme un clic long. Si vous attendez un tel événement, vous pouvez alors libérer la touche FC+ ou FC- dès que la LED s’illumine. Ce n’est pas transcendant je vous l’accorde, mais comme cette miette informatique n’ajoute que 40 octets au programme, ce serait un peu dommage de ne pas l’ajouter au code source.
Autres petits détails peu couteux.
Notons au passage que pour optimiser l’utilisation « en standard » du signal SINUS sur l’entrée A2 pour travailler en « Lissajous » avec le TRACEUR X/Y, le gain vertical est désormais de x4 et le décalage vers le haut d’une position. Ainsi par défaut ces valeurs centrent la courbe et en donnent une amplitude idéale. Encore un petit ajustement du programme pour en améliorer l’agrément, et gratuit en terme d’octets car on ne fait que modifier des constantes.
Pour la modique somme de huit octets de programme, on s’offre la possibilité de générer une impulsion de SYNchronisation externe sur D10 chaque fois que l’on déclenche une séquence de code ou une combinaison de notes musicales. Il suffisait d’ajouter pour chaque fonction l’appel à la procédure TOP_SYN(); au bon endroit et le tour est joué. Il suffisait d’y penser, ce petit plus insignifiant sera parfois bien apprécié lors d’analyses oscilloscopiques sur des systèmes en cours d’étude.
Toujours dans la boutique des options à faible consommation d’octets, pour la modique somme de 34 emplacements occupés en mémoire de programme, on change un peu le comportement du Générateur de CODE sélectif en mode Vérification. Maintenant, quand le curseur pointe « les informations du bas », la rotation fait changer Num comme avant, mais la tonalité correspondante est générée en permanence. Ce comportement favorise l’ajustement de la fréquence de détection d’une tonalité individuelle. Le bouton FC- court stoppe la génération continue, et comme avant il déclenche une génération durant la temporisation programmée. Cette configuration privilégie alors l’analyse des transitoires de commutation. Pour si peu d’augmentation de taille du logiciel on a étendu la combinatoire des possibilités d’exploitation. Vive la logique programmable …
Pour dix octets de plus, on trouve en promotion sur la même étagère cette modification de comportement pour le CODE sélectif à notes musicales en mode Vérification. Une bonne idée peut avoir des effets « boule de neige » et je ne doute pas un instant, qu’au cours des manipulations avec votre PICOSYNTHÉ vous rencontrerez des cas particuliers qui vous inciteront à reprendre le collier. C’est d’autant plus facile à faire qu’une carte Arduino vous permet à l’aide le la limande de raccordement sur la DB9, de téléverser le croquis amélioré sans avoir à ouvrir le couvercle.
Conclusion, perspectives …
S’obstiner à rentabiliser le microcontrôleur à outrance en occupant tout l’espace mémoire disponible serait maladif. Autant monopoliser une telle technologie pour ne traiter qu’une lampe clignotante peut sembler pauvre, encore que, (Une platine Arduino a été employée dans une application réelle uniquement pour éclairer l’intérieur d’une maquette de navire. Dans cette application qui ne fait que faire scintiller des LED, ce choix est parfaitement pertinent. Alors évitons de se montrer péremptoire …) autant vouloir absolument chercher la saturation ne serait pas très malin.
Il reste actuellement 3496 octets pour le programme, soit 11% de la mémoire réservée au logiciel. Quand aux variables dynamiques, 69% de l’espace dédié en RAM est encore disponible. Autant dire que le risque de collision entre la PILE et le TAS n’est pas à craindre.
L’ATmega328 est bien exploité, tout en nous ménageant de bonnes perspectives pour d’éventuelles modification. Le développement du programme s’achèvera sur ces lignes, mais pas notre cheminement. Retrouvons-nous dans les derniers chapitres de Réalisation du générateur, car il nous reste encore quelques petits sentiers originaux et amusants à parcourir.
