Lors de l’intégration d’un module Bluetooth dans une conception, l’une des premières décisions fondamentales est le choix entre trois modèles architecturaux : l’Interface Contrôleur-Hôte (HCI), les commandes AT ou l’intégration SoC. Cette décision n’est pas qu’une simple préférence technique ; elle affecte directement la vitesse de développement, la flexibilité fonctionnelle, les coûts de certification et la scalabilité en production. Cet article compare les trois approches avec des paramètres réels et clarifie les scénarios où chacune présente des avantages.
Vue d’Ensemble des Trois Modèles Architecturaux
Architecture HCI : Le processeur hôte envoie des commandes HCI au contrôleur, qui renvoie des événements et des données ACL. L’hôte exécute le BLE Host Stack (GAP/GATT/SMP/L2CAP) tandis que le contrôleur gère le Link Layer et les couches inférieures. Exemples représentatifs : firmware USB HCI Nordic nRF52840, Cypress CYW43012.
Architecture Commandes AT : Le module exécute en interne la stack complète ; l’hôte envoie seulement des chaînes de commandes ASCII via UART. Aucune connaissance BLE requise côté hôte. Exemples : HC-42, HM-10, Microchip RN4870. Bande passante de connexion : 115200 baud = max 11,5 KB/s de débit effectif.
Intégration SoC : Le code applicatif et la stack BLE s’exécutent sur la même puce, sans MCU hôte externe. Exemples : nRF52833 (512KB Flash/128KB RAM), ESP32-C3, Silicon Labs EFR32BG22.
Comparaison des Principales Piles de Protocoles
| Stack | Licence | Puces Compatibles | Flash/RAM Min. | Caractéristiques |
|---|---|---|---|---|
| Zephyr BLE | Apache 2.0 (gratuite) | Nordic, ST, NXP et autres | ~256KB/~64KB | Multiprotocole, communauté active |
| NimBLE | Apache 2.0 (gratuite) | ESP32, Nordic, autres | ~100KB/~32KB | Léger, natif ESP-IDF |
| SoftDevice | Propriétaire Nordic (usage gratuit) | Série nRF52 uniquement | ~148KB/~8KB | Certifié, support officiel Nordic |
| BGAPI | Propriétaire Silicon Labs | Série EFR32BG | ~200KB/~32KB | Compatible AT, modes NCP/SoC |
Analyse Détaillée de l’Architecture HCI
HCI offre la flexibilité maximale mais aussi le coût d’implémentation le plus élevé côté hôte. Pour UART HCI, le tramage H4 (indicateur de type de paquet sur 1 octet) est utilisé, avec un débit maximum généralement de 1 Mbps. USB HCI utilise des endpoints isochrones pour supporter Bluetooth 5.2 LE Audio.
Détails d’Implémentation des Commandes AT
Les modules à commandes AT maximisent la vitesse de développement mais ont des contraintes de débit et de latence. Séquence de commandes représentative :
AT+RESET // Réinitialiser le module
AT+ROLE=1 // Configurer le mode périphérique
AT+NAME=MyDevice // Définir le nom du dispositif
AT+UUID=FFE0 // Configurer l'UUID du service
AT+CHAR=FFE1 // Configurer l'UUID de la caractéristique
AT+NOTI=1 // Activer les notifications
AT+ADVEN=1 // Démarrer la publicitéCaractéristiques de latence : temps de traitement des commandes AT = analyse de commandes (~1ms) + traitement stack (~5-50ms) + temps d’écho UART. La latence des événements de connexion est typiquement de 50-200ms, plus élevée que la manipulation directe HCI (~10-30ms).
Stratégie d’Implémentation de l’Intégration SoC
L’intégration SoC est l’approche la plus élégante, minimisant le nombre de composants BOM et optimisant la consommation énergétique. Cependant, elle nécessite une connaissance approfondie de la stack BLE dans l’équipe de développement.
En prenant nRF52833 comme exemple, consommation de ressources de SoftDevice S140 (v7.3.0) : Flash 148KB (0x00000-0x26000), RAM 8KB, Flash disponible pour l’application ~364KB. SoftDevice S113 (orienté économie d’énergie) nécessite Flash 112KB, RAM 6KB (périphérique seulement).
Conception d’Interface : Choix entre UART et SPI
| Paramètre | UART | SPI |
|---|---|---|
| Vitesse maximale | Jusqu’à 4Mbps (contrôle de flux requis) | Jusqu’à 8Mbps (selon le module) |
| Nombre de broches | 2 (TX/RX) + 2 (CTS/RTS) | 4 (MOSI/MISO/CLK/CS) + interruption |
| Charge CPU | Faible avec DMA | Faible avec DMA |
| Synchronisation | Asynchrone | Synchrone (horloge maître) |
| Application | Priorité coût, vitesse moyenne | Haut débit, environnement bruité |
Analyse des Coûts de Certification RF
| Scénario de Certification | Coût Estimé | Durée |
|---|---|---|
| Adoption de module certifié (commandes AT) | 2 000-8 000$ (produit final uniquement) | 4-8 semaines |
| HCI + module contrôleur certifié | 5 000-15 000$ | 6-12 semaines |
| Conception SoC personnalisée (certification complète) | 15 000-60 000$ | 16-32 semaines |
Adéquation Architecturale par Volume de Production
| Volume de Production | Architecture Recommandée | Justification |
|---|---|---|
| <1 000 unités/an | Module à commandes AT | Priorité vitesse de développement, BOM élevé acceptable |
| 1 000-50 000 unités/an | HCI + module certifié | Équilibre flexibilité-coût |
| 50 000-200 000 unités/an | SoC + stack commercial (SoftDevice) | Réduction BOM amortit l’investissement |
| >200 000 unités/an | SoC + stack open source (Zephyr) | Sans royalties, contrôle total |
Exemple de calcul du seuil de rentabilité : module AT (HM-10, 3,50$/unité) vs conception SoC personnalisée (nRF52810, 1,80$/unité, coût de développement 80 000$). Seuil de rentabilité = 80 000$ ÷ (3,50$ – 1,80$) ≈ 47 000 unités. La conception SoC devient avantageuse au-delà de 50 000 unités de production.
Conclusion
La sélection de la pile de protocoles pour les modules Bluetooth est un compromis de conception sans réponse unique « optimale ». Les commandes AT permettent la mise sur le marché la plus rapide, HCI offre une flexibilité maximale avec les systèmes hôtes existants, et l’intégration SoC fournit la solution optimale pour les coûts de production en série et la consommation énergétique. L’essentiel est d’évaluer honnêtement le volume de production cible, les ressources de développement disponibles et le budget de certification — puis de choisir l’architecture la mieux adaptée à ces contraintes. Changer d’architecture en cours de projet engendre des réécritures importantes du firmware et des recertifications, rendant le choix initial particulièrement critique. Pour plus d’informations techniques sur les modules Bluetooth, contactez notre équipe d’ingénierie.