ASM51

Caros amigos,

Fiz um controle Infrared com dois PIC's (TX e RX), baseado no protocolo SIRC da Sony, utilizando a frequência de 38KHz para a portadora do Transmissor e PWM por software.
Testei com dois PIC's 16F628A e funcionou mais ou menos, por isso, resolvi pedir ajuda dos amigos aqui do fórum para as seguintes questões:

1) Com os PIC's 16F628A hora os LEDs no receptor são acionados e outras vezes não, ou seja, fica intermitente. Minha dúvida é a seguinte será que pode ser o Receptor Infrared TSOP1738 que está sem o Shield e está recebendo alguma interferência da luz solar ou não tem nada haver?

2) Outro problema é que não consigo fazer funcionar com o PIC12F675 como transmissor (PWM por software utilizando o mesmo código pro PIC 16F628A). Queria saber onde está o erro no código. Porque não funciona com o PIC 12F.

Abaixo mais detalhes do projeto e uma porção do código fonte (compilador CCS)

Código: Selecionar todos

* BASEADO NO PROTOCOLO SIRC (SONY)
* INTERRUPÇÃO EXTERNA
* BITS DE COMANDO: 8 BITS
* START = 2400US
* BIT "1" = 1200US
* BIT "0" =  600US

ROTINA DE ENVIO DO BIT DE START (MODULADO COM PORTADORA DE 38KHz)
cpp code

void ir_send(unsigned int code)  

unsigned char i = 0;
 
/*------ ENVIO START --------*/    ENVIO PRIMEIRO O BIT DE START PWM POR SOFTWARE 
 
 for (i=0;i<93;i++){
       
       output_high(pin_B3);
       delay_us(9);
       output_low(pin_B3);
       delay_us(2);
}
       delay_us(600);

ROTINA PARA ENVIAR O BIT 0 e o BIT 1 (8 BITS) - MODULADO COM PORTADORA DE 38KHz
cpp code

void ir_send (unsigned int code)  

while ( j < 8 ) {  
 
#bit first = code.0    // associa o bit 0 à variável first
    
  // Transmitimos un 1  
  if (first) {         //Verifica se é 0 ou 1. Se for 1 envia o protocolo relativo ao bit 1
   for (i=0;i<47;i++){
       
       output_high(pin_B3);
       delay_us(9);
       output_low(pin_B3);
       delay_us(2); 
      }
       delay_us(600); 
  }  
    
  

  // Transmitimos un 0  
  else {               //Se for 0 envia o protocolo relativo ao bit 0
   for (i=0;i<23;i++){
       
       output_high(pin_B3);
       delay_us(9);
       output_low(pin_B3);
       delay_us(2); 
 } 
       delay_us(600);
  }  
    
  code >>= 1;          //Desloca os bits para a esquerda
  j++;

_________________________________________________________________

ENVIO DO CÓDIGO DA TECLA PRESSIONADA (8 BITS)
cpp code

while (true){
 
    if (!TECLA1){
      #define code 0b00000001 
      
      ir_send(code);
      j=0;
            
    }
    
    if (!TECLA2){
      #define code 0b00000011
      
      ir_send(code); 
      j=0;
    }

Parabens pela contribuicao

Eu programei a muito tempo atrás usando este protocolo em ASM,aí ficou fácil verificar as temporizações.
Você testou o código com uma TV Sony ou outro aparelho Sony?
Deste modo vai ter garantia que sua temporização esta correta,ainda mais que usando o CCS,você vai ter que utilizar a diretriz FASTIO para poder ter os tempos corretos com os ports.

vtrx escreveu:Eu programei a muito tempo atrás usando este protocolo em ASM,aí ficou fácil verificar as temporizações.
Você testou o código com uma TV Sony ou outro aparelho Sony?
Deste modo vai ter garantia que sua temporização esta correta,ainda mais que usando o CCS,você vai ter que utilizar a diretriz FASTIO para poder ter os tempos corretos com os ports.

Na verdade eu simplifiquei o protocolo e peguei somente a ideia do Protocolo SIRC e as temporizações para os Bits de START, ZERO e UM. Reduzi o protocolo a 8 bits apenas.

Também fiquei pensando nessa questão da temporização e fiz um teste com PWM do PIC16F628A (TX) mas o circuito se comportou de forma instável também (intermitente)

Para gerar um sinal de 38KHz eu configurei o timer 2 do PIC16F628A assim:

Código: Selecionar todos

setup_timer_2(T2_DIV_BY_1,26,1);

Onde 26us é o período atribuído ao registrador PR2 ==> 1/26us = 38Khz

O código no receptor creio que está correto pois pequei de um exemplo que vi num livro em espanhol. Já testei a recepção utilizando interrupção externa e também por meio do módulo CCP, mas acontece a mesma instabilidade.
To desconfiado do Receptor TSOP1738 que está sem o Shield mas não sei se isto pode ser a causa da instabilidade.

No caso do PIC 12F675 acredito ser mesmo um problema de temporização já que estou utilizando PWM por software e aí já viu né, durante a execução do programa a gente tem que considerar os delays envolvidos na execução do código.

Matheus,


Quando se aproveita um programa feito em C de uma família de microcontrolador para outra família mesmo do fabricante, voce tem de considerar no código se todos os registradores estão configurados corretamente, pra saber se o problema está relacionádo á logica do programa, ou apenas da falta de inicialização de algum SFR. O meu palpite, é que pelo fato do PIC12F675 possuir entradas A/D, e a Microchip estabelecer por padrão como ativas na inicialização, voce pode estar esquecendo desse detalhe, e o uC estar interpretando um valor constante de uma entrada digital, desabilitada ( suponho, pois voce não postou o código completo, e não dá pra saber se as entradas TECLA1 e TECLA2 estão no PORTA ).

Outro aspecto a se considerar em se tratando de RF, é que TUDO interfere, e acaba se transformando em antena, dependendo da qualidade do layout da geringonça como um todo, e isso tem de ser investigado também, caso a tese acima não se confirme.

Na verdade eu simplifiquei o protocolo e peguei somente a ideia do Protocolo SIRC e as temporizações para os Bits de START, ZERO e UM. Reduzi o protocolo a 8 bits

Um protocolo não se altera.
Esta lógico que sua instabilidade esta relacionada a como você esta gerando o sinal a ser transmitido pois o receptor é sincronizado,ele decodifica os bits que estão dentro dos 38 Khz.

Com relação ao seu item 1, teste colocando um tubo de papelão de preferência preto vedando luz solar, no receptor. Se ficar estável está ai a resposta.
Não vejo por que não funcionar o mesmo programa na família 12F exceto configuração, frequência interna, direção da porta, pullup, etc. Você está gerando a mesma frequência nos dois chips ?

vtrx escreveu:

Na verdade eu simplifiquei o protocolo e peguei somente a ideia do Protocolo SIRC e as temporizações para os Bits de START, ZERO e UM. Reduzi o protocolo a 8 bits

Um protocolo não se altera.
Esta lógico que sua instabilidade esta relacionada a como você esta gerando o sinal a ser transmitido pois o receptor é sincronizado,ele decodifica os bits que estão dentro dos 38 Khz.

Desculpe, mas é possivel sim. Vc pode simplificar um protocolo e configurá-lo ao seu jeito.Como disse, peguei somente o conceito do protocolo SIRC.
No meu caso eu estou trabalhando apenas com 8 bits e o código no receptor foi ajustado para ler o BIT de START e os 8 bits de comando.
A prova é tanta que o código funcionou no Proteus e está funcionando do protoboard, embora, com um pouco de instabilidade.

Com relação ao seu item 1, teste colocando um tubo de papelão de preferência preto vedando luz solar, no receptor. Se ficar estável está ai a resposta.
Não vejo por que não funcionar o mesmo programa na família 12F exceto configuração, frequência interna, direção da porta, pullup, etc. Você está gerando a mesma frequência nos dois chips ?

Pois eh também não sei porque o mesmo código que funciona com o 16F628A, não funciona no 12F.
A frequência a que vc se refere eh a da portadora? Neste caso a resposta é sim, 38KHz.
Uma coisa que eu estou pensando aqui é que li em algum tópico sobre o 12F perder a calibração do Osc. Interno. Quem sabe não é isso, já que estou trabalhando com Osc. Interno de 4MHz.

A frequência que me refiro é o clock e prescaler nos dois chips (mesmo timer ?), no 16F e no 12F de forma que seu programa resulte nos mesmos 38kHz.
Desconheço essa de perder o valor da calibração. Mais provável o usuário alterar, mesmo sem querer.

Desculpe, mas é possível sim. Vc pode simplificar um protocolo e configurá-lo ao seu jeito

Não disse que era impossível,apenas acho sem utilidade não aproveitar um protocolo tão usado e testado,mas pelas dúvidas que tem,talvez não chegue a uma comunicação viável.

fmatheus escreveu: Uma coisa que eu estou pensando aqui é que li em algum tópico sobre o 12F perder a calibração do Osc. Interno. Quem sabe não é isso, já que estou trabalhando com Osc. Interno de 4MHz.

Tenta gravar em outros PICs do mesmo modelo... Seria difícil que todos apresentassem o mesmo problemas se for realmente isso da calibragem do Oscilador interno...
Ou então:

COMO CALIBRAR A FREQUÊNCIA DO OSCILADOR INTERNO DO PIC 12F675/629 (DIDÁTICO)
Na familia 12F temos um recurso para calibrarmos corretamente a frequência do oscilador interno. Ao ser fabricado e testado, descobre-se qual é o valor correto a ser colocado no registrador ‘OSCCAL’ para que chip oscile exatamente a 4mhz com tolerância de 1%. Este valor é gravado na última posição da flash, ou seja , no enderêço 0x3FF. Pode acontecer de acidentalmente gravarmos sobre este valor de calibração. O resultado é que perdemos a precisão da frequência, ficando díficil trabalhar com certas rotinas, em que o tempo preciso é fundamental. Um exemplo típico é o uso da comunicação serial. A solução está em recalibrar. Mas como fazer isto?
A MicroChip fornece em uma das suas Note Application (AN250) uma maneira de fazer isto. Mas a proposta aqui será um pouco diferente, não necessitando de um preciso gerador de 5khz, mas de um simples frequêncimetro (destes que já vem embutidos na maioria dos multitesters, desde que esteja ‘calibrado’). A proposta é colocar o chip para trabalhar com a ‘PALAVRA DE CONFIGURAÇÃO’ ajustada para ‘oscilador com saída externa de clock’ e monitorar a frequência de saída (pino 3), enquanto aumentamos/reduzimos o valor do registrador ‘OSCCAL’.
...

http://larios.tecnologia.ws/iBlog/archives/2881

Só vai ter como confirmarmos algumas teorias aqui se tiver o código completo pra analizar...

EvandrPic escreveu:

fmatheus escreveu: Uma coisa que eu estou pensando aqui é que li em algum tópico sobre o 12F perder a calibração do Osc. Interno. Quem sabe não é isso, já que estou trabalhando com Osc. Interno de 4MHz.

Tenta gravar em outros PICs do mesmo modelo... Seria difícil que todos apresentassem o mesmo problemas se for realmente isso da calibragem do Oscilador interno...
Ou então:

Ou então:
http://picprojects.org.uk/projects/reca ... struction_

Pessoal,

Essa semana vou ver se consigo fazer novos testes

Vou seguir a sugestão do colega André_Teprom e desabilitar as entradas analógicas do PIC 12F675
Estou aguardando chegar também o novo receptor infrared com o "shield"

Vou atualizando o post assim que for realizando os teste

Fiz um para RC5 usando um AT89S52 tx e rx a pouco tempo, tanto controlando a TV como recebendo do controle remoto, mas vamos as encrencas.

O receptor nunca para de receber a diferença é que quando tem um algo coerente transmitindo ele recebe o código correto, esses receptores tem operacionais internos que acertam o nível de recepção pelo sinal recebido, se o sinal for forte ele aumenta o limiar e fica acima do ruido, o receptor tem que estar preparado para lidar com esse sparks na recepção, quando não tem sinal.

Para recepção da para fazer sem cristal, transmissão eu não faria sem cristal, a não ser que use um Freescale que é mais estável do que Microchip.


Edson