Trois pièges dans I2C que tout le monde souhaiterait ne pas exister

La meilleure partie d'I2C est qu'il s'agit d'un bus disponible à peu près partout, couvrant un vaste écosystème de périphériques qui l'offrent comme une interface définie par le matériel, tout en étant suffisamment simple pour pouvoir également être implémenté uniquement par logiciel sur un simple GPIO. épingles. Malgré cette popularité, I2C est l'une de ces célèbres normes informelles qui présentent quelques implémentations populaires, tout en laissant de nombreux détails tels que le timing exact, la capacité du bus et d'autres détails fastidieux aux pauvres gens chargés du développement du produit. C'est ainsi que nous nous retrouvons avec des articles comme un récent sur le blog tordant [paire de poires pared], couvrant les problèmes rencontrés lors de la mise en œuvre d'un esclave I2C.

Comme pour tout bus partagé, qu'il soit multi-maître ou non, déterminer quand le bus est libre est un sujet amusant, mais qui peut causer des maux de tête sans fin. Un problème ici vient d'une fonctionnalité que la version SMBus d'I2C appelle lecture/écriture rapide. Cela permet le transfert rapide de certaines données. Néanmoins, en fonction des données renvoyées par l'esclave, il peut sembler au maître que rien ne se passe encore, puisque le SDA est maintenu bas par l'esclave jusqu'à la condition d'arrêt, verrouillant essentiellement le bus.

Là où les choses deviennent encore plus excitantes, c'est généralement sous la forme de ce que les analyseurs logiques aiment appeler de manière traumatisante une « fausse condition de démarrage/arrêt ». Cela fait référence au comportement de SDA et SCL, SDA étant faible avant que SCL n'indique une erreur. Cela peut se produire en raison d'un temps d'attente trop court, ce qui fait que d'autres appareils sur le bus manquent la transition. Ici, SMBus définit un temps de transition de 300 ns, tandis qu'I2C appelle 0 seconde, mais il est désormais suggéré de retarder l'appel d'une condition de démarrage/arrêt jusqu'à ce qu'un délai de 300 ns soit écoulé. Essentiellement, il semblerait que la mise en place d’un délai d’attente soit la voie à suivre jusqu’à ce que la preuve du contraire apparaisse.

Le troisième écueil concerne les modes I2C à vitesse plus élevée, notamment Fast-Mode (FM) et Fast-Mode Plus (FM+). La rétrocompatibilité avec ces versions à vitesse plus élevée est absente ou inégale. Bien que FM+ (introduit par NXP en 2007) soit censé être rétrocompatible avec des vitesses plus lentes, les différences d'exigences de synchronisation entre les normes FM+ et FM sont trop importantes pour être compensées. Au moins dans les versions actuelles des normes, mais l'une des joies d'I2C est qu'il y a toujours une nouvelle série de révisions à espérer.