I want to build a hardware interface using the F2013 that communicates
bidirectionally with a visual basic program that talks to virtual com3
using the ez430 usb development tool.
I can't figure out how to get the msp430 to read/write the virtual
serial
port via the eZ430.
Is there a tutorial or app note on this?
All I've found are a couple of promising broken links.
Yes, I know there's no HW uart, but there is a sw library for one.
But, with any luck, all I gotta do is write bytes to the proper API call.
Serial: msp430 >> eZ430 >> USB >> MSP-FET430UIF(com3) >> VB program on Com3??
Started by ●March 21, 2011
Reply by ●March 21, 20112011-03-21
If you plan to use the programming dongle anyway why not just reflash
the micro in the dongle? There is a hardware USB interface there. If not
then why not add a simple USB part like the CP2102. Heck if you didn't
know how to reflash the dongle you could probably remove the micro and
rewire the 2013 to the USB interface. I know you're trying to use the
programming port to return data to the PC, but this makes no long term
sense as you are tying up a programming dongle to use a feature that
doesn't seem to be well supported anyway, and therefore may not last
through the next firmware upgrade of the dongle micro.
Al
On 21/03/2011 2:37 PM, spamme0 wrote:
> I want to build a hardware interface using the F2013 that communicates
> bidirectionally with a visual basic program that talks to virtual com3
> using the ez430 usb development tool.
>
> I can't figure out how to get the msp430 to read/write the virtual serial
> port via the eZ430.
>
> Is there a tutorial or app note on this?
> All I've found are a couple of promising broken links.
>
> Yes, I know there's no HW uart, but there is a sw library for one.
> But, with any luck, all I gotta do is write bytes to the proper API call.
>
>
the micro in the dongle? There is a hardware USB interface there. If not
then why not add a simple USB part like the CP2102. Heck if you didn't
know how to reflash the dongle you could probably remove the micro and
rewire the 2013 to the USB interface. I know you're trying to use the
programming port to return data to the PC, but this makes no long term
sense as you are tying up a programming dongle to use a feature that
doesn't seem to be well supported anyway, and therefore may not last
through the next firmware upgrade of the dongle micro.
Al
On 21/03/2011 2:37 PM, spamme0 wrote:
> I want to build a hardware interface using the F2013 that communicates
> bidirectionally with a visual basic program that talks to virtual com3
> using the ez430 usb development tool.
>
> I can't figure out how to get the msp430 to read/write the virtual serial
> port via the eZ430.
>
> Is there a tutorial or app note on this?
> All I've found are a couple of promising broken links.
>
> Yes, I know there's no HW uart, but there is a sw library for one.
> But, with any luck, all I gotta do is write bytes to the proper API call.
>
>
Reply by ●March 21, 20112011-03-21
On Mon, 21 Mar 2011 04:07:29 -0000, spamme0 wrote:
>I want to build a hardware interface using the F2013 that communicates
>bidirectionally with a visual basic program that talks to virtual com3
>using the ez430 usb development tool.
>
>I can't figure out how to get the msp430 to read/write the virtual serial
>port via the eZ430.
>
>Is there a tutorial or app note on this?
>All I've found are a couple of promising broken links.
>
>Yes, I know there's no HW uart, but there is a sw library for one.
>But, with any luck, all I gotta do is write bytes to the proper API call.
It sounds like your eZ430-F2013 unit includes Rev 2.0 of the
MSP-EZ430U debugging interface board, since a virtual COM
port comes up. My recollection is that the Rev 1.x boards do
not show a virtual COM port. But I could be wrong on that.
If you have an older eZ430-F2013 unit that sports only four
pins from the MSP-EZ430U debugging interface board (in other
words, Rev 1.x) and if I'm right in the above comment, then I
believe there is a need to update the firmware on it (both
the Rev 1.x and Rev 2.0 units use the F1612 stepping B parts
so that part should be okay) and a need to update the
hardware with a couple of resistors and some wiring. The
firmware issue I haven't researched, but the newer Rev 2.0
devices fire up on a PC with a virtual COM port set up. As I
said, I don't recall that happening with the Rev 1.0 and 1.1
systems, so that's why I think some kind of software update
is needed. This means getting access to a binary of the Rev
2.0 and creating a programming adapter for a 4-wire
programmer (which you will also need) that is needed to
download the new code into the F1612 chip. Then modifying
the hardware, also, to add the two series 100 ohm resistors
to pins 34 and 35 (underneath side of the board) and bring
the other ends over where you can get at them for your F2013
(the detachable target board) to access.
In short, some work is needed but it may be doable in the
end.
I don't know if TI supplies the binary, but I suspect not.
But maybe a search may turn it up. Without it, you'd need to
write your own code or perhaps (haven't tried) consider this:
http://homepage.mac.com/skimu/msp430/dfw/
It may also be possible that the binary from a Rev 2.0 board
can be extracted from the EZ430U debugging interface board's
F1612 using some of the instructions from the above page. And
then applied to an older Rev 1.x board. But it may be locked
for all I know. Worth a try, perhaps.
Okay. Enough on the older boards. Sounds like you have one
of the newer ones (Rev 2.0) with six pins on the header and
the outside pins for Rx and Tx [and probably a fixed data
rate (9600bps, I vaguely recall.)] In that case, you don't
have to do anything much except connect header pin 1 and
header pin 6 over onto your target board and then write some
software to "bit bang" the RS-232. For that, you probably
can get by with the source code for the LaunchPad system.
Their source code files can be picked up in slac435.zip from
TI, I think. Grab the main.c file from there and do some
reading.
Once you have the F2013 software written, compiled, and
loaded up, and the target board wired to the RX and TX header
pins of a Rev 2.0 debugging interface board and all that
plugged into the PC's USB port, I suspect all you need to do
in VB.NET is use the API for COM port communications. With
the older VB 6.0 and with VB.NET 1.1, I think you used MSComm
Control to do that. With VB.NET 2.0 and above, you have the
SerialPort class within the System.IO.Ports namespace. I
don't imagine any problems there.
Jon
>I want to build a hardware interface using the F2013 that communicates
>bidirectionally with a visual basic program that talks to virtual com3
>using the ez430 usb development tool.
>
>I can't figure out how to get the msp430 to read/write the virtual serial
>port via the eZ430.
>
>Is there a tutorial or app note on this?
>All I've found are a couple of promising broken links.
>
>Yes, I know there's no HW uart, but there is a sw library for one.
>But, with any luck, all I gotta do is write bytes to the proper API call.
It sounds like your eZ430-F2013 unit includes Rev 2.0 of the
MSP-EZ430U debugging interface board, since a virtual COM
port comes up. My recollection is that the Rev 1.x boards do
not show a virtual COM port. But I could be wrong on that.
If you have an older eZ430-F2013 unit that sports only four
pins from the MSP-EZ430U debugging interface board (in other
words, Rev 1.x) and if I'm right in the above comment, then I
believe there is a need to update the firmware on it (both
the Rev 1.x and Rev 2.0 units use the F1612 stepping B parts
so that part should be okay) and a need to update the
hardware with a couple of resistors and some wiring. The
firmware issue I haven't researched, but the newer Rev 2.0
devices fire up on a PC with a virtual COM port set up. As I
said, I don't recall that happening with the Rev 1.0 and 1.1
systems, so that's why I think some kind of software update
is needed. This means getting access to a binary of the Rev
2.0 and creating a programming adapter for a 4-wire
programmer (which you will also need) that is needed to
download the new code into the F1612 chip. Then modifying
the hardware, also, to add the two series 100 ohm resistors
to pins 34 and 35 (underneath side of the board) and bring
the other ends over where you can get at them for your F2013
(the detachable target board) to access.
In short, some work is needed but it may be doable in the
end.
I don't know if TI supplies the binary, but I suspect not.
But maybe a search may turn it up. Without it, you'd need to
write your own code or perhaps (haven't tried) consider this:
http://homepage.mac.com/skimu/msp430/dfw/
It may also be possible that the binary from a Rev 2.0 board
can be extracted from the EZ430U debugging interface board's
F1612 using some of the instructions from the above page. And
then applied to an older Rev 1.x board. But it may be locked
for all I know. Worth a try, perhaps.
Okay. Enough on the older boards. Sounds like you have one
of the newer ones (Rev 2.0) with six pins on the header and
the outside pins for Rx and Tx [and probably a fixed data
rate (9600bps, I vaguely recall.)] In that case, you don't
have to do anything much except connect header pin 1 and
header pin 6 over onto your target board and then write some
software to "bit bang" the RS-232. For that, you probably
can get by with the source code for the LaunchPad system.
Their source code files can be picked up in slac435.zip from
TI, I think. Grab the main.c file from there and do some
reading.
Once you have the F2013 software written, compiled, and
loaded up, and the target board wired to the RX and TX header
pins of a Rev 2.0 debugging interface board and all that
plugged into the PC's USB port, I suspect all you need to do
in VB.NET is use the API for COM port communications. With
the older VB 6.0 and with VB.NET 1.1, I think you used MSComm
Control to do that. With VB.NET 2.0 and above, you have the
SerialPort class within the System.IO.Ports namespace. I
don't imagine any problems there.
Jon
Reply by ●March 23, 20112011-03-23
It depends on how many you need, if the answer is just 1 or a handful
then not. So you need to buy the RF version of the dongle from Ti, not
the 2013 version.
I have just had 50 USB dongles built, PCB, USB interface, MSP430F2254,
all parts, etc and average cost works out to less than $17 each
including shipping.
Al
On 22/03/2011 5:43 AM, spamme0 wrote:
>
> --- In m..., OneStone wrote:
>> If you plan to use the programming dongle anyway why not just reflash
>> the micro in the dongle? There is a hardware USB interface there. If not
>> then why not add a simple USB part like the CP2102. Heck if you didn't
>> know how to reflash the dongle you could probably remove the micro and
>> rewire the 2013 to the USB interface. I know you're trying to use the
>> programming port to return data to the PC, but this makes no long term
>> sense as you are tying up a programming dongle to use a feature that
>> doesn't seem to be well supported anyway, and therefore may not last
>> through the next firmware upgrade of the dongle micro.
>>
>> Al
> Where am I gonna get a fully functional USB dongle with
> virtual serial driver that interfaces with a processor for $20?
>
> And I can remove the $3 processor board if it doesn't need the
> interface. No build a circuit board, mounting of tiny SMT parts,
> no power supply, no packaging...and on and on.
> Sure beats the heck out of a 40-pin DIP processor and all the
> support it takes to make it a complete packaged device.
> If I don't update the firmware of the dongle, I shouldn't care
> about changes to the dongle firmware???
>
> Sounds like a no-brainer. IF there's an easy way to access
> the virtual serial port from the target micro. Doesn't have to
> be well supported, just doable. My objective is to write
> code for the target that calls some existing functions inside the dongle
> to do the communication.
> The functions have to be in there because the debugger can
> access registers inside the target and send the data over the
> usb interface. And there's no hardware uart in the target and
> no space for software emulation. So I shouldn't need hardware
> of software uart in the target processor, just use the same
> mechanism that exists for the debugger.
>
> Whether those functions are accessible is another matter, and the
> point of this question.
>
>
then not. So you need to buy the RF version of the dongle from Ti, not
the 2013 version.
I have just had 50 USB dongles built, PCB, USB interface, MSP430F2254,
all parts, etc and average cost works out to less than $17 each
including shipping.
Al
On 22/03/2011 5:43 AM, spamme0 wrote:
>
> --- In m..., OneStone wrote:
>> If you plan to use the programming dongle anyway why not just reflash
>> the micro in the dongle? There is a hardware USB interface there. If not
>> then why not add a simple USB part like the CP2102. Heck if you didn't
>> know how to reflash the dongle you could probably remove the micro and
>> rewire the 2013 to the USB interface. I know you're trying to use the
>> programming port to return data to the PC, but this makes no long term
>> sense as you are tying up a programming dongle to use a feature that
>> doesn't seem to be well supported anyway, and therefore may not last
>> through the next firmware upgrade of the dongle micro.
>>
>> Al
> Where am I gonna get a fully functional USB dongle with
> virtual serial driver that interfaces with a processor for $20?
>
> And I can remove the $3 processor board if it doesn't need the
> interface. No build a circuit board, mounting of tiny SMT parts,
> no power supply, no packaging...and on and on.
> Sure beats the heck out of a 40-pin DIP processor and all the
> support it takes to make it a complete packaged device.
> If I don't update the firmware of the dongle, I shouldn't care
> about changes to the dongle firmware???
>
> Sounds like a no-brainer. IF there's an easy way to access
> the virtual serial port from the target micro. Doesn't have to
> be well supported, just doable. My objective is to write
> code for the target that calls some existing functions inside the dongle
> to do the communication.
> The functions have to be in there because the debugger can
> access registers inside the target and send the data over the
> usb interface. And there's no hardware uart in the target and
> no space for software emulation. So I shouldn't need hardware
> of software uart in the target processor, just use the same
> mechanism that exists for the debugger.
>
> Whether those functions are accessible is another matter, and the
> point of this question.
>
>
Reply by ●March 23, 20112011-03-23
On Mon, 21 Mar 2011 20:24:01 -0000, spamme0 wrote:
>--- In m..., Jon Kirwan wrote:
>>
>> On Mon, 21 Mar 2011 04:07:29 -0000, spamme0 wrote:
>>
>> >I want to build a hardware interface using the F2013 that communicates
>> >bidirectionally with a visual basic program that talks to virtual com3
>> >using the ez430 usb development tool.
>> >
>> >I can't figure out how to get the msp430 to read/write the virtual serial
>> >port via the eZ430.
>> >
>> >Is there a tutorial or app note on this?
>> >All I've found are a couple of promising broken links.
>> >
>> >Yes, I know there's no HW uart, but there is a sw library for one.
>> >But, with any luck, all I gotta do is write bytes to the proper API call.
>>
>> It sounds like your eZ430-F2013 unit includes Rev 2.0 of the
>> MSP-EZ430U debugging interface board, since a virtual COM
>> port comes up. My recollection is that the Rev 1.x boards do
>> not show a virtual COM port. But I could be wrong on that.
>>
>> If you have an older eZ430-F2013 unit that sports only four
>> pins from the MSP-EZ430U debugging interface board (in other
>> words, Rev 1.x) and if I'm right in the above comment, then I
>> believe there is a need to update the firmware on it (both
>> the Rev 1.x and Rev 2.0 units use the F1612 stepping B parts
>> so that part should be okay) and a need to update the
>> hardware with a couple of resistors and some wiring. The
>> firmware issue I haven't researched, but the newer Rev 2.0
>> devices fire up on a PC with a virtual COM port set up. As I
>> said, I don't recall that happening with the Rev 1.0 and 1.1
>> systems, so that's why I think some kind of software update
>> is needed. This means getting access to a binary of the Rev
>> 2.0 and creating a programming adapter for a 4-wire
>> programmer (which you will also need) that is needed to
>> download the new code into the F1612 chip. Then modifying
>> the hardware, also, to add the two series 100 ohm resistors
>> to pins 34 and 35 (underneath side of the board) and bring
>> the other ends over where you can get at them for your F2013
>> (the detachable target board) to access.
>>
>> In short, some work is needed but it may be doable in the
>> end.
>>
>> I don't know if TI supplies the binary, but I suspect not.
>> But maybe a search may turn it up. Without it, you'd need to
>> write your own code or perhaps (haven't tried) consider this:
>>
>> http://homepage.mac.com/skimu/msp430/dfw/
>>
>> It may also be possible that the binary from a Rev 2.0 board
>> can be extracted from the EZ430U debugging interface board's
>> F1612 using some of the instructions from the above page. And
>> then applied to an older Rev 1.x board. But it may be locked
>> for all I know. Worth a try, perhaps.
>>
>> Okay. Enough on the older boards. Sounds like you have one
>> of the newer ones (Rev 2.0) with six pins on the header and
>> the outside pins for Rx and Tx [and probably a fixed data
>> rate (9600bps, I vaguely recall.)] In that case, you don't
>> have to do anything much except connect header pin 1 and
>> header pin 6 over onto your target board and then write some
>> software to "bit bang" the RS-232. For that, you probably
>> can get by with the source code for the LaunchPad system.
>> Their source code files can be picked up in slac435.zip from
>> TI, I think. Grab the main.c file from there and do some
>> reading.
>>
>> Once you have the F2013 software written, compiled, and
>> loaded up, and the target board wired to the RX and TX header
>> pins of a Rev 2.0 debugging interface board and all that
>> plugged into the PC's USB port, I suspect all you need to do
>> in VB.NET is use the API for COM port communications. With
>> the older VB 6.0 and with VB.NET 1.1, I think you used MSComm
>> Control to do that. With VB.NET 2.0 and above, you have the
>> SerialPort class within the System.IO.Ports namespace. I
>> don't imagine any problems there.
>>
>> Jon
>>Thanks for the input.
>My EZ430-F2013 board has the 4-pin interface.
Too bad. That's the old unit. I've got a bunch of them,
too. But I also have six of the newer ones, as well, along
with some of the -RF2500 and what comes with the Chronos.
>But I do have a EZ430-RF2500 with the 6-pin
>interface.
That will do it.
>There's lots of confusing info on the web,
>but I think I understood that the programming side of
>the dongle is the same for the -2013 and the -RF2500,
>given the latest rev.
Yes, given the latest rev. 2.0.
>It's getting harder to find a PC or a PDA with a
>hardware serial port.
Yup.
>USB is attractive for that reason only.
Yup.
>My REAL objective is to get the -RF2500 repurposed for
>data acquisition.
Easy to do. You've got everything you need except your
application code and the ground, tx, and rx lines cabled up.
>I'm currently using a Bluetooth/serial
>converter on a PIC. It works, but it uses way too much power
>to be battery operated. RF2500 looks attractive there.
Do you require RF? I know you are currently using it, but
that doesn't tell me if you require it. You may be okay with
something wired over.
>I figured it would be easy to leave
>all the existing demo code in place to manage the radio channel
>and just find where to input/retrieve bytes from the radio.
>I was OPTIMISTIC!! I got totally lost in the dozens of files
>that made up the demo. So, I backed off to the direct hardware
>connection of the -2013 demo. Baby steps...
Look at the LaunchPad file I recommended to you. In fact,
BUY a LaunchPad!! It has the serial port, as well. You can
use it and just ignore the processor target section there.
In any case, they provide serial port code for you. Go get
it. It's all in one file. Very simple.
>I'm a BASIC programmer. I've been
>using PICBasic on a PIC16F877A. Most of my programs are
>a dozen lines of uC code that reads/writes I/O ports,
>and uses the RS232 port
>and a PDA or PC to do the heavy lifting. The MSP430
>is attractive because I have one, it has multiple sleep
>modes and the target board is half the price and
>way easier to package than
>a 40-pin dip PIC and all the peripheral stuff it takes
>to make it go. And it's motivation to finally learn the
>"C" environment.
Okay.
>"C", or assembler, is
>simple enough for the stuff I need, but I get horribly
>lost in pragmas and resource files and .h files and compiler
>options and assembler options and linker options and all
>the complexity it takes to get a 5-line program compiled
>and downloaded to the target. I failed in my attempt to get
>a visual C++ "hello world" program for a PDA to say
>"goodbye cruel world".
>There's gotta be a sting in there somewhere, but I never
>found it. I do have a short attention span.
If you buy the LaunchPad ($4.30 shipped), you will have your
target system to try out your code on, together with the USB
to RS-232 stuff that accesses the PC's HID drivers and allows
you to use VB.NET on the PC side. In short, you write simple
code on the PC in VB.NET to talk with your target device. And
they give you pretty much all the code you need to at least
do a "hello world" real quick, all for just $4.30. You can't
beat that with a stick.
>Since my last posting, I
>have successfully compiled and downloaded two demo programs
>to the eZ430 using IAR.
Okay.
>Somehow, the debugger can access the insides of the target processor
>through the 4-pin interface.
Better than that. There is +3.3V and ground pins there so
they do it all with just two more wires. It's a 2-wire JTAG.
Fancy.
>It's serial, but probably not RS-232.
Correct. And the debugging access is proprietary, so don't
worry about trying to find out much on that score (or if you
do and succeed, let me know the details!)
>I was hoping that I could use that same serial interface
>from the target end to access some API inside the programmer part
>of the dongle to get bytes to show up at the PC virtual com port
>accessible from VB6.
No. That is the JTAG. It's not for communicating to the PC.
You need TWO MORE wires for that. And you need to write
code. And you need a device that will mediate between your
asynch communications and the USB HIB drivers on the PC,
which means you need that -RF2500, or newer -F2013, or
LaunchPad.
>I've got no problem with the VB6 side. I'm confident I can make
>the target functions work. It's a matter of knowing what I need to
>send to the dongle from the PC and/or the target to set up the
>communication path and get data in/out of it.
I mentioned the classes for you. Read docs, check out
example code that deals with that.
>You've suggested that, with the 6-pin interface, I can get
>9600 baud RS232 out of the target into the dongle.
Yes. I believe they ONLY support 9600 bps (I hate using
'baud' here because it has a precise meaning in
communications technology where bps <> baud, at times.) So
no options here, until and unless they decide to update their
drivers.
>I found a serial uart library slaa307a.zip for the target.
>Does serial in/out of the two extra interface pins to the
>dongle automagically show up at the virtual serial port
>on the PC?
I've not looked at the slaa307a.zip code. Just the one I
mentioned earlier regarding the LaunchPad system. It's all
in the main.c file there.
But yes, the essential idea here is that you need code to
"bit bang" the RS-232 asynch protocol at 9600 bps. Once you
have that, you need to tie the pins you selected over to the
right pins on that 6-pin header and just let it fly.
I'd recommend, of course, first using a "dumb terminal"
program of some kind on your PC side of things. And if you
like, you should also download usbview.exe from the FTDI web
site. It is VERY HANDY for making sure you know which COM
port has been set up for you. (Free, too.)
>Or is there some setup required in the dongle?
No. It's plug and play.
>I really, really don't want to have to try to rewrite the dongle
>code. The idea is to make things simpler...or at least not
>much more complex than a basic program into a bootloader into a pic.
>
>I'm asking a lot of simple questions. I'm trying to determine
>whether my goal is reasonable before I invest what few brain cells
>I have left in learning a whole new uC. Thanks for hanging in there.
>mike
Buy the LaunchPad, as your nifty serial port wires are
already there AND wired over to your target IC in a nice
socket. You can just plug that thing in and start right away
doing code. Get the usbview.exe file, too. And get the
source code from slac435.zip (in main.c there) as a starting
point. You just install IAR kickstart, install that zip
file's set of files, load up the project, compile and go.
(Also, of course, have some dumb terminal program running and
attached to the COM port you find with usbview.exe.) Once
you've got that up and running, you are already using the
serial port and you can type and see. That done, work on
your VB.NET or VB 6.0 code to replace your dumb terminal
program. If that works okay, then you now have something
working in your own VB code and something working on a target
processor. At that point, you can attempt to move the whole
thing over to the -F2013 target board, if you like, and power
it from your LaunchPad and use it's 6-wire interface for
talking. Etc.
Jon
>--- In m..., Jon Kirwan wrote:
>>
>> On Mon, 21 Mar 2011 04:07:29 -0000, spamme0 wrote:
>>
>> >I want to build a hardware interface using the F2013 that communicates
>> >bidirectionally with a visual basic program that talks to virtual com3
>> >using the ez430 usb development tool.
>> >
>> >I can't figure out how to get the msp430 to read/write the virtual serial
>> >port via the eZ430.
>> >
>> >Is there a tutorial or app note on this?
>> >All I've found are a couple of promising broken links.
>> >
>> >Yes, I know there's no HW uart, but there is a sw library for one.
>> >But, with any luck, all I gotta do is write bytes to the proper API call.
>>
>> It sounds like your eZ430-F2013 unit includes Rev 2.0 of the
>> MSP-EZ430U debugging interface board, since a virtual COM
>> port comes up. My recollection is that the Rev 1.x boards do
>> not show a virtual COM port. But I could be wrong on that.
>>
>> If you have an older eZ430-F2013 unit that sports only four
>> pins from the MSP-EZ430U debugging interface board (in other
>> words, Rev 1.x) and if I'm right in the above comment, then I
>> believe there is a need to update the firmware on it (both
>> the Rev 1.x and Rev 2.0 units use the F1612 stepping B parts
>> so that part should be okay) and a need to update the
>> hardware with a couple of resistors and some wiring. The
>> firmware issue I haven't researched, but the newer Rev 2.0
>> devices fire up on a PC with a virtual COM port set up. As I
>> said, I don't recall that happening with the Rev 1.0 and 1.1
>> systems, so that's why I think some kind of software update
>> is needed. This means getting access to a binary of the Rev
>> 2.0 and creating a programming adapter for a 4-wire
>> programmer (which you will also need) that is needed to
>> download the new code into the F1612 chip. Then modifying
>> the hardware, also, to add the two series 100 ohm resistors
>> to pins 34 and 35 (underneath side of the board) and bring
>> the other ends over where you can get at them for your F2013
>> (the detachable target board) to access.
>>
>> In short, some work is needed but it may be doable in the
>> end.
>>
>> I don't know if TI supplies the binary, but I suspect not.
>> But maybe a search may turn it up. Without it, you'd need to
>> write your own code or perhaps (haven't tried) consider this:
>>
>> http://homepage.mac.com/skimu/msp430/dfw/
>>
>> It may also be possible that the binary from a Rev 2.0 board
>> can be extracted from the EZ430U debugging interface board's
>> F1612 using some of the instructions from the above page. And
>> then applied to an older Rev 1.x board. But it may be locked
>> for all I know. Worth a try, perhaps.
>>
>> Okay. Enough on the older boards. Sounds like you have one
>> of the newer ones (Rev 2.0) with six pins on the header and
>> the outside pins for Rx and Tx [and probably a fixed data
>> rate (9600bps, I vaguely recall.)] In that case, you don't
>> have to do anything much except connect header pin 1 and
>> header pin 6 over onto your target board and then write some
>> software to "bit bang" the RS-232. For that, you probably
>> can get by with the source code for the LaunchPad system.
>> Their source code files can be picked up in slac435.zip from
>> TI, I think. Grab the main.c file from there and do some
>> reading.
>>
>> Once you have the F2013 software written, compiled, and
>> loaded up, and the target board wired to the RX and TX header
>> pins of a Rev 2.0 debugging interface board and all that
>> plugged into the PC's USB port, I suspect all you need to do
>> in VB.NET is use the API for COM port communications. With
>> the older VB 6.0 and with VB.NET 1.1, I think you used MSComm
>> Control to do that. With VB.NET 2.0 and above, you have the
>> SerialPort class within the System.IO.Ports namespace. I
>> don't imagine any problems there.
>>
>> Jon
>>Thanks for the input.
>My EZ430-F2013 board has the 4-pin interface.
Too bad. That's the old unit. I've got a bunch of them,
too. But I also have six of the newer ones, as well, along
with some of the -RF2500 and what comes with the Chronos.
>But I do have a EZ430-RF2500 with the 6-pin
>interface.
That will do it.
>There's lots of confusing info on the web,
>but I think I understood that the programming side of
>the dongle is the same for the -2013 and the -RF2500,
>given the latest rev.
Yes, given the latest rev. 2.0.
>It's getting harder to find a PC or a PDA with a
>hardware serial port.
Yup.
>USB is attractive for that reason only.
Yup.
>My REAL objective is to get the -RF2500 repurposed for
>data acquisition.
Easy to do. You've got everything you need except your
application code and the ground, tx, and rx lines cabled up.
>I'm currently using a Bluetooth/serial
>converter on a PIC. It works, but it uses way too much power
>to be battery operated. RF2500 looks attractive there.
Do you require RF? I know you are currently using it, but
that doesn't tell me if you require it. You may be okay with
something wired over.
>I figured it would be easy to leave
>all the existing demo code in place to manage the radio channel
>and just find where to input/retrieve bytes from the radio.
>I was OPTIMISTIC!! I got totally lost in the dozens of files
>that made up the demo. So, I backed off to the direct hardware
>connection of the -2013 demo. Baby steps...
Look at the LaunchPad file I recommended to you. In fact,
BUY a LaunchPad!! It has the serial port, as well. You can
use it and just ignore the processor target section there.
In any case, they provide serial port code for you. Go get
it. It's all in one file. Very simple.
>I'm a BASIC programmer. I've been
>using PICBasic on a PIC16F877A. Most of my programs are
>a dozen lines of uC code that reads/writes I/O ports,
>and uses the RS232 port
>and a PDA or PC to do the heavy lifting. The MSP430
>is attractive because I have one, it has multiple sleep
>modes and the target board is half the price and
>way easier to package than
>a 40-pin dip PIC and all the peripheral stuff it takes
>to make it go. And it's motivation to finally learn the
>"C" environment.
Okay.
>"C", or assembler, is
>simple enough for the stuff I need, but I get horribly
>lost in pragmas and resource files and .h files and compiler
>options and assembler options and linker options and all
>the complexity it takes to get a 5-line program compiled
>and downloaded to the target. I failed in my attempt to get
>a visual C++ "hello world" program for a PDA to say
>"goodbye cruel world".
>There's gotta be a sting in there somewhere, but I never
>found it. I do have a short attention span.
If you buy the LaunchPad ($4.30 shipped), you will have your
target system to try out your code on, together with the USB
to RS-232 stuff that accesses the PC's HID drivers and allows
you to use VB.NET on the PC side. In short, you write simple
code on the PC in VB.NET to talk with your target device. And
they give you pretty much all the code you need to at least
do a "hello world" real quick, all for just $4.30. You can't
beat that with a stick.
>Since my last posting, I
>have successfully compiled and downloaded two demo programs
>to the eZ430 using IAR.
Okay.
>Somehow, the debugger can access the insides of the target processor
>through the 4-pin interface.
Better than that. There is +3.3V and ground pins there so
they do it all with just two more wires. It's a 2-wire JTAG.
Fancy.
>It's serial, but probably not RS-232.
Correct. And the debugging access is proprietary, so don't
worry about trying to find out much on that score (or if you
do and succeed, let me know the details!)
>I was hoping that I could use that same serial interface
>from the target end to access some API inside the programmer part
>of the dongle to get bytes to show up at the PC virtual com port
>accessible from VB6.
No. That is the JTAG. It's not for communicating to the PC.
You need TWO MORE wires for that. And you need to write
code. And you need a device that will mediate between your
asynch communications and the USB HIB drivers on the PC,
which means you need that -RF2500, or newer -F2013, or
LaunchPad.
>I've got no problem with the VB6 side. I'm confident I can make
>the target functions work. It's a matter of knowing what I need to
>send to the dongle from the PC and/or the target to set up the
>communication path and get data in/out of it.
I mentioned the classes for you. Read docs, check out
example code that deals with that.
>You've suggested that, with the 6-pin interface, I can get
>9600 baud RS232 out of the target into the dongle.
Yes. I believe they ONLY support 9600 bps (I hate using
'baud' here because it has a precise meaning in
communications technology where bps <> baud, at times.) So
no options here, until and unless they decide to update their
drivers.
>I found a serial uart library slaa307a.zip for the target.
>Does serial in/out of the two extra interface pins to the
>dongle automagically show up at the virtual serial port
>on the PC?
I've not looked at the slaa307a.zip code. Just the one I
mentioned earlier regarding the LaunchPad system. It's all
in the main.c file there.
But yes, the essential idea here is that you need code to
"bit bang" the RS-232 asynch protocol at 9600 bps. Once you
have that, you need to tie the pins you selected over to the
right pins on that 6-pin header and just let it fly.
I'd recommend, of course, first using a "dumb terminal"
program of some kind on your PC side of things. And if you
like, you should also download usbview.exe from the FTDI web
site. It is VERY HANDY for making sure you know which COM
port has been set up for you. (Free, too.)
>Or is there some setup required in the dongle?
No. It's plug and play.
>I really, really don't want to have to try to rewrite the dongle
>code. The idea is to make things simpler...or at least not
>much more complex than a basic program into a bootloader into a pic.
>
>I'm asking a lot of simple questions. I'm trying to determine
>whether my goal is reasonable before I invest what few brain cells
>I have left in learning a whole new uC. Thanks for hanging in there.
>mike
Buy the LaunchPad, as your nifty serial port wires are
already there AND wired over to your target IC in a nice
socket. You can just plug that thing in and start right away
doing code. Get the usbview.exe file, too. And get the
source code from slac435.zip (in main.c there) as a starting
point. You just install IAR kickstart, install that zip
file's set of files, load up the project, compile and go.
(Also, of course, have some dumb terminal program running and
attached to the COM port you find with usbview.exe.) Once
you've got that up and running, you are already using the
serial port and you can type and see. That done, work on
your VB.NET or VB 6.0 code to replace your dumb terminal
program. If that works okay, then you now have something
working in your own VB code and something working on a target
processor. At that point, you can attempt to move the whole
thing over to the -F2013 target board, if you like, and power
it from your LaunchPad and use it's 6-wire interface for
talking. Etc.
Jon
