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.
- ....