La fréquence mixte I2C est-elle possible?

Supposons que nous ayons un bus 400 kHz I ² C. Il y a un maître et un tas de dispositifs esclaves. Nous aimerions introduire un autre appareil esclave, mais malheureusement, il ne va qu'à 100 kHz.

De toute évidence, les choix de conception solides sont les suivants:

• il suffit d'exécuter ce bus à 100 kHz
• utiliser des bus séparés pour les périphériques 400 kHz et 100 kHz

Mais la question n'est qu'un piratage: que se passe-t-il si nous utilisons un bus, et adressons les périphériques à 400 kHz à 400 kHz, et basculons le bus à 100 kHz lorsque nous parlons à l'esclave à 100 kHz?

Ou l'esclave plus lent pourrait-il mal se comporter en réponse au hachage de 400 kHz qu'il voit sur les lignes I ² C parce qu'il pense à tort qu'il est adressé?

Pouvons-nous compter sur des appareils à 100 kHz pour être en mesure de traiter suffisamment bien le signal 400 kHz I ² C pour ignorer de manière fiable les messages adressés à d'autres esclaves?

Comme vous le suggérez, cela n'est pas une bonne pratique d'ingénierie. Alors que certains périphériques ignoreraient le plus le trafic qu'ils ne sont pas en mesure de recevoir (sous-échantillon), d'autres périphériques peuvent encombrer le bus avec des trames erronées.

Ainsi, la réponse que vous recherchez dépend de vos spécificités de votre application telles que:

• longueur de vos connexions I2C
• valeur des résistances de traction
• compatibilité des appareils

Bien sûr, il est difficile de prédire ce qui arriverait à un appareil fonctionnant en dehors de ses spécifications quelques années plus tard.

Une autre option consiste à exécuter une ligne d'arrêt pour ralentir les périphériques ou passer la ligne d'horloge (à condition qu'ils ne puissent pas générer de signal d'horloge) via une porte ET.

Une autre option, si vous n'avez pas de bus I2C supplémentaire sortant de votre maître, est d'utiliser un commutateur I2C, tel que le PCA9543A / 43B . Placez les esclaves 400 kHz sur une branche et les esclaves 100 kHz sur l'autre et changez-les si nécessaire.

Il n'y a aucune garantie que le périphérique à 100 kHz ne se comportera pas mal lorsqu'il est exposé à un trafic à 400 kHz - tout, des NACK aux blocages de bus, est possible.

Vous devez soit exécuter l'intégralité du bus à 100 kHz, soit disposer d'un bus séparé à faible vitesse pour votre périphérique lent.

Autres options. Au lieu d'avoir deux bus, vous pouvez simplement utiliser une ligne supplémentaire (plus facile avec un logiciel / bitbanged I ² C). Une ligne d'horloge distincte ou une ligne de données distincte. Ou utilisez un tampon I ² C ou un commutateur I ² C pour placer cette seule puce de 100 MHz sur son propre segment, sans avoir à changer quoi que ce soit d'autre.

Ou testez-le simplement sur un seul bus. Il est tout à fait possible que la puce à 100 kHz affecte la ligne. Il pourrait lire tous les 4 bits et finir par penser qu'il a été résolu. Mais il devrait voir une condition de démarrage valide, puis lire tous les 4 bits sur les 32 bits suivants en tant qu'adresse exacte, puis il devrait soit essayer de lire les deux octets suivants en tant qu'informations valides pour écrire dans ses registres. ou essayez d'extraire les données. Je ne pense pas que ce soit trop probable une situation. Le mieux est de le câbler simplement dans un circuit de test et de le vérifier.

Deux choses à noter, s'il s'agit d'un circuit unique ou si vous n'en faites que quelques-uns, il est assez facile de le risquer ou de le changer. Si c'est un article produit en série, vous voudrez peut-être simplement avoir le deuxième bus. L'autre, c'est que vous devez considérer que la puce 100 kHz a été simplement produite selon les spécifications I ² C d'origine, et pourrait très bien prendre en charge des vitesses d'horloge plus élevées. Il n'a tout simplement pas été testé selon les spécifications de la vitesse supérieure de 400 kHz.

La conception du bus I2C est telle que -

1. lorsqu'un front descendant se produit sur SCL, cela peut amener un périphérique esclave à affirmer immédiatement SDA, sans retard minimum particulier;
2. l'ordre relatif des fronts montant et descendant est d'une importance cruciale.

En raison de la différence de force du pilote et de capacité de ligne, il serait théoriquement possible qu'un appareil réponde à un front descendant quelque peu lent sur SCL en pilotant le SDA si rapidement qu'un autre appareil verrait le SDA tomber en premier.

Il aurait pu être possible de définir plusieurs seuils logiques sur SCL, et de spécifier que pour qu'un front descendant sur SCL soit considéré comme venant après un front sur SDA, il doit toujours être supérieur à 2/3 VDD lorsque le front sur SDA est détecté, mais un appareil peut ne pas affirmer SDA en réponse à un front descendant sur SCL jusqu'à ce qu'il soit tombé en dessous de 1/3 VDD, mais la spécification n'est pas écrite en ces termes.

Au lieu de cela, les dispositifs qui voient des fronts descendants presque simultanés sur SDA et SCL considéreront généralement que le bord sur SCL s'est produit en premier, à moins qu'il ne soit sensiblement précédé par le bord sur SDA. Certaines implémentations I2C gèrent cela en synchronisant SCL et SDA avec une horloge externe et en exigeant qu'un front descendant de SDA soit observé deux périodes avant celui de SCL afin d'être considéré comme étant arrivé en premier. Si la vitesse des opérations sur SCL et SDA est trop rapide par rapport à l'horloge de synchronisation, les appareils peuvent percevoir des séquences arbitraires de signaux hauts et bas sur SCL et SDA; si l'une de ces séquences semble s'adresser au périphérique lent, elle peut réagir en conséquence, annulant toute autre communication en cours.

Il n'y a aucune raison particulière pour que les périphériques sur un bus I2C doivent s'appuyer sur la synchronisation avec une horloge système (pouvoir détecter deux seuils discrets sur SCL serait mieux), mais le fait est que certains périphériques fonctionnent en fait de cette façon. Notez que même si un périphérique limité à des vitesses lentes voulait coexister en interne avec un bus rapide, il devrait probablement utiliser au moins une horloge qui s'étire à chaque fois que quelque chose se passait, ce qui pourrait l'intéresser.

Cela entraînerait certaines communications à se produire plus lentement qu'elles ne le feraient autrement, mais la dégradation de la vitesse ne serait probablement pas aussi mauvaise que celle requise avec la conception synchronisée par l'horloge (la quantité réelle par laquelle le périphérique lent étire les horloges ne le serait probablement pas être aussi mauvais que la quantité de ralentissement de l'horloge pour éviter les pires cas de défaillance dans les unités d'horloge synchronisées).