Émetteur-récepteur HF — logiciel embarqué
Architecture firmware d’un transceiver HF
Séparer acquisition, commande RF, interface opérateur, CAT, télémétrie et sécurité afin de conserver un comportement déterministe.
Organisation fonctionnelle
Drivers matériels→HAL→Services RF→Machine d’états→Sécurité→UI locale→CAT/API→Journalisation
Point critique : Un firmware monolithique où chaque bouton agit directement sur les GPIO devient vite impossible à sécuriser et à maintenir.
Découpage logiciel
Les drivers pilotent GPIO, ADC, SPI, I²C, UART et timers.
La couche métier gère fréquence, mode, filtres, puissance et séquençage.
Les interfaces utilisateur ne doivent jamais accéder directement au matériel.
Source de vérité
Un état central représente fréquence, mode, PTT, bande, filtres et défauts.
Chaque modification passe par une validation.
L’état affiché doit provenir de l’état réellement appliqué.
Déterminisme
Les fonctions critiques évitent allocations dynamiques et blocages.
Les interruptions restent courtes.
Les traitements longs sont découpés en tâches contrôlées.
Repères d’ingénierie
Commande valide = intention + contexte + règles de sécurité
État réel ≠ dernière commande reçue
Temps de traitement maximal < période de la tâche
Contrôles systématiques
- Conserver RX comme état sûr par défaut.
- Valider chaque commande avant action matérielle.
- Mesurer le pire temps d’exécution.
- Tester les capteurs invalides et pertes de communication.
- Associer chaque correction à un test de régression.
Procédure recommandée
Validation : toute panne logicielle simulée doit ramener le matériel vers un état réception sûr et explicite.