Timer LPC2138 ?

[MarcusPonce]

Você está usando o registrador certo para habilitar/desabilitar as interrupções dos Matches, mas pode ser que tenha ocorrido o seguinte:

a) T0MCR bit 0 (MR0I) controla se haverá interrupção quando comparador 0 se igualar ao contador. Você fez T0MCR=4 e portanto desabilitou a interrupção. Mas ao mesmo tempo ativou o bit MR0S.

b) Você testou em seguida se a interrrupção ocorreria quando houvesse o MATCH, mas descobriu que a interrupção realmente não acontece pois estava desabilitada. Porém, o bit MR0S ativado faz com que no instante do MATCH o T0TCR bit 0 vai para 0... o que causa a parada do contador (disable).

c) Fazendo T0MCR = 3 vai habilitar a interrupção, mas sem colocar T0TCR bit 0 novamente em 1 não teremos contagem.

Será que foi isso que aconteceu ?

[Renato]

É verdade (opção C).
Tem que fazer um Enable do Timer (T0TCR=1).

E então surge outra dúvida.
Este Enable sugere que o Timer ficou Disable durante um tempo.
Ou seja, parado.
Sendo isto verdade, se outros processos estiverem em curso neste periférico (captures/compares), serão afetados por essa parada,
ocasionando perda de captura, resultado impreciso de uma captura,
erro numa comparação, etc.
Ou a coisa não é assim ?

[MarcusPonce]

Pois é, o clock parou e portanto a contagem parou... Mas o que dá para entender lendo o "User Manual" do LPC2138 feito pelo fabricante é só isso, ou seja: as outras funções continuam normalmente.
Se for isso mesmo, então enquanto estiver neste estado "disabled" cada pulso de captura vai capturar o mesmo número e as comparações nunca vão chegar a dar "igual", pois o contador fica parado no mesmo número.

[Renato]

Fiz um teste usando 2 canais Compare, cada um gerando um sinal externo.
Concluí que o TxTCR=0 realmente para tudo.
Então deve existir uma outra maneira de bloquear uma fonte de Int
momentaneamente.

Outra questão:
Neste teste também tentei gerar sinais com diferentes tempos.
Daí setando o bit 1 do TxMCR ele reseta o contador do timer.
Sendo assim o canal com valor maior de contagem não é alcançado.
Resultado é sinal gerado somente num canal.
Por outro lado, se não resetar, continuará e o Match só haverá
na outra volta.
Então parece que deveria existir um TC para cada canal ...
É claro que esta lógica não me parece muito coerente ... e devo estar
confuso em alguma parte do treco.

No exemplo citado lá no início do tópico pelo Ponce (4 compares + 4 captures no mesmo Timer), entendi que os valores devem ser atualizados
(MRx para Compare) por esse motivo, o que dá um bom trabalho de
soft para administrar por exemplo esses 4 sinais com períodos diferentes.
E no caso de Capture, eventualmente alguma terá que ser ignorada (se o
sistema permitir ...).

[MarcusPonce]

Sobre a interrupção do timer: Cada um dos 4 comparadores tem um bit que habilita a interrupção. Para o comparador 0 é o T0MCR bit 0 (MR0I), basta manipular apenas este bit para habilitar/desativar a interrução.
Deixe o bit que pausa a contagem em 0: MR0S
E deixe o bit que reseta a contagem em 0 também: MR0R
(só para lembrar: cada comparador tem os seus)

Para gerar sinais com tempos diferentes usando dois ou mais comparadores e um TC veja o post que eu coloquei aqui neste assunto mesmo em 22/ago/08. Precisa disparar interrupção quando ocorre um match e no tratamento da interrupção somar uma constante no valor do comparador que gerou a int. E precisa ajustar o hardware para que complemente o valor pino de saída todas as vezes que der um match.

Realmente precisa de várias rotinas de tratamento de interrupção. Captures podem ocorrer com precisão, pois é só o hardware que faz a captura, porém pode ser que você não tenha tempo de guardar o valor da capture antes que seja sobreescrita por outra capture.

Mas aqui é uma questão de bom senso: o ARM rodando a 60MHz é bem rápido e pode gerar sinais de dezenas de kHz sem problema e ainda fazer outras tarefas.
Se necessitar de um sinal de frequência mais alta ele pode ser gerado em outro TC ajustado para fazer só isso e sem usar interrupções.

[Renato]

Sobre performance, para uma idéia comparativa, num LPC2138 :
CCLK= 60 MHz MAMTIM=3 MAMCR=2

O loop abaixo, em C, quanto dá a variável I ?
Variável Flag é setada no atendimento de uma Int do timer Comparador
num intervalo de 104 us (PCLK= 15 MHz T0PR=15 T0MR0=104).

DO
I=0
T0TCR=2
T0TCR=1
DO WHILE Flag=0
I=I+1
LOOP
T0TCR=0

Flag=0
PRINT #0, "DO LOOP :";I

FOR R=1 TO 1000000
NEXT
LOOP

[Renato]

...
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.

Ok. Vi numa AN uma aplicação que subtrai "signed long int" que essa
questão de subtrair menor do maior tem que ser tratada.
a) É 'queimado' um canal match só para resetar o timer quando chegar
em 3FFFFFFFh (limite máximo),
b) ADJUST=40000000h
c) Se TCatual < TCanterior então TCatual = TCatual OR ADJUST

[MarcusPonce]

Não sei se na AN citada havia outro motivo para resetar o contador em 0x3FFFFFFF. Mas mantenho aquilo que eu afirmei. Veja:

No algoritmo que você descreveu, eles efetivamente construíram um contador de 30bits. Para fazer a conta ( menor - maior ) eles detectam esta situação antes da conta e adicionam um bit em 1 na esquerda dos 30 bits (portanto agora terão 31 bits), o qual vai garantir que os 2 bits que não existem na contagem de 30 bits(os mais significativos) sejam 00 no resultado. Ou seja, o algoritmo serve para ajustar bits que não fazem parte da contagem mas existem nas variáveis de 32 bits...

Então usando variáveis unsigned int (32 bits) conseguiríamos fazer as contas corretas com um contador de 32bits, pois:
a) na subtração, o "empresta um" se propaga do bit menos para o bit mais significativo
b) se o contador tem 32 bits e as variáveis também, os bits que ficariam errados por não checar a situação ( menor - maior) estariam à esquerda os 32 bits, portanto não existem...

[Renato]

Ponce:
A tua informação anterior está correta sim.
Apenas acrescentei esta outra possibilidade como troca e
compartilhamento de informações.
A discussão sempre acrescenta alguma coisa.
Num caso desses que as variáveis tem que ser 'signed' este modo é uma
alternativa.
No caso da AN não me detive do porquê as variáveis deviam ser desse
tipo, mas enfim ...
Outro ponto discutido anteriormente é sobre o reg TxTCR, que nessa AN
é usado num determinado canal e influi nos demais canais e seus eventos,
no caso, o reset do timer, estabelecendo o limite de contagem por um
motivo específico.
Isso no meu ponto de vista é uma característica interessante do LPC a ser
gerenciada para um correto uso dos Timers.
Abçs

[MarcusPonce]

Ok, Renato, também sou a favor da trocar de idéias, não estava achando que seu post era outra coisa.
Sempre é interessante conhecermos AN para saber como outros desenvolvedores pensam, no final aprendemos algumas coisas.
Escolhi mal as palavras do meu post, fortes demais... deveria ter escolhido melhor.
Abraços !