En dan ipv "serieeel" moet dat gewoon RS485 zijn. Toch?
Dit wordt, schat ik, veel te ingewikkeld voor de TS. Die wil gewoon op 3 plekken de vochtigheid en temperatuur meten en heeft drie DHT22's (*) aan z'n arduino gehangen.
@exfietser: In het datasheet dat door Arco gelinkt is, zie je na verloop van tijd een golf-vorm-plaatje. Daar staat het eerste deel van de golfvorm extra dik gedrukt met als onderschrift: "by the host". (of zoiets).
De host stuurt een startpuls, daarna gaat die de datalijn pollen: na iedere opgaande flank: 35 us wachten en dan het databit inlezen van de communicatiedraad. Zo haal je bijna? 40 bitjes binnen (#).
Als de TS zegt dat de chip "vastloopt" dan denk ik dat er powerdips op de lijn zitten waardoor de chip dus onderuitgaat maar net niet genoeg om de brownout reset te triggeren.
Er zijn systemen zoals i2c en dit (en de echte) one-wire protocol waarbij het "hoog" niveau door een weerstand geleverd wordt.
Bij lange draden op zo'n protocol is het van belang om de weerstand zo laag te kiezen dat de RC van de draad en de R laag genoeg is dat je er geen last van hebt bij het protocol. Omdat "ouderwets" i2c met iets van 4k7 op 5 microseconde per halve-periode werkte en 4m kabel aankon, zou ik bij deze ongeveer 10x langzamere situatie niet direct een probleem verwachten met een weerstand van 4k7, 5.1k of 10k. Maar het zou kunnen. Een onnodig lage weerstand verhoogt het stroomverbruik, en kan in extreme gevallen te veel zijn voor de output poort. Bij de arduino is dat officieel 20mA, dus 5V/20mA = 250 Ohm. Dat is het minimum. De DHT zou best wel eens minder sterke drivers kunnen hebben -> ik zou niet lager gaan dan 1k.
Als dat het geval is, dan loopt niet de DHT22 maar de arduino vast. Als die verwacht 37 of 40 bits te ontvangen en geen timeout heeft dan hangt ie als er een start-van-een-bit puls gemist wordt.
Wat ik vroeger deed met de DHT22 is de lengte van de "hoog" periode meten. Ik kreeg dan iets van 5 loops voor een 0 en 14 voor een 1. Nu ik ouder ben heb ik bovenstaande truuk: "na 35 microseconden het datbit van de lijn plukken" bedacht. Met mijn oude implementatie zou je "te kleine weerstand" zien doordat je maar 2-3 hoog meet met uitschieters naar 1 en heel soms 0: puls helemaal gemist.
(*) En een manier om die data te presenteren: Display, link-naar-een-database, zoiets.
(#) ik zag vandaag iets van "bitje 37" als naam voor het eerste bitje. Maar nu ik dat afrond naar "bijna 40" denk ik me te herinneren: "precies 5 bytes, ja dat was het".