C’est souvent lors de « l’intégration des systèmes » que l’on découvre des incompatibilités ou des interactions sources inépuisables de complexité. À partir du moment où l’on fait cohabiter des entités de technologies différentes, on peut rencontrer des perturbations de proximité et ce d’autant plus que l’on est dans un domaine qui « vibre » avec des signaux électriques binaires à des fréquences élevées, générant par nature des harmoniques à l’infini. Nous allons dans ce chapitre nous assurer que l’ensemble de la répartition des E/S du schéma de la Fig.1 sur la Fiche n°14 est viable.
Compatibilité de l’afficheur OLED avec les deux circuits PCA9685.
Partageant la ligne I2C avec les deux multiplexeurs, il faut impérativement s’assurer que l’on n’aura pas de problème d’adressage. On commence par s’instruire avec la Fiche n°2 qui nous apprend que la couche logicielle qui va gérer ce composant est constituée de la bibliothèque spécifique <U8glib.h> disponible dans le dossier <Documents> vous évitant ainsi une recherche laborieuse sur Internet. C’est celle que j’utilise et qui ne m’a jamais posé de problème. Dans le même dossier je vous propose un petit livret personnel qui résume les méthodes de cette bibliothèque nommé Bibliothèque U8glib.pdf et formaté pour en faire un petit livret au format A5 bien commode. La technique d’assemblage du livret est précisée dans Réaliser un petit livret.pdf.
Avec l’utilitaire P00_Test_ligne_I2C.ino disponible dans <OUTILS> on confirme l’adresse I2C 0x3C de la documentation qui en hexadécimal donne 0x78 qui ne devrait pas interférer avec les multiplexeurs PCA9685 ce que semble confirmer le démonstrateur P01_Programme_de_base.ino.
OLED et PCA9685 font bon ménage.
Avec le démonstrateur P01 on entre dans le vif du sujet, c’est à dire que l’on compile un logiciel qui va servir de fondation aux autres démonstrateurs qui vont suivre, aboutissant à l’étape ultime du programme d’exploitation de notre réplique d’Énigma. C’est à dire qu’à partir d’ici, certaines séquences de traitement seront « définitives » et surtout on va systématiquement adopter l’architecture électronique qui résulte des affectations de la Fiche n°1. Le démonstrateur que l’on téléverse dans l’ATmega328 est conçu pour vérifier l’intégralité des périphériques gérés par la ligne I2C. Sur RESET le module OLED et les deux modules PCA9685 sont initialisés. L’écran affiche « BONJOUR » prouvant ainsi la compatibilité entre les trois circuits électroniques. Les protocoles d’utilisation de P01 sont listés dans la Fiche n°15. Il importe toutefois de se reporter à la Fiche n°10 car la répartition des lettres affectées sur les sorties des multiplexeurs correspond à la géométrie du tableau simulé des ampoules à incandescence. Il faudra un peu jongler avec le « fouillis » Fig.3 des branchements provisoires entre les modules et les plaquettes d’essais. La LED triple est directement branchée sur le multiplexeur n°2. Pour les autres LEDs, je ne disposais que du petit module M auquel j’ai ajouté la plaquette P pour y placer deux LEDs oranges du lots approvisionné et ainsi déterminer leur valeur de 1kΩ pour la limitation du courant qui les traverse.
Éventuellement, voici le lien ou j’ai approvisionné ces composants :
https://www.amazon.fr/dp/B0CBX3JQFV?psc=1&ref=ppx_yo2ov_dt_b_product_details
L’offre précise un courant nominal de 20mA. Leur rendement est très bon, et les 2,7mA qui les traversent sont largement suffisants pour obtenir une luminosité tout à fait appropriée.
Outre la vérification de l’intégralité des 32 LEDs, la sortie pour le BUZZER est également testée. Toutefois, il faudra au préalable valider le bruiteur avec la commande [ESPACE], l’état de cette option étant précisé dans la fenêtre du Moniteur.
Lorsque toutes les commandes propres à P02 auront été testées, mis à part le CLAVIER l’intégralité des périphériques aura été validée. Valider le CLAVIER est précisément l’objet du chapitre qui suit.
Multiplexage matriciel.
Classique dans le domaine de la programmation, la technique consiste à organiser l’exploration d’un clavier en l’organisant sous forme d’une matrice de L lignes et de C colonnes. Le nombre de touches que l’on pourra ainsi différencier sera égal à L fois C. ATTENTION : Ce type de structure électronique n’est possible que pour des touches à contact travail et repos isolé. Si aucune des touches n’est cliquée, l’intégralité des broches d’interfaçage doivent être isolées les unes des autres. Du coup, cette technique n’était pas utilisable pour explorer le tableau des fiches croisées par exemple, raison pour laquelle sa matérialisation a été abandonnée. Le petit tableau de la Fig.4 résume la combinatoire, pour L et C compris entre 2 et 6. La combinaison 2 x 2 ne justifie pas du multiplexage puisqu’elle utilise le même nombre de broches 
que pour une sélection directe. Comme le CLAVIER présente 26 lettres, on doit choisir dans ce tableau une combinaison d’au moins cette valeur. Pour optimiser le matériel, la plus proche est soit 5 x 6 soit 6 x 5. Si mathématiquement ces deux solutions sont strictement équivalentes, dans leur mise en Å“uvre elle ne l’est pas. En effet, en consultant la Fiche n°17 on observe que chaque colonne C de la matrice sera réunie par une résistance de 10kΩ à GND pour forcer sur cette dernière un état « 0« . Du coup, pour simplifier au maximum le matériel, moins il y a de colonne meilleure est la solution. La combinaison 6 x 5 serait donc préférable. Pourtant c’est 5 x 6 qui a été retenue. Tout simplement, lors du développement, je n’ai pas pensé à ce petit détail. Aussi, si informatiquement reprendre le programme serait assez élémentaire, je n’ai pas le courage de refaire la documentation, et en particulier la Fiche n°1 et la Fiche n°13. Aussi, par paresse, je n’en suis pas à économiser un résistor. Puisque l’on aborde l’aspect logiciel, je vous invite à consulter la Fiche n°14 qui traite de la façon dont est géré le CLAVIER à 30 boutons poussoir par le démonstrateur P02_Validation_du_CLAVIER.ino que l’on doit téléverser dans l’ATmega328. La Fiche n°16 pour sa part donne la liste des commandes qui cette fois sont imposées par le CLAVIER simulé sur Image 03.JPG. On commence à s’approcher de la structure définitive, car l’intégralité du matériel est pratiquement validée. Comme la grille laisse libre quatre touches, ces dernières serviront à gérer les servitudes d’exploitation de notre Énigma. Leur fonction sera définitivement affectée lors du développement qui génèrera forcément des besoins à satisfaire.
Comme le clavier « retourne » les 26 lettres de l’alphabet, il fallait attribuer quatre caractères à ces touches qui restent disponibles. Par simplification ce sont les chiffres ‘1‘, ‘2‘, ‘3‘ et ‘4‘ qui ont été choisis. Arbitrairement, si au moment du sondage du clavier par la procédure Tester_le_Clavier() aucune touche n’est active, le caractère retourné sera arbitrairement le ‘@‘.
Un premier bilan sur l’évolution du programme.
Normalement, vous avez été voir le didacticiel précisé dans la page de garde de ce document, ou tout au moins vous l’avez « survolé ». Du coup, vous savez que j’affectionne l’artifice qui consiste à représenter la place occupée par le programme en cours de développement sous forme d’un thermomètre. Avec la Fig.5 je ne résiste pas à ce petit plaisir pour poursuivre cet amusement dans ce tutoriel. (Du reste cette technique me sert de statistiques en cours de développement pour savoir si l’on conserve la facilité de placer les textes affichés directement dans le programme, ou s’il faut impérativement en loger en EEPROM pour dégager de la place car le code OBJET approche la saturation de la zone dédiée.)
Nous n’avons rédigé que quelques procédures pour commencer à valider l’architecture matérielle et déjà 41% de l’espace réservé au programme est consommé. Pourtant, à ce stade du développement il n’y a pas vraiment de raison de s’inquiéter. En effet, le codage fait encore moins de 200 lignes, du coup nous avons l’impression qu’il ne fait pas grand chose. Détrompez-vous. Quelques instructions « discrètes » se goinfrent en OCTETs comme la gestion de la ligne série USB du Moniteur ou <Wire.h> pour traiter l’I2C. Par ailleurs, on a ajouté la bibliothèque Adafrui-PWM-Servo-Driver-Library-master qui accompagne le module PCA9685. Elle est très performante mais gourmande en code objet. Enfin, et ce n’est pas la plus économe, <U8glib.h> particulièrement aisée à utiliser, mais qui discrètement amène en mémoire une table de génération de la police de caractères. Bref, l’essentiel est en place.
La suite est ICI.
