I²C (1/3) : Introduction

Introduction

1. Le protocole I²C
2. Les bases minimales
3. Trop de règles ?
4. Les cas possibles

1. Le protocole Intergrated-to-Integrated-Circuit

Nous n’entrerons pas dans les détails du fonctionnement de l’I2C, en effet il s’agit d’un standart pouvant être géré matériellement par les périphériques. Cette gestion matérielle est confortable pour l’utilisateur qui peut mettre en oeuvre le protocole avec des connaissances minimales : c’est notre cas.

2. Les bases minimales

Il faut quand même comprendre quelques caratéristiques de base de ce protocole pour le mettre en oeuvre. En voici les principales :

1. Two Wire Interface (TWI) : Physiquement, une liaison I2C se compose de deux fils (plus la masse) : SCL pour le signal d'horloge et SDA pour les données.
2. BUS synchrone : Un fil étant réservé à l’horloge, celle-ci est la même pour l’ensemble des périphériques qui communiquent sur le BUS à un instant donné (contrairement à l’UART par exemple).
3. BUS série : Sur un même bus I2C, on peut relier plus de deux périphériques (là encore contrairement à l’UART)

1. Statut de maître/esclave : Il faut de l’ordre. C’est bien beau de pouvoir brancher N périphériques sur un même bus de données, mais il ne faudrait pas qu’ils se mettent à tous parler en même temps ! C’est pourquoi chaque périphérique a un statut : il est soit maître, et s’adresse aux
   esclaves, soit esclave et répond aux maîtres.
   Dès lors, le standard impose deux règles : deux maitres ne peuvent pas communiquer ensemble et deux esclaves ne peuvent pas communiquer ensemble. En fait on peut même dire qu’il y a un seul cas possible : seul un maitre peut s’adresser à un esclave, et celui-ci peut éventuelement lui répondre si il y est autorisé (on y reviendra dans la partie 4). Bien qu’ils ne puissent pas communiquer entre eux, il peut y avoir plusieurs maîtres sur une même ligne, communiquant - éventuellement - avec des esclaves communs...
2. Notion d’adressage : Etant donné qu’il y a plusieurs périphériques sur la ligne, il faut pouvoir les identifier.
   On attribue donc une adresse aux périphériques, mais pas aux maitres. Le standard permet de coder celles-ci sur 7 ou 10 bits. Le nombre d’esclaves que l’on peut mettre sur la même ligne est donc limité à 128 ou 1024.

3. Trop de règles ?

Les notions citées précédement sont d'après moi essentielles pour comprendre la mise en oeuvre qui va suivre. Les explications que j'ai données précédement sont minimales. Pour plus d'informations, consultez les références données en fin de document.

Ces règles peuvent sembler restrictives, et elles le sont, mais elles garantissent un bon fonctionnement du bus de données. En effet, si ces règles sont respectées (et c'est le cas avec la prise en charge matérielle, vous ne vous pouvez pas faire n'importe quoi) le protocole vous protège d'un certain nombre d'erreurs : collisions si deux maîtres décidaient de prendre la ligne en même temps, réponses simultanées... mais non, la définition du protocole fait que cette situation est nécéssairement évitée !

4. Les cas possibles

Il y a 4 cas de communication I²C envisageables

1. Ecriture du maître sur l'esclave avec adressage 7bits
2. Lecture du maître sur l'esclave avec adressage 7bits
3. Ecriture du maître sur l'esclave avec adressage 10bits
4. Lecture du maître sur l'esclave avec adressage 10bits

Dans ces documents, nous n'aborderons que les deux premiers points, qui sont largement suffisants pour des applications robotiques de notre niveau.