terça-feira, 8 de fevereiro de 2022

APERTURE Laboratories


Water Ripple & Still Alive demo



Esquema:


Lado esquerdo Attiny85, suporte ISP funcional.

Lado direito Display com reset temporizado (apr. 0,5ms), linha SDA bidirecional, condensador de 330pF ao gnd na linha SCK, para eliminar interferências parasitas quando da leitura da memória interna do display (GRAM).

Também lado direito a memória flash 2MB, CS temporizado (apr. 500ms).

A leitura da memória é efetuada quando CS está low, infelizmente toda a vez que se vai ler um byte desta memória, tem de se executar a operação de leitura, seguidamente do endereço e só depois se consegue obter o byte pretendido. Para colmatar o abandono da leitura e atraso significativo (comunicação partilhada com o display), a memória fica activa permanentemente, entretanto separada através de resistências para evitar conflitos.

A entrada de SCK na memória é bloqueada sempre que a linha CS fica LOW (modo display), através de um díodo simples (experimentei um schottky sem sucesso).


Etapa amplificadora de audio:


A frequência PWM é alta (+-800kHZ) e na filtragem basta um simples filtro passa baixo, neste caso por volta de 1kHZ. No amplificador escolhi um IC de baixo ruído extraído de um leitor de CDs para fones. A configuração paralela providencia uma saída de menor impedância, neste caso 8ohms, embora o volume também seja baixo.

O ganho é unitário:


Antes de programar o micro, os fuses devem ser implementados para possibilitar o modo PLL no código, neste caso: 

Low=F1 High=DF Ext=FF

https://www.engbedded.com/fusecalc/

Na configuração, o sinal PLL é obtido multiplicando por 8 o oscilador interno de 8MHz, resultando em 64MHz; este pode ser usado como clock de sistema após dividido por 4.

Bascom:

'Enable the PLL
 Pllcsr.plle = 1
'Wait for the PLL to lock
While Pllcsr.plock = 0
Wend
'Enable the 64MHz clock  /4=16MHz
Pllcsr.pcke = 1

A calibração do clock interno (8MHz) também é fundamental para se atingir os pretendidos 24MHz, 


Segundo a ficha técnica desta calibração (OSCCAL register), não deve ser alterar acima de 10% o seu valor. No meu caso calibrei 1º para obter 16MHz certos, valor que me deu Osccal=98, para chegar aos 24MHz o valor foi de Oscall=212.

Ldi R24 , 212      '24MHZ
Out Osccal , R24

Embora tenha calibrado para 50%, ainda não verifiquei qualquer falha no seu funcionamento, procurei no entanto o seu limite, e a partir de 223 bloqueia (sem avariar).

Configuração TIMER0 para 11.025Hz:

Config Timer0 = Timer , Prescale = 8 , Clear Timer = 1
Enable Ovf0

O contador segundo esta configuração, dá 11719, entretanto existe algum atraso devido a outros procedimentos e o resultado é aproximado.

Tive dificuldades de obter o sinal PWB em PB4 (OC1B), as informações pela net foram infrutíferas, até que tentei a configuração pelo “Codevision AVR Wizard”:

'----------------------------TIMER 1 PWM
'TCCR1 – Timer/Counter1 Control Register
'CTC1 PWM1A COM1A1 COM1A0 CS13 CS12 CS11 CS10
    Tccr1 = &H1
'GTCCR – General Timer/Counter1 Control Register
'TSM PWM1B COM1B1 COM1B0 FOC1B FOC1A PSR1 PSR0
'    0      1           1             0            0         0       0       0
    Gtccr = &B01100000
'TCNT1 – Timer/Counter1
    Tcnt1 = &H00
    Ocr1a = &H00
    Ocr1b = &H80 ‘Mid
    Ocr1c = &HFF
    Config Portb.4 = Output

O sinal PWM é modelado alterando o registo Ocr1b:
Ocr1b = Value


- Water Ripple -

Não estava previsto, mas resolvi implementar nos 15% de memória ainda disponíveis.

Conheço bem o algoritmo para gerar o efeito fogo no PC, mas este parecia-me mais adequado, com áudio via pwm, nº aleatório.

https://web.archive.org/web/20160418004149/http://freespace.virgin.net/hugo.elias/graphics/x_water.htm

https://thecodingtrain.com/CodingChallenges/102-2d-water-ripple.html

O 2 problemas quando se quer apresentar algum efeito gráfico, são a falta de memória e a velocidade.

O 1º consegui ultrapassar usando a própria memória do display para enviar e receber; configurei em modo de 18bits e todas as informações foram trabalhadas em formato 6 bits x 3canais rgb, difícil mas não impossível.

A velocidade deixou de ser problema quando se faz o processamento em série, ou melhor, cada pixel é calculado de forma igual, independentemente do valor dele.


Outro truque foi de partilhar o local das variáveis, para o efeito “Water dripple” uso 4 arrays de 64bytes, esse espaço é partilhado com variáveis do “Still Alive” através do procedimento “Overlay”, usa exactamente o mesmo endereço mas com nomes diferentes.

.Sei que Bascom não é uma ferramenta de programação muito adoptada, preferem C ou algo parecido; desde miúdo que programo, comecei com QBasic depois Pascal e sempre de olho em C. Não sei porquê mas sempre tive dificuldades em entender C, falha minha, e até assembler me parecia mais confortável de entender… acredito que não depende da linguagem mas sim da forma que se escreve e se entende,  para gerar um código limpo.

A biblioteca de controle do display for completamente alterada, SPI em hardware na maior parte das funções.

A união de Som, Imagem e Texto foi possível via VB6, o sincronismo no seu melhor.





Sem comentários :