Le problème
Passer d’octets bruts à une API sûre
Le protocole transporte des payloads hétérogènes : nombre flottant, structure IMU, position GPS optionnelle, état radio. Le driver doit valider le type de réponse, son numéro de séquence et sa longueur avant de construire un objet métier utilisable.
Les erreurs sont séparées en transport, protocole et périphérique. L’appelant sait ainsi si une opération peut être retentée, si les octets sont invalides ou si le device a explicitement refusé la commande.
Architecture
Une API publique découplée du simulateur
DeviceDriver
binary payload
ou mock
simulé
Le simulateur supporte délai artificiel, réponse perdue, statut `BUSY` et corruption. Cela permet d’exercer les politiques de récupération sans modifier la couche C++ ni rendre les tests probabilistes.
Décisions d’ingénierie
Utiliser le type system comme garde-fou
Types dédiés par capteur
`ImuReading`, `GpsFix`, `RadioStatus` et `BatteryReading` rendent l’API explicite.
GPS avec `std::optional`
L’absence de fix est un état métier normal, distinct d’une erreur de transport.
`std::variant` pour les lectures
Une collection hétérogène reste type-safe sans cast ni union manuelle.
Hiérarchie d’exceptions contrôlée
Transport, protocole et statut device sont distingués pour une réaction appropriée.
Démonstration réelle
Onze scénarios du codec au driver
La suite exécutée couvre le vecteur CRC standard, les round-trips, les payloads, le décodage capteur, les retries après timeout ou `BUSY`, les statuts d’erreur et le rejet d’une séquence inattendue.
./simulator/device_simulator.py --socket /tmp/edds_device.sock --verbose
./edds_cli --socket /tmp/edds_device.sock --command allPreuves techniques
Ce que le dépôt permet de vérifier
- Round-trip du codec et détection des magic/CRC invalides.
- Décodage de température, batterie, IMU, GPS et radio en types C++ dédiés.
- Retries après timeout et statut `BUSY`, puis propagation d’un vrai statut d’erreur.
- Documentation séparée du protocole, du simulateur, des tests et de l’architecture.