ASM51

Olá pessoal!

Fiz um circuito receptor de identificação de tecla pressionada por um controle remoto infravermelho (IV) da Philips, com o protocolo RC5. Até aí tudo bem.
Os tempos necessários foram todos obtidos via "perda de tempo". Um contador de instruções, que mantinha o uC ocupado até que tal tempo fosse completado.
Quero que além desta tarefa, o circuito também promova algum tipo de atitude em função da tecla pressionada, sendo que uma delas é o acionamento e controle, do tipo rádio controle (RC). Este tipo de acionamento requer repetibilidade com atualização a cada 20 ms. Aí começaram os problemas. Não posso mais me dar ao luxo de criar tempos com a ocupação integral do uC, uma vez que as atualizações e a identificação de teclas do controle remoto podem ocorrer em instantes conflitantes.
Em função do exposto, alterei a composição dos tempos necessários para a identificação das teclas do controle remoto IV, via interrupções (INT e TIMER0). Esta solução permite que outras tarefas possam ser realizadas enquanto o contador do timer0 estiver sendo atualizado. O trabalho para efetivar esta alteração não foi nada simples, vide http://rapidshare.com/files/299786987/RC5.doc .
Agora estou trabalhando na etapa do lado do acionamento. Uma vez identificada a tecla pressionada, o que fazer?
Há diversas sub-etapas nesta etapa e em cada uma delas, estes conflitos entre a identificação da tecla pressionada e o acionamento, devem ser levados em consideração.
Em vista destes fatos e APÓS os mesmos, veio a pergunta:

Qual das duas seguintes opções seria a mais apropriada?

Opção 1:

Usar apenas um uC para fazer todo o trabalho, incorrendo em tempo demasiado de projeto, porém sem a utilização de um segundo uC (de 8 pinos).

Opção 2:

Usar o uC para o trabalho exclusivo de acionamento, e um segundo uC, de 8 pinos apenas, para a identificação da tecla pressionada. A comunicação entre eles poderia ser a serial e o trabalho de desenvolvimento seria cerca de 1/5 do trabalho da opção1.

Qual é a opinião de vocês?

MOR_AL

Não sei o teu trabalho será remunerdo financeiramente após concluído, ou se é apenas acadêmico, mas no meu ponto de vista devem ser esgotadas as possibilidades de utilização plena no uC. Seja com o uso de componentes mais baratos em conjunto com o uC seja aumentando a velocidade do uC ... um exemplo, se tu precisa utilizar um uC barato de poucos terminais para acionar varios displays 7 segmento, vai utilizar um uC de 40 pinos e trabalhar confortavelmente com um custo maior ... ou utilizar um pic de 20 pinos e multplex??eu partiria para a segunda opção ... no teu caso eu utilzaria 1 uC e exploraria até o tutano do bixin!

_blackmore_ escreveu:Não sei o teu trabalho será remunerdo financeiramente após concluído, ou se é apenas acadêmico (apenas hobby), mas no meu ponto de vista devem ser esgotadas as possibilidades de utilização plena no uC. Seja com o uso de componentes mais baratos em conjunto com o uC seja aumentando a velocidade do uC ... um exemplo, se tu precisa utilizar um uC barato de poucos terminais para acionar varios displays 7 segmento, vai utilizar um uC de 40 pinos e trabalhar confortavelmente com um custo maior ... ou utilizar um pic de 20 pinos e multplex??eu partiria para a segunda opção ... no teu caso eu utilzaria 1 uC e exploraria até o tutano do bixin! (mas mesmo assim, há muitos outros projetinhos na "fila de espera". Utilizar ao máximo o uC significa aumentar em muito o tempo do projeto)

MOR_AL

mas mesmo assim, há muitos outros projetinhos na "fila de espera". Utilizar ao máximo o uC significa aumentar em muito o tempo do projeto

qual o problema de esperar? já não está esperando? já não é para passar o tempo? então faz o tempo passar!!

abrax!

_blackmore_ escreveu:... qual o problema de esperar? já não está esperando? já não é para passar o tempo? então faz o tempo passar!!

abrax!

Hehe!!
MOR_AL

No fim da história que vai ter de decidir é vc mesmo, porem creio que este foi o motivo da invenção das interrupções.

A leitura do controle deve ser a tarefa predominante executada por interrupção, e se tiver alguma outra coisa crítica no seu controle (não todo só alguma coisa mais crítica que perder um comando do controle) amarra com uma interrupção tbem.

brasilma escreveu:No fim da história que vai ter de decidir é vc mesmo (É... Sei disso.), porem creio que este foi o motivo da invenção das interrupções. (Ela permite que o projeto seja viável com menos hardware, mas a um preço de tempo de projeto alto. Daí a minha pergunta. Será que vale a pena?).

A leitura do controle (mais precisamente a recepção do código IV e a atualização dos RC's) deve ser a tarefa predominante executada por interrupção, e se tiver alguma outra coisa crítica no seu controle (não todo só alguma coisa mais crítica que perder um comando do controle) amarra com uma interrupção tbem.

Com um uC de 8 pinos eu poderia detetar e guardar o código da tecla pressionada, enquanto o uC principal faria as atualizações RC e o controle. Logo após este tratamento, o uC principal poderia ler uma porta do uC do receptor IV, e saber se houve tecla pressionada. Caso afirmativo solicitaria o código via serial. Ficaria bem mais simples de se implementar e garantidamente sem interferência entre os dois processos.
Acho que vou optar por essa solução. Além dela ser simples e organizada, a outra possui tantos detalhes que, mesmo após eu já ter testado e funcionado (a parte da recepção IV com interrupções), ainda não há confiança.
Para chegar a funcionar tive que eliminar cada um dos problemas, e isso é que dava trabalho. As vezes você não tem a mínima idéia do que o está causando. Com a segunda opção, o projeto fica mais "limpo" e organizado em tarefas distintas. Qualquer problema pode ser facilmente identificado e seu código corrigido sem ter muito que procurar.

MOR_AL