DHT11 de Dhruba Saha v2.1.0

Cette librairie (elle n'est pas la seule) va nous permettre d'utiliser le capteur de température et d'humidité construit sur la puce du même nom avec notre carte arduino. J'utiliserai pour tous les tests une vraie carte et non pas un clone.
           
Ci-dessus une photo du capteur avec son connecteur, on peut voir qu'une des broches de ce connecteur est non connectée, on peut donc se dire que I2C et SPI, on va oublier et effectivement, en voyant quelques passages du datasheet, on comprend que la broche SIG va fournir toutes les données sur une entrée digitale de l'arduino.

Le datasheet et le code de la librairie (DHT11.h et DHT11.cpp)

Processus de communication : Interface série (bidirectionnelle monofilaire)

Je ne vais pas tout détailler mais reprendre quelques chronogrammes du datasheet et les relier au code de la librairie.

La méthode startSignal est appelée dans readRawData. On voit que les temps d'attente sont ceux mentionnés dans le chronogramme.

Donc à  la fin des 40us, le MCU passe en écoute. La réponse du DHT consiste en 2 période de 80us au niveau bas puis au niveau haut. A ce moment, débute la transmission des bits correspondants à l'humidité relative et la température, c'est la méthode readByte qui suit ces chronogrammes.

L'idée est de remplir un byte avec chacun des bits envoyé par le DHT, le 1er while correspond aux 50us du DHT pour le signal bas, si le signal haut dure au moins 30us alors le bit reçu est un 1 sinon c'est un 0. Après le remplissage de value par l'opérateur de décalage uniquement pour les bits à 1, on trouve un 2ème while qui attend la fin des 70 us pour soit repartir pour un tour de boucle, soit retourner value dans le tableau data car à  la fin de la boucle "for" , les 8 bits ont été en théorie reçus.

A noter que pour les bits à 0, value n'est jamais calculée et le 2éme while n'attend pas car le DHT a déjà mis la ligne à l'état bas avant la fin du délai de 30us.

L'auteur a aussi codé le timeout et le check-sum qui remontent une erreur.

J'ai indiqué au début que cette librairie n'était pas la seule et en particulier avec l'utilisation de celle-ci, l'atméga passe beaucoup de temps à attendre, dit comme ça, cela a l'air anodin, mais à l'échelle du temps mcu à une fréquence d'horloge de 16Mhz et compte-tenu que le datasheet indique que la plupart des instructions s'exécutent en 1 cycle d'horloge, 30us correspondent à 480 cycles où il ne se passe rien. 

Si je ramène cela à l'échelle humaine et prenons comme unité de temps la seconde, c'est comme si vous attendiez 480 secondes un évènement comme un coup de fil ou une porte qui s'ouvre.

Je n'ai pas étudié les autres librairies mais une semble non-bloquante sans doute codée avec des interruptions.

Vidéo du capteur sur afficheur oled.