ASM51

Boa noite pessoal.

Galera, estou atormentado desde segunda com esse problema.

Estou usando um conversor USB para DB9 e um MAX232 para recebimento de dados pelo PIC16F874A. Como os pinos de UART padrão já estão sendo usados por um xbee, então tive de fazer um serial por software. Da seguinte forma:

Código: Selecionar todos

#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)
#use rs232(baud=2400, parity=N, xmit=PIN_B3, rcv=PIN_B1, bits=8, stream=BALANCA, ERRORS)

O problema é nessa parte do código:

Código: Selecionar todos

      if (kbhit(BALANCA)) {
         caracter_recebido = fgetc(BALANCA);
         fprintf(XBEE, "%c", caracter_recebido);
      }

Eu estou usando o XCTU como terminal para enviar e visualizar os dados. Ao iniciar o sistema tudo parece tranquilo, mas depois de algum tempo dá a doida e o PIC começa a receber da BALANCA sem nada ter sido digitado e o pior é que o envio é intermitente.

Alguém já passou por isso. Alguém tem alguma solução ou sugestão.

Obrigado e até.

Cavalcante,


Um dos grandes problemas da família PIC16 da Microchip é o fato de que há apenas um vetor de interrupção para todos os módulos do microcontrolador ( UART, A/D, Timer, etc... ), o que significa que o compilador terá um grande trabalho para determinar de onde partiu o evento externo - mesmo para os módulos padrão por hardware - e pra piorar, se um dos pinos que você selecionou para o RX não for sensível á interrupção externa ( se não me engano são os RB0, RB4-RB7 ), não vejo como o microcontrolador vá detectar a chagada de um novo caractere, podendo incorretamente associar qualquer um.

Para confirmar essa teoria, desconecte o XBEE e verifica se continua recebendo caracteres aleatórios, pois é nessa entrada aí que está a UART nativa, que possui flag de interrupção.

Para abrir um pouco sua mente para outras opções, sugiro dar uma olhada aqui: UART externa

Outro problema vai acontecer quando VC receber dados de mais de uma porta ao mesmo tempo ou qdo já estiver recebendo o dado de outra porta nestas situações os dados de uma delas não será lido. A melhor saída é procurar um UC com UARTs por HW.

andre_teprom

Como eu iria ler os dados enviados se quando eu uso o XCTU eu leio do xbee que está recebendo dados do xbee da placa?

Na verdade, esse projeto não é meu. Eu só estou adicionando mais uma DB9 para leitura. Os únicos pinos que ficaram livres foram do 2 ao 10, RA0 à RA5 e RE0 à RE2, além do pino 19 que é o RD0 e o pino 36 que é o RB3. O RB1 que eu estou usando atualmente, estava sendo usado por um DS1307, mas eu modifiquei o código para rx. Eu posso usar algum desses livres ou vou ter de começar o projeto com um novo uc?

Até.

icavalcante escreveu:Eu posso usar algum desses livres ou vou ter de começar o projeto com um novo uc?

Pra ser franco, não sei. O fato é que devido ao uC não possuir recurso de HW para lidar com a detecção da transição na entrada, isso vai ser um gargalo para o compilador fazer algum malabarismo, como por exemplo uma pesquisa constante na entrada, que na melhor das hipoteses iria gerar uma sobrecarga no processamento.

andre_teprom

Eu testei sem o xbee e continua dando o mesmo erro.

Eu tentei colocar os dois dispositivos, tanto o teclado como a balança, nos mesmos pinos e usar um protocolo simples para identificar quem está enviando e acontece o mesmo erro. Eu estou usando um conversor USB/DB9 para simular. Será que pode ser isso?

Até.

Sugiro voce ir conectando os dispositivos seriais aos pares, para saber exatamente quem está afetando quem. Como são 3 seriais, também são apenas 3 combinações, duas a duas.

icavalcante escreveu:Eu estou usando um conversor USB/DB9 para simular. Será que pode ser isso?

Acredito que não tanha relação.

putz...é uma dor de cabeça danada para resolver...

Como falou a turma...talvez tenhas que partir para um processador de 4 ou 5 seriais...e faze-lo como device ao teu pic...

01 alternativa seria vc multiplexar (ou demultiplexar) os sinais do tx-rx com hw e fazer o mc decidir de quem quer receber. neste caso, interrupt não deve ser uma boa pedida.

Galera eu consegui resolver +- kkkkkk

O único problema que está acontecendo é que quando eu envio qualquer número inicialmente 80% das vezes sai ".....", mas depois de um tempo com a tecla pressionada aparece tudo corretamente.

A imagem mostra como é:



Alguém sabe por que essa bruxaria está acontecendo? Parece carro velho que tem de pegar depois que o motor esquenta kkkkkk

Pessoal, descobri o erro. Era no timer0. Acho que quando estoura perde algo da leitura.