Communication I2C

Le I2C n'est pas adapté pour être transmit sur un câble externe. On peut s'en apercevoir en observant son nom:
I2C - Inter-Integrated Circuit
En fait, ce protocole de communication a été établie pour lier des périphériques présents sur le même circuit.

Dans le cadre de notre projet, il y a des risques qui surviennent avec ce type de transmission. En effet, nous n'avions pas assez songé sur le fait qu'un BUS I2C ait une limitation d'une capacité maximale de 400 pF. Le plancher est de 12 pieds, donc il a de fortes chances que nous ne soyons pas en mesure de transmettre les trames convenablement a un débit satisfaisant.

J'ai fait la recherche de plusieurs solutions pour contrer cette limitation du BUS I2C

Pour éloigner ce problème, nous utilisons un câble plat de téléphone à 6 conducteurs pour la communication. Nous n'avons pas besoin de 6 conducteurs pour communiquer. Cependant, nous pouvons isoler le signal SDA et SCL entre des lignes de GND pour réduire l'effet capacitif que peut produire les lignes SDA et SCL entre elles.

Pour augmenter cette spécification, nous pouvons avoir recours a I2C BUS Extender. Cette méthode permet d'augmenter le courant  des signaux SDA et SCL par un facteur de 10. Bien que cette méthode serait la plus efficace, elle est cependant très couteuse dans notre cas. Nous avons un total de 36 Drivers de LEDs sur 6 BUS I2C en parallèles. Donc avec cette méthode, on se retrouve avec 36 + 6  pièces supplémentaires. À environ 3$ le circuit intégré, cette solution n'est pas envisageable.

Une autre façon serait de réduire le débit. Au départ, l'intention était d'avoir un débit d'environ 700 kbits/sec. Il faudra sans doute réduire ce débit si nous ne rencontrons pas les spécifications du BUS I2C au final.

Nous allons donc, tout simplement, diminuer la fréquence d'horloge des BUS i2C. J'ai lue sur internet qu'avec une fréquence de 100kHz, nous pouvons atteindre une longueur près de 100 pieds (C'est à confirmer).

Pour s'adresser a un Driver on doit nécessairement avoir :

1 start bit
1 octet d'adressage
1 octet pour le registre
1 stop bit
2 acquittements
---------------
20 bits

Pour contrôler une seule tuile on a :

1 octet pour le rouge
1 octet pour le vert
1 octet pour le bleu

3 acquittements

---------------
27 bits

Un Drivers contrôle 4 tuiles, donc nous avons au total :

20 bits + (27 bits * 4) =  128 bits

Nous avons 6 Drivers par BUS I2C


128 bits * 6 Drivers =  768 bits

Nous nous retrouvons au final avec 768 bits a envoyer par BUS I2C.
Avec une fréquence de 100kHz ca prend un temps de :

768 bits * (1/100E3 Hz)  =  7.68 millisecondes

Avec seulement 7.68ms nous pouvons avoir une fréquence de rafraichissement de 130 images par seconde ce qui est largement suffisant pour notre application.

Au final, nous ne devrions pas avoir de problème avec les limitations I2C si nous optons pour une fréquence d'horloge de 100 kHz.