P.06Prototype interne
Systèmes embarqués
Travaux bas niveau en C et C++ : lecture OBD-II multi-canaux, chronométrage réseau sur microcontrôleur, instrumentation graphique temps réel.
- Période
- 2025 – 2026
- Rôle
- Acquisition, protocoles, affichage, outillage de build.
- Stack
- C
- C++
- Python
- OBD-II
- sockets TCP
- ESP32
- Make
Repères
8
canaux véhicule lus en parallèle
sorties CSV déclarées dans le module d'acquisition
1 ms
période de scrutation
paramètre poll_interval du module d'acquisition
0,1 s
délai de reconnexion
paramètre reconnect_delay du module d'acquisition
Le problème
Entre le calculateur d'une voiture et un écran lisible, il y a une longue suite de choses qui n'existent pas toutes seules : un lien série ou réseau qui se coupe, des canaux qui répondent à des rythmes différents, et un affichage qui ne doit jamais attendre la donnée.
Ce qui a été construit
- 01
Une lecture OBD-II de huit canaux — régime, vitesse, carburant, température de liquide, pression de pneus, pression de freins, position de pédale, rapport engagé — chacun écrit dans son propre fichier.
- 02
Une reconnexion automatique : la coupure du lien n'interrompt ni la lecture des autres canaux ni l'écriture sur disque.
- 03
Un affichage en C : compteur de vitesse et compte-tours dessinés, alimentés par le flux Python via un lien local.
- 04
Un chronométrage en C++ qui interroge un microcontrôleur en réseau et horodate les passages, un fil d'exécution par voiture.
- 05
Un lanceur qui démarre les deux processus, propage les signaux d'arrêt aux enfants et ne laisse pas de processus orphelin.
Architecture
Décisions techniques
Un fichier par canal
Les canaux OBD-II ne répondent pas au même rythme et certains ne répondent pas du tout selon le véhicule. Un fichier unique aurait imposé d'attendre le canal le plus lent, ou d'écrire des trous. Un fichier par canal permet à chacun d'avancer à sa cadence, et l'absence d'un capteur se voit immédiatement : le fichier reste vide.
Écriture forcée sur disque
Chaque relevé est vidé du tampon puis synchronisé sur le support. Sur une acquisition en voiture, la session se termine rarement proprement : on coupe le contact, on débranche, la batterie de l'ordinateur lâche. Une donnée restée dans un tampon système est une donnée perdue.
Propagation explicite des signaux d'arrêt
Le lanceur intercepte l'interruption et termine ses enfants avant de sortir. Sans cela, un Ctrl-C laisse un processus Python accroché au port série, et le lancement suivant échoue sur un périphérique occupé — sur le bord d'une piste, avec un ordinateur portable et cinq minutes devant soi, ce détail décide si la séance a lieu.
Ce que ça démontre
Programmation système, protocoles véhicule, robustesse aux coupures, gestion de processus et de signaux.