Usart trava... C...

[evertonsilva]

Boa noite pessoas...

Estou com outro problema... Recebendo numa rs232 vinda de outro aparelho, onde me envia uma string por segundo.

O PIC recebe normalmente até um momento.. nao trava, mas para de receber a string.... n acho o que esta ocorrendo, alguem teve um problema parecido ?

Estou programando em C... posso até mudar para ASM, mas tenho muitos calculos no programa, e fazer isso em ASM eh um tanto "chato"....

Agradeço a atenção!!!! abraços...
Tom.

[xultz]

Cara, se você receber mais de um byte sem tratar ele, o fdp trava. O buffer de recepção do CCS é uma porcaria.
Recomendo que você trate por interrupção, e sempre leia o byte recebido quando entrar na ISR. Eu também já quebrei a cabeça com isso.

[evertonsilva]

xultz, bom dia!

Então... vc resolveu o problema tratando com interrupção ?! Quando recebo a string, o programa passa para outra etapa de calculos, pode ser que antes de voltar a tratar o buffer ele receba mais de uma vez e trava... se ao receber uma string eu desative a recepção e ative ao voltar dos calculos... hum.. vou testar... alguma sugestão !?

Agradeço a atenção!!!!
Abraços.

[andre_luis]

Código: Selecionar todos

#int_RDA
void RDA_isr( void )
{
if ( kbhit() ) DadoRecebido = getc()                   ;
}

[EDSONCAN]

Andre_teprom

Se vc esta recebendo na interrupção para que precisa do kbhit, sempre vai ter dado, ou nao pediria interrupcao?

Edson

[zielpunkt]

Usa " ERRORS" no final da diretiva "#use rs232", que ela libera a bagaça. Também poderia atuar direto nos bits de enable/disable rx da usart, dando um refresh no buffer. Mas isso funciona bem se vc sabe o momento em que vai receber os dados.

O que o andre exemplificou é bom pra receber uma string completa na interrupção, ficando em loop ali mas com algum timeout, até receber o final da string ou dos dados.

Abço.

[evertonsilva]

As vezes programando em asm, p evitar que o recebimento trave por algum motivo, sempre utilizava a instrução:

Código: Selecionar todos

bcf  RCSTA,CREN ;
bsf  RCSTA,CREN ;


colocava antes de iniciar uma nova recepção.. como seria o mesmo em CCS? Ou isso não é uma boa alternativa ?

Zielpunkt... exemplo:

Código: Selecionar todos

#use rs232(baud=9600, xmit=PIN_B2, rcv=PIN_B1, ERRORS)


ficaria tipo assim... ?! Obrigado atenção pessoal!!

[zielpunkt]

Acho que vai bem das duas maneiras, porque "ERRORS" em algum momento faz a mesma coisa que fez em asm, além de sinalizar outras condições da usart. Ao final, se não vai utilizar as flags de erros, pode inserir em asm mesmo e abrir mão do " ERRORS".


Abço.

[andre_luis]

Andre_teprom

Se vc esta recebendo na interrupção para que precisa do kbhit, sempre vai ter dado, ou nao pediria interrupcao?

Edson

Faço isso por um motivo de compatibilidade. Essa função que uso, pode ser usada tanto dentro de uma interrupção como no main, atravez de polling, sem necessidade de alterar o código.

Mas realmente voce está correto. É redundante e pode ser retirada para otimizar velocidade\espaço.

+++

[evertonsilva]

Boa tarde!!

Olha só o que ocorreu... fiz todos os testes, errors, desligar a recepção depois voltar a ligar, e outros mais...

Nada o problema insistiu em aparecer, o pic em questão era o 16f876.
Passei o mesmo programa que fiz no ccs para o mikropascal, nada travou tambem (detalhe, como disse trava apenas o recebimento nao o pic em si).

Peguei o mesmo programa, sem alterar nada, e gravei num 16f877, resultado... funcionou sem problemas, nao travou nenhuma vez.
Alguem ja passou por isso ?!

Bom, problema "resolvido". Mas fiquei incomodado com isso....

Agradeço a todos a atenção!! Valeu mesmo! Abraços!!

[xultz]

Eu só não entendi se você tratou a serial por interrupção também ou não.
Eu tive esse problema até com o fato de conectar e desconectar o cabo, o ruído enganava a usart, e entupia o buffer. Eu tinha um flag, que se estivesse baixo a ISR lia o byte e jogava fora, para tratar esse problema. Depois, quando realmente queria tratar os bytes recebidos, eu siba o flag. O que eu aprendi é que com CCS, serial tem que ser tratada sempre por interrupção.

Uma outra solução jaguara é usar uma usart em firmware (ou seja, na declaração da serial forçar para não usar hardware). Para você receber um byte, tem que fazer pooling para ver se está recebendo um startbit (passou do startbit e não fez o pooling, dançou), dessa maneira não tem buffer, mas tem que fazer um pooling no mínimo 10x mais rápido que a serial (de preferência, por interrupção de timer, o que no fim dá na mesma).

[tcpipchip]

Voce apagou o FLAG de OVERRUN quando o erro ocorre?

[evertonsilva]

Bom dia!
Então xultz, havia tentado por interrupção, sem interrupção... mas o erro continuou no 16f876 (8mhz), quando passei o mesmo programa para o 16f877 (20mhz) o erro ñ ocorreu mais...

Ñ sei se a questão do clock possa alterar algo... ainda estou tentando descobrir o que ocorre, apagar o FLAG de OVERRUN, como tcpipchip
disse... não cheguei a tratar isso, quando coloco ERRORS na configuração em USES, ainda preciso tratar ?

Enfim, estou fazendo mais testes com o 877 que ainda não travou, mas fico meio incomodado com isso.... agradeço mais uma x a atenção !

Abraços!

[assamaral]

Caro Everton,

Faz o seguinte, após o recebimento dos caracteres, antes que a USART trave, limpa e seta o bit "RCSTA", posição "0x18". Não vai te incomodar mais. Isto ocorre porque o buffer de recepção recebe um novo caractere sem que o anterior seja lido.

Sds.