HDMI e I C


15

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.222

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.


+1 para uma ótima pergunta! Eu acho que isso se relaciona com a CEC! Eu uso o STM32 e eles têm um periférico CEC e estou ansioso para saber a resposta.
Roh

2
Atuei em alguns painéis VESA como representante de padrões de uma semi-empresa (VGA) quando o DDC2 estava sendo implementado. A Philips conseguiu negociar para implementar seu padrão, o que era pouco contencioso por ser uma solução proprietária, embora seja uma boa solução para plug and play. Então, @TurboJ tem a resposta certa. Naquele momento, o multi-drop não era considerado importante, pois era analógico ponto a ponto (VGA).
placeholder

Respostas:


8

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.


2
Então, em resumo, você está dizendo que é devido a problemas de compatibilidade herdada e funciona bem. Por que alterá-lo?
horta

3

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.


Então, você está dizendo que, em uma configuração multi-HDMI, apenas um transceptor i2c é necessário no lado do host, e é por isso que a comunicação multi-ponto é uma coisa agradável de se ter?
Vladimir Cravero

Você nem precisaria de um transceptor dedicado (como em um único IC cuja única função é se comunicar através do I2C). Poderia ser apenas uma responsabilidade menor de um IC de ponte que está gerenciando uma variedade de interfaces diferentes. É provável que exista um barramento I2C dedicado para cada monitor. Uma das falhas do I2C (IMO) é que nenhum dos dois escravos pode ser configurado com o mesmo endereço de barramento e não há protocolo (que eu saiba) para atribuir dinamicamente novos endereços aos escravos.
precisa saber é o seguinte

Sim, esse foi o meu ponto, além do mais, acho que dois monitores idênticos têm o mesmo endereço, então você precisará de linhas separadas de qualquer maneira.
Vladimir Cravero

1
Eu não acho que esse fato seja realmente um grande problema ou contra-argumento para o seu uso em HDMI. Especialmente quando você considera que praticamente qualquer outro protocolo exigiria uma interface separada para cada monitor.
kjgregory

Sim, eu concordo com isso
Vladimir Cravero

0

É 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!

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.