This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM48, USB CDC and Virtual COM Port

Hi,

I have been trying to use the RM48 HDK as a USB device, for this I used the demo application that implements the CDC class, it works fine and I am able to transfer data from host application using a serial port API.

But I have questions for TI. 

1. Can the USB Device Stack and CDC code provided by TI be used without using the Virtual COM Port at the host side, i.e. if I don't want to communicate over VCP with the RM48 HDK USB device, then what changes (if any) are required in the library (CDC example code). For instance, how to do a basic read/write of data without using the VCP driver.

2. What is the maximum throughput that has been tested on RM48 HDK using the cdc example?

Looking forward for your help.

Thanks

Anila

  • Hi Anila,

    This example is just for the CDC Class, so it only supports a virtual com port.
    And it's an example - not something that's been characterized well so I can't answer your question about throughput. However, the USB device is full speed only and that means that it's not going to be super fast - the raw bit rate is 12Mbps. But the host normally will schedule 1 packet per 1ms max to the device. So hopefully that will give you an idea of the throughput to expect. I think it's reasonable to expect it to be on par with a regular COM port ..

    If you want to use something other than CDC you need a class driver for the embedded target. The best place to get this would be from a company that specializes in an OS w. middleware... there are some links on our tool folder for third parties like Micrium that carry this type of software. And then you'll need a host side driver as well.

    The *very* nice thing about the VCP is that windows and linux will come with the driver to speak to a CDC class device so it's very minimal effort on the host side to use this option. And writing to a COM port through "C" isn't nearly as complex as creating your own host driver.

    If this doesn't sound too appealing and you need a higher throughput w.o. going through the work on the driver side - you may want to look at Ethernet instead.