| ??? 02/09/06 19:58 Read: times |
#109643 - Pesky hardware FIFOs Responding to: ???'s previous message |
Grant Beattie said:
Just to add to my previous comment, and perhaps to save someone a wasted effort. Recall I discussed how sending XOFF to a PC was futile since the PC would continue to send the data in it's FIFO before the XOFF was honored. My algorithm at one time sent an XOFF in response to any data received after my input buffer trip point was surpassed. So if the PC sent 100 bytes after my trip point, I sent 100 XOFFs in response. It didn't help... just in case anyone had the idea to try that. I know, I tried it. My first thought was that my XOFF was getting lost, so I tried sending a few of them, but with no luck. Yelling and screaming over and over doesn't help when no one is listening. :) Thanks for pointing this out. If you have enough money you can fight fire with fire by either designing an 8051 circuit with tons of RAM or using an external UART with a FIFO in it. Or simply refuse to talk to Windows PC's ;-) My old DOS test box running PCPLUS honors XOFF *immediately*. Don't know what the UART is in it though.
GB Well, I was definitely fighting fire with fire here, in my case using lots of RAM. As a viable and low cost alternative though, if you are designing the PC application and the PC <==> 8051 application layer protocol, you can easily incorporate simple, reliable flow control into your system at the application layer. Simply never send more bytes at a time from the PC than can be held in the 8051's receive buffer. Then, the PC can simply wait until the 8051 sends an acknowledgement indicating it is waiting for more data. Of course, depending on the nature of the application, this might have notable performance implications. Discounting anything odd/interesting that Windows does, I think you just hinted at a major problem of doing software flow control when using a hardware FIFO: software flow control state is checked right before the hardware FIFO-equipped host submits data to the FIFO for transmission, and not right before the time the FIFO begins to put the byte on the wire. This, of course, is in sharp contrast to the operation of my software FIFO implementation. I wouldn't be the slightest bit surprised if your DOS test box wasn't using a hardware FIFO, and/or wasn't doing any OS-based buffering either, thus allowing it to to be extremely responsive to software flow control requests. Just out of curiosity, have you observed any improved response on your Windows PC to your 8051's XOFFs after disabling the FIFO in Windows? I never tried this. --Sasha Jevtic |
| Topic | Author | Date |
| XON/XOFF control | 01/01/70 00:00 | |
| what do you need to know? | 01/01/70 00:00 | |
| XON/XOFF control | 01/01/70 00:00 | |
| What's the problem | 01/01/70 00:00 | |
| Buffer overflow | 01/01/70 00:00 | |
| Standard Keil implementation! | 01/01/70 00:00 | |
| Software flow control in depth | 01/01/70 00:00 | |
| nice! | 01/01/70 00:00 | |
| Bad 16550s | 01/01/70 00:00 | |
| re: Bad 16550s | 01/01/70 00:00 | |
| XOFF Clarification | 01/01/70 00:00 | |
| Software flow control in hardware | 01/01/70 00:00 | |
| Neat | 01/01/70 00:00 | |
| Opposite of SMS? | 01/01/70 00:00 | |
| Pesky hardware FIFOs | 01/01/70 00:00 | |
Bad 16550's and Control | 01/01/70 00:00 | |
| then join me and score it | 01/01/70 00:00 |