Existe-t-il des instructions de brochage I2C définitives? Ne cherche pas un «STANDARD»

16

EDIT: Cela a été répété plusieurs fois, donc pour le mettre en haut: Oui, il est bien connu qu'il n'y a pas de "standard" pour les connecteurs inter-appareils I2C, mais cette communauté peut sûrement formuler une liste de points "d'orientation" pour faire ces interconnexions, basées sur le comportement du signal, la minimisation du bruit et l'atténuation des risques dus à de mauvaises connexions.


NXP a défini la norme I2C sans spécifier de brochage pour les connecteurs I2C, si je comprends bien. Le seul guide de NXP semble être une mention de placer un Ground et / ou Vss entre SDA et SCL si Vss / Gnd sont transportés à travers l'interconnexion.

Les achats de divers modules I2C m'ont laissé avec une variété de brochages I2C, et un peu de tâche de garder une trace des diverses petites cales de commutation de câble ruban que j'ai dû faire pour elles.

par exemple

  • Module mono OLED: SCL, SDA, GND, 5V (évidemment pas idéal, car l'horloge et les données sont côte à côte.
  • Bouclier de capteur pour Arduino: SDA, SCL, GND, 5V (encore une fois pas idéal, plus SCL / SDA commutés)
  • Module LCD couleur: SCL, GND, 5V, SDA (Yay!)
  • Répéteur I2C sans nom: SCL, 5V, GND, SDA (aïe, ils ont commuté les broches d'alimentation! Laissons presque la magie s'éteindre.)

Ma question est donc la suivante :
existe-t-il une directive définitive / faisant autorité pour la séquence de brochage du connecteur 4 broches I2C à utiliser, où Vss et GND doivent être transportés de l'hôte au périphérique?

À défaut, existe-t-il un répertoire, aussi incomplet soit-il, des modules / appareils I2C listant le brochage adopté par chacun?

Clarification: recherche de directives telles que "rapprocher Vss de SCL parce que ..." plutôt qu'une norme définie qui n'existe clairement pas.

Anindo Ghosh
la source
3
D'où la question.
Anindo Ghosh
1
Par votre propre question, il est clair de voir qu'il n'y a pas de norme ... et s'il y en avait, évidemment, les gens ne la suivent pas. Vous êtes coincé à faire des cales. : P
Toby Lawrence
1
@AnindoGhosh heh. Si c'était moi, j'abandonnerais probablement les modules pré-achetés et ferais rouler mes propres cartes de dérivation avec un brochage standardisé à l'aide d'un en-tête polarisé. Probablement quelque chose comme 6 broches, avec GND à côté de SDA, SCL et 5V ... puis en utilisant un câble avec trois paires torsadées pour garder la masse près de chaque signal pour aider à réduire le bruit et à rejeter les interférences.
Toby Lawrence
3
Il semble que certaines personnes soient offensées que I2C soit une option de connexion par défaut populaire pour de nombreux modules vendus aux utilisateurs d'Arduino. Même s'il n'a jamais été conçu pour un connecteur de carte externe, il est ici et il se vend et demander des conseils sur la meilleure façon de fabriquer le connecteur pour de nouveaux appareils est utile pour nous, pas les experts, et possible que les experts n'aiment pas cela.
ExcitingProjects
1
@ExcitingProjects Non, ils ont raison sur ce qu'ils disent, I2C n'était pas destiné à cela, et fait clairement face à plusieurs défis dans la connexion inter-appareils. Il se trouve que les concepteurs de modules ont choisi d'utiliser I2C. Je serais aussi "offensé" si j'avais le choix.
Anindo Ghosh

Réponses:

16

J'ai récemment roulé le mien en ce qui concerne les connecteurs I2C. Le connecteur lui-même n'est pas très important, en ce moment j'utilise juste un en-tête de 100mil (généralement une femelle à bord, donc ce n'est pas si pokey lorsqu'il n'est pas connecté), mais n'importe quel connecteur à 4 broches fera l'affaire. De plus, j'utilise le P82B715de TI comme un prolongateur de bus I2C. Cela surmonte les problèmes de capacité associés à l'exécution de longues gouttes I2C, ce qui, comme certains l'ont dit, n'était pas destiné à l'origine à l'I2C. J'ai essayé de nombreuses combinaisons différentes, comme dans les exemples que vous avez donnés et je n'ai remarqué aucune différence de performance. Je crois que c'est parce que I2C est relativement lent, l'interférence entre SDA et SCL n'est pas vraiment un problème. Fondamentalement, le temps de montée des tensions (lorsque des interférences se produiront) sur le bus est beaucoup plus petit qu'une longueur de bit. Donc, ce n'est peut-être pas ce que vous voulez entendre, mais cela offre plus d'options. Personnellement, je suis allé avec [VCC, SDA, GND, SCL] pour être facilement routé vers / depuis cette puce et également être immunisé contre un mélange VCC / GND lorsqu'il est branché à l'envers.

Samuel
la source
2
+1 + Accepter. Merci, probablement la réponse la plus pratique à ce jour, "I2C interdevice existe, voici comment je l'utilise et pourquoi". L'évitement de confusion VCC / GND est utile. Bon point pour éviter les en-têtes de broches pokey à bord, j'ai arraché quelques broches de certains modules de capteur par accident.
Anindo Ghosh
Ce n'est que la réponse qui est vraiment utile et si j'ai assez de réputation, je donnerais un bonus à @Samuel pour cela et je préfère cette question car j'ai beaucoup de modules I2C et je construirai des modules I2C un jour en suivant ces guides.
ExcitingProjects
11

Lorsqu'il a été créé pour la première fois, le bus I2C (circuit inter-intégré) était uniquement destiné à connecter des puces sur un seul ensemble PCB. Il n'a jamais été conçu pour être utilisé sur des câbles pour connecter plusieurs cartes ensemble, et par conséquent, aucun connecteur à cet effet n'a été défini.

Les seules interfaces externes basées sur I2C "standard" que je connaisse sont le bus ACCESS.bus de courte durée pour connecter les périphériques d'interface utilisateur aux ordinateurs et le canal de données d'affichage VESA utilisé pour récupérer les informations du moniteur via les connecteurs VGA, DVI et HDMI.

Dave Tweed
la source
Je comprends que l'objectif d'origine était différent, mais comme I2C est utilisé pour de nombreux modules connectés par câble, j'espère que quelqu'un a commencé une base de données collaborative pour documenter les brochages utilisés par divers produits, en particulier les nombreux produits destinés à les marchés Arduino et autres cartes microcontrôleurs.
Anindo Ghosh
4

Pas de brochage standard, pas de connecteur standard. La norme I2C ne se prête pas vraiment à ce genre de chose. Il est spécifié au niveau du bus, pas au niveau de l'appareil. Par exemple, lorsque vous souhaitez brancher un périphérique I2C, savez-vous selon la norme si les pullups sont sur l'hôte ou sur le périphérique ?? Non. Beaucoup d'autres choses que vous ne savez pas non plus, comme la capacité de vos câbles, ce que Vcc doit être ...

En fait, il existe même des périphériques I2C qui ont besoin de lignes supplémentaires pour les interruptions et autres anciennes E / S numériques. Comment pouvez-vous les ajouter à la norme, si vous ne pouvez pas vous mettre d'accord sur le nombre de broches dont vous avez besoin.

En bout de ligne, si vous recherchez la portabilité et la stabilité de vos interconnexions, I2C et SPI ne sont pas là où vous devez chercher.

Scott Seidman
la source
3
Que se passe-t-il si l'on cherche une directive pour fabriquer son propre appareil, qui fonctionnerait avec (et comme) tous ces autres modules pour le 'duino? Il y a un marché là-bas, je ne vois pas l'intérêt de l'ignorer. Soit dit en passant, des tractions sont requises sur l'hôte et facultatives sur l'appareil, conformément aux spécifications.
Anindo Ghosh
5
La "belle" chose au sujet des normes est qu'il y a tellement de choix! Vous choisissez une norme avec un connecteur bien défini, comme MIDI, USB, RS232 (à part ces stupides choses de modem nul), et créez un traducteur dans votre propre appareil. L'autre option consiste à former un groupe de travail sur les normes par le biais d'une organisation de normalisation, comme IEEE. Les pullups "facultatifs" sur le périphérique ont un impact sur le comportement de l'ensemble du bus, ce qui fait exactement mon point. Le MIDI isole optiquement tous les appareils par standard, donc les appareils conformes ne causent pas ces problèmes
Scott Seidman
1
+1 pour le point drôle mais tellement vrai sur les normes! :-)
Anindo Ghosh
4

Beaucoup de gens utilisent une sorte de connecteur pour transporter les signaux I²C et l'alimentation entre deux PCB. Par exemple,

Quelques conseils généraux pour transporter des signaux I²C sur de plus longues distances:

ps: Je vois que Wikipedia: L'interconnexion du circuit I²C a lié à cette question.

davidcary
la source
3

Bien qu'il n'y ait pas de brochage ou de connecteur I²C standard, il existe un certain nombre d'emplacements I²C qui sont standardisés. Certains qui me viennent à l'esprit sont les modules de mémoire (DIMM, SO-DIMM), les connecteurs vidéo ( DDC en DVI , VGA ) et SM-Bus (oui, leur page Web ressemble à quelque chose qu'un enfant a fait au milieu des années 90). En particulier, le connecteur du bus SM est claveté et contient uniquement I²C et l'alimentation, mais SM-Bus impose des restrictions supplémentaires, donc techniquement, tous les périphériques I²C ne doivent pas être connectés à un SM-Bus réel. Quelques prises supplémentaires sont également présentes, telles que les capteurs Lego NXT.

Yann Vernier
la source
C'est un fait qu'il n'y a pas de norme ... Ce que j'espère, c'est une collection canonique de directives, que les concepteurs d'appareils pourraient ensuite suivre. SMBus, par exemple, a la ligne + 5V à l'extérieur, tandis que NXP recommande que + V et GND soient entre les traces de signal. Quelle voie est la meilleure et pourquoi?
Anindo Ghosh
2

Il n'y a pas de norme.

Il n'y a pas de pratique courante.

En ce qui concerne les questions pour vous décider quoi faire:

  1. Gardez les signaux sur une seule planche comme s'ils étaient destinés à être en premier lieu. Les lignes IIC ont une impédance assez élevée, sont asymétriques et sont donc sensibles au bruit et ne terminent pas bien les lignes de transmission. IIC n'est tout simplement pas destiné à sortir du circuit.

  2. Si vous allez de toute façon descendre à bord, gardez le bus court. Quelques pouces est probablement OK. Un mètre ou plus demande vraiment des ennuis.

  3. Éloignez les lignes de bord des sources de bruit. Ne les enroulez pas autour d'un moteur, par exemple, ou n'essayez même pas de vous en approcher.

  4. Utilisez un connecteur qui ne peut pas être raccordé vers l'arrière. Si quelqu'un peut le brancher à l'envers, quelqu'un le fera.

  5. Le câble ruban est probablement le plus facile à utiliser. Vous avez besoin d'au moins trois fils, SCL, SDA et terre. Ajouter de la puissance est probablement une bonne idée. Dans tous les cas, assurez-vous que le fil de terre est entre SCL et SDA pour éviter la diaphonie. Le câble d'alimentation ne doit pas être bruyant, alors collez-le d'un côté, peu importe lequel.

  6. Après avoir joué avec les connecteurs et chassé les problèmes potentiels, réalisez que le point 1 était en fait le seul que vous deviez connaître.

Olin Lathrop
la source
Nous devons donc mettre la tête dans le sable pour toutes les centaines de choses I2C que les gens ont fabriquées et vendues pour les débutants de l'arduino et d'autres microcontrôleurs?
ExcitingProjects
1

Comme d'habitude pour tout article demandant pourquoi quelque chose est [nt] standardisé:
Fortunately, the charging one has been solved now that we've all standardized on mini-USB. [Or is it micro-USB? Shit.
De XKCD

Connor Wolf
la source
Peut-être que si vous aviez lu la question plus attentivement ou les nombreux fils de commentaires, vous auriez peut-être remarqué que ce n'est pas une norme recherchée mais un ensemble de sagesse sous la forme de directives canoniques.
Anindo Ghosh
1
@AnindoGhosh - Je ne vois pas comment cela fait une différence. Si vous remplacez la norme par la directive dans la bande dessinée ci-dessus, elle est également valable. Toute situation où il y a plusieurs façons de faire quelque chose se traduit généralement par de nombreuses personnes qui font ladite chose de nombreuses façons. Même si ce n'est pas une "norme" formelle.
Connor Wolf