| View previous topic :: View next topic |
| Author |
Message |
srikrishna
Joined: 06 Sep 2017
Posts: 82
|
| #USE RS232 directive with ERRORS flag |
 Posted: Wed Oct 11, 2017 7:45 am |
 |
|
| What is the function of #USE RS232 directive with ERRORS flag ? What it ERROR does?? |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Wed Oct 11, 2017 7:56 am |
|
|
Key point is that on the PIC, the hardware UART _will_ become hung, if two characters arrive and are have not been read. At this point it won't respond to anything more even if data arrives. Clearing this requires a special sequence to the UART. When 'ERRORS' is set, any call to getc, will automatically perform this sequence, if the UART is in the hung state.
Now it adds a couple of other things (it actually generates a variable called 'RS232_ERRORS', into which it copies the status register, so you can detect the errors if you require, and also adds the bit in this for 9bit handling if required), but the automatic clearance is the one that 'matters' for most people.
Basically, if using the hardware UART, you _must_ either have the ERRORS code set in #USE RS232, or you need to add your own error handling code to the receive.
Since most people don't do the latter, ERRORS should always be used. |
|
|
srikrishna
Joined: 06 Sep 2017
Posts: 82
|
|
| Posted: Wed Oct 11, 2017 8:32 am |
|
|
| What do you mean by 'if two characters arrive' ?? |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1909
|
|
| Posted: Wed Oct 11, 2017 10:38 am |
|
|
| If whatever is connected to your PIC generates two serial characters and you DON'T extract them from the UART. The UART then enters an error state and stops responding to incoming serial data. |
|
|
guy
Joined: 21 Oct 2005
Posts: 297
|
|
| Posted: Thu Oct 12, 2017 2:29 am |
|
|
Most PIC12 to PIC18 chips have a 2-byte receive buffer and when it becomes full the PIC will stop receiving additional characters until you (the programmer) start reading the characters and emptying the buffer.
To be precise, in addition to the 2-byte buffer there is the register that accepts the incoming data so even if 2.5 bytes were received there isn't an overflow yet. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Thu Oct 12, 2017 10:52 am |
|
|
Most PIC's have just a one byte receive register, plus the shift register.
When the last bit of a second character arrives, at the moment this transfers to the RCREG, the error sets. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Oct 12, 2017 11:02 am |
|
|
What does "most PICs" refer to ? All the 16F or 18F I have ever seen
have a 2-byte receive fifo. Maybe you're thinking of the transmitter. |
|
|
guy
Joined: 21 Oct 2005
Posts: 297
|
|
| Posted: Thu Oct 12, 2017 11:30 am |
|
|
...and what's the story with Dick.Fred... ?  |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Thu Oct 12, 2017 1:54 pm |
|
|
| PCM programmer wrote: | What does "most PICs" refer to ? All the 16F or 18F I have ever seen
have a 2-byte receive fifo. Maybe you're thinking of the transmitter. |
No. I have in the past found that on a lot of PIC's the overrun error bit actually gets set after two bytes are received, not 2.95 as you would expect..... (middle of the stop bit on the third byte).
I was doing some code where because of other interrupts events, the interrupt latency on the RS232 went up, and was puzzled when I hit problems. |
|
|
guy
Joined: 21 Oct 2005
Posts: 297
|
|
| Posted: Fri Oct 13, 2017 12:05 am |
|
|
| Quote: |
I suppose Microchip wanted to be on the safe side and raise the flag even if there is still little room in the receive shift register.
|
Yes. In fact it works very well. If you test the errors flag on the read, you can clear the condition and get two bytes while there is data still being shifted in, and not lose anything. It seems to set as soon as a start bit is received when there are two bytes stored.
It was just my 'expectation' that I has 2 plus seven bits+ of time _before_ the error being flagged, that led to it causing an issue!... 
However it is important, since it means you must have the 'clearing' code present if only 2+bytes can be missed..... |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Fri Oct 13, 2017 3:50 am |
|
|
| Ttelmah wrote: | I have in the past found that on a lot of PIC's the overrun error bit actually gets set after two bytes are received, not 2.95 as you would expect..... (middle of the stop bit on the third byte).
|
Hmm, I'd expect the overrun to fire as soon as a a third character starts to arrive. The reason is simple: there's nowhere to put it and unless space can be made by the code, i.e. something reads one or both of the previosuly buffered characters, the character's toast. Firing early gives the code time and a fighting chance to do something and retain the character, firing on the stop bit means nothing can be done and the character is irretrievably lost. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Fri Oct 13, 2017 7:07 am |
|
|
It is not actually an 'error', till there has been a data loss. Nothing has overflowed. It's just a second character being received.
No 'overrun' has occurred at this point.
If it was called the 'FIFO full' flag I'd agree, but calling it the 'Overrun ERROR flag', does imply that an error should have actually happened.
It also can mislead, since if you assume data has been lost when this is set, you could unnecessarily discard characters.... |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
