This is probably going to have everyone here except my fellow EE/computer geeks going “huh?” but anyway…
I need to run a 16554 in polled mode. The problem I’m running into is that the transmit FIFO doesn’t seem to work properly. The data sheet from EXAR contradicts itself. In one place it says that the THR empty flag in the LSR register will be set if there is at least one FIFO location available. In another place it says that the THR empty flag will be clear if there is at least one byte in the FIFO. Unfortunately, the second one seems accurate.
The problem with this is that now I can’t tell when the FIFO is full. Because this is in polled mode and not interrupt mode, I have to stuff a bunch of characters into the FIFO, then go off and do other things, then come back around and keep stuffing characters into the FIFO so that there are always enough characters going out that the UART will keep transmitting while I’m off doing other things (the device I’m talking to is apparently very picky about having long gaps in between characters).
Is there any way to tell when the FIFO is full through the standard UART registers?
FCR bit 0 is a 1, which according to the data sheet enables the FIFO.
Most people run UARTs in interrupt mode. The UART generates an interrupt when the FIFO is empty, and the interrupt service routine stuffs it full of characters again. Generating interrupts isn’t an option in this application.
Any way you can have it generate the interrupt itself but ignore it on your side, and then read the ISR to check the status of the TXRDY bit? (or read the TXRDY bit itself?) You’d still have to clear the UART’s interrupt, though, so that may not work for you.
Have you tried recalibrating the ICMDE? If you can get it to DJN without much 9IW or RB2 while maintaining BNQ whithin an MEWE enviroment, you might be able to reroute the EUW through the MBNDKNs and IIE the 22BCA.
Page 18/5-46 and 23/5-51 do seem inconsistent. :dubious:
It’s been a while since I’ve done this type of thing… and I only used simple PICs… (and it was just as a hobby)… and my friend did the heavy lifting… but can you just jam stuff in there 'till LSR Bit-1 goes high? (P22/5-50)
Alternately, Page 18/5-46 says “ISR will reflect FIFO status once FIFO trigger level is reached”. You could perhaps set that to full or near-full, and check that while sending.
ISR doesn’t seem to do diddley with interrupts disabled, and as soon as I write to IER to enable interrupts the machine crashes. Grrr.
LSR bit 1 is on the receive side, which works fine. It’s the transmit side that’s giving me fits. Just my luck the device I’m talking to actually cares about pauses in between characters. I haven’t figured out exactly where the threshold is, but it’s less than a 10 ms pause that causes it to drop the packet. The packets vary from about 10 bytes to about 250 bytes, so I can’t just shove them into the FIFO and forget about it either. If I could get the freakin FIFO to work properly that would give me about a 15 ms buffer, which would easily ride through the 10 ms pauses.
Yeah, and if you re-route the power through the deflector grid and reverse the polarity, that just might work, Scotty.
Looking at the data sheet, you should be using LSR BIT 5, if it is equal to 1 (FIFO empty), stuff 16 characters into the TX FIFO. Wait for LSR BIT 5 to return to 1, stuff another 16 characters into the TX FIFO. There doesn’t appear to be a “TX FIFO not full” flag. You could keep track of the space available in the TX FIFO in software, set the count equal to 16 whenever LSR BIT 5 is 0, decrement it after each character is written to the UART. When the count hits zero, stop writing characters to the UART and wait for the TX FIFO to empty.
You could keep track of the space available in the TX FIFO in software, set the count equal to 16 whenever LSR BIT 5 is 1, decrement it after each character is written to the UART. When the count hits zero, stop writing characters to the UART and wait for the TX FIFO to empty.
mks57, I think the problem is he can’t wait until the FIFO is empty, since the receiving end might have a problem if it’s empty for too long. I also don’t see how he could know the count in the FIFO without constantly checking the transmit shift register (and even that seems unreliable).
Have you seen any difference between “mode 0” and “mode 1” (FCR bit 3)? It suggests that TXRDY behaves differently in those cases; maybe the register bits do too.
Have you gotten any information from EXAR about the discrepancy?
He should have one character serialization time to load new data into the TX FIFO and avoid a transmitter underrun after the TX FIFO is emptied. If there is a suitably precise local clock available, the driver could estimate how much free space was available in the TX FIFO by computing the elapsed time since the last time data was loaded into the TX FIFO.
After doing some research with google, this seems to be a known limitation of the 16550 and its descendants. The designer’s intent seems to be that the TX FIFO reduces the interrupt load by allowing the driver to write 16 characters, or less if 16 characters are not available, to the UART for every TX interrupt (TX FIFO empty). It does not reduce interrupt latency requirements for applications that can’t tolerate underruns.