Dans ce chapitre nous allons aborder quelques aspect d’utilisation d’Arduino qui ne sont pas forcément abordés dans les forums dédiés à notre microcontrôleur favori. Ces manipulations ne vont pas forcément utiliser des composants ou des modules particuliers, elles ont pour but d’explorer des pistes probablement nouvelles pour vous. Les démonstrateurs associés sont tous regroupés dans le dossier dédié <DIVERSES EXPERIENCES>.
Diverses_Experiences_1 : Mesure de la tension +5Vcc d’Arduino.
Alimenté en autonome par un accumulateur rechargeable de type USB en sortie, en mesurer la tension durant le fonctionnement de la machine peut prévenir l’opérateur qu’il est temps de penser à recharger cette source d’énergie. Certains modèles affichent leur état de charge de cette réserve d’énergie, mais ce n’est que rarement le cas. Aussi on désire surveiller la tension d’alimentation avec une entrée analogique. Comme par défaut l’instruction analogRead() retourne une valeur comprise entre 0 et 1023 lorsque la tension mesurée sur le CAN varie entre 0 et +Vcc, la valeur affichée serait erronée et une baisse de tension ne serait pas détectée. Il faut impérativement prendre une tension interne stabilisée et précise comme référence pour le CAN : analogReference(INTERNAL). Mais cette tension de référence fait exactement 1,1V. Il faut impérativement ramener le +5Vcc d’Arduino à cet ordre de grandeur ce que fait le schéma de la Fig.286 et parer les fluctuations inexorables affectant ce type de mesurage. Avec les valeurs de ce schéma la tension sur le point chaud du potentiomètre ajustable A fait environ +1,6V. Parer les fluctuations consiste à totaliser 1000 mesures avec le CAN et à en faire la moyenne :
L’instruction (1) compte les mesures sachant qu’avant de rentrer dans cette boucle on commence par TENSION = 0. En (2) on effectue les mesures et on additionne dans le unsigned longTENSION. En (3) on calcule la moyenne. En (4) on convertit la plage maximale de [0 à 1023] en [0 à 53] car 1023 est obtenu pour exactement 5,3V. Enfin le float U reçoit la valeur mesurée qui sera affichée avec une décimale. (Pour l’étalonnage voir Diverses_Experiences_1.ino)
Diverses_Experiences_2 : Le mode SOMMEIL.
Bien que ce ne soit pas spécifiquement courant, des applications particulières ont besoin de minimiser la consommation d’Arduino dans certaines circonstances. Par exemple c’est le cas pour https://www.robot-maker.com/ouvrages/panneaux-solaires-experimentations/ qui propose une petite centrale solaire qui mesure et enregistre tout au long de l’année l’énergie que nous fournit l’astre diurne. Cette application est dotée d’un petit accumulateur rechargeable qui prend le relais lorsque l’ensoleillement est faible ou durant la nuit. Pendant cette dernière, il n’y a plus de mesures à faire, aussi il convient de faire passer le dispositif en sommeil pour minimiser sa consommation. Il faut savoir que le microcontroleur ATmega328 met à notre disposition cinq modes de veille différents par ordre d’économie d’énergie :
• SLEEP_MODE_IDLE : Le mode d’économie d’énergie le plus faible.
• SLEEP_MODE_ADC. • SLEEP_MODE_PWR_SAVE. • SLEEP_MODE_STANDBY.
• SLEEP_MODE_PWR_DOWN : Le mode d’économie d’énergie le plus élevé qui est utilisé dans le démonstrateur Diverses_Experiences_1.ino. Ce dernier se contente d’allumer la LED d’Arduino durant l’activité du processeur. Il rend compte de son état sur le Moniteur de l’IDE. Pour avoir plus de périphérique à passer en veille, un afficheur OLED de 1,3 pouce de diagonale affiche l’état du système en parallèle. Naturellement vous pouvez vous en passer si ce composant n’est pas disponible. Comme précisé dans le listage, c’est une carte NANO qui est utilisée ici, car sa LED rouge de témoin d’énergie a été supprimée car « trop présente ». Ses caractéristiques sont présentées en Fiche n°5 et en Fiche n°6. (Pensez à la déclarer !) Une carte UNO convient également.
Diverses_Experiences_3 : Gestion des Interruptions.
Rencontré dans le démonstrateur P100, il me semble judicieux de vous proposer une deuxième manipulation qui ici va faire appel à l’interruption INT 0 sur la broche D2. L’immense avantage des interruptions, c’est qu’il n’y a pas à effectuer de scrutation permanente pour détecter l’arrivée de l’événement surveillé. De plus, ce dernier sera pris en compte même si le processeur est enlisé dans une séquence un peu longue comme un delay() par exemple. Il serait parfaitement possible dans le démonstrateur Diverses_Experiences_3.ino de gérer un clavier complet. Comme ici on désire juste mettre en place les éléments fondamentaux de la gestion des interruptions, on se contentera d’un simple bouton poussoir. Le fonctionnement du programme et son utilisation sont précisés dans le listage. En tâche de fond on se contente de faire clignoter la LED d’Arduino.
Diverses_Experiences_4 : DELAI par Interruption.
Nombreuses sont les techniques possibles pour gérer le temps. On peut faire des boucles imbriquées telles que celles du démonstrateur précédent, mais hors procédure d’Interruption, si delay() est utilisable c’est bien plus simple et lisible. On peut utiliser le compteur interne de l’ATmega328 comme dans P010. Il est encore possible d’utiliser une autre ressource interne pour gérer un délai par Interruption. C’est ce que fait Diverses_Experiences_4.ino qui nous sert d’exercice de révision sur la gestion des Interruptions.
Diverses_Experiences_5 : Des chronomètres à gogo avec millis.
Puisque nous avons ouvert l’éventail des possibilités pour programmer des chronométrages, il me semble incontournable d’aborder le cas où l’on désire gérer plusieurs chronomètres indépendants les uns des autres, sans pour autant enliser la boucle de base dans des temporisations imbriquées les unes dans les autres et se déclenchant sans la moindre synchronisation. C’est encore le compteur interne de l’ATmega328 qui va nous servir d’horloge. 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 un delay() 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.287 présente un exemple avec deux chronomètres indépendants. Pour mémoire, 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. Le principe du chronométrage explicité en Page 8 pour P010 est repris sur la Fig.287 sur laquelle on va prendre en compte deux chronométrages. 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 surveiller en permanence la valeur de millis. Dès que [millis – Top_1] sera égal ou plus grand 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 et 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é, le « petit cœur » de la boucle de base cesse de battre. (Le pauvre ! ! !)
Un petit Cœur logiciel qui bat discrètement.
Stéthoscope à l’oreille, le programmeur doit pouvoir vérifier à tout moment que le processeur ne tombe pas dans une séquence trop longue ou pire, dans une boucle infinie. C’est la raison pour laquelle dans la plupart de mes programmes, si elle est disponible je fais clignoter la LED d’Arduino. Pour le démonstrateur Diverses_Experiences_5.ino ce sera le petit cœur d’Arduino qui bat à la seconde. Son rythme sera bien entendu calibré par millis(). Pour bien montrer l’indépendance de plusieurs chronomètres, on va faire clignoter cinq LEDs à des cadences différentes, l’une sera pilotée dans une procédure pour bien montrer que l’on peut vraiment placer les chronomètres n’importe où dans le programme. Enfin pour montrer que la durée peut être dépassée, un bouton poussoir permet de bloquer le programme dans l’attente du relâcher. Durant toute son activation les chronomètres sont suspendus et ils repartent tous au moment de la libération.
Diverses_Experiences_6 : Usage de serialEVENT.
Assez peu connue, cette procédure est pourtant très séduisante quand on utilise le Moniteur de l’IDE. Elle présente l’immense avantage d’effectuer une lecture du tampon de la ligne série que lorsque celui-ci est validé. Concrètement c’est une procédure qui à aucun moment dans le programme n’est invoquée. La boucle de base y fait appel automatiquement lorsque les données sont disponibles. La manipulation consiste à frapper des caractères dans la fenêtre de saisie du Moniteur de l’IDE. Si on valide, il ne se passe rien, ou plus exactement la chaîne reste en attente. Dès que l’on ajoute la « sentinelle » choisie arbitrairement ‘/‘ toute la chaîne mémorisée est affichée sur le Moniteur, y compris si des caractères suivent le ‘/‘.
Diverses_Experiences_7 : Dialogue entre deux machines.
Typiquement deux cartes Arduino sont impliquées dans un même projet et doivent coopérer. Par exemple l’une gère un petit robot. L’autre est intégrée dans un petit pupitre de commande. La liaison entre les deux unités peut être filaire ou passer par radio, Bluetooth etc. Faire dialoguer deux machines n’est absolument pas élémentaire. Contrairement aux bavardages humains pour lesquels les messages sont transportés par l’air ambiant, sur des machines ce sont des impulsions binaires qui se succèdent à cadences élevées sur les lignes de communication. Dans notre cas ce seront TX et RX sur D0 et D1 qui seront affectées à cette fonction palabresque. Non seulement pour se comprendre les deux machines devront échanger des propos par le biais de protocoles très précis, mais surtout des problèmes de synchronisation sérieux pourront rompre et bloquer « les discutions ». Le processus qui conduit à aboutir à en ensemble qui dialogue encombrerait exagérément ce didacticiel. Donc, pour celles et ceux qui seront concernés, les démonstrateurs et les développements techniques sont regroupés dans le sous-dossier <Diverses_Experiences_7 >. Y figure également un document Dialogue entre machines.pdf qui fait pas moins de 10 pages, c’est dire si le sujet est dense.
La suite est ici.
