Matrizes de leds

[vtrx]

Pessoal,as matrizes do exemplo:

-> Matriz rolante <-

É anodo comum ou catodo?

Estava transcrevendo do ASM para CCS e C18,mas o Proteus não consegue mostrar o resultado direito nos códigos em C (CCS e C18),apenas em ASM.

Não descobrí porque pois o código foi trancrito o mais próximo do ASM para C.

Decidí então montar o Hardware para testar os códigos em C na prática,mas preciso comprar as matrizes.

[aphawk]

Vtrx,

Mudei o clock na simulação para 50 Khz, e quando começou a acender alguma coisa dei um PAUSE, e pelos sinais é ANODO COMUM.

Mas reparei numa coisa, a saída de um 74HC164 só pode fornecer 25 mA de corrente.... se os oito leds acenderem, sobra 3,13 mA apenas para cada Led ! Assim teria de usar matriz de Leds de alto rendimento, e são bem mais caras ( quando se acha né ... ) .

Está faltando os excitadores de corrente ULN qqr coisa, ou vai ficar com pouca luminosidade !

O tempo de refresh de cada coluna é de 85 ms, isto é, cada coluna se acende quase 12 vezes por segundo, e fica acesa apenas durante 1 milisegundo... realmente acho que na prática nem vai dar para perceber ela acesa.

E mesmo assim vai ter um flicker bem grande.

Mas está funcionando, realmente se pudesse colocar uma interface serial ou USB para passar os textos e eles serem gravados numa EEPROM , fica show !

Paulo

[vtrx]

Então Paulo,as temporizações só vão ser ajustadas com o circuito prático montado.

Eu apenas fiz o Proteus mostrar as letras como se fosse real.

Sobre o 74HC164,eu usei o esquema que mais aparece na net,pois é tudo simulado.

Vão montar na prática justamento para usar um PIC 18F2550,com interface USB,para o prpósito que falou,mas a simulação ficou comprometida.

Creio eu que seja limitação do Proteus.

e pelos sinais é ANODO COMUM

Vou procurar em um site essas matrizes.

Minha intenção é postar o código em C (CCS que é mais comum) do circuito usando o 16F628.

[aphawk]

Vtrx,

Ok, vai ter uma boa diversão ainda kkkkk !

Sobre o Proteus, ele suporta o CCS, tem de configurar para ele gerar o arquivo de saída COF. E conforme a temporização que voce gerar para as matrizes, tenha de configurar melhor o modelo dela na simulação (timing), pode ser que ela não acenda na simulação mas acenda na prática...

Se puder, vai reportando a evolução do projeto.

Paulo

[vtrx]

Se puder, vai reportando a evolução do projeto.

Sim claro.

o que achei estranho é que o código em ASM,que é o do link,roda legal na simulação,ja os códigos em C não.

Isso não tem lógica pois as temporizações para a varredura dos displays é feito usando o TIMER,logo tanto em ASM como em C o tempo de varredura é o mesmo,só pode ser algo no Proteus.

Acho que na prática funciona normal pois eu baixei o clock no Proteus para 0.02MHZ e da para ver a varredura formando as letras perfeitamente nos códigos em C.

Foto do código em c CCS:

Foto do código em C C18:

Usando o 18F2550,ficou pior,logo deve ser a simulação ja que o 18F2550 tem muito mais registros que o 16F628,mas usando o 16F628a com CCS ainda tem falhas.

Só montando na prática mesmo.

[aphawk]

Infelizmente eu também já percebí que existem algumas falhas no Proteus, e geralmente estão no modelo daquele microcontrolador.... Já achei um ATMEGA16 que dá pau e um outro modelo que só muda o invólucro funciona perfeitamente !

Uma coisa que funcionou no caso dos AVRs é em vez de carregar o arquivo .hex carregar o arquivo .obj , sempre funciona dessa maneira, e algumas vezes quando carrego o .hex dá uns paus estranhos.....

Veja se não tem alguma dica parecida para os PICs, carregar um arquivo de saída diferente em vez dos .hex. Esse tal de COF, tentou ele ?

Paulo