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 CCS Technical Support

Framing and Overrun Error on Serial Comm

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



Joined: 29 Dec 2003
Posts: 81

View user's profile Send private message

Framing and Overrun Error on Serial Comm
PostPosted: Mon Jun 28, 2004 5:10 pm     Reply with quote

Hello,

Anyone in the community who can explain the cause and effect of serial framing error and overrun error.

How can I prevent a framing and overrun error ?

What will happend to #int_rda interrupt if framing error and/or overrun error will occur?

How can I add an error traper in my PIC such that it will not hung my interrupt? A sample code snippet will do...

BTW, where is the best way to put this error trapper for framing and overrun error?

I need ur help on this... I plan to use PIC18F1320.

Thnx
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Jun 28, 2004 5:42 pm     Reply with quote

Quote:
How can I prevent a framing and overrun error ?

To prevent framing errors, use the correct baud rate. Make sure it's
accurate. To prevent overrun errors, make sure you read a
character from the USART often enough so that the small internal
fifo doesn't overflow (it's only 2 characters deep). If you are using
an interrupt driven receive fifo, then don't disable interrupts for an
extended period of time.

Quote:
What will happen to #int_rda interrupt if framing error and/or overrun error will occur?

It will lock up unless you clear the error.

Quote:
How can I add an error traper in my PIC such that it will not hung my interrupt? A sample code snippet will do...

Simply add ERRORS to the end of your #use rs232() statement.

Quote:
BTW, where is the best way to put this error trapper for framing and overrun error?

The best place is at the end of your #use rs232 statement.
Like this:
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
chingB



Joined: 29 Dec 2003
Posts: 81

View user's profile Send private message

PostPosted: Mon Jun 28, 2004 5:56 pm     Reply with quote

which is better in handling errors... adding ERRORS at #use rs232() built-in function or by simply using register?

Thnx
Ttelmah
Guest







PostPosted: Tue Jun 29, 2004 6:32 am     Reply with quote

chingB wrote:
which is better in handling errors... adding ERRORS at #use rs232() built-in function or by simply using register?

Thnx

In 'quality', no difference really.
However in 'code size', probably the latter.
As it stands, the 'errors' function, adds an error check to every getc, and then if an error is found, flags it, and clears it. If you want to perform your own code when an error is seen, you then have to test for the flag, and perform your code. Hence the test becomes duplicated when using the errors ability this way.
Also seperately, if for any reason, you disable the receive interrupt, and clear it, then the 'getc' won't be called, so in this case, manual clearing becomes essential.
For users who just want to ensure that the errors are cleared, and are using the I/O in a normal manner, the errors ability is fine (though adds in this case a couple of extra instructions to set the error flag, compared to a simple clear).

Best Wishes
Guest








PostPosted: Tue Jun 29, 2004 5:19 pm     Reply with quote

Ttelmah wrote:
chingB wrote:
which is better in handling errors... adding ERRORS at #use rs232() built-in function or by simply using register?

Thnx

In 'quality', no difference really.
However in 'code size', probably the latter.
As it stands, the 'errors' function, adds an error check to every getc, and then if an error is found, flags it, and clears it. If you want to perform your own code when an error is seen, you then have to test for the flag, and perform your code. Hence the test becomes duplicated when using the errors ability this way.
Also seperately, if for any reason, you disable the receive interrupt, and clear it, then the 'getc' won't be called, so in this case, manual clearing becomes essential.
For users who just want to ensure that the errors are cleared, and are using the I/O in a normal manner, the errors ability is fine (though adds in this case a couple of extra instructions to set the error flag, compared to a simple clear).

Best Wishes


Do you have a sample snippet on using register for handling errors?

thnx
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