Supérieur en agrément d’utilisation, un bouton rotatif est bien plus adapté pour la gestion de menus qu’un clavier avec divers touches consacrées « aux déplacements » dans les textes des items. Dans ce type d’application confinée dans un boitier de petites dimensions, j’intègre régulièrement ce type de capteurs. Facile à se procurer sur la toile, il suffit de proposer « encodeur rotatif KY-040 » à un quelconque moteur de recherche pour obtenir une foison de références. Le KY-40 est un codeur sans butée à 20 points par tour pourvu d’un « bouton poussoir » par appui sur la tige de commande centrale. La sortie se fait par deux lignes pilotées par des capteurs de type codage Gray. (Algorithmes Utilisateur n°7 par exemple.)
La Fig.6 donne le schéma des branchements à réaliser sur Arduino NANO pour gérer les menus dans notre projet.
Fonctionnement :
Concrètement les trois sorties sont alimentées au + 5 Vcc par des résistances de 10 kΩ. La sortie SW est celle de l’inverseur piloté par appui sur la tige du rotor. Les deux sorties CLK et DT sont en réalité deux sorties classiques avec déphasage de 90° souvent nommées A et B pour ce type de capteur. Le déphasage de 90° électriques des signaux CLK et DT permet de déterminer le sens de rotation. (Voir Fig.7) Le capteur est traité par interruptions.
Mise en Å“uvre de l’encodeur KY-040.
Disponibles à des tarifs très variables dans le commerce en ligne, la qualité de ces composants est également fonction de l’investissement financier. Aussi, j’ai approvisionné des exemplaires dont le coût est très faible, mais de très médiocre qualité pour les contacts électriques du codeur. Il en résulte des « faux contacts » qui engendrent des « indexages » complètement aléatoires. Un moyen radical de parer ce problème et peu couteux consiste à ajouter un condensateur C de 100nF entre A, B et GND. Si le composant que vous avez approvisionné donne pleine satisfaction, souder ces deux condensateurs sur le circuit ne sera pas utile. Par contre, si sur les deux programmes de validation P05_Indexer_dans_un_MENU.ino et P05_Indexer_un_Emplacement.ino le déplacement de l’index est illogique, alors les deux condensateurs C de la Fig.6 seront indispensables.
Avec P05_Indexer_dans_un_MENU.ino on teste la faculté d’indexer un MENU de BASE. Ce petit logiciel ajoute à la gestion de l’afficheur OLED celle du capteur rotatif utilisé en interruptions. Ce programme met en place le MENU de BASE et les aiguillages pour l’indexation des items. Si on clique sur le Bouton Poussoir Central il y a validation de l’item indexé. Dans la suite Bouton Poussoir Central sera remplacé par les initiales B.P.C. Tant que le B.P.C. est appuyé, la LED d’arduino s’illumine. Le sous-menu activé ouvre un écran noir avec sa nature. Cliquer à nouveau sur le B.P.C. ramène au MENU de BASE. Le Menu BARILLET est en place. Valider l’Item engendre un BIP sonore et ramène au MENU de BASE.
Téléverser P06_Indexer_dans_un_Emplacement.ino va préparer l’avenir en tenant compte de la faible définition de l’afficheur. Ce croquis visualise comme montré sur la Fig.10 le contenu fictif de l’EEPROM qui ne contiendra que dix algorithmes au maximum. Cette limitation est adoptée pour deux raisons. La première vient du fait qu’afficher plus d’emplacements simultanément sur l’écran imposerait l’utilisation d’une police de caractères bien plus petite, la lisibilité deviendrait médiocre. (Et votre narrateur a dépassé les 74 printemps !)
La deuxième raison est issue de l’expérience acquise au cours de mes nombreux projets. L’utilisation d’un afficher graphique impose des méthodes extrêmement boulimiques en octets de programme. Pour un projet comme celui-ci, il est déjà évident qu’il va falloir optimiser à outrance.
Stratégie d’utilisation de l’EEPROM.
Directement influencée par les choix effectués pour l’élaboration de la machine élémentaire, les 10 algorithmes envisagés à ce stade des études seront logés en « haut » de la mémoire non volatile EEPROM. Juste « en dessous » on réservera la place pour une configuration de BARILLET. On se réserve la 
possibilité de charger un algorithme sur RESET et une configuration de BARILLET, qui comme pour la machine élémentaire, s’octroient les trois derniers octets. On ne s’interdit pas la possibilité de sauvegarder un algorithme étendu, comme montré sur la Fig.11, mais ce ne sera possible que si les procédures indispensables ne saturent pas l’espace disponible pour le programme. Comme l’afficheur consomme un espace programme sur l’ATmega328 considérable, il va falloir optimiser à outrance, contrairement à ce qui avait été fait pour la machine élémentaire. Aussi, l’un des moyens le plus efficace pour « tasser » le code consiste à loger les textes affichés en EEPROM. Nous allons donc réserver le début de l’EEPROM dans ce but. La suite du développement orientera les solutions adoptées et influencera, ça on le sait, les performances au sens général de la petite machine électronique. Le programme P06_Indexer_dans_un_Emplacement.ino intègre le codeur rotatif et ajoute l’indexation des dix fichiers potentiels. Si on Clique sur le B.P.C. l’index pointant un fichier vide représenté par « — » il y a génération d’un BIP d’alerte. Cliquer sur une position occupée indiquée par la référence numérique de l’algorithme ne provoque aucune action. Tant que le B.P.C. est appuyé, la LED d’arduino sur D13 s’illumine.
La gestion des divers menus.
Quel que soit le système étudié, la 
convivialité d’utilisation et la qualité opérationnelle seront directement influencées par la facilité de « se déplacer » dans les divers menus. Aussi, avant de mettre en place les fonctions qui effectuent les traitements idoines, Arduino\P07_Noyau_de_base.ino architecture le programme squelette et émule les menus principaux. Ce démonstrateur intègre l’affichage de P05 et celui du contenu de l’EEPROM testé dans P06. Dans l’affichage du contenu de l’EEPROM on indexe un fichier. Quand on clique sur le B.P.C, si cette position est vide il y a retour au MENU de BASE avec génération d’un BIP d’avertissement. Si l’emplacement est occupé il y a ouverture du Menu EEPROM. (Voir la Fig.12) Le BP central déclenche la fonction qui dans ce croquis n’effectue aucun traitement. Toutefois elle est présente, et il suffit de « remplir » les corps des procédure au fur et à mesure que sera développé le programme. 
Le menu de la Fig.13 est relatif à la gestion du BARILLET. Chaque clic sur l’un des dix items génère un BIP sonore suivi d’un retour au MENU de BASE. La Fig.14 montre le Menu PROGRAMME. Comportement analogue à celui du menu précédent, sauf que la Fuite ne génère pas le BIP sonore. L’ossature du logiciel d’exploitation est en place. La compilation précise que le code binaire consomme déjà 10348 octets soit 33% de la place totale disponible pour loger le programme. C’est assez inquiétant, car on ne fait que choisir des actions, et encore pas toutes. (Les OPTIONS ne sont pas encore agencées car elles seront fonction de la place restant disponible pour le code.) Les procédures de traitement sont vides. Les traitements de l’algorithme ne sont pas implémentés. Bref, l’avenir est problématique, et il ne sera peut être pas possible de faire tout ce qui est implémenté sur la Machine Élémentaire. Il est tout à fait possible qu’il soit nécessaire de renoncer à du graphique par exemple. Bref, le but de tous ces outils consiste à valider les approches, les choix, et surtout d’optimiser le « source » au fur et à mesure. 
C’est d’autant plus facile, que l’on ne se préoccupe que de sections bien déterminées du logiciel.
Passage des textes en EEPROM.
Première étape avant de pouvoir utiliser les textes, il faut les inscrire dans la mémoire non volatile du microcontrôleur. Dans ce but, on téléverse P00_Initialiser_EEPROM.ino qui n’avait pas été utilisé. Comme suggéré dans le programme à la ligne 70 on valide la remarque pour remplir l’EEPROM de « FF » faciles à repérer sur le listage. Puis on active le programme qui affiche les chaînes de textes actuellement inscrits. La Fig.15 liste ceux qui sont présents à ce stade du développement avec leurs adresses. Ce croquis installe également une configuration BARILLET et dix algorithmes pour pouvoir continuer le développement et disposer de données à traiter. La Fig.16 représenterait ce que montrerait dans ces conditions le programme de 
la Machine Élémentaire. En vert, les cinq emplacements qui n’existent plus. Concrètement, le n°5 devient une zone de 56 octets placée juste avant les algorithmes. Les deux références 254 et 255 n’étaient pas utilisables pour les programmes, maintenant elles ne sont plus utiles et peuvent être « récupérées ». La Fig.17 présente l’implantation actuelle en EEPROM. La zone jaune sera affectée à un algorithme pour Machine ÉTENDUE s’il est possible d’ajouter cette option. La zone blanche correspond à de la place pour loger encore du texte. En vert se prouve l’emplacement réservé pour loger une configuration de BARILLET. Enfin toute la zone bleue est occupée par les dix algorithmes potentiels avec en violet tout en haut le la mémoire les trois octets de gestion des rechargements durant le RESET. La mémoire EEPROM étant gavée de toutes ces données, il faut maintenant téléverser P08_Textes_en_EEPROM.ino le démonstrateur strictement identique à P07 dans lequel, seuls les affichages qui étaient directement dans le programme sont maintenant puisés en EEPROM. On compile le code source, on le téléverse sur la carte ARDUINO, et l’afficheur OLED avec le codeur rotatif doivent présenter un comportement strictement identique à celui de P07. On note que la taille du logiciel passe de 10348 octets à 10422 soit une taille plus importante de 74 octets. Tout ce travail semble donc totalement négatif. C’est une
fausse impression, car le code a été « plombé » des méthodes de EEPROM.h qui de toute façon sera indispensable pour échanger des données avec la mémoire non volatile. Il convient maintenant de continuer à définir les stratégies à privilégier et de compléter la structure matérielle et la structure logicielle.
La suite est ici.
