Added OTA Update Strategie writedown

This commit is contained in:
simon 2025-07-26 10:35:40 +02:00
parent 01d0be7004
commit 95bfcaa4d2

View File

@ -177,3 +177,55 @@ techn. Anforderungen hinreichend gut umsetzen lassen.
und ob diese den ursprünglichen Anforderungen entsprechen.
## OTA-Update Technische Umsetzung:
### Vorrausetzung:
- Update File steht bereit und ist unter 2MB groß.
- UART Verbindung steht
- ESP Funktioniert einwandfrei
- ESP Läuft auf Partition A, Partition B soll geupdated werden
### Erste Schritt:
- Update in 200Byte stücke zerhacken und stück für stück per UART an den Master schicken
- Uart Protokol hat schon eine fehlercheck für die Übertragung drinnen
- Firmware wird in Partition B geschrieben
- OTA API Validiert Firmware am ende
#### Hier könnte man schon einen Neustart machen und Validieren ob die Firmware für den Master läuft!
#### Denn angeblich kann man beim ESP die aktuell laufende Partition auslesen
### Zweiter Schritt:
- Master liest in 200Byte stücken die Firmware aus seiner Partition B aus
- Und schickt per Broadcast die ersten 20 Packete an die Clients
- Die clients haben 4KB Buffer vorgesehen wo sie die 20 Packete unterbringen können
- Master Forder Ack Bitmaske an zur Validierung das alle 20 Packete da sind
- Sollten in der Bitmaske zeilen fehlen gibt der Master per unicast die fehlenden Zeilen an die Entsprechend Clients erneut
- ESP NOW kümmert sich hier um die Datenintigrität
- Wenn alle ihre ersten 20 packete haben gibt der master das go und alle schreiben die ersten 20 packete weg.
- Der master aktuallisiert den fortschritt für alle clients -> dann kann man das auch abfragen per uart und hat eine Fortschrittsanzeige
- Alle melden sich zurück wenn sie fertig sind mit dem schreiben per ota und der buffer leer ist.
- Repeat bis alle Daten da sind
Hier hab ich mal grob gerechnet:
2MB in 200Byte Schritten -> 10.000 Packete
10.000 Packete in 20er Schritten -> 500 Sequencen
Retries und Acks mal aussen vor hab ich leider keinen richtigen anhaltspunkt wie lang das dauern kann.
Aber 500* ca 300ms => ist schonmal 150sekunden nur für das acken das die Packete da sind. Annahme hier das die maximal latenz beim Ping mit 16 Clients ca 300ms sind.
Entsprechend mit Daten und retries... ja kp, Gemini schätzt max 10min. Wird sich zeigen. Da addiert sich zu viel auf.
- Alle Clients validieren ihren firmware
- Sollte das bei einem nicht klappen muss man hier nochmal gucken ob man den ganzen process nochmal von vorne anstößt nur mit dem fehlenden client...
### Dritter Schritt:
- Alle Clients rebooten
- Clients geben rückmeldung ob das Update funktioniert
#### Hier müssten war noch entscheiden was passiert wenn das Update bei nur ein paar funktionert hat?
#### Was passiert wenn das Update garnicht funktioniert hat, behält der master dann auch seinen stand?
#### Entsprechend hätte man ihn vorher auch nicht neustarten dürfen
- Sollten alle Clients ihr go geben startet der Master auch neu
#### Wenn das Master Update jetzt fehlschlägt sagt er den clients bescheid und die booten auch wieder um?
Gibt halt noch ein zwar sachen die man sich überlegen muss aber ich denke den rest hab ich soweit ausgearbeitet