LusoRobótica - Robótica em Português
Robótica => Projectos de robótica => Projectos em desenvolvimento => Tópico iniciado por: LuísR.A. em 04 de Agosto de 2014, 23:13
-
Entao achei que devia postar aqui nos projectos, como as vezes o pessoal pede para ver projectos.
Decidi ja à uns 2 meses fazer uma matriz de LEDs RGB, possivelmente de 800, levando a um total de 2400 para controlar.
Ora como pretendia tirar partido total das cores que um RGB consegue ter queria ter controlo de brilho.
Decidi usar o TLC5940.
Para controlar isto tudo tenho um Tiva TM4C1294XL launchpad, um ARM-M4 que funciona a 120Mhz
Possivelmente ja viram noutro post eu às voltas com ele a tentar mete-lo a funcionar. Tentei algumas coisas mas no fim decidi assim controla-lo:
Usar apenas o GrayScale mode.
Para o GSCLK uso o gerador de PWM do Tiva so porque nao queria usar um timer, nao vou usar motores e talvez precise do o timer para algo, mas pode-se perfeitamente usar um timer para o GSCLK.
Para enviar dados decidi usar o modulo Quad-SSI que permite mandar em paralelo 4 sinais de dados diferentes, com o mesmo CLK.
Escolhi GSCLK e SCLK de 30Mhz, a velocidade maxima do TLC5940. Nesta velocidade tive problemas de interferencias por causa ate de usar uma breadboard. Adicionei um anel de ferrite e ficou 5 estrelas.
Ora no final do ciclo de PWM é necessario pulsar o BLANK e tambem para guardar os valores enviados para o TLC5940 é necessario pulsar o XLAT. Para este fim de ciclo uso um timer para contar os "rising edge" do GSCLK, o timer automaticamente conta e gera um interrupt ao pulso nº 4096. Ai pulso o BLANK e o XLAT e digo ao modulo SSI que pode fazer um update aos dados quando quiser.
No modo que tenho agora estou sempre a enviar dados em todos os ciclos de PWM.
Da maneira que tenho o processador so tem de intervir no interrupt, em que perde menos de 400ns nele. E claro para mudar os valores de PWM sempre que quer.
Assim com um PWM de 12bits de resolução tenho um refresh rate de 7302hz, dando muito espaço para multiplexar. Tambem de considerar que o TLC5940 permite usar varios em cascata e como é necessário só 192bits para completamente configurar um TLC5940, dentro do ciclo de PWM é possivel usar 21 TLC5940 em serie.
E estou por aqui. Quando começar a vir o material ou tiver algum update venho ca postar. Por agora é so isto. Deixo 1 video a controlar 4 pequenas fitas RGB, espero que se veja
https://www.youtube.com/watch?v=w1PSUIQFN_g (https://www.youtube.com/watch?v=w1PSUIQFN_g)
talvez este mostre melhor o efeito
https://www.youtube.com/watch?v=aaarrQ2wt98&feature=youtu.be (https://www.youtube.com/watch?v=aaarrQ2wt98&feature=youtu.be)
-
é de preposito aquele delay entre as fitas?..
vais montar a matriz de 800 leds com as matrizes 8x8?
-
é de preposito aquele delay entre as fitas?..
vais montar a matriz de 800 leds com as matrizes 8x8?
O delay é de proposito. Queria fazer um efeito de girar. Se tens algum padrao que queiras em especifico com essas 4 fitas posso fazer :p gosto de ir testando padroes enquanto nao me apetece implementar o UART
Isso ficava mt caro. Tava a pensar usar leds mesmo um pouco afastados, a baixa resoluçao nao importa :p mas era giro fazer assim com essas matrizes
Aqui esta um para veres que dá para mudar tudo ao mesmo tempo
https://www.youtube.com/watch?v=6jqI0UZAiS0&feature=youtu.be (https://www.youtube.com/watch?v=6jqI0UZAiS0&feature=youtu.be)
-
Não vale a pena perder tempo com isso, é a conclusão a que já cheguei, ws2812b e um Teensy 3 ou 3.1 com FadeCandy e está feito, o software é extremamente bem feito, dá para centenas de leds, muito código para o lado do pc, muito flexivel.
Por outro lado, percebo a ideia de querer fazer isso, a ideia é aprender.
-
Não vale a pena perder tempo com isso, é a conclusão a que já cheguei, ws2812b e um Teensy 3 ou 3.1 com FadeCandy e está feito, o software é extremamente bem feito, dá para centenas de leds, muito código para o lado do pc, muito flexivel.
Por outro lado, percebo a ideia de querer fazer isso, a ideia é aprender.
Pois é. A ideia era aprender. Nao considerei fitas de leds endereçadas porque pensei que eram muito mais caras mas mostraram-me que nem por isso. Talvez use isso apesar deste trabalho todo, mas nao sera trabalho perdido claro porque aprendi imensas coisas.
-
Pelos vistos agora tenho de usar fitas de leds endereçaveis, ou seja, o tlc5940 nao interessa.
Para isso gostava de opiniões, uso ws2811/ws2812 ou ws2801?
Parecem ser na pratica muito parecidos, tirando a comunicação. O ws2812 parece ser o mais popular mas acho-o tao lento, com um minimo de 30uS de envio por LED RGB. Se quisesse usar VGA nisto seria muito dificil. E tambem acho mais dificil de comunicar com ele
Por isso queria usar o ws2801 mas parece ser pouco popular apesar dos 25Mhz de clock possivel na comunicação serial e o facto de muitos MCUs terem um periferico dedicado para este tipo de comunicação
-
ok certo.
mas usando as matrizes 8x8, até quantas davam pra usar? (em mono e matrizes rgb?)
-
ok certo.
mas usando as matrizes 8x8, até quantas davam pra usar? (em mono e matrizes rgb?)
Deixa me ver, que resolução pretendes de PWM? de 256-4096.
Para 4096:
30Mhz estao ambos os CLK, logo da uns 137uS para os 4096 rising edges de GSCLK, no fim necessita de 400nS para fazer o latch, reset do counter, etc. Dentro desses 137uS consegues em teoria ter em serie 21 TLC5940. Isto da jeito para a multiplexagem porque assim podes ainda multiplexar, por output do modulo, 146 em teoria se quiseres uma frequencia de 50Hz.
Ora 21*16*146=49056 Leds com resolução de 4096. So que isto claro é impratico porque assim cada led esta ligado muito pouco tempo e ficam com pouco brilho (e resoluçao claro) por isso multiplexar 4x ou 8x no maximo é melhor, por isso 1344 a 2688 LEDs é o valor teorico mais pratico.
E vê, fiz as contas com alguem que tem muito mais conhecimentos com este MCU e concluimos que o codigo para um ciclo PWM (de 4096) ocupa o processador 0,29% do tempo, isto aproximadamente.
Tendo este Tiva 4 modulos SSI, e este pouco overhead, podes quadrupiclar os valores anteriores.
Logo, se conseguires um sinal forte o suficiente para nao sofrer interferencia a esta velocidade e quantidade de cablagem que terá de ter entre os TLC5940, poderás ter potencialmente 5376-10752 LEDs com multiplexagem e 4 modulos SSI ou 1344 LEDs com 4 modulos SSI e sem mux. Falo sempre de LEDs individuais, RGB contam como 3.
ps: se queres algo de controlo mono de LEDs, sem controlo de brilho, sei melhor
-
aqui esta um examplo a usar o ws2812, gostava era de experimentar o ws2801 mas nao tenho ca https://www.youtube.com/watch?v=NrOKWOEVLHw (https://www.youtube.com/watch?v=NrOKWOEVLHw)
-
Lentos?
Vai ver o que fazem com o FadeCandy e se o achas lento.
E se vais fazer um ecrã com resolução VGA com leds, prepara uns milhares..
-
Lentos?
Vai ver o que fazem com o FadeCandy e se o achas lento.
E se vais fazer um ecrã com resolução VGA com leds, prepara uns milhares..
Acho muito mais dificil de trabalhar em relação ao ws2801 por causa to tipo de interface. 2º estando limiitado a 30uS por led, torna mais dificil ter fitas em serie em relação ao ws2801. O ws2812 necessita muito mais de envio paralelo. O efeito que por exemplo tenho em um dos meus videos com o TLC5940, envolve enviar um valor diferente a cada 20uS, impossivel para o ws2812 mas possivel como ws2801. Mas esta parte ate pode ser contornada
Uma matriz de 8x8 demora 0,00192s a receber todos os dados. Por isso acho que mesmo que usa-se DMA para enviar os dados pelos GPIO acho que nao vale o trabalho havendo algo com comunicação tipo SPI a 25Mhz
Quem disse resolução VGA? Apenas vou enviar por VGA. Converto o video que quero para a resolução que quero e depois na leitura do VGA leio de x em x pixels.
-
16 fitas de leds:
https://www.youtube.com/watch?v=ezCkpqYFVxg (https://www.youtube.com/watch?v=ezCkpqYFVxg)
-
16 fitas de leds:
https://www.youtube.com/watch?v=ezCkpqYFVxg (https://www.youtube.com/watch?v=ezCkpqYFVxg)
Ai está, envia até 64 por canal, e tem 8.
Demora 2ms por cada 64... Acho que dá para trabalhar com isso.
Significa que tenho de ir mais na direção de envio paralelo ja que nao da para ter em serie mais rapido.
Mas continuo com o problema do VGA...
-
2ms são 500Hz, tens video a mais de 500Hz?
Se multiplexares os tlc tambem se torna mais lento e precisa de mais house-keeping só para manter os leds a funcionar correctamente, não existem soluções baratas no que toca a controlar quantidades massivas de leds.
-
2ms são 500Hz, tens video a mais de 500Hz?
Se multiplexares os tlc tambem se torna mais lento e precisa de mais house-keeping só para manter os leds a funcionar correctamente, não existem soluções baratas no que toca a controlar quantidades massivas de leds.
Isso é verdade quanto a soluções baratas, ou faceis.
O problema é so ter os dados todos do VGA ao fim de 20mS, e so depois enviar os dados para os drivers.
Pensei em mal recebia um pixel enviar, mas isso tb nao sei se da. Tenho de ver.
Se conseguir implementar um solução como PWM dos timers + DMA em vez do SPI deve dar
-
E porque não fazes o pré-processamento todo num pc, e fazes um delay de 1 frame entre o real e o que sai para o teu monitor?
Assim sincronizas os leds com o video.
Estás a fazer algo estilo ambilight?
-
é +- isso. O problema é tb nao saber controlar bem a saida VGA da minha GPU.
Agora que penso nisso, eu ia descartar alguns dos pixeis na resoluçã 1024x768 para se adequar à dos LEDs... assim ha tempo entre pixeis para enviar.
Hum...
tenho mesmo de meter isto a funcionar com os timers e dma
-
Estás a ter em consideração que o sinal VGA é analógico, certo?
-
Estás a ter em consideração que o sinal VGA é analógico, certo?
yep, tenho um adc de 2Milhoes de sample por segundo. claro que isto será impreciso a essa velocidade mas basta funciona a 60mil por segundo
-
640x480*60Hz tem "um pixel clock" de 25.175 MHz, e são 3 canais que tens de samplar (RGB) mais trigger nos sincronismos.
http://tinyvga.com/vga-timing/640x480@60Hz (http://tinyvga.com/vga-timing/640x480@60Hz)
2Msps não dá para nada neste caso. Já experimentaste capturar uma frame como "proof of concept"?
Video é filho da mãe de processar, por isso é que há ICs específicos para captura e geração do mesmo, e quando se quer processamento a sério não é estranho usarem-se FPGAs
-
fiquei com ideia que o VGA envia 3 sinais analogicos a cada H-sync.
http://www-mtl.mit.edu/Courses/6.111/labkit/images/vga_frame.png (http://www-mtl.mit.edu/Courses/6.111/labkit/images/vga_frame.png)
E que a essa resolução que disseste, que se usa 31.469Khz no H-sync
-
sim, envia um sinal analógico a cada h-sinc (31.xxkhz). Esse sinal analógico codifica uma linha horizontal (de onde vem o H). Não é uma tensão analógica fixa, é o valor de brilho nessa cor para cada pixel nessa linha horizontal. Como há intervalos de blanking não é bem 640*31khz (ou a resolução horizontal que for), mas sim mais um bocadinho.
Ora pensa um bocadinho comigo: se o impulsos de sicronismo fossem instântaneos e não ouvesse intervalos de blanking (que era para os CRT ter tempo de fazer o feixe retornar de um lado do ecrã ao outro), tinhamos as seguintes contas para a resolução VGA mais standard de 640x480 a 60Hz de refrescamento:
O refrescamento é 60Hz, logo o V-sync também vai ser 60Hz, porque a imagem é desenhada em linhas horizontais e só depois da imagem toda desenhada é que vais reiniciar(sync) a começar outra vez de cima (vertical). Como nessa frequência vertical vais ter de desenhar 480 linhas, tens de ter um refrescamento horizontal no mínimo de 60Hz * 480 linhas, para dar tempo de desenhar as linhas todas, o que dá 28.8khz (tás a ver como é perto dos 31khz? a diferença é principalmente para o tal blanking).
Falta dividir as linhas em pixeis. Para dar tempo de desenhar os pixeis todos numa linha, a frequência de pixel terá de ser no mínimo 28.8Khz*640 =18.432Mhz. Como já não eram bem os 28.8Khz, e também tens de ter blanking horizontal, dão os tais 25.175Mhz. Continuamos na mesma ordem de grandeza.
No mundo analógico estas frequências não são nada de outro mundo, mas no domínio digital têm que se lhe diga...
Espero que tenha ajudado.
-
Ajudas-te muito. Obrigado.
Sim isso realmente nao tinha entendido entao e é mesmo complicado para o MCU ler isso.
-
640 x 480 x 3 = 921.600 LEDs
Criar um display à base de LEDs é bastante complexo e dispendioso, embora haja quem os faça para locais públicos, não é prático para uso pessoal em que sairá mais caro que uma TV de LEDs.
Quando a saída de vídeo é de uma placa gráfica já fica metade do trabalho resolvido, entretanto iria para os 320x240 dando 230.400 LEDs, isso pode ser feito a metade da velocidade de captura e ignorando linhas intercaladamente (boa altura para tratar da exibição de uma linha de LEDs), deste modo a resolução de saída da placa gráfica até pode ser bem maior se for controlada a captura.
-
Boas,
Independentemente de ser viável ou não penso que estás de parabéns pelo projecto.
Um TIVA fica um pouco "curto" ... mas com um qualquer DSP (a TI tem os KeyStone com cores ARM
e os C6000/C5000) consegues levar esse projecto para a frente na boa, de qualquer forma esse core
é suficiente para pelo menos um mockup de dimensões mais reduzidas.
Abraços,
PA
-
VGA ta de parte. Como isto é para o clube e a ideia é tambem desenvolver conhecimentos talvez arranje alguem mais interessado na area e incluo uma FPGA pequena para fazer a interface VGA <-> UART com a redução de pixeis e tudo ou um RPI. Ora porque isso em vez de por exemplo usar processing? Quero poder ligar qualquer computador por VGA e imprimir a imagem nos LEDs. FPGA para video é algo que o meu departamento usa muito e um dos professores que as vezes peço ajuda é especializado nisso.
Mas por agora vou ter de criar algo para o PC tratar dos dados e enviar por USB.
Como o pessoal quer mesmo que use o ws2812 em vez do 2801, tive a pensar melhor e consigo de forma viavel ter 8 saidas paralelas que conseguem teoricamente 500leds cada. Isto usando DMA ligado a GPIO e controlado por timers. Como tenho 32 canais de DMA, uma carrada de GPIO e 16 timers de 16bits, acho que consigo expandir isto até 32 saidas paralelas. Tenho so de ver como o DMA trata dos stalls
Usar um c5000/c6000 nao me parece viavel por serem tao caros e nao costumar ver muito info sobre eles. Parece mais viavel usar um combo de Tivas, Tiva+RPI ou Tiva+FPGA.
-
Ora entao boas noites ;D
Desde o ultimo post ja fiz muita coisa, ou pelo menos ja aprendi muita coisa, isso de certeza.
Decidi realmente usar os ws2812. E como os controlar? Com as portas digitais. Claro isto envolveria muito uso do processador, por isso que vou usar? DMA.
É a forma que o fadecandy e o teensy controlam os ws2812 com 8 outputs, tendo 8x mais taxa de refrescamento.
Bem eu nao demorei tanto tempo so para decidir como fazer. Ja tenho feito! Pelo menos a parte de controlar o ws2812 a partir dos valores na ram. Ainda falta uma forma de mandar dados do computador para a MCU, tanto o codigo do computador como do receber do MCU.
Ok entao aqui ao meu lado tenho neste momento 8 ws2812 em serie a piscar (so tinha estes) com valores de um random. E com os 8 outputs não? Não! Eu tenho 32 outputs controlados a partir de 4 arrays de varios membros de 1byte.
O unica desvantagem grande que tem em relação ao teensy é o contador do DMA. O do Tiva é apenas de 10bits contra os 15bits do teensy.
O modo que tenho isto a funcionar nao é tão eficiente, necessita de 24*3bytes para controlar 1 ws2812 por cada 8 portas (ou seja ta a controlar 8 ws2812). Com o limite do DMA so poder fazer 1024 transferencias antes de ter de ser re-configurado pelo processador, o DMA so consegue enviar dados para 14 ws2812 por transferencia (14 ws2812 por porta, por isso 32*14). Entao de 14 em 14 Ws2812 tem de rapidamente re-configurar o source address e ligar o DMA. O Tiva que tenho é um ARM-M4 120Mhz logo executa os interrupts muito rapido (ja testei alguns interrupts a re-configurar o SPI e consegui um tempo dentro do interrupt de 400ns e o interrupt nao demora mais de 180nS a fazer push and pop)
Tendo 256Kb de RAM deixa espaço para controlar muitos LEDs mesmo na forma pouco optimizada que tenho para enviar dados.
TODO:
Protocolo UART para receber dados e actualizar as tabelas.
Programar RPI ou Computador para enviar dados para o controlador
Optimizar o trigger do DMA usando mais perifericos e diminuindo o uso de RAM para 3x menos
Estudar funcionamentos mais complexos de DMA para ultrupassar o limite de 1024 transferencias (talvez Scater-Gather)
Possivelmente anexar um projecto de outro membro que envolva uma FPGA converter dados VGA para UART com a resolução e velocidade apropriada
Deixo-vos um video de quando tinha apenas 8 outputs paralelos, tambem nao tenho ca material para vos mostrar 32 outputs a funcionarao mesmo tempo.
https://www.youtube.com/watch?v=5JMPuKWixjk (https://www.youtube.com/watch?v=5JMPuKWixjk)
-
Já tenho o DMA a funcionar em modo ping-pong. Agora que tenho uma fita de LEDs verifiquei que era mesmo necessário para controlar mais de 14 LEDs
Então aqui esta um exemplo de isto a funcionar com uma fita de 30 LEDs
https://www.youtube.com/watch?v=eeEgYPr_E8o&feature=youtu.be (https://www.youtube.com/watch?v=eeEgYPr_E8o&feature=youtu.be)
-
Bem até agora so tenho metido coisas ou com muito poucos LEDs ou sem controlo de brilho qualquer.
E que tal 60LEDs?
https://www.youtube.com/watch?v=1mJxePD8Wxs (https://www.youtube.com/watch?v=1mJxePD8Wxs)