General Category > Discussion - Software

Can someone please explain how event characters are supposed to work?

(1/2) > >>

Me123:
Hello.  I'm using the FTD2XX.dll to interface to a FT232RL chip and was noticing some odd behaviour.  I've turned on event characters and when I send a series of packets that are exactly 62 bytes (including the event character) then there is a very long delay before the data is available to my application.  I've read application note AN232B-04 a few times and this behaviour makes sense if I don't have event characters turned on, as the rate I am sending data back and the value of the latency timer means data wouldn't be sent until the USB buffer is full.  But as I have event characters turned on shouldn't the USB buffer be flushed every time an event character is seen in the data stream, or have I misunderstood something?

Many thanks

FTDI Community:
Hello,

If the event character is enabled and it is detected in the data stream, then the contents of the devices buffer is sent immediately. The event character is not stripped out of the data stream by the device or by the drivers, it is up to the application to remove it. Event characters may be turned on and off depending on whether large amounts of random data or small command sequences are to be sent. The event character will not work if it is the first character in the buffer. It needs to be the second or higher. The reason for this being applications that use the Internet for example, will program the event character as '$7E'. All the data is then sent and received in packets that have '$7E' at the start and at the end of the packet. In order to maximise throughput and to avoid a packet with only the starting '$7E' in it, the event character does not trigger on the first position.

You may also want to take a look at the latency timer.

The latency timer is a form of time-out mechanism for the read buffer of FTDI devices. When a FT_Read instruction is sent to the device, data will not be sent back to the host PC until the requested number of bytes has been read. If the requested number of bytes never comes, the device would not send data back.

The latency timer counts from the last time data was sent back to the PC. If the latency timer expires, the device will send what data it has available to the PC regardless of how many bytes it is waiting on. The latency timer will then reset and begin counting again.

The default value for the latency timer is 16ms. This value may be customised by adding or changing the following entries in the FTDIPORT.INF file of the driver before installation.

[FtdiPort232.NT.HW.AddReg] 
 
HKR,,"LatencyTimer",0x00010001,50 
 
This example will set the default latency timer value to 50ms. The valid range for the latency timer is 1ms - 255ms, although 1ms is not recommended as this is the same as the USB frame length.

The latency timer value is held in the registry under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\FTDIBUS\{Device VID, PID and serial number}\0000\Device Parameters\LatencyTimer 
 
Please see AN232B-04 Data Throughput, Latency and Handshaking for additional information on the latency timer.

Best Regards,
FTDI Community

Me123:
Hi, thanks for the reply. 

Yes I have seen that application note and read it several times, however it is still not clear to me what the behaviour should be when a packet of data is sent that ends in an event character and is 62 bytes long.

You state that if the event character is enabled and it is detected in the data stream, then the contents of the devices buffer is sent immediately. However, this is not true if the packet of data you are sending is 62 bytes long, at least not in my testing. This, combined with the fact that if you are sending packets of data with a smaller interval than the latency timer setting then the buffer will not be transmitted until it is full (default 4096bytes), means even if you are using event characters there can be very long delays between receiving data.  I would like to know if this is the expected behaviour, because it does not seem like it should be to me.

Thanks.

FTDI Community:
Hello,

If you are sending 62 bytes of data and then the event character, then the event character could be sent in the next packet of data (64 bytes in total with two status bytes). This could violate this rule:

The event character will not work if it is the first character in the buffer.

However you need to decide whether you really need event characters. If you are sending 62bytes of data then it will be send immediately since you are sending a full buffer of data.

Best Regards,
FTDI Community

Me123:
Hi.  I am sending 62 bytes including the event character.  It is not sent immediately, at least it is not available to be read out by my application and as I stated in my last post - because the latency timer never times out no data is available to be read until the USB buffer is full.  For me this happens 6.4 seconds after I start sending data, which seems a bit extreme.

Navigation

[0] Message Index

[#] Next page

Go to full version