beginners problem

[soddemfx]

Hi, im having difficulty recieving and printing hexadecimal numbers using the rs232 protocol. The PIC im using (16C84) recieves data from a device and then prints to a Visual Basic application running on a PC. The PIC waits for the start character from the device 0x80 or 0x81 and then recieves the next two 8 bit hex numbers from the device. It then prints these two to the PC via the serial port.

The problem is that sometimes the PIC decides to add a '1' to the front of the second of the two numbers i.e. instead of:

01101111 (6F)

it will print:

11101111 (EF)

The problem is intermittent, sometimes it does it, sometimes it doesnt... the problem is only with the second of the numbers, the first number is always fine.

here is the code in question:

--------------------------------------------------------------------------------
void compass(void)
{
#use rs232(baud=9600, xmit=PIN_B2, rcv=PIN_B3)

c = 0x00;

output_high(PIN_A0);
output_low(PIN_A1);
output_low(PIN_A2);

while ((c != 0x80) && (c != 0x81))
{
c = getch();
}

a = getch();
b = getch();

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

printf("%x \n", a);

printf("%x \n", b);

return;
}
--------------------------------------------------------------------------------
a, b and c are defined as so:
--------------------------------------------------------------------------------
unsigned int8 a;
unsigned int8 b;
unsigned int8 c;
--------------------------------------------------------------------------------

ive tried defining them as:

int a;
int8 a;
int16 a;
unsigned int a;
unsigned int16;

etc... but it still does the same.

Im using MPLAB with CCS.

Any help would be much appreciated, like ive said - im sure its a beginner style problem, but its driving me mad!

Tom

[SteveS]

Add ERRORS to your #USE RS232 statement and check it each time on inout. Maybe it's getting messed up on the incoming side.

I always try to break the problem down or localize it. Perhaps you can send each received character to a port to verify it's correct. then you know if it's on the receive end or the transmit end.

Try another PC - evidently PCs these days can be off quite a bit on baud.

What is your clock freq? and have you checked that it's correct?

Remember:
"Sometimes it's not what you don't know, but what you know that ain't so"

- SteveS

[SherpaDoug]

This sounds like a marginal baud rate error problem.
The real fix is to see which clock is off and fix it.
If you are using a software UART you could try setting the PIC for 10080 baud or 9120 baud (9600 +/- 5%), or tweak the divisors if it is a hardware UART.
You could also try sending data with two stop bits to give the receiver a little more time to synchronize to the next start bit.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[soddemfx]

Thanks for the advice, ive been playing with it all day... I tried changing the resonator and playing with the baud rates as you suggested. Unfortunately it still produced the same results.

After a lot of fiddling i found out the problem was due to the design of my board. I was trying to recieve the same rs232 data on two PIC's (by sharing a recieve line). Apparantly they didnt like sharing... Ive now changed it so that one PIC 'echoes' the data to the other and it works fine.

My next problem is that when i send 8bit numeric data from one PIC to the other (rs232), it decides to convert it to ASCII as so:

if i send decimal 1 (01 (hex)) it sends it as ASCII '1' which is 00110001 which is hex 31 or decimal 49. How do i stop it from doing this?

Sorry for asking these lame questions...

Tom

[Guest]

[Ttelmah]