Piles de protocoles. Ce qui circule réellement au-dessus du bus physique

Tout ce que nous avons couvert jusqu'ici. UART, SPI, I2C, CAN, RS-485. concerne essentiellement les couches 1 et 2. Cela amène des bits d'une puce à une autre, de manière fiable. Mais les bits ne sont que des bits. Que signifient-ils ? C'est le travail de la couche de protocole au-dessus.

C'est là que réside la plupart de la complexité du monde réel. Une trame Modbus RTU ne signifie rien sans la cartographie de registres. Une trame CAN ne signifie rien sans connaître la correspondance ID-signal. Le bus physique n'est que le transport ; le protocole par-dessus est le contrat.

Le modèle de couches pour l'embarqué

Rendering diagram...

Quand quelque chose casse, savoir à quelle couche se situe le problème réduit considérablement le temps de débogage.

RS-485 + Modbus RTU

La pile industrielle la plus courante. Modbus RTU repose directement sur RS-485, sans tramage supplémentaire nécessaire. la trame Modbus est transmise sous forme d'octets bruts à la vitesse en bauds convenue.

Application : "Obtenir le débit depuis le compteur à l'adresse 4"
Modbus :      [04][03][00 1E][00 01][CRC16]
RS-485 :      tension différentielle sur paire torsadée

L'application ne se soucie que des numéros de registres et des valeurs d'ingénierie. Modbus gère le tramage. RS-485 gère la livraison électrique.

CAN + CANopen

CANopen est un protocole de couche supérieure construit sur CAN, largement utilisé en automatisation industrielle, appareils médicaux et contrôle de mouvement. Il définit un dictionnaire d'objets standard. une table de paramètres que chaque appareil doit exposer. Les données en temps réel sont échangées via PDO (Process Data Objects) ; la configuration utilise des SDO (Service Data Objects).

Rendering diagram...

CANopen est plus lourd que Modbus brut, mais standardise des choses que Modbus n'a jamais essayé : profils de variateurs, séquences de mouvement, identification d'appareils.

I2C + SMBus

SMBus (System Management Bus) est un sous-ensemble d'I2C conçu à l'origine pour les batteries de laptops et la gestion d'énergie ACPI. Il ajoute :

• Vérification d'erreur de paquet (PEC) : un octet CRC supplémentaire après chaque transaction
• Une spécification de timing minimum fixe (pas d'extension d'horloge indéfinie)
• Commandes standard : ReadByte, WriteWord, BlockRead, etc.

Si vous utilisez un CI de jauge de batterie (comme BQ27546 ou MAX17055), il parle presque certainement SMBus sur ses pins I2C. La différence en pratique : activez PEC dans votre pilote I2C et c'est tout.

SPI + protocole carte SD + FAT32

Les cartes SD exportent un protocole assez complexe en mode SPI. séquences d'initialisation, commandes de lecture/écriture avec jetons de réponse R1/R2/R3, blocs de données avec CRC16. Par-dessus fonctionne FAT32 ou exFAT.

Rendering diagram...

Chaque couche ignore ce qui se trouve dans celle au-dessus. Cette séparation permet de remplacer n'importe quelle couche indépendamment. remplacez la carte SD par une flash QSPI, gardez FAT32 par-dessus sans changement.

Conseil de débogage : remontez depuis le bas

L'erreur de débogage la plus courante est de commencer par la couche applicative quand le problème est physique. Si votre lecture Modbus retourne des données incorrectes, vérifiez la tension différentielle RS-485 avec un multimètre avant d'examiner les cartographies de registres. Si I2C se bloque, mettez un oscilloscope sur SDA et SCL avant de lire le code source de la bibliothèque capteur.

Les problèmes de couche physique se déguisent continuellement en problèmes de protocole. Terminez votre bus, corrigez vos résistances de tirage, obtenez un signal propre. puis déboguez le protocole.