Guide avancé sur les protocoles de communication dans les microcontrôleurs

Principaux enseignements

• La distance et le nombre de nœuds déterminent le choix du protocole bien avant que le débit ne soit pris en compte ; il faut donc commencer par dimensionner la couche physique, puis adapter le micrologiciel en conséquence.
• Les interfaces SPI, UART, I2C et CAN impliquent chacune un compromis entre différentes ressources ; le bon choix est celui dont le coût peut être pris en charge par votre conception.
• La définition précoce des limites du protocole permet de garantir la portabilité d'un contrôleur embarqué d'un banc d'essai à l'autre et d'une chaîne d'outils à l'autre, au lieu de le limiter à une seule carte.

Le choix d'un protocole de communication pour un microcontrôleur est une décision relative au matériel que l'on prend une fois pour toutes et qui s'applique pendant toute la durée de vie du produit.

Le nombre de broches, la longueur des câbles, le nombre de nœuds et la gestion des erreurs évoluent tous simultanément, et la moindre erreur se traduit par des dysfonctionnements intermittents que personne ne parvient à reproduire. Un véhicule haut de gamme embarque aujourd’hui environ 150 unités de commande électroniques, chacune étant un microcontrôleur qui doit échanger des données sans perdre une seule trame.

Les protocoles SPI, UART, I²C et CAN perdurent car chacun d'entre eux résout un problème différent. Le SPI privilégie le débit au détriment du nombre de broches, l'I²C récupère des broches au prix d'une perte de vitesse, et le CAN mobilise davantage de silicium pour rester opérationnel dans un châssis sujet au bruit. Adaptez le protocole à la contrainte qui s'impose réellement à votre conception, et le micrologiciel qui le gère s'en trouvera simplifié.

Fonctionnement de la communication série au sein d'un système à microcontrôleur

La communication série transfère les données bit par bit via quelques fils, sacrifiant la bande passante parallèle au profit du nombre de broches et de l'espace sur la carte. Chaque protocole d'un microcontrôleur superpose des règles à ce principe, couvrant la synchronisation, la sélection des périphériques et la gestion des erreurs.

Un composant Cortex-M classique intègre plusieurs blocs USART, deux ou trois blocs SPI, quelques blocs I²C et souvent un contrôleur CAN. Ces blocs partagent des broches via un multiplexeur ; c'est donc le protocole que vous choisissez pour un capteur qui détermine quelles broches restent disponibles.

Cinq propriétés déterminent le comportement d'un bus une fois la carte équipée.

• Synchronisation : en effet, un bus synchrone comporte une ligne d'horloge, tandis qu'un bus asynchrone fonctionne à un débit binaire prédéfini.
• L'adressage, qui détermine le nombre d'appareils partageant les câbles.
• Topologie associant des liaisons point à point à des bus multipoints couvrant l'ensemble d'un châssis.
• Portée électrique : en effet, les signaux asymétriques s'affaiblissent sur de longues distances, tandis que les paires différentielles y résistent.
• La gestion des erreurs, c'est-à-dire ce que fait le circuit intégré lorsqu'une somme de contrôle échoue.

Assurez-vous que ces cinq points soient bien en place avant même d'aborder la question des débits de données. Aucun micrologiciel ne pourra corriger une couche physique qui n'a pas été dimensionnée pour la tâche à accomplir.

Pourquoi SPI s'impose lorsque le débit brut est primordial

Le SPI est un bus synchrone en duplex intégral fonctionnant à des fréquences de l'ordre de plusieurs dizaines de mégahertz, car le contrôleur fournit l'horloge et aucune adresse n'est intégrée dans la trame. Quatre fils acheminent l'horloge, deux lignes de données et une ligne de sélection de puce, et chaque périphérique nécessite une broche de sélection supplémentaire.

Les travaux d'affichage illustrent ce compromis. Un écran TFT couleur de 320 × 240 pixels à 30 images par seconde nécessite plusieurs mégaoctets de données de pixels par seconde ; l'interface SPI permet de transférer ces données sans difficulté à 40 MHz, tandis que l'interface I²C à 400 kHz mettrait plusieurs minutes pour traiter une seule image.

Le protocole SPI ne prévoit aucune mesure de contrôle au sein même du protocole. Il ne définit ni accusé de réception ni mécanisme de récupération ; ainsi, lorsqu’un périphérique manque un front d’horloge, il renvoie discrètement des données erronées, et votre micrologiciel doit les détecter à l’aide de son propre CRC. La longueur de la ligne de transmission a également son importance, car une horloge à 40 MHz sur une longueur de 30 centimètres de câble ruban génère des interférences suffisamment importantes pour corrompre les données.

« Cela implique qu’il n’y a ni confirmation ni récupération ; ainsi, un périphérique qui rate un front d’horloge renvoie discrètement des données erronées, et votre micrologiciel doit les détecter à l’aide de son propre CRC. »

Comment l'UART gère les liaisons point à point sans horloge

L'UART relie exactement deux appareils via deux fils, sans horloge commune ; les deux extrémités doivent donc s'accorder au préalable sur un débit binaire. C'est précisément cette simplicité qui en fait la première interface que les ingénieurs activent sur un nouveau matériel et la dernière qu'ils désactivent.

Presque tous les modules que vous achetez le prennent en charge. Un récepteur GNSS transmet des messages de position à 9 600 bauds, et une console de débogage via un pont USB vous fournit des données lisibles quelques minutes après la mise sous tension d'une carte neuve.

Les limites apparaissent dès que l'on ajoute un troisième appareil. L'UART ne prenant pas en charge l'adressage, pour aller au-delà d'une seule liaison, il faut recourir à des émetteurs-récepteurs RS-485 et à un schéma d'adressage que vous devez désormais gérer. La précision de l'horloge constitue l'autre contrainte, car le récepteur échantillonne le milieu de chaque bit et ne tolère qu'une dérive d'environ 2 % ; c'est pourquoi un oscillateur RC interne pose problème à des débits élevés, contrairement à un oscillateur à quartz.

Pourquoi l'I2C est adapté aux réseaux de capteurs disposant d'un nombre limité de broches

Le protocole I2C permet de connecter de nombreux périphériques sur deux fils en attribuant à chacun une adresse de 7 bits que le contrôleur utilise pour le sélectionner. Les sorties à drain ouvert dotées de résistances de rappel haut permettent à n'importe quel périphérique de maintenir une ligne à l'état bas ; c'est ainsi que fonctionnent l'accusé de réception et l'étirement d'horloge sans nécessiter de broches supplémentaires.

C'est dans les groupes de capteurs que cette solution s'avère particulièrement rentable. Un appareil portable peut ainsi intégrer un capteur de température, un accéléromètre, une petite mémoire EEPROM et un moniteur de consommation sur les deux mêmes broches.

Cette commodité s'accompagne toutefois de deux risques de défaillance. Les composants identiques sont souvent livrés avec la même adresse fixe ; ainsi, trois capteurs de pression identiques nécessitent un multiplexeur, et s'en rendre compte au stade du prototype coûte cher. La capacité du bus constitue l'autre limite, car la spécification plafonne un bus standard à 400 pF et les cartes surchargées dépassent cette valeur, ce qui entraîne l'arrêt du fonctionnement à 400 kHz.

Comment le système CAN garantit la fiabilité des contrôleurs décentralisés en présence de parasites électriques

Le protocole CAN transmet les messages sur une paire torsadée différentielle ; ainsi, le bruit électrique affecte les deux fils de manière égale et s'annule au niveau du récepteur. Les nœuds ne sont pas adressés individuellement. Chaque message comporte un identifiant qui définit également sa priorité, et le matériel résout les collisions sans perdre la trame gagnante.

Cette conception a fait ses preuves à grande échelle, avec plus de 2 milliards de nœuds CAN vendus chaque année dans les véhicules et les machines industrielles. Un groupe motopropulseur électrique en explique la raison. La gestion de la batterie, l’onduleur, le chargeur et le tableau de bord sont distants de plusieurs mètres les uns des autres sur une seule paire torsadée, et un message d’erreur provenant de la batterie l’emporte sur une mise à jour de routine concernant la température.

Le silicium prend en charge les fonctions que le micrologiciel aurait autrement assurées. Les contrôleurs CAN gèrent les contrôles CRC, les accusés de réception et les retransmissions, et un nœud qui présente des défaillances répétées se déconnecte automatiquement du bus. Cela a toutefois un coût en termes de taille de charge utile et de planification, car les trames classiques transportent 8 octets, tandis que le protocole CAN FD porte cette capacité à 64 octets, et chaque identifiant doit être attribué avant même que quiconque ne commence à écrire le micrologiciel.

Choisir le protocole adapté aux contraintes de votre application

Commencez par la contrainte physique qui n'est pas négociable, généralement la distance ou le nombre de nœuds, puis examinez seulement ensuite le débit. Une liaison nécessitant 2 mètres de câble à l'intérieur d'une machine exclut d'emblée les protocoles SPI et I2C avant même que la question de la vitesse ne soit abordée.

Les architectures mixtes sont la norme. Un contrôleur de moteur lit les données de son capteur de position via SPI, configure un moniteur de puissance via I²C, met à disposition une interface UART pour les techniciens de maintenance et communique avec le véhicule via CAN. Les équipes d’OPAL-RT sont confrontées à cette même configuration mixte lorsque le code d’un contrôleur embarqué passe d’un prototype de banc d’essai à du matériel de laboratoire, où la compatibilité de la chaîne d’outils permet d’éviter que le portage ne se transforme en une réécriture complète.

Réponses claires aux questions courantes sur les protocoles de communication des microcontrôleurs

Quelle est la principale différence entre SPI et I2C ?

La principale différence entre les interfaces SPI et I²C réside dans le fait que l'interface SPI privilégie la vitesse au détriment du nombre de broches, tandis que l'interface I²C privilégie le nombre de broches au détriment de la vitesse. L'interface SPI nécessite une ligne de sélection par périphérique fonctionnant à des fréquences de l'ordre de plusieurs dizaines de mégahertz, tandis que l'interface I²C partage deux fils entre plusieurs périphériques adressés, avec une fréquence pouvant atteindre 3,4 MHz.

Le bus CAN vaut-il la peine d'être utilisé sur un seul circuit imprimé ?

Rarement. Le CAN justifie son coût lorsque les nœuds sont espacés de plusieurs mètres et soumis à des interférences électriques, et que, sur une même carte, les interfaces SPI ou I²C permettent de transférer les mêmes données avec moins de composants électroniques. La seule exception concerne une carte qui vient s’ajouter à un réseau CAN existant.

Quel protocole faut-il configurer en premier sur un nouveau matériel ?

L'UART, presque toujours. Une console série opérationnelle vous permet d'afficher les sorties à l'écran pour déboguer tout le reste, et elle ne nécessite que deux broches et un réglage correct de l'horloge.

Quand le respect des protocoles porte ses fruits tout au long du cycle de vie d'un produit

Les choix de protocole vieillissent mal lorsqu’ils sont faits pour le prototype plutôt que pour le produit final. Les équipes qui choisissent un bus en se basant uniquement sur la disponibilité des broches passent des années à ajouter des multiplexeurs, des logiques de réessai et des blindages pour soutenir une conception qu’une paire différentielle aurait pu prendre en charge.

Les ingénieurs qui ne sont pas confrontés à ce problème considèrent le bus comme faisant partie intégrante de l'architecture du système. Ils comptent les nœuds et mesurent la longueur des câbles avant de choisir les composants, prévoient dans leur budget l'espace occupé par les broches des lignes de sélection et définissent la table d'identification avant le démarrage du micrologiciel. Rien de tout cela n'a de prestige, mais cela revient moins cher que de traquer un défaut intermittent sur une chaîne de production.

OPAL-RT tire parti de la facilité avec laquelle le code des contrôleurs embarqués passe d’un banc d’essai à l’autre, car une conception dotée de limites de protocole clairement définies s’adapte à différentes chaînes d’outils sans que personne n’ait à réécrire la couche d’interface. Un choix judicieux de protocoles relève d’une ingénierie discrète, qui se traduit par des cartes fonctionnant du premier coup et des bus qui restent fiables longtemps après le départ des personnes qui les ont sélectionnés.

« Les ingénieurs qui ne sont pas confrontés à ce problème considèrent le bus comme faisant partie intégrante de l'architecture du système. »