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

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.

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.

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.

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.

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

• le connecteur UEXT à 10 broches est alimenté en I²C et +3,3 V (et SPI);
• le connecteur iPack à 10 broches est alimenté en I²C et +5 V;
• le connecteur Molex SEMCONN ACCESS.bus à 4 broches est alimenté en I²C et +5 V;
• quelques personnes utilisent les connecteurs 8p8c et le câble CAT5 normalement utilisés pour la couche physique Ethernet pour transporter des signaux I²C codés différentiels et une alimentation +12 V ( Envoi fiable d'I2C sur des câbles Cat5 ) ou des signaux I²C asymétriques amplifiés et une puissance +12 V ( le "Pond Electronics Bus" );
• chaque connecteur HDMI et la plupart des connecteurs et câbles DVI et VGA transportent des données DDC2 sur I²C;
• quelques autres connecteurs qui transportent I²C sont répertoriés dans "Connecteurs et câbles de bus I2C"

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

• "Note d'application NXP AN11075: pilotage de signaux de bus I2C sur des câbles à paire torsadée avec PCA9605"
• Joshua Vasquez. "Prendre le saut: une introduction à l'I2C sur de longs câbles"
• "Connecteurs et câbles de bus I2C" répertorie de nombreux conseils généraux pour éviter la diaphonie (avec une trace de portée montrant le couplage du signal SDA sur SCL et causant des problèmes), la réduction du bruit externe, etc.

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

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.

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.

Comme d'habitude pour tout article demandant pourquoi quelque chose est [nt] standardisé:

De XKCD