Searching \ for '[PIC] UART Framing Error Interrupt' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ints.htm?key=interrupt
Search entire site for: 'UART Framing Error Interrupt'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] UART Framing Error Interrupt'
2010\03\27@072702 by Josh Koffman

face picon face
Hi all. I'm having a bit of trouble verifying if a framing error in
the UART will cause a receive interrupt. I'll likely be using the
18f2420. The datasheet talks about how to clear a framing error, and
it talks about how to enable the receive interrupt flag, but it
doesn't seem to talk about what happens in an error situation.

I've found a few documents on the web that mention framing errors
blocking subsequent interrupts (which makes sense since you need to
clear the interrupt by reading the receive register).

Can anyone help enlighten me?

Thanks!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2010\03\27@075003 by Thomas C Sefranek

flavicon
face
 ----- Original Message -----
 From: Josh Koffman
 To: Microcontroller discussion list - Public.
 Sent: Saturday, March 27, 2010 7:27 AM
 Subject: [PIC] UART Framing Error Interrupt


 Hi all. I'm having a bit of trouble verifying if a framing error in
 the UART will cause a receive interrupt.

 Yes

 I'll likely be using the
 18f2420. The datasheet talks about how to clear a framing error, and
 it talks about how to enable the receive interrupt flag, but it
 doesn't seem to talk about what happens in an error situation.

 I've found a few documents on the web that mention framing errors
 blocking subsequent interrupts (which makes sense since you need to
 clear the interrupt by reading the receive register).

 Can anyone help enlighten me?

 Possibly

 Thanks!

 Josh
 --
 A common mistake that people make when trying to design something
 completely foolproof is to underestimate the ingenuity of complete
 fools.
         -Douglas Adams
 --

2010\03\27@125653 by Harold Hallikainen

face
flavicon
face

> Hi all. I'm having a bit of trouble verifying if a framing error in
> the UART will cause a receive interrupt. I'll likely be using the
> 18f2420. The datasheet talks about how to clear a framing error, and
> it talks about how to enable the receive interrupt flag, but it
> doesn't seem to talk about what happens in an error situation.
>
> I've found a few documents on the web that mention framing errors
> blocking subsequent interrupts (which makes sense since you need to
> clear the interrupt by reading the receive register).
>
> Can anyone help enlighten me?
>
> Thanks!
>
> Josh
> --


When the uart receives a break, a 0x00 shows up in RXREG, the FE bit is
set, and RXIF is set (just like receiving any other character). There is
some discussion of this at
http://www.microchip.com/forums/tm.aspx?m=485444 .

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2010\03\27@174140 by Ruben Jönsson

flavicon
face
A framing error occures when you don't have a stop bit when you are supposed to
have it (a space or high on 5V and low on RS232 i think). That means that you
already have clocked in as many bits as you should to receive a byte and then
you will get a receive interrupt (after the stop bit (should) have been
received).

So, yes - in order to get a framing error you will have the RCIF flag set and
you do get an interrupt if the RCIE, PEIE and GIE are all set.

/Ruben

{Quote hidden}

> -

2010\03\27@183943 by Josh Koffman

face picon face
On Sat, Mar 27, 2010 at 1:22 PM, Harold Hallikainen
<spam_OUTharoldTakeThisOuTspamhallikainen.org> wrote:
> When the uart receives a break, a 0x00 shows up in RXREG, the FE bit is
> set, and RXIF is set (just like receiving any other character). There is
> some discussion of this at
> http://www.microchip.com/forums/tm.aspx?m=485444 .

Hi Harold,

Thanks for the info and the link. Just to double check, that 0x00 that
appears when the interrupt occurs is caused by the break, not the
start code, correct? The next valid byte would be the start code?

As for your link, that's good info to know. There was a response
posted just today actually, I'm curious how this progresses.

I'm writing a new routine for this based on a state machine on the 18f
chips. I haven't done reception for a while and I'd like to update my
library of code.

Thanks!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2010\03\27@184045 by Josh Koffman

face picon face
2010/3/27 Ruben Jönsson <.....rubenKILLspamspam@spam@pp.sbbs.se>:
> A framing error occures when you don't have a stop bit when you are supposed to
> have it (a space or high on 5V and low on RS232 i think). That means that you
> already have clocked in as many bits as you should to receive a byte and then
> you will get a receive interrupt (after the stop bit (should) have been
> received).
>
> So, yes - in order to get a framing error you will have the RCIF flag set and
> you do get an interrupt if the RCIE, PEIE and GIE are all set.

Ok, good to know. I thought that would be how it worked, but I wasn't
really able to find an explanation in the datasheet.

Thanks!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2010\03\28@151305 by Harold Hallikainen

face
flavicon
face

> Thanks for the info and the link. Just to double check, that 0x00 that
> appears when the interrupt occurs is caused by the break, not the
> start code, correct? The next valid byte would be the start code?

Yes, the 00 is in the FIFO from the break. The next byte will be the start
code. On finding FE true, I just read RXREG and throw it out.

>
> As for your link, that's good info to know. There was a response
> posted just today actually, I'm curious how this progresses.

I just updated that post
(http://www.microchip.com/forums/tm.aspx?m=485444). A couple other changes
I made recently to that code is to change the code that calls the ISR from
an "if rxif" to "while rxif". Sometimes by the time the ISR has finished
processing a byte, another on is in the FIFO. This loops until the FIFO is
empty, then exits the ISR. Another change is to put the check of FE only
in state 0, when I'm waiting for break. I had previously watched for an FE
no matter what state the ISR was in. If I found an FE, I'd go to state 1
where I wait for the start code. Because of the FE bit going around the
FIFO, this caused some problems.

I think that code is now good to go. They'll do more testing next week. I
have not worked for that company for 3 years now, but still go back to fix
stuff.

Harold




--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

More... (looser matching)
- Last day of these posts
- In 2010 , 2011 only
- Today
- New search...