USB *Host* VCP example

See: http://e2e.ti.com/f/471/p/45125/154912.aspx#154912

As PCs are rapidly losing their COM ports, and just having USB, so devices are now losing their RS232 ports and providing only a USB Device connection.

Previously, it was easy to use devices with microcontrollers by connecting to the UART - now we increasingly need to be able to provide a USB Host socket to act as a "virtual COM port".

Unfortunately, nobody seems to provide any examples of this!

:-(

There are loads of USB Host examples for mass-storage and HID - but (virtually) nothing for VCP (or CDC).

:-(

So, it'd be great to have a Host* VCP example - something into which you could connect a standard USB-to-Serial adaptor, for the purposes of demonstration...

See also: http://www.8052.com/forumchat/read/168024

19 Replies

  • I agree. TI, please consider adding a host version of the Stellaris usblib usbdcdc.[ch].

    Atmel has two appnotes, http://www.atmel.com/dyn/resources/prod_documents/doc6269.pdf for their AT91 ARMs, and http://www.atmel.com/dyn/resources/prod_documents/doc7727.pdf for their AVRs. That, along with the code examples, is exactly what I am asking TI to consider providing.

    Thanks!

    Post edited by: eortheain, at: 2009/11/22 21:00
  • I'll make sure this is on the requested-feature list. It shouldn't be particularly technically difficult. The problem is likely just a matter of having it bubble to the top of the priority list given everything else that we are working on.
  • After reading the thread on "USB Host VCP" over in the general forum, I would like to change my request. What I really need is for my Luminary MCU board to interface with an usb-to-serial adapter, and as I understand it, pretty much every single such adapter on the market uses a proprietary interface rather than the CDC class.

    This appears to be a pretty common desire. Would you please consider implementing something like the Linux usb-serial stack (drivers/usb/serial)?
  • We would not be able to provide support for proprietary interfaces unless those interfaces were publicly documented (and, hence, not proprietary) - Catch 22?
  • In practice, I think there are only a relatively few chips in common use; viz, FTDI, Prolific, SiLabs - any others?

    I think FTDI & Prolific are the "top two" - so just supporting them should be sufficient?

    This does seem to be the approach adopted by http://www.ghielectronics.com/products - as mentioned in the thread in the General forum:

    http://e2e.ti.com/f/471/p/45125/154912.aspx#154912
  • Texas Instruments too - e.g. the TUSB3410. That one is documented too. And there's a driver for it in /usr/src/linux/drivers/usb/serial, as it happens.

    So if TI/Luminary could port the Linux USB serial driver framework, they would have any number of options -- support the ported framework and the actual drivers for various Serial-to-USB chips; support the framework and all documented Serial-to-USB chips, support the ported framework, or what have you.
  • Thank you for the suggestions and pointing out the specific parts, especially the TI one. That is interesting. We added this to the feature suggestion list.
  • Let me encourage you to just support standard CDC ACM, in the no-modem mode, instead of trying to emulate some version of a proprietary scheme.

    Especially in terms of peripheral side drivers ... but similarly on the host side. The USB marketplace is way too cluttered with needlessly proprietary serial links, and it'd be better not to worsen that problem.

    In terms of connectivity, host side CDC ACM support is widespread. Linux certainly supports it, as do many proprietary operating systems; CDC is vendor-neutral. Even Microsoft supports it ... although their driver stack (not just usbser.sys) has design problems which complicate its use with composite devices. (That is, if your device exports serial *plus* something else it's likely to cause various headaches when you try to associate different drivers with each interface.)
  • I would disagree with dbrownell's suggestion for one simple reason: "installed base".

    There are a *lot* of industrial and consumer devices out there that use serial-to-USB chips that don't implement CDC ACM.

    Given the large number, I would go as far as to suppose that vendors may actually have good reasons for implementing a proprietary communication framework rather than CDC ACM.

    It is precisely because of this large installed base that it would be very valuable to have USB HOST support for connecting Luminary MCUs to this type of devices.
  • I would disagree with dbrownell's suggestion for one simple reason: "installed base".

    There are a *lot* of industrial and consumer devices out there that use serial-to-USB chips that don't implement CDC ACM.

    Given the large number, I would go as far as to suppose that vendors may actually have good reasons for implementing a proprietary communication framework rather than CDC ACM.

    It is precisely because of this large installed base that it would be very valuable to have USB HOST support for connecting Luminary MCUs to this type of devices.