Usart trava... C...

Software e Hardware para uC PIC

Moderadores: andre_luis, 51, guest2003, Renie

Usart trava... C...

Mensagempor evertonsilva » 29 Out 2007 20:07

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.
Avatar do usuário
evertonsilva
Bit
 
Mensagens: 41
Registrado em: 17 Out 2006 13:27
Localização: Rio Claro - SP

Mensagempor xultz » 29 Out 2007 21:24

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.
98% das vezes estou certo, e não estou nem aí pros outros 3%.
Avatar do usuário
xultz
Dword
 
Mensagens: 3001
Registrado em: 13 Out 2006 18:41
Localização: Curitiba

Mensagempor evertonsilva » 30 Out 2007 07:36

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.
Avatar do usuário
evertonsilva
Bit
 
Mensagens: 41
Registrado em: 17 Out 2006 13:27
Localização: Rio Claro - SP

Mensagempor andre_luis » 30 Out 2007 08:37

Código: Selecionar todos
#int_RDA
void RDA_isr( void )
{
if ( kbhit() ) DadoRecebido = getc()                   ;
}
"Por maior que seja o buraco em que você se encontra, relaxe, porque ainda não há terra em cima."
Avatar do usuário
andre_luis
Dword
 
Mensagens: 5447
Registrado em: 11 Out 2006 18:27
Localização: Brasil - RJ

Mensagempor EDSONCAN » 30 Out 2007 09:25

Andre_teprom

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

Edson
EDSONCAN
Word
 
Mensagens: 876
Registrado em: 11 Out 2006 14:11

Mensagempor zielpunkt » 30 Out 2007 10:05

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.
"Talento é mais barato que sal. O que separa a pessoa talentosa da bem-sucedida é muito trabalho duro." [ Stephen King ]
zielpunkt
Byte
 
Mensagens: 376
Registrado em: 12 Out 2006 11:36
Localização: Sao Paulo - SP

Mensagempor evertonsilva » 30 Out 2007 10:10

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!!
Avatar do usuário
evertonsilva
Bit
 
Mensagens: 41
Registrado em: 17 Out 2006 13:27
Localização: Rio Claro - SP

Mensagempor zielpunkt » 30 Out 2007 10:21

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.
"Talento é mais barato que sal. O que separa a pessoa talentosa da bem-sucedida é muito trabalho duro." [ Stephen King ]
zielpunkt
Byte
 
Mensagens: 376
Registrado em: 12 Out 2006 11:36
Localização: Sao Paulo - SP

Mensagempor andre_luis » 30 Out 2007 10:28

EDSONCAN escreveu: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.

+++
"Por maior que seja o buraco em que você se encontra, relaxe, porque ainda não há terra em cima."
Avatar do usuário
andre_luis
Dword
 
Mensagens: 5447
Registrado em: 11 Out 2006 18:27
Localização: Brasil - RJ

Mensagempor evertonsilva » 04 Nov 2007 12:48

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!!
Avatar do usuário
evertonsilva
Bit
 
Mensagens: 41
Registrado em: 17 Out 2006 13:27
Localização: Rio Claro - SP

Mensagempor xultz » 04 Nov 2007 15:22

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).
98% das vezes estou certo, e não estou nem aí pros outros 3%.
Avatar do usuário
xultz
Dword
 
Mensagens: 3001
Registrado em: 13 Out 2006 18:41
Localização: Curitiba

Mensagempor tcpipchip » 04 Nov 2007 21:58

Voce apagou o FLAG de OVERRUN quando o erro ocorre?
Avatar do usuário
tcpipchip
Dword
 
Mensagens: 6560
Registrado em: 11 Out 2006 22:32
Localização: TCPIPCHIPizinho!

Mensagempor evertonsilva » 05 Nov 2007 08:06

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!
Avatar do usuário
evertonsilva
Bit
 
Mensagens: 41
Registrado em: 17 Out 2006 13:27
Localização: Rio Claro - SP

Mensagempor assamaral » 29 Nov 2007 19:50

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.
assamaral
Bit
 
Mensagens: 15
Registrado em: 24 Out 2006 19:51
Localização: Imbé/RS


Voltar para PIC

Quem está online

Usuários navegando neste fórum: Nenhum usuário registrado e 1 visitante

cron

x