USB *Host* VCP example

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.

Notice I said "especially on the peripheral side". This thread picked up that issue at some point.

Supporting CDC for the peripheral side is about as easy as supporting some proprietary scheme ... and it will work out-of-the-box with many more operating systems. From an end-user perspective, needless market fragmentation is not desirable. From a vendor perspective, needing to provide proprietary host-side drivers for multiple operating systems is worth avoiding.

The fundamental reason for all those non-standard protocols is, from what I've seen, that CDC is firmware-oriented (like a Stellaris chip) while almost all those cheap chips (FT2232, CP210x, and so on) do their work in silicon. A Stellaris-based solution will not save transistors or power by avoiding CDC; it's already using more silicon, by orders of magnitude, than those cheap USB-to-Serial adapter chips. It's also more expensive. Notice that the TI part someone mentioned earlier is pretty far from that very low end ... it's slightly programmable (8052 not ARM; sigh) and is not in that space.

(Whether TI wants to have an inexpensive USB-oriented microcontroller is for them to answer. Atmel's AT90USB162 parts are cheaper than those specialized parts; there must then be some kind of market.)

Agreed that having the host side support work with more than CDC would be good, and it's natural to expect such examples would handle any TI-proprietary solution before implicitly promoting one third party over another.

But that should be in addition to supporting the standard solution.

@dbrownell:

Thanks for the clarification. I think we are in agreement after all: if Luminary can provide more USB host functionality in the Stellaris library, that would be great.

I agree that CDC ACM Host functionality would be valuable, especially with many cellular modems implementing CDC ACM Device functionality.

dbrownell wrote:
it's natural to expect such examples would handle any TI-proprietary solution before implicitly promoting one third party over another.
Although, as the dev boards already use FTDI chips, that would seem an obvious first-choice of (non-TI) proprietary solution...

Bump:

http://e2e.ti.com/support/microcontrollers/stellaris_arm_cortex-m3_microcontroller/f/471/p/127237/455567.aspx#455567