Como criar um clone do Ambilight baseado em FPGA?


10

Alguns antecedentes rápidos: O
Ambilight é um sistema em algumas TVs Philips que analisa as informações de cores na tela e define alguns LEDs na parte traseira do monitor para projetar a cor da tela na parede. É um efeito bastante bacana. Agora, existem clones desse sistema que usam um PC para processar o vídeo e controlar os LEDs. Acho que isso é um pouco exagerado - usar uma máquina inteira para dançar alguns LEDs ...

Gostaria de modificar o NeTV do bunnie para processar um processo não criptografado.Alimentação de vídeo HDMI e conduza alguns LEDs. Sei que o NeTV foi projetado para outros fins, mas sinto que ele pode ser modificado para alcançar meu objetivo. Não ligo para o subsistema Linux subjacente, a falsificação I2C, a sobreposição de vídeo etc. Neste momento, não estou preocupado em trabalhar com fluxos criptografados em HDCP.

Esquemas NeTV

Código fonte NeTV

Diagrama de blocos do FPGA Diagrama de blocos do NeTV
Este é um diagrama de blocos de um dos slides da apresentação de bunnie.
O restante do conjunto de slides está aqui .

Apresentação de slides HSYNC, VSYNC, PIXCLK
Esse slide parece sugerir que os pixels do vídeo são decodificados (não necessariamente descriptografados ) .

Finalmente ... alguns dos meus pensamentos e perguntas:

  1. Isso pode ser feito no meu hardware desejado? Se "sim", continue! Se "não", me diga o que mais eu preciso!

  2. Serei capaz de processar informações de vídeo sem nenhuma memória externa? Não há memória que o FPGA possa acessar diretamente, pelo que sei. Provavelmente depende de qual algoritmo eu uso para processar os dados de vídeo - para usar o mínimo possível de RAM de bloco FPGA, acho que eu gostaria de usar algum tipo de 'soma iterativa' dos pixels que chegam, em vez de armazenar um todo quadro de dados da imagem e, em seguida, calculando a média das cores. Alguma dica em relação à implementação desse algoritmo? Como começar com isso é o meu maior obstáculo.

  3. Eu investiguei o código-fonte para onde eu deveria 'acessar' os dados do vídeo.
    Parece o local apropriado:
    Diagrama de blocos do decodificador DVI
    eu sei, essa imagem é longa - é o melhor que eu poderia fazer enquanto deixava a leitura clara. Culpe a ferramenta da Xilinx por isso!
    Isso parece absorver os dados do TMDS e gerar 8 bits para cada cor.

  4. Eu deveria ter algum tipo de máquina de estado para o driver de LED - a cada ciclo de relógio, ele obtém as informações de pixel de qualquer módulo que eu criar para processar os dados de vídeo.

Desculpe se isso é prolixo ou longo - estou tentando ser meticuloso ... só preciso de ajuda para decolar com isso. Esta é a minha primeira tentativa de um projeto FPGA - alguns podem dizer que é muito difícil para um iniciante, mas eu digo ... tenho que começar em algum lugar :) Obrigado pela leitura.


11
O NeTV não decodifica o fluxo HDMI. Ele segue o processo de negociação do HDCP e criptografa o novo fluxo para corresponder; Acho que você não conseguirá obter informações em vídeo com isso.
Akohlsmith

Você poderia postar (um link para) os esquemas relevantes? Além disso, a declaração dos módulos HDL relevantes ajudaria.
Drxzcl

11
@AndrewKohlsmith, então a sobreposição é feita no final da TV? Uau, eu não tinha ideia que o HDMI poderia fazer isso!
Drxzcl

11
Não sei se você será capaz de fazer tudo o que precisa sem usar um buffer de quadro de memória externo, mas, de qualquer maneira, que análise de cores você planeja usar? Se for FFT, levará algum tempo e não tenho certeza se a luz ambiente não será tarde demais para a cor do vídeo. Eu diria que primeiro tente obter dados do HDMI e verifique se você pode analisá-lo. Por exemplo, faça um filtro passa-baixo e produza o resultado.
Sócrates

11
Lembro-me de ler isso de volta quando o NeTV saiu. De acordo com esse post, Bunnie usa um esquema de sobreposição complicado que não requer descriptografar a fonte HDMI; ele apenas o criptografa novamente quando necessário. Não há decodificação de fluxos criptografados.
quer

Respostas:


7

Estou baseando minha resposta completamente no código e na documentação do módulo dvi_decoder , e supondo que ele realmente funcione conforme anunciado. Este arquivo parece ser uma cópia (modificada?) Do IP nas notas do aplicativo Conectividade de Vídeo Usando E / S TMDS nos FPGAs Spartan-3A e / ou Implementando uma Interface de Vídeo TMDS no FPGA Spartan-6 . Essas notas de aplicativos estão repletas de detalhes importantes e sugiro que você as leia com atenção.

Como você indicou na pergunta, assumirei que você está tratando fluxos não criptografados, ou seja, não-HDCP. Estou bastante certo de que as informações no projeto NeTV podem ser adaptadas para descriptografar o HDCP, mas isso envolveria uma quantidade não trivial de trabalho adicional e estaria em bases legais questionáveis, dependendo da sua jurisdição.

Parece que você será capaz de obter os dados necessários das saídas do bloco dvi_decoder. Informações do bloco de saídas de 24 bits de cor utilizando os fios red, greene blue, sincronizado com o relógio do pixel pclk. As saídas hsynce vsyncalertam o usuário para o final de uma linha / tela, respectivamente. Em geral, você deve conseguir fazer a média instantânea usando essas saídas.

Você vai precisar de alguma lógica básica para traduzir hsync, vsynceo relógio de pixel em um local (X, Y). Instancie apenas dois contadores, um para Xe outro para Y. Incremento Xa cada pixel clock. Redefina Xpara zero em hsync. Incremento Ya cada hsync. Redefina Ypara zero a cada vsync.

Usando red, green, blue, Xe Y, você pode fazer na média mosca. Ao comparar com Xe Y, você pode determinar em qual caixa cada pixel individual deve contribuir, se houver. Soma os valores das cores em um registro de acumulação. Para obter o valor médio, você precisa dividir o valor no registro pelo número de pixels. Se você for esperto, verifique se o número de pixels é uma potência de dois. Em seguida, você pode simplesmente conectar os MSBs do registro ao que desejar.

Como queremos direcionar as exibições durante o acúmulo, precisaremos fazer buffer duplo. Portanto, precisaremos de dois registros por caixa e por componente. Se você estiver usando uma string de 25 led, isso significa que você precisará de 25 * 3 * 2 = 150 registros. Isso é um pouco, então você pode querer usar o bloco ram em vez de registradores. Tudo depende de suas necessidades exatas, experimente!

Presumo que você esteja dirigindo uma corda de led como a usada no kit original do projeto adafruit . Você deve ser capaz de descobrir como direcioná-lo a partir dos valores nos registros com bastante facilidade usando o SPI.

O módulo dvi_decoder é um kit bastante complexo. Eu sugiro que você estude as notas do aplicativo em detalhes.

Além disso, se você ainda não comprou um NeTV para uso neste projeto, recomendo que você também dê uma olhada no quadro Atlys da Digilent . Com duas entradas HDMI e duas saídas HDMI, ele parece ser feito sob medida para projetos desse tipo.


NP, obrigado pela pergunta legal. Se você tiver algum problema específico com este projeto, sinta-se à vontade para postar novamente.
Drxzcl 9/08/12

Btw, (e isso está particularmente fora do escopo da pergunta), você já pensou em dirigir o carro de um sistema de microcontrolador relativamente robusto? Algo como o RaspberryPi é cerca de 6 vezes mais barato e deve ser capaz de acionar os leds e exibir o vídeo ao mesmo tempo.
Drxzcl

ainda aguardo a chegada da minha ferramenta JTAG para que eu possa depurar com o ChipScope ... aceitando esta resposta; estabelece uma abordagem fundamental para resolver esse problema. @drzxcl eu já tenho o netv em minha posse. RaspPi é uma sugestão interessante, mas impossível usar o HDMI como fonte de vídeo.
dext0rb

Você já conseguiu fazer isso funcionar? Adoraria ver um artigo / vídeo!
drxzcl

Não, na verdade não. : | Eu fiz um driver de LED meio bobo , mas ainda não tive tempo de entrar nele. Espero que em breve.
dext0rb
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.