Hallo!
Ich möchte Interruptbasiert mit 1600hz jeweils 6 Bytes über I2C aus
einem Sensor auslesen. Das klappt eigentlich auch und auf dem
Oszilloskop kann ich erkennen dass die I2C Routine schnell genug ist um
zwischen den Interrupts die Daten auszulesen, auch werden keine
Interrupts verpasst. Leider verändert sich die Situation wenn ich mit
WiFi.h und WiFi.begin(); den ESP32 ins WLAN bringe. Dann kommt es häufig
vor dass das Auslesen der sechs bytes zu lange dauert und der nächste
Interrupt verpennt wird. Offensichtlich stört also das WiFi irgendwie
das RTOS. Weiß jemand woran das liegen könnte? Auf dem Screenshot sieht
man das ganz gut. Unten der DataReady Interrupt des Sensors und oben die
Funktion des Sensors die auf dem Bild gleich zwei mal länger braucht als
normal.
A. B. schrieb:> Auf dem Screenshot sieht man das ganz gut. Unten der DataReady Interrupt> des Sensors und oben die Funktion des Sensors
Für mich sieht "die Funktion" irgendwie völlig beliebig aus. Was soll
denn da wie "funktionieren"?
> die auf dem Bild gleich zwei mal länger braucht als normal.
Woran erkennt man das? Wie sollte das denn korrekt aussehen?
Soll da auf jede steigende Flanke von "blau" ein kurzer High-Impuls auf
"gelb" kommen?
> Offensichtlich stört also das WiFi irgendwie das RTOS.> Weiß jemand woran das liegen könnte?
Augenscheinlich gibt da wer die Interrupts nicht schnell genug frei. Das
ist das Hauptproblem bei schlecht programmierten Treibern.
Wird Pin15 (Kanal 1 auf dem Oszi) auf HIGH gezogen während die Funktion
den Sensor über I2C ausliest. Damit sieht man in etwa wie lange die
Funktion zugange ist.
A. B. schrieb:> Damit sieht man in etwa wie lange die Funktion zugange ist.
Ich würde mir gleich mal die eigentliche Kommunikation/Reaktion auf dem
I2C Bus ansehen.
Könnte auch sein, dass der Scheduler der readI2cTsk nicht wichtig genug
ist. Das ist das Problem bei solchen Multitasking-Dingern: wie sag ich
dem Scheduler, dass ich mir selbst der Wichtigste bin? Und wie
beeinflusse ich dadurch das Betriebssystem?
Hallo,
ich habe in einem anderen Zusammenhang im Prinzip das gleiche Problem.
Sobald WiFi aktiv ist, läuft "mein" Programm nicht mehr so zeitgenau,
wie ohne. Dass WiFi im Hintergrund aktiv ist und somit durch den
"unsichtbaren" Scheduler auch Prozessorzeit bekommt, ist natürlich klar.
Evtl. würde es helfen, hätte man hier ein paar wenige Einflüsse auf die
ganzen Zusammenhänge. Ich kann zwar einzelne Teile auf einen
Prozessorkern legen und nur dort laufen lassen (ich nutze einen alten
ESP32-WROOM-32), aber ich habe bisher nicht wirklich sinnvolle
Dokumentation über diese Zusammenhänge gefunden, also ESP32, FreeRTOS,
Scheduler und Nutzung von Interrupts für Systemkomponenten / Treiber.
Anders gesagt, WiFi kann aktiviert werden und reagiert z.B. auf versch.
IP-Grundfunktionen wie z.B. einen Ping, d.h. der ESP antwortet auf
Ping-Anfragen aus dem Netzwerk. Das geschieht dann irgendwo im Treiber
für WiFi / Netzwerk, und hierauf hat man keinen Einfluss. Für
zeitkritische Punkte müsste man also die Möglichkeit haben, andere
Interrupts vorübergehend zu deaktivieren, mit dem Wissen, dass hier
natürlich dann etwas verpasst werden kann.
Mein Fazit: mit dem ESP32 kann man viel machen, aber die volle Kontrolle
hat man mit FreeRTOS und der Arduino-Umgebung nicht.
Gruß
Nils