Puisque nous en sommes à la réalisation des circuits imprimés, il serait assez logique de créer le petit clavier secondaire et celui des LEDs oranges. Ce n’est pas le bon moment. En effet, le petit clavier n’est pas encore défini, il vaut mieux attendre que le programme d’exploitation soit globalement développé pour en choisir ensuite la répartition pertinente des touches et des LEDs de servitude. Pour le tableau des LEDs orange, on ne pourra le faire que lorsque le boitier sera réalisé. La raison résulte de la procédure appliquée pour souder les LEDs. Pour des raisons esthétiques, le trou de passage à travers le panneau du coffret sera réduit au minimum. Elles traverseront « en sifflant ». Hors percer tous les trous exactement en face des 26 LEDs est impossible avec des moyens amateurs. S’il est possible en A de la Fig.15 de faire fléchir les broches dans leur plan, perpendiculairement comme en B c’est infaisable. La technique aisée illustrée sur la Fig.16 consiste comme en C à enfiler
complètement toutes les diodes comme en C. Puis, la plaque supérieure a été percée avec ses orifices pointés avec précision et alésés pour que les LEDs le traversent pratiquement sans jeu. On réalise la liaison entre le circuit imprimé et le dessus en intercalant les entretoises de longueurs idoines. Puis on retourne le tout. Les LEDs coulissent alors, certaines traversant les trous de passage jusqu’au contact avec leur collerette. Pour celles qui ne sont pas exactement dans l’axe il suffit à la main de les orienter comme en D. (Sur ces dessins le décalage des trous de passage est exagéré, car même un « bricoleur » occasionnel ne sera pas aussi imprécis que sur ces représentations.) Toutes les LEDs étant correctement positionnées, on soude alors leurs deux broches et le tableau peut être déposé pour y ajouter les résistances, les connecteurs HE14 et les ponts éventuels de liaison. On peut passer au logiciel.
La visualisation des positions des Rotors.
L’idée de réaliser des éléments volumiques animés ayant été abandonnée, on va afficher les lettres de leur orientation sur l’afficheur graphique. Pour que notre réplique puisse s’approcher de l’apparence de la machine historique, on désire que les lettres affichées sur OLED soit les plus grandes possibles. Pour l’apparence on va les présenter dans des rectangles simulant un peu mieux les Rotors. La police de caractère implantée est choisie pour rester parfaitement visible, tout en nous octroyant des lignes de textes contenant assez de caractères. Mais cette police u8g_font_6x10 même en double taille affiche des lettres un peu petites pour la représentation des Rotors. Aussi, dans un premier temps on va supposer que nous aurons assez de place en mémoire de programme pour ajouter une deuxième police u8g_font_9x15B qui semble un bon
compromis entre la grandeur des lettres présentées en double taille en Fig.17 et un encombrement en octets pas trop déraisonnable. C’est le démonstrateur P03_Afficher_les_Rotors.ino qui est chargé de tester cette approche. Son protocole d’utilisation est précisé en tête de programme. P03 commence à mettre en place les deux modes d’exploitation de la machine. Il reste maintenant à implémenter toutes les fonctions de CRYPTAGE et celles du mode COMMANDE qui permettra d’initialiser la chiffreuse.
Nouveau bilan sur l’évolution du programme.
Visiblement, sur le thermomètre de la Fig.18, le fait d’avoir ajouté une police de caractère et quelques instructions à fait monter « la température ». C’est que la police u8g_font_9x15B se gloutonne à elle seule 3002 octets de programme soit 9% de la zone dédiée. Il est fort possible que ce luxe de présentation déborde au final les possibilités de l’ATmega328. Si tel était le cas en fin de développement, il serait toujours envisageable d’abandonner cette présentation et de la reconditionner pour l’exploitation en double taille de la police des menus textuels u8g_font_6x10.
La suite est ICI.