Announcement: there is an English version of this forum on Moin zusammen, hat jemand Erfahrung mit der Übertragung von Daten zwischen 2 ESPs mittels Protokoll ESP-Now ? Ich will eine Echtzeitanwendung erstellen, die Daten zwischen 2 ESPs (ESP8266 oder ESP32) austauscht bzw. sendet/empfängt. Der Empfänger soll kontinuierlich (mehrmals pro Sekunde) Daten von dem Sender empfangen. ESP-Now mit seinem Interrupthändling soweit so gut, wenn nur alle paar Sekunden mal etwas empfangen wird. Wenn aber nun merhmals pro Sekunde ein Sensorwert empfangen werden soll und dieser im Empfänger (innerhalb der Loop Prozedur) noch verarbeitet werden soll, wie kann man dies umsetzen ? Meine Befürchtung oder Unwissen ist, wie der LOOP-Teil (Hauptprogramm) noch arbeiten kann, wenn der ESP wohl aus der Interruptserviceroutine durch das kontinuierliche Empfangen der Daten , nicht oder kaum noch rauskommt. Kann man das beim ESP mit ESP-Now Protokoll irgendwie handhaben ? Merci
:
Bearbeitet durch User
David schrieb: > Wenn aber nun merhmals pro Sekunde ein Sensorwert > empfangen werden soll und dieser im Empfänger (innerhalb der Loop > Prozedur) noch verarbeitet werden soll, wie kann man dies umsetzen ? Das kann der billigste µC. Es ist eben die Frage, was Du mit "verarbeiten" so meinst, und in welchem Umfang da was verarbeitet werden soll, und was "mehrmals pro s" bedeutet, damit Du weist, wieviel Zeit überhaupt pro Runde zur Verfügung steht. Der ESP ist meines Wissens nicht unbedingt der Langsamste, da kann man auch in zehntel oder hundertstel Sekunden genug machen. Und wenn es doch nicht ganz reichen sollte, kann man immer noch überlegen, ob man nicht einen Teil aus der ISR in den Mainloop verfrachtet, um diverse Dinge asynchron erledigen zu lassen. Aber dazu musst Du eben selbst mal anfangen, und entsprechende Tests machen, um zu sehen, was Deine "Verarveituzng" so an Ressourcen braucht. Oder schreibe alles in Assembler, dann kannst Du schon im Voraus die nötigen Befehle abzählen, und die nötigen Ticks zusammenrechnen ... ;-)
David schrieb: > Wenn aber nun merhmals pro Sekunde ein Sensorwert > empfangen werden soll und dieser im Empfänger (innerhalb der Loop > Prozedur) noch verarbeitet werden soll, wie kann man dies umsetzen ? Nicht WLAN benutzen.
ESPNow ist dafür gut, habe ich selbst mal mit zwei ESP32 umgesetzt, für ein Motion Control Projekt. Darauf aufgesetzt war ein kleines zusätzliches Protokoll das gegebenenfalls auftretende Framedrops erkennen konnte. Framecounter, ACK nach Empfang etc. Ich hatte es so gehandhabt: Senden/Empfangen in einer ISR, was Standart ist, und Verarbeiten im RTOS Task. In der ISR nur Flags setzen, Ein- und Ausgangsbuffer kopieren und alles weitere außerhalb der ISR. Der ESP32 ist flott der hat mit ein paar Berechnungen keinen Stress
Johannes schrieb: > ESPNow ist dafür gut, habe ich selbst mal mit zwei ESP32 umgesetzt, für > ein Motion Control Projekt. Darauf aufgesetzt war ein kleines > zusätzliches Protokoll das gegebenenfalls auftretende Framedrops > erkennen konnte. Framecounter, ACK nach Empfang etc. Ich hatte es so > gehandhabt: Senden/Empfangen in einer ISR, was Standart ist, und > Verarbeiten im RTOS Task. In der ISR nur Flags setzen, Ein- und > Ausgangsbuffer kopieren und alles weitere außerhalb der ISR. Der ESP32 > ist flott der hat mit ein paar Berechnungen keinen Stress Danke Johannes, meine Bedenken gingen dahin, dass der Sender (ESP8266) wirklich kontinuierlich sendet und damit der Empfänger fortlaufend in der ISR (auch wenn dort wenig Code ist) sich befindet, da fortlaufend Interrupts ausgelöst werden müssten?
David schrieb: > Danke Johannes, meine Bedenken gingen dahin, dass der Sender (ESP8266) > wirklich kontinuierlich sendet und damit der Empfänger fortlaufend in > der ISR (auch wenn dort wenig Code ist) sich befindet, da fortlaufend > Interrupts ausgelöst werden müssten? Du hast das eigentliche Problem nicht erkannt: WLAN und Echtzeit-Kommunikation schließt sich prinzipiell aus. Der Kanal ist dafür einfach ungeeignet. Jedenfalls in realen zivilisierten Umgebungen. Dabei ist ganz egal, was du tust, oder wie lange irgendwelche ISRs dauern. Das Problem ist: du hast keinerlei Kontrolle darüber, was andere in denselben Funkbändern tun. Selbst wenn sich alle wenigstens an die Beschränkungen der Standards und rechtlichen Bestimmungen halten würden (was keinesfalls gesichert ist), reicht es nicht näherungsweise für irgendwas, was als "Echtzeit" durchgehen könnte.
Echtzeit ist immer relativ. Nehmen wir eine Beckhoff SPS, die mit EtherCAT angebunden in Echtzeit mit 1kHz Sensorwerte verarbeitet. Für kritische Interlocks verwende ich lieber ein FPGA, welches in Nanosekunden Sensorwerte abtastet. Da ein FPGA im Gegensatz zu einer MCU streng nach Clock arbeitet, ist dies hier ebenfalls Echtzeit. Im Bankensektor ist Echtzeit in einigen Sekunden definiert. Meiner Meinung nach ist hier die Begrifflichkeit relativ und solange kein jitterfreies Abtasten erforderlich ist, ist Ethernet wie auch WiFi oder Bluetooth dazu in der Lage, Werte zuverlässig in Intervallen zu senden. Die Definition von Echtzeit im Bereich Ethernet (Real Time Ethernet) lässt beispielsweise eine Modifikation von Layer >=5 zu um sich als Echtzeit definieren zu dürfen. Damit kann man mit eigenem Protokoll und Timern Echtzeit-Anforderung erfüllen, trotz dass Ethernet an sich per Definition nicht echtzeit ist. Und btw nutze ich bei uns in der Firma bei Anlagen EtherCAT und Ethernet (TCP/IP mit eigenem Protokoll) sowie FPGAs alles zusammen, je nach Anforderung. Und WLAN als generell ungeeignet zu definieren ist nicht korrekt. Es kommt immer darauf an, wo was verwendet wird. Es wurde nicht gesagt ob im privaten oder professionellen Umfeld. Im professionellen würde ich die Finger davon lassen, im privaten bastel ich selbst gerne damit rum und es funktioniert tadellos. Aber zurück zum Thema. Ich würde nicht kontinuierlich senden sondern das Senden an einen Timer knüpfen, der alle paar ms ein Frame sendet. Das Intervall kann man anhand der benötigten Rechenzeit für die ISR sowie der Datenverarbeitung abschätzen. Plus etwas Luft. Kann man sich auch per Try and Error rantasten. Watchdog setzen zb. Aber wenn wir beispielsweise ein Intervall von 10ms nehmen, da kann ein ESP32 schon verdammt viel abarbeiten. Eine FFT zb über 2048 Samples sollten easy drin sein, ein Frame für eine UI rendern und diese in den SPI Buffer schieben ebenfalls
Johannes schrieb: > Echtzeit ist immer relativ. Natürlich. [Viel Labersülz] Du kannst es drehen und wenden, wie du willst. Echtzeit bedeutet: Garantiert innerhalb eines (frei definierbaren) Zeitintervalls eine Antwort auf eine Anfrage zu erhalten. Bei "shared" Medien (wie etwa WLAN) kannst du das aber niemals garantieren, da du halt das Medium nicht vollständig kontrollierst. Einfache Sache, das. Klar, du kannst nach einem Timeout noch mal fragen, und dann vielleicht doch noch die ersehnte Antwort erhalten. Aber das ist dann halt eben nicht mehr "Echtzeit". Und wenn es keine Echtzeit ist, sollte man eben auch nicht von Echtzeit schwafeln.
Viel bla bla. Ethernet ist ebenfalls ein Shared Medium. Teilnehmer sind in einem Netz und nicht Point to Point verbunden. Dennoch ist RTE ein Thema und sollte deiner Meinung nach unmöglich sein. Teilnehmer synchronisieren sich über PTP, oberhalb von Layer 4, was das Medium an sich unangetastet lässt. Auch hier kannst du nicht kontrollieren, was andere Teilnehmer in dem Netz machen und bist davon abhängig, dass dein Switch oder Router die Frames passend weiterleitet. Dennoch spricht man hier von Echtzeit
Johannes schrieb: > Ethernet ist ebenfalls ein Shared Medium Mit Hubs ja, aber heute haben wir Switche. Seit denen sind es faktisch Point to Point Verbindungen. Switche puffern und multiplexen die Pakete übertragen, gerne auch mit geregelter Priorität, falls sich mal zu viele aufstauen. Vom Grundsatz her ist Ethernet immer noch ein Shared Medium, aber die Wahrscheinlichkeit von signifikanten Verzögerungen >10ms ist geschätzt um Faktor 10000 geringer, als in der Stadt bei WLAN.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.