MSP430F5528 USB CDC Windows drivers

Hi,

I found this from another post(http://e2e.ti.com/support/embedded/android/f/509/t/101013.aspx) , http://www.jungo.com/st/embedded_usb_cdc.html 

Quick question as well, I am thinking of getting MSP430F5528 for USB as well, is it easy to use? I need to connect USB to android tablet.

I'm not sure I quite understand what is being asked here.  The MSP430F5528 USB Developer's Package, available as a link from the MSP430F5528 Product Folder, has documentation indicating the CDC class leverages the Native OS Driver support, in this case Microsoft Windows.  Specifically, there is no Windows side driver update associated with this package.  The only thing that would be needed is an INF file.  This can be generated by the USB Descriptor Tool which is a part of the aforementioned developer's package.

If I'm missing something, please clarify what is needed.

The good thing is that Linux and Mac OS X support the USB CDC ACM driver internally.  For Windows you need a special driver that gets generated by the USB descriptor tool.  Since Android is Linux, I would expect that the 5528 USB will work fine with Android.  It should be discovered as /dev/ttyACMx, but it might be something else similar.  On a Mac (and presumably iOS), it will show up as /dev/tty.usbmodemx

The bad thing is that "easy to use" is a relative term.  In comparison with USB firmware for other MCUs, the TI USB firmware has nicer GUI features but under the surface the code is more impenetrable than usual, and it's not optimized much at all.  TI provides some examples, and if you can copy one of these exactly, or nearly exactly, then I would say it's a 7/10 for "easy to use."  If you find that this is not enough, or it isn't working right, then you can expect to spend about a month fighting with a debugger.  A 10/10 for "easy to use" would be a three function library (init, non-blocking rx/listen, non-blocking tx) that implements a single-interface CDC, but that is nowhere to be found.

For the record, I've spent about a month fighting with a debugger in order to try to create said three function library.

JP Norair said:

Since Android is Linux, I would expect that the 5528 USB will work fine with Android.  It should be discovered as /dev/ttyACMx, but it might be something else similar.

Unfortunately in the default, Android doesn't support CDC device. You'll need to rebuild Android kernel and burn it to the ROM on the Android device.

USB host (OTG) is officially introduced to Android since ver3.1. Before this version, Android works just as an USB device (Accessory) mode. Even after this version, supported USB classes by Android host are limited, like Mass-Storage, HID keyboard/mouse. If you wouldn't like to touch to Android kernel to extend USB class support, you could port libusb (user-mode driver) to it. Over libusb, you'll write your custom driver in your Android applications.

On Android, serial communication is supported better over bluetooth than over USB.

[Reference]
USB Host and Accessory - on Android Developers site
http://developer.android.com/guide/topics/usb/index.html

JP Norair said:

non-blocking rx/listen, non-blocking tx

The timing of USB transactions is determined by host, on both direction. Therefore, firmware has to wait for host anyway. Using cyclic buffers for TX and RX over USB endpoints, your main-stream code may run in "non-blocking", though your USB task is still waiting for transactions from host behind the cyclic buffers.

Tsuneo

Tsuneo Chinzei said:

The timing of USB transactions is determined by host, on both direction. Therefore, firmware has to wait for host anyway. Using cyclic buffers for TX and RX over USB endpoints, your main-stream code may run in "non-blocking", though your USB task is still waiting for transactions from host behind the cyclic buffers.

TI does not include a working application example of non-blocking CDC in their USB toolkit.  It uses the UsbConstruct functions, which are blocking, instead of using USB device interrupts.  Obviously, the USB layer that is beneath the "Construct" layer is non-blocking, but the TI implementation is blocking.  I'm almost done with my project, which strips-away all of the glue code from the TI library (for code efficiency reasons) and implements an interrupt-driven non-blocking CDC RX/TX model.  It is very easy to use.  I will be open-sourcing it.

JP Norair said:

instead of using USB device interrupts

Endpoint interrupt doesn't play major role here. It is applied just to increase the throughput. Polling of endpoint status is the workhorse.

As of RX (host --> device) direction,
1) The status of the bulk OUT endpoint is polled by a USB task, which is called by SOF interrupt or by main-loop repeatedly.
2) When the endpoint has received data, AND when there is enough room on the RX cyclic buffer, the USB task moves data from endpoint buffer to the cyclic buffer. The endpoint is armed again.
3) If there isn't enough room on the cyclic buffer, the endpoint is left untouched until next USB task call.
In this way, data loss by overwrite is prevented.

To apply endpoint interrupt along with above polling method, the endpoint ISR also does 2) and 3) procedures. If endpoint interrupt alone would be applied without polling, data overwrite could occur on the buffer.


As of TX (device --> host) direction,
1) The status of the bulk IN endpoint is polled by the USB task. A latency timer (counter) counts up.
2) When the endpoint has finished transaction, AND when there is enough data (64 bytes or more) on the TX cyclic buffer, the USB task moves 64 bytes data from the cyclic buffer to the endpoint buffer. The endpoint is armed again. The latency timer is cleared. A full-packet flag is set.
3) If there isn't enough data on the cyclic buffer, the endpoint is left untouched until next USB task call.
4) When the latency timer goes to full count (usually 4ms or so), the USB task arms the IN endpoint with the all data on the cyclic buffer (less than 64 bytes). If the full-packet flag is up AND if no data is kept on the cyclic buffer, a ZLP (Zero-Length Packet) is armed to the endpoint. The latency timer is cleared. The full-packet flag drops.

In this way, the transfer speed is kept by full-size packets. Also, the latency timer guarantees the deadline response.
To apply endpoint interrupt along with above polling method, the endpoint ISR also does 2) and 3) procedures.

I believe USB-UART chips, like FTDI and SiLabs, apply similar algorithm.

Tsuneo

Any advice when installing the .inf generated file does not work?

I have a new windows XP machine, project originated on previous machine where everything was working. I also tried the descriptor Registry Clean.

Wayne