RECEPTOR GENERICO FLEX – UM PROGRAMA PARA VARIAS OPÇÕES DE CIRCUITOS INTEGRADOS – COM PIC 12F675/629 (REF126)

Hoje encontramos no mercado, transmissores de controle remoto para portão e alarmes com vários circuitos integrados. Que tal um único código em que pudéssemos optar qual modelo usar?

Analisando as muitas situações de uso para os controles remotos, desejei tentar fazer um programa que atendesse as mais variadas necessidades dos hobistas. Por exemplo: Um artigo é postado para um receptor usando um HT6P20b, com 2 canais. Surge alguém que precisa de 3 canais. Outro hobista deseja um canal invertido. Ainda outro, que a saída seja em modo ‘retenção’ para todos os pinos. Sem falar dos que desejam um pino em modo ‘pulso’ e outros em ‘retenção’. Realmente se torna um pouco ‘enfadonho’, escrever e reescrever os códigos já publicados, com estas simples alterações. Também, em muitas localidades não se encontra determinado integrado usado na montagem, mas existe de outros modelos. Surgiu a ideia de escrever um código em que fosse possível montar nosso receptor a ‘LA CARTE’. Cada hobista escolheria sua opção e marcaria no código. Depois é só compilar e carregar o PIC.

As características desejadas obtidas neste código são estas:

1) Opção de escolher qual integrado do transmissor iremos decodificar. Assim, poderá ser optado pelo ci HT6P20B, PT2262,PT2240B e família HCS 200 …301 (somente em modo fixo, sem usar o HOPPING CODE).
Obs. Apenas um modelo pode ser usado por vez.
2) Opção de escolher de forma individual, se as saídas serão em modo ‘PULSO’ ou ‘RETENÇÃO’.
3) Opção de escolha de forma também individual, se as saídas serão ‘invertidas’ ou ‘normais’.
4) Opção por aprendizado único de todos os botões (para uso em um único aparelho) ou aprendizado individual (para uso com vários aparelhos)
5) Escolher entre o PIC 12f675 ou 629.
6) Escolher carregar um byte de calibração provisório (em situações de perda deste de forma acidental). Os Pics ‘encostados’ , por não funcionarem em programas gerados em compiladores ‘C’, pela falta deste byte de calibração, poderão ser reaproveitados.
7) Possibilidade de mudar quais pinos serão usados, respeitando as limitações para pinos específicos.

Outra necessidade é que fosse em uma linguagem mais ‘usual’ e não no ‘Assembly’, pois muitos tem ‘aversão’, uma genuína ‘idiossincrasia’ só da menção do nome desta nobre linguagem. Dando os primeiros passos na linguagem “C”, portanto, esta foi a linguagem escolhida para este humilde projeto de iniciante. Creio que, para quem já é experiente nesta linguagem, não terá dificuldade em alterar e talvez simplificar as linhas de código. Mas foi o que consegui e portanto, estou compartilhando. Todas sugestões serão bem recebidas, de como fazer de uma forma melhor.

Voltando ao código, foi usado o compilador CCS C para a compilação, podendo ser usado a versão de demonstração. Logo no início do programa, podemos alterar nossas escolhas em ‘Opções do Usuário’, por comentar ou descomentar as linhas relacionadas as opções.
A rotina faz uso da interrupção do Timer 0 a cada 100 microssegundos, para analisar o estado da entrada que tem o sinal do receptor de 433mhz (RFIN, pino 3). Se for ‘0’, irá incrementar o contador ‘LC’ e acionar o flag_L. Depois, quando a entrada ficar ‘1’, irá incrementar o contador ‘HC’. Quando a entrada rfin ficar ‘0’ novamente, será analisado se o contador ‘LC’ estourou um valor máximo, o que indicaria um intervalo grande (pausa entre transmissões) e que servirá de sincronização do sinal. Se o valor de ‘LC’ ficou abaixo do permitido, haverá uma subtração de ‘LC’- ‘HC’, cujo valor do ‘carry’ será deslocado para dentro do buffer de recepção de 3 bytes e resetando ‘LC’, ‘HC’ e o ‘flag_L’, em preparação para um novo bit a ser recebido. Ao final de 24 bits recebidos (ou 64 no HCS) teremos uma recepção completa. Isto será sinalizado por setar o ‘flag_rok’. São feitas 2 recepções para comparar e eliminar erros de transmissão. Depois a rotina procura na memória pelo número transmitido (serial number), se já foi aprendido na memória. Se foi, irá acionar as saídas de acordo com as opções escolhidas pelo usuário. Se não, irá verificar se o botão ‘LEARN’ foi apertado (e o led ‘learn’ deverá estar aceso). No caso de ter sido apertado, será gravado este número recebido na EEprom e apagará o led “LEARN’. Com respeito a recepção do HCS, foi aproveitado apenas parte do serial number (HCS usa 28 bits + 4 botões= 32 bits ou 4 bytes da parte ‘fixa’ + 32 bits ou 3 bytes na parte encriptada, mas são gravados na EEprom apenas 22 bits + 2 bits dos botões). A razão desta decisão foi dar compatibilidade com os outros controles que usam apenas 3 bytes para o serial number.
Atenção: Este programa é de caráter didático apenas, sujeito a bugs ainda não detectados.

Segue o arquivo ‘C’:

RX_GEN_FLEX_C

Segue pasta zipada com os arquivos do projeto (10/11/2013):

arquivos_projeto_c

Segue pasta zipada com os arquivos do projeto ( atualizada em 17/12/2016):

RX_GEN_FLEX__

Segue pasta zipada com os arquivos do projeto, sendo esta uma versão que salva o estado das saídas em retenção na EEprom do pic e retorna no seu reset ( 17/12/2016):

rx_gen_flex__eep.c

E versão (em teste) para ht6p20d também:

RX_GEN_FLEX_4_C

Como a montagem permite muitíssimas combinações de circuitos integrados e modos de operação, ficará evidente porque não tentei fornecer o arquivo Hex. Cada hobista deverá escolher a suas opções e recompilar, para obter o arquivo HEX.
Obs. Ainda não obtive retorno do funcionamento do código para PT2262, sendo testado apenas com o clone do PT2262 deste blog.

Segue os esquemas de 4 sugestões de montagens, onde temos receptores de 1 a 4 canais:

Manuais:
HCS200
PT2262
PT2240b
Pic12F675

Curiosidades:
O rio que teve seu curso invertido
Outros grandes terremotos estão por vir
Será que Deus é o responsável?
Teve um Projeto? O econômico peixe-cofre
Por que a cooperação é essencial
Como poderá manter um conceito equilibrado sobre o dinheiro?
Sou viciado em aparelhos eletrônicos?
20 modos de criar mais tempo
Dengue — uma ameaça crescente
Preservados numa gota dourada
O “mundo perdido” da Bolívia

Outros assuntos:
Um site para você
Como disciplinar seu filho adolescente
Por que eu me corto?
Desempenhem bem o papel de pais
Como fazer seu segundo casamento dar certo
O que acontece quando morremos?
Como criar filhos responsáveis
Como administrar o seu dinheiro
Ensine valores morais a seus filhos
Ensine seus filhos bons principios com atividades de colorir
Como posso ter ânimo para exercitar
Como posso controlar meu peso?
Entrevista com um bioquímico
Adolescentes- O que fazer se estou sofrendo bullying?
Como evitar ferir com palavras?
Como tratar seu cônjuge com respeito?
Perguntas Bíblicas Respondidas

Até o próximo artigo!!!

113 comments on “RECEPTOR GENERICO FLEX – UM PROGRAMA PARA VARIAS OPÇÕES DE CIRCUITOS INTEGRADOS – COM PIC 12F675/629 (REF126)

  1. Boa noite Cláudio. Entendi o funcionamento de gravação e leitura. Fiz no proteus! Você é o cara. Tenho outra dúvida sobre a variável botoes, que aparece assim em seu código como: botoes=buffer[2]; Queria entender o seguinte: Suponha que pressionei um botão do controle chaveirinho e o mesmo enviou a string: C6F06D. Nesse caso, o valor do buffer[2] terá qual valor da string que foi recebida pelo controle? Seria o caractere ‘C’ em binário (1100)? Um abraço.

  2. Nobre Lário, tudo bem?
    Queria tirar mais uma dúvida contigo. Para que serve o comando shift_right(&buffer[0],3,(lc>hc)); Ele rotaciona os bits? Preciso salvar na eeprom, 1 byte antes do sinal do botão e depois ler o valor. Um agrande abraço.

    1. Olá Xuguinho!
      Este comando rotaciona para direita, ‘0’ ou ‘1’, dependendo se ‘lc’ for maior ou menor que ‘hc’. Para salvar um byte pode usar o comando write_eeprom( endereço, byte desejado) e para ler use read_eeprom(endereço).
      Cláudio

  3. Olá Lário. Entendi sua explicação. Ficou bem claro. Experimento: Fiz alguns testes com um controle de 4 botões no padrão HT6P20B. O mesmo repete os últimos bit para os botões 3 e 4. Veja como ficou a leitura de cada botão: botão_1 = 8B6976, botão_2 = 4B6976, botão_3 = 2B6976 e botão_4 = 1B6976. Os botões 3 e 4 acionam as mesmas saídas. veja como ficou o byte de cada botão: botão_3 = 0010 e botão_4 = 0001. Logo temos dois ‘zeros’ nos bits 6 e 7. Consegui resolver isso acrescentando mais um bit (bit 5) na condição IF que estava na dúvida na postagem anterior. Assim, os botões acionaram saídas diferente, pois a lógica comparou 3 bits (001 e 000) ao invés de dois. Você é o cara!!! Outra dúvida: Teria como escolher qual saída poderei acionar ao pressionar um botão? Ex: Se quisesse acionar a saída 4 com o botão 1, ou acionar a saída 4 com o botão 2? Pensei em acrescentar um dip switch para selecionar a saída que quisesse acionar com um botão pressionado. Assim a configuração ficaria gravado na eeprom. Pensei em gravar um número na frete ou no final do código que será gravado na eeprom. Ex: Ao colocar a chave 1 do dip switch na posição ON e pressionar o botão aprender_botão, gravaria a posição da chave mais o código do botão (14B6976). E assim por diante: 24B6976, 34B6976. Um abraço e muito obrigado por compartilhar o conhecimento. 😀

    1. Olá Xuguinho! Com respeito a sua dúvida, pelo que você passou é realmente possível acrescentar uma chave dip, desde que você a acione na ocasião do aprendizado do controle, e fazendo o aprendizado botão por botão. Deverá salvar cada botão não em 3 bytes, mas em 4 bytes (um byte para dizer ‘qual’ canal acionar). A rotina de recepção tem que ser alterada para buscar apenas o endereço do chaveirinho e desprezar o byte de ‘canal’, na hora de comparar mas usa-lo na hora de acionar. Sucesso em seus experimentos!!!
      Cláudio

  4. Olá mestre Lário, tudo bem? Andei estudando um pouco sua obra prima e tive a idéia de tentar traduzir o sinal que é enviado ao módulo ao pressionar um botão. Começei com um controle tipo chaverinho, padrão HT6P20B. Ao pressionar o primeiro botão, recebi no terminal o código C6F06D, sendo o primeiro byte igual a 1100. Ao pressionar o segundo botão, recebi o código 46F06D com o primeiro byte igual a 0100. Por fim, o terceiro botão 86F06D com o primeiro byte igual a 1000. Até aí entendi. No exemplo citado, as saídas ligam quando: A saida_1 = 11, a saida_2 = 01 e a saida 3 = 10. Uma coisa que fiquei na dúvida foi entender para que serve o bit_test(botoes,7))||(bit_test(botoes,6))). A variável ‘botoes’ recebe algum valor do buffer ou sbuffer? Caso sim, quais? O número 6 e 7 representam algum binário do primeiro byte? Para quê eles servem exatamente? Pretendo utilizar um pic16f268a para experimentos e ampliar o número de saídas. Desde já agradeço e um grande abraço.

    1. Olá Xuguinho! Por favor, sem essa de ‘mestre’. Sou apenas um hobista de microcontrolador!!! Quanto a seu raciocínio, ele está correto. A variável ‘botões’ apenas armazena o ultimo byte recebido (buffer[2]), para realizar os testes sobre o estado dos botões, sendo estes os bits 6 e 7. Poderia ter sido feito este teste usando o próprio buffer, mas na rotina de recepção tem a opção ‘aprender todos os botões’ ou ‘aprender único botão’. Quando uso ‘aprender todos os botões eu simplesmente apago estes 2 bits (6 e 7) e gravo na eeprom. Então, tenho que salva-los, para teste posterior, do estado dos botões. Por isso que salvo na variável ‘botões’.
      Não sei se deu para entender.
      Cláudio

  5. Olá Lario. Entendi o que você quis dizer. Pintou uma dúvida ❓ :
    Na condição -> if((bit_test(botoes,7))||(!bit_test(botoes,6))), os bits 6 e 7 se referem à algum valor hexadecimal do código enviado pelo controle (chaveirinho HT6P20B) quando pressionarmos um botão? Ex:F573498

    Um abraço.

    1. Olá Xuguinho!
      Exatamente! Os bits 6 e 7 se referem ao terceiro byte recebido em uma transmissão do protocolo ht6p, sendo os botões esquerdo e direito do controle remoto (”1″ = acionado).
      No seu exemplo seria o ‘F’ que em binario = ‘1111’. Os botões seriam os 2 primeiros ‘1’. Os outros 2 bits fazem parte do endereço fixo do controle (22 bits de endereço fixo.
      Cláudio

Comments are closed.

Back To Top