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
