Vitesse d'horloge et fiabilité minimales I2C

Y a-t-il une fréquence d'horloge minimale spécifiée par I2C? Je sais que la fréquence d'horloge la plus utilisée est de 100 kHz et il existe un mode "rapide" de 400 kHz pris en charge par certains appareils, et un mode encore plus rapide pris en charge par d'autres appareils (je pense que 1 MHz?). Étant donné que le signal SCK est généré par le maître, je suppose que l'on pourrait fonctionner à une vitesse beaucoup plus lente que n'importe lequel d'entre eux - y a-t-il une limite inférieure dans la pratique? Dans quelle mesure les appareils esclaves se soucient-ils de la fréquence d'horloge (par exemple, est-il courant qu'ils aient de courts délais)? La raison pour laquelle je pose la question est que je me demande si je pourrais éventuellement exécuter I2C sur une plus longue distance (par exemple 20 pieds) pour programmer de manière fiable les EEPROM I2C dans une configuration de testeur de production. Je suppose que cela ne fonctionnera pas de manière fiable sur cette distance aux débits de données standard.

Non, il n'y a pas de fréquence minimale, la fréquence d'horloge minimale est 0 ou DC. Voir les spécifications , page 48.

Mais vous devrez faire attention aux temps de montée et de descente. Ce sont 1000 ns et 300 ns maximum, resp. Et un câble plus long, avec une certaine capacité, influencera les bords, quelle que soit la fréquence.

C'est cette capacité, ainsi que les résistances de traction qui détermineront le temps de montée. Le temps de chute n'est pas un problème car le FET qui tire la ligne vers le bas a une très faible résistance, et la constante de temps de chute sera également très faible. Il nous reste donc le temps de montée. Pour obtenir un temps de montée de 1000 ns sur un câble de 200 pF, vos résistances de pull-up ne doivent pas dépasser 2,2 kΩ. (temps de montée à 90% de la valeur finale.)

Le graphique montre la résistance de traction maximale (en Ω) par rapport à la capacité du câble (en pF) pour obtenir des fronts montants de 1000 ns. Notez que les appareils I2C n'ont pas besoin de descendre plus de 3 mA, donc à 3,3 V, la capacité du bus ne devrait pas être supérieure à environ 395 pF, sinon la résistance de pull-up devrait être inférieure à 1100 Ω, et permettre plus que le 3 mA. Ce sont les lignes pointillées verdâtres. Pour un fonctionnement en 5 V, la capacité autorisée est même de 260 pF, pour une valeur de pull-up de 1667 Ω (lignes pointillées violettes).

J'ai exécuté I2C à environ 100 Hz sans problème. Comme l'a dit @stevenvh, ne vous inquiétez que de la vitesse maximale et de la capacité de la ligne.

Vous devriez être en mesure de résoudre les problèmes de longueur de ligne avec une sélection rigoureuse des pilotes et une adaptation d'impédance.

Une autre option, en supposant que le long terme fait partie de la configuration et non du produit, pourrait être d'utiliser quelque chose qui gère bien la distance comme RS422 (ou pratiquement RS232) pour parler à un microcontrôleur placé dans le connecteur du faisceau de test, qui parlerait alors i2c sur une distance assez courte à la cible.

Ou vous pourriez probablement le faire sans l'intelligence, en utilisant une petite carte qui a ponté un protocole de signalisation différentielle avec des récepteurs de déclenchement Schmidt vers et depuis la signalisation i2c à la cible.

Vos parcours ne sont probablement pas assez longs pour que les temps de propagation du signal (en l'absence de problèmes de stabilisation) nécessitent des fréquences d'horloge particulièrement lentes pour éviter de faire tourner le bus pendant que les anciennes données sont toujours en vol.

Bien sûr, vous voudrez faire une vérification de relecture des données que vous venez de programmer.

À titre de comparaison, les moniteurs VGA IIRC ont une lecture d'ID i2c (ou est-ce du type i2c), qui fonctionne probablement toujours si vous ajoutez une rallonge de 6 pieds au câble de 3 ou 4 pieds d'origine.