![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
mshearer
Joined: 12 Jan 2009 Posts: 33
|
rs232 errors |
Posted: Thu Feb 05, 2009 10:04 am |
|
|
Hi, I have a fully working comms program, but there is one part still worrying me.
Although i have:
Code: | #use delay(clock=40000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, parity=O,ERRORS) |
So i know that any transmitted bytes are going to be set to odd parity.
I am not so sure about how to check bytes coming in.
Basically I have
Code: | #include <18f4520.h>
#fuses H4,NOWDT,WDT128,NOPROTECT,NOBROWNOUT,NOPUT,STVREN,DEBUG,NOLVP,WRT,NOWRTB,NOWRTC,NOCPD,NOCPB,NOEBTR,NOEBTRB
#use delay(clock=40000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, parity=O,ERRORS)
#byte reg_RCSTA = 0xFAB
#byte reg_PIR1 = 0xF9E
#bit bit_RCIF = reg_PIR1.5
void main(void)
{
char c =0 ;
while(1)
{
if(bit_RCIF == TRUE)
{
if (kbhit())
{
c = getc();
printf("\r\n%c",c);
printf("::%x",RS232_ERROR);
}
}
}
} |
So each byte comes in and the RS232_ERRORS variable can detect any erorrs in the incoming parity.
My problem is, that it doesn't always give what i think it should
i.e outputs look like
Quote: | t::0
t::0
t::0
y::1
y::0
t::1 |
So changes between certain characters give errors but then eventually setting to being ok.
Of course this error could come from the transmitting buffer, but I'm more suspicious that baud is slightly off, should i worry about the #use rs232() command?
thanks,
Matt |
|
![](templates/subSilver/images/spacer.gif) |
mshearer
Joined: 12 Jan 2009 Posts: 33
|
|
Posted: Thu Feb 05, 2009 11:00 am |
|
|
looks like the getc(); is causing the problem. Reading straight from the register works fine. Should have known better |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Thu Feb 05, 2009 11:21 am |
|
|
First, check your clock really is the speed you expect. Just use a simple program to pulse a line high for one second, then low for one seccond. Time ten cycles with a stopwatch. If it oes measure at 20 seconds, you have confirmed your clock. If the clock is right, then the baud rate will be within a tiny margin.
Second, a small comment. There is no point at all, in testing RBIF, then using kbhit. Kbhit, tests RBIF. All you are doing, is repeating the same test, and wasting a little tme...
Then, how are the characters being sent?. Are you typing these by hand, one at a time, or using some form of automation to send them?.
Now, you say 'read from the register works fine'. If you do this, you have _no parity support at all_. Key to understand, is that parity in the PIC, is not a hardware supported feature. To generate parity, the UART, is switched to 9bit mode, and the compiler generates/tests parity in software. The same internal bit is used for parity on the outgoing character, and the returning character. To test parity, you _must_ read the RS232_ERRORS bit at effectively the same time as you read the character.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Feb 05, 2009 12:19 pm |
|
|
To see what Ttelmah is talking about, you need to look at the .LST file.
You're just checking RCIF over and over again:
Quote: | .................... while(1)
.................... {
.................... if(bit_RCIF == TRUE)
00CA: BTFSS PIR1.RCIF
00CC: BRA 0100
.................... {
.................... if (kbhit())
00CE: BTFSS PIR1.RCIF
00D0: BRA 0100
.................... {
.................... c = getc();
00D2: BRA 0004
00D4: MOVFF 01,c
getc() code:
0004: BTFSS PIR1.RCIF
0006: BRA 0004
0008: MOVFF RCSTA,rs232_errors
000C: MOVFF RCREG,01
etc. |
|
|
![](templates/subSilver/images/spacer.gif) |
mshearer
Joined: 12 Jan 2009 Posts: 33
|
|
Posted: Fri Feb 06, 2009 4:27 am |
|
|
Hi, thanks both for the replys
I believe the clockspeed is correct, it does measure 20 seconds. How would you fix this problem if it was off though? Set the baud manually instead of using #use RS232() ?
Quite right about RBIF and kbhit, removed
For now i am sending the characters one at a time through a siow.exe but they will eventually be part of a long chain of inputs.
Ah, so RS232_ERRORS only works if you use getc(), that explains why it always remains at 0x00 at present.
I have tried reading the register, then writting code to test the RX9D bit against the number of 1's in each byte. However the RX9D bit seems to have a lag of one byte, therefore making it impossible to determine if the parity is correct for the first byte. |
|
![](templates/subSilver/images/spacer.gif) |
mshearer
Joined: 12 Jan 2009 Posts: 33
|
|
Posted: Fri Feb 06, 2009 4:55 am |
|
|
well figured out the lag.
Stupidly enough i was reading the RX9D bit after reading from the RCREG, therefore clearing the register and reading the wrong RX9D.
might stick with this, and not use getc for now |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|