schmidt100:
@jurs: Ich habs ausprobiert und die DHT Library scheint das Problem zu sein. Ich habe die Library von:
Guckst Du Quellcode, weißt Du Bescheid:
boolean DHT::read(void) {
...
// pull the pin high and wait 250 milliseconds
digitalWrite(_pin, HIGH);
delay(250);
Das ist Code, den Du für nicht-interaktive Programme gebrauchen kannst. Sagen wir mal ein batteriebetriebener Temperatursensor ohne jegliche Bedienelemente hängt im Garten und funkt alle drei Minuten seine Temperatur an eine Wetter-Basisstation im Haus. Dem Sensor im Garten ist es völlig egal, ob Du in den drei Minuten zwischen zwei Messungen das Programm für eine Viertelsekunde blockierst oder nicht. Da ist so etwas brauchbar.
Bei interaktiven Programmen, die blitzschnell auf Benutzereingaben reagieren sollen, ist das Programm mit einem "delay(250)" von einer Viertelsekunde in jeder loop schon total verkackt.
Solche digitalen Temperatursensoren benötigen alle eine bestimmte Auslesezeit zwischen "Anforderung einer Messung" und "Auslesen der Daten". Und im Endeffekt muß die Library genau das auch widerspiegeln, d.h. es muss eine Funktion zum Anfordern einer Messung geben und eine andere Funktion zum Abholen der Messdaten, die man dann erst nach einer bestimmten Zeit aufruft. Und zwischendrin kann das Programm eine Viertelsekunde lang beliebige andere Dinge tun, z.B. auf Tastendrücke reagieren.
Deine Library ist wegen der Verwendung von "delay(250)" für interaktive Programme unbrauchbar.
Du kannst bei einem interaktiven Programm allenfalls die negativen Auswirkungen verringern, wenn Du die Temperatur seltener ausliest. Mal angenommen,, Du liest die Temperatur statt "ständig in der loop" nur noch "einmal pro Minute" aus, dann würde auch nur einmal pro Minute das delay auftreten und damit das Programm viel seltener für Eingaben blockiert sein.
Aber im Endeffekt wäre das nur ein Herumstümpern an Symptomen. Für ein interaktives Programm muss viel eher das Auslesen des Sensors optimiert werden.