CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com
rs232 errors

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
mshearer



Joined: 12 Jan 2009
Posts: 33

View user's profile Send private message

rs232 errors
PostPosted: Thu Feb 05, 2009 10:04 am     Reply with quote
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
mshearer



Joined: 12 Jan 2009
Posts: 33

View user's profile Send private message

PostPosted: Thu Feb 05, 2009 11:00 am     Reply with quote
looks like the getc(); is causing the problem. Reading straight from the register works fine. Should have known better
Ttelmah
Guest
PostPosted: Thu Feb 05, 2009 11:21 am     Reply with quote
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
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu Feb 05, 2009 12:19 pm     Reply with quote
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.
mshearer



Joined: 12 Jan 2009
Posts: 33

View user's profile Send private message

PostPosted: Fri Feb 06, 2009 4:27 am     Reply with quote
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 Smile

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.
mshearer



Joined: 12 Jan 2009
Posts: 33

View user's profile Send private message

PostPosted: Fri Feb 06, 2009 4:55 am     Reply with quote
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
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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