EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

USB driver for MSP430 Launch Pad Rev 1.5

Started by james osburn September 3, 2012
Is there a USB driver needed for the MSP430 Launch Pad board (rev 1.5)?

I am using the 32 bit version of Windows 7 professional.
James


Beginning Microcontrollers with the MSP430

On Mon, Sep 3, 2012 at 3:46 PM, james osburn wrote:

> Is there a USB driver needed for the MSP430 Launch Pad board (rev 1.5)?

I am pretty sure the answer here is yes, and that driver gets
installed with CCS.

-p.
Actually, there are two parts for this answer:

1. For the debugging port on the LaunchPad (i.e., to use it as a FET for
programming and debugging the target MSP430, either in the pluggable socket
on the PCB or connected externally), the answer is yes, and it's supposed
to be installed automatically by/with CCS. (You might have to find it --
not necessarily an easy task -- and install it manually if, for example,
you're using a GNU toolchain.)
2. For the serial COM port on the LaunchPad, for async IO with the
target chip, the answer is no. The port should show up as a standard COM
device with some port number, being driven by a standard MS driver. (I
never have figured out how WinXP decides what port number to use for it,
just look in the Control Panel | System | Hardware pane. Don't know if Win7
is more logical.)

Mike

On Mon, Sep 3, 2012 at 2:34 PM, Peter Johansson wrote:

> **
> On Mon, Sep 3, 2012 at 3:46 PM, james osburn
> wrote:
>
> > Is there a USB driver needed for the MSP430 Launch Pad board (rev 1.5)?
>
> I am pretty sure the answer here is yes, and that driver gets
> installed with CCS.
>
> -p.
>
>
>


On Mon, 3 Sep 2012 16:41:48 -0700, you wrote:

>Actually, there are two parts for this answer:
>
> 1. For the debugging port on the LaunchPad (i.e., to use it as a FET for
> programming and debugging the target MSP430, either in the pluggable socket
> on the PCB or connected externally), the answer is yes, and it's supposed
> to be installed automatically by/with CCS. (You might have to find it --
> not necessarily an easy task -- and install it manually if, for example,
> you're using a GNU toolchain.)
> 2. For the serial COM port on the LaunchPad, for async IO with the
> target chip, the answer is no. The port should show up as a standard COM
> device with some port number, being driven by a standard MS driver. (I
> never have figured out how WinXP decides what port number to use for it,
> just look in the Control Panel | System | Hardware pane. Don't know if Win7
> is more logical.)
>
>Mike

I think Windows designers felt constrained by some
assumptions they made about users of Windows. If I recall,
Windows will assign a port to a specific device ID on the
first install and then remember that association pretty much
forever, like it or not. So if you figure it out once, you
can bake it into your code if that code will only be used on
that system. What I do is simply enumerate all the ports and
ask the user which one.

I think Windows may ALSO support the device making a request
for specific virtual COM port positions -- but I haven't done
much with USB and have to admit I don't even know if that is
possible.

FTDI supplies useful tools for devices using their chips (not
the LaunchPad, though, which does not.) However, some of the
tools are STILL useful -- such as USBView. See the utilities
link below for that tool.

http://www.ftdichip.com/Support/Utilities.htm

It will be easy to see what is happening with that.

They also include tools to reassign their devices to
different COM ports. I'd love to see the source code for
that.

Jon
Jon,

On Mon, Sep 3, 2012 at 6:40 PM, Jon Kirwan wrote:

> **
> ...FTDI supplies useful tools for devices using their chips (not
> the LaunchPad, though, which does not.) However, some of the
> tools are STILL useful -- such as USBView. See the utilities
> link below for that tool.
>
> http://www.ftdichip.com/Support/Utilities.htm
>
> It will be easy to see what is happening with that.
>

Thanks for reminding me about the FTDI utilities. (Nice when a vendor
provides useful support software :-)
>
> They also include tools to reassign their devices to
> different COM ports. I'd love to see the source code for
> that.
>
> Jon
>

Yes, indeed.

Mike


On 04/09/12 03:40, Jon Kirwan wrote:
>
>
> On Mon, 3 Sep 2012 16:41:48 -0700, you wrote:
>
>>Actually, there are two parts for this answer:
>>
>> 1. For the debugging port on the LaunchPad (i.e., to use it as a FET for
>> programming and debugging the target MSP430, either in the pluggable
> socket
>> on the PCB or connected externally), the answer is yes, and it's supposed
>> to be installed automatically by/with CCS. (You might have to find it --
>> not necessarily an easy task -- and install it manually if, for example,
>> you're using a GNU toolchain.)
>> 2. For the serial COM port on the LaunchPad, for async IO with the
>> target chip, the answer is no. The port should show up as a standard COM
>> device with some port number, being driven by a standard MS driver. (I
>> never have figured out how WinXP decides what port number to use for it,
>> just look in the Control Panel | System | Hardware pane. Don't know if
> Win7
>> is more logical.)
>>
>>Mike
>
> I think Windows designers felt constrained by some
> assumptions they made about users of Windows. If I recall,
> Windows will assign a port to a specific device ID on the
> first install and then remember that association pretty much
> forever, like it or not. So if you figure it out once, you
> can bake it into your code if that code will only be used on
> that system. What I do is simply enumerate all the ports and
> ask the user which one.
>

That is the basic idea - once a particular USB device serial number has
been allocated a port on a particular machine, it keeps that same
number. Removing that link is a pain, involving searching through the
windows registry for various entries.

FTDI drivers can be modified to make the serial port number link to the
physical USB port rather than the device serial number. Sometimes this
can be more useful (it is particularly aimed at testing).

With Linux, the standard method is to give the USB device the next
serial device that is available at the time, but you can also set up
udev rules for specific devices if you want.

> I think Windows may ALSO support the device making a request
> for specific virtual COM port positions -- but I haven't done
> much with USB and have to admit I don't even know if that is
> possible.
>
> FTDI supplies useful tools for devices using their chips (not
> the LaunchPad, though, which does not.) However, some of the
> tools are STILL useful -- such as USBView. See the utilities
> link below for that tool.
>
> http://www.ftdichip.com/Support/Utilities.htm
>
> It will be easy to see what is happening with that.
>
> They also include tools to reassign their devices to
> different COM ports. I'd love to see the source code for
> that.
>

I think this sort of thing is specific to FTDI devices, rather than
general for all USB serial ports. There is no common driver for these
things in Windows (unlike USB mice or keyboards, for example), so each
manufacturer can add features that they want.

On Tue, 4 Sep 2012 10:05:07 +0200, you wrote:

>>
>> I think Windows may ALSO support the device making a request
>> for specific virtual COM port positions -- but I haven't done
>> much with USB and have to admit I don't even know if that is
>> possible.
>>
>> FTDI supplies useful tools for devices using their chips (not
>> the LaunchPad, though, which does not.) However, some of the
>> tools are STILL useful -- such as USBView. See the utilities
>> link below for that tool.
>>
>> http://www.ftdichip.com/Support/Utilities.htm
>>
>> It will be easy to see what is happening with that.
>>
>> They also include tools to reassign their devices to
>> different COM ports. I'd love to see the source code for
>> that.
>
>I think this sort of thing is specific to FTDI devices, rather than
>general for all USB serial ports. There is no common driver for these
>things in Windows (unlike USB mice or keyboards, for example), so each
>manufacturer can add features that they want.

I've been using the USBView tool just fine with non-FTDI
devices.

Or, at least, I perceive that I have been.

Jon
On 4/09/2012 4:48 PM, Jon Kirwan wrote:
I was following this thread with interest as I am trying to get a USB
device working from a FET and RS232 level shifter. I can output ASCII
characters to a PC ok and receive in TeraTerm or a similar program. I
purchased a CP2104 evaluation kit and have been trying this. It goes
from my FET to my MSP430F149 thru a Level shifter then out of this to a
USB port on the PC. I assume the driver is built into the CP2104. I can
use USBviewer and look at the evaluation board but how do I see data
that goes from my MSP430 to the PC. If I am send serial data I can use
TeraTerm or Hyperterminal. What do you do for USB?

TIA

Peter
> On Tue, 4 Sep 2012 10:05:07 +0200, you wrote:
>
>>>
>>> I think Windows may ALSO support the device making a request
>>> for specific virtual COM port positions -- but I haven't done
>>> much with USB and have to admit I don't even know if that is
>>> possible.
>>>
>>> FTDI supplies useful tools for devices using their chips (not
>>> the LaunchPad, though, which does not.) However, some of the
>>> tools are STILL useful -- such as USBView. See the utilities
>>> link below for that tool.
>>>
>>> http://www.ftdichip.com/Support/Utilities.htm
>>>
>>> It will be easy to see what is happening with that.
>>>
>>> They also include tools to reassign their devices to
>>> different COM ports. I'd love to see the source code for
>>> that.
>> I think this sort of thing is specific to FTDI devices, rather than
>> general for all USB serial ports. There is no common driver for these
>> things in Windows (unlike USB mice or keyboards, for example), so each
>> manufacturer can add features that they want.
> I've been using the USBView tool just fine with non-FTDI
> devices.
>
> Or, at least, I perceive that I have been.
>
> Jon
>
On Fri, 07 Sep 2012 15:23:04 +0800, Peter wrote:

>I was following this thread with interest as I am trying to get a USB
>device working from a FET and RS232 level shifter. I can output ASCII
>characters to a PC ok and receive in TeraTerm or a similar program. I
>purchased a CP2104 evaluation kit and have been trying this. It goes
>from my FET to my MSP430F149 thru a Level shifter then out of this to a
>USB port on the PC. I assume the driver is built into the CP2104. I can
>use USBviewer and look at the evaluation board but how do I see data
>that goes from my MSP430 to the PC. If I am send serial data I can use
>TeraTerm or Hyperterminal. What do you do for USB?
>
>TIA

I used the LaunchPad unit and its virtual COM port for
communications with the PC. The MSP430 is programmed to use
the Rx and Tx pins as asynch serial, but there are no level
shifters for genuine RS-232 involved here. They use a
TUSB3410 plus a custom programmed MSP430F1612 to do all the
interfacing for me.

If I needed to (I never did, since the code 'just worked' as
I intended), I would grab up my HP 54645D and scope out some
digital pins (like the Rx and Tx and probably a few others
I'd use for additional 'information'.)

I don't have any decent software for monitoring USB driver
communications on the PC side, though. Or... maybe I do, but
don't know I do. I do have software that allows monitoring
the virtual COM port communications. But nothing much deeper
than seeing what is going both ways. I don't use TeraTerm or
HyperTerm. I use ucon, instead. It's designed as an embedded
RS-232 monitor (which means it doesn't cook the books much)
and I prefer it.

There are some interesting web pages on USB that you might
also look at, if you want to try USB without going through
someone else's slave USB hardware and software:

http://www.obdev.at/products/vusb/index.html
http://www.lendlocus.com/?qfusb
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId&80&dDocName=en537044

Although I've been interested in digging deeper (the USB
manual is OVER 1000 pages long), I've not bitten that off
just yet. When I get some time, perhaps. USB is something of
a specialty if you aren't using FTDI or some specialized chip
and instead are doing all the driver work on both sides (or
just one side if depending on standard Windows HID drivers.)

Jon
On 7/09/2012 5:02 PM, Jon Kirwan wrote:
Jon,

I believe I have the answer for this. I am trying to get a MSP430 to
talk with a USB enabled device (satellite modem) and I obviously cannot
load the drivers into the MSP430. Thus I cannot use it. As I see it the
USB standard was designed to get rid of parallel and serial ports from
the PC (& other computers). It was not designed for peer to peer
communications. I did notice that around 2004 a standard of
USB-On-The-GO (USB-OTG) was suggested to get over this problem. I have
yet to get any reliable information on this but will continue to search.

Thanks

Peter
On Fri, 07 Sep 2012 15:23:04 +0800, Peter wrote:
>> I was following this thread with interest as I am trying to get a USB
>> device working from a FET and RS232 level shifter. I can output ASCII
>> characters to a PC ok and receive in TeraTerm or a similar program. I
>> purchased a CP2104 evaluation kit and have been trying this. It goes
> >from my FET to my MSP430F149 thru a Level shifter then out of this to a
>> USB port on the PC. I assume the driver is built into the CP2104. I can
>> use USBviewer and look at the evaluation board but how do I see data
>> that goes from my MSP430 to the PC. If I am send serial data I can use
>> TeraTerm or Hyperterminal. What do you do for USB?
>>
>> TIA
> I used the LaunchPad unit and its virtual COM port for
> communications with the PC. The MSP430 is programmed to use
> the Rx and Tx pins as asynch serial, but there are no level
> shifters for genuine RS-232 involved here. They use a
> TUSB3410 plus a custom programmed MSP430F1612 to do all the
> interfacing for me.
>
> If I needed to (I never did, since the code 'just worked' as
> I intended), I would grab up my HP 54645D and scope out some
> digital pins (like the Rx and Tx and probably a few others
> I'd use for additional 'information'.)
>
> I don't have any decent software for monitoring USB driver
> communications on the PC side, though. Or... maybe I do, but
> don't know I do. I do have software that allows monitoring
> the virtual COM port communications. But nothing much deeper
> than seeing what is going both ways. I don't use TeraTerm or
> HyperTerm. I use ucon, instead. It's designed as an embedded
> RS-232 monitor (which means it doesn't cook the books much)
> and I prefer it.
>
> There are some interesting web pages on USB that you might
> also look at, if you want to try USB without going through
> someone else's slave USB hardware and software:
>
> http://www.obdev.at/products/vusb/index.html
> http://www.lendlocus.com/?qfusb
> http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId&80&dDocName=en537044
>
> Although I've been interested in digging deeper (the USB
> manual is OVER 1000 pages long), I've not bitten that off
> just yet. When I get some time, perhaps. USB is something of
> a specialty if you aren't using FTDI or some specialized chip
> and instead are doing all the driver work on both sides (or
> just one side if depending on standard Windows HID drivers.)
>
> Jon
>

The 2024 Embedded Online Conference