Accueil » Ressources » Blog » Communication I2C

Communication I2C

Introduction

I2C (ou IIC) contraction de Inter-IC Communication, est un des plus populaires protocoles de communication implémenté sur les microcontrôleurs. Il est couramment utilisé pour interagir avec des capteurs mais se retrouve également dans beaucoup d’autres applications.

I2C est un protocole de communication synchrone, ce qui signifie qu’il existe une ligne horloge dédiée (voir les protocoles de communication synchrones/asynchrones).

Communication I2C

Bien que l’I2C n’utilise que deux lignes de communication (horloge et données), il peut prendre en charge plusieurs périphériques sur le même bus I2C. Cela est réalisé en utilisant un schéma d’adressage où chaque périphérique sur le bus a une adresse unique. La communication commence par l’envoi de l’adresse du périphérique avec lequel la communication est prévue, et le périphérique adressé doit ensuite accuser réception en indiquant qu’il est présent et prêt à communiquer.

Comme il n’y a qu’une seule ligne de données (SDA – données sérielles), utilisée à la fois pour l’envoi et la réception de données (mode half-duplex), un mécanisme est nécessaire pour permettre au maître et au périphérique esclave de contrôler la ligne de données sans conflits. Il est essentiel d’éviter les contentions sur le bus, où un périphérique tente d’écrire un niveau haut sur le bus tandis qu’un autre périphérique tente d’écrire un niveau bas sur le bus, ce qui créerait un court-circuit.

Pour y parvenir, on utilise un mécanisme open-drain ; où chaque périphérique ne peut mettre le bus qu’à un niveau « bas » ou le « relâcher », et des résistances de tirage sont utilisées pour ramener la ligne à un niveau haut lorsqu’elle est relâchée (si vous n’êtes pas familier avec les termes open-drain ou résistance de tirage, veuillez consulter notre article sur le sujet). La ligne d’horloge (SCL – Horloge sérielle) utilise également ce mécanisme, et quelques techniques innovantes sont utilisées pour ajouter des fonctionnalités utiles au protocole I2C – nous en parlerons plus en détail sous peu.

Le diagramme ci-dessous illustre les caractéristiques typiques d’une séquence de communication I2C.

La communication débute avec le bus I2C en état de repos – les lignes d’horloge et de données ne sont pas activées et sont donc tirées vers le haut par les résistances de tirage. Ensuite, la communication est initiée par le maître (le périphérique initiant la communication) tirant d’abord la ligne SDA puis la ligne SCL vers le bas – cela est défini comme une condition de départ (Start).

Ensuite, le maître transmet l’adresse sur 7 bits du périphérique avec lequel il souhaite communiquer, suivie d’un bit « lire ou écrire » qui indique si le maître souhaite écrire (0) ou lire (1) à partir du périphérique. La ligne de données est considérée comme valide (lue par les esclaves) sur les fronts montants de la ligne d’horloge, et les données sont transmises en commençant par le bit le plus significatif (MSB).

Après que l’adresse a été transmise, et en supposant que l’esclave adressé est présent sur le bus I2C, le maître relâchera la ligne de données (open drain), et l’esclave maintiendra la ligne de données basse pendant un cycle d’horloge pour accuser réception (ack) qu’il est présent et prêt à communiquer. Si l’esclave n’est pas présent sur le bus, alors la résistance de tirage tirera la ligne de données vers le haut, et le maître saura que l’esclave n’est pas disponible.

À ce stade, les données peuvent être transmises entre le maître et l’esclave. Si des données sont lues, alors l’esclave transmettra les données (pendant que le maître continue de piloter la ligne d’horloge), ou si des données sont écrites, alors le maître transmettra les données. Après chaque octet de données, il y a un seul bit d’acquittement (Ack), pendant lequel le récepteur (qui peut être le maître ou l’esclave, selon le côté qui a transmis les données) doit maintenir la ligne de données basse pour indiquer qu’il a reçu la communication (et qu’il est prêt à passer à la communication suivante si nécessaire).

Etirement d'horloge

Les périphériques esclaves sur le bus I2C ont la capacité de retarder leurs réponses (s’ils sont toujours occupés et ne sont pas encore prêts à répondre) en maintenant la ligne d’horloge (SCL) à un niveau bas, une fonctionnalité connue sous le nom d’« étirement d’horloge » (clock stretching) ; une fois prêt à répondre, l’esclave relâche la ligne d’horloge et la transmission des données se poursuit. Ceci est similaire aux lignes de contrôle de flux dans l’UART (CTS/RTS), mais sans nécessiter de lignes de communication supplémentaires (notez que le protocole SPI n’a pas de fonction de contrôle de flux).

Un ou plusieurs octets de données peuvent être communiqués en séquence, avec un acquittement (ack) survenant après chaque octet.

Redémarrage

Parce que les périphériques esclaves peuvent avoir une multitude de valeurs disponibles à lire (telles que plusieurs valeurs de capteurs ainsi que des valeurs de réglages), l’esclave peut exiger que le maître émette d’abord une instruction indiquant ce qu’il souhaite lire avant de procéder à la lecture effective. Dans ce cas, le maître émettra d’abord une écriture avec les données indiquant ce qui doit être lu, puis le maître émettra immédiatement après une lecture. Cependant, il n’y a pas d’arrêt émis entre les deux. À la place, le maître utilise une condition de redémarrage (repeated start), suivie de l’adresse de 7 bits et du bit de lecture/écriture d’1 bit, maintenant réglé sur lecture, pour passer de l’écriture à la lecture. Pour émettre un redémarrage, le maître place d’abord la ligne de données à un niveau haut, puis la ligne d’horloge, et ensuite le maître abaisse la ligne de données suivie de la ligne d’horloge.

Débit et distances

La communication sur le bus I2C se déroule généralement à des vitesses de 100 kHz ou 400 kHz. Ces vitesses relativement basses conviennent bien pour de petites quantités de transmission de données, mais le SPI (utilisant des horloges dans la plage des mégahertz, et éventuellement en mode Dual ou Quad) est généralement préféré pour des applications à haut débit où de grandes quantités de données doivent être transmises. L’I2C est plutôt utilisé pour des communications sur des distances relativement courtes, cependant, des mécanismes existent permettant la transmission d’I2C sur des paires différentielles pour communiquer sur des distances plus longues (veuillez consulter notre article sur la conception à haut débit pour plus d’informations sur les paires différentielles).

Proteus inclut un instrument analyseur de protocole I2C en mode DUAL (maître ou esclave) à placer sur les liens du schéma. Cela vous permet ensuite de saisir et d’injecter des séquences I2C dans la simulation en cours et de visualiser les paquets reçus en provenance d’autres périphériques sur le bus I2C. C’est un excellent outil pédagogique qui permet un test rapide et facile des firmwares en mode maître et en mode esclave. Vous trouverez beaucoup d’exemples de projets qui incluent des communications I2C avec des capteurs ou des projets multi-processeurs. Tous ceux-ci peuvent être simulés dans la version de démonstration.


Copyright Labcenter Electronics Ltd. 2024

Traduction française

Copyright Multipower France 2024

Retour en haut