Added OTA Update Strategie writedown
This commit is contained in:
parent
01d0be7004
commit
95bfcaa4d2
52
readme.md
52
readme.md
@ -177,3 +177,55 @@ techn. Anforderungen hinreichend gut umsetzen lassen.
|
|||||||
und ob diese den ursprünglichen Anforderungen entsprechen.
|
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
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user