DHT11 one wire

MGU

Senior Member
Bonjour,

J'essaye de voir comment on peut lire les données d'un DHT11, capteur "one wire" de température et humidité avec un picaxe.

Ces données se composent d'une séquence de 40 bits d'une largeur de 28 ou 70 µs, espacés de 50 µs.
Sur un M2 à 32 MHz, la mesure, le traitement et le stockage de chaque bit demanderaient plus de 300µs (à votre avis?)

Sauf erreur, exit les M2

Les X2 ont des commandes spécifiques, OWin et OWout et d'après la doc, un "One wire tutorial" que je n'ai pas trouvé.

Où trouver ce tutorial?
Peut-on lire un DHT11 avec un picaxe?

Merci pour vos réponses
MM
 

westaust55

Moderator
Un 1-Wire d'instruction ou au moins l'information est disponible ici (post43):
http://www.picaxeforum.co.uk/showthread.php?15306-One-Wire-Devices-Networks/page5


C'est apparemment une version de propriété industrielle des communications de 1 fil. Il semble peu probable que les commandes de PICAXE OWIN et d'OWOUT fonctionneront avec ce dispositif.
http://www.picaxeforum.co.uk/showthread.php?19118


Une fiche technique en Anglais est disponible ici:
http://www.robotshop.com/PDF/dht11.pdf


Un exemple de code pour l'arduino est ici:
http://www.robotshop.com/forum/showthread.php?902
Notez que le code pour l'arduino est converti en assembleur et court ainsi beaucoup plus rapidement qu'un programme de PICAXE
 

MGU

Senior Member
bonjour Westaus55

Merci pour les liens, j'ai aussi constaté que les protocoles "One wire" des DHT11 et ceux de Maxim (protocole Dallas) sont différents.

Le DHT11 est plus simpliste, pas de code famille, pas de commandes ROM,....

La commande Owout des Picaxes est donc totalement inadaptée. Mais elle peut probablement être remplacée par pulsout.

Pour la lecture de la réponse, je ne sais pas encore comment elle va être "digérée" par Owin. J'attends des DHT11 pour tester.

C'est pas forcément perdu d'avance si owin ne mesure que le rapport cyclique du bit.

MM
 

zebulon

Member
Bonjour,

J'avais fait quelques expérimentatiosn avec un 28X2 poussé jusqu'à setfreq M16 et ce n'est pas assez rapide
N'ayant pas de quartz, je n'ai pas pu essayé avec setfreq EM64.

Sinon, pour distinguer les impulsions court et longue, il faut utiliser par exemple

pulsin C.4,1,w1

C.4 = port de lecture
1 = détection sur un front montant
W1 = variable word de stockage de la durée de l'impulsion

Mon code pour tester :

Code:
#picaxe 28X2

symbol i = b0
symbol val  = b1

setfreq M8

pause 2000

output C.4

debut:
	let ptr = 10
	high C.4
	pulsout C.4, 5

	for i = 1 to 40
		pulsin C.4,1,W1
		if W1 < 10 then
			put @ptrinc, "0"
		else
			put @ptrinc, "1"
		endif
	next i

	let ptr = 10
	for i = 1 to 40
		get @ptrinc, val
		sertxd(val)
	next i
	sertxd(13,10)

	pause 2000

	goto debut
A+,
Guillaume
 
Last edited:

MGU

Senior Member
bonjour zebulon,


J'attends des DHT11 pour tester pulsin et autres

Mais, les premiers essais avec un 20X2 à la fréquence max de 64 MHz, montrent que le moindre if sur la variable w de pulsin prend plus de temps que 50µs.

Il semble incontournable de devoir passer par une commande écrite en assembleur.

Owin était la réponse, je garde un espoir (tout petit), les bits de owout ont une longueur de 105µs, assez loin des 60µs du protocole Dallas, alors....


Michel
 

PieM

Senior Member
Bonjour,

Je ne sais si c'est accepté par la syntaxe, mais dans la mesure ou la valeur pulsin est inférieure à 254, pourquoi ne pas utiliser une variable byte qui elle serait stockée telle quelle puis traitée dans un second temps ?

la boucle ne serait plus que :

for i = 1 to 40
pulsin C.4,1,@ptrinc
next i
 

zebulon

Member
Bonjour,

Oui tout a fait, j'avais fait l'essai comme cela, mais ça n'a pas mieux fonctionné.

On peut aussi mettre 40 pulsin l'un en dessous de l'autre

pulsin C.4,1,@ptrinc
pulsin C.4,1,@ptrinc
pulsin C.4,1,@ptrinc
.
. (40 fois)
.
pulsin C.4,1,@ptrinc
pulsin C.4,1,@ptrinc

pour éviter les tests de la boucle for, mais à 16Mhz, ce n'est pas encore assez rapide.

Il reste a essayer avec un quartz externe.
Il y a eu une discussion sur le forum anglais et personne n'a apporté de réponse positive.

Guillaume
 

MGU

Senior Member
Bonjour,

Merci pour vos réponses.

Même avec un 20X2 à 64 MHz, le temps est compté.

Ex:

pulsout C.1,1
pulsout C.1,1

donne deux impulsions <1µs espacées de 45µs

avec un "put @ptrinc, b0" au milieu, l'espacement passe à 88µs
dans une boucle, on passe à 124µs;

Il n'y que 50µs entre les "bits" courts ou longs du protocole DHT11

Seule solution qui me paraît jouable est de stocker les données pulsin dans le scratchpad comme dans l'exemple de zébulon, sans boucle.

A 64MHz, le "bit long" de 70µs donne 112 unités pour la variable pulsin,

Je verrai ce qui se passe quand j'aurai les bestioles.

Pas avant quelques semaines, elles arrivent à pied par la Chine...

Michel
 
Last edited:

PieM

Senior Member
Bonjour,

juste une petite remarque: sauf erreur de ma part, la meilleure syntaxe est @ptrinc = b0 au lieu de put @ptrinc, b0
 
Top