HEX+UART+CCS+PIC16F877

[Flaviofrc]

Amigos acho que estou desaprendendo,

Preciso enviar uma sequencia de numeros hexadecimais na Stream "x" da UART e simplismente não estou conseguindo.... estou programando em C para CCS. estou usando:

fputs ("1,2,3,4,5,6,7,8,9",x);

porem a saida disso no terminal não é hexadecimal.....

ai usei o seguinte:

fputc(0x01,x);
fputc(0x02,x);
.
.
.
fputc(0x09,x);

porêm dessa maneira no terminal no final da sequancia acontece um sinal sonoro....

Ai eu pergunto tem uma maneira mais facil de enviar essa sequencia de caracteres sem o sinal sonoro no final e uma maneira mais "enxuta" de se escrever isso.....


Desde já agradeço.

[lucastanure]

qual versão do ccs c que vc usa ?
por que voce não usa a função printf:

#use rs232(baud=19200, xmit=PIN_C6, rcv=PIN_C7)
printf(":%x %lx %c",byte1,byte2,byte3);// esse codigo poe na serial, só habilitar

byte1 é impresso em hexa
byte2 é impresso em long hexa
byte3 é em char

[Flaviofrc]

qual versão do ccs c que vc usa ?
por que voce não usa a função printf:

#use rs232(baud=19200, xmit=PIN_C6, rcv=PIN_C7)
printf(":%x %lx %c",byte1,byte2,byte3);// esse codigo poe na serial, só habilitar

byte1 é impresso em hexa
byte2 é impresso em long hexa
byte3 é em char

Respondendo as questões:
Versão: 4.057

a função printf funciona desde que não seja com Stream, com Stream fica assim:

#use rs232(baud=38400,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8,stream=w)
fprintf("%x,0x01,0x58,0x12,0x80,0x91,0x07,0x03,0x01,0x01,0x01,0x89",w);

mas dessa maneira me retorna um erro na compilação:
Erro 130 Stream must be a constant in the valid range....

Como não sei o que é isso eu usei o fputs qe tambem não funcionou como esperado.....

[lucastanure]

#use rs232(baud=19200, xmit=PIN_C6, rcv=PIN_C7, stream = a)
printf(a, "BLABLABLA\n");

[Flaviofrc]

#use rs232(baud=19200, xmit=PIN_C6, rcv=PIN_C7, stream = a)
printf(a, "BLABLABLA\n");

Não funciona para mim, preciso enviar dados em hexadecimal tipo 0x01 0x12...etc....

obrigado

[fabim]

voce vai mandar valores de $00 a $FF ?.

bom não sei se ajudãnha masss..

pega sua função normal de transmição pela RS232..

observa a forma de como ele envia pela serial, em ASM!!!

você vai observar que ele coloca o valor em um FSR, e só sai da função quando este valor zerar, informando que o byte foi enviado..

só fazer uma funçãozinha simples da sua maneira!!

bração
fabim

[zielpunkt]

Bom,

fputs não funciona pq ele envia uma string por meio da stream, e vc que enviar em hex. Sobra o fputc(dado,stream) , que funciona e muito bem. Na verdade vc sempre envia byte a byte. Pra enviar uma sequencia de dados, enfia eles num buffer com tamanho dos dados que quer enviar e utiliza um ponteiro pra selecionar o dado, tudo dentro de um loop controlado (por um caracter final ou por numero de dados). Essa de sinal sonoro, o terminal não está entendendo o controle ASCII 0x07=="bell"?

Abço.

[Sergio38br]

Bom dia a todos,

Flaviofrc, o terminal que vc fala é o hyperterminal?

Vc manda diversos caracteres de controle, possivelmente o terminal deve esta interpretando isto, por isso vc visualiza coisas estranha na tela, inclusive
quando manda o 0x07(bell)(toca um bip no micro)

Sergio

[ze]

se o fputc (mais prático) não funcionar, que tal:

Código: Selecionar todos

char* itoa(unsigned int value, char *string)
{
sprintf(string, "%x", value); //%u,%d, etc
return string;
}

void main(void)
{
char txt[10]; //10 p.ex.
...
...
itoa(0x55,txt);
fputs(txt,....); //não uso fpuc
....
}

(digitei aqui)

[LeandroPIC]

Tem que ver se o Terminal do Windows trata os dados em ASCII ou HEX.

[Flaviofrc]

Já entendi, utilizei o PUTC e funcionou certinho......


Agora me surgiu uma nova duvida, estou monitorando a serial de um PC e esse PC envia de tempos em tempos uma String de caracteres.

Estou com um PIC fazendo a aquisição de caracteres pela serial porem o numero de caraceres muda as vezes e como a função fgetc() aguarda a chegada de um caracter pela serial e o resultado é meio incorreto pois não sei quando começa uma string e quando termina....

Alguem conhece alguma maneira de executar essa aquisição da String independente do numero de caracteres, sei lá.. talvez bolando um time- out ???

Obrigado....

[zielpunkt]

Encapsula os teus dados, tipo #ddddddddd&, onde #=inicio e &=final da string, e d=dados. Qquer maneira, um controle por timeout é fundamental, a partir da recepção do início da string.

Abço.

[Flaviofrc]

Encapsula os teus dados, tipo #ddddddddd&, onde #=inicio e &=final da string, e d=dados. Qquer maneira, um controle por timeout é fundamental, a partir da recepção do início da string.

Abço.

Olá Ziel,

O problema é justamente o timeout, não consigo imaginar essa rotina. Como é feita a detecção do primeiro caracter? é com a função hbhit()? ou tem outra maneira?
Se não for pedir demais um exemplo ajudaria.....

Obrigado

[zielpunkt]

Flávio,

Na recepção de um caracter, indicado pelo kbhit(), você dispara um timer, por exemplo. Se ele estourar antes da recepção do outro caracter, vc identifica e aborta a recepção. Se recebeu o caracter dentro do tempo, vc recarrega o timer e aguarda o próximo caracter. E por ai vai. Dependendo da velocidade da usart, fica fácil determinar um timeout entre caracteres. Um valor de timeout "multiuso" (funciona bem na prática, independente da taxa de rx) pode ser de 100ms.

Tem um exemplo no help do CCS de como receber da usart com timeout, chamado "timed_getc()" , justamente no tópico "KBHIT()" . Dá uma olhada por lá mas, diferente do que eu sugeri - utilizar um timer - ele faz isso dentro de um "big loop" de 500ms. Mas o conceito é o mesmo, ok.

Abço.

[Flaviofrc]

Olá Ziel,

Eu fiz o que vc falou e funcionou em modo experimental, mas encontrei mesmo outro problema que estava tirando meu sono, a comunicação que eu estava tentando "monitorar" parece não seguir a norma UART pois o tempo dos bit é diferente do padrão que conhecemos, para se ter uma idéia o bit start te arpoximadamente 28uS isso da algo em torno de 35714 Bps, velocidade fora do padrão e isso que está me deixando estresado nesse momento, um terminal normal não consegue ler esses bits e mesmo implementando uma comunicação serial por software no PIC com o tempo de bit preciso, alguns bits são lidos incorretamente.

Bem mais isso é um outro problema.....

Valeu....