HDMI et I

Je regardais le brochage HDMI et je me suis dit: pourquoi utiliseraient-ils I 2 C pour la communication écran-hôte? Ma question ici concerne les paramètres de conception qui ont conduit à ce choix.$^2$

HDMI est une norme assez récente alors que I 2 C existe depuis 1982 . I 2 C est destiné à la communication embarquée, puce à puce, de plus la norme autorise plusieurs appareils connectés au même bus. Un câble HDMI peut mesurer environ 15 m de long , de sorte que le signal I 2 C devrait probablement utiliser des tensions supérieures à la normale pour éviter trop de bruit, ce qui ajoute la nécessité de tranceivers des deux côtés. À propos du multi-périphérique, je ne peux pas vraiment penser à la façon dont vous connecter plus d'un moniteur à un seul port HDMI, sauf si vous êtes très, très non standard.$^2$$^2$$^2$

Je ne suis vraiment pas un expert en protocoles de communication mais je pense que RS485, CAN ou un autre protocole point à point, full duplex, SNR supérieur aurait été mieux.

Alors pourquoi choisiraient-ils I 2$^2$ C?

note: Je sais que cela pourrait être marqué comme "basé sur l'opinion", j'espère que quelqu'un autour peut penser à / connaît des raisons objectives.

L'histoire DCC en HDMI passe par DVI jusqu'à VGA. Il est implémenté de manière à ce que vous puissiez simplement brancher une puce de mémoire eeprom I²C standard sur le côté du moniteur, qui est presque aussi bon marché que la saleté (AT24C01 et compatible).

Le signal I2C devrait probablement utiliser des tensions supérieures à la normale pour éviter trop de bruit

Nan. Les +5 Volts vous racontent une histoire différente. Ce qu'ils pourraient faire, c'est une fréquence d'horloge inférieure sur le bus. Les câbles HDMI sont également bien blindés.

Alors pourquoi choisiraient-ils I2C?

Il était là en DVI (auquel HDMI est compatible) et fonctionne et est bon marché.

I2C est très peu coûteux et simple à mettre en œuvre pour plusieurs raisons. Il est souvent utilisé lorsque seulement quelques octets doivent être transférés. C'est également une interface très structurée, avec un protocole défini pour qui devrait parler à un moment donné. I2C, en raison de son âge, est également bien pris en charge par les fabricants I2C (d'où son coût et sa simplicité de mise en œuvre). En raison du faible débit de données, le SNR n'est vraiment pas un problème et 3,3 V est une tension de bus typique et il peut être fortement filtré passe-bas, si nécessaire.

Je pense qu'il est important de préciser COMMENT l'I2C serait utilisé dans un moniteur. Non seulement l'I2C permettrait la communication vers plusieurs moniteurs, mais vers plusieurs périphériques (par exemple plusieurs CI) au sein de chaque moniteur, bien qu'il existe probablement un bus I2C distinct pour chaque câble HDMI dans la plupart des systèmes hôtes. L'interface I2C serait probablement utilisée pour établir la connexion avec l'hôte, où l'hôte interrogerait le moniteur pour trouver des choses comme sa résolution, la fréquence d'images, le fabricant, le nom et probablement d'autres choses. I2C ne serait pas assez rapide pour transférer des données d'image et de son, cette information passe par les fils TDMS, qui seront à haute vitesse et à faible SNR.

Son bon marché, ça marche, il était déjà là depuis l'ère VGA, et il n'y avait pas vraiment de raison de le changer.

Une bonne ingénierie dans l'espace grand public est bon marché et fonctionne assez bien (ce que fait principalement HDMI), personne ne gagne de points pour concevoir quelque chose dans cet espace qui utilise des puces supplémentaires, a de sérieux frais de communication et prend en charge des topologies multidrop complexes pour quelque chose comme ça.

La puce est lue une fois lors de la mise en ligne du lien, donc même si vous ne pouvez synchroniser la chose qu'à des taux KHz, ce n'est pas un problème pour la centaine d'octets de données. CAN ou RS485 auraient tous deux nécessité plus de tâches dans une application grand public très limitée en termes de coûts.

Je soupçonne que le contenu DDC a été importé en gros sans même y penser, comme en fait la plupart du timing vidéo (Displayport et HDMI sont à peu près identiques électriquement), et le timing vidéo peut être facilement retracé au moins aussi loin que la vidéo composite sur les écrans cathodiques, le porche avant, la vidéo active, le porche arrière, l'intervalle de retour ... Cela semble très familier à n'importe quel gars de la télévision à l'ancienne.

Il s'agit en fait d'un cas assez rare où un organisme de normalisation N'apporte PAS de modifications pour supprimer un avantage du fabricant et opte plutôt pour une norme de facto connue pour fonctionner. Je n'aurais pas été surpris par I2C mais avec le bus abaissé et l'état actif étant la logique 1, ou quelque chose de tout aussi stupide juste pour éviter de donner un avantage à Phillips / NXP / Nexperia!