Seite 1 von 1
ESP Innereien
Verfasst: 04.03.2023, 20:31
von Zoltan
Es ist still im Forum geworden, da alles in der Praxis gut funktioniert und "never touch a running system". Daher widme ich mich nun ein wenig der Theorie.
Ich habe mal woanders folgendes gelesen:
"
Bei einem ESP wird immer ein binary blob von espressif mit verwendet. Die ESP Familie hat also das große Problem dass da zentral ein binary von espressif drin werkelt deren interrupt eine höhere Priorität haben als die von dem Programm dass man produziert hat. Wenn man bei den Vorraussetzungen zuverlässlich auf die Mikrosekunde genau ein DCC Signal rausbringen will, dann muss man den Bogen schon etwas spannen. Die meisten tun das nicht und das DCC Signal sieht auch danach aus. "
Nachdem meine ESPs mit dem LY Framework total zuverlässig funktionieren, und auf dem Oszi die Signale total gesund aussehen, weiss ich nicht, was ich von der obigen Behauptung halten soll.
Ebenfalls:
"
Ein klassischer uCPU auf der Hauptplatine ist eine sicherere Karte weil
wie die ESP Produkte in einem Jahr aussehen das weiß der Geier."
Ich verwende ESPs aus bis jetzt min. 4 Jahrgänge und habe keine Probleme erlebt, die verhalten sich alle gleich... Und ich dachte ein ESP ist auch eine MikroCPU und ein "Arduino-killer" weil er alles und mehr und besser kann wie die ATMegas? Oder liege ich da falsch?
Ich bin Anwender und kein uC-Programmierer und kenne mich mit den Details zu wenig aus. Daher wäre ich froh, wenn jemand mich hierbei etwas aufklären könnte
Re: ESP Innereien
Verfasst: 05.03.2023, 08:00
von little.yoda
Wo kommen die Aussagen denn ursprünglich her?
Bei solchen Aussagen bitte immer eine Quelle, wenn möglich.
Der Kontext ist ja auch noch relevant.
oh je, will man das kommentieren, wenn jemand so unausgeglichen schreibt?
Ich versuch's mal sachlich:
- Ein ziemlich großer binary blob existiert, ja. Die Schlussfolgerung daraus ist aber nicht korrekt.
- Am Ende läuft auf den ESPs FreeRTOS. Ein Real-Time Operation System für Mirkoprozessoren. Dieses System sorgt für die Verteilung der Rechenzeit zwischen den einzelnen Tasks (Wifi, Bluetooth, das eigentliche Programm,...)
- Dies ist auch dringend notwendig, da alleine die Ansteuerung von Wifi nicht trivial ist und auch schon einiges an Rechenzeit benötigt und es extrem auf Timing ankommt.
- Die Aussagen stimmen (wenn überhaupt) primär nur für den ESP8266. Der ESP32 ist (meistens) mit zwei Cores ausgestattet. Auf einem Core läuft Wifi, Bluetooth und co und auf dem zweiten läuft dein Programm dann unbehelligt von Interrupts.
- Es gibt langfristige Zusicherungen, wie lange die verschiedenen Modelle produziert werden.
Vielleicht sind die Lieferzeiten für klassische Mikroprozessoren nicht so lang, für IOT-Technik finde ich sie aber bemerkenswert lang.
- DCC Genauigkeit
Wenn man das DCC Signal natürlich auf die primitivste Weise via Software Bit-Banging erzeugst, dann hat man natürlich Probleme. Bei Bit-Banging wird im Programm der Ausgang "manuel" in passenden Abständen auf low oder high gesetzt. Hier muss das Timing absolut passen. Auf einem einfachen Mikroprozessor wird es noch funktionieren können, auf einem ESP mit Wifi-Task und ähnlichem wird dir das DCC Signal zumindest auf dem ESP8266 regelmäßig zerschossen.
Aber wer das DCC-Signal so erzeugen lässt, dem ist nicht zu helfen. Mein Framework nutzt für die Erstellung die SPI-Komponente. Die SPI-Komponente ließt die Daten fortlaufend aus einem Speicherbereich (Wer kennt noch DMA-Zugriffe?) und steuert den Port direkt und automatisch an. Dieser Prozess ist unabhängig von Interrupts. Er läuft im Hintergrund. Das Programm muss nur dafür sorgen, dass die SPI-Komponente immer mal wieder Futter (=> neue DCC-Befehle) bekommt.
Ich hatte die Genauigkeit des DCC-Signal mit Hilfe von SPI mal ausgerechnet und sie war innerhalb aller DCC Vorgaben.
Ich weiß aber nicht, wie die anderen Lösungen das DCC-Signal erzeugen. Der Implementierung von SPI ist natürlich etwas aufwendig und ein Grund dafür, dass ich noch keinen Nerv hatte, es auf den ESP32 zu portieren. Ich hatte den Aufwand inkl. Tests mal auf ein Wochenenden geschätzt.
Zoltan hat geschrieben: ↑04.03.2023, 20:31
Ich verwende ESPs aus bis jetzt min. 4 Jahrgänge und habe keine Probleme erlebt, die verhalten sich alle gleich... Und ich dachte ein ESP ist auch eine MikroCPU und ein "Arduino-killer" weil er alles und mehr und besser kann wie die ATMegas? Oder liege ich da falsch?
Diese Aussage ist genauso pauschal
Die Auswahl eines Mikroprozessors ist immer ein Abwägen.
Der ESP ist so beliebt, weil er zu einem extrem niedrigen Preis Wifi anbietet. Damals ~2016 gab es nichts vergleichbares. Selbst heute gibt es nur wenige Alternativen, die noch zeigen müssen, ob sie überleben.
- Wifi
- Sehr viel Speicher
- Einfache Nutzung durch Arduino Integration
- Schnell
- ....
Aber es gibt auch viele Gründe, die gegen einen ESP bzw. ESP8266 sprechen:
- Hoher Stromverbrauch
- Die ADC-Eingänge sind mies. (ADC: Messung von Spannungen an einem PIN)
- Die Dokumentation ist immer noch mager
- In den ersten Jahren noch sehr viele Fehler in den Software-Bibliotheken
- Schwierige Nutzung in Real-Time Umgebungen.
- ....
Re: ESP Innereien
Verfasst: 05.03.2023, 08:10
von Zoltan
Vielen lieben Dank für die detaillierte Erklärung, nun verstehe ich das halbwegs.
Die Aussagen stammen aus dem Spur-N-Forum und waren mir gleich suspekt, nachdem ich das mit den Erfahrungen mit deinem Framework verglichen habe.
Ich glaube nicht, dass es sich lohnt, dort mit dem Kollegen zu diskutieren, werde ich auch nicht tun, ich wollte mich nur vergewissern, dass ich, wie ich es vermutet habe, mit deinem Framework doch auf dem richtigen Pfad bin.
Re: ESP Innereien
Verfasst: 11.03.2023, 11:18
von Zoltan
Ergänzung:
Ich bin zufällig auf die Seite DCC-EX gestoßen.
Dort wird ein Arduino Uno oder Mega mit einem Wifi-Shield (und Motorshield) benutzt (und das mit 2 verschiedene Netzadapter...)
Meine Frage: Warum?
Eine Vemos D1Mini mit dem ESP drauf ist sehr viel kleiner und kann mit dem LY-FW einem Motordriver (zB. LN298N) all das!
Oder irre ich mich?