Tutoriel · Débutant · 30 min de lecture

Comment marche le bus I2C : adresses et résistances de rappel

Deux fils, un bus partagé : le rôle réel des résistances de rappel, pourquoi empiler des cartes casse tout, et comment résoudre une collision d'adresses.

Introduction

Chaque page de capteurs de ce site dit de brancher SDA et SCL, et aucune ne dit ce que ces deux fils font. La plupart du temps pas besoin de le savoir — vous câblez, la bibliothèque marche, et le capteur lit.

Puis vous ajoutez une seconde carte et la première cesse de répondre. Ou la bibliothèque renvoie des zéros sans erreur. Ou deux appareils veulent la même adresse et rien dans la documentation ne dit quoi faire.

Tout cela est le même petit ensemble de faits sur I²C, et ils sont moins nombreux que les symptômes le suggèrent.

Deux fils, beaucoup d’appareils

I²C met chaque appareil sur une paire de fils partagée :

  • SDA — la ligne de données.
  • SCL — l’horloge, toujours pilotée par le contrôleur.

Sur un Arduino Uno, ce sont A4 et A5 (et les broches en double à côté d’AREF — les deux mêmes broches, pas des supplémentaires). Chaque appareil se branche aux deux mêmes, en parallèle. Pas de fil de sélection ni d’anneau : ajouter un appareil signifie le souder à la même paire.

C’est pourquoi cela passe si bien à l’échelle pour les robots. Un MPU-6050, un VL53L0X et un PCA9685 partagent tous les deux fils et se distinguent par l’adresse plutôt que par le câblage.

Personne ne pilote la ligne au niveau haut

C’est le fait dont tout le reste découle.

Un appareil I²C ne peut que tirer une ligne vers le bas. Il ne peut pas la piloter au niveau haut — la sortie est en collecteur ouvert, c’est-à-dire un interrupteur vers la masse et rien de plus. Laissée seule, la ligne flotterait à aucune tension particulière.

Les résistances de rappel sont ce qui met la ligne au niveau haut. Elles ne sont pas une mesure de robustesse ni un supplément optionnel ; elles sont la moitié du circuit, et sans elles le bus n’a pas d’état de repos et rien ne marche.

Le collecteur ouvert a un vrai avantage, et c’est pourquoi c’est fait ainsi : si deux appareils parlent à la fois, l’un tirant bas et l’autre relâchant, le résultat est bas. Rien ne lutte, rien n’est court-circuité, et l’appareil perdant peut le détecter. Sur un bus où tout appareil peut parler, cela compte.

La fenêtre où un rappel doit vivre

Il y a des limites des deux côtés, et elles sont calculables.

Trop bas et aucun appareil ne peut tirer la ligne vers le bas. La spécification exige qu’un appareil absorbe au moins 3 mA en tenant la ligne sous 0,4 V, donc :

R_min = (Vcc − V_OL) / I_sink = (5 − 0.4) / 0.003 = 1533 Ω

Trop haut et le front montant est trop lent. La ligne monte en courbe RC contre la capacité du bus, et l’horloge n’attendra pas :

t_rise ≈ 0.85 × R × C        ≤ 1000 ns at 100 kHz, ≤ 300 ns at 400 kHz
Un graphe en échelle logarithmique de la résistance de rappel permise en fonction de la capacité totale du bus. Deux courbes descendantes marquent le plafond du temps de montée pour 100 kilohertz et 400 kilohertz, et une ligne rouge horizontale à 1533 ohms marque le plancher sous lequel aucun appareil ne peut absorber assez de courant pour tirer la ligne au niveau bas. Quatre lignes horizontales en pointillés marquent la résistance effective d'une, deux, trois et quatre cartes d'extension empilées à 4700, 2350, 1567 et 1175 ohms ; la ligne à quatre cartes passe sous le plancher.
La bande utilisable se tient entre le plancher du courant absorbé et le plafond du temps de montée. Notez où va le 400 kHz sur un bus lourdement chargé : passé environ 250 pF son plafond passe sous le plancher, donc le mode rapide y est inatteignable avec de simples résistances. Télécharger le SVG

Maintenant la partie qui attrape les gens. Presque chaque carte d’extension amateur a ses propres rappels déjà montés, d’ordinaire 4,7 kΩ. Câblez-en plusieurs au même bus et ces résistances sont en parallèle :

Cartes sur le bus Rappel effectif Verdict
1 4700 Ω Bien
2 2350 Ω Bien
3 1567 Ω Limite — 34 Ω au-dessus du plancher
4 1175 Ω Sous le plancher

La panne a donc une forme précise : un capteur marche, deux marchent, trois marchent les bons jours, et la quatrième carte arrête tout le bus. Rien n’est cassé. Les appareils ne peuvent simplement plus tirer la ligne assez bas pour être lus comme un niveau bas.

Le correctif est de retirer les résistances de rappel de toutes les cartes sauf une — ce sont d’ordinaire deux petites résistances CMS marquées 472, et la documentation de la carte dit lesquelles. Les dessouder semble faux la première fois et c’est la bonne réponse.

Balayez le bus avant de déboguer quoi que ce soit d’autre

Avant de toucher une bibliothèque, demandez au bus ce qui s’y trouve. Ce programme essaie chaque adresse et rapporte celles qui répondent :

#include <Wire.h>

void setup() {
  Wire.begin();
  Serial.begin(115200);
  while (!Serial) {}

  Serial.println(F("Scanning I2C..."));
  uint8_t found = 0;
  for (uint8_t addr = 1; addr < 127; addr++) {
    Wire.beginTransmission(addr);
    if (Wire.endTransmission() == 0) {
      Serial.print(F("  device at 0x"));
      Serial.println(addr, HEX);
      found++;
    }
  }
  Serial.println(found ? F("done") : F("nothing answered — check wiring and pull-ups"));
}

void loop() {}

Le résultat dit quel problème vous avez :

  • Rien ne répond → câblage, alimentation, ou rappels manquants. Pas la bibliothèque.
  • L’appareil répond à une adresse inattendue → une broche de sanglage d’adresse est réglée autrement que supposé.
  • L’appareil répond, mais la bibliothèque renvoie des zéros → le bus va bien et le problème est au-dessus.

Cette dernière ligne vaut tout le programme. Elle sépare proprement « le fil est faux » de « le code est faux », ce qui fait sinon l’essentiel du temps de débogage.

Les adresses, et la confusion du 0xD0

Une adresse I²C fait 7 bits. Seize valeurs sont réservées, restant 112 utilisables.

Voici le piège. Sur le fil, l’adresse est envoyée comme sept bits suivis d’un bit lecture/écriture, donc elle ressemble à une valeur 8 bits. Les fiches techniques citent fréquemment cette forme 8 bits. La bibliothèque Wire d’Arduino veut la forme 7 bits.

Une fiche technique de MPU-6050 dit que son adresse est 0xD0 en écriture et 0xD1 en lecture. La bibliothèque Wire veut 0x68 :

0xD0 = 1101 0000
0x68 = 0110 1000        the same bits, shifted right by one

Si un appareil ne répond pas à l’adresse imprimée dans sa fiche technique, essayez cette valeur décalée d’un cran à droite avant de conclure que la carte est morte. C’est l’erreur I²C la plus courante qui soit.

Quand deux appareils veulent la même adresse

Les adresses sont fixées par le fabricant, donc les collisions sont de routine. Trois correctifs, par ordre de préférence :

1. Une broche de sanglage d’adresse. Le correctif le moins cher, quand la pièce en a une. Un MPU-6050 se tient à 0x68, ou 0x69 avec sa broche AD0 au niveau haut — donc deux coexistent avec un fil. Un PCA9685 a six cavaliers à souder donnant 64 adresses, et c’est pourquoi vous pouvez chaîner jusqu’à 62 cartes sur un bus.

2. Tenez les autres en reset pendant que vous réadressez l’une. Certaines pièces ont une adresse fixe mais reprogrammable à l’exécution. Un VL53L0X est toujours 0x29 sortie de boîte, et c’est la façon standard d’en faire tourner plusieurs : tenez la broche XSHUT de chaque capteur basse, montez-en un, dites-lui de passer à une nouvelle adresse, et répétez. La nouvelle adresse vit en RAM, donc la séquence rejoue à chaque démarrage.

3. Un multiplexeur. Un TCA9548A est un appareil en 0x70 avec huit bus commutés derrière. Sélectionnez une voie, parlez à l’appareil dessus, sélectionnez la suivante. C’est la réponse pour huit capteurs identiques sans broche de sanglage ni réadressage — au prix d’une pièce, et d’un bus l’un après l’autre.

Vitesse, longueur, et ce qui casse vraiment

I²C a été conçu pour courir entre puces d’une carte. Un robot l’étire à travers un châssis, et c’est là que les limites commencent à mordre.

  • La capacité est la vraie limite, pas la longueur. La spécification permet 400 pF au total. Le câble en nappe ajoute environ 50–100 pF par mètre, et chaque appareil ajoute environ 10 pF. Les longues courses échouent en ralentissant le front montant — ce que la figure ci-dessus montre comme le plafond qui chute.
  • Ralentissez avant d’abandonner. Wire.setClock(50000) divise par deux le débit standard et achète une vraie marge sur un bus limite. Un robot qui sonde un capteur à 100 Hz n’a pas besoin de 400 kHz.
  • Gardez SDA et SCL écartés. Les faire courir en paire adjacente dans une nappe couple les fronts d’horloge dans les données. Un fil de masse entre eux aide.
  • Étirement d’horloge. Un appareil qui a besoin de temps peut tenir SCL bas, et le contrôleur doit attendre. Le vrai I²C matériel le gère ; certaines implémentations bit-bang non, et le symptôme est un appareil qui marche seul et corrompt les données quand le bus est occupé.
  • Un bus coincé. Si un appareil a été réinitialisé en plein transfert, il peut tenir SDA bas indéfiniment, et chaque balayage ne renvoie rien. Impulser SCL neuf fois le laisse finir l’octet qu’il croyait envoyer et relâcher la ligne — c’est ce que fait la routine de reprise d’une bonne bibliothèque.

Mélanger 3,3 V et 5 V

Un ESP32 et un Raspberry Pi font tourner leur I²C en 3,3 V ; un Uno le fait en 5 V. Parce que le bus est en collecteur ouvert, la tension de rappel décide du niveau haut pour tout le monde dessus. Rappelez à 5 V avec une pièce 3,3 V seulement branchée et vous mettez 5 V dans une broche calibrée pour 3,6 V.

Deux choses vous sauvent la plupart du temps, et il vaut de savoir à laquelle vous vous fiez :

  • Beaucoup de cartes « compatibles 5 V » sont une puce 3,3 V avec un régulateur et une adaptation de niveaux déjà sur la carte. Vérifiez avant de supposer — la présence d’un régulateur de tension seul ne signifie pas que les broches de signal sont protégées.
  • Là où elles ne le sont pas, un adaptateur de niveaux bidirectionnel à MOSFET est la réponse standard. Un diviseur à résistances ne l’est pas : il casse le comportement en collecteur ouvert dans le sens qui compte.

Quand ça tourne mal

Symptôme Généralement
Le scanner ne trouve rien du tout Rappels manquants, SDA/SCL permutés, ou pas de masse commune
Marchait avec trois cartes, meurt avec quatre Rappels en parallèle sous le plancher du courant absorbé
Appareil absent à son adresse de fiche technique Adresse 8 bits citée ; décalez d’un cran à droite
Deux capteurs identiques, un seul répond Collision d’adresses — broche de sanglage, XSHUT, ou multiplexeur
Lit bien en court, échoue sur un long câble Capacité du bus ; ralentissez l’horloge ou raccourcissez
Corruption intermittente pendant que les moteurs tournent Bruit d’alimentation — voir alimentation et microcoupures
Le scanner ne renvoie soudain plus rien après un plantage Un appareil coincé tenant SDA bas ; pulsez SCL neuf fois
Marche seul, corrompt quand le bus est occupé Étirement d’horloge que le contrôleur n’honore pas

L’habitude utile est de lancer le scanner d’abord, à chaque fois, avant d’ouvrir la source d’une bibliothèque. Cela prend trente secondes et cela coupe le problème en deux — et la moitié de tout débogage I²C est de ne pas savoir de quel côté du fil est la panne.

Explorer le graphe

Fait partie de ces réalisations

Les projets et parcours d'apprentissage qui incluent ce tutoriel.

Pour aller plus loin

Références