How do I increase the speed of my USB cdc device?
I am updating the processor in an embedded system to work. It's all in C, no OS. Part of this update includes migrating the communication interface of the processor and PC from IEEE-488 to USB. Finally, I got the USB firmware and tested it. This was great until I tried to push through a lot of data, only to find that my USB connection is slower than the old IEEE-488 connection. I have a USB device that is listed as a CDC device with 115200bps baud rate, but clearly I didn't even reach that throughput, and I thought this number is a bogus value, which is a latency since RS232 days. but I may be wrong. I control all aspects of this from the front of the PC to the firmware of the embedded system.
I guess my problem is how I write to USB with an embedded system. Right now, my USB_Write function runs at spare time and is just a while loop that writes one char to the USB port until the write buffer is empty. Is there a more efficient way to do this?
One of my problems that I have is that in the old system we had a board in the system dedicated to communication. The CPU will just write data over the bus to that board and it will process messages, which means the CPU shouldn't have wasted time processing actual messages, but could shut down communication before the "coprocessor" (not the CPU, but functionally then same here). Even with such a concern though, I decided that I should get higher speeds, given that USB speeds are on the order of MB / s, while IEEE-488 is on the order of kB / s.
In short, is it more of a fundamental system limitation or a software optimization problem?
source to share
I thought the number was a bogus value which is a delay since RS232 days, but I could be wrong.
You are correct, the baud number is a bogus value. If you create a CDC / RS232 adapter, you must use it to configure your RS232 hardware, in which case it means nothing.
Is there a more efficient way to do this?
Absolutely! You should write chunks of data the same size as the USB endpoint for maximum transfer speed. Depending on the device you are using, a stream of single-byte records may be bundled into a single packet before sending, but from my experience (and your results) this is unlikely.
Depending on your latency requirements, you can insert into a round buffer and only output data from it to the USB_Write function when you have an ENDPOINT_SZ number of bytes. If this results in excessive latency, or your interface is not always communicating, you can implement Negle's algorithm.
One of my problems that I have is that in the old system we had a board in the system dedicated to communication.
The NXP part you mentioned in the comments is no doubt fast enough to saturate a USB connection at full speed.
In short, is it more of a fundamental system limitation or a software optimization problem?
I would call this a software design problem, not an optimization, but no, you are unlikely to be fundamentally stuck.
Take care of what kind of USB connection you are using, but if you are using USB 1.1 you will be limited to 64KB / s, USB 2.0 maximum speed will be limited to 512KB / s. If you require higher bandwidth, you should upgrade to a separate mass endpoint for data transfer.
I would recommend reading through a simple USB site to get a good overview of the various USB speeds and their capabilities.
One recent release, vendor CDC libraries are not always the best and the implementation of the CDC standard may differ. In theory you can get more data through the CDC endpoint using the larger endpoints, I've seen this cause the host-side drivers to kneel, although if you go that route, create your own driver using bulk end points.
Try to test your device on multiple systems, you may find that you get different results between windows and linux. This will help you point your finger at the end of the knot.
Finally, make sure you are doing large buffered reads on the host side, USB will stop transferring data when the host side buffers are full.
source to share