Incontournable sur un explorateur réel pour tenir compte de l’environnement et parer l’arrivée des tempêtes, mesurer les facteurs atmosphériques constituent pour toutes les sondes d’exploration des missions fondamentales … à condition toutefois que l’astre visité possède une atmosphère ! Déterminer la composition moléculaire, la présence d’eau, la température constituent les fondamentaux de tout géophysicien consacrant sa carrière à ce que l’on nomme l’espace. La petite station météorologique installée sur JEKERT est élémentaire. Elle ne comporte qu’un petit module ajouté au luxmètre. Bien que simplicime elle n’en mesure pas moins et avec une précision raisonnable deux données primordiales dans l’air ambiant de la petite machine : La température et surtout l’hygrométrie. D’une banalité manifeste, vraiment très facile à ce procurer dans le commerce en ligne pour des broutilles, le petit module utilisé DHT11 fait l’objet de la Fiche n°18 qui pour des raisons d’économies de papier porte sur la face verso la répartition des broches correspondant à l’implantation définitive. On peut y observer que le module DHT11 ne mobilise qu’une seule broche binaire D11 qui sera employée à la fois en entrée et en sortie.
Basés sur des phénomènes physiques complexes, les capteurs d’humidité exigent des traitements informatiques complexes pour traduire les mesures effectuées en valeur d’humidité relative par rapport à la saturation théorique de l’atmosphère terrestre. Représentant un marché de loisir considérable, les petites stations météorologiques domestiques ont envahi les chaumières. Aussi, pour gagner des parts de marché, les fournisseurs de capteurs spécifiques ont muni leurs produits d’une informatique locale les rendant presque simples à les mettre en service. Les bibliothèques spécialisées ont fait le reste. L’intégralité du traitement gérant le DHT11 se résume à peu de lignes de
code source. Le code objet qui en résulte consomme 556 octets, affichages des valeurs comprises :
Ultra classique, la séquence des directives et déclarations relative à un module particulier commence en (1) par invoquer la bibliothèque développée pour le C++ d’Arduino. Ensuite, en (2) on affecte l’identificateur Broche_Com_DH11 à la broche du microcontrôleur qui sera chargée d’établir la Communication avec la logistique interne au DHT11. Dans notre cas on affecte D11 qui seule restait disponible, car vous pouvez observer sur la Fiche n°18 que l’intégralité des ressources de l’ATmega328 sont mobilisées. Enfin en (3) on réserve la variable Humidite codée sur un octet de type byte. C’est suffisant puisque le module retourne des valeurs de pourcentage d’humidité relative dont la fourchette sera forcément limitée entre [0 et 100].
Notons au passage que pour son fonctionnement interne ce type de capteur doit aussi mesurer la valeur de la température atmosphérique, car le taux de saturation en dépend. Aussi, le fabriquant de ce circuit a ajouté un peu de logiciel à son composant. Outre l’humidité, le module fournit aussi la valeur de la température, et l’on fait d’une pierre deux coups.
Pour en bénéficier il importe de réserver une variable dédiée :
Comme on se contentera d’un affichage sous forme d’entiers, les dixièmes de °C n’étant pas pertinents dans cette application, un byte est largement suffisant.
La procédure qui affiche tous les paramètres météorologiques est élémentaire :
Les deux premières ligne (1) et (2) mesurent la valeur de la luminosité ambiante et en affichent la grandeur sur la ligne série USB du moniteur de l’IDE. Minimisant le code objet les textes sont puisés en EEPROM. l’instruction de la ligne (3), pour des raisons de lisibilité du programme se contente d’invoquer Afficher_Hygrometrie_et_Temperature() qui se charge d’afficher comme montré sur la Fig.121 la valeur du taux d’humidité et celle de la température.
Le gros du travail de mesurage est effectué en (1) par la fonction readDHT11 de la bibliothèque <DHT11.h>. Utilisant la technique des « pointeurs » repérable par le caractère & elle détermine les valeurs de Temperature et Humidite. Elle affecte également un état aux trois indicateurs DHT11_TIMEOUT_ERROR et DHT11_CHECKSUM_ERROR et DHT11_SUCCESS qui rendent compte de l’échange de données entre Arduino et DHT11. L’instruction ‚ effectue l’aiguillage du traitement en fonction de ces trois variables d’état. Les lignes (8) et (9) vont générer un BIP d’alerte sonore et un message d’erreur n°16 ou n°17 si un incident de dialogue est détecté. Par exemple « !ERR 16! » si le petit module n’est pas présent sur la ligne D11. Si le dialogue binaire est validé, en (2) les instructions de (3) à (7) vont s’enchaîner pour afficher conformément à la Fig.121 les données du DHT11. L’instruction de la ligne (6) fait afficher le caractère ‘°’ qui sur la ligne série USB est spécial, il faut en indiquer son code 186 dans la table des caractères du moniteur de l’IDE. Enfin, les divers textes qui sont affichés sur la ligne série USB sont issus de l’EEPROM et exploitent Aff_TXT_EEPROM(PTR,LGR) et Aff_TXT_EEPROM_et_CRLF(PTR,LGR). Par exemple en ligne (7) l’instruction Aff_TXT_EEPROM_et_CRLF(804,1) affiche le « C » de « °C ». Elle peut sembler exagérée juste pour afficher un caractère suivi d’un passage à la ligne. Si on la remplace par le classique Serial.println(‘C’) on aboutit à exactement la même taille de code objet et d’encombrement de mémoire dynamique, d’où le codage du source pour l’homogénéité.
La suite est ici.
