regelmäßige loop Verzögerungen

International Deutsch
1

Hallo,

nachdem das Problem mit dem Dallas-Sensor behoben war und alles in mein Hauptsketch importiert war, habe ich weiterhin die loop Zeiten im Auge behalten. Dabei mußte ich feststellen, dass regelmäßig die loop Zeit auf 29ms wächst und sonst immer bei 1-2ms liegt.

Habe das Problem durch auskommentieren sämtlicher Funktionen versucht auf die Schliche zubekommen und war mir dann sicher, dass die Funktion "TempToDisplay" die loop verzögert. Jedenfalls kann ich den Effekt mit auskommentieren und wieder dazu nehmen damit nachvollziehen. So richtig einleuchten wollte mir das jedoch nicht, da ich ja mehrere Daten auf das Display ausgebe nicht nur diese eine.

Also habe ich "TempToDisplay" in meinen reinen "Dallas_WaitForConversion3" Sketch eingebaut und siehe da, loop Zeiten von 1 -2ms.

Dann habe ich sämtliche Funktion vor setup deklariert. Bringt auch nichts.

Jetzt meine Frage, ist Euch ein Grund ersichtlich warum die loop Zeit im Zusammenhang mit der Temp.ausgabe in die Höhe schießt? Oder hat das andere Ursachen?

Dallas_WaitForConversion3_002.ino (4.55 KB)

SDcard_Write_Taster_LcdSPI_DS1820_009.ino (20.7 KB)

2

Hallo,

ich hab jetzt in der loop mehrere µs Meßpunkte gesetzt, diese ausgeben lassen und in Excel zur Auswertung formatiert.
Fakt ist, dass hat sich damit bestätigt, dass das auslesen und anzeigen der Dallas Temperaturen die loop >20ms beansprucht.
Im einfacheren Testsketch ist diese Funktion auslesen und anzeigen jedoch keine Bremse. Die gesamte loop läuft konstant unter 2ms.

Ich weis nicht was in dem großen Sketch anders sein soll? Sieht jemand einen Unterschied? Gibts Probleme mit Variablennamen?

Arduino Zeitmessung.xls (314 KB)

SDcard_Write_Taster_LcdSPI_DS1820_009a.ino (21.4 KB)

Dallas_WaitForConversion3_002.ino (4.45 KB)

3

Hallo,

hab jetzt das auslesen und anzeigen der Temperaturen extra unterteilt und mir die Zwischenzeiten µs ausgeben lassen.
Das auslesen der Sensoren beansprucht plötzlich mehr Rechenzeit im Vergleich zum einfachen Testsketch. Warum nur?

Arduino Zeitmessung 2.xls (78.5 KB)

SDcard_Write_Taster_LcdSPI_DS1820_009b.ino (21.1 KB)

4

Erst mal Glückwunsch zu deinem sehr methodischen und strkturierten Herangehen um das Problem zu isolieren.
Das sieht man so nicht oft.

Zu deinem Problem direkt kann ich nichts sagen. Mir ist noch unklar welche deiner geposteten sketche der "einfache Testsketch" ist, der schneller läuft.

5

Hast du mal probiert den Sensor z.B. nur alle 500-1000ms auszulesen? Im Moment sieht das so aus als ob es in jedem loop Durchlauf geschieht. Dann hast zwar erst recht unterschiedliche Durchlaufzeiten, aber es ist nur selten mal etwas länger.

6

Hallo,

Danke.

Der einfache Testsketch der optimal läuft ist der "Dallas_WaitForConversion3". Der ist aus den beiden async Wait Bsp. der Dallas-Library entstanden und am Ende mußte ich feststellen, dass ich genau auf die Methode kam die Serenifly mir schon die ganze Zeit anbieten wollte. Zu der Zeit habe ich aber den Wald vor lauter Bäumen nicht gesehen. Sein Programmierstil sieht nur schöner aus.

Ich habe dann nichts weiter gemacht, als das erlernte in mein großes Projekt zu übernehmen. Und zack, habe ich unerklärliche Verzögerungen beim Temperatur auslesen drin. Die zusätzlichen includes Librarys vom großes Projekt hatte ich mal Testweise mit in der "Dallas_WaitForConversion3" kompilieren lassen, hatte jedoch keine Auswirkung auf die Looptime.

@ Serenifly. Die Auslesewartezeit hatte ich schon höher gesetzt wie 750ms. Hatte keine Auswirkung. Und laut Excelauswertetabelle wird auch wirklich nur alle 750ms ausgelesen. Das sollte passen. Direkt nachdem auslesen erfolgt wieder ein Conversation Request. Sieht man auch sehr schön in der Excelauswertung.

Was ich noch machen könnte, wäre Deine Request und Auslese Funktion zu verwenden. Könntest Du mir die nochmal bitte geben mit allen was dazu gehört?
Zur Zeit denke ich das irgendwleche Variablen durcheinander kommen und der arme µC muß die dann jedesmal sichern, neu sortieren usw. Ich habe keine Ahnung.

7

Ja, stimmt. Du hast ja durch das relativ lange Delay der Wandlung der alten Sensor Version schon eine anständige Verzögerung zwischen den Messungen. Noch ein Delay würde das nur noch mehr verzögern.

Bei mir sieht es so aus:

boolean readTemperatureSensors()
{
	static unsigned long previousPollingMillis;
	static unsigned long previousRequestMillis;
	static boolean dataRequested;

	if(dataRequested == true && millis() - previousRequestMillis > 100)      //du willst hier 750
	{
		temperatures[0] = sensors.getTempC(sensorList[0]);
		temperatures[1] = sensors.getTempC(sensorList[1]);
		dataRequested = false;
		return true;
	}
	
	if(dataRequested == false && millis() - previousPollingMillis > POLLING_INTERVAL)
	{
		previousPollingMillis = millis();

		sensors.requestTemperatures();
		dataRequested = true;
		previousRequestMillis = millis();
	}

	return false;
}

Funktions-Prototypen sind übrigens auf dem Arduino i.d.R. nicht nötig. In Standard C ja, aber die IDE legt die selbst im Hintergrund an. Die sind nur dafür da damit die Funktion bei der Verwendung auch bekannt ist. Ohne die müsste man eine Funktion vor der Verwendung implementieren, d.h. darüber.

8

Hallo,

mir fehlt was. Wie rufst Du die Funktion in der loop auf?
Das muß irgendwas mit if Funktion wahr oder falsch ist, dann mache ... nur was dann machen?. Funktionrückgabewert abfragen und gleiche Funktion nochmal abrufen? dataRequest kann nicht nicht abfragen, weil die ist lokal. Ich blick da nicht durch. Ist für mich zu trickreich geschrieben.
Wofür brauchst Du einen Rückgabewert der Funktion und warum hat dataRequest keine Anfangsdefinition? Sämtliche Wartezeiten regelt Deine Funktion intern selbst laut meiner Auffassung. Wie groß ist Dein Polling_Intervall?
Und warum hast Du eine extra Wartezeit nachdem auslesen drin? Man kann doch direkt nachdem dem auslesen einen neuen Request senden?

Tut mir leid, zur Zeit wirft das mehr Fragen auf.

9

Globale und statische Variablen werden anders als lokale nicht-statische Variablen automatisch auf 0 initialisiert. Der Ausgangswert ist also false.

Einfach abfragen ob die Funktion true zurückgibt:

if(readTemperatureSensors() == true)
{
}

Im Moment frage ich alle 500ms ab (bei 100ms Umwandlungszeit). Das ist aber erst mal nur zum Test. Später vielleicht alle 1 Minute. Wieso willst du die Temperatur so schnell abfragen? Die ändert sich nicht so schnell. Die Dallas Sensoren sind auch durch das Gehäuse etwas träge.
Für eine Anzeige muss das nur so schnell sein, dass es flüssig ist. Da reichen auch etwas längere Zeiten. Bei mir soll das eine Heizungssteuerung werden. Das System lässt sich gar nicht so schnell regeln wie man da messen kann. Und muss auch nicht so schnell sein.

EDIT:
Wobei das bei dir durch die 750ms Wandlungszeit insgesamt länger dauert wie bei mir zur Zeit. Da ist das ohne zusätzliches Delay für eine Anzeige ok. Aber das kommt auf die Anwendung an. Wenn du z.B. die Temperatur automatisch auf SD loggen wolltest, wäre das zu oft.

10

Hallo,

aller Sekunde würde bei mir auch ausreichen, 750ms warte ich sowieso schon zwangsweise.
Deine Wandlungszeit beträgt 100ms und Deine Request-Intervall beträgt demnach 500-100, also 400ms. Nach den 400ms und anschließenden 100ms Wandlungszeit bekommst Du aller 500ms einen neuen Wert. Richtig erkannt?

Ich wußte nicht was ich in die { } rein schreiben sollte. Weil ich schon alles in der Funktion stehen hatte. :wink:

Ich habe das bei mir jetzt so eingebaut.

if(readTemperatureSensors() == true)
   {
    TempToDisplay( 0,1,TempSensor1);    // Displayausgabe
    TempToDisplay(10,1,TempSensor2);
   }

und Deine Funktion folgendermaßen für mich angepaßt, sodass ich noch eine extra Warte von 250ms habe zwischen auslesen und neuen Request.

 boolean readTemperatureSensors()
   {
	static unsigned long previousPollingMillis;
	static unsigned long previousRequestMillis;
	static boolean dataRequested;

	if(dataRequested == true && millis() - previousRequestMillis > 750)      
	{
		TempSensor1 = sensors.getTempC(sensor1);  // 1. Dallas Sensor auslesen (Device Adresse)
                TempSensor2 = sensors.getTempC(sensor2);  // 2. Dallas Sensor auslesen (Device Adresse)
		dataRequested = false;
		return true;
	}
	
	if(dataRequested == false && millis() - previousPollingMillis > 1000)
	{
		previousPollingMillis = millis();

		sensors.requestTemperatures();
		dataRequested = true;
		previousRequestMillis = millis();
	}

	return false;
   }  // Ende boolean readTemperatureSensors

Ergebnis ist, dass die loop immer noch beim auslesen >20ms blockiert. Also alles beim alten. :frowning:

@ Serenifly: hast Du Deine Looptime schon einmal vermessen für die Dallas Geschichte? Wäre interessant.

SDcard_Write_Taster_LcdSPI_DS1820_010.ino (21 KB)

11

Spontan würde ich die Schuld irgendwie auf das Display schieben, aber sowie du es sagst liegt es nicht daran.

Deine Wandlungszeit beträgt 100ms und Deine Request-Intervall beträgt demnach 500-100, also 400ms. Nach den 400ms und anschließenden 100ms Wandlungszeit bekommst Du aller 500ms einen neuen Wert. Richtig erkannt?

Ich glaube alle 600ms. Da ich alle 500ms anfordere und danach 100ms auf ein Ergebnis warte. Erst wenn der Sensor ausgelesen wurde, erfolgt wieder die nächste Anforderung. 500ms. Die zwei if-Abfragen sind voneinander unabhängig. Wenn die obere 100ms dauert wird die nächsten Anfrage trotzdem 500ms nach der letzten ausgeführt.

Gemessen habe ich es aber nicht ob das wirklich stimmt. Mir ist nur wichtig, dass der Temperatur-Wert korrekt ist und der Touch Screen dabei nicht blockiert wird.

EDIT Zusammenfassung (hat ein paar Anläufe gedauert :frowning: ):
Die normale Loop-Zeit liegt bei etwa 20-30µs wenn sonst nichts gemacht wird.

Wenn der Temperatur-Sensor ausgelesen und angezeigt wird habe ich 70300µs! Da ist aber auch noch zweimal dtostrf() drin und die TFTs sind recht langsam.

Wenn ich nur den Sensor auslese und nicht anzeige sind es 25900µs. Deckt sich also mit dem was du hast

12

Hallo,

Danke für Deine Zeitnahme. So langsam weis ich nicht ob ich ein Phantom jage oder doch ein kleines Problem im Programm steckt.

Ich habe mir nochmal das Library Bsp. WaitForConversion2 als Basis genommen, dieses soweit Stück für Stück für meine Sensoren und Display umgebaut bis es lief. Dabei die grundlegende Auslese und Request if Struktur beibehalten. Damit erreiche ich Loopzeiten von max 1ms.

Danach habe ich das exakt 1:1 in meinen großen Sketch übernommen. Inkl. aller Änderungen im setup und davor.
Im Ergebnis habe ich jetzt Loopzeiten von 30ms wenn er ausliest.

am Taster debouncen liegt es leider auch nicht. Zeit geändert, Loopzeiten unverändert.

Ich bin am Ende mit meinem Latein.

"WaitForConversion2_Vermessung_004" läuft super
"SDcard_Write ... " hat nachwievor ein Problem.

Was ich noch machen könnte wäre, meinen großen Sketch Stück für Stück zurückbauen bis soweit zurück bin das ich damit beim Bsp. Sketch lande. Nur habe ich ja schon das Ding vermessen und weis das es am auslesen hängt. Für heute ist für mich erstmal Pause. Ideen sind herzlich willkommen.

SDcard_Write_Taster_LcdSPI_DS1820_012.ino (19.5 KB)

WaitForConversion2_Vermessung_004.ino (3.48 KB)

13

Es sieht für mich so aus als ob die 20-30ms normal für die OneWire Kommunikation sind und dass das generell langsam ist.

Ich habe mal das WaitForConversion Beispiel genommen. Die Zeiten sind da nur für den Request gemacht. Wenn das so ändert das beide Varianten 12 Bit verwenden und wenn man die Ausgaben etwas nach unten rückt so dass sie das Auslesen mit einschließt wird beidesmal (blocking und non-blocking) ca. 780ms angezeigt. Bei 9 Bit sind es auch bei non-blocking noch 124ms. Also immer noch 20-30ms mehr als eigentlich für die Wandlung gebraucht wird.

Genauso nur setResolution(). Das dauert anscheinend 93ms :o

14

Hallo,

es lässt einem ja doch keine Ruhe. Also doch noch den großen Sketch zurückgebaut und als ich das hier

 // Zeit seit µC Reset wird formatiert und zerlegt
 ZeitstempelSekunden = Zeitstempel/1000;       // Bsp. aus 8.000.000millis werden 8000sec
 LaufendeStunden = ZeitstempelSekunden/3600;   // 8000/3600=2,22 > 2h
 LaufendeMinuten = (ZeitstempelSekunden/60)-(LaufendeStunden*60);  // (8000/60)-(2*60)=13min
 LaufendeSekunden = ZeitstempelSekunden-(LaufendeStunden*3600)-(LaufendeMinuten*60); // 8000-7200-780=20sec

auskommentiert hatte lagen meine loop Zeiten bei 1ms und der Effekt mit 30ms war weg.
Allerdings erschließt sich mir nicht warum diese Rechnerei jetzt die Ursache dafür sein soll. Bei meiner ersten Vermessung benötigen diese 4 Zeilen 0,9ms. Allerdings sehe ich auch einen Effekt, dass diese 4 Zeilen immer nur 0,5ms benötigen wenn die Temperatur ausgelesen wird und der Sketch ausgebremst wird. Siehe erste Exceltabelle. In Spalte R sieht man den Effekt mit den 28ms wenn sie aller 750ms auftreten und Spalte S daneben die Zeit für obige 4 Zeilen.

SDcard_Write_Taster_LcdSPI_DS1820_013.ino (12.2 KB)

Arduino Zeitmessung 1.xls (314 KB)

15

Hallo,

also das die OneWire Kommunikation immer 20-30ms benötigt kann nicht sein. Dann würde ich mit dem Bsp. keine konstanten 1ms messen im Vergleich.

"Genauso nur setResolution(). Das dauert anscheinend 93ms."
Ja das dauert etwas, wird aber nur einmal im setup gesetzt. Stört demnach die loop nicht.

16

Hallo,

also ich jage irgendwie einen Geist. Gestern habe ich mit dem auskommentieren von unten nach oben begonnen. Und dachte es liegt an reinen 4 Rechenzeilen. Blieben als letzte übrig, nach auskommentieren auch dieser flutschte alles. Aber logisch war es nicht.

Heute habe ich von oben nach unten der Reihe nach auskommentiert. Tja, schon seltsam. Erst als ich unten den letzten Funktionsaufruf rausnahm flutschte alles. Dann habe ich bis ZeitstempelToDisplay(8,0); von unten wieder alles dazu genommen. Funktionierte nicht mehr. Und dann gab es seltsame Effekte. Ob ihr mir das glaubt oder nicht. Wenn ich ZeitstempelToDisplay(8,0); rausnehme und wieder reinnehme, sollten doch immer reproduzierbare Ergebnisse rauskommen. Tut es aber nicht. Manchmal läuft die loop astrein, manchmal wieder nicht. Ich hatte selbst einmal die 30ms Verzögerung wo nur noch die obere Dallas Funktions aktiv war. Danach nicht mehr. Bis ich wieder mit dem Rest der loop experimentiert hatte.

Das doppelt gesetzte delayInMillis vor und in setup habe ich schon korrigiert. Bringt auch keinen erhofften Vorteil.

Irgendwas spinnt hier "zufällig" rum. Nur was? Können sich die Librarys gegenseitig das Leben schwer machen?

17

Hallo,

so, weiter getestet.

Im kleinen kurzen Testsketch "WaitForConversion_Vermessung_004" bekomme ich konstante Loopzeiten von 0 -2 ms angezeigt. Hier ist demnach alles i.O.

Heute habe ich wieder meinen großen Sketch "SDcard_Write_LcdSPI_DS1820_016" genommen und alles in der loop gekürzt bis es genauso war wie im "WaitForConversion_Vermessung_004". Also nur Dallas Sensoren beackern und Werte auf Display ausgeben. Damit hatte ich wieder Loopzeiten von ca. 28ms im maximum.

Also Problem wie gehabt. Obwohl das auch schon mal anders aussah.

Dann habe ich in beiden Sketchen sämtliche Befehlszeilen einzeln vermessen und direkt ausgeben lassen. Und jetzt wirds noch unerklärbar interessant. Sämtliche benötigte Zeiten in µs sind bei allen beiden Sketchen gleich. Demnach dauert ein Sensor auslesen 13ms. Da ich 2 habe sind wir schon bei 26ms. Abzüglich der benötigten seriellen Ausgabezeit, die ich nicht kenne. Ausgaben der Funktion Looptime mit ihren min, max, avg bekam ich keine angezeigt. Dauert wahrschlich zu lange. Habe ne weile gewartet.

setRes1 12928
setRes2 13000
setWait 4
firstRequest 2216

Looptime 12
if 4294967060
Sensor1 13244
Sensor2 13060
Display1 464
Display2 468
request 2224
setmillis 4

Die Daten im seriellen Monitor kommen ohne stocken ohne Pause ohne Ende. Das bedeutet, die Sensoren werden in jeden Durchlauf beackert. Wahrscheinlich dauert ein loop durch die Zwischenmessungen länger wie 750ms. Was jedoch jeden sofort ins Auge fallen sollte ist die hohe Zeitnahme der if Abfrage. Das wären ja 71 Minuten. Wenn das so wäre, würde ich jedoch nie neue Temperaturwerte sehen und der µC wäre blockiert. Die 71min sind jedoch dem Overflow der micros() verdammt nah. Stimmt hier was nicht? Verrechnet sich jemand?

Und wenn die Sensoren wirklich jeweils 13ms benötigen, warum sehe ich diese Zeit als Maximum nicht auch im kleinen WaitForConversion_Vermessung_004" Sketch?

SDcard_Write_Taster_LcdSPI_DS1820_016.ino (20.1 KB)

_017_Vermessung.ino (3.97 KB)

_018_Vermessung.ino (4.9 KB)

18

Also, was mir spotan auffällt:
Serial.begin(57600); in 017_Vermessung.ino
Serial.begin(9600); in WaitForConversion_Vermessung_004.ino

Bei 9600 Baud kann die Übertragung der Zeile "Sensor1 13244" schonmal 20ms dauern.

if 4294967060

vorher = micros();
if (millis() - lastTempRequest >= delayInMillis) // waited long enough??
nachher = micros();
diffe=nachher-vorher; Serial.print("if "); Serial.println(diffe);

du speicherst "vorher" bei jedem loop durchlauf ab, "nachher" aber nur, wenn die if-Bedingung erfüllt ist, also nur alle 800ms.
Also ist bei fast allen Abfragen nachher kleiner also vorher. => Die Ausgabe stimmt, die Abfrage ist unsinnig. (Hast du vielleicht nur die geschweiften Klammern vergessen? oder falsch gesetzt?)

Was mir bei deinen ganzen Messungen gerade nicht ganz klar ist: Wo genau ist das Problem?

19

Hallo,

Danke das Du dir die Zeit genommen hast mal reinzuschauen.

guntherb:
Also, was mir spotan auffällt:
Serial.begin(57600); in 017_Vermessung.ino
Serial.begin(9600); in WaitForConversion_Vermessung_004.ino
Bei 9600 Baud kann die Übertragung der Zeile "Sensor1 13244" schonmal 20ms dauern.

okay stimmt, sollte sich jedoch nicht auf die eigentlichen einzelnen Zeitnahme auswirken.
Deswegen hatte ich mir überlegt vor und nach einer Befehlszeile die Zeit zu speichern um dann in Ruhe die Differenz zu bilden und seriell auszugeben. Die Messung an sich dürfte mit serial.print dann nicht verfälscht werden. Bestätigen auch meine Messungen, in allen Sketchen gleiche Zeitausgaben.

du speicherst "vorher" bei jedem loop durchlauf ab, "nachher" aber nur, wenn die if-Bedingung erfüllt ist, also nur alle 800ms.
Also ist bei fast allen Abfragen nachher kleiner also vorher. => Die Ausgabe stimmt, die Abfrage ist unsinnig. (Hast du vielleicht nur die geschweiften Klammern vergessen? oder falsch gesetzt?)

Ja okay, das ist Schwachsinn. Ich wollte die benötigte Rechenzeit für die IF Abfrage wissen. Habs rausgenommen.

Was mir bei deinen ganzen Messungen gerade nicht ganz klar ist: Wo genau ist das Problem?

Mein zufällig entdecktes Problem ist, dass mir Deine Looptime Meßfunktion bei meinem nackten Dallas Testsketch, hier "018_Vermessung" ohne die ganzen Zwischenzeitnahmen immer konstante Loopzeiten zwischen 0 und 1ms anzeigt. Sehr selten 2ms.

Bei meinem großen "Projektsketch" gibt mir Deine Looptime Funktion jedoch Werte von maximal 30ms aus, selbst wenn ich die extrem zurückgebaut habe. Und zwar immer genau dann wenn auch die Sensoren beackert wurden. Das konnte ich mir nicht erklären versuche seitdem herauszufinden warum es Unterschiede mit dem Sketchen gibt bei den Durchlaufzeiten.

Aktuell habe ich immer noch gleiche Befehlsmesszeiten meiner Zwischenmessungen: (alles in µs)

Sensor1 13328
Sensor2 13040
Display1 472
Display2 476
request 2216
setmillis 4

jedoch sagt mir die Looptime immer Zeiten an zwischen 0 und 1ms. Kann doch aber nicht sein, wenn 2 Sensoren auslesen schon ca. 26ms dauert und die vielen seriellen Ausgabe unbeachtet auch etwas Zeit kosten.

Aber jetzt kommst. Wenn ich die 4 Zeilen dazu nehme wo ich den Zeitstempel zerlege, was nur 120µs dauert, dann sagt mir die Lopptime immer ein max. von 31ms. Das sind doch aber alles Ganzzahlrechnungen. Warum sollen die bremsen? Außerdem werden die max. 31ms nur gemessen wenn auch die Sensoren beackert wurden. Also während die Sensoren in Ruhe gelassen werden sind es max. 4ms.

Was hat jetzt das eine mit dem anderen zu tun? Ohne Zeitstempelzerlegung ist alles bestens. Egal wie ich es drehe und wende, ich kanns mir nicht erklären.

Wenn die Looptime Funktion immer max. 30ms anzeigen würde, dann hätte ich kein Problem. Das wäre für mich glasklar das das Sensoren auslesen wirklich ca. 26ms dauert. Nur in diesem einem kurzen Sketch zeigt die Looptime konstant max. 1ms trotz Sensoren auslesen.

Problem irgendwie verständlich erklärt? Ich hoffe es, anders und besser kann ich es nicht erklären.

v017_Zeitnahme.txt (57.6 KB)

DS1820_017.ino (19.5 KB)

v018_Zeitnahme.txt (245 KB)

Vermessung_018.ino (4.69 KB)

20

Hallo,

konnte es noch näher einkreisen. Mein Problem ist, anders ausgedrückt, dass sich die Meßzeiten widersprechen. Und ich weis nicht welche stimmt und welche nicht.

Bleiben wir jetzt beim aktuellsten Sketch "DS1820_019"

Die LoopTiming Funktion zeigt mir max. Werte von 1ms an, trotz das das Sensoren Zeugs ca. 26ms dauert, wenn es aufgerufen wird.

Sensor1 13352
Sensor2 13056
Display1 460
Display2 472
request 2216
setmillis 8
durchschnittlich alle 0ms
minimaler Abstand 0ms
maximaler Abstand 1ms

Nehme ich die LoopTiming Funktion raus und messe die Differenz zwischen Loop Anfang und Ende selbst, erhalte ich 31472µs wenn die Sensoren aller 800ms dabei sind. Also ca 31ms. Das würde ja stimmen. Summe aller Einzelzeiten.

Gesamt 8
Gesamt 8
Gesamt 8
Sensor1 13324
Sensor2 13040
Display1 460
Display2 464
request 2224
setmillis 8
Gesamt 31472

Jetzt beschleicht mich das dumme Gefühl, dass die LoopTiming Funktion bei zu kurzen Sketchen irgendwie falsch misst. Kann das sein? Und sobald der Sketch wächst haut es hin. Was ich mir aber nicht erklären könnte, warum die LoopTiming Funktion falsch messen sollte. Frage bzw. Problemstellung jetzt klarer?

DS1820_019.ino (18.5 KB)