Comprendre les taux de transmission de données sur un fil de cuivre

J'ai fait des recherches sur les différentes façons de connecter des capteurs à un Arduino, et l'i2c semble être une méthode populaire. J'ai lu qu'il n'est fiable qu'à courte distance (quelques mètres au maximum), avec un débit de 400 ou 100 kbps. J'ai du mal à comprendre pourquoi les limites de ce protocole sont si faibles par rapport à d'autres transmissions de données sur cuivre, telles que Gigabit Ethernet. J'ai vu des raisons comme la capacité, la chute de tension et la résistance, mais Ethernet sur cat5 / 6 n'est-il pas soumis à tous ces mêmes problèmes? Fondamentalement, je veux savoir pourquoi l'impulsion d'une certaine tension sur un fil de cuivre ne donne pas de résultats plus cohérents (bande passante, distance) lors de la comparaison de ces différentes méthodologies.

Le théorème de Shannon définit la limite ultime de la bande passante d'information sur un câble. Voici quelques informations supplémentaires à ce sujet: https://www.gaussianwaves.com/2008/04/channel-capacity/

tl; version dr: l'équation de Shannon-Hartley:

• $C = B \; log_2 \left( 1 + \frac{S}{N}\right) \;\;\;\;\;\;\;\;\;\; \rightarrow (1)$

Où est la largeur de bande en Hz, est le rapport signal / bruit.$B$$\frac{S}{N}$

I2C n'est évidemment pas proche de la limite de Shannon pour un câble. Au lieu de cela, il s'agit d'un protocole léger avec une synchronisation intentionnellement lente (100/400 kbit / s) utilisant un bus à collecteur ouvert pour le rendre facile à mettre en œuvre pour un réseau de petits appareils avec des besoins d'E / S et de contrôle modestes. L'opération lente spécifiée par I2C évite la plupart des problèmes d'intégrité du signal.

Il existe des variantes plus rapides d'I2C qui utilisent des débits de 1 Mbit et 3,2 Mbit / s. Ceux-ci nécessitent plus d'attention à la disposition et à la terminaison que l'I2C normal et ont bien sûr un timing plus serré et plus exigeant.

En remontant la chaîne alimentaire dans le sens Shannon, Gbit Ethernet utilise plusieurs techniques pour atteindre son débit:

• Signalisation différentielle
• Plusieurs paires (4)
• Signalisation à plusieurs niveaux, appelée PAM-5
• Préemphasis / Deemphasis
• Égalisation adaptative

Ces techniques nécessitent beaucoup de silicium, y compris un bloc ADC / DAC à signaux mixtes rapide et volumineux pour communiquer avec le câble et un traitement du signal assez lourd pour le gérer. Ajoutez à cela, la pile logicielle beaucoup plus complexe pour le piloter. Cela rend Ethernet un bloc sur puce un peu trop pour un microcontrôleur bas de gamme (dont certains choisissent d'utiliser un PHY externe à la place). Sa maturité le place cependant bien à la portée de plus grands Systems-on-Chip.

De quelle façon nous rapprochons-nous de la limite de Shannon, de toute façon? Plus ici: https://pdfs.semanticscholar.org/482f/5afbf88a06d192f7cb052f543625c4b66290.pdf

La transmission ne se limite pas au câble en cuivre. Avez-vous vu le matériel derrière Ethernet? Probablement pas, car il est extrêmement difficile de trouver des circuits de base pour ce qui se passe réellement, car les tripes sont toujours cachées dans un circuit intégré. Le plus proche que j'ai jamais trouvé est le magnétique requis pour Ethernet, qui n'est apparemment pas optionnel. Ce n'est qu'un aperçu de ce qui se passe physiquement avec le matériel Ethernet.

Pensez-y de cette façon: l'air est un médium. Pourquoi le type d'informations qui peuvent être transmises lorsque les chiens se parlent tellement moins que lorsque les humains se parlent? Pourquoi l'envoi de certaines ondes de pression dans l'air ne donne-t-il pas des résultats plus cohérents dans la communication entre ces deux types d'animaux?

Quelques-uns des facteurs limitants pour I2C (et de nombreux autres protocoles) sont:

1. entraînement à collecteur ouvert
2. pas d'adaptation d'impédance
3. pas de transmission équilibrée
4. pas de vérification d'erreur
5. schéma d'encodage simple
6. niveaux de tension relativement élevés (si votre pas de tension ne doit pas être aussi grand, vous pouvez transmettre plus rapidement car votre dV / dT n'a pas besoin d'être aussi élevé pour des vitesses plus élevées)
7. pas d'isolement
8. tensions unipolaires (Ethernet transmet à +/- 2,5 V, ce qui aide probablement en quelque sorte)
9. La transmission de l'esclave est cadencée par le maître, donc fondamentalement l'horloge doit faire un aller-retour plus rapidement que le signal de données

Tous ces éléments sont bons pour simplifier les choses. Pas si bon pour des débits de données élevés ou une transmission longue distance.

Il y a aussi probablement un autre vaudou dans le matériel que je ne connais pas.

Quelques règles de base simples: le sol n'existe pas. Tous les fils sont des antennes. Tous les fils sont des lignes de transmission. Il y a toujours du bruit.

Si un fil est court par rapport au temps de montée du signal, vous pouvez alors ignorer les asymétries et les réflexions d'impédance de la ligne de transmission (contrairement à Ethernet, qui nécessite des terminaisons complexes et une mise en forme d'impulsion). Si le fil est long, les tensions induites sur le fil et les différentiels de masse sont plus susceptibles de rendre vos niveaux de signal numérique à l'extrémité distante indéterminés ou incorrects. Mais Ethernet utilise une signalisation différentielle à paire torsadée, réduisant considérablement le bruit induit et les problèmes de référence au sol. Le récepteur Ethernet utilise également des entrées analogiques plus sensibles plutôt que des entrées numériques typiques, permettant ainsi une perte de ligne plus importante. Ajoutez à cela le codage Ethernet et la correction d'erreurs pour surmonter les statistiques du bruit, et vous pouvez aller de manière plus fiable et plus rapide et plus loin.

I2C est un bus à drain ouvert , il est activement tiré vers le bas, mais le pull up (au moins pour les variantes normales à 100 kHz, 400 kHz) sont des résistances passives.

À cause de cela, il y a une limite à la vitesse à laquelle la chose peut fonctionner en fonction de la vitesse à laquelle les résistances de pull up peuvent charger la capacité du bus, vous pouvez parfois obtenir un peu plus de vitesse en abaissant les valeurs de pull up, mais cela signifie alors que les nœuds doivent sombrer plus de courant pour obtenir une logique basse .... Ou vous pouvez aller dans l'autre sens, ralentir le bus pour permettre l'utilisation de résistances de pull up de valeur plus élevée pour une dissipation de puissance plus faible (voir par exemple bus PM).

Il est instructif de lancer une lunette et de noter que le front descendant sur I2C est BEAUCOUP plus net que le front montant.

Pour l'utilisation prévue, essentiellement des capteurs de température et de petits dispositifs de configuration dans une seule carte (ou tout au plus un seul châssis), cela se révèle à peu près le compromis entre la complexité de la mise en œuvre, le faible nombre de broches et le matériel simple. L'intention de conception n'était pas «des liaisons de données rapides et à longue distance», et pour tout ce que je trouve que SPI est généralement plus facile à gérer, I2C correspond vraiment très bien à son cas d'utilisation prévu.

Une fois que les distances augmentent, quelque chose d'autre devient un meilleur ajustement, mais sur une carte avec des interfaces de configuration eeprom / température / périphérique modestes, cela fonctionne assez bien (à noter que l'interface de gestion PHY ressemble beaucoup à I2C).

Les différents résultats sont dus au fait que le circuit pilote est différent pour chaque technologie.

100kHz I2C utilise généralement une résistance de pullup pour mettre le signal à un niveau élevé et des pilotes à drain ouvert pour mettre le signal à un niveau bas.

Les résistances de rappel sont généralement de plusieurs kilo-ohms. Plus un câble est long, plus il aura de capacité. Le temps nécessaire à la ligne pour passer de 0 à 1 sera proportionnel à la capacité totale sur la ligne et à la valeur de la résistance de rappel. Quelque part dans la gamme d'environ T = 2 * R * C serait à peu près juste.

Par exemple, si vous aviez un câble de 10 pieds qui avait 20pF par pied de capacité et que vous utilisiez une résistance de rappel de 10K, alors il faudrait T = 2 * 20pF / ft * 10 ft * 10K = 3,6us pour passer de bas à haut.

Dans ce cas, vous ne pouviez évidemment pas avoir un seul bit après un bit zéro de moins de 3,6us de large, donc votre taux de transmission serait limité à 277 kHz.

Dans un vrai système I2C, la spécification I2C impose en outre la configuration et le maintien des temps autour des transitions de données et d'horloge. Ces temps sont soit des centaines de nanosecondes, soit des microsecondes. Le timing a été rendu très lent exprès afin que les appareils puissent être mis en œuvre à moindre coût (quelques centimes) et consomment très peu d'énergie (milliwatts).

Ethernet, d'autre part, peut fonctionner plus rapidement malgré la capacité du câble car il n'utilise pas de résistance de rappel. Il entraîne activement haut ou bas dans le câble. Le pilote est de faible impédance et il peut charger très rapidement toute capacité de ligne. Bien sûr, tout cela a un prix. Ethernet consomme généralement des centaines de mW d'énergie et coûte au moins quelques dollars par port à mettre en œuvre.

Une configuration similaire à I2C pourrait-elle fonctionner plus rapidement, bien sûr, il suffit de changer le pullup 10K à 100 ohms et maintenant votre temps de montée en 10 pieds de câble passe de 3,6us à 36ns. Vous pourriez alors probablement fonctionner à environ 10 MHz sans trop de problèmes (à part le fait que les puces I2C régulières ne peuvent pas parler aussi vite).