08) La vérification matérielle.

Permettre un test complet de l’ensemble du matériel qui sera utilisé est un impératif suggéré en page 13 avant de développer le programme d’application. On peut aussi en profiter pour préparer l’avenir et intégrer des routines qui seront utiles plus tard. Il est également avantageux de pouvoir évaluer certains paramètres qui seront indispensables pour créer les autres démonstrateurs. C’est exactement ce que fait P05_Test_materiel.ino en introduisant la routine d’exploitation du petit clavier et en mesurant certaines valeurs critiques. Toutefois, avant de téléverser le programme de test et d’en décrire l’usage et le fonctionnement, il n’est pas raisonnable de laisser OLED en « porte à faux ». C’est la raison pour laquelle on prépare la semelle d’Image 01.JPG sur laquelle on immobilise les deux circuits imprimés ainsi que le petit écran sur la plaquette principale. On peut voir sur la Fig.28 ainsi que sur Image 21.JPG la présence provisoire d’un potentiomètre de 10kΩ inséré sur une plaquette expérimentale 8. Observons la Fig.29 qui présente en coupe médiane le petit module potentiométrique. On a découpé dans du carton rigide « culinaire » deux disques 2. Celui en B de la Fig.28 est prévu pour six positions. (Voir en page 12 le cahier des charges.) Il n’est pas interdit que le besoin fasse émerger la nécessité de sept indexages raison pour laquelle un deuxième disque « gradué » est disponible en A. Si l’on regarde la Fig.30 qui correspond au potentiomètre commandé qui sera sur la façade, on constate que les broches à souder étant orientées vers la droite comme prévu pour l’insertion dans le coffret, l’ergot 3 anti-rotation E est alors vers nous. C’est la raison pour laquelle sur les disques « gradués » A et B il est vers le bas par rapport aux index. Le potentiomètre est soudé perpendiculairement au circuit imprimé 4 qui s’insère par les picots coudés 7 sur la plaquette 8. Du coup il est en porte à faux et toute pression verticale en 1 s’accompagne d’une torsion inévitable 5. À ce régime les picots de sortie du potentiomètre ne résisteront pas longtemps. Pour les soulager un petit bloc de mousse synthétique 6 est calé entre le corps du potentiomètre et la plaquette expérimentale 8. Ce bloc souple se distingue très bien sur Image 21.JPG. Le décor est en place, on va pouvoir tester le matériel en toute sérénité et analyser P05_Test_materiel.ino.

La vérification des LEDs.

À ce stade, la configuration d’Image 21.JPG est en place et l’entrée E est reliée à la sortie du Signal étalon sur D9. Conformément au protocole de la Page 17 le signal de référence a été ajusté à exactement 4V crête. À la mise sous tension ou sur un RESET l’écran OLED affiche la page de la Fig.31 avec sur la ligne du haut la version du démonstrateur P05. Étant donné que l’entrée E est soumise au Signal étalon la valeur en ligne 2 alterne régulièrement entre 0.00 et environ 4.00 volts la valeur crête. Comme nous n’avons encore cliqué sur aucune touche du clavier, les données le concernant en 3, 4 et 5 sont « neutres ». En ligne 1 la valeur actuelle retournée par le CAN de l’entrée A0 fait ici 215 car le Potentiomètre est indexé sur la position n°2. (Analysé plus avant.) Tant que l’on n’agit pas sur le clavier, la LED jaune reste éteinte. Si le circuit imprimé principal a été correctement câblé, sans rien avoir à faire, en tâche de fond void loop allume tour à tour tous les témoins lumineux durant exactement une seconde, puis extinction de tout ce petit monde durant également une
seconde. C’est la LED triple qui s’active, avec dans l’ordre le rouge, le vert et le bleu. Puis c’est le tour des deux petites LEDs de 3mm de diamètre qui s’éclairent, la rouge en premier puis la verte. Notons au passage que les délais de pause et d’illumination sont longs, puisque d’une seconde. Et pourtant ils ne ralentissent pas la boucle de base. Une explication s’impose.

Des chronomètres à gogo.

Chaque usage de la fonction millis permet de créer un chronomètre indépendant qui ne bloque pas le déroulement du programme dans undelay() qui immobiliserait le microcontrôleur, et on peut en créer à volonté. Toutefois, chaque chronomètre devra se servir d’un « Top chrono » qui lui est propre. La Fig.32 présente un exemple avec deux chronomètres indépendants. Lorsque le microcontrôleur est mis sous tension ou lors d’un RESET, un compteur interne démarre à zéro et se voit incrémenté mille fois par seconde. (Il contient la durée écoulée en mS.) À tout moment millis peut en lire la valeur est la retourner sous forme d’un unsigned long en sortie de cette fonction. Pour mesurer l’intervalle de temps T1 la valeur retournée par millis est enregistrée dans Top_1. Puis dans le programme le chronomètre A va lire en permanence la valeur de millis. Dès que la valeur de [millis – Top_1] sera égale ou plus grande que la valeur désirée T1 c’est que la durée calibrée sera atteinte et l’on déclenchera l’action pour A, puis immédiatement Top_1 sera rechargé avec millis pour démarrer un nouveau chronométrage. Pour réaliser un deuxième chronomètre B afin de mesurer une temporisation T2 il suffit de dupliquer cette séquence, avec comme origine de chronométrage une mémoire TOP_2 et effectuer la comparaison [millis – Top_2]. On peut ainsi en créer autant que nécessaire. Ces séquences peuvent se situer n’importe où dans le programme avec des durées T1 et T2 quelconques. Noter que la durée de la temporisation ne sera pas strictement égale à celle calibrée, car il faut tenir compte du fait que l’écart de temps étant arrivé, le programme peut être occupé ailleurs. (Par exemple tant qu’un B.P. est cliqué …)

Analyse du chronométrage pour les LEDs.

Exemple typique d’un chronométrage sans pénalité pour la rapidité du logigiel, la Fig.33 présente le listage de la séquence qui gère les LEDs dans le démonstrateur P05 et qui est invoquée à chaque cycle de la boucle de base infinie void Loop. C’est dans la zone 1 coloriée en rose pastel que sont effectués les tests pour le chronométrage. Cette comparaison est très rapide et la sortie est immédiate tant que la durée attendue n’est pas atteinte. Puis, dès que l’on dépasse la temporisation consignée dans la valeur mise en évidence en jaune, on déclenche toutes les actions de la zone vert pastel 3. La première action urgente pour obtenir un chronométrage précis, c’est en 2 le Top_1 de la Fig.32 sauf que dans notre cas il n’y a pas besoin de mémoriser cette valeur puisqu’il n’y a qu’un seul chronométrage à gérer. Généralement les actions 3 n’exigent que peu de cycles microcontrôleur et ensuite la boucle de base reprend sa routine de fond généralement à un rythme élevé.

Rapidité de « rotation » de la boucle de base.

Dans les nombreux conseils prodigués péremptoirement dans ce didacticiel, il est précisé que l’on doit mesurer la rapidité d’exécution void loop() pour vérifier que le taux d’affichage est important, que le délai de prise en compte des potentiomètres, B.P. et autres périphériques de type clavier est faible. Bref, que le dispositif est réactif. Seule limite, il faut disposer d’un fréquencemètre. Pour ceux qui le désirent, sur
https://www.robot-maker.com/ouvrages/apprendre-a-programmer-arduino-en-samusant/
est décrit ce type d’appareil réalisé avec une carte Arduino.
On obtient pour le démonstrateur P05 une fréquence de 7Hz. La prise en compte du bouton poussoir est donc vive sans être toutefois exceptionnelle. En effet, elle est ralentie considérablement par la boucle d’affichage sur le petit écran OLED car toues les autres séquences sont très rapides.

La gestion d’un bouton poussoir et l’antiparasitage.

Dans ce chapitre nous allons mêler théorie et pratique et prendre en exemple la ligne clavier gérée par A6. Pour mémoire la Fig.34 reproduit son schéma électrique. Bien que dans ce démonstrateur on ne va prendre en compte que quatre boutons poussoir, ce thème reste directement utilisable pour un clavier plus conséquent, voir multiplexé. La première source de parasitage dans la lecture d’une entrée analogique vient avec le « bruit alimentation ». Considérons la Fig.35 qui montre l’évolution de la tension alimentation au cours de temps. En théorie l’adaptateur secteur fournit un +5V bien filtré et continu représenté par le trait rouge horizontal. Dans la réalité, à cette tension continue se superposent des variations très rapides que les techniciens nomment « herbe » ou « bruit blanc ». Sur la Fig.35 cette perturbation est considérablement exagérée. (Ou alors l’adaptateur secteur doit être mis à la poubelle !) Même si l’alimentation est parfaite, le +5V du bloc USB fournit la polarisation par la ligne électrique dans laquelle se trouve la résistance R3 de protection de 1kΩ. Elle est indispensable, car sans elle si l’opérateur clique simultanément sur les deux boutons BP3 et BP4 on réalise un court-circuit franc entre le +5V et le GND. Cette ligne dans un environnement électromagnétique très encombré capte les parasites hertziens et sera forcément affectée par moment de petites impulsions parasites. Plus la résistance sera de valeur faible, moins ces phénomènes seront présents. À vide, R1 et R2 forment un diviseur de tension par deux. Comme en A la tension à vide est de l’ordre de 4V, sur A6 elle est de 2V et la numérisation par le CAN donne la valeur de 486. Cliquer sur BP3 a pour effet de faire un court-circuit entre A6 et GND. Donc quand on cliquera sur le bouton poussoir, A6 se retrouvera au potentiel nul. Pour minimiser l’influence des parasites captés par la ligne de polarisation, il suffit de prendre comme seuil de décision la moitié de la tension présente entre celle du repos et celle de l’enfoncement de la touche concernée. Ce qui compte pour le programme, ce n’est pas la tension mesurée, mais le résultat de la numérisation du CAN. Les valeurs seront directement concernées par celles des résistances R1, R2 et R3 qui ont une tolérance de fabrication. (Probablement dans les 5%.) Du coup sur votre prototype elles ne seront pas forcément les mêmes. Pour optimiser le code, P05 est conçu pour mesurer ces valeurs numérisées et les afficher. Cliquer un court instant sur le B.P. du haut puis deux secondes sur celui du bas. Sur la ligne « CAN sur A0 » la valeur de 653 résulte de l’orientation de Pot sur l’index 4. Sur la ligne de l’encadré jaune on trouve les valeurs des numérisations effectuées lors du dernier clic réalisé sur les deux lignes du clavier. Donc A6 = 930 est relatif au B.P. du haut, soit BP4, alors que A7 = 0 concerne BP3. Juste au dessus du cadre, l’information du type BP = Bas : Long concernera toujours les attributs de la dernière touche cliquée. Il est donc facile d’obtenir les quatre valeurs des CAN pour toutes les touches activées. Notez au passage que lorsque l’on clique sur le B.P. du haut, on génère un BIP d’alerte. On teste donc au passage une routine qui sera utile aux futurs programmes. Sur la Fig.35 ont été reportées les valeurs numérisées sur le prototype. Le seuil de décision situé entre les données limites est également porté en vert et en violet. Si vous consultez le listage de la procédure void Tester_le_BP(), ce sont ces valeurs qui sont consignées. Toute valeur plus grande que 707 désignera BP4, toute valeur inférieure à 243 dénoncera BP3. Il reste à déterminer les valeurs des CAN au repos des deux lignes A6 et A7. Dans ce but il suffit dans le logiciel de P05 de passer en remarques les deux lignes repérées par des @@@@@@@@@@@@@@@@@ et de valider les deux lignes du dessous.
On a réglé le problème de « l’herbe » mais il reste à éliminer les rebonds du contact électrique. Quand on bascule la mécanique d’un inverseur ou celle d’un bouton poussoir, on engendre le mouvement de pièces métalliques qui viennent en contact. Électriquement on génère un état « X » sur une entrée analogique ou binaire. Et bien cet état est inutilisable directement. En effet, lorsque deux pièces mécaniques sont « bousculées » l’une contre l’autre, il y a des rebonds mécaniques et l’évolution de l’état logique sur l’entrée concernée ressemble à ce à celle de la Fig.37 qui correspond à un élément de très bonne qualité, car ici le contact ne rebondit que quatre fois lors de l’activation. Les transitoires verts sont représentés par des « durées nulles » car ils se font très rapidement. Si on ne tient pas compte de ce phénomène, alors le logiciel va croire que l’action sur le composant a été déclenchée quatre fois et les traiter en conséquence. Dans la pratique, un interrupteur de qualité va présenter entre dix et vingt « ricochets ». Un composant médiocre peut en générer jusqu’à deux cents voir plus ! Aussi, il faut systématiquement faire de l’anti-rebonds. Parmi les techniques ordinaires, on peut adopter celle de la Fig.38 dans laquelle le traitement peut être effectué juste après le relâcher du bouton poussoir en là ou dès que le clic est stabilisé en ici. L’approche « ici » est en général moins pénalisante en taille de programme, et peut surtout faire gagner un peu de temps en exécution si le composant met du temps à se stabiliser, car ce délai sera en partie « masqué » par la durée du traitement. La stratégie « là » impose la gestion d’un booléen mais autorise l’appel multiple à la séquence de surveillance d’une utilisation du clavier. Cet organigramme n’explique pas comment se fait l’anti-rebonds. En analysant le code source, on constate que l’on utilise un COMPTEUR. Chaque fois qu’une mesure signale un état « Repos » il est incrémenté. Si durant le comptage on constate un état « X » ,c’est qu’il y a rebond et le COMPTEUR est remis à zéro. Il faut atteindre un nombre de lecture stables NB_tests_antirebonds fois pour considérer que le contact électrique est stabilisé et que le relâcher est stabilisé. On ne se préoccupe pas de la stabilisation de l’état travail, puisque seule celle du relâcher est importante. La valeur de NB_tests_antirebonds est trouvée expérimentalement. Plus le composant est médiocre, plus il faut l’augmenter au détriment naturellement du temps pris par le traitement des « ricochets ». On peut « juguler » un peu ces faux contacts en plaçant un condensateur entre l’entrée logique et GND mais je ne le fais que dans des cas particuliers car ce sont des composants en plus à ajouter à la circuiterie électronique.

Utilisation de la PWM ou de l’instruction tone ?

Lors du chapitre précédent on a modifié deux lignes pour tester les CAN au repos des touches du clavier. On a repéré immédiatement les longues lignes de remarques du genre //@@@@@@@@@@@@@@@@. C’est un artifice pour attirer immédiatement le regard dans un listage. J’utilise systématiquement cette sorte d’étiquette dans mes programmes pour des lignes de code dont on est amené à changer « régulièrement » le contenu. Par exemple en tête de programme on trouve un texte qui précise la date de validation du démonstrateur. Si plus tard on le modifie, pour mettre à jour cette référence il faut la retrouver facilement. Dans P05 on utilise la PWM pour générer le signa étalon. C’est la raison pour laquelle sa fréquence de répétition est de 490 Hz avec une période T ≈ 2042 µS pour PWM D3, D9, D10 et D11. Pour les sorties PWM D5 et D6 la fréquence de répétition serait de 976 Hz avec une période T ≈ 1025 µS. (Pulse Width Modulation) Dans une instruction telle que analogWrite(Sortie_PWM, N) le rapport cyclique est directement proportionnel à la valeur N passée en paramètre et Sortie_PWM fait référence à la broche de sortie utilisée. N impose la durée à l’état « 1« , donc influence directement le rapport cyclique.

Lorsque l’on déclenche une PWM, elle continue « définitivement » sauf si par la suite on utilise analogWrite(Sortie_PWM, N) avec N = 0 ou N = 255 sur la broche concernée. C’est de cette façon qu’avec la seule instruction analogWrite(Signal_Etalon, 128) dans void setup() on génère le signal de test pour notre oscilloscope sur la broche D9 de l’ATmega328.
Étant limité à deux tonalités au maximum, il est naturel de chercher à enrichir les possibilités musicales du bruiteur installé. C’est précisément la finalité de l’instruction tone dont la mise en Å“uvre est particulièrement conviviale. Pour s’en rendre facilement compte, dans la procédure void Gere_stabilisation_et_duree() on utilise la PWM pour générer avec tone(BUZZER,200) la tonalité grave sur D4 durant l’enfoncement d’une touche. Dès que son relâchement est stabilisé, avec l’instruction noTone(BUZZER) on stoppe le bruitage. Cette instruction laisse la broche au potentiel de GND le courant étant alors nul. Pour le BIP() sonore, la fréquence générée de 4000Hz a été choisie car elle n’est ni trop grave ni trop aigüe, toutefois amusez-vous à proposer d’autres tonalités. On ne peut rêver plus simple pour « faire de la musique ». Toutefois, la taille du programme augmente de 1312 Octets d’un coup et 23 Octets de plus dans les données dynamiques.
Conclusion : Générer une tonalité musicale peut se faire de plusieurs façons. Utiliser de la PWM est parfait pour gérer la luminosité d’une LED par exemple en modifiant le rapport cyclique. Par contre, pour créer une note musicale on est limité à une seule fréquence relativement basse. Si on désire n’utiliser qu’un seul BIP sonore, on peut se contenter d’un BUZZER actif et d’une procédure élémentaire telle que : (Un BUZZER actif génère du 3000 Hz quand il est soumis à +5Vcc)

Dans cette procédure qui réalise un BIP sonore sur un bruiteur passif la fréquence sera d’autant plus élevée que T est de faible valeur. La durée du BIP est directement proportionnelle à MAX. Cette procédure ne consomme que 52 Octets de programme et rien de plus dans la mémoire dynamique.

Résumé : Pour générer des tonalités par un bruiteur il existe un nombre infini de possibilités qui n’est limité que par notre manque d’imagination. Si l’on désire se faire plaisir est obtenir facilement des tonalités différentes, l’emploi d’un BUZZER passif s’impose. Si de plus on dispose de largement trop de place en mémoire de programme pour y loger notre code, ne pas hésiter à privilégier tone et notone. Si au contraire on cherche désespérément à loger le code objet qui dépasse l’espace disponible, passer éventuellement à un BUZZER actif et se contenter d’une seule tonalité, d’environ 3000Hz qui est celle de ce type de composant. Reste à aborder la caractéristique du bruiteur adopté initialement sur le prototype car on va en changer pour le remplacer par un actif.

ATTENTION : Ces éléments, qu’ils soient actif ou passifs sont polarisés et la Fig.40 en broche B précise la sortie positive, l’autre devant aller sur GND. Corrigé sur le schéma de la Fig.18 en page P14 le dispositif initial était branché directement sur la sortie D4. Lorsque l’on observe l’oscillogramme de la Fig.41 on constate que le niveau logique « 1 » talonne à 1,5V avec des petits « pics » qui montent jusqu’à 4,4V et des impulsions négatives jusqu’à -0,7V. Ce constat étant réalisé, j’ai mesuré la résistance du composant : 11Ω ! Suite à un démontage du BUZZER initial, son étude montre que c’est un simple bobinage avec un noyau central et un aimant permanent annulaire autour. C’est « le sens » de l’aimant qui impose une polarisation. Du coup les 11Ω font presque un court-circuit sur la sortie D4 et à ce régime l’ATmega328 ne va pas supporter très longtemps. Il serait possible de persister dans cette voie, en intercalant un petit transistor amplificateur de courant. Outre qu’il ne reste pas assez de place sur le circuit imprimé, des essais ont montré que ce n’est pas vraiment la solution. Aussi, avec le prochain démonstrateur on va radicalement changer de solution et utiliser un bruiteur ACTIF. Ce dernier présente une impédance très élevée et ne consomme pratiquement rien. Toutefois, une résistance de 150Ω est insérée en série, car il est un peu trop bruyant. C’est la raison pour laquelle le schéma de la Fig.18 a le mot passif rayé. C’est avec le prochain démonstrateur P07_Gestion_MENUs.ino que sera mis en service ce composant qui a été changé sur le circuit imprimé, les dessins étant mis à jour sur la Fig.26 et dans la notice.
Donner dans la facilité n’est jamais une bonne chose. Aussi, il suffit de réécrire void BIP() et de changer quelques instructions dans void Gere_stabilisation_et_duree() pour passer de P05 au démonstrateur P06_Test_optimal.ino qui effectue strictement le même travail avec toutefois une réduction de 1312 octets pour la taille du programme ce qui est considérable et une diminution de 23 octets dans la mémoire dynamique. (tone est simple à utiliser, mais gloutonne 1312 octets !)
STATÉGIE ADOPTÉE : Il suffit d’abandonner la facilité apportée par tone et utiliser PWM pour générer la tonalité grave qui signale l’activation d’une touche du clavier. Quand à void BIP() elle est entièrement construite pour générer la fréquence de 4000Hz dans le BUZZER. La période est de 250µS d’où l’utilisation de delayMicroseconds(125) pour temporiser de la moitié qui dans la Fig.39 correspond à T. Comme l’on désire une durée du BIP de 0.15 seconde, le nombre de périodes MAX est de 0.15 / 0.00025 = 600 valeur adoptée dans la séquence sonore.
CONCLUSION : Souvent, quand on programme sous la houlette d’un langage évolué comme le C++ l’approche la plus naturelle consiste à faire usage de toutes ses instructions et en particulier des plus évoluées. Ce n’est pas forcément la bonne approche au point de vue de l’optimalisation du code. On en a un exemple typique avec tone. Aussi, le programmeur devrait toujours envisager d’autres écritures qui permettent parfois une économie en octets substantielle. À méditer …

Préparer les menus par gestion du Potentiomètre branché sur A0.

Envisagé dans le chapitre du bas de la Page 12, les divers menus d’exploitation vont utiliser le positionnement du Potentiomètre branché sur A0. Pour en effectuer la gestion nous aurons besoin des valeurs que retourne la CAN. Pour les noter les démonstrateurs P05 ou P06 affichent ces dernières dans la ligne 1 de la Fig.31 en Page 19. Dans le tableau de la Fig.42 sont résumées les valeurs relevées sur le prototype. Elles sont directement fonction des caractéristiques de Pot mais également de la position des points tracés pour l’indexation, et bien entendu de l’ouverture du potentiomètre. Il suffit pour votre exemplaire de faire ces relevés, et surtout ne vous formalisez pas si les valeurs affichées fluctuent. Leur saisie à ± 10 unités sera largement assez précise comme on va le constater dans le chapitre qui suit. Si par la suite nous envisagions sept indexations au lieu de six, il suffirait de remplacer le disque en carton par celui en A sur la Fig.28 et de téléverser à nouveau P05 ou P06 pour refaire la manipulation. Avant d’en terminer avec la validation complète des deux cartes électroniques, on débranche l’entrée E du Signal de test et on la relie comme suggéré sur la Fig.43 à un quelconque potentiomètre à variation linéaire compris entre 1kΩ et 47kΩ. C’est d’autant plus facile à faire que le +5Vcc et GND sont disponibles sur les picots non utilisés par les straps de polarisation du petit écran OLED. Quand on balaye l’intégralité de son ouverture, l’information de la ligne U sur E en 2 de la Fig.31 doit varier entre 0.00 et 5.00 volts.

Principe de la sélection de l’une des six fonctions envisagées.

Quel que soit le MENU ou le sous-menu traité, l’idée consiste à déclencher l’une des six fonctions lorsque l’on active un Clic long. (Possible aussi sur un clic court.) C’est la position calée sur le bouton du potentiomètre qui détermine laquelle est invoquée, raison pour laquelle on utilise un bouton flèche et que sur l’étiquette six points d’indexage ont été tracés en divisant l’amplitude de la rotation en cinq secteurs d’ouvertures angulaires équivalentes. Pour fiabiliser et faciliter au maximum le travail de l’opérateur, la technique (Voir la Fig.44) consiste à attribuer à chaque index un secteur angulaire dont les limites sont éloignées au maximum des positions voisines. Il suffit de placer la frontière du secteur à la moyenne des deux positions mitoyennes. Avec cette approche, même soufrant d’une très mauvaise coordination gestuelle, plaçant vaguement la flèche du bouton pas trop loin du point vert, on déclenche sans aucun problème l’activation de la fonction désirée. Sur le prototype les valeurs à retenir sont les suivantes :

Pour tester la routine Lire_INDEX qui gèrera les menus et qui consomme 136 octets téléverser P07_Gestion_MENUs.ino qui affichera en ligne du bas la position de l’INDEX déterminé lors de l’utilisation de n’importe quelle touche du clavier, que le clic soit long ou court. Comme maintenant avec le bruiteur ACTIF on ne dispose que de la tonalité à 3000Hz, la routine BIP(byte Duree) est paramétrée. Les BIPs d’alerte seront longs, alors que chaque clic sur une touche du clavier ne déclenchera qu’un BIP très court mais suffisant pour informer l’opérateur de sa prise en compte.

Faire un petit bilan avant de commencer l’étude de l’oscilloscope, me semble utile à ce stade. Si l’on compare le travail de P07 au cahier des charges de la Page 12 on a traité les items suivants :
01) Limiter à quatre boutons poussoir et un potentiomètre l’encombrement de la façade de pilotage.
03) Présence d’une LED jaune entre les boutons poussoir pour attester d’un Clic long.
04) Protection de l’entrée si surcharge en tension ou inversion de polarité.
07) Envisager la présence d’un petit bruiteur ACTIF pour la gestion du clavier et des incidents.
10) Fournir en permanence un Signal de test.
Pourtant, vous êtes en droit de vous inquiéter pour la suite du projet. En effet, strictement aucune fonction relative à l’oscilloscope n’est écrite et le démonstrateur se gloutonne déjà 34% de l’espace mémoire. Rassurez-vous, l’expérience sur un très grand nombre de projets m’a montré que chaque fois les premières ébauches prennent beaucoup de place. En réalité on fait appel à des bibliothèques qui engendrent beaucoup de code. Puis, par la suite on ne va utiliser que des « instructions élémentaires » et la boulimie en octets va rapidement s’étioler. Il n’y a pas de raison que pour ce projet ce soit différent, personnellement je reste confiant. Par ailleurs, on a déjà mis en place la gestion de l’afficheur qui incorpore dans le code sa police de caractères et ses routines. C’est l’un des deux gros consommateurs actuels. Le deuxième « convive affamé » réside dans les bavardages, c’est à dire les textes affichés à l’écran. Le chapitre suivant va traiter de ce sujet fondamental.

La suite est ici.