301 lines
14 KiB
Markdown
301 lines
14 KiB
Markdown
# UART Protokoll
|
||
|
||
## Struktur einer Nachricht
|
||
|
||
- Control Bytes:
|
||
- 0xAA = Startbyte
|
||
- 0xBB = EscapeByte
|
||
- 0xCC = EndByte
|
||
|
||
checksum = XOR über alle Bytes (ohne Control Bytes und Checksum-Byte)
|
||
|
||
Command, Payload und Checksum werden Escaped sollten sie einem Control Byte ensteprechend
|
||
| Startbyte | Command | Payload (variable) | Checksum | Endbyte |
|
||
|-----------|---------|--------------------|----------|---------|
|
||
|
||
### Felder im Detail:
|
||
|
||
- **Command** (`uint8_t`):
|
||
Gibt an, welcher Nachrichtentyp gesendet wird.
|
||
|
||
- **Payload** (`variabel`):
|
||
Datenfeld mit variabler Länge, abhängig vom `Command`.
|
||
|
||
- **Checksum** (`uint8_t`):
|
||
XOR über aller Bytes von `Command` und `Payload`.
|
||
|
||
|
||
### Messages
|
||
|
||
Command:
|
||
- UART_ECHO = 0x01
|
||
- UART_VERSION = 0x02
|
||
- UART_CLIENT_INFO = 0x03
|
||
|
||
Grundlegend sind alle Zahlenwerte im LittleEndian format!
|
||
|
||
#### UART_ECHO:
|
||
|
||
- Send Message: AA 01 01 CC
|
||
- Message Received: AA 01 01 CC
|
||
|
||
Sendet zurück was geschickt wird.
|
||
|
||
#### UART_VERSION:
|
||
|
||
| Offset | Länge (Bytes) | Bezeichnung | Beschreibung |
|
||
|--------|---------------|-------------|------------------|
|
||
| 0 | 2 | Version | Software Version |
|
||
| 2 | 7 | BuildHash | Git Hash |
|
||
|
||
|
||
- Send Message: AA 02 02 CC
|
||
- Message Received: AA 02 01 00 33 62 35 36 30 37 39 6F CC
|
||
|
||
| Version | Buildhash |
|
||
|---------|-----------|
|
||
| 1 | 3b56078 |
|
||
|
||
|
||
Sendet die Version und den Buildhash vom Master zurück.
|
||
|
||
#### UART_CLIENT_INFO:
|
||
|
||
Das erste Datenbyte nach dem Commando gibt an wie viele Client Infos in dieser Nachricht vorhanden sind.
|
||
|
||
Danach teilt sich ein Eintrag wie Folgt auf:
|
||
| Offset | Länge (Bytes) | Bezeichnung | Beschreibung |
|
||
|--------|---------------|----------------------------|---------------------------------------------------------------|
|
||
| 0 | 1 | Client ID | Eindeutige ID des Clients. |
|
||
| 1 | 1 | Ist verfügbar | Boolean-Wert (0 = nein, 1 = ja), ob der Client verfügbar ist. |
|
||
| 2 | 1 | Slot genutzt | Boolean-Wert (0 = nein, 1 = ja), ob der Slot belegt ist. |
|
||
| 3 | 6 | MAC-Adresse | Die Hardware-Adresse des Clients. |
|
||
| 9 | 4 | Letzter Ping | Zeit in Millisekunden seit dem letzten Ping. |
|
||
| 13 | 4 | Letzter erfolgreicher Ping | Zeit in Millisekunden seit dem letzten erfolgreichen Ping. |
|
||
| 17 | 2 | Version | Versionsnummer des Clients. |
|
||
|
||
##### Ein Client
|
||
|
||
- Send Message: AA 03 03 CC
|
||
- Message Received: AA 03 01 00 01 01 50 78 7D 18 89 F8 34 00 00 00 61 1F 00 00 02 00 76 CC
|
||
|
||
| Client ID | Verfügbar | Genutzt | MAC-Adresse | Last Ping | Last Successful Ping | Version |
|
||
|-----------|-----------|---------|-------------------|-----------|----------------------|---------|
|
||
| 0 | 1 | 1 | 50:78:7D:18:89:F8 | 52 | 8033 | 2 |
|
||
|
||
##### Zwei Clients
|
||
|
||
- Send Message: AA 03 03 CC
|
||
- Message Received: AA 03 02 00 01 01 50 78 7D 18 89 F8 22 00 00 00 F4 2A 01 00 02 00 01 01 01 50 78 7D 18 0C B4 10 00 00 00 F1 2A 01 00 02 00 FE CC
|
||
|
||
| Client ID | Verfügbar | Genutzt | MAC-Adresse | Last Ping | Last Successful Ping | Version |
|
||
|-----------|-----------|---------|-------------------|-----------|----------------------|---------|
|
||
| 0 | 1 | 1 | 50:78:7D:18:89:F8 | 34 | 76532 | 2 |
|
||
| 1 | 1 | 1 | 50:78:7D:18:C:B4 | 16 | 76529 | 2 |
|
||
|
||
#### UART_CLIENT_INPUT:
|
||
|
||
Die Identifizierung wird hier anhand der vorher gesendeten ClientID gemacht also muss einmal vorher `UART_CLIENT_INFO` aufgerufen werden.
|
||
|
||
Das erste Datenbyte nach dem Commando gibt an wie viele Client Infos in dieser Nachricht vorhanden sind.
|
||
|
||
Danach teilt sich ein Eintrag wie Folgt auf:
|
||
| Offset | Länge (Bytes) | Bezeichnung | Beschreibung |
|
||
|--------|---------------|-------------|----------------------------------------------------------------------------------|
|
||
| 0 | 1 | Client ID | Eindeutige ID des Clients. |
|
||
| 1 | 4 | LageX | Float Wert von der X Lage. |
|
||
| 5 | 4 | LageY | Float Wert von der Y Lage. |
|
||
| 9 | 4 | InputMaske | Int32 Wert der als Bitmaske genutzt wird um bis zu 32 Boolische Werte anzugeben. |
|
||
|
||
Inputmaske:
|
||
Taster1, Taster2, IOError1, IOErro2, AkkuStand1, AkkuStand2 (2 Bit kodiert für 25%,50%,75%,100%), rest unbelegt, default 0
|
||
|
||
| Bit1 | Bit2 | Akkustand |
|
||
|------|------|-----------|
|
||
| 0 | 0 | 25% |
|
||
| 0 | 1 | 50% |
|
||
| 1 | 0 | 75% |
|
||
| 1 | 1 | 100% |
|
||
|
||
|
||
<div style="page-break-after: always;"></div>
|
||
|
||
# Machbarkeits-Studie
|
||
|
||
## 1.0 Hardware-Features
|
||
|
||
### 1.1 Hardware-Aufbau
|
||
Anforderung
|
||
Es soll eine Hardware von 20 Modulen bereitgestellt werden, welche als Basis der
|
||
grundlegenden Software-Features dient. Dabei liegt der Fokus auf der Verarbeitung von
|
||
Wifi-Nachrichten und weniger auf deren Hardware-technischen Umsetzung.
|
||
Lösungsansatz
|
||
Die Hardware besteht aus 20 ESP32-Modulen (1x Koordinator und 19 Peers) und der
|
||
entsprechenden Energieversorgung: 20x Stecker-Netzteil + USB-Leitungen
|
||
Abnahme-Kriterium
|
||
Alle Peers sind so mit Energie zu versorgen, dass sie sich in einem Radius von ca. 15m um
|
||
den versorgten Koordinator befinden.
|
||
Dokumentation
|
||
Es wird per Liste festgehalten, welches ESP32-Board benutzt wird und ob Modifikationen
|
||
bei der Spannungsversorgung (bspw. Elko an 3.3V) vorgenommen wurden.
|
||
|
||
## 2.0 Software-Features
|
||
|
||
### 2.1 Netzwerk-Aufbau
|
||
Anforderung
|
||
Das Netzwerk soll sich nach einem Power-On selbständig aufbauen und eine Teilnehmer-
|
||
Liste nach abgeschlossener Initialisierung bereitstellen.
|
||
Lösungsansatz
|
||
Der Koordinator erstellt ein MAC-Netzwerk und fügt die Peers in das Netzwerk hinzu.
|
||
Zusätzlich erstellt der Koordinator eine Liste von MAC-Adressen der Peers.
|
||
Abnahme-Kriterium
|
||
Dieses Feature wird per Systemtest verifiziert. Der Test startet den Netzwerk-Aufbau auf
|
||
dem Koordinator per Terminal-Kommando und gibt nach 5 Minuten die MAC-Adressen-
|
||
Liste zurück.
|
||
Dokumentation
|
||
Der Netzwerk-Aufbau wird per Ablauf-Diagramm dokumentiert.
|
||
|
||
### 2.2 PingPong-Feature
|
||
Anforderung
|
||
Nach dem Netzwerk-Aufbau soll jeder Peer durch den Koordinator ein Ping erhalten,
|
||
welchen dieser umgehend mit einem Pong (bzw. mit seiner Firmware-Version)
|
||
beantwortet. Sollte ein Teilnehmer auf die Anfrage nicht reagieren, soll die Anfrage sofort
|
||
wiederholt werden. Die benötigte Zeit und die Anzahl der Wiederholungen soll erfasst
|
||
werden.
|
||
ALOX Labs UG Lastenheft Pflichtenheft PowerPods 4
|
||
Lösungsansatz
|
||
Der Koordinator sendet an die hinterlegten MAC-Adressen jeweils den Ping-Befehl und
|
||
erwartet die Pong-Antwort (Firmware-Version) des jeweiligen Peers. Sollte ein Teilnehmer
|
||
nicht antworten wird die Nachricht nach 10ms wiederholt – maximale Wiederholung: 5x.
|
||
Die Zeit (Start: vor der Sendung – Stopp: nach dem Empfang) wird im Koordinator erfasst.
|
||
Abnahme-Kriterium
|
||
Dieses Feature wird per Systemtest verifiziert. Der Test startet das PingPong-Feature mit
|
||
einer erwarteten Firmware-Version und bekommt als Resultat eine Liste mit dem Status
|
||
der Firmware, der Dauer und den benötigten Versuchen pro Peer zurück.
|
||
Dokumentation
|
||
Das PingPong-Feature wird per Ablauf-Diagramm dokumentiert.
|
||
|
||
### 2.3 PingPong-Feature im definierten Raster
|
||
Anforderung
|
||
Es soll sichergestellt werden, dass die Dauer der Peer-Abfrage immer im gleichen zeitlichen
|
||
Raster stattfindet. Dies soll unabhängig von den Teilnehmern des Netzwerks sein und sich
|
||
an der Maximalen Anzahl der Teilnehmer richten. Dadurch soll sichergestellt werden, dass
|
||
die Performance bei 5 Teilnehmern sich genauso verhält wie bei 19 Teilnehmern.
|
||
Lösungsansatz
|
||
Der Koordinator sendet an die hinterlegten MAC-Adressen jeweils den Ping-Befehl in
|
||
einem vor-definierten zeitlichen Raster. Das Raster richtet sich an die in Pos. 2.2
|
||
gemachten Ergebnisse, wo die maximale Dauer einen PingPongs bestimmt wird.
|
||
Die menschl. Reaktionszeit beträgt ca. 250ms. Die maximale Abfrage-Zeit sollte unterhalb
|
||
von 200ms (bestenfalls bei 125ms) liegen um ein flüssigen Spielablauf zu gewährleisten.
|
||
- 19 Teilnehmer mit 125ms: 5ms Raster + 3 Wiederholungen (5ms + 5ms)
|
||
- 19 Teilnehmer mit 200ms: 8ms Raster + 3 Wiederholungen (8ms + 8ms)
|
||
Abnahme-Kriterium
|
||
Dieses Feature wird per Systemtest verifiziert. Der Test startet das PingPong-Feature im
|
||
vor-definierten Raster und bekommt als Resultat eine Liste mit der jeweiligen Dauer, den
|
||
benötigten Versuchen und einer Rückmeldung, ob das Raster eingehalten wurde zurück.
|
||
Dokumentation
|
||
Das PingPong-Feature im definierten Raster wird per Ablauf-Diagramm dokumentiert
|
||
|
||
### 2.4 Broadcast-Message
|
||
Anforderung
|
||
Der Koordinator soll nicht nur die Peers einzeln per MAC-Adresse, sondern auch per
|
||
globaler Nachricht direkt an alle Peers eine Nachricht versenden können.
|
||
Lösungsansatz
|
||
Durch eine spezielle Nachricht, die an alle Peers gerichtet ist, können Nachrichten per
|
||
Broadcast vom Koordinator an alle Peers versendet werden. Eine Rückmeldung der Peers
|
||
wird nicht erwartet.
|
||
ALOX Labs UG Lastenheft Pflichtenheft PowerPods 5
|
||
Hinweis
|
||
Der erfolgreiche Abschluss der Machbarkeitsstudie soll mit den aufgeführten Punkten erreicht werden.
|
||
Nach dem Abschluss soll der Status soweit sein, um mit der Produkt-Entwicklung starten zu können.
|
||
Im Rahmen der Entwicklung wird (wenn nicht anders im Unterpunkt beschrieben) immer davon
|
||
ausgegangen, dass Funktionen und Übertragungen korrekt funktionieren – sprich, es wird der Gut-Fall
|
||
abgedeckt. Sollten trotz dieser Erwartung Fehler während oder nach der Inbetriebnahme stattfinden,
|
||
werden diese nachträglich behoben.
|
||
Abnahme-Kriterium
|
||
Die Broadcast-Message wird über einen Systemtest verifiziert. Dabei wird der Test per
|
||
Terminal-Kommando gestartet und an alle Peers eine globale Nachricht mit einem Wert
|
||
gesendet. Diesen Wert fragt der Koordinator per modifiziertem PingPong (Wert statt
|
||
Firmware-Version) im zweiten Schritt ab.
|
||
Dokumentation
|
||
Der Systemtest zur Broadcast-Nachricht wird per Ablauf-Diagramm dokumentiert.
|
||
|
||
### 2.5 OTA-Update
|
||
Anforderung
|
||
Die Peers sollen vom Koordinator eine neue Firmware per Funk übertragen bekommen, so
|
||
dass eine händische Programmierung der Module nicht notwendig ist.
|
||
Lösungsansatz
|
||
Der Koordinator prüft nach jedem Neustart des Netzwerks, ob die Teilnehmer die korrekte
|
||
Firmware besitzen. Wenn dies nicht der Fall ist, wird die aktuelle Firmware übertragen.
|
||
Abnahme-Kriterium
|
||
Das OTA-Update wird über einen Systemtest verifiziert. Dabei wird der Test per Terminal-
|
||
Kommando gestartet und an alle Peers die neue Firmware übertragen. Mit einem
|
||
nachträglichen PingPong wird im zweiten Schritt die neue Version der Peers abgefragt.
|
||
Dokumentation
|
||
Der Integrationstest zum OTA-Update wird per Ablauf-Diagramm dokumentiert.
|
||
|
||
## 3.0 Abschlussbericht
|
||
|
||
### 3.1 Nach erfolgreicher Implementierung der beschriebenen Features soll ein
|
||
aussagekräftiger Abschlussbericht erstellt werden. Darin sollen die gemachten Ergebnisse
|
||
und Erkenntnisse kurz dargestellt werden. Dieser Bericht dient dann als Grundlage für
|
||
das Lasten- und Pflichtenheft der Produktentwicklung und gibt einen Ausblick, ob sich die
|
||
techn. Anforderungen hinreichend gut umsetzen lassen.
|
||
|
||
### 3.2 Eine tabellarische Auflistung, welche der aufgeführten Features wie umgesetzt wurden
|
||
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
|