Jump to content
43oh

MSP430F5510 USB: how well does it work?


Recommended Posts

This is a question for people who have used the F5510 (or related). Is the USB interface on those chips usable in practice for a UART interface?

 

The reason I ask is because I have many projects where I would like to have a working simple USB interface (UART on the PC side, I2C/SPI/UART on the microcontroller side). FT232RL works very well, but is large and expensive. The new FT200XD chip (USB to I2C) looks great, but is unobtainium for now.

 

However, I prefer to ask, because USB on paper is very different from USB in practice. In particular, I'm worried about:

 

* driver support: for UART, do drivers need to be installed on host computers? If so, are those royalty-free, easily available and work on Mac OS/Linux as well as Windows?

 

* libraries: will I need to write everything myself, or is there code that I can use?

 

* code size: given that I'm limited to 16kB by the free Code Composer license, can I fit a usable USB implementation and still have room for my code?

 

I guess my questions boil down to this: is it reasonable to expect to be able to replace a FT232RL+MSP430G2 with a F5510?

 

 

Link to post
Share on other sites

MSP430F5510 can be used as USB CDC device (virtual serial port), without changing PC code (written for uart).

 

There is some difference regarding way of transfer, and I done some researching...

http://forum.43oh.com/topic/2775-msp430-usb-benchmark/

 

Don't see any reason for using MSP430G2xx at all (even for non-USB application). Only plus for MSP430G2xx is DIP, nothing else.

Link to post
Share on other sites

Well, one good reason to use G2xxx is price: the MSP430G2412IRSA16T, which I currently use in my projects is exactly 4.3x cheaper (checked at Farnell) than the cheapest usable (non-BGA) F5510 (MSP430F5510IRGZT).

 

But let me clarify: I asked not about changing PC code, but about driver support. Think about it this way: if I build something and give it away to people, will they be able to use it? With FTDI chips the answer is yes: you download drivers from FTDI, which is reasonably easy, and you're done. This works on Mac and Windows at least.

 

I should mention here that Texas Instruments' policy of limiting the free version of CCS to 16kB is a handicap here: it makes it more difficult for hobbyists to transition to more modern MSP430 chips. F5510 has 32kB of flash, which I won't be able to use.

Link to post
Share on other sites

Didn't know that price ratio is so high. Anyway, MSP430F550x family offer much more than MSP430F2xx, and don't need any programming/flashing tool.

 

If your USB device will be CDC (virtual serial port), there is no need for any non-standard driver support. Standard CDC drivers exists on any OS. So anybody who want to use your device, just need to plug it (MSP430F5510 without any other parts) to PC, and it will be automatically enumerated by OS.

 

Original TI USB stack (http://www.ti.com/tool/msp430usbdevpack) is about 4 KB. My assembler USB stack is about 1 KB in total. USB support will not eat too much flash space. There are free C compilers that don't have 16 KB limitation, and MSP430F550x can be flashed just by USB interface without any programming/debugging tool, so there is no need for CCS or IAR.

Link to post
Share on other sites

This sounds quite interesting -- I didn't know you could program the chip via USB. Well, you've just about convinced me to at least try them :-)

 

As for the pricing, the 2412 I'm using now is a bargain, but if I need ADC or USCI, I end up with 2553, which isn't that much cheaper than F5508 or F5510. And the F55xx series has LOADS of peripherals, much more than 2553. So it might make sense to go straight to F55xx.

 

Do you plan to make your USB stack available?

Link to post
Share on other sites

A few thing to be aware of when using ACM CDC. There is limited handshake line support and it tends to be buggy - not a problem if you are using just tx/rx data. The FTDI and Prolific chips properly support all handshake lines. On some version of windows there are annoyances with signing of the inf file required for CDC ACM.

 

 

 

The FTDI FT230X is available now for about $2, and works very well.

Link to post
Share on other sites

The TI USB descriptor tool produces a fairly bloated, non-configurable library that leaves a lot to be desired.  The CDC implementation is probably about 5KB once you consider the program code and required static, descriptor data, so make sure to consider these requirements.  Jazz has a purpose built library that is smaller, although his/her claims of 1KB seem optimistic as USB descriptor data is pretty big -- probably at least 500 bytes.  Even so, I'm sure it's smaller than the TI library.  If you want ACM-CDC, though, I don't know if it will do that.

 

Anyway, to answer the original question, I believe the MSP430F5 is not really suitable to run USB in complex applications.  For low-duty-cycle applications where your program code does not have hard-real-time requirements, it is easy enough to work the TI examples into your program.  For applications with hard-real-time requirements, you may find that USB is getting blocked by your other task or USB is blocking your task (the USB library runtime is demanding and generates a ton of interrupts).  In this case, you *might* get data corruption and disconnects unless you implement a type of RTOS -- if you have two I/O pipes, such as USB and an RF interface, you *will likely* have some glitching here and there.  If you think you will need an RTOS, make sure to check for support of MSP430F5-USB.

Link to post
Share on other sites

This sounds quite interesting -- I didn't know you could program the chip via USB. Well, you've just about convinced me to at least try them :smile:

 

As for the pricing, the 2412 I'm using now is a bargain, but if I need ADC or USCI, I end up with 2553, which isn't that much cheaper than F5508 or F5510. And the F55xx series has LOADS of peripherals, much more than 2553. So it might make sense to go straight to F55xx.

 

Do you plan to make your USB stack available?

 

Firmware in TI txt format can be flashed by USB BSL. "MSP430_USB_Firmware_Upgrade_Example-1.2.1-Setup.exe" can be download from here:

http://software-dl.t.../index_FDS.html

 

I will not publish source code of my USB stack, but don't have any secrets related to code. Everything is published on this topics:

http://forum.43oh.com/topic/2775-msp430-usb-benchmark/

http://forum.43oh.com/topic/2843-msp430-dma/

http://forum.43oh.com/topic/2926-msp430-usb-2-kb-ram-1c00-23ff/

 

I will help anyone who want to make something like this, or anything else related to MSP430 USB. No problem.

 

 

A few thing to be aware of when using ACM CDC. There is limited handshake line support and it tends to be buggy - not a problem if you are using just tx/rx data. The FTDI and Prolific chips properly support all handshake lines. On some version of windows there are annoyances with signing of the inf file required for CDC ACM.

 

The FTDI FT230X is available now for about $2, and works very well.

 

AFAIK it is not related to MSP430F550x. It is related to Win32 "usbser.sys" driver. Prolific and FTDI don't have this problem becouse they are using costumaised CDC drivers.

 

Didn't work with FTDI chips, only with Prolific PL2303HXD that support any boud rate (123456, 654321...) up to 12 Mbps. Just to note that depending on transfer, USB/Uart bridge at 115200 bps is slower that native hardware port at 115200 bps. Short data transfer or turning on/off handshake signals is bigest problem for bridge chips.

 

post-26480-0-28725400-1356864476_thumb.gif

 

 

The TI USB descriptor tool produces a fairly bloated, non-configurable library that leaves a lot to be desired.  The CDC implementation is probably about 5KB once you consider the program code and required static, descriptor data, so make sure to consider these requirements.  Jazz has a purpose built library that is smaller, although his/her claims of 1KB seem optimistic as USB descriptor data is pretty big -- probably at least 500 bytes.  Even so, I'm sure it's smaller than the TI library.  If you want ACM-CDC, though, I don't know if it will do that.

 

Complete firmware size for my CDC/Generic benchmark (stack + application) is under 1.5 KB. You can download and check by yourself. All USB things are not implemented, only basic operations that I need.

Link to post
Share on other sites

Right, it is a limitation of the CDC ACM spec, not a problem with the F5000 series. The Prolific chips use an extended ACM protocol (to support handshake lines) with their own drivers.

 

The FTDI chips perform very - high throughput and low latency (configurable). They even have 'H' series parts that use high speed (480 Mbps) USB.

Link to post
Share on other sites

Right, it is a limitation of the CDC ACM spec, not a problem with the F5000 series. The Prolific chips use an extended ACM protocol (to support handshake lines) with their own drivers.

On ACM: There are many optional features that an ACM host should technically support, including hardware handshaking (e.g. RTS/CTS).  The device side allows optional support for these features.  The best document for learning about this stuff is the CDC spec itself, which is  actually quite easy to read.

 

The TI USB library CDC firmware is lacking in several ways.  One thing you will note if you spend a lot of time developing USB with it is that the Interrupt Endpoint NEVER seems to get used at all.  Another thing is that all of the hooks for RTS/CTS are present, operated by the control endpoint.  If the host sends a handshake over the control endpoint, the ISR code will indeed get serviced ("control line state" I believe).

 

Granted, serial-style handshaking is somewhat irrelevant over USB.  It's not like there is an actual pin that can wake up the system, the entire USB subsystem needs to be operational just to receive the control transfer from the host, so the host might-as-well just send the data packet rather than do any handshaking.  In other words, the USB MAC already has some handshaking built-in.  It also has data integrity CRC built-in, for the record.

Link to post
Share on other sites

There are some applications that need more than the one pair of handshake provided by CDC ACM. Using the MSP430 BSL for example.

 

FTDI can do wakeup on CD line change.

 

It is possible with MSP430's USB over CDC, as long as you know how to send these control messages from the host.  Looking at page "16" of USB CDC 1.1 spec (actual page 27), there is a list of ACM control requests and notifications.  Anything that RS232 can do, so can USB CDC-ACM, the names are just different -- arguably more descriptive.

 

Re: CD line change.  Are you referring to the 5th pin from the OTG spec?  Certainly, it is possible to implement this on an MSP430.

 

If you want a ready-built USB adapter, the FTDI chip is really difficult to beat.  But if you need an MCU, you need USB, and you want to reduce the chip count, then there is the MSP430F55 series with USB.  It has a USB BSL, too.  So, don't put a square peg in a round hole, just use FTDI if it is the best solution.  Personally, I like to cut-out UART from the solution if I can.

Link to post
Share on other sites

Thanks to everyone for thoughtful and informative answers. Just to clarify, I don't need anything fancy or fast, just a basic UART for configuration and data retrieval. A 115200-baud UART would be just fine, and even 9600 would do.

 

FTDI chips would be just fine if I could get my hands on the newer simpler I2C models (I could not find the FT200XD in Europe) and if they were slightly cheaper. The FT232RL costs about 3-4 times as much as the MSP430 I'm using :-) -- so I'd much rather upgrade to a F5508 (getting a ton of bonus peripherals in the process).

Link to post
Share on other sites

FTDI chips would be just fine if I could get my hands on the newer simpler I2C models.

I've used one of these, and it's not great.  What you really want in an I2C-USB bridge is a master-to-master transfer mode, which it doesn't support.  As it is now, it is impossible to push data to the master (your MSP) with this bridge.

 

Also, I would go for the 5509, because the USB driver firmware has a reasonable heavy footprint.  If you want to have similar flash size to the G-series device you are using now, go with the 5509.

 

I use the 5503 in some applications, myself.  It is a 5510 without ADC.

Link to post
Share on other sites

This isn't *strictly* on topic, but we touched on it in this discussion, so here goes:

 

As far as chip choice is concerned, I just checked prices at Farnell UK (I'm limiting this to what they have in stock, non-BGA versions, qty 10, converted approximately to USD, sorted by price, only "interesting" chips chosen):

 

MSP430F5508IRGZR (16k): $2.87 <- that's the cheapest in the F55xx line

MSP430F5502IRGZR (24k): $3.46

MSP430F5509IRGZT (24k): $4.18

MSP430F5510IRGCR (32k, loaded): $4.60

 

Let's compare with G2 series pricing:

 

MSP430G2553IRHB32T (16k): $2.92

and my favorite:

MSP430G2412IRSA16T (8k): $0.99

 

Here's my takeaway from this:

 

1. Using the G2553 makes no sense. You can get an F5508 with the same amount of flash and WAY more peripherals, for less money.

 

2. For really cheap stuff, use the G2412. Can't beat the price on that one. I still intend to use it in projects whenever I can.

 

3. F5502 is a good value if you don't need the ADC.

 

On a more general note: it makes sense to either use the G2412 if you can, or go straight to F55xx. There really isn't much inbetween that makes sense. In my projects the two pivotal peripherals are USI/USCI and ADC. So either I can get away without an ADC and with a single USI -> go G2412 and stay cheap, or

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...