Your browser does not allow scripts
Please click here to view a static table of contents without scripts
Small Amounts of Data and End of Buffer Conditions
Return to Introduction  Previous page  Next page
When transferring data from an FTDI USB-Serial or USB-FIFO IC device to the PC, the device will send the data given one of the following conditions:

1.The buffer is full (64 bytes made up of 2 status bytes and 62 user bytes).  
2.One of the RS232 status lines has changed (USB-Serial chips only). A change of level (high or low) on CTS# / DSR# / DCD# or RI# will cause it to pass back the current buffer even though it may be empty or have less than 64 bytes in it.  
3.An event character had been enabled and was detected in the incoming data stream.  
4.A timer integral to the chip has timed out. There is a timer (latency timer) in the FT232R, FT245R, FT2232C, FT232BM and FT245BM chips that measures the time since data was last sent to the PC. The default value of the timer is set to 16 milliseconds. Every time data is sent back to the PC the timer is reset. If it times-out then the chip will send back the 2 status bytes and any data that is held in the buffer.  
From this it can be seen that small amounts of data (or the end of large amounts of data), will be subject to a 16 millisecond delay when transferring into the PC. This delay should be taken along with the delays associated with the USB request size as mentioned in the previous section. The timer value was chosen so that we could make advantage of 64 byte packets to fill large buffers when in high speed mode, as well as letting single characters through. Since the value chosen for the latency timer is 16 milliseconds, this means that it will take 16 milliseconds to receive an individual character, over and above the transfer time on serial or parallel link.

For large amounts of data, at high data rates, the timer will not be used. It may be used to send the last packet of a block, if the final packet size works out to be less than 64 bytes. The first 2 bytes of every packet are used as status bytes for the driver. This status is sent every 16 milliseconds, even when no data is present in the device.

A worst case condition could occur when 62 bytes of data are received in 16 milliseconds. This would not cause a timeout, but would send the 64 bytes (2 status + 62 user data bytes) back to USB every 16 milliseconds. When the USBD system driver receives the 64 bytes it would hold on to them and request another 'IN' transaction. This would be completed another 16 milliseconds later and so on until USBD gets all of the 4K of data required. The overall time would be (4096 / 64) * 16 milliseconds = 1.024 seconds between data packets being received by the application. In order to stop the data arriving in 4K packets, it should be requested in smaller amounts. A short packet (< 64 bytes) will of course cause the data to pass from USBD back to the FTDI driver for use by the application.

For application programmers it must be stressed that data should be sent or received using buffers and
individual characters.