Matériel
Bras robotisé ESP8266 open source avec micrologiciel Rust
Le micrologiciel libre fonctionne sur un bras ESP8266 à cinq servomoteurs et fournit le modèle articulaire du simulateur. Celui-ci ne dépend d’aucune liaison série, Bluetooth ou réseau avec le bras réel.
Conception
Rust gère la logique ; C++ sert de bibliothèque matérielle
La dépendance est unidirectionnelle. Un seul crate déclare les fonctions matérielles importées et la frontière ne transporte que des octets, jamais de chaînes Arduino, d’objets C++, de routes, de JSON ou d’état applicatif.
Rust prend en charge
- Politique de démarrage et exécuteur coopératif
- Routage et protocole Hotaru
- Analyse et réponses HTTP
- Validation et état des servos
C++ gère
Uniquement les opérations nécessitant des symboles Arduino ou ESP8266 :
- Horloges, masquage des interruptions, watchdog, redémarrage, tas, aléatoire et liaison série
- Modes point d’accès et station Wi-Fi, poignées TCP et UDP brutes
- Poignées DNS captif et SPIFFS
- GPIO, PWM, écriture des impulsions de servo et écriture OTA brute
Native WiFiClient, File, and Servo Les objets restent derrière des poignées entières côté C++. Le micrologiciel Arduino embarqué ne possède pas de fonction Rust fn main(), ; la passerelle exporte donc un unique point d’entrée C sans retour qui setup() calls once.
Espace de travail
Les crates
- hcr-gateway
- L’application : politique de démarrage, routage et unique point d’entrée C appelé une fois par Arduino.
- hcr-http
- Analyse et réponses HTTP en no_std, ainsi que le protocole Hotaru.
- hcr-io-esp8266
- Transport Hotaru sur la couche TCP de la plateforme.
- hcr-rt-esp8266
- Environnement d’exécution, temps et sections critiques.
- hcr-platform
- Traits et valeurs de plateforme partagés dans tout l’espace de travail.
- ffi/hcr-ffi
- Le seul crate qui déclare des fonctions matérielles importées et fournit des adaptateurs sûrs par-dessus.
Protocole
L’API actuelle de l’appareil et le contrat hcr.v1
Le service Rust utilise l’enveloppe additive hcr.v1 avec JSON et CBOR. La passerelle ESP8266 actuelle expose une API HTTP/JSON bornée ; MQTT n’est pas encore implémenté.
| Client | Transport | Encodage |
|---|---|---|
| Application web (actuelle) | HTTPS request–response | JSON |
| Contrat du service Rust | Liaison HTTP hcr.v1 | JSON et CBOR |
| Passerelle Rust ESP8266 (actuelle) | HTTP sur le point d’accès de l’appareil | JSON |
| Voie MQTT de l’appareil (prévue) | MQTT over TCP/TLS | CBOR |
Corrélation dans l’enveloppe
La corrélation ne repose pas sur les propriétés MQTT 5. Les appareils peuvent négocier la version 3.1.1 et la liaison HTTP ne possède aucune propriété. Un mécanisme commun est plus fiable que deux solutions partielles.
Les horodatages ne définissent pas l’ordre
Les horloges des appareils ne sont pas fiables ; l’ESP8266 n’accède à NTP que lorsque le routeur fonctionne. L’ordre vient du FIFO de chaque sujet, jamais de l’horloge de l’émetteur.
Versions mineures uniquement additives
De nouveaux champs facultatifs, types et sujets peuvent être ajoutés. Face à un élément inconnu, le récepteur le journalise et l’ignore au lieu d’échouer.