HDMI e I \ $ ^ 2 \ $ C

El historial de DCC en HDMI va a través de DVI hasta VGA. Se implementa de manera que simplemente puede conectar un chip de memoria I²C eeprom estándar en el lado del monitor, que es casi tan barato como la suciedad (AT24C01 y compatible).

  

La señal I2C probablemente debería usar voltajes más altos que los normales para evitar demasiado ruido

No. Los +5 voltios te cuentan una historia diferente. Lo que podrían hacer es una frecuencia de reloj más baja en el bus. Los cables HDMI también suelen estar bien protegidos.

  

Entonces, ¿por qué elegirían I2C?

Estaba allí en DVI (al cual HDMI es compatible) y funciona y es barato.

I2C es muy económico y fácil de implementar por varias razones. Se usa a menudo cuando solo se necesitan transferir unos pocos bytes. También es una interfaz muy estructurada, con un protocolo definido para quién debe hablar en un momento dado. I2C, debido a su antigüedad, también está bien soportado entre los fabricantes de I2C (por lo tanto, su implementación es económica y sencilla). Debido a la baja velocidad de datos, la SNR no es realmente un problema y 3.3V es una tensión de bus típica y puede filtrarse en un paso muy bajo, si es necesario.

Creo que es importante señalar CÓMO el I2C se usaría en un monitor. El I2C no solo permitiría la comunicación con múltiples monitores, sino también con múltiples dispositivos (por ejemplo, múltiples circuitos integrados) dentro de cada monitor, aunque es probable que haya un bus I2C separado para cada cable HDMI en la mayoría de los sistemas host. La interfaz I2C probablemente se usaría para establecer la conexión con el host, donde el host consultaría al monitor para averiguar cosas como su resolución, velocidad de fotogramas, fabricante, nombre y probablemente otras cosas. I2C no sería lo suficientemente rápido para transferir datos de imagen y sonido, esa información pasa a través de los cables TDMS, que será de alta velocidad y baja SNR.

Es barato, funciona, ya estaba allí desde la era VGA, y no había ninguna razón real para cambiarlo.

La buena ingeniería en el espacio del consumidor es barata y funciona lo suficientemente bien (lo que en su mayoría lo hace HDMI), nadie gana puntos por diseñar algo en ese espacio que usa chips adicionales, tiene una gran sobrecarga de comunicaciones y es compatible con topologías complejas multipunto para algo como esto.

El chip se lee una vez en la activación del enlace, por lo que incluso si solo puede cronometrar la cosa a velocidades de KHz, eso no es un problema para los cien bytes de datos. CAN o RS485 habrían requerido más acciones en una aplicación de consumo muy restringida en costos.

Sospecho que el material DDC se importó al por mayor sin siquiera pensarlo, ya que en realidad era la mayor parte de la sincronización de video (Displayport y HDMI son prácticamente idénticos eléctricamente), y la sincronización de video se puede rastrear fácilmente al menos tan atrás. como video compuesto en CRT, porche delantero, video activo, porche trasero, intervalo de rastreo ... Parece muy familiar para cualquier chico de la televisión de la vieja escuela.

Este en realidad es un caso un tanto raro en el que un organismo de estándares NO realiza cambios para eliminar una ventaja de los fabricantes, y en su lugar va con un estándar de facto conocido. I2C no me hubiera sorprendido, pero con el bus derribado y el estado activo como lógica 1, o algo igual de estúpido para evitar darle una ventaja a Phillips / NXP / Nexperia.