Hardware
Open-Source-ESP8266-Roboterarm mit Rust-Firmware
Die quelloffene Firmware läuft auf einem ESP8266-Arm mit fünf Servos und stellt das Gelenkmodell des Simulators bereit. Der Simulator benötigt weder eine serielle noch eine Bluetooth- oder Netzwerkverbindung zu diesem Arm. Der vollständige Kurs funktioniert daher ohne physisches Gerät.
Entwurf
Rust bestimmt die Abläufe; C++ bleibt eine Hardwarebibliothek
Die Abhängigkeit verläuft nur in eine Richtung. Nur ein Crate deklariert importierte Hardwarefunktionen; über die Grenze gehen Bytes statt Arduino-Strings, C++-Objekten, Routen, JSON oder Anwendungszustand.
Rust übernimmt
- Startablauf und kooperativer Executor
- Hotaru-Routing und -Protokoll
- HTTP-Parsing und -Antworten
- Servoprüfung und -zustand
C++ übernimmt
Nur Vorgänge, die Arduino- oder ESP8266-Symbole benötigen:
- Taktgeber, Interrupt-Maskierung, Watchdog, Neustart, Heap, Zufall, serieller Port
- WLAN-Zugangspunkt- und Stationsmodus sowie einfache TCP- und UDP-Handles
- Handles für Captive DNS und SPIFFS
- GPIO, PWM, Schreiben von Servopulsen und direkte OTA-Schreibvorgänge
Native WiFiClient, File, and Servo Objekte bleiben auf der C++-Seite hinter ganzzahligen Handles. Eingebettete Arduino-Firmware besitzt keine gewöhnliche Rust- fn main(), Daher exportiert das Gateway einen einzelnen, nicht zurückkehrenden C-Einstiegspunkt, der setup() calls once.
Workspace
Die Crates
- hcr-gateway
- Die Anwendung: Startablauf, Routing und der einzelne C-Einstiegspunkt, den Arduino einmal aufruft.
- hcr-http
- no_std-HTTP-Parsing und -Antworten sowie das Hotaru-Protokoll.
- hcr-io-esp8266
- Hotaru-Übertragung über TCP der Plattform.
- hcr-rt-esp8266
- Laufzeit, Zeit und kritische Abschnitte.
- hcr-platform
- Plattform-Traits und Werte, die im gesamten Workspace gemeinsam genutzt werden.
- ffi/hcr-ffi
- Das einzige Crate, das importierte Hardwarefunktionen deklariert, mit sicheren Adaptern darüber.
Protokoll
Die aktuelle Geräte-API und der hcr.v1-Dienstvertrag
Der Rust-Dienst verwendet den additiven hcr.v1-Umschlag mit JSON- und CBOR-Bindungen. Das aktuelle ESP8266-Rust-Gateway stellt eine begrenzte HTTP/JSON-Servo-API bereit; MQTT ist dort noch nicht implementiert.
| Client | Übertragung | Kodierung |
|---|---|---|
| Browser-App (heute) | HTTPS request–response | JSON |
| Rust-Dienstvertrag | hcr.v1-HTTP-Bindung | JSON und CBOR |
| ESP8266-Rust-Gateway (heute) | HTTP am Gerätezugangspunkt | JSON |
| MQTT-Gerätepfad (geplant) | MQTT over TCP/TLS | CBOR |
Zuordnung im Nachrichtenumschlag
Die Zuordnung steht nicht in MQTT-5-Eigenschaften. Geräte können 3.1.1 aushandeln, und die HTTP-Bindung besitzt keine solchen Eigenschaften. Ein überall funktionierender Mechanismus ist zuverlässiger als zwei unvollständige.
Zeitstempel bestimmen keine Reihenfolge
Geräteuhren sind unzuverlässig; der ESP8266 erreicht NTP nur bei aktivem Router. Die Reihenfolge folgt dem FIFO jedes Topics und niemals der Uhr des Absenders.
Additive Nebenversionen
Neue optionale Felder, Arten und Topics können ergänzt werden. Empfänger protokollieren und verwerfen unbekannte Inhalte, statt daran zu scheitern.