Bus I2C et SPI : connecter les capteurs

Une adresse I2C tient sur 7 bits : 128 combinaisons possibles, de 0 à 127. Le protocole en réserve seize pour ses usages spéciaux — les adresses 0 à 7 et 120 à 127 — si bien qu'il reste 112 adresses utilisables, de 8 à 119. C'est la taille maximale du carnet d'adresses d'un bus : largement assez pour tous les capteurs d'un robot, sur deux fils seulement.

Les fiches techniques écrivent les adresses en hexadécimal, la notation en base seize des informaticiens : 0x68 se lit « 68 en hexadécimal » et vaut 6 × 16 + 8 = 104 en décimal. Ce n'est qu'une écriture — la puce, elle, ne voit que sept bits. L'adresse est fixée par le fabricant et publiée dans la fiche technique ; certaines puces offrent une broche de sélection qui permet de la décaler d'un cran, on verra bientôt pourquoi c'est précieux.

Chaque échange I2C suit le même rituel. Le maître ouvre par une condition de départ, puis envoie l'adresse visée accompagnée du sens de l'échange — lire ou écrire. La puce qui se reconnaît ACQUITTE : sur le neuvième battement d'horloge, elle tire SDA vers le bas pour dire « présent, bien reçu ». Puis les octets circulent, chacun suivi de son acquittement, jusqu'à la condition d'arrêt qui rend le bus au silence.

Deux règles ne souffrent aucune exception. Un : l'horloge appartient au maître — même quand c'est le périphérique qui fournit les données, c'est le maître qui bat la mesure sur SCL. Deux : un périphérique ne parle jamais spontanément — il attend d'être appelé par son adresse. Cette discipline est ce qui permet à dix puces de cohabiter sur deux fils sans jamais se marcher sur les octets.

Le scanner I2C exploite l'acquittement : il appelle chaque adresse de 8 à 119, sans rien demander d'autre, et note qui répond « présent ». Le résultat est la liste des habitants du bus — par exemple : « périphérique trouvé à l'adresse 0x68 ». Trois secondes d'exécution pour savoir si le câblage vit et qui est branché : c'est LE premier réflexe de débogage, à lancer avant toute lecture de capteur, et le premier programme à écrire sur un bus neuf.

Lis ses verdicts comme un médecin. Le capteur attendu apparaît : câblage bon, adresse confirmée, tu peux dialoguer. Il n'apparaît pas : inutile d'insister en lecture, la panne est plus bas — fils, alimentation, pull-up. Une adresse inconnue surgit : un module embarque une puce dont tu ignorais l'existence, et sa fiche technique te dira laquelle. Le scanner ne répare rien, mais il coupe l'enquête en deux à chaque exécution.

Remets les deux bus côte à côte, chiffres en main. L'I2C rapide bat à 400 kHz : un bit par battement, moins le péage du protocole — adresse, acquittements — soit environ 30 kilooctets utiles par seconde. Immense pour un thermomètre qui livre deux octets dix fois par seconde ; étouffant pour un écran dont chaque image pèse un kilooctet et qui veut se rafraîchir en boucle. Le SPI, à 8 MHz et au-delà, pousse la même image vingt fois plus vite.

La règle de choix tient en une question : combien d'octets par seconde ? Capteurs lents et modules de confort — température, centrale inertielle lue quelques dizaines de fois par seconde, expandeur — vivent très bien sur l'I2C et ses deux fils. Écrans, cartes mémoire et gros flux exigent le SPI et acceptent son fil de sélection supplémentaire. Dans un robot réel, les deux cohabitent : l'I2C fédère les capteurs, le SPI sert les gloutons.