Objective Development Forums

I have built an Hid device which is going to be used as a general purpose RF transceiver. I have successfully tested input and output transfers (separately) through interrupt endpoints at the maximum polling speed (around 8ms) with 8 bytes packet. This was done using separate C# WPF applications which uses asynchronous transfers through the interrupt In and Out endpoints. However, when I tried to run both input and output transfer threads simultaneously, it seems to choke the firmware after few seconds and the device gets reset and re-enumerated.

How can the In and Out traffic be controlled so that the device will not lock up? Is it better to do in host software or firmware?

Yeah, not going to happen.

This is an over,kill but explains why
viewtopic.php?f=8&t=11102


The v-usb consumes the entire CPU to handle NAK until the driver is ready. You will have no choice but to wait for it to do its thing before sending out. Simultaneous is not achievable but you could allow time slots with usbDisableAllRequests / usbEnableAllRequests

The problem is there is no way to predict the input data time to complete, it could be seconds. One trick you could do is skip the output until complete by adding flags. I have done that with great success but the window (normally 8 or 10 ms) for your bulk data will not be reliable.

Thanks for reply.
I don't know that much about what is going on inside the driver. So it requires some looking up before I could find out what modifications are needed.

Oh... no this is not well documented. Personally I think a disclaimer should have been put up (or maybe there is). V-usb loosely supports data input. I guess it is sort of expect, being this is a FM implementation of a hardware protocol but yeah, its not designed to preform as well as a hardware usb chip at all. Kudos to Christian for doing this, but it was only destined to be an emulation.

Yes, I know v-usb will not give the real performance of usb chip. But the biggest advantage here is that it is the cheapest alternative for a usb enabled solution. And this opens up so much possibilities in my opinion. For now, doing In and Out transfers at same time really does some nasty things to v-usb. Let me think what to do.

I have synchronized the input thread and the output thread of the C# application and now the crashing problem is solved. When the input thread received an interrupt in packet, an event is set so that output thread can send out packet. It seems like there is no collisions of in and out packets with this method. I can tell more details after more testing.

I have tried that but it didn't work out well for all systems. There is too much overhead in the OS that many times the application will be delayed and end up overrunning. One thing that helped was to set the thread to high priority but still had issues. If you close all other application it also will help but this will never be a perfect solution because a built c# application is dependent on higher priorities of the OS. A command line C application would be needed. If the occasional overrun is ok, you will be fine with the exception of OS tasks like heavy scratch disk use, defrags, windows updates, virus scanners, and any other app or tool that require CPU time.