Sunday 9 December 2012

What's with the FIFO counter?

What a drama.

On the LPC's UART you are supposed to be able to read a register (FIFOLVL) with a counter that tells you how many bytes are in the Tx FIFO, this is very important because you can use this value to have your code decide not to try and put any more bytes in the FIFO. At this point you may decide to either block until there is room for the next byte or write it to a software buffer.

So far so good. Trouble is the bloody thing doesn't work. Or at least nothing I try can coerce it to reveal the number of bytes in the FIFO.

What to do?

Well the simple way is to always write into the buffer and let the "Tx FIFO empty" interrupt read data from that buffer. But that does introduce some small inefficiencies. Meaning that if you want to quickly blat < 17 bytes out the serial port you can do so without all the enqueueing and dequeueing for those bytes, you can just write them directly into the hardware FIFO. But you need to know that there's room in the FIFO.

Hence my conundrum.

So I've decided to implement my own counter in software, and it looks like it's working well.

Here's a trace of the results of sending 20 bytes to the serialWrite() function.



The centre trace is the output from the UART. The pulses on the top trace are produced for each byte written into the software buffer, and those on the bottom trace are for each byte written into the UART's FIFO.

Because 20 is > 16 four of the bytes are enqueued into the buffer during the serialWrite() function, that's the four pulses on the top trace.

Some time later we get a "FIFO empty" interrupt and the ISR fetches the last four bytes from the buffer and writes them to the FIFO.

Job done.

So a day later and a little wiser am I. I'd still rather get the reading of the hardware counter to work but meanwhile this seems to do the job.

No comments:

Post a Comment