Tag zusammen, ich möchte gerne eine Art Plugin System mit einem ESP32 umsetzen. Die Idee ist, beim Start ein Programm aus einem I2C EEPROM zu laden, in den RAM zu legen und anschließend aus dem Hauptprogramm dorthin zu springen. Nach der Abarbeitung dieses Programms soll dann wieder zurück in das Hauptprogramm gesprungen werden. Ich weiß, dass der ESP32 dazu in der Lage sein sollte, er hatte allerdings in Rev0 einen Bug, der dies verhinderte. Der Bug ist mittlerweile aber behoben worden. Mir stellt sich momentan allerdings die Frage, wie man soetwas am besten umsetzt. Mein bisheriger Ansatz sieht wie folgt aus: 1. RAM reservieren (malloc?) 2. Daten aus I2C EEPROM ins RAM laden 3. Programmcounter sichern 4. Programmcounter auf RAM setzen (Pointer aus malloc?) 4. Plugin abarbeiten 5. Rücksprung Adresse lesen und zurück springen Kann man das so machen, oder gibt es sinnvollere Ansätze? Hat vielleicht jemand schon etwas ähnliches umgesetzt und Beispielcode dazu? Bevor Fragen kommen, wozu das gut sein soll: Ich möchte ein Modul bauen, dass mit verschiedenen Sensoren kommunizieren können soll. Die Sensoren werden per I2C mit dem ESP32 verbunden. Da im Laufe der Zeit weitere Sensoren dazu kommen sollen, würde dies bedeuten, dass immer ein Firmware Update auf dem ESP32 nötig wäre und zudem ein großer Teil nicht benötigter Firmware vorhanden wäre. Daher möchte ich, dass die Sensoren ihre Firmware auf einem I2C EEPROM selber mitbringen. Somit scheidet leider auch ein zusätzlicher SPI Flash am ESP32 aus.
Hallo Hellmut, interessantes Konzept, aber etwas schwierig umzusetzen. 1. Das Stückchen Code im I2C-Flash muss so gestaltet sein, dass es in der Umgebung des laufenden ESP32 funktioniert. Entweder es enthält alle Systemfunktionen wie memcpy, strcmp, ... selbst, oder es muss die Einsprungstellen im Umsystem kennen. Das Linken wird entsprechend kompliziert und bei Änderungen des Basissystems (ESP32) müssen alle I2C Codes neu gelinkt werden. 2. Per malloc wird es kaum gehen, da dann der I2C Code neu reloziert werden muss (oder er ist so universell (Hand-ASM), dass er das nicht braucht. Da der Code aber vermutlich aber I2C Routinen das ESP32 nutzen muss (um Daten vom Sensor zu holen ...) ist das kaum machbar. Ich würde eher über einen Interpreter nachdenken (LUA oder microPython), der vom I2C Flash ein kurzes Script läd, welches dann die Sensorbedienung durchführt. Beide Interpreter gibt es fertig für den ESP32. Viel Erfolg pitschu
Schnapsidee. Viel Aufwand für (fast) nix. Und wer soll die Sensor-Firmware liefern? >würde dies bedeuten, dass immer ein >Firmware Update auf dem ESP32 nötig wäre Und was ist der Aufwand mit den Extra-EEPROMs? >und zudem ein großer Teil nicht >benötigter Firmware vorhanden wäre. Wen interessiert's solange das Flash reicht?
mble schrieb: > Schnapsidee. > Ich lach mich kaputt. Jetzt denk mal scharf drüber nach, wo dieses Konzept noch verwendet wird. ... ... ... Bei dem PC vor dem du sitzt. Prozessoren, die direkt aus dem Flash exekutieren sind die absolute Minderheit.
mble schrieb: > Schnapsidee. Ganz im Gegenteil. Der Sensor hat seine eigene Firmware im Bauch. Gibts einen neuen Sensor muß der einfach nur ans alte System angesteckt werden, einfach Plug and Play. MfG Klaus
Ich finde die Idee auch gar nicht sooo schlecht. Sehe nur Probleme bei der Umsetzungsidee. Würde es von daher ganz anders es angehen. Erstmal würde ich einen I2C Multiplexer vorsehen. Jede Sensor+EEPROM Kombination bekommt dann seinen eigenen I2C Kanal. C/C++ Code im EEPROM halte ich für eine schlechte Idee! Weil eben schwierig umsetzbar, wurde oben schon genannt. Helmut M. schrieb: > Da im Laufe der Zeit weitere > Sensoren dazu kommen sollen, würde dies bedeuten, dass immer ein > Firmware Update auf dem ESP32 nötig wäre und zudem ein großer Teil nicht > benötigter Firmware vorhanden wäre. Solange der Speicher nicht überquillt, ist das doch kein Problem. Und auch ein Firmware Update kann man automatisieren. Ob per Make, und seine Brüder, oder ob man die Arduino IDE im Batch betreibt. Das macht keinen prinzipiellen Unterschied. Der UPLOAD erfolgt dann OTA. So schwebt mir das vor: Ab und an prüft der ESP32 ob sich was an seinem i2c Fächer geändert hat. Z.B. bei jedem Reset. Falls ja, schickt der die neue Konfiguration, welche er aus den jeweiligen EEPROMs ließt, zu einem Serverprozess auf einem beliebigen PC. Der PC stoppelt die neue Firmware Quelle zusammen, ruft z.B. Arduino oder make im Batchbetrieb auf, generiert so die Firmware und überträgt sie per OTA zum ESP. Und fertig ist die Laube.
ich würde auch erstmal schauen ob Lua eine Option für dich ist. Falls nicht, ich habe sowas in der art für einen STM32F4 gebaut. Wobei das "Plugin" als unprivileged code ausgeführt wird und es hat auch eine art Syscall api. Also die Hauptanwendung stellt über eine einzige Funktion die eine feste Adresse hat alle RTOS und HAL Funktionalitäten bereit. Ist nicht unbedingt das performanteste aber es funktioniert recht gut. Die "Plugins" können völlig unabhängig compiliert und gelinkt werden, sie müssen lediglich die eine einzige Sprung addresse vom hauptprogramm kennen. Umgekehrt muss das Hauptprogramm den "Entrypoint" des Plugins kennen. Den RAM habe ich über das Linkerscript file aufgeteilt. 1/4 an das Hauptprogramm und 3/4 für die "plugins". Den Rest erledigt der Linker selbst. Der RAM und die "lebensnotwendingen" peripherals des Hauptprogramm sind durch die MPU zusätzlich geschützt. Als Entwickler des Plugins bekommt man es kaum mit das man nicht das Hauptprogramm ist, solange man nicht versucht auf unerlaubte Ressourcen zu zugreifen.
Klaus schrieb: > mble schrieb: >> Schnapsidee. > > Ganz im Gegenteil. Der Sensor hat seine eigene Firmware im Bauch. Gibts > einen neuen Sensor muß der einfach nur ans alte System angesteckt > werden, einfach Plug and Play. > Ja, Jaaaa. BlaggnBlei gibt's zum Nulltarif, Ihr Träumer? > MfG Klaus
Helmut M. schrieb: > Bevor Fragen kommen, wozu das gut sein soll: Ich möchte ein Modul bauen, > dass mit verschiedenen Sensoren kommunizieren können soll. Die Sensoren > werden per I2C mit dem ESP32 verbunden. Da im Laufe der Zeit weitere > Sensoren dazu kommen sollen, würde dies bedeuten, dass immer ein > Firmware Update auf dem ESP32 nötig wäre und zudem ein großer Teil nicht > benötigter Firmware vorhanden wäre. Meine Herangehensweise: Nimm einen kleinen 8-Bitter wie den hier http://www.microchip.com/wwwproducts/en/PIC16F18426 Der ist zum ESP32 hin I2C Slave und spricht ein genormtes Protokoll, das alle zukünftigen Sensoren verwenden werden. Weiterhin steuert er seinen Sensor über einen weiteren I2C oder SPI oder analog (das Ding hat einen 12 Bit ADC!) oder wie auch immer an. Damit kann der Code auf dem ESP konstant bleiben, und Du kannst auch mehrere Sensoren auf einmal ansprechen, auch wenn die Sensorchips alle die gleiche I2C Adresse haben sollten. Der PIC abstrahiert das alles. Du kannst auch irgendwas anderes nehmen, aber die PICs haben für ihre Pinanzahl recht viel Peripherie drin. Und 12 Bit ADCs sind z.B. bei AVRs eher selten. fchk
mble schrieb: > BlaggnBlei gibt's zum Nulltarif, Ihr Träumer? Ja, man kriegt sogar noch was raus ;) Beim Init scannt die CPU den I2C Bus und lädt für jeden Sensor seinen Treiber aus dem EEPROM des Sensors, fertig. Und der Treiber kann auch viel später entstanden sein als das Hauptsystem, es müssen sich nur beide an die gleichen Regeln halten. So wie früher beim PC die Bioserweiterungen auf den IO-Karten. Fand das BIOS da die richtige Signatur wurde der Code dahinter gecallt und der hat sich dann als BIOS-Erweiterung eingerichtet. Ben W. beschreibt ein ähnliches System. Aber auch die "aktiven" Slaves von fchk sind nett. MfG Klaus
Bitte 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.