Comment résoudre les conflits d'adresses I2C?

Je souhaite connecter plusieurs périphériques esclaves I2C à un microcontrôleur sur le même jeu de broches, mais les périphériques I2C partagent la même adresse. Les adresses sont fixes dans le matériel.

Est-il possible de connecter plusieurs appareils avec la même adresse?

Peut-être une sorte de module de traduction d'adresses I2C avec chaque périphérique avec une adresse configurable afin que je puisse assigner mes propres adresses à chacun.

Cela n’existe pas dans I2C. Normalement, les périphériques esclaves auront des broches externes pouvant être réglées sur 0 ou 1 pour faire basculer quelques bits d’adresse afin d’éviter ce problème. Alternativement, j'ai traité avec quelques fabricants qui ont 4 ou 5 références pour une pièce, la seule différence étant son adresse I2C.

La plupart des périphériques ont un matériel spécifique qui gère la communication I2C, c’est-à-dire que l’accusé de réception ACK est dans le matériel, vous ne pouvez donc pas le pirater.

En ce qui concerne le module de traduction, vous pouvez acheter des PIC à 0,50 USD avec 2 bus I2C et écrire un code rapide pour les faire agir en tant que traducteurs d'adresses, je suppose.

Je viens de rencontrer ce problème avec plusieurs périphériques I2C avec une adresse fixe. Notre solution consistait à utiliser des lignes d’entrée / sortie sur le microcontrôleur pour forcer les lignes SDA à placer le plus haut possible sur les périphériques que nous ne voulions pas adresser, tandis que la ligne d’entrée / sortie pour le périphérique que nous ciblons est définie en entrée ). Cela signifie que seul le périphérique ciblé correspond à son adresse I2C et que les autres ignorent les données ultérieures.

Les résistances de la ligne SDA pour les périphériques inactifs finissent par agir comme des tractions pour le bus. La valeur exacte dépend donc du nombre de périphériques dont vous disposez et de la tension dont vous avez besoin pour votre bus. Donc, si vous choisissez des résistances de 10K, 3 appareils inactifs donnent un pullup de 3K3.

Les diodes Schottky garantissent que le périphérique peut toujours tirer la ligne SDA assez bas lors de la transmission de données à l'hôte.

Si aucun des périphériques I2C n’utilise l’étirement de l’horloge et si vous battez le maître I2C, un simple hack consiste à faire en sorte que certains périphériques échangent les broches d’horloge et de données. Pendant la transmission d'un octet, le dispositif dont l'horloge et les broches de données sont échangées verra chaque bit "0" comme un non-événement (les données montent et descendent sans horloge) et verra chaque bit "1" comme un arrêt I2C. et start (l’horloge monte tant que les données sont basses, suivie de données montantes et descendantes, suivie d’une horloge décroissante) Les conditions d’arrêt et de démarrage intentionnels pour un périphérique peuvent être considérées comme des bits de données par l’autre, mais à moins qu’un périphérique ne présente un nombre excessif de conditions de démarrage et d’arrêt entre "1" bits, il est peu probable qu’un périphérique "accidentellement"

J'envisagerais d'utiliser des commutateurs de bus pour multiplexer le bus I2C parmi les périphériques avec des adresses en conflit. Les commutateurs de bus ont une très faible capacité et résistance, et contrairement aux tampons / pilotes, ce sont de véritables commutateurs qui connectent ou déconnectent deux nœuds de circuit.

Les commutateurs de bus ont généralement une caractéristique étrange, cela n'a pas d'importance pour I2C car il utilise des dispositifs à drain ouvert: un commutateur de bus a une faible résistance active lorsqu'il lie des tensions proches de 0 (Vss), mais la résistance augmente considérablement à l'approche des tensions l'alimentation Vdd. (C'est parce qu'ils sont essentiellement des MOSFET avec des tensions de grille au niveau de l'alimentation lorsqu'ils s'allument, de sorte que les tensions commutées s'approchent de Vdd, les Vgs disponibles sont beaucoup plus faibles)

Je voulais comparer deux capteurs de lumière de couleur TCS3414 (les packages FN et CS, qui ont des filtres différents). L'adresse I2C est câblée. Après avoir examiné le fonctionnement d’I2C en termes de lignes SCL (horloge) et SDA (données), il a semblé qu’éteindre la ligne SDA empêcherait la puce d’obtenir un bit de début ou d’arrêt et de la laisser ainsi en veille. Nous avons donc utilisé un commutateur analogique CMOS (4066B) pour allumer ou éteindre la ligne SDA vers chaque périphérique. Cela a très bien fonctionné pour basculer entre les deux appareils. Je sais que c'est un bidouillage, et le PCA9548 serait beaucoup mieux, mais je n'en avais pas.

Il existe maintenant une réponse: Linear Tech dispose de la série de traducteurs d'adresses LTC4316 / 17/18. Ils sont relativement nouveaux et la disponibilité est incertaine.

Plusieurs fabricants proposent des circuits intégrés multiplex et commutateur bus I2C.

Un multiplex peut activer un canal à la fois; un commutateur peut en activer plusieurs en parallèle.

Vérifiez par exemple les offres de NXP , TI et Maxim .

Pour l'expérimentation, Adafruit a une carte TCA9548a .

Si vous avez 8 puces cibles avec des adresses identiques, sélectionnez un MUX 8-à-un. Avant d’accéder aux puces cibles, configurez le MUX pour activer le bus I2C approprié.

Avantages

• Ne nécessite aucune programmation (approche vs microcontrôleur)
• Peut prendre en charge les fonctionnalités et les vitesses I2C dont vous avez besoin (par rapport aux multiplexeurs de bus analogiques / numériques classiques). Par exemple, un multiplex standard (non I2C) ne transmettra pas les adresses d’appel général à tous ses canaux.

Utilisez une simple puce de démultiplexage (par exemple, 74HC139) et connectez la broche I2C CLK à l’entrée (la broche I2C CLK étant sortie uniquement). Utilisez les broches GPIO pour contrôler la sortie souhaitée. Ensuite, les broches de données I2C peuvent être partagées entre tous les esclaves.