saida VGA

Software e Hardware para linha ARM

Moderadores: 51, guest2003, Renie, gpenga

Mensagempor msamsoniuk » 21 Set 2010 13:45

acho que eh DAC demais para processador de menos hein.

polesapart escreveu:Achei, era esse aí que o colega postou.

http://www.analog.com/en/digital-to-analog-converters/video-encoders/adv7125/products/product.html

Esquematico c/ exemplo de como conectar as linhas do LCD no conversor (o que te interessa tá na pag. 5):
http://www.toradex.com/files/media/pdf/Colibri_EvaluationBoard_Schematics_Rev2.1_0.pdf
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor polesapart » 21 Set 2010 13:53

Marcelo Samsoniuk escreveu:acho que eh DAC demais para processador de menos hein.


Isso vai depender do que ele escolher como processador :P A idéia é usar isso pra algo que tenha uma saída TTF-compatível, pra LCD, com um controlador decente (memória suficiente pra framebuffer, dma, etc).

Qualquer coisa menos que isso, e concordo: cavalos demais pra um fusca :P
Warning: time of day goes back (-163479us), taking countermeasures. :)
Avatar do usuário
polesapart
Byte
 
Mensagens: 477
Registrado em: 19 Nov 2007 12:56
Localização: Curitiba

Mensagempor msamsoniuk » 21 Set 2010 13:59

mesmo 1280x1024 em 85Hz tem pixelclock de apenas 135MHz e 24 bits nessa resolucao requer 400MB/s de bandwidth. mas com esse DAC ae dah para fazer na boa 2048x1536 em 100Hz, o problema eh que precisaria de mais de 1GB/s de bandwidth!

polesapart escreveu:
Marcelo Samsoniuk escreveu:acho que eh DAC demais para processador de menos hein.


Isso vai depender do que ele escolher como processador :P A idéia é usar isso pra algo que tenha uma saída TTF-compatível, pra LCD, com um controlador decente (memória suficiente pra framebuffer, dma, etc).

Qualquer coisa menos que isso, e concordo: cavalos demais pra um fusca :P
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor polesapart » 21 Set 2010 14:17

Marcelo Samsoniuk escreveu:mesmo 1280x1024 em 85Hz tem pixelclock de apenas 135MHz e 24 bits nessa resolucao requer 400MB/s de bandwidth. mas com esse DAC ae dah para fazer na boa 2048x1536 em 100Hz, o problema eh que precisaria de mais de 1GB/s de bandwidth!


Os controladors de LCD TTF desta classe costumam fazer 1024x768 @60hz (alguns fazem 75hz). Como foram projetados para painéis de LCD e não monitores de tubo, geralmente a diferença do clock é inútil (bom, pode até não ser, mas o fato é que os fabricantes de LCD de mesa não tem colocado clock maior que 75hz na entrada vga deles (eu brinquei plugando o notebook com uma tv de 32" dia desses, apesar da resolucao 1920x1080, o clock era apenas 60hz, e em 1024x768 o EDID tentava forcar 60hz tbm, embora aceitasse 75hz). Até o cabo de vídeo desses monitores LCD de mesa estão vindo safados e sem blindagem :/

Provavelmente fazem isso por que como o fade out do pixel do lcd independe de ser "refresheado" pelo sinal analógico como ocorre na varredura do monitor de tubo, o clock para imagens estáticas e evitar distorçoes realmente pode ser menor. Nas imagens muito dinâmicas, se fizesse diferença teorica, não faria na prática: reza a lenda que os painéis LCDs convencionais são + lentos pra trocar o valor do pixel do que isso. No caso das TVs parece que o grande diferencial está sendo melhorar isso.

Outra coisa é que os barramentos TFT até podem ter 24 bits, mas esses painéis pequenos são de (no máximo) 18 bits em sua maioria (trabalhei com uns de 16 bits, com um conversor lvds no meio), então tá sendo difícil achar controladores para os TFT de 24 bits: muitos estão vindo só com 18.


Então a largura de banda memória <-> controlador TFT não precisa ser o fim do mundo: usando 24 bits de cor (o controlador descartando os inferiores (m.s.) de cada cor), aliás, chutemos o pau da barraca, supondo que ele precise 32 bits por pixel, isso dá um pouco menos de 24 mhz pra 30 frames/s (entre memória <-> controlador tft, a partir dali ele gera os line clocks ou seja la o que for que saia dele, eu não lembro hehe... bom, aí precisa de um dac parrudo, em tese poderia ser um menor que este, mas não sei se acha algo muito pior que esse :P
Warning: time of day goes back (-163479us), taking countermeasures. :)
Avatar do usuário
polesapart
Byte
 
Mensagens: 477
Registrado em: 19 Nov 2007 12:56
Localização: Curitiba

Mensagempor rcakto » 21 Set 2010 22:40

bom, eu ainda nao tive tempo para ler os documentos que voces postaram, MAS pela conversa de voces, daria para economizar nos pinos caso o meu professor esteja certo... ele uma vez comentou em sala que existe ICs onde converte sinal serial em paralelo de 10BITs, acredito eu que poderei aumentar a eficiencia do circuito com isso.... o problema e achar e ver o custoXbeneficio de utilizar de tal aparato....

NEON, para facilitar nas minhas perguntas eu vou documentar todo o meu projeto e colocar online... mas so tera a parte teorica pq ainda tenho de aprender muito para jogar na pratica...
rcakto
Word
 
Mensagens: 787
Registrado em: 09 Jun 2010 00:57
Localização: vitoria ES

Mensagempor polesapart » 21 Set 2010 23:39

rcackto, a melhor dica que posso dar é a que já te apresentaram, e a que vc mesmo sugeriu: formalize melhor teu projeto, e esqueçamos o hardware por enquanto.

Pois tem "N" variáveis aí. E começar pensando se vai ser necessário economizar pinos ou não não é o caminho. É preciso entender que você tem várias opções para gerar vídeo, dependendo muito do que você considera um mínimo aceitável; Vídeo é complexo, não tem muito milagre, vc quer por um shift register tocando um LCD com um único pino de um pic de 8 pinos? Claro que dá pra fazer: mas quantos quadros por segundo (ou melhor, segundos por quadro neste caso hehehe) são necessários pra uma interface com o usuário decente?

E por aí vai: Quantas cores você vai precisar exibir simultaneamente? Qual resolução mínima é aceitável? Você vai usar imagens de alta resolução, e se sim, em que contexto?

Antes de responder essas perguntas (e outras até mais importantes que devem vir antes dela), é preciso estar com a visão geral bem formalizada.

Senão vc vai fazer como trabalho de universidade, o cara se propõe a mudar o mundo ou explicar como funciona a cabeça das mulheres como trabalho de conclusão de curso, vai apressado ao laboratório e começa logo montando uma protoboard com um pic de 8 pinos, um 555, três leds, vai ligar a alimentação e dizer "faça-se a luz!", e no máximo vai sair só uma fumacinha, e quando ele perceber que o buraco é mais embaixo, que daquele ferramental ele não extrai nem o começo, vai pensar "droga, onde fui me meter?" :P

E pq eu usei esse exemplo? pq sem aparar algumas arestas e definir algumas direções, teu trabalho vai acabar ficando *mais* complicado que explicar como funciona cabeça de mulher.
Warning: time of day goes back (-163479us), taking countermeasures. :)
Avatar do usuário
polesapart
Byte
 
Mensagens: 477
Registrado em: 19 Nov 2007 12:56
Localização: Curitiba

Mensagempor msamsoniuk » 22 Set 2010 00:05

pow, eu ainda uso 1280x1024 em 85Hz num display CRT. enfim, mesmo com resolucao altissima nao ocuparia um DAC tao veloz. para VGA, tem varios DACs mais simples:

http://www.analog.com/en/digital-to-ana ... index.html

polesapart escreveu:
Marcelo Samsoniuk escreveu:mesmo 1280x1024 em 85Hz tem pixelclock de apenas 135MHz e 24 bits nessa resolucao requer 400MB/s de bandwidth. mas com esse DAC ae dah para fazer na boa 2048x1536 em 100Hz, o problema eh que precisaria de mais de 1GB/s de bandwidth!


Os controladors de LCD TTF desta classe costumam fazer 1024x768 @60hz (alguns fazem 75hz). Como foram projetados para painéis de LCD e não monitores de tubo, geralmente a diferença do clock é inútil (bom, pode até não ser, mas o fato é que os fabricantes de LCD de mesa não tem colocado clock maior que 75hz na entrada vga deles (eu brinquei plugando o notebook com uma tv de 32" dia desses, apesar da resolucao 1920x1080, o clock era apenas 60hz, e em 1024x768 o EDID tentava forcar 60hz tbm, embora aceitasse 75hz). Até o cabo de vídeo desses monitores LCD de mesa estão vindo safados e sem blindagem :/

Provavelmente fazem isso por que como o fade out do pixel do lcd independe de ser "refresheado" pelo sinal analógico como ocorre na varredura do monitor de tubo, o clock para imagens estáticas e evitar distorçoes realmente pode ser menor. Nas imagens muito dinâmicas, se fizesse diferença teorica, não faria na prática: reza a lenda que os painéis LCDs convencionais são + lentos pra trocar o valor do pixel do que isso. No caso das TVs parece que o grande diferencial está sendo melhorar isso.

Outra coisa é que os barramentos TFT até podem ter 24 bits, mas esses painéis pequenos são de (no máximo) 18 bits em sua maioria (trabalhei com uns de 16 bits, com um conversor lvds no meio), então tá sendo difícil achar controladores para os TFT de 24 bits: muitos estão vindo só com 18.


Então a largura de banda memória <-> controlador TFT não precisa ser o fim do mundo: usando 24 bits de cor (o controlador descartando os inferiores (m.s.) de cada cor), aliás, chutemos o pau da barraca, supondo que ele precise 32 bits por pixel, isso dá um pouco menos de 24 mhz pra 30 frames/s (entre memória <-> controlador tft, a partir dali ele gera os line clocks ou seja la o que for que saia dele, eu não lembro hehe... bom, aí precisa de um dac parrudo, em tese poderia ser um menor que este, mas não sei se acha algo muito pior que esse :P
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor polesapart » 22 Set 2010 00:13

Marcelo Samsoniuk escreveu:pow, eu ainda uso 1280x1024 em 85Hz num display CRT. enfim, mesmo com resolucao altissima nao ocuparia um DAC tao veloz. para VGA, tem varios DACs mais simples:


Eu tenho um monitor de tubo que pega 1600x1200 @ 75hz ... eu usava ele em 14??x??? @ 100hz, mas eu comecei a ficar meio cegueta e ultimamente só tava usando 1152x864 ... mas o cabo do maldito rompeu de tanto ficar dobrado num ponto só, quando mudei de lugar desdobrou, rompeu as linhas r & b, ficou só a g funcionando: até que eu tenha saco de consertar o cabo, eu tenho um monitor de fósforo daqueles de antigamente uahehuahee :D

Tá encostado num canto.

Marcelo Samsoniuk escreveu:http://www.analog.com/en/digital-to-analog-converters/video-encoders/products/index.html


Bom saber :D
Warning: time of day goes back (-163479us), taking countermeasures. :)
Avatar do usuário
polesapart
Byte
 
Mensagens: 477
Registrado em: 19 Nov 2007 12:56
Localização: Curitiba

Mensagempor rcakto » 22 Set 2010 08:18

Bom, vamos por parte... polesapart, eu não estou saindo fora da ideia do meu projeto, e ele é algo que para mim mesmo, não e para TCC ou para vender, é de uso pessoal meu, e so estou vendo as possibilidades de sair fora dos ARMs que tem modulo LCD, MAS que na maioria não tem memoria interna..

NEON, em resumo meu projeto será uma "central" onde utilizarei sensores para monitorar circuitos ou aparelhos que eu monte, assim terei uma forma de feedback para analise de melhoramento E/OU para evitar falhas possiveis. Mas o problema central está sendo no CHIP a trabalhar pois quase todos que achei no site da nxp que vem com modulo LCD não tem memoria interna para o codigo... e como estou aprendendo a programar ARM, eu irei escolher um chip para o meu projeto pessoal, aprenderei a programar todos seus perifericos e possibilidades e apos isto irei dar inicio a formalização do projeto.

Antes de mais nada, agradeço a todos pela atenção!!!

Fui.. ainda tenho muito que fazer por hj, atarde eu volto.
rcakto
Word
 
Mensagens: 787
Registrado em: 09 Jun 2010 00:57
Localização: vitoria ES

Mensagempor helton » 22 Set 2010 09:03

Já que é algo pra vc, não seria interessante utilizar uma beagle board para escrever num display de LCD, aproveitando que ela tem :

- DVI-D for connecting digital computer monitors
- Compatibility with a huge collection of USB peripherals including hubs, keyboards, mice, WiFi, Bluetooth, web cameras, and much more

http://beagleboard.org/hardware
Helton Marques
"Priorize as Prioridades"
helton
Byte
 
Mensagens: 146
Registrado em: 16 Out 2006 09:18
Localização: São José-SC

Mensagempor rcakto » 22 Set 2010 09:17

Helton, o problema e o seguinte, eu estou querendo MUITO aprender a programar ARM e eu até tenho um kit aqui com o 2368, MAS achei muito complicado fica olhando na placa qual pino esta conectado em qual jamper para utilização de componentes externos... e no beagle vai ser a mesma coisa, mas para uma aplicação que não precise de algo adcional, que não vai ser o meu caso no momento, realmente ele e uma mao na roda pelo valor dele... entao prefiro fazer uma placa simples para utilizar livremente o chip, irei aprender e o principal de tudo.. poderei dizer "eu fiz e aprendi"...
rcakto
Word
 
Mensagens: 787
Registrado em: 09 Jun 2010 00:57
Localização: vitoria ES

Mensagempor Djalma Toledo Rodrigues » 22 Set 2010 10:05

Quanto ao kit 23268 e o complicados jumper's você poderia fazer um esquema ou uma respectiva Tabela.

Ou mesmo figura com a facilidade de fotos digitais

---------------------------------------------------------------
Agora dificil mesmo e "*mais* complicado que explicar como funciona cabeça de mulher.
como disse o Polesapart
Nem Freud conseguiu
caracas
----------
DJ
Avatar do usuário
Djalma Toledo Rodrigues
Dword
 
Mensagens: 2334
Registrado em: 03 Ago 2008 13:22

Mensagempor rcakto » 22 Set 2010 10:32

isso eu sei, eu até tentei fazer a sequencia dos pinos, mas por exemplo, usando um teste de continuidade do multimetro para saber aonde esta o pino 100 deu sinal em 3 pinos diferentes da pinagem que sai da placa para poder usar em protoboard... deve ter algum componente na placa que esta fazendo essa ligação.. e como não sou nada paciente para ficar testando de um em um... prefiro selecionar um chip que va me servir, fazer uma placa minha, aprender a programar, e montar meu projeto.... se eu ja tivese o chip escolhido em 2 semanas ja estava programando ele... eu ate pensei em tirar o 2368 e montar uma placa a meu modo para ele... mas me falaram que esse chip ta cheio de bugs internos que a nxp nao resolveu ( ainda não tive tempo de ler o erratas dele, mas sei que não passa dos 200Mhz internos por falha na fabricação) ...
rcakto
Word
 
Mensagens: 787
Registrado em: 09 Jun 2010 00:57
Localização: vitoria ES

Mensagempor msamsoniuk » 22 Set 2010 11:51

que medo hein, o fabim nao havia comentado sobre estes bugs! :/

rcakto escreveu:isso eu sei, eu até tentei fazer a sequencia dos pinos, mas por exemplo, usando um teste de continuidade do multimetro para saber aonde esta o pino 100 deu sinal em 3 pinos diferentes da pinagem que sai da placa para poder usar em protoboard... deve ter algum componente na placa que esta fazendo essa ligação.. e como não sou nada paciente para ficar testando de um em um... prefiro selecionar um chip que va me servir, fazer uma placa minha, aprender a programar, e montar meu projeto.... se eu ja tivese o chip escolhido em 2 semanas ja estava programando ele... eu ate pensei em tirar o 2368 e montar uma placa a meu modo para ele... mas me falaram que esse chip ta cheio de bugs internos que a nxp nao resolveu ( ainda não tive tempo de ler o erratas dele, mas sei que não passa dos 200Mhz internos por falha na fabricação) ...
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor polesapart » 22 Set 2010 11:57

O 2368 foi desenhado pra 72mhz ... do que vc tá falando?! :P
Warning: time of day goes back (-163479us), taking countermeasures. :)
Avatar do usuário
polesapart
Byte
 
Mensagens: 477
Registrado em: 19 Nov 2007 12:56
Localização: Curitiba

AnteriorPróximo

Voltar para ARM

Quem está online

Usuários navegando neste fórum: Nenhum usuário registrado e 1 visitante

cron

x