Pourquoi l'ajout d'un deuxième capteur fige votre micro:bit ou votre Arduino

Quand l'ajout d'un capteur supplémentaire paralyse tout un projet micro:bit ou Arduino, le coupable est presque toujours un blocage du bus I2C provoqué par des collisions d'adresses, des résistances de tirage mal dimensionnées ou un conflit de tensions.
Si votre projet fonctionnait parfaitement avec un écran OLED ou un capteur environnemental, mais s'est complètement figé à l'instant où vous avez branché un deuxième capteur, votre code n'a pas simplement rencontré une petite erreur de logique : votre bus de communication est physiquement bloqué. La carte s'arrête parce que le microcontrôleur est coincé dans une boucle infinie, en attente d'un acquittement électrique qui n'arrivera jamais.
Sur des plateformes comme la BBC micro:bit, l'Arduino Uno et l'ESP32, les montages multicapteurs communiquent presque toujours en I2C (Inter-Integrated Circuit). Si l'I2C est populaire parce qu'il ne demande que deux fils de données (SDA et SCL) quel que soit le nombre d'appareils connectés, il est aussi tristement vulnérable aux blocages matériels en un seul point.
Pourquoi l'I2C se fige au lieu d'échouer proprement
Contrairement à une liaison série classique ou à une lecture sur broche numérique, l'I2C repose sur un câblage à drain ouvert. Le microcontrôleur et les capteurs ne forcent pas eux-mêmes les lignes à l'état haut ; des résistances de tirage, externes ou internes, ramènent doucement SDA (données) et SCL (horloge) à la tension de service. N'importe quel appareil du bus peut émettre un signal en tirant la ligne vers la masse.
Lorsque votre code appelle une fonction comme Wire.endTransmission() ou demande des données via une extension MakeCode, le microcontrôleur envoie une trame d'adresse puis attend un bit d'acquittement (ACK). Si un défaut matériel maintient SDA ou SCL à l'état bas, ou si deux appareils brouillent le signal, la bibliothèque synchrone du firmware attend indéfiniment. Pour l'enseignant comme pour l'élève, la carte a tout simplement l'air morte.
Les trois coupables derrière le blocage
Trois situations matérielles courantes expliquent la quasi-totalité des blocages I2C en montage multicapteur, en classe :
1. Des adresses par défaut identiques
Chaque capteur I2C possède une adresse hexadécimale fixe sur 7 bits, gravée dans son silicium. Si vous connectez deux capteurs identiques (par exemple deux accéléromètres MPU6050 ou deux écrans OLED standard de 0,96 pouce), les deux appareils partagent exactement la même adresse (par exemple 0x68 ou 0x3C).
Quand le microcontrôleur diffuse cette adresse, les deux puces tentent de parler au même instant. Leurs lignes de données entrent en collision, brouillent les impulsions d'horloge et bloquent l'état du bus.
| Type de capteur | Adresse par défaut courante | Adresse secondaire (broche basculée) |
|---|---|---|
| MPU-6050 (gyroscope/accéléromètre) | 0x68 | 0x69 (AD0 au 3,3 V) |
| OLED SSD1306 (128x64) | 0x3C | 0x3D (cavalier à souder) |
| BME280 (température/pression) | 0x76 | 0x77 (SDO au VCC ou à la masse) |
| DS3231 (horloge temps réel) | 0x57 / 0x68 | Fixe / pont de soudure |
2. Résistances de tirage absentes ou lignes flottantes
Comme l'I2C compte sur les résistances de tirage pour ramener les lignes à l'état haut, l'absence de tirage laisse les lignes d'horloge et de données flotter de façon imprévisible. À l'inverse, brancher ensemble quatre ou cinq cartes d'extension — chacune équipée de ses propres résistances de tirage de 4,7 kΩ ou 10 kΩ — met toutes ces résistances en parallèle. La résistance totale du bus chute alors si bas que les transistors, peu puissants, à l'intérieur des capteurs standard n'arrivent plus à tirer la ligne jusqu'à 0 V, ce qui provoque des échecs de transmission.
3. Des niveaux logiques 3,3 V et 5 V incompatibles
La BBC micro:bit et les microcontrôleurs ESP32 récents fonctionnent en logique 3,3 V, tandis qu'un Arduino Uno classique ou une ancienne carte d'extension de capteur travaille en 5 V. Si vous branchez sur un bus partagé un capteur 5 V doté de résistances de tirage intégrées à côté d'un capteur 3,3 V, la ligne 5 V va tirer les lignes de données de la micro:bit jusqu'à 5 V. Dans le meilleur des cas, cela corrompt le bus ; dans le pire, cela endommage le capteur 3,3 V ou le périphérique I2C du microcontrôleur.
Une procédure de dépannage en 4 étapes pour la classe
Quand le montage multicapteur d'un élève fige la carte, déroulez cette séquence de diagnostic pas à pas pour localiser rapidement le défaut électrique :
Étape 1 : isoler et scanner
Débranchez le nouveau capteur et vérifiez que le circuit d'origine démarre toujours. Téléversez ensuite sur la carte un script de scanner I2C (facilement disponible dans les exemples Arduino standard ou via des extensions MakeCode de base). Le scanner interroge les adresses de 0x01 à 0x7F et signale sur la liaison série chaque appareil qui répond. Branchez le deuxième capteur seul et scannez-le. Si les deux capteurs annoncent exactement la même adresse hexadécimale, vous avez trouvé la collision.
Étape 2 : changer la broche d'adresse matérielle
La plupart des cartes d'extension proposent une broche de sélection d'adresse (souvent notée ADDR, AD0 ou SDO) ou un petit pont de soudure au dos du circuit imprimé. Relier cette broche au 3,3 V ou à la masse modifie le bit de poids faible de l'adresse de l'appareil. Une fois la broche réaffectée, mettez à jour le code d'initialisation de ce capteur précis pour qu'il utilise l'adresse secondaire.
Étape 3 : contrôler la tension du bus et la longueur des lignes
Assurez-vous que tous les capteurs du bus travaillent à la même tension logique. Si vous devez combiner des modules 5 V avec une micro:bit en 3,3 V, faites passer les signaux par un convertisseur de niveau logique bidirectionnel dédié plutôt que de les câbler en parallèle. Gardez par ailleurs des fils de liaison courts : un câblage long et désordonné sur plaque d'essai ajoute une capacité parasite qui arrondit les impulsions carrées de l'horloge et provoque des pertes de paquets.
Étape 4 : activer les délais d'expiration du pilote
Le code Arduino historique repose sur des fonctions bloquantes. Dans l'IDE Arduino, vous pouvez empêcher le microcontrôleur de se figer définitivement en ajoutant un délai d'expiration du bus après Wire.begin() :
Wire.begin();\nWire.setWireTimeout(3000, true); // délai de 3 ms, réinitialise le bus en cas de blocageSi le bus se bloque à cause d'un fil mal enfiché ou d'un pic électrique, le pilote réinitialise automatiquement le périphérique matériel et poursuit le reste de la boucle au lieu d'arrêter tout le système.
Construire des circuits robustes pour la classe
Expliquer aux élèves comment fonctionne l'I2C sous le capot transforme un blocage silencieux et frustrant en une leçon concrète sur les protocoles de communication. Si vous concevez des kits de robotique multicapteurs pour des clubs ou pour un programme d'enseignement, vous pouvez découvrir des cartes d'extension modulaires et des kits de matériel pédagogique sur la boutique Sheen Robotics, ou bâtir des parcours d'apprentissage complets avec nos leçons structurées sur Sheen Canvas.
En imposant des câblages courts, en vérifiant les adresses matérielles avant d'assembler les projets et en apprenant aux élèves à lire les adresses hexadécimales sur un scanner I2C, vous ferez disparaître le redoutable blocage multicapteur avant qu'il ne perturbe votre cours.



