|
|
View previous topic :: View next topic |
Author |
Message |
Oliver Lai
Joined: 12 Dec 2003 Posts: 16
|
RS232 baud rate 57600, receiving by PIC XTL 20MHz, ok? |
Posted: Mon Apr 05, 2004 11:21 pm |
|
|
Hi, I have got a problem:
From a RS232 output, the baud rate is 57600, I can read data from hyperterminal by PC, but had problem with PIC18F452 (XTL: 20MHz).
I code:
#use rs232 (baud=57600, parity=N, xmit=PIN_C6, rcv=PIN_C7)
BYTE x;
void main() {
x = getc()
}
it stuck in the line x = getc();
It seems nothing has been received, is it the baud rate too high? Can anybody tell me the reason?
Thanks a lot,
Oliver |
|
|
ttelmah Guest
|
Re: RS232 baud rate 57600, receiving by PIC XTL 20MHz, ok? |
Posted: Tue Apr 06, 2004 2:19 am |
|
|
Oliver Lai wrote: | Hi, I have got a problem:
From a RS232 output, the baud rate is 57600, I can read data from hyperterminal by PC, but had problem with PIC18F452 (XTL: 20MHz).
I code:
#use rs232 (baud=57600, parity=N, xmit=PIN_C6, rcv=PIN_C7)
BYTE x;
void main() {
x = getc()
}
it stuck in the line x = getc();
It seems nothing has been received, is it the baud rate too high? Can anybody tell me the reason?
Thanks a lot,
Oliver |
I would have expected the chip to receive 'data', but the probability of it being garbage would be high, because of the very large timing error at this baud rate. The fact that it does not see the data at all, suggests that the problem is perhaps in something 'hardware', like your receive buffer.
That having been said, receiving the right data, is less likely. Unfortunately the clock and baud rate you have selected gives a very large timing error (read the MicroChip data sheet for how to calculate this). The error will be about 8%, which is beyond the normally accepted 'max' for reliable reception. I don't know which compiler you have, but latter versions will normally complain about this.
You can solve this problem, by chosing a crystal frequency that is a nicer multiple of the baud rate. The recommended crystals would be either 22118400Hz, or 18432000Hz. This latter crystal s a common part for exactly this reason (a lot of baud rate generators need this type of multiple).
So you probably have two problems to fix. One with the receive hardware, and a second one with the baud rate. Fix the receive hardware one first.
I am assuming that your test program does do more than you show, since what you type, would just receive the garbage, and then sleep.
Best Wishes |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Tue Apr 06, 2004 6:58 am |
|
|
What do you mean by "stuck"?
The only way to get stuck at x=getc() is if there is no start bit. That is pretty independant of baud rate. Getc() will wait forever for that start bit and then grab bits at the next 9 bit intervals and return, even if the bits are garbage. This indicates you have a hardware problem. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
Ttelmah Guest
|
|
Posted: Tue Apr 06, 2004 2:52 pm |
|
|
SherpaDoug wrote: | What do you mean by "stuck"?
The only way to get stuck at x=getc() is if there is no start bit. That is pretty independant of baud rate. Getc() will wait forever for that start bit and then grab bits at the next 9 bit intervals and return, even if the bits are garbage. This indicates you have a hardware problem. |
Exactly.
This is why I think there is a hardware problem, independant of the baud rate problem.
Best Wishes |
|
|
Oliver Lai
Joined: 12 Dec 2003 Posts: 16
|
if it is the hardware problem, why other program works? |
Posted: Tue Apr 06, 2004 3:18 pm |
|
|
I have tried other programs, like ex10 and ex11 (CCS gave example program), it works well. The RS232 can getc() receiving data from key hit.
Any suggestion how can I solve this problem?
I got suggestion from CCS technical support, using:
#use rs232 (baud=57600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
I have tried, the program is stucked on this line now.
Oliver |
|
|
SteveS
Joined: 27 Oct 2003 Posts: 126
|
|
Posted: Wed Apr 07, 2004 7:19 am |
|
|
Shouldn't you be specifying BITS in the #USE RS232 comand? Probably not the problem, but I find it best to be explicit in all my declarations - don't assume defaults.
If it works with examples, what is different with your program? Is it the baud? If so try changing to that baud in the example. Is it something else -try changing that.
- SteveS |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|