Interrupção/Pilha

[MOR_AL]

Olá pessoal!

Estou fazendo um programa para identificar a tecla pressionada de um controle remoto da Philips. O protocolo é o RC6.
Como há possibilidade de ocorrerem diversos erros, devido aos períodos dos pulsos existentes nos códigos enviados pelo controle remoto, tenho que monitorar todos eles. Isso está gerando não um problema, mas o uso não convencional para as interrupções. Explico melhor.
Quando uma tecla for pressionada, ocorre uma interrupção, que vai fazer a monitoração de todos os pulsos enviados pelo controle.
Sei que deve-se deixar o mínimo de tarefas possível dentro da interrupção, mas como estas tarefas necessitam ser tratadas a medida que os pulsos ocorrem, não estou vendo um meio de deixar poucas tarefas dentro da interrupção.
O que estou tentando descobrir é se não há um meio da interrupção identificar a transição no pino, e o tratamento ocorrer fora da interrupção.
Não quero ter que ficar monitorando o estado de uma entrada ou de um bit, para iniciar o tratamento. Quero que a interrupção se encarregue de monitorar e me informar quando ocorre, para que eu trate IMEDIATAMENTE E FORA da interrupção.
Não faço isso sem motivo. O tratamento gera muitas instruções de chamada a subrotinas, que por sua vez chamam outras. Minha preocupação é a de não estourar a pilha (stack).
Algum de vocês já passou por isso e resolveu?
Aguardo comentários.
MOR_AL

[Alesandro F Zagui]

MOR_AL

Ja pensou em utilizar dois uC?

Voce poderia colocar um pic 12F629 só para receber o sinal e enviar o sinal ja tratado para o outro pic.

[tcpipchip]

Eu faco o seguinte: POLLING mas deixo um tempinho a mais pressionado o botao do controle remoto...
No interrupts...
TCPIPCHIP

[MOR_AL]

Olá Alesandro!
Já pensou em utilizar dois uC?
Não gostaria de usar este artifício. A idéia é simplificar ao máximo. De qualquer forma, valeu pela dica!

Olá tcpipchip!
Eu faco o seguinte: POLLING mas deixo um tempinho a mais pressionado o botao do controle remoto...
No interrupts...

Note que a tecla pressionada por mais tempo vai gerando o mesmo código (após algum tempo), porém com a etapa de inicialização alterada em seu "Toggle Bit". A tecla pressionada, de modo normal, faz com que o controle remoto gere um protocolo com três etapas: Header, com 6 bits, com períodos que dependem dos bits, Control, com 8 bits, com períodos iguais e Information, com 8 bits com períodos iguais.
Se eu entendi corretamente, POLLING, seria ficar monitorando. Mas é isso que eu gostaria de evitar.
Vejo uma "saída pela tangente". Pode resolver este problema específico, mas não o problema que gerou este tópico.
Há um período de 2,666ms após o código ser enviado, em que o controle fica sem atividade. É para diferenciar o final do código de uma tecla e o início do código de outra tecla (que inclusive pode ser devido à permanência da mesma tecla pressionada). Durante este intervalo, o uC poderia fazer alguma outra tarefa.
Mas, como eu disse, o problema que gerou este tópico, não foi resolvido.
Será que há algum modo de, armazenar os endereços em outro local de memória, para poupar o Stack?
Ou então. Será que há algum meio de não usar "Pool", deixando a interrupção apenas informar que ela ocorreu, e fazer o tratamento externo à ela?
Grato.
MOR_AL

[RobL]

Se estiver usando uma porta, com interrupção por mudança de estado, para cada transição que chega a ela e garar uma interrupção, a solução vai depender se o chip usado tem velocidade para tal em funcão do número de interrupções e tempo da rotina de tratamento, mesmo esta estando fora da interrupção, pois poderia estourar pelo acúmulo de tarefas (ram cheia de dados a tratar).

O ideal é que estes casos fossem tratados por um periférico, tal como uma uart. A interrupçào seria gerada ao final do head, control, etc e não a cada bit. O byte recebido seria passado para uma Ram e o tratamento ser feito sobre a ram, já fora da interrupção. O periférico ficaria recebendo 6 ou 8 bits sem atrapalhar.

Na linha AVR tem um chip com um periférico para controle remoto, por exemplo, pois muitos já passaram por esta dificuldade com chips com stack por hardware com comprimento fixo. Num pequeno AVR, o stack pode ter o tamanho da RAM, nos menores até 256 chamadas.

Somente como sugestão para pensar, pensei rápido e pode não ter consitência:
Se estiver usando PICs da linha 12F ou 16F tente uma saída através de uma uart ou SPI . Para tal verifique se há como ajustar o baudrate para a velocidade do controle remoto. Alguns micros a uart pode trabalhar com número variáveis de bits entre 5 a 9 bits. Não me recordo se as uarts da MC permitem isso.

[Djalma Toledo Rodrigues]

Sim . claro que há.

Crie um Flag (um bit )

Quando da ocorrencia da Interrupção:

Identifica a origem, Int do Contrôle Remoto ?

Testa Flag se Set (formalidade)
Aborta a interrupção - Sai, pois ainda não concluiu o tratamento
Else
Set Flag , apenas isso. Saí


O Programa em Loop testa esse Flag
após tratamento Clear o Flag
.

[MOR_AL]

RobL.

Você deu uma boa idéia.
Tratar cada transição do sinal na saída do receptor infravermelho (IV) como uma interrupção. Aí o tratamento fica a nível de transição e não a nível do protocolo inteiro.
Quanto à rapidez; se seria suficiente. O tratamento seria quase o mesmo, dentro ou fora da interrupção. Acredito que daria sim.

O ideal é que estes casos fossem tratados por um periférico, .... O periférico ficaria recebendo 6 ou 8 bits sem atrapalhar.

O "tratamento" a que me refiro é o de obter o código da tecla e não o de decidir o que fazer com o código. Para o primeiro já está quase pronto, com quase todo o programa de identificação da tecla, dentro da interrupção. No meu caso, os códigos (são três) são salvos em registros exclusivos, para posteriormente serem enviados a um grupo de 8 leds. O tempo necessário é pequeno e dá fácil para fazer.

Quanto a linha AVR. Seria uma opção. No momento não cogito em estudá-la, porém seria interessante.

Quanto a sua sugestão final, tipo "UART ou SPI". Somente os dois últimos grupos de dados do protocolo é que possuem períodos constantes. Além do mais o código de transmissão é o Manchester, ou seja, a informação está na transição e não no nível lógico.

Djalma.
Se é que eu entendi bem, este flag já existe e é o INTCON, INTF (meu caso de interrupção em RB0).

"O Programa em Loop testa esse Flag após tratamento Clear o Flag"

O problema é o danado do loop (veja nas postagens anteriores).

Acho que para evitar o loop e usar a interrupção, deve-se tentar separar o problema em partes tão pequenas quanto possível, para que o tratamento da interrupção tenda a ficar reduzido.
MOR_AL