2) Le protocole I2C :
3) La gestion des conflits :
3.1) Mise en situation :
La structure même du bus I2C a été conçu pour pouvoir y accueillir plusieurs maîtres. Se pose alors le problème commun à tout les réseaux utilisant un canal de communication unique : la prise de parole. En effet, chaque maître pouvant prendre possession du bus dès que celui-ci est libre, il existe la possibilité de que deux maîtres prennent la parole en même temps. Si cela ne pose pas de problème sur le plan électrique grace l'utilisation de collecteurs ouverts, il faut pouvoir détecter cet état de fait pour éviter la corruption des données transmises.
3.2) Principe :
Comme nous l'avons vu précedement, pour prendre le contrôle du bus, un maître potentiel doit d'abord vérifier que celui-ci soit libre, et qu'une condition d'arrèt ait bien été envoyée depuis au moins 4,7µs. Mais il reste la possibilité que plusieurs maîtres prennent le contrôle du bus simultanement.
Chaque circuit vérifie en permanence l'état des lignes SDA et SCL, y compris lorsqu'ils sont eux même en train d'envoyer des données. On distingue alors plusieurs cas :
3.3) Exemple :
Soit le chronogramme suivant :
Dans cet exemple :
Analyse :
Le premier octet est transmis normalement car les deux maîtres imposent les même données. (Cas n°1). Le bit ACK est mis à '0' par l'esclave.
Lors du deuxième octet, le maître n°2 cherche à imposer un '1' (SDA2) , mais relit un '0' (SDAR), il perd alors le contrôle du bus et devient esclave (Cas n°3) . Il reprendra le contrôle du bus, lorsque celui-ci sera de nouveau libre.
Le maître n°1 ne voit pas le conflit et continue à transmettre normalement. (Cas n°2)
Au total, l'esclave à reçu les données du maître n°1 sans erreurs et le conflit est passé inaperçu.