Serial port RTS question


Jim Battle

Recommended Posts

Jack, maybe I'm completely misguided as I haven't worked with virtual com ports before, but here goes.  I noticed in the schematic only the async rx/tx pins from the FTDI device are connected to the FPGA.  In my particular application, I capture around 100 KB of data, then I stream it all at once over the serial port at 3 Mbps.   One worry I have is that should I be connected to a full speed USB port and there is some other traffic which competes for the available bandwidth (say a multiport USB hub), what is to prevent data loss?  If the ready to send/receive bits were wired from the FTDI device to the FPGA, it seems like I could guard against data loss, but as it is, I simply have to trust that things will be OK.

 

Is this a misguided fear, or maybe something that could be addressed in the BGA-based design where you will have more I/Os to spare?

Link to comment
Share on other sites

Jim, You might even lose data due to the host OS being distracted - if the buffers overrun then the bytes will be dropped. 

 

What is needed is some sort of flow control - maybe a "buffer credits" system, where the host acks every set of 'n' bytes ensuring that the board never sends so much that buffers overflow.

Link to comment
Share on other sites

Ugh, that is exactly what I was afraid of.  Rather than having a simple serial protocol, now I have to implement a protocol on top of an unreliable channel.  That is a terrible feature.  Jack, I vote for this with a high priority: fix the connection to the FTDI serial port so flow control works, removing a layer of complexity.

 

Hamster, even what you propose is problematic.  How am I to know how small the buffer size needs to prevent overflow?  It seems in the worst case I have to assume it might overflow (no matter how small a buffer is used) and have a means of reporting that fact back to my device and retrying.

 

In my case, I don't need to worry about flow control from the host to my device, as I have a 2KB FIFO to hold the command stream, and I can ensure that there is never more than 2K outstanding at a time.  But I can imagine other applications where being able to throttle the host would be useful without having to create an in band flow control mechanism.

Link to comment
Share on other sites

Jim, You might even lose data due to the host OS being distracted - if the buffers overrun then the bytes will be dropped. 

 

What is needed is some sort of flow control - maybe a "buffer credits" system, where the host acks every set of 'n' bytes ensuring that the board never sends so much that buffers overflow.

 

If I understand the concern, I have some additional information: The USB bus already has such a system. Each endpoint has a fixed max size, and no more than that can be outstanding at a time (plus double-buffering if supported.)

 

Now, if you're sending 1.2 kB of data per second to the host, and the host is not actually receiving and processing 1.2 kB of data per second, then something will drop somewhere. More than likely, the FIFO in the FTDI will fill up, and then the FTDI will drop the data. This is much more likely than the host dropping the data (unless you're using very shitty serial-USB drivers.) 

 

So, does the FTDI document the size of the FIFO? IIRC, the max size of a USB full-speed endpoint is 64 bytes, but the FTDI could conceivably have a deeper buffer. Hardware flow contrl between FTDI and FPGA would totally solve this, though -- host need not be involved. (But then, the data will back up on the FPGA side -- it has to back up somewhere :-)

 

Also, have you considered using a USB microcontroller instead of the FTDI chip? If you need some microcontroller for analog ins or flash bootloading or whatever, then that might be able to do double duty. Or it might change the design more than it's worth!

Link to comment
Share on other sites

Jon, in my case the can run at 3 Mbps and I've run many MB of data through at that speed without loss, but since I don't really know how much margin there is in the design, I backed off to 2 Mbps.  And really, the 2 Mbps carries only 1.6 Mbps of data payload once the start/stop bit overhead is removed.

 

Yes, I'm aware that USB packetizes the data, has flow control and error correction mechanisms (checksum, ACK/NAK, retry), but should the link get congested, the FTDI chip should drop the RTS status and let me know to throttle.  How likely is that? Well, the 2232D that the Papilio Pro uses is a full speed USB link and uses a 128 byte transmit buffer.  Although a full speed link is 12 Mbps peak, but the reality is that packetizing and flow control overheads means that throughput will be less, probably under 8 Mbps.  If the USB link I'm connected to goes through a hub and is sharing the bandwidth with a scanner, which is capable of saturating the link, the FT2232D on the papilio pro will drop RTS but the FPGA will never know it.

 

Sure, I could work around it by adding another FTDI or similar device, but my point is that it could all be avoided if the FTDI flow control signals were connected up to the FPGA.

Link to comment
Share on other sites

One of my ZPUino examples is an Audio Player, which streams a WAV file, stereo, 14.4K, 16-bit, through the USB serial at 3MBps. Sometimes a bit is lost, and the frame needs to be retransmitted (the framing used is HDLC, as well as the protocol, although not 100% HDLC compliant). No need for RTS/CTS, the flow control is handled by the upper layer, which knows the FIFO size in advance.

 

It works very well with the default settings in Linux and Windows.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.