Plusieurs petits programmes sont fournis en C++ écrits à l’aide de l’IDE, bien que seul P10_Programme_COMPLET.ino sera au final téléchargé dans la carte Arduino UNO. Ces petits démonstrateurs intermédiaires permettent au programmeur de mettre au point séparément certaines séquences qui ensuite viennent compléter le logiciel « définitif ». Comme déjà annoncé au début de ce didacticiel, nous allons pousser l’analyse et la précision des mesures exagérément par rapport à l’utilité pratique de cet appareil. Cette recherche n’a pas d’autre justification que « la beauté du geste ». Une étude conduite à outrance juste pour le plaisir. Commencez par enlever le fusible du support, la plus grande partie du programme sera développée sans avoir 
à gaspiller de l’électricité et chauffer inutilement notre laboratoire. Par contre, bien que la carte Arduino soit alimentée par la prise USB, si vous n’avez pas effectué la correction décrite en bas de la page 19, il faut laisser branchée
la fiche du +12V car c’est elle qui alors amène GND Arduino sur GND du circuit imprimé principal.
Le démonstrateur NOYAU de base.
Fidèle à une technique qui a fait ses preuves depuis belle lurette, dès le début de développement d’un projet qui risque d’engloutir pas mal d’heures en programmation, un logiciel élémentaire portant la référence « double zéro » est mis en place. Nommé P00_PGM_de_base.ino, ce qui n’est pas très original, et surtout évocateur de sa mission, ce démonstrateur joue un rôle crucial pour faciliter le développement logiciel. Petit programme minimal pour écrire les routines complexes, il évacue les diverses options à valider sur RESET et ne comporte que les procédures indispensables à la séquence en cours d’étude. Ainsi la lecture du source est plus aisée, évitant la recherche d’une erreur dans un listage de plusieurs centaines de lignes. Quand le module logiciel est mis au point, il est alors intégré au programme complet, ainsi que ses subroutines dédiées. Naturellement, ce démonstrateur intègre la gestion de l’afficher LCD ainsi que la procédure d’exploitation du clavier. Les déclarations de constantes et de variables ainsi que l’affectation des E/S sont cumulées au fur et à mesure que les séquences testées et mises au point vont enrichir le logiciel complet. Ainsi il y a concordance permanente entre ce petit démonstrateur et le « programme définitif ». Il vous est livré dans sa configuration en fin de développement pour un éventuel usage personnel.
Mise en service du module afficheur LCD.
Premier programme écrit en C++ pour appréhender le matériel, P01_Test_du_clavier_du_SHIELD.ino est autonome. Poliment il dit « >>> Bonjour. <<<« . Ensuite, chaque action sur une touche est suivie d’un BIP un peu agressif et indique en texte sur la ligne du bas, quel petit bouton vient d’être sollicité. L’écran est configuré en mode « lumineux ». Bien que rudimentaire, ce petit démonstrateur met en place la gestion du module LCD et de son afficheur à deux lignes. Il permet de tester le bon fonctionnement du SHIELD et confirme la pertinence des branchements relatifs à la carte électronique insérée en gigogne sur les connecteurs HE14 d’utilisation d’Arduino UNO. C’est un bon début, on peut passer à du plus consistant.
La Fig.44 résume la façon assez classique dont est géré un clavier à plusieurs boutons en n’utilisant qu’une seule entrée analogique. Autant de résistances que de poussoirs forment un diviseur de tension. Compte tenu des valeurs utilisées sur le SHIELD on obtient dans notre cas les tensions indiquée en violet. En bleu clair la valeur numérique que retourne le CAN. (Convertisseur Analogique Numérique.) Pour différencier chaque bouton on définit des seuils situés entre les deux valeurs numériques. La procédure void Tester_le_BP_A0() effectue la lecture du clavier. Si aucun BP n’est activé on en sort immédiatement pour ne pas pénaliser la boucle de base. Si un contact est détecté, la routine effectue l’anti-rebonds et filtre la touche utilisée. Cette technique ne permet pas de gérer plusieurs touches activées simultanément.
Mesurer la température du bloc thermique.
Résistance de consommation de courant et dissipateur de chaleur pourraient sans grand danger accepter de bien plus fortes températures que celles qui seront présentes quand la stabilité thermique sera obtenue, ventilateur d’extraction en service. Toutefois, sur panne de ce dernier, si le bloc thermique pourrait sans incident monter jusqu’au maximum d’environ 94°C en statique, le coffret en matière thermoplastique n’apprécierait pas vraiment. Mesurer la température du radiateur en permanence pour déclencher une alerte en cas d’incident devient une mesure de sauvegarde « prioritaire ». Avant d’aborder le calcul de la capacité, on va rapidement balayer la façon dont sera « tâtée » et calculée la température mesurée. Pour l’alerte nous verrons plus avant.
Le composant qui va transformer la température de contact en une valeur « électrique » est une thermistance CTN, c’est à dire un corps d’épreuve dont la résistance varie en fonction de la température à laquelle il est soumis. CTN, car contrairement au comportement banal des composants ordinaires en électricité qui voient leur résistance augmenter avec leur température, une CTN présente la particularité inverse. Quand nous serons capables de mesurer la valeur de la température du bloc de dissipation d’énergie, la traiter dans le programme complet sera facile, soit de la programmation « standard ». Pour débroussailler le problème, P02_mesure_la_temperature.ino, également autonome, remplit cette tâche finement et va permettre de détailler quelques particularités. Revenons à notre Coefficient de Température Négatif.
Incontestablement le petit module très courant dans le commerce en ligne dédié à Arduino, représenté sur la Fig.45 et équipé d’une thermistance CTN, est l’un des plus rudimentaires qui soit proposé comme module pour Arduino sur le marché. Comme on peut le voir sur la Fig.46 il est constitué d’un résistor de 10kΩ mis en série avec la thermistance à coefficient de température négatif. Le schéma du petit circuit imprimé se résume à deux fois rien. La Fig.45 précise les branchements à effectuer pour interfacer avec la carte ARDUINO sur l’entrée analogique A3. Attention, contrairement à ce que laisse présager la sérigraphie, il faut impérativement brancher le +5Vcc sur la broche réputée – et GND au centre. Mesurer la valeur de la thermistance n’est pas difficile puisqu’il s’agit d’un simple dispositif potentiométrique. La tension mesurée étant U, on peut facilement en déduire CTN en fonction de R :
Petit détail scabreux : La valeur de R nous est assez indifférente, c’est la température qui à nos yeux présente de l’intérêt. Bien que l’on pourrait royalement se contenter des informations données par le fournisseur de la CTN, car il maitrise avec précision la caractéristique de ses composants qui sont tous identiques à une dispersion dérisoire, pour une approche rigoureuse, des mesures physiques ont été réalisées ici, thermomètre logé dans les ailettes du radiateur. Les résistances de charge ont été soumises à une tension de 12V, le dissipateur n’étant pas ventilé. Ça chauffe, ça chauffe. Partant de la température ambiante, un grand nombre de points ont été mesurés. Sur la Fig.47 ont été sélectionnés certains d’entre eux pour répartir les points figuratifs et tracer la courbe de variation. (Petits disques rouges bordés de noir.) Manifestement, la variation n’est pas linéaire, et c’est bien dommage car la formule de transformation Résistance vers Température serait élémentaire. Le graphe est à deux entrées. À gauche nous avons la valeur de CTN en fonction de la température précisée en abscisse. À droite la tension qui en résulte sur R. Quelle que soit la température, la résistance du composant ne deviendra jamais nulle, elle tend vers une limite basse qui se situe vers 600 ohms. Normal, pour une température nulle il faut descendre vers le zéro absolu pour des comportements ordinaires. Ici il faudrait une chaleur solaire, il y aura longtemps que le composant se sera volatilisé ! Quand il fait froid, la résistance devient infinie, les mathématiciens parlent alors d’asymptote. Le pire, c’est que ces derniers parlent pour la variation visualisée d’une évolution logarithmique. Berkkkkkkk !
La suite est ici.
