ASM51

Cada um dos 2 timers possui 4 canais Captura + 4 canais Comparação.
Uma questão:
Suponho que se existem esses vários canais, deve ser possível controle
de alguns eventos "simultâneos".
Medindo um tempo, gerando um pulso, gerando um delay, gerando outro delay, etc...
Isso é possível já que os registros timer/prescaler são únicos para os
8 canais ?
Alguem pode explicar como funciona isto

Outra questão:
Um mesmo canal pode ser direcionado a pinos diferentes.
É possível iniciar um evento num pino e finalizar em outro e/ou no
mesmo pino ?

Uma questão:
Suponho que se existem esses vários canais, deve ser possível controle
de alguns eventos "simultâneos".
Medindo um tempo, gerando um pulso, gerando um delay, gerando outro delay, etc...

R. Sim, claro que é possível , nada impede que dois Comparadores possuam até valores identicos.

Outra questão:
Um mesmo canal pode ser direcionado a pinos diferentes.
É possível iniciar um evento num pino e finalizar em outro e/ou no
mesmo pino ?

R. Sim . Soft é uma coisa extremamente flexível.
Nada impede que se configure um pino de I/O como entrada
Leia e preserve o valor lido no Acumulador, ou em uma posição da memória RAM e
Configure este mesmo pino de I/O como saida e
Escreva nele o valor anteriormente lido
.

Djalma: Tua resposta foi bem genérica. De qualquer forma grato.
Sobre a 2a. questão, achei no manual do usuário:

When more than one pin is selected
for a Capture input on a single TIMER0/1 channel, the pin with the
lowest Port number is used.
Logo para Captura a resposta é não.

Match Output functionality can be selected
on a number of pins in parallel. It is also possible for example, to have
2 pins selected at the same time so that they provide MAT1.3 function
in parallel.
Logo para Comparação a resposta é sim.
Mas ao que parece é paralelo mesmo, ou seja, mesma operação em
ambos pinos (nada, clear, set, muda), o que na prática parece não ter
muita utilidade.

Permanece a dúvida sobre a primeira questão ...

Renato por incrivel que pareça eu ainda nao precisei usar este recurso
Assim to meio sem ciência pra responder. Mas creio que vc já achou o caminho.

Renato: fica mais fácil de imaginar como isso pode ser usado se você imaginar um exemplo: vamos medir os períodos de 4 sinais diferentes e gerar 4 ondas quadradas de períodos diferentes, basta apenas um dos dois timers funcionando do seguinte modo:

1) o prescaler (PR) ajustado para fornecer um pulso de clock a cada 1us para o contador principal (TC), aquele mesmo que é comum para os 4 canais de captura e os 4 canais de comparação

2) o contador principal (TC) tem 32 bits, portanto só vai virar para zero novamente depois de contar quase 4,3 bilhões de pulsos, o que neste exemplo equivale a quase 4300 segundos, mais de uma hora. Para isso basta que nenhum canal de comparação ou captura resete este contador principal.

3) cada um dos 4 canais de comparação ajustado para complementar o estado de um pino do ARM e gerar uma interrupção. Vamos gerar 4 ondas quadradas de 50% ciclo com períodos diferentes por estes pinos.

4) cada um dos 4 canais de captura disparados por mudança de estado em um pino do ARM, portanto são 4 pinos diferentes. Gerando interrupção também. Vamos usar para medir 4 períodos de 4 sinais diferentes.


Tudo isso funciona ao mesmo tempo, lembrando que a rotina que trata as interrupções é uma única, mas que ela pode ler no registrador IR qual ou quais dentre os 8 eventos ocorreu ou ocorreram, depois escrever "1" no bit correspondente para rearmar para a próxima ocorrência. E para otimizar deveria tratar todos os bits em "1" do IR antes de retornar.
Continuando no exemplo:

Quando um dos 4 canais de comparação detectar que o valor armazenado nele (MR0...MR3) ficou igual ao TC vai disparar a interrupção, além de complementar o respectivo pino. Supondo que MR0 disparou, quando a rotina da interrupção rodar poderá fazer MR0 = MR0 + qtd0, onde qtd0 é um valor (em us) igual à metade do período da onda quadrada que precisa ser gerada no pino. O mesmo vale para quando MR1 a MR3 dispararem a interrupção, para cada um deles o firmware soma um valor diferente, pois os períodos das ondas quadradas são diferentes.
A única preocupação é que a interrupção possa ser chamada e colocar o novo valor em MR0 a MR3 antes de chegar o instante em que o respectivo pino deveria mudar de estado. Veja que mesmo sendo variável o tempo para tratar a interrupção, obteremos uma onda quadrada excelente pois os instantes em que os pinos mudam de estado dependem do hardware. Assim, se garantirmos que a interrupção é chamada e atualiza o MR0 a MR3 em menos de 5 us então podemos gerar freqüências até 100kHz. Claro que estou supondo que existem outras ints mais prioritárias para atender antes, pois caso contrário o ARM7 rodando a 60MHz trata isso em menos de 1us.

Quando qualquer um dos 4 canais de captura for acionado pela mudança de estado no respectivo pino, ele vai armazenar o valor que estava no contador principal (TC) naquele instante e disparar a interrupção. Quando a rotina da interrupção vai tratar este disparo, ela lê o valor que ficou registrado em CR0 a CR3, dependendo de qual foi disparado. Então, para CR0 (por exemplo) basta subtrair deste valor recente o outro valor que a rotina já leu no disparo anterior do CR0 e armazenou em alguma variável, o resultado é a diferença em us entre os dois disparos, portanto o próprio período do sinal que está entrando no pino correspondente ao CR0.
Veja que novamente a precisão só depende o hardware, pois é ele que armazena o valor que estava no TC. Desde que a interrupção seja chamada e trate os dados em um tempo menor que o período dos sinais que estamos medindo.

Excelente Ponce. Muito grato.
Seguindo daí:
Numa aplicação como essa, supondo Capturas assíncronas e Comparação
contínua, o TC passará pelo zero, já que não será indicado resetá-lo.
Assim uma segunda leitura poderá dar um valor menor que a primeira.
Como fazer ?
Basta testar essa ocorrência e somar a segunda leitura com o que faltava para o total da primeira ? (ainda considerando que poderá passar pelo zero mais de uma vez entre um evento e outro ...)

Abçs

Obrigado! De nada, Renato.

Então continuando no mesmo exemplo, temos dois casos:

Caso (1): Os maiores intervalos dos canais de comparação e de captura são menores que o tempo necessário para o contador TC passar duas vezes pelo mesmo valor. Ou seja, os intervalos não ultrapassam pouco menos de 4300 segundos (neste nosso exemplo).
Neste caso nenhuma providência é necessária para levar em conta a passagem por zero. Pode parecer que deveria haver algum tratamento para quando TC passar por zero e "uma segunda leitura poderá dar um valor menor que a primeira", mas não será necessário se as variáveis usadas nos cálculos forem de 32 bits. O resultado da subtração sempre ficará correto mesmo quando subtraindo menor - maior.

Caso (2): Há pelo menos um intervalo maior que o tempo necessário para TC passar duas vezes pelo mesmo valor. Ou mais que duas vezes.
Então o firmware precisa controlar isso. É provável que você precise sacrificar um canal de comparação para o firmware ir contando quantas vezes o TC passou por zero, caso precise medir um intervalo longo com um canal de captura. Se o intervalo longo for apenas para canais de comparação então não vai precisar deste sacrifíco, pois o firmware pode ir reconfigurando o canal para que no instante do MATCH só troque o valor do pino que gera a onda quadrada às vezes, mas sempre gera interrupção. O própria rotina de tratamento da INT reconfigura o comportamento para o próximo MATCH.

Renato:

Djalma: Tua resposta foi bem genérica. De qualquer forma grato.

Sua pergunta também foi bem genérica e eu julguei que fosses um principiante .

Marcos Ponce:

podemos gerar freqüências até 100kHz. Claro que estou supondo que existem outras ints mais prioritárias para atender antes, pois caso contrário o ARM7 rodando a 60MHz trata isso em menos de 1us.

Não fiz cálculo, mas, assim a priore, parece um resultado bem mediocre para um uC de 32 bits .
Com um PIC12Fxxx , dedicado e com clock de 4 MHz eu consigo uma onda quadrada de 250 000 cps* , 4 instruções por ciclo, com Duti Cicle exato de 50% e com resolução de 2 useg.

* Cps e não Hz , pois, a rigor sómente a onda senoidal possui frequência.

Djalma Toledo Rodrigues escreveu:
Não fiz cálculo, mas, assim a priore, parece um resultado bem mediocre para um uC de 32 bits .
Com um PIC12Fxxx , dedicado e com clock de 4 MHz eu consigo uma onda quadrada de 250 000 cps* com Duti Cicle exato de 50% e com resolução de 2 useg.

* Cps e não Hz , pois, a rigor sómente a onda senoidal possui frequência.

Usando a porta PWM, a limitação seria a frequência de clock do pll dividido por 2 (30mhz no exemplo acima), e até onde entendo a resolução seria idêntica ao step do divisor usado pelo periférico do pwm (1/30e06 neste caso), mas o jitter seria baixissimo (inferior ao clock do cristal, que é melhorado pelo retorno do loop do pwm), portanto, assumindo que a resolução corresponda a expectativa, a precisão não seria problema. Quando se pega 30mhz e leva pra fora do µC, pode ser que lá na placa ocorram problemas, mas é outra história.

Já usando o método acima, não parei pra calcular todas as variáveis, mas chutando que a latência de atendimento da FIQ é, no pior caso (hmm assumindo que o handler esteja na RAM e que ela tenha realmente zero wait-states), 29 ciclos, o que dá 0.525 µs a 60mhz se calculei direito, assumindo que dê pra fazer com outros 29 ciclos (incluindo o retorno), daria cerca de 1.05 µs. O jitter neste caso (assumindo que a interrupção seja sempre atendida a tempo) também não conta muito, pois o que importa é tomar a atitude a tempo, já que as comutações são feitas pelos periférios e não pelo handler.

Pois é, como demonstrado acima, para gerar freqüências de MHz neste microcontrolador é preciso que o hardware faça isso sozinho sem depender do firmware cada vez que o pino de saída mude de estado.

Os canais de PWM deste ARM são bem úteis. Se for necessário mais, nos outros timers também dá para configurar de maneira a gerar MHz.

O objetivo do primeiro exemplo era só para mostrar como usar todo o hardware de um timer ao mesmo tempo.

polesapart
Minha postagem anterior foi editada, daria para vc editar esta sua e atualizar o Quote onde esta 500 000 substituir por 250 000

Abraço e obrigado.

Djalma Toledo Rodrigues escreveu:polesapart
Minha postagem anterior foi editada, daria para vc editar esta sua e atualizar o Quote onde esta 500 000 substituir por 250 000

Abraço e obrigado.

Feito. Abraços!

MarcusPonce escreveu:Os canais de PWM deste ARM são bem úteis. Se for necessário mais, nos outros timers também dá para configurar de maneira a gerar MHz.

Até 15 MHz ? http://asm51.eng.br/phpBB/viewtopic.php?t=434

Renato escreveu:

MarcusPonce escreveu:Os canais de PWM deste ARM são bem úteis. Se for necessário mais, nos outros timers também dá para configurar de maneira a gerar MHz.

Até 15 MHz ? http://asm51.eng.br/phpBB/viewtopic.php?t=434

Até PCLK / 2, se o clock principal com o PLL for de 60mhz, pra gerar 15mhz o PCLK precisaria ser 30mhz (divisor setado em 2). Lembrando que por padrão o divisor é 4, o que limitaria em 7,5mhz, mas com o divisor desabilitado (setado em 1) teria o máximo de 30mhz de onda quadrada.

Assumi aqui os lpc mais tradicionais, por que têm os que suportariam >= 70mhz e tem os que tem divisores individuais de clock para os periféricos.

Como o Marcus citou, o periférico PWM é um super-set do periférico timer, muita coisa que dá pra fazer com um, se faz no outro, o PWM até onde lembro só tem mais canais e pinos associados.

Editei:

Só note que os limites acima são pra gerar onda quadrada, qualquer que seja o duty cicle. Pra comutar pinos na mão ou gerar modulações estranhas, valem os limites do post que você citou, pois aí teria que usar a função GPIO e ela é lenta.

Dúvida ainda sobre gerenciamento dos Timers:

Tendo vários canais em uso, na pior hipótese os 4 comparadores e os
4 capture, como posso gerenciar (habilitar/desabilitar) geração de Int
individualmente ?
Tentei desabilitar a Int do Comparador 0 usando reg T0MCR=4, ela
desabilitou, mas quando tento habilitar novamente com T0MCR=3, não
reativa a Int.