MQX4.0 USB client TX - max rate, low latency

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MQX4.0 USB client TX - max rate, low latency

Jump to solution
502 Views
jpa
Contributor IV

I'm trying to write software for a USB client using MQX 4.0.1.  (Kinetis K60 Tower)  The data streams coming into the device are asynchronous, and need to be delivered to the host (via USB) with low latency.  At the same time, the multiple streams could combine at times to push towards the bandwidth limits.  Reading here on the forums and elsewhere, I'm convinced I need to 1) send data to the host immediately if nothing has been sent recently, and 2) buffer data up to 64 bytes for anything received in the time between the last send and USB_APP_SEND_COMPLETE. 

I _think_ I've got this coded up and it works for single packet transmissions (nothing received before the previous SEND_COMPLETE).  When I get a USB_APP_SEND_COMPLETE, I check to see if any data has been buffered, and if so, I call USB_Send_Data to send the buffered data.  But the host never receives this data.  I test by having the host suspend reading, and have the client send one packet (and USB_Send_Data gets called immediately) and then a second and third packet (that get combined into the same outgoing buffer).  When the host starts reading, the first packet is received, USB_APP_SEND_COMPLETE is triggered, causing USB_Send_Data to be called with the buffer holding data packets 2 & 3, but the host never seems to receive this data.  USB_APP_SEND_COMPLETE is triggered a second time.  If I have the client send a 4th packet, it gets sent immediately, but appears to never be received by the host.  A 5th packet (and all subsequent packets to be sent immediately) go through fine.  If I suspend reading at the host a second time, the same process is repeated. 

Am I doing something wrong by calling USB_Send_Data within the Notification Callback from the previous send?  If so, how should it be done?

Does IMPLEMENT_QUEUING have anything to do with this?  Is there an explanation somewhere that tells what this is trying to accomplish?

I'm using a class I derived from the USB_Audio and USB_CDC classes. 

John

Labels (1)
0 Kudos
1 Solution
335 Views
jpa
Contributor IV

FWIW, I tracked down the immediate problem to a mistake in the USB configuration...following the example of another device (when I shouldn't have), the max packet for the endpoint was 8 bytes, and when two messages were queue'd up, it exceeded this max.  Increasing the endpoint descriptor settings to my actual max of 64 bytes seems to have fixed most of the problems above, although I'm still fighting other issues. 

John

View solution in original post

0 Kudos
1 Reply
336 Views
jpa
Contributor IV

FWIW, I tracked down the immediate problem to a mistake in the USB configuration...following the example of another device (when I shouldn't have), the max packet for the endpoint was 8 bytes, and when two messages were queue'd up, it exceeded this max.  Increasing the endpoint descriptor settings to my actual max of 64 bytes seems to have fixed most of the problems above, although I'm still fighting other issues. 

John

0 Kudos