View previous topic :: View next topic |
Author |
Message |
jjwsei
Joined: 10 Aug 2007 Posts: 2
|
Strange RS232 problem... |
Posted: Tue May 06, 2008 9:52 am |
|
|
I'm using a PICF506 and setting up the following rs232 port:
#include <16F506.h>
#device adc=8
#FUSES NOWDT //No Watch Dog Timer
#FUSES INTRC_IO
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOMCLR //Master Clear pin used for I/O
#FUSES IOSC8 //INTOSC speed 8MHz
#use delay(clock=8000000)
#use rs232(baud=2400,parity=N,xmit=PIN_C4,rcv=PIN_C5,bits=8)
As a simple wiring test I tried running the following:
while(1){
printf("Hello");
delay_ms(500);
}
"Hello" translates to the following ascii byte pattern:
0x48 0x65 0x6C 0x6C 0x6F
But what I actually receive is the following:
0x88 0xC5 0xCC 0xCC 0xCF
I'm not sure what's going on. The hardware checks fine. Any ideas what I should check? Is there a possible compiler issue with this chip?
Any help would be appreciated. |
|
|
Douglas Kennedy
Joined: 07 Sep 2003 Posts: 755 Location: Florida
|
|
Posted: Tue May 06, 2008 11:02 am |
|
|
This may well be a frequency issue. The internal osc is not perfect and maybe off frequency. RS232 is fairly tolerant of timing maybe 5% off and it will still work. I would change the baud rate downward (often is the best to try first) and see if you get "hello". If you do then you have very much established that it was a frequency issue. |
|
|
RLScott
Joined: 10 Jul 2007 Posts: 465
|
Re: Strange RS232 problem... |
Posted: Tue May 06, 2008 3:47 pm |
|
|
Yes, it is strongly suggestive of a timing problem. You will notice that bits 0-4 of each byte are received perfectly. Then bit 5 gets delayed to bit 6 and bit 6 gets delayed to bit 7. Bit 7 is a no-show. This is consistent with the fact that serial data is sent low-order bits first and high-order bits later. So if there is a small timing error, it is more likely that the first few bits would come through OK, but the higher-order bits, being more distant from the start pulse, are more likely to be picked up at the wrong time.
Robert Scott
Real-Time Specialties |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Tue May 06, 2008 8:27 pm |
|
|
Rather than changing the baud rate, since we suspect a clock speed problem, I would change the declared clock speed to represent what is really happening. Try #use delay(clock=7200000) for a clock 10% slow. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
|