Heavy cost between USB_HostCdcDataSend and its callback on TWR-K65 USB EHCI Host

[johnesmith]

Below is what I've done to measure the interval between USB_HostCdcDataSend and its callback on TWR-65 USB EHCI Host.
1. Connect the K65 USB EHCI Host with FTDI device.
2. Send data packet to device via USB_HostCdcDataSend and set the time as T1.
3. Once the callback comes, set the time as T2.
4. T2 - T1 is nearly 2ms. Moreover, if there happens to be an IN transfer between the USB_HostCdcDataSend and its callback, then the value of (T2 - T1) would be nearly 5ms.

That's totally too long a cost for real time systems. However, the FTDI device can response to the PC host within 1ms. I suspect it is an issue in USB low level driver. 

BTW, I didn't see any NAK after calling USB_HostCdcDataSend.

Can anyone help to verify this issue, or share some performance benchmark in this case?

[johnesmith]

why it needs almost 2ms between the send request and its callback? it is too long for real time system. 

[jorge_a_vazquez]

Hi Johne Smith

It could be many reasons for this timing that you are getting;

first, how are you measuring this times (T1 and T2), are you setting any kind of GPIO and checking the output in the scope?

This could not necessary give you the actual time that you mention as a USB specification, it could take some time to pass from a high level API as it is USB_HostCdcDataSend to a low level as it is the hardware when it send data and the checks ack to set the interrupt that will call the callback, so it could be that

"However, the FTDI device can response to the PC host within 1ms", unfortunately we cannot compare a USB embedded application with a USB PC application, first of all, we have just one core that takes care of all the process, in a PC we have more resources available, so yes, a PC host will have a better performance.

Additionally, as my colleagues Carlos mentioned in the thread,  the USB-serial devices are CDC class, which use Bulk transactions, so, the latency depends of the Host capacity and workload, so if there happens to be an IN transfer between the USB_HostCdcDataSend, it will uses the available resources as it need it.

Hope this information could help you,

Best Regards

Jorge Alcala

[johnesmith]

Thanks for your analysis, Jorge.

1. Well, I believe that the bottleneck is not in the USB IP behavior which should follow the spec. What I actually concerned is time taken from the high level API to the corresponding callback, i.e. the total time consumed in the USB stack.
That is why I request you some benchmark result for the time between the high level API and its callback.

2. Compared with the PC, the embedded system usually focus on one dedicated application, which should get better performance in the terms of 'real time'. Here we talked about things like real time system, not the capacity of how much tasks one could process.

3. It would be better to have a similar test on your side, i.e. send a packet via CDC class pipe, and measure the time taken between the high level API and its callback. If you have the same result, I think we would identify the root cause which would be the problem in the USB stack.

[johnesmith]

I found some others had the same issue as me. Anyone can help on it?

https://community.nxp.com/thread/447097