Hi: I am working on the receive portion of a driver for the TMS320F2812 UART (SCI). The driver is interrupt driven and uses a software FIFO (which I refer to as the "buffer") to enhance the amount of chars that can be received without loss before being read by user code. There is also the 16-byte hardware FIFO which I call the "FIFO". In the case that there is a FIFO overrun, then I know that all of the data yet to be read in both the buffer and the FIFO is still good (no dropped chars). It would be easy to just abandon the last 16 chars received in the FIFO, and inform the user that what's in the buffer was all that was available prior to the error. It would be somewhat more difficult to try to preserve the last 16 FIFO chars as well. Since the FIFO will continue to receive even after an overrun error, to track where the error occurred while still allowing FIFO chars to be streamed into the buffer would require some additional counter and logic. The benefit would be allowing the user to digest all of the chars before the error occurred instead of discarding the 16 chars that were received before the error. Since if an overrun error occurs it is likely that much of what had been sent up to the point of the error will have to be re-sent anyway, is it worth the trouble and added complexity to preserve the last 16 chars? The only reason I can think of is that the device I'm making will have both a command interpretation mode, and a binary block transfer protocol mode. Preserving all FIFO chars might enable responding to a command like "stop" which may have been issued prior to the lost chars. Otherwise, processing this command would have to wait until the program realized the error, reset the UART, and the other side of the link realized what happened, reinitialized communications, and reissued the command. What is typically done in UART drivers with the contents of the hw FIFO when an overrun is detected? Thanks for input! -- Good day! ____________________________________ CRC crobcREMOVETHIS@BOGUSsbcglobal.net NOTE, delete texts: "REMOVETHIS" and "BOGUS" from email address to reply.
Serial driver - abandon FIFO data on error?
Started by ●June 9, 2008
Reply by ●June 9, 20082008-06-09
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
Reply by ●June 9, 20082008-06-09
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.
Reply by ●June 9, 20082008-06-09
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.
Reply by ●June 9, 20082008-06-09
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
Reply by ●June 9, 20082008-06-09
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
Reply by ●June 9, 20082008-06-09
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.
Reply by ●June 9, 20082008-06-09
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.
Reply by ●June 9, 20082008-06-09
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. > > BillThat'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.
Reply by ●June 18, 20082008-06-18
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.
