HDMI e I C

Eu estava olhando a pinagem do HDMI e pensei: por que eles usariam I C para a comunicação do host da tela? Minha pergunta aqui é sobre as métricas de design que levam a essa escolha.$^2$

HDMI é um padrão bastante recente , enquanto I C existe desde 1982 . I C destina-se à comunicação a bordo, chip a chip, além disso, o padrão permite vários dispositivos conectados ao mesmo barramento. Como um cabo HDMI pode ter 15 m de comprimento , o sinal I C provavelmente deve usar tensões mais altas que o normal para evitar muito ruído, adicionando a necessidade de tranceivers nos dois lados. Sobre a coisa dos vários dispositivos, não consigo pensar em como você conectaria mais de um monitor a uma única porta HDMI, a menos que você esteja sendo muito, muito fora do padrão.$^2$$^2$$^2$

Eu realmente não sou especialista em protocolos de comunicação, mas acho que o RS485, CAN ou algum outro ponto a ponto, protocolo SNR full duplex e superior teria sido melhor.

Então, por que eles escolheriam I C?$^2$

nota: eu sei que isso pode ser marcado como "baseado em opiniões", espero que alguém ao redor possa pensar / conhecer algumas razões objetivas.

A história do DCC no HDMI passa por DVI até VGA. Ele é implementado de forma que você pode simplesmente conectar um chip de memória I²C eeprom padrão no lado do monitor, que é quase tão barato quanto a sujeira (AT24C01 e compatível).

O sinal I2C provavelmente deve usar tensões mais altas do que o normal para evitar muito ruído

Não. Os +5 volts contam uma história diferente. O que eles podem fazer é uma frequência de relógio mais baixa no barramento. Os cabos HDMI também costumam ser bem blindados.

Então, por que eles escolheriam o I2C?

Estava lá no DVI (com o qual o HDMI é compatível) e funciona e é barato.

O I2C é muito barato e simples de implementar por vários motivos. É frequentemente usado quando apenas alguns bytes precisam ser transferidos. É também uma interface muito estruturada, com protocolo definido para quem deveria estar falando em um determinado momento. O I2C, devido à sua idade, também é bem suportado pelos fabricantes de I2C (por isso, é barato e simples de implementar). Devido à baixa taxa de dados, o SNR realmente não é um problema e 3.3V é uma tensão de barramento típica e pode ser filtrada com baixa passagem, se necessário.

Eu acho importante salientar como o I2C seria usado em um monitor. O I2C não apenas permitiria a comunicação com vários monitores, mas com vários dispositivos (por exemplo, múltiplos ICs) dentro de cada monitor, embora exista provavelmente um barramento I2C separado para cada cabo HDMI na maioria dos sistemas host. A interface I2C provavelmente seria usada para estabelecer a conexão com o host, onde o host consultaria o monitor para descobrir coisas como resolução, taxa de quadros, fabricante, nome e provavelmente outras coisas. O I2C não seria rápido o suficiente para transferir dados de imagem e som; essas informações passam pelos fios TDMS, que serão de alta velocidade e baixo SNR.

É barato, funciona, já estava lá da era VGA, e não havia motivo real para mudar isso.

Uma boa engenharia no espaço do consumidor é barata e funciona bem o suficiente (o que o HDMI costuma fazer), ninguém ganha pontos por projetar algo nesse espaço que usa chips extras, possui sérias comunicações aéreas e suporta topologias multiponto complexas para algo assim.

O chip é lido uma vez na troca de link, portanto, mesmo que você possa registrar apenas a taxa de KHz, isso não é um problema para as centenas de bytes de dados. O CAN ou o RS485 teriam exigido mais ações em um aplicativo de consumidor com muito custo.

Suspeito que o material DDC tenha sido importado por atacado sem muita reflexão, como na verdade era a maior parte do tempo do vídeo (Displayport e HDMI são eletricamente idênticos), e o tempo do vídeo pode ser facilmente rastreado pelo menos desde o vídeo composto em CRTs, alpendre, vídeo ativo, alpendre, intervalo de retração .... Parece muito familiar para qualquer cara da TV da velha escola.

Na verdade, esse é um caso um tanto raro de um organismo de padrões NÃO fazer alterações para remover a vantagem de um fabricante e, em vez disso, optar por um padrão defacto conhecido. Eu não ficaria surpreso com o I2C, mas com o barramento desativado e o estado ativo sendo lógico 1, ou algo igualmente estúpido apenas para evitar oferecer uma vantagem ao Phillips / NXP / Nexperia!