Cette communication est-elle I²C?

9

J'ai besoin de décoder la communication entre deux appareils, mais je n'ai aucune information sur ces appareils. Tout ce que je sais, c'est que quatre fils sont nécessaires (GND, VCC et deux fils de communication). Je soupçonne qu'il s'agit d'une communication I²C.

J'essaie de le décoder avec l'outil de décodage de l'oscilloscope, mais je n'en suis pas sûr. Je ne peux pas identifier correctement les éléments de la communication I²C lorsque je vérifie visuellement les formes d'onde.

En regardant les formes d'onde, j'ai fait les hypothèses suivantes, et peut-être que quelqu'un peut aider. Ce sont mes hypothèses:

Tout porte à croire que l'horloge est le signal bleu et les données le signal rouge.
L'horloge semble être inversée car son état de veille n'est pas au niveau haut.
Je ne sais pas si le signal de données est également inversé, mais il semble que ce soit le cas.

Mes hypothèses sont-elles correctes?

Dans la dernière figure, la figure avec le chiffre 5 indiqué dans un cercle, et il y a une partie du signal. Je ne peux pas identifier les bits de début, d'acquittement et d'arrêt. Quelqu'un peut-il identifier ces éléments en regardant simplement la figure?

[Modifié] Certaines personnes m'ont posé des questions sur les appareils qui sont dans la communication. La communication se fait entre une clé de voiture et un outil que je n'ai pas le droit de dire, mais j'essaie de faire une rétro-ingénierie dessus.

i2c communication

— Daniel
source

1

Vous avez la condition de démarrage sur le bord rouge (SDA) le plus à gauche. Il devient bas tandis que le bleu inversé (–SCL) est maintenu bas. Après cela, les changements au rouge (SDA) ne semblent se produire que lorsque le bleu inversé (–SCL) est élevé. C'est une conversation I²C valide.

— Janka

2

@Janka, c'est seulement une conversation I2C valide si vous supposez que SCL est inversé. Il n'y a aucune raison de supposer cela.

— Annie

2

@Janka, l'OP a indiqué cela comme une hypothèse. Cette hypothèse est basée sur l'hypothèse qu'il s'agit de I2C. Il y a plusieurs raisons de croire que ce n'est pas I2C - l'une d'entre elles étant que l'horloge est au ralenti basse.

— Annie

5

@Daniel, pourriez-vous nous dire quels sont les deux appareils?

— Annie

2

Peut-être qu'au lieu de vous soucier de "ce que c'est", vous devriez penser à "ce qu'il dit". Déterminez les bords que vous devez échantillonner. Obtenez un analyseur logique, probablement du type USB en streaming, et commencez à écrire un décodeur qui capture l'ampleur de la variabilité. Commencez ensuite à rechercher des modèles dans les données.

— Chris Stratton

6

Je suppose que c'est le protocole "I2C" de la société. Il y en avait certains à l'époque où utiliser I2C signifiait devoir donner de l'argent à Philips.

Il semble avoir un ACK (l'impulsion courte sur la ligne de données avant l'étirement de l'horloge ressemble beaucoup à la ligne de données passant du maître à l'esclave).

Curieusement, il semble transmettre 7 bits à la fois.

— Annie
source

1

S'il s'agit d'une version propriétaire du protocole, il pourrait tout aussi bien utiliser une communication à 7 bits ou moins

— Maple

6

@Maple Ouais. Je peux imaginer un ingénieur disant: "Comment pouvons-nous faire cela comme I2C mais juste assez différent pour que nous n'ayons pas à payer de redevances? Inversez l'horloge et envoyez 7 bits à la fois." Mais je ne peux que deviner.

— Annie

11

Étant donné qu'il n'y a que 8 horloges par octet (I2C nécessite une 9ème horloge pour le bit ACK / NAK) et que l'état inactif de l'horloge semble être faible, je dirais qu'il s'agit plus probablement d'une interface SPI (ou de type SPI).

Cependant, je ne suis pas sûr de la largeur d'horloge supplémentaire sur le premier bit de chaque octet.

— Dave Tweed
source

1

D'un autre côté, cette impulsion étroite à la fin de la séquence d'horloge ressemble beaucoup à NACK. De plus, ce qui ressemble à un ralenti bas pourrait être l'étirement de l'horloge, qui n'est plus autorisé par les spécifications mais pourrait être utilisé par les anciens esclaves. L'état initial sur les photos (1) et (2) est en fait élevé

— Maple

1

@Maple: Je vois votre impulsion de données étroite, mais je ne vois toujours pas la 9ème impulsion d'horloge. Le modèle de données est parfaitement cohérent avec certaines configurations SPI de phase d'horloge et de polarité d'horloge.

— Dave Tweed

1

C'est vrai, je suis en fait d'accord avec vous sur l'horloge. Ce qui est étrange pour moi, c'est un comportement inactif SDI / SDO incohérent (quel qu'il soit) à la fin de (1)

— Maple

1

@Maple I2C ne libérerait-il pas les lignes au ralenti?

— Selvek

1

@Selvek Oui, et c'est exactement ce que je vois sur l'image (1) et au début de l'image (2). Le reste, cependant, est plus cohérent avec SPI, comme l'a souligné Dave. Eh bien, à part la première horloge surprenante qui ressemble au bit de départ. Hmm ... bit de départ ... cela pourrait-il être ...

— Maple

3

Je vais jeter mon chapeau dans le ring ...

S'il s'agit d'anciens appareils, vous pourriez envisager une variante RS-232 synchrone "strict minimum" à 7 bits:

Cette impulsion plus longue au début de chaque trame pourrait être un bit de départ, et
Le plateau du signal d'horloge au tout début pourrait être ramené à 0 avant de passer à une "marque" négative. (Vous n'avez pas fourni de tension sur les captures d'écran, donc je suppose ici).

— Érable
source

1

Oooh, c'est nouveau pour moi. A-t-il un accusé de réception? (Impossible d'en trouver un dans ma très brève recherche Google). Sinon, autre chose qui expliquerait la courte impulsion sur la ligne de données après le 8e clk?

— Annie

1

Pas que je sache de. Et dans tous les cas, s'il s'agit bien d'une série à l'ancienne, toute communication dans une autre direction nécessiterait des fils séparés. Cette impulsion est trop courte pour être significative. Très probablement, le pilote se réinitialise avant la prochaine image. Tout cela est devinable, comme vous l'avez dit vous-même. Sauf si OP fournit plus de détails sur les appareils, c'est tout ce que nous pouvons faire.

— Maple

@Maple, la communication se fait entre une clé de voiture et un outil que je n'ai pas le droit de dire, mais j'essaie de faire du reverse engineering dessus.

— Daniel

RS232 est une norme pour les niveaux électriques, pas pour le codage des mots de données

— Chris Stratton

@ChrisStratton Où avez-vous trouvé quelque chose sur l'encodage dans ma réponse? Tout ce que je dis, c'est que si les niveaux de tension correspondent à RS232 et que les signaux ressemblent à une série synchrone, alors ce n'est probablement pas I2C

— Maple

-1

Selon mon expérience avec I2C, je peux utiliser un appareil de plusieurs mètres pour vérifier l'horloge en réglant l'appareil pour mesurer la fréquence (en hertz), donc s'il lit une valeur stable comme 2k, c'est l'horloge I2C.

— user10433585
source

3

Non, ce n'est pas du tout une conclusion valable. Beaucoup de choses qui ne sont pas I2C ont des horloges stables. En fait, I2C n'a pas d'horloge régulière, mais plutôt brusque. Si votre compteur compte sur une période de temps, il va en fait faire la moyenne de la synchronisation active avec des interludes inactifs - vous devez mesurer l'inverse de la largeur d'une impulsion, idéalement sur une portée où vous pouvez être sûr que vous êtes mesurer réellement ce qui est prévu. En revanche, certains autres systèmes comme I2S ont tendance à avoir des horloges en fonctionnement continu. Mais la fréquence d'horloge ne peut exclure que quelque chose, pas dedans.

— Chris Stratton