ASM51

Pessoal, estou enfrentando problemas com a int_rb para realizar o incremento (contagem) de uma variável quando um reed switch é acionado.

Às vezes conta, às vezes não e fica nessa intermitência. O problema só ocorre quando faço a checagem para saber se existe algum dado disponível da serial por software. Ver código abaixo.

Código: Selecionar todos

void main() {
   ...
   while(true) {
      ...
      if (kbhit(TECLADO)) {
         ct = fgetc(TECLADO);
         ...
      }

      if (kbhit(XBEE)) {
         ...
      }
      ...
   }
}


Se eu cometo a parte do if (kbhit(TECLADO)) o incremento da variável passa a funcionar perfeitamente. No proteus tudo é perfeito, mas na vida real dá esse problema.

A porta B está com todos os pinos em uso:
pino RB7 - ICSP
pino RB6 - ICSP
pino RB5 - TX (teclado numérico - max232)
pino RB4 - Reed Switch
pino RB3 - ICSP
pino RB2 - RX (teclado numérico - max232)
pino RB1 - SDA (RTC)
pino RB0 - SCL (RTC)

O código para tratamento da int_rb segue logo abaixo e o debounce do reed switch está sendo feito por software usando o timer0.

Código: Selecionar todos

#int_rb
void trata_int_rb(void) { //rotina para tratar INT_RB
   int stateReed;
   stateReed = input(PIN_B4);
   if (intRbEnabled) {
      t2 = 0;
      intRbEnabled = false;
      if (oldStateReed == 1 && stateReed == 0) { //reed switch fechado
         oldStateReed = 0;
      } else if (oldStateReed == 0 && stateReed == 1) { //reed switch aberto
         oldStateReed = 1;
         cont = cont + 4; //C O N T A D O R
      }
   }
}


Alguma luz?
PS: não estou setando tris, pull etc na porta B.
--
MhagnumDw

Alguma alma com uma ideia por aí?
Alguma configuração nessa porta que eu deva usar?

--
MhagnumDw

mhagnumdw escreveu:...O problema só ocorre quando faço a checagem para saber se existe algum dado disponível da serial por software...

Experimenta limpar o flag de buffer cheio manualmente :

Código: Selecionar todos

void main() {
   ...
   while(true) {
      ...
      if (kbhit(TECLADO)) {
         RCIF = 0; ////////////////////
         ct = fgetc(TECLADO);
         ...
      }

      if (kbhit(XBEE)) {
         ...
      }
      ...
   }
}


+++

andre_teprom,

a stream TECLADO é uma serial por software:
#use rs232(baud=2400, parity=N, xmit=PIN_B5, rcv=PIN_B2, bits=8, stream=TECLADO)

a stream XBEE é uma serial por hardware:
#use rs232(baud=9600, parity=N, xmit=PIN_C6, rcv=PIN_C7, bits=8, stream=XBEE)

O RCIF se referencia a serial por hardware. Correto?

Obs: PIC16F874A

--
MhagnumDw

mhagnumdw,

Pelo jeito você esta usando o compilador CSS que não conheço, mas quando você diz:

O problema só ocorre quando faço a checagem para saber se existe algum dado disponível da serial por software

Será que dentro desta função não deshabilita o bit GIE do registrador INTCON e durante a execução da função você perde os eventos em RB0 ?

Abraço

Andre_Cruz,

sim, estou usando o CCS.

Penso que a função kbhit não desative as interrupções (GIE - INTCON). Caso desativasse, eu conseguiria observar, pois o meu timer0 é usado para gerar uma base de tempo de pooling para 6 displays de 7 segmentos e não observo falha nos displays. O manual do CCS também não menciona que essa função desative/ative uma ou outra interrupção.

Ah, detalhe que esqueci de mencionar: nem precisa ter nada dentro do if (kbhit(TECLADO)) para acontecer o problema.

--
MhagnumDw

talvez precise de pullup. veja no proteus se algum pino as vezes fica cinza. talvez o kbhit trave tudo esperando uma tecla. talvez eu nem precise registrar meu ódio pelo ccs. talvez...
abç

lellis,

RB3, RB6 e RB7 ficam sem estado definido (cinza) no Proteus. São os pinos que estão dedicados para a gravação ICSP. No hardware eles são ligados diretamente a um conector para receber o plug para gravar via ICSP, mas no Proteus eu não os liguei em canto algum.

RB5 não uso, pois não envio nada pro teclado numérico, mas ele fica sempre em nível lógico 1 (vermelho).

Ahh, em testes que venho fazendo, troquei o if (kbhit(TECLADO)) por um if (input(PIN_B2) == 0), fazendo a falhada na contagem diminuir, mas não sanar. Fiz essa troca apenas como teste e pelo fato de que o nível lógico vai de 1 para 0 quando existe um novo dado a ser recebido. Logo em seguida ao if (input(PIN_B2) == 0) coloquei um ct = fgetc(TECLADO).

--
MhagnumDw

lellis,
não tenho como, via software, ativar o pull-up individualmente por pino, então ativei em toda a porta B apenas para testar. O problema continuou o mesmo.

Bom... depois de muitas e muitas tentativas, resolvi mudar a #int_rb (que aparentemente não estava errada) e o tratamento do debounce. Com isso ficou perfeito! Pra quem por ventura venha a ter esse problema, vou deixar aqui como ficou o código.

Código: Selecionar todos

#include <16F874A.h>
#use delay(clock=20000000)
#fuses HS, NOWDT, NOPUT
#use rs232(baud=9600, parity=N, xmit=PIN_C6, rcv=PIN_C7, bits=8, stream=XBEE, ERRORS)
#use rs232(baud=2400, parity=N, xmit=PIN_B5, rcv=PIN_B2, bits=8, stream=TECLADO, ERRORS)
#include <stdlib.h>
...
#int_timer0
void trata_timer0() {
   set_timer0(initTimer0 + get_timer0());
   ...
   ++t2;
}
#int_rb
void trata_int_rb(void) { //rotina para tratar INT_RB
   int porta;
   if (intRbEnabled == 1 && input(PIN_B4) == 0) { //botão pressionado
      t2 = 0;
      intRbEnabled = 0;
   }
   porta = input_b(); //para evitar 'mismatch condition'. Datasheet, pág 44, coluna 2, do PIC16F874A
}
void main() {
   ...
   while(1) {
      if (intRbEnabled == 0 && t2 >= t2Value) { //debounce do reed switch e incremento dos tijolos
         t2 = 0;
         if (input(PIN_B4)) {
            intRbEnabled = 1;
            cont = cont + 4; //C O N T A D O R
         }
      }
   
      if (kbhit(TECLADO)) {
         ct = fgetc(TECLADO);
       ...
      }
     
      if (kbhit(XBEE)) {
         c = fgetc(XBEE);
       ...
      }
      ...
   }
}


--
MhagnumDw