Jim Granville wrote:
> Chris Carlen wrote:
>> Jim Granville wrote:
>>
>>> Chris Carlen wrote:
>>>
>>>>
>>>> What is typically done in UART drivers with the contents of the hw 
>>>> FIFO when an overrun is detected?
>>>
>>>
>>>  My understanding is that the better HW FIFO UART designs have a 
>>> 'wider fifo' that includes the error flags, for each byte. The errata 
>>> I have seen as well, indicates they do not always get the tracking of 
>>> those flags quite right!
>>>
>>>  So, I would say 'best practise' would be to implement a similar SW 
>>> scheme:
>>> slightly more work, but it gives much more info for fault anaylsis, and
>>> as you indicate, works better by discarding less data.
>>
>>
>> I'm not writing a software UART, just a software buffer extension of a 
>> hardware UART with 16-byte FIFO.  When an overrun error occurs, know 
>> that it occured after the 16 bytes in the FIFO.  Any other error (FE, 
>> PE) I have no idea to which character it pertains since it is possible 
>> that I don't get into the interrupt routine until several chars have 
>> been queued.  That is because the RX ISR will need to be preemptable 
>> by other much more time critical interrupts in a real-time controller.
> 
> So, this device has a HW CHAR fifo, but not an HW Flag/error fifo ?
> - seems to have not caught up with the better uart designs... ?


It took me a while to figure out the functionality of two bits in a 
register (the documentation can be a bit vacuous).

Indeed, the F2812 tracks framing and parity errors for each char in the 
FIFO.

There are two bits: SCIRXBUF.SCIFFFE and SCIFFPE which reflect the 
status of the character at the top of the FIFO (the one you are about to 
read from SCIRXBUF.RXDT).

There are also a set of error bits for FE, PE, etc., which just latch 
whenever an error is detected.  I had thought the SCIFFFE and SCIFFPE 
were redundant with these (and wondered why) until I figured out that 
these two track the error status of the top FIFO char.




-- 
Good day!

____________________________________
CRC
crobcREMOVETHIS@BOGUSsbcglobal.net
NOTE, delete texts: "REMOVETHIS" and
"BOGUS" from email address to reply.

Jim Granville wrote:
> Chris Carlen wrote:
>> Jim Granville wrote:
>>
>>> Chris Carlen wrote:
>>>
>>>>
>>>> What is typically done in UART drivers with the contents of the hw 
>>>> FIFO when an overrun is detected?
>>>
>>>
>>>  My understanding is that the better HW FIFO UART designs have a 
>>> 'wider fifo' that includes the error flags, for each byte. The errata 
>>> I have seen as well, indicates they do not always get the tracking of 
>>> those flags quite right!
>>>
>>>  So, I would say 'best practise' would be to implement a similar SW 
>>> scheme:
>>> slightly more work, but it gives much more info for fault anaylsis, and
>>> as you indicate, works better by discarding less data.
>>
>>
>> I'm not writing a software UART, just a software buffer extension of a 
>> hardware UART with 16-byte FIFO.  When an overrun error occurs, know 
>> that it occured after the 16 bytes in the FIFO.  Any other error (FE, 
>> PE) I have no idea to which character it pertains since it is possible 
>> that I don't get into the interrupt routine until several chars have 
>> been queued.  That is because the RX ISR will need to be preemptable 
>> by other much more time critical interrupts in a real-time controller.
> 
> So, this device has a HW CHAR fifo, but not an HW Flag/error fifo ?
> - seems to have not caught up with the better uart designs... ?


It took me a while to figure out the functionality of two bits in a 
register (the documentation can be a bit vacuous).

Indeed, the F2812 tracks framing and parity errors for each char in the 
FIFO.

There are two bits: SCIRXBUF.SCIFFFE and SCIFFPE which reflect the 
status of the character at the top of the FIFO (the one you are about to 
read from SCIRXBUF.RXDT).

There are also a set of error bits for FE, PE, etc., which just latch 
whenever an error is detected.  I had thought the SCIFFFE and SCIFFPE 
were redundant with these (and wondered why) until I figured out that 
these two track the error status of the top FIFO char.




-- 
Good day!

____________________________________
CRC
crobcREMOVETHIS@BOGUSsbcglobal.net
NOTE, delete texts: "REMOVETHIS" and
"BOGUS" from email address to reply.

Bill A. wrote:
> Chris Carlen wrote:
>> Jim Granville wrote:
>>> Chris Carlen wrote:
>>>>
>>>> What is typically done in UART drivers with the contents of the hw
>>>> FIFO when an overrun is detected?
>>>
>>>  My understanding is that the better HW FIFO UART designs have a
>>> 'wider fifo' that includes the error flags, for each byte. The
>>> errata I have seen as well, indicates they do not always get the 
>>> tracking of those
>>> flags quite right!
>>>
>>>  So, I would say 'best practise' would be to implement a similar SW
>>> scheme: slightly more work, but it gives much more info for fault
>>> anaylsis, and as you indicate, works better by discarding less data.
>>
>> I'm not writing a software UART, just a software buffer extension of a
>> hardware UART with 16-byte FIFO.  When an overrun error occurs, know
>> that it occured after the 16 bytes in the FIFO.  Any other error (FE,
>> PE) I have no idea to which character it pertains since it is possible
>> that I don't get into the interrupt routine until several chars have
>> been queued.  That is because the RX ISR will need to be preemptable
>> by other much more time critical interrupts in a real-time controller.
> 
> Assume the buffer is full when it's 16 bytes from actually being full.  
> On overflow, read the 16 bytes from the FIFO into the buffer and report 
> to the user there was an overflow condition and document that all of the 
> data in the buffer is valid up to the point of overflow.
> 
> Bill


That's worth looking into.  Thanks for the input!



-- 
Good day!

____________________________________
CRC
crobcREMOVETHIS@BOGUSsbcglobal.net
NOTE, delete texts: "REMOVETHIS" and
"BOGUS" from email address to reply.

cs_posting@hotmail.com wrote:
> On Jun 9, 5:57 pm, Chris Carlen <crcarleREMOVET...@BOGUSsbcglobal.net>
> wrote:
> 
>>I'm not writing a software UART, just a software buffer extension of a
>>hardware UART with 16-byte FIFO.  When an overrun error occurs, know
>>that it occured after the 16 bytes in the FIFO.  Any other error (FE,
>>PE) I have no idea to which character it pertains since it is possible
>>that I don't get into the interrupt routine until several chars have
>>been queued.  That is because the RX ISR will need to be preemptable by
>>other much more time critical interrupts in a real-time controller.
> 
> I think that you should either design your system such that an over-
> run error is impossible except as a result of a hardware failure
> (insure you will always service the interrupt in time to drain the
> hardware fifo even with the pipe kept full at maximum baud rate), or
> else you should use an acknowledgment protocol and just throw away
> data when an overrun error occurs.

That won't be a problem for the system design, which will be guaranteed 
to not overrun.  But the driver should deal sensibly with trouble 
nonetheless.

Thanks for input.


-- 
Good day!

____________________________________
CRC
crobcREMOVETHIS@BOGUSsbcglobal.net
NOTE, delete texts: "REMOVETHIS" and
"BOGUS" from email address to reply.

Jim Granville wrote:
> Chris Carlen wrote:
>> Jim Granville wrote:
>>
>>> Chris Carlen wrote:
>>>
>>>>
>>>> What is typically done in UART drivers with the contents of the hw 
>>>> FIFO when an overrun is detected?
>>>
>>>
>>>  My understanding is that the better HW FIFO UART designs have a 
>>> 'wider fifo' that includes the error flags, for each byte. The errata 
>>> I have seen as well, indicates they do not always get the tracking of 
>>> those flags quite right!
>>>
>>>  So, I would say 'best practise' would be to implement a similar SW 
>>> scheme:
>>> slightly more work, but it gives much more info for fault anaylsis, and
>>> as you indicate, works better by discarding less data.
>>
>>
>> I'm not writing a software UART, just a software buffer extension of a 
>> hardware UART with 16-byte FIFO.  When an overrun error occurs, know 
>> that it occured after the 16 bytes in the FIFO.  Any other error (FE, 
>> PE) I have no idea to which character it pertains since it is possible 
>> that I don't get into the interrupt routine until several chars have 
>> been queued.  That is because the RX ISR will need to be preemptable 
>> by other much more time critical interrupts in a real-time controller.
> 
> So, this device has a HW CHAR fifo, but not an HW Flag/error fifo ?
> - seems to have not caught up with the better uart designs... ?


So it would seem.


-- 
Good day!

____________________________________
CRC
crobcREMOVETHIS@BOGUSsbcglobal.net
NOTE, delete texts: "REMOVETHIS" and
"BOGUS" from email address to reply.

Chris Carlen wrote:
> Jim Granville wrote:
> 
>> Chris Carlen wrote:
>>
>>>
>>> What is typically done in UART drivers with the contents of the hw 
>>> FIFO when an overrun is detected?
>>
>>
>>  My understanding is that the better HW FIFO UART designs have a 
>> 'wider fifo' that includes the error flags, for each byte. The errata 
>> I have seen as well, indicates they do not always get the tracking of 
>> those flags quite right!
>>
>>  So, I would say 'best practise' would be to implement a similar SW 
>> scheme:
>> slightly more work, but it gives much more info for fault anaylsis, and
>> as you indicate, works better by discarding less data.
> 
> 
> I'm not writing a software UART, just a software buffer extension of a 
> hardware UART with 16-byte FIFO.  When an overrun error occurs, know 
> that it occured after the 16 bytes in the FIFO.  Any other error (FE, 
> PE) I have no idea to which character it pertains since it is possible 
> that I don't get into the interrupt routine until several chars have 
> been queued.  That is because the RX ISR will need to be preemptable by 
> other much more time critical interrupts in a real-time controller.

So, this device has a HW CHAR fifo, but not an HW Flag/error fifo ?
- seems to have not caught up with the better uart designs... ?

-jg

Chris Carlen wrote:
> Jim Granville wrote:
>> Chris Carlen wrote:
>>>
>>> What is typically done in UART drivers with the contents of the hw
>>> FIFO when an overrun is detected?
>>
>>  My understanding is that the better HW FIFO UART designs have a
>> 'wider fifo' that includes the error flags, for each byte. The
>> errata I have seen as well, indicates they do not always get the tracking 
>> of those
>> flags quite right!
>>
>>  So, I would say 'best practise' would be to implement a similar SW
>> scheme: slightly more work, but it gives much more info for fault
>> anaylsis, and as you indicate, works better by discarding less data.
>
> I'm not writing a software UART, just a software buffer extension of a
> hardware UART with 16-byte FIFO.  When an overrun error occurs, know
> that it occured after the 16 bytes in the FIFO.  Any other error (FE,
> PE) I have no idea to which character it pertains since it is possible
> that I don't get into the interrupt routine until several chars have
> been queued.  That is because the RX ISR will need to be preemptable
> by other much more time critical interrupts in a real-time controller.

Assume the buffer is full when it's 16 bytes from actually being full.  On 
overflow, read the 16 bytes from the FIFO into the buffer and report to the 
user there was an overflow condition and document that all of the data in 
the buffer is valid up to the point of overflow.

Bill

On Jun 9, 5:57 pm, Chris Carlen <crcarleREMOVET...@BOGUSsbcglobal.net>
wrote:

> I'm not writing a software UART, just a software buffer extension of a
> hardware UART with 16-byte FIFO.  When an overrun error occurs, know
> that it occured after the 16 bytes in the FIFO.  Any other error (FE,
> PE) I have no idea to which character it pertains since it is possible
> that I don't get into the interrupt routine until several chars have
> been queued.  That is because the RX ISR will need to be preemptable by
> other much more time critical interrupts in a real-time controller.

I think that you should either design your system such that an over-
run error is impossible except as a result of a hardware failure
(insure you will always service the interrupt in time to drain the
hardware fifo even with the pipe kept full at maximum baud rate), or
else you should use an acknowledgment protocol and just throw away
data when an overrun error occurs.

For the former, I'd connect the overrun error flag to some kind of
attention-grabbing message and then hammer the system with trivial
data, interspersed with the most time-consuming commands/messages you
have.

That's of course only testing what valid data over a functioning
signaling scheme can do.  Data framing and timing errors are a whole
other problem.

Jim Granville wrote:
> Chris Carlen wrote:
>>
>> What is typically done in UART drivers with the contents of the hw 
>> FIFO when an overrun is detected?
> 
>  My understanding is that the better HW FIFO UART designs have a 'wider 
> fifo' that includes the error flags, for each byte. The errata I have 
> seen as well, indicates they do not always get the tracking of those 
> flags quite right!
> 
>  So, I would say 'best practise' would be to implement a similar SW scheme:
> slightly more work, but it gives much more info for fault anaylsis, and
> as you indicate, works better by discarding less data.

I'm not writing a software UART, just a software buffer extension of a 
hardware UART with 16-byte FIFO.  When an overrun error occurs, know 
that it occured after the 16 bytes in the FIFO.  Any other error (FE, 
PE) I have no idea to which character it pertains since it is possible 
that I don't get into the interrupt routine until several chars have 
been queued.  That is because the RX ISR will need to be preemptable by 
other much more time critical interrupts in a real-time controller.

>  An easily variable FIFO size, and trigger points, can also help 
> testing/tuning. Skewing the clocks outside spec, can be one way to
> guarantee errors, and tert your error recovery.

Yes.



Thanks for input.


-- 
Good day!

____________________________________
CRC
crobcREMOVETHIS@BOGUSsbcglobal.net
NOTE, delete texts: "REMOVETHIS" and
"BOGUS" from email address to reply.

Chris Carlen wrote:
> 
> What is typically done in UART drivers with the contents of the hw FIFO 
> when an overrun is detected?

  My understanding is that the better HW FIFO UART designs have a 'wider 
fifo' that includes the error flags, for each byte. The errata I have 
seen as well, indicates they do not always get the tracking of those 
flags quite right!

  So, I would say 'best practise' would be to implement a similar SW scheme:
slightly more work, but it gives much more info for fault anaylsis, and
as you indicate, works better by discarding less data.
  An easily variable FIFO size, and trigger points, can also help 
testing/tuning. Skewing the clocks outside spec, can be one way to
guarantee errors, and tert your error recovery.

-jg