Lister une famille de critères à respecter c’est bien, mais encore faut-il avant de s’engager réellement dans le projet, d’en vérifier la faisabilité. Si vraiment les premières études tendent à prouver que ce n’est pas réaliste, il vaut infiniment mieux abandonner l’idée, que de foncer tête baissée dans le guidon, investir des sommes et surtout des heures et des heures de loisir pour en fin de compte aboutir à un échec. Les premières études « griffonnées sur du papier » laissent entrevoir que la pierre d’achoppement réside dans la gestion des nombreuses Entrées/Sorties avec une seule carte Arduino NANO. (Gérer des servomoteurs pour faire tourner des rotors 3D a été abandonnée par exemple car générait trop de parasites.) Il est donc impératif de s’assurer que les choix effectués sont viables.
Pour éviter d’alourdir le didacticiel par de trop nombreuses parenthèses techniques, ce tutoriel est accompagné d’un grand nombre de fiches au format A5 que je vous invite à imprimer en Recto / Verso et disponibles dans le document FICHES A5.pdf.
Commencer par consulter la Fiche n°11 et la Fiche n°12 pour faire connaissance avec Arduino NANO.
Architecture globale envisagée.
Véritable chef d’orchestre, le processeur Arduino se charge de l’intégralité des traitements. Outre l’afficheur OLED en 2 il Il assure la lecture du clavier à vingt-six touches en 7 plus quatre boutons poussoir de servitude en 8 dont la fonction reste à définir en cours de développement. En 3 il faut également gérer les vingt-six LEDs du tableau 
des ampoules auquel on peut ajouter les trois témoins en 4 gérant une LED tricolore. Le petit bruiteur actif placé en 6 sera piloté géré par une sortie binaire. Il reste à prouver que tout cela est viable et réaliste. (Trois servomoteurs en 5 et trois capteurs micro-Switch en 1. ont été abandonnés.)
Répartition et justification des Entrées/Sorties.
Avant de vérifier le bienfondé de la structure adoptée en Fig.2 qui résulte directement de la répartition des broches, passons en revue les critères techniques qui ont conduit à la distribution des lignes d’interfaçage indiquée en Fig.1 de la Fiche n°1.
C’est volontairement que les deux broches analogiques A6 et A7 sont Non Utilisées pour que l’on puisse librement utiliser une carte Arduino UNO si cette dernière emporte votre préférence car un exemplaire disponible « traine » dans vos tiroirs. Initialement le BUZZER actif était branché sur A13. Toutefois, cette broche est sur la LED d’Arduino qui s’illumine une fraction de seconde lors d’un RESET, ce qui engendrait un BIT intempestif. Du coup l’ensemble du multiplexage du clavier a été décalé « vers le haut ». Les broches de lecture du multiplexage en entrées ont été choisies contigües de D3 à D8 car généralement cette approche peut simplifier la gestion informatique du clavier. Même critères pour D9 à D13 qui en sorties assurent le multiplexage en balayage ligne. Toutes les broches binaires sont affectées, puisque D1 et D2 sont réservées pour le dialogue série avec le Moniteur de l’IDE et le téléversement des démonstrateurs. Initialement prévues pour la lecture des trois capteurs d’orientation des Rotors les entrées analogique A0 à A2 sont non utilisées et restent disponibles en Entrées ou Sorties. Pour la gestion de la ligne I2C qui pilote l’afficheur OLED et les deux multiplexeurs PCA9685 nous n’avons pas le choix. Les bibliothèques de ces périphériques imposent les deux broches A4 et A5. Au final, il reste encore la broche analogique A3 qui peut aussi bien servir en entrée qu’en sortie binaire pour un éventuel complément non encore prévu et trois sorties sur le multiplexeur n°2.
La suite est ICI.
