Forum: Mikrocontroller und Digitale Elektronik ESP32 - Programmteile im RAM


von Helmut M. (Gast)


Lesenswert?

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.

von pitschu (Gast)


Lesenswert?

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

von mble (Gast)


Lesenswert?

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?

von achso (Gast)


Lesenswert?

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.

von Klaus (Gast)


Lesenswert?

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

von Einer K. (Gast)


Lesenswert?

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.

von Ben W. (ben_w)


Lesenswert?

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.

von mble (Gast)


Lesenswert?

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

von fchk (Gast)


Lesenswert?

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

von Klaus (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.