03) Configuration matérielle et scénario envisagés.

À ce stade du développement, il faut définir la structure du clavier qui servira à l’interface HOMME/MACHINE. Plus il sera « discret », et meilleure sera la mise en Å“uvre de la machine. Une bonne expérience sur ce type de réalisations de faible encombrement m’a convaincu qu’associer au codeur rotatif un clavier à cinq touches est généralement suffisant. Sans préjuger des proportions et des dimensions, la Fig.18 donne une idée de ce que pourrait être l’appareil

quand il sera terminé. Étant droitier, je privilégie la position du capteur rotatif à droite de l’afficheur OLED. Une diode électroluminescente avec trois couleurs fondamentales sera largement suffisante pour informer l’opérateur de certains événements particuliers. Quand au clavier, il reste à définir ses protocoles d’utilisation. Par exemple G et D peuvent choisir des sens de rotation, B, 0 et 1 imposer une écriture. Ou les quatre BP extérieurs servent à se déplacer dans une grille, et le codeur rotatif à changer la valeur de la cellule pointée. Ces façons d’utiliser le clavier élémentaire seront choisir par expérimentation pour aboutir à des protocoles conviviaux et une machine à forte qualité opérationnelle.

L’agencement matériel.

Inutile de redécouvrir le monde. Le schéma électrique du clavier montré en Fig.19 reprend intégralement un circuit totalement analogue utilisé sur d’autres projets qui sont du reste en ligne sur ROBOT MAKER. Les cinq boutons poussoir seront de taille à déterminer, le choix des
éléments étant probablement influencé par leur disponibilité dans les tiroirs. L’approvisionnement sera d’autant plus aisé que je m’impose des types à simple fermeture de contact. Ce sont de loin les plus courants et existent à profusion sur les étagères virtuelles du commerce en ligne.
Le clavier à cinq touches.
Compte tenu du faible nombre de touches, il est plus rentable de monopoliser deux entrées analogiques que d’effectuer un multiplexage. La Fig.19 présente la solution retenue dans laquelle les valeurs des résistances sont choisies pour minimiser le courant consommé, optimiser les zones de décision et offrir une immunité satisfaisante aux parasites. Les valeurs des résistances sont choisies de façon
à avoir des écarts de tension « homogènes » en fonction des boutons poussoir activés dans la plage définie par la valeur à vide tout en adoptant des références de composants très courantes faciles à approvisionner. Le tableau de la Fig.20 indique les valeurs obtenues sur la ligne à trois boutons alors que celui de la Fig.21 est relatif à l’entrée A1. .
ATTENTION : Les valeurs indiquées ne sont vraies que si la tension fait environ 4,9V, valeur de la sortie 5V la carte étant alimentée par une ligne USB. La Fig.22 et la Fig.23 présentent l’étalement obtenu en fonction de la numérisation effectuée par les convertisseur de l’ATmega328. On y trouve les seuils de comparaison pour déterminer quel est le bouton poussoir utilisé. Pour optimiser le filtrage des parasites, les seuils de comparaison pour déterminer le bouton poussoir actionné sont placés à exactement la moyenne entre les valeurs typiques issues des CAN. (CAN : Conversion Analogique Numérique.)
La diode électroluminescente.
Composant ultra courant, la LED triple à cathode commune est ultra courante et très populaire. Il existe diverses références dont les rendements peuvent varier. Celle approvisionnée donne de très bons résultats avec une résistance de limitation commune de 10kΩ. Non seulement elles présentent une très bonne luminosité avec un courant très faible, et surtout, la clarté est analogue sur les trois couleurs fondamentales. On peut alors n’introduire qu’une seule résistance de limitation de courant R1 entre cathodes et GND. Cet agencement ne convient que si une seule couleur est utilisée à la fois. Dans le cas contraire, c’est la couleur qui engendre la chute de tension aux bornes la plus faible qui s’allumera à l’exclusion des autres. Si on désire allumer deux ou trois LEDs simultanément, il faut les piloter conformément à la Fig.25 chaque ligne étant indépendante. Par exemple rouge et bleu donne du violet, bleu et vert produit du cyan, rouge et vert ressemble à du jaune. Les trois simultanément produisent une sorte de blanc moiré. On peut aussi produire des effets particuliers. par exemple on allume bleu et on fait clignoter rouge etc. Comme pour notre application nous n’avons pas encore déterminé quel sera l’usage final, lors du développement effectué par des branchements provisoires sur des plaques à essais on adopte le schéma de la Fig.25 quitte à simplifier comme sur la Fig.24 si les LEDs ne sont utilisées qu’indépendamment les unes des autres.

L’agencement logiciel.

L’étape qui suit naturellement pour la détermination du matériel consiste à mettre en place le code pour gérer les nouveaux composants réunis au microcontrôleur. Et aussi prendre en compte les données logées en EEPROM, en particulier ne plus simuler comme sur la Fig.10 et effectuer une lecture réelle du haut de la mémoire non volatile pour en déduire le contenu. C’est précisément l’objet de P09_Noyau_Complet.ino que l’on téléverse sur la carte NANO pour en observer le comportement et surtout vérifier les routines de servitude. Typique d’un assemblage électrique provisoire, la Fig.26 présente ce qui sera probablement la version définitive du matériel. Les fils électriques qui relient les composants sont tellement nombreux, que la Carte Arduino NANO insérée sur une plaque à essais est pratiquement invisible masquée sous le fatras des connections électriques volantes. On comprend que la réalisation d’un petit circuit imprimé adapté sera plus que salutaire. Du reste, pour pouvoir effectuer sans trop se contorsionner, le mini bouton de RESET de la carte Arduino a été doublé par un élément extérieur bien dégagé de ce méli-mélo inextricable. Ce tutoriel s’adresse à toutes celles et tous ceux qui désirent concrétiser une petite Machine de Turing autonome sans pour autant avoir du temps à consacrer au plaisir la programmation. « Oubliez » dans ce cas ce qui suit, car destiné aux internautes qui utilisent régulièrement l’IDE pour leurs propres projets :
Quand nous engageons régulièrement nos loisirs dans le développement de petites applications à microcontrôleurs, on finit souvent par employer fréquemment des périphériques courants. La concrétisation du projet peut prendre plusieurs semaines. Aussi, il ne faut pas hésiter à s’entourer de petits accessoires qui serviront régulièrement et nous assisteront tout au long de nos expériences de programmeurs. Par exemple la Colonne place bien au dessus du montage l’Afficheur qui est sur un support articulé pour l’orienter en hauteur directement vers l’opérateur. En particulier on remarquera que la Ligne OLED qui relie l’Afficheur OLED au microcontrôleur est longue et souple. On peut ainsi bien dégager l’ensemble, voir l’approcher de l’opérateur. Ainsi, à l’aide d’une loupe à fort grossissement on peut bien voir certaines zones de l’écran. Dans cette application ce ne sera certainement pas le cas. Mais j’utilise également des afficheurs bien plus petits de 0,96 pouces de diagonale. Pour vérifier des dessins, des graduations etc, il faut zoomer. Sur cette Colonne est également immobilisé le Codeur rotatif sur lequel on clique un nombre incalculable de fois. Il importe que ce type de composant soit vraiment aisé à manipuler. Il en va également de même pour les mini-claviers qui équipent nos petites réalisation. Clipser des petits boutons poussoir sur des plaques à essais est une solution très malcommode. Les fils de liaison gênent l’accès, et quand on clique pas exactement au milieu ils basculent et il faut alors les réinsérer correctement sur la plaquette expérimentale. C’est ainsi que dans le tiroir des outils on trouve un clavier à 16 touches pour multiplexer, des inverseurs et boutons en tout genre, des rampes de LEDs et toute une famille de petites électroniques d’accastillage. Bref, au cours de vos « cheminements » de programmeur, construisez vos outils ..

Fin des « confidences », revenons à P09_Noyau_Complet.ino qui sur un RESET affiche le MENU de BASE. À l’aide du codeur rotatif indexer l’item EEPROM et valider. S’affiche l’écran de la Fig.26 sur lequel on a indexé Pm7 qui contient l’algorithme dont la référence est le n°18. Il ne s’agit plus d’une simulation, car avec P09 on effectue réellement l’analyse du contenu de l’EEPROM. (Notez au passage que les dix emplacements sont occupés pour pouvoir librement effectuer des actions en tous genres dans la mémoire non volatile et en vérifier le bon déroulement. C’est du reste le bon moment pour ouvrir une parenthèse relative aux croquis fournis.)

Cliquer deux fois sur le B.P.C. afin de revenir au MENU de BASE et vous en profitez pour constater que maintenant c’est la composante rouge de la LED qui s’allume durant l’enfoncement. Puis cliquer sur l’un des « Switch » qui ici sert de bouton poussoir. Par exemple sur X de la Fig.27 et immédiatement, comme le montre la Fig.28 la valeur de la numérisation est affichée dans l’encadré rouge. C’est cette valeur, ainsi que celles des quatre autres boutons qui seront prises en compte pour optimiser les seuils de détection qui sur les figures 22 et 23 sont relatifs à des résultats issus d’un clavier installé sur un autre projet. Les résistances sont de valeurs précises, alors que sur le montage de la Fig.26 c’est du « n’importe quoi ». Le logiciel détermine immédiatement quel est le bouton poussoir actionné. Vous avez certainement remarqué que tant que le switch est activé, la composante verte de la LED triple qui s’allume. Il y aura donc un contrôle visuel de la prise en compte de ces deux périphériques.
Pour achever cette expérimentation, on clique sur tous les boutons et surtout on retient :

BILAN : Le compilateur s’active sur P09 et annonce son verdict : Le programme actuel fait 11270 octets et occupe déjà 36% de la place disponible pour le logiciel alors que l’on effectue encore aucun traitement. Pour le moment il ne faut pas s’affoler. En effet, une longue expérience a montré que c’est toujours la mise en place des procédures de base qui gloutonne un maximum de place. Ensuite l’évolution sera moins dramatique. Et puis s’il faut réduire nos objectifs on taillera dans les prévisions quitte à abandonner les belles représentations graphiques. De toute façon, à partir du moment où l’on désire utiliser un composant de faible dimensions pouvant afficher un nombre significatif de caractères textuels, qu’il soit graphique ou non n’intervient pas vraiment dans la taille occupées par les procédures puisées dans sa bibliothèque. En revanche, plus on va chercher à bénéficier des possibilités de U8glib, plus la boulimie en octets va s’amplifier. Aussi, à ce stade du développement on doit impérativement effectuer des choix et définir une stratégie :

Stratégie d’utilisation de la librairie U8glib.

Livret Bibliothèque U8glib en main, on notera en bas de P4 que chaque police de caractère encombrera la RAM dynamique. Il ne faut donc pas s’étonner qu’actuellement le programme du petit livret en consomme 13%. Ce n’est pas dramatique. D’un autre coté, si l’on change plusieurs fois de police de caractères, ce sera chaque fois du code qui s’ajoute. Aussi, comme l’on affichera que des textes « ordinaires », on n’utilisera qu’une seule police de caractères pour tout le programme. Par ailleurs, il aurait été tentant d’exploiter les beaux curseurs de la page P9 du petit livret. Toutefois, il suffit de déclarer la « fonte réduite » et de faire afficher une fois le curseur pour que le programme enfle de 100 octets. On se passera de la possibilité d’afficher des curseurs graphiques. Par ailleurs, si possible on minimisera les outils graphiques utilisés. Le plan budgétaire étant approuvé, on peut passer au développement du logiciel. Comme l’exploitation de l’appareil sera impossible sans la facilité de créer et de modifier des Algorithmes, la prochaine étape va donc consister à mettre en place l’ÉDITEUR de PROGRAMME ainsi que ses fonctions d’affichage. C’est parti …

La suite est ici.