I'm in the process of writing something about the MSP430 and
spent a couple of hours today looking around at the different
tools that are front and center (with or without code limits)
when looking for a toolchain for the MSP430 and hobbyists
(not considering professional work right now, though such
details may be added.)
Straight off, I admit I'm used to using IAR's toolchain when
writing samples. But I want to broaden out my own experience.
In looking today, I installed CCS and probably will do the
same for mspgcc 4, tomorrow. First thing I did was to take a
look at the assembler/linker for CCS and I find good docs,
but quite different syntax for talking with the linker and,
I'm guessing that the linkers are not the same (already know
the assemblers aren't.)
In addition to all of the above (and it has been a very long
time), I assume that TI created their own assembler and
linker at some point in time. Since they are "selling" the
GUI tools of others now, I'm having some difficulty finding
out if TI still produces their own assembler and linker tools
or if they perhaps provide something to the CCS chain,
instead?
This brings up a question for me. CCS has a 16k size limit.
IAR as a 4k size limit. I would assume that old TI tools
would have no limit (if working only in assembly.) Does
anyone know of a web page or would be willing to talk about
what their experiences are regarding all these limitations,
or lack thereof, under different circumstances? Is data
included in some tool limits, but only code in others? In C
source code only in some, but in others both C and assembly
and all libraries included??
Does TI even make a complete toolchain for the command line
only? (No GUI.)
Syntax counts. I'm not particularly happy using gas for the
MSP430, because I already know that AT&T syntax is enough
different from IAR and CCS assembly text that it is a problem
for my goals. I can accept different linker directions (code
and data segments specified somewhat differently, or
different linker file control syntax.) But I really do not
want to jump over entirely to gas (gnu assembler) and AT&T
syntax (though AT&T COFF files are just fine, I think.)
What I'd like to be able to do is to provide links to a full
fledged assembler and linker tool chain that is used only
from the command line prompt (better still, if it can run
under a pure, boxed version of DOS 5.0 with perhaps a DPMI
extender for protected mode code and data space access.) But
without ANY code or data limits and, preferably with 20-bit
capability in processing the syntax. (I have to admit that
I'm not familiar with "models" that various compiler folks
may have individually designed to cope with 20-bit.. so that
is probably something else I can use some education about.)
In other words, if a C compiler is avoided and only non-AT&T
syntax assembly code written, I'd like to support the full
available flash on any part.
I know where to find the flasher for this. It appears to work
well, even on this 64-bit system (yes, I just re-installed an
entirely new IAR toolchain and yes I still cannot get the
thing to program a chip -- okay... it did it ONCE or TWICE
when I got real lucky.) So that is impressive considering the
struggles with the IAR tools. (And yes, I uninstalled the USB
driver and then forced the darned thing to re-install from a
specified file in the newly installed IAR Inf directory. No
good luck from that. And yes, I tried four different dated
LaunchPads, too. And yes, different CPU chips, too.)
Also, is the assembler found in CCS from TI? Just guessing,
since the install directory is \TI, I'd say yes. The file,
ASM430.EXE is found in there:
C:\ti\ccsv5\tools\compiler\msp430_4.1.2\bin>asm430 -?
Usage: asm430 [-options] filename
This tool is designed to be invoked by the compiler.
C:\ti\ccsv5\tools\compiler\msp430_4.1.2\bin>
But it doesn't say who owns it. Nor does LNK430.EXE.
How is the code size limit imposed by CCS if these are TI
tools? If there is a code size limit imposed by the linker at
link time, is there a different linker that will accept the
same COFF file? Or should I use a different linker from TI?
There are other questions. But... well, having any answers to
just a few things above will probably answer a lot more.
Thanks,
Jon
Command Line ONLY tools for MSP430 (except debug)
Started by ●December 9, 2012
Reply by ●December 9, 20122012-12-09
There's a lot of obsolete "gcc for MSP430" cruft around. Peter Bigot has
been maintaining mspgcc. mspgcc & mspdebug provide a complete suite of command
line tools which should work on anything.
http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=MSPGCC_Wiki
TI has announced that they are going to provide support for gcc for the MSP430.
http://article.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10885/match=ti+support
The TI CCS tools can be used via the command line, though I don't think it's well documented.
http://article.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10895/match=ti+support
Another option for assembly is Alfred Arnold's portable macro assembler:
http://john.ccac.rwth-aachen.de:8000/as/
Matthias Koch's mecrisp project, a native forth for the MSP430 uses it. I find mecrisp especially appealing because you can develop and debug in forth w/ a 'G2553 connected to an RS-232 line.
Have Fun!
Reg
http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=MSPGCC_Wiki
TI has announced that they are going to provide support for gcc for the MSP430.
http://article.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10885/match=ti+support
The TI CCS tools can be used via the command line, though I don't think it's well documented.
http://article.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10895/match=ti+support
Another option for assembly is Alfred Arnold's portable macro assembler:
http://john.ccac.rwth-aachen.de:8000/as/
Matthias Koch's mecrisp project, a native forth for the MSP430 uses it. I find mecrisp especially appealing because you can develop and debug in forth w/ a 'G2553 connected to an RS-232 line.
Have Fun!
Reg
Reply by ●December 9, 20122012-12-09
On Sun, 9 Dec 2012 04:10:47 -0800 (PST), Reg wrote:
> There's a lot of obsolete "gcc for MSP430" cruft around.
> Peter Bigot has been maintaining mspgcc. mspgcc & mspdebug
> provide a complete suite of command line tools which should
> work on anything.
>
> http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=MSPGCC_Wiki
Thanks. I'm planning on setting up mspgcc today. Whatever is
promises to be stable and yet also likely to be what people
prefer to use right now. And learn some things myself in the
process about it.
What I hate most is gdb, I think. I have been forced to use
it for another processor (Energy Micro ARMs) and really found
the learning experience, despite my own general knowledge
about tools from both using as well as making them on my own,
more difficult than easy. Coming at it as a neophyte, I found
nothing worked "straight out of the box" and that I had to
dig like crazy into details I knew little of to find the
right commands to properly set up and initialize things
before it worked as it should. The "download" process didn't
set these things up, automatically, and instead depended upon
DEEP knowledge of gdb by whomever was using it. This informed
me that writing about it would be VERY MUCH harder to do. And
so I don't look forward to that idea, right now, given that
prior experience before. GDB by itself sometimes isn't enough
and you need various proxy tools to go with it to make things
easier. Anyway... not looking forward to writing about gdb.
> TI has announced that they are going to provide support for
> gcc for the MSP430.
>
> http://article.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10885/match=ti+support
VERY GOOD NEWS! Thanks for that!
> The TI CCS tools can be used via the command line, though I
> don't think it's well documented.
>
> http://article.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10895/match=ti+support
Thanks. I will take a look at the BSP30 branch.
> Another option for assembly is Alfred Arnold's portable
> macro assembler:
>
> http://john.ccac.rwth-aachen.de:8000/as/
I'm also aware of this, too, from yesterday's google
"research." It is from Michael Kohn:
http://www.mikekohn.net/micro/naken430asm_msp430_assembler.php
http://freecode.com/projects/naken430asm
http://www.43oh.com/2011/10/count-instruction-cycles-in-asm-code-naken430asm/
Looks interesting to me. Lists cycle counts... nice. It is
also being used in a variety of projects I also found at the
time.
> Matthias Koch's mecrisp project, a native forth for the
> MSP430 uses it. I find mecrisp especially appealing because
> you can develop and debug in forth w/ a 'G2553 connected to
> an RS-232 line.
>
> Have Fun!
> Reg
Thanks so much, Reg. That was a big help. I'm still curious
about some of the remaining questions I asked, and more. But
this is very helpful, too. So thanks again,
Jon
> There's a lot of obsolete "gcc for MSP430" cruft around.
> Peter Bigot has been maintaining mspgcc. mspgcc & mspdebug
> provide a complete suite of command line tools which should
> work on anything.
>
> http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=MSPGCC_Wiki
Thanks. I'm planning on setting up mspgcc today. Whatever is
promises to be stable and yet also likely to be what people
prefer to use right now. And learn some things myself in the
process about it.
What I hate most is gdb, I think. I have been forced to use
it for another processor (Energy Micro ARMs) and really found
the learning experience, despite my own general knowledge
about tools from both using as well as making them on my own,
more difficult than easy. Coming at it as a neophyte, I found
nothing worked "straight out of the box" and that I had to
dig like crazy into details I knew little of to find the
right commands to properly set up and initialize things
before it worked as it should. The "download" process didn't
set these things up, automatically, and instead depended upon
DEEP knowledge of gdb by whomever was using it. This informed
me that writing about it would be VERY MUCH harder to do. And
so I don't look forward to that idea, right now, given that
prior experience before. GDB by itself sometimes isn't enough
and you need various proxy tools to go with it to make things
easier. Anyway... not looking forward to writing about gdb.
> TI has announced that they are going to provide support for
> gcc for the MSP430.
>
> http://article.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10885/match=ti+support
VERY GOOD NEWS! Thanks for that!
> The TI CCS tools can be used via the command line, though I
> don't think it's well documented.
>
> http://article.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10895/match=ti+support
Thanks. I will take a look at the BSP30 branch.
> Another option for assembly is Alfred Arnold's portable
> macro assembler:
>
> http://john.ccac.rwth-aachen.de:8000/as/
I'm also aware of this, too, from yesterday's google
"research." It is from Michael Kohn:
http://www.mikekohn.net/micro/naken430asm_msp430_assembler.php
http://freecode.com/projects/naken430asm
http://www.43oh.com/2011/10/count-instruction-cycles-in-asm-code-naken430asm/
Looks interesting to me. Lists cycle counts... nice. It is
also being used in a variety of projects I also found at the
time.
> Matthias Koch's mecrisp project, a native forth for the
> MSP430 uses it. I find mecrisp especially appealing because
> you can develop and debug in forth w/ a 'G2553 connected to
> an RS-232 line.
>
> Have Fun!
> Reg
Thanks so much, Reg. That was a big help. I'm still curious
about some of the remaining questions I asked, and more. But
this is very helpful, too. So thanks again,
Jon
Reply by ●December 9, 20122012-12-09
Daniel Beer has done a very good job w/ mspdebug which makes reading and writing
flash simple.
http://mspdebug.sourceforge.net/
http://wiki.noccylabs.info/wiki/MSPDebug
BTW there are a variety of minor differences between mspgcc and IAR or CCS. Nothing too difficult once you find out how to specify things, but a C program that compiles w/ IAR will probably need to be modified for use w/ mspgcc. The m...@lists.sourceforge.net mailing list is a good source of help.
Reg
http://mspdebug.sourceforge.net/
http://wiki.noccylabs.info/wiki/MSPDebug
BTW there are a variety of minor differences between mspgcc and IAR or CCS. Nothing too difficult once you find out how to specify things, but a C program that compiles w/ IAR will probably need to be modified for use w/ mspgcc. The m...@lists.sourceforge.net mailing list is a good source of help.
Reg
Reply by ●December 9, 20122012-12-09
On Sun, 9 Dec 2012 15:30:58 -0800 (PST), Reg wrote:
> Daniel Beer has done a very good job w/ mspdebug which makes
> reading and writing flash simple.
>
> http://mspdebug.sourceforge.net/
> http://wiki.noccylabs.info/wiki/MSPDebug
Thanks, again.
> BTW there are a variety of minor differences between mspgcc
> and IAR or CCS. Nothing too difficult once you find out how
> to specify things, but a C program that compiles w/ IAR will
> probably need to be modified for use w/ mspgcc. The
> m...@lists.sourceforge.net mailing list is a good
> source of help.
Right now, I'm focused on assembly coding. This helps me vet
out issues regarding linkers (gives me a thorough
understanding of how segmentation is viewed; whether or not
common, overlapping segments can be arranged; if duplicates
of segments can be constructed in the linker file; and so on.
I am NOT currently planning on writing about AT&T style
assembly source code. That decision is subject to a lot of
things I also don't yet know, though. So I'm not spending
time on gas, yet.
But I may change my mind.
Thanks a lot!
Jon
> Daniel Beer has done a very good job w/ mspdebug which makes
> reading and writing flash simple.
>
> http://mspdebug.sourceforge.net/
> http://wiki.noccylabs.info/wiki/MSPDebug
Thanks, again.
> BTW there are a variety of minor differences between mspgcc
> and IAR or CCS. Nothing too difficult once you find out how
> to specify things, but a C program that compiles w/ IAR will
> probably need to be modified for use w/ mspgcc. The
> m...@lists.sourceforge.net mailing list is a good
> source of help.
Right now, I'm focused on assembly coding. This helps me vet
out issues regarding linkers (gives me a thorough
understanding of how segmentation is viewed; whether or not
common, overlapping segments can be arranged; if duplicates
of segments can be constructed in the linker file; and so on.
I am NOT currently planning on writing about AT&T style
assembly source code. That decision is subject to a lot of
things I also don't yet know, though. So I'm not spending
time on gas, yet.
But I may change my mind.
Thanks a lot!
Jon
Reply by ●December 10, 20122012-12-10
On 10/12/2012 01:27, Jon Kirwan wrote:
> On Sun, 9 Dec 2012 15:30:58 -0800 (PST), Reg wrote:
>
> > Daniel Beer has done a very good job w/ mspdebug which makes
> > reading and writing flash simple.
> >
> > http://mspdebug.sourceforge.net/
> > http://wiki.noccylabs.info/wiki/MSPDebug
>
> Thanks, again.
>
> > BTW there are a variety of minor differences between mspgcc
> > and IAR or CCS. Nothing too difficult once you find out how
> > to specify things, but a C program that compiles w/ IAR will
> > probably need to be modified for use w/ mspgcc. The
> > m...@lists.sourceforge.net
> mailing list is a good
> > source of help.
>
> Right now, I'm focused on assembly coding. This helps me vet
> out issues regarding linkers (gives me a thorough
> understanding of how segmentation is viewed; whether or not
> common, overlapping segments can be arranged; if duplicates
> of segments can be constructed in the linker file; and so on.
>
> I am NOT currently planning on writing about AT&T style
> assembly source code. That decision is subject to a lot of
> things I also don't yet know, though. So I'm not spending
> time on gas, yet.
>
> But I may change my mind.
>
> Thanks a lot!
>
> Jon
>
What is your target audience here? There are not many people interested
in writing in pure assembly any more. I think it is a great thing for
developers to do at least some assembly programming - it is the best way
to get familiar with a processor, and to understand what is really going
on inside the chip. But I also know that very few people actually want
to take the time to learn it. Are you sure it is worth spending much
time on?
Having said that, I have a couple of points about assembly programming
on the msp430 that may help you:
AFAIK, IAR's assembler for the msp430 is free (zero cost) and unlimited
- it is only their compilers that have code limits. But it is about a
decade since I used it, so I might be out of date... C-Spy worked for
debugging assembly code, but IMHO it was hideous to use for assembly.
Again, my experience is dated, so may be of little worth - and I'm sure
the IAR people in this group can give you more up-to-date information.
The "AT&T" style assembly in binutils GAS is for x86 code. GAS for the
msp430 uses basically the same assembly syntax as any other msp430
assembler. Of course, there are always small differences in assemblers,
especially for different directives. But GAS is almost certainly the
most feature-rich assembler you can find for the msp430 (or most other
targets), and it is the only good assembler that is fully free and works
on virtually all host OS's. If you want to discount it because you find
it hard to install, or don't like the documentation, or other good
technical reasons, then that's fair enough. But please don't dismiss it
due to a misunderstanding about the syntax!
IMHO, the free tools - binutils and gcc - should always be your first
choice when looking for tools for hobby use or educational use (I think
they should also be the first choice for professional use too, but
opinions differ there!). The tools are truly free and unlimited, they
work on all systems, and they have features that generally rival or
exceed those of commercial toolchains. I think it is always worth
trying them first - and asking for help in the appropriate place (the
mspgcc mailing list is the best choice in this case) as necessary. You
might find you have to do a little research or trial and error to get
the right setup, and to separate useful web resources from outdated ones
(there are many of these - why do people never put dates on their
websites?). And it could be that you find the tools are too hard to use
for some reason, such as debugging problems or difficulties integrating
with an IDE.
And I don't think you'll find anything hosted on DOS 5.0. To put it
mildly, DOS is dead and buried. You want something that can run from
the Windows command prompt and/or Linux shells.
mvh.,
David
> On Sun, 9 Dec 2012 15:30:58 -0800 (PST), Reg wrote:
>
> > Daniel Beer has done a very good job w/ mspdebug which makes
> > reading and writing flash simple.
> >
> > http://mspdebug.sourceforge.net/
> > http://wiki.noccylabs.info/wiki/MSPDebug
>
> Thanks, again.
>
> > BTW there are a variety of minor differences between mspgcc
> > and IAR or CCS. Nothing too difficult once you find out how
> > to specify things, but a C program that compiles w/ IAR will
> > probably need to be modified for use w/ mspgcc. The
> > m...@lists.sourceforge.net
> mailing list is a good
> > source of help.
>
> Right now, I'm focused on assembly coding. This helps me vet
> out issues regarding linkers (gives me a thorough
> understanding of how segmentation is viewed; whether or not
> common, overlapping segments can be arranged; if duplicates
> of segments can be constructed in the linker file; and so on.
>
> I am NOT currently planning on writing about AT&T style
> assembly source code. That decision is subject to a lot of
> things I also don't yet know, though. So I'm not spending
> time on gas, yet.
>
> But I may change my mind.
>
> Thanks a lot!
>
> Jon
>
What is your target audience here? There are not many people interested
in writing in pure assembly any more. I think it is a great thing for
developers to do at least some assembly programming - it is the best way
to get familiar with a processor, and to understand what is really going
on inside the chip. But I also know that very few people actually want
to take the time to learn it. Are you sure it is worth spending much
time on?
Having said that, I have a couple of points about assembly programming
on the msp430 that may help you:
AFAIK, IAR's assembler for the msp430 is free (zero cost) and unlimited
- it is only their compilers that have code limits. But it is about a
decade since I used it, so I might be out of date... C-Spy worked for
debugging assembly code, but IMHO it was hideous to use for assembly.
Again, my experience is dated, so may be of little worth - and I'm sure
the IAR people in this group can give you more up-to-date information.
The "AT&T" style assembly in binutils GAS is for x86 code. GAS for the
msp430 uses basically the same assembly syntax as any other msp430
assembler. Of course, there are always small differences in assemblers,
especially for different directives. But GAS is almost certainly the
most feature-rich assembler you can find for the msp430 (or most other
targets), and it is the only good assembler that is fully free and works
on virtually all host OS's. If you want to discount it because you find
it hard to install, or don't like the documentation, or other good
technical reasons, then that's fair enough. But please don't dismiss it
due to a misunderstanding about the syntax!
IMHO, the free tools - binutils and gcc - should always be your first
choice when looking for tools for hobby use or educational use (I think
they should also be the first choice for professional use too, but
opinions differ there!). The tools are truly free and unlimited, they
work on all systems, and they have features that generally rival or
exceed those of commercial toolchains. I think it is always worth
trying them first - and asking for help in the appropriate place (the
mspgcc mailing list is the best choice in this case) as necessary. You
might find you have to do a little research or trial and error to get
the right setup, and to separate useful web resources from outdated ones
(there are many of these - why do people never put dates on their
websites?). And it could be that you find the tools are too hard to use
for some reason, such as debugging problems or difficulties integrating
with an IDE.
And I don't think you'll find anything hosted on DOS 5.0. To put it
mildly, DOS is dead and buried. You want something that can run from
the Windows command prompt and/or Linux shells.
mvh.,
David
Reply by ●December 10, 20122012-12-10
IAR's assembler is still free and unlimited. C-Spy isn't the best
debugger around, it has many limitations when debugging assembler, but
it is certainly better than, for example, the old Motorola assembler of
the mid to late 90's, and I find it usable, even if frustrating at
times, for example it might break down internal registers into their bit
fields in the view window, but, even given a header file, or other forms
of bit defintions it doesn't do the same for user vars. I stick with it
because it is simple, free and does most of what I need. I tend to write
in a fairly crude straightforward manner. I don't need relocatable code,
in fact mostly that would be a major pain in the butt for me, as I like
to precisely allocate memory how I like, so I don't need to get fancy
with the linker, or, in fact anything else.
Al
On 11/12/2012 1:14 AM, David Brown wrote:
> On 10/12/2012 01:27, Jon Kirwan wrote:
>> On Sun, 9 Dec 2012 15:30:58 -0800 (PST), Reg wrote:
>>
>> > Daniel Beer has done a very good job w/ mspdebug which makes
>> > reading and writing flash simple.
>> >
>> > http://mspdebug.sourceforge.net/
>> > http://wiki.noccylabs.info/wiki/MSPDebug
>>
>> Thanks, again.
>>
>> > BTW there are a variety of minor differences between mspgcc
>> > and IAR or CCS. Nothing too difficult once you find out how
>> > to specify things, but a C program that compiles w/ IAR will
>> > probably need to be modified for use w/ mspgcc. The
>> > m...@lists.sourceforge.net
>> mailing list is a good
>> > source of help.
>>
>> Right now, I'm focused on assembly coding. This helps me vet
>> out issues regarding linkers (gives me a thorough
>> understanding of how segmentation is viewed; whether or not
>> common, overlapping segments can be arranged; if duplicates
>> of segments can be constructed in the linker file; and so on.
>>
>> I am NOT currently planning on writing about AT&T style
>> assembly source code. That decision is subject to a lot of
>> things I also don't yet know, though. So I'm not spending
>> time on gas, yet.
>>
>> But I may change my mind.
>>
>> Thanks a lot!
>>
>> Jon
>>
> What is your target audience here? There are not many people interested
> in writing in pure assembly any more. I think it is a great thing for
> developers to do at least some assembly programming - it is the best way
> to get familiar with a processor, and to understand what is really going
> on inside the chip. But I also know that very few people actually want
> to take the time to learn it. Are you sure it is worth spending much
> time on?
>
> Having said that, I have a couple of points about assembly programming
> on the msp430 that may help you:
>
> AFAIK, IAR's assembler for the msp430 is free (zero cost) and unlimited
> - it is only their compilers that have code limits. But it is about a
> decade since I used it, so I might be out of date... C-Spy worked for
> debugging assembly code, but IMHO it was hideous to use for assembly.
> Again, my experience is dated, so may be of little worth - and I'm sure
> the IAR people in this group can give you more up-to-date information.
>
> The "AT&T" style assembly in binutils GAS is for x86 code. GAS for the
> msp430 uses basically the same assembly syntax as any other msp430
> assembler. Of course, there are always small differences in assemblers,
> especially for different directives. But GAS is almost certainly the
> most feature-rich assembler you can find for the msp430 (or most other
> targets), and it is the only good assembler that is fully free and works
> on virtually all host OS's. If you want to discount it because you find
> it hard to install, or don't like the documentation, or other good
> technical reasons, then that's fair enough. But please don't dismiss it
> due to a misunderstanding about the syntax!
>
> IMHO, the free tools - binutils and gcc - should always be your first
> choice when looking for tools for hobby use or educational use (I think
> they should also be the first choice for professional use too, but
> opinions differ there!). The tools are truly free and unlimited, they
> work on all systems, and they have features that generally rival or
> exceed those of commercial toolchains. I think it is always worth
> trying them first - and asking for help in the appropriate place (the
> mspgcc mailing list is the best choice in this case) as necessary. You
> might find you have to do a little research or trial and error to get
> the right setup, and to separate useful web resources from outdated ones
> (there are many of these - why do people never put dates on their
> websites?). And it could be that you find the tools are too hard to use
> for some reason, such as debugging problems or difficulties integrating
> with an IDE.
> And I don't think you'll find anything hosted on DOS 5.0. To put it
> mildly, DOS is dead and buried. You want something that can run from
> the Windows command prompt and/or Linux shells.
>
> mvh.,
>
> David
>
debugger around, it has many limitations when debugging assembler, but
it is certainly better than, for example, the old Motorola assembler of
the mid to late 90's, and I find it usable, even if frustrating at
times, for example it might break down internal registers into their bit
fields in the view window, but, even given a header file, or other forms
of bit defintions it doesn't do the same for user vars. I stick with it
because it is simple, free and does most of what I need. I tend to write
in a fairly crude straightforward manner. I don't need relocatable code,
in fact mostly that would be a major pain in the butt for me, as I like
to precisely allocate memory how I like, so I don't need to get fancy
with the linker, or, in fact anything else.
Al
On 11/12/2012 1:14 AM, David Brown wrote:
> On 10/12/2012 01:27, Jon Kirwan wrote:
>> On Sun, 9 Dec 2012 15:30:58 -0800 (PST), Reg wrote:
>>
>> > Daniel Beer has done a very good job w/ mspdebug which makes
>> > reading and writing flash simple.
>> >
>> > http://mspdebug.sourceforge.net/
>> > http://wiki.noccylabs.info/wiki/MSPDebug
>>
>> Thanks, again.
>>
>> > BTW there are a variety of minor differences between mspgcc
>> > and IAR or CCS. Nothing too difficult once you find out how
>> > to specify things, but a C program that compiles w/ IAR will
>> > probably need to be modified for use w/ mspgcc. The
>> > m...@lists.sourceforge.net
>> mailing list is a good
>> > source of help.
>>
>> Right now, I'm focused on assembly coding. This helps me vet
>> out issues regarding linkers (gives me a thorough
>> understanding of how segmentation is viewed; whether or not
>> common, overlapping segments can be arranged; if duplicates
>> of segments can be constructed in the linker file; and so on.
>>
>> I am NOT currently planning on writing about AT&T style
>> assembly source code. That decision is subject to a lot of
>> things I also don't yet know, though. So I'm not spending
>> time on gas, yet.
>>
>> But I may change my mind.
>>
>> Thanks a lot!
>>
>> Jon
>>
> What is your target audience here? There are not many people interested
> in writing in pure assembly any more. I think it is a great thing for
> developers to do at least some assembly programming - it is the best way
> to get familiar with a processor, and to understand what is really going
> on inside the chip. But I also know that very few people actually want
> to take the time to learn it. Are you sure it is worth spending much
> time on?
>
> Having said that, I have a couple of points about assembly programming
> on the msp430 that may help you:
>
> AFAIK, IAR's assembler for the msp430 is free (zero cost) and unlimited
> - it is only their compilers that have code limits. But it is about a
> decade since I used it, so I might be out of date... C-Spy worked for
> debugging assembly code, but IMHO it was hideous to use for assembly.
> Again, my experience is dated, so may be of little worth - and I'm sure
> the IAR people in this group can give you more up-to-date information.
>
> The "AT&T" style assembly in binutils GAS is for x86 code. GAS for the
> msp430 uses basically the same assembly syntax as any other msp430
> assembler. Of course, there are always small differences in assemblers,
> especially for different directives. But GAS is almost certainly the
> most feature-rich assembler you can find for the msp430 (or most other
> targets), and it is the only good assembler that is fully free and works
> on virtually all host OS's. If you want to discount it because you find
> it hard to install, or don't like the documentation, or other good
> technical reasons, then that's fair enough. But please don't dismiss it
> due to a misunderstanding about the syntax!
>
> IMHO, the free tools - binutils and gcc - should always be your first
> choice when looking for tools for hobby use or educational use (I think
> they should also be the first choice for professional use too, but
> opinions differ there!). The tools are truly free and unlimited, they
> work on all systems, and they have features that generally rival or
> exceed those of commercial toolchains. I think it is always worth
> trying them first - and asking for help in the appropriate place (the
> mspgcc mailing list is the best choice in this case) as necessary. You
> might find you have to do a little research or trial and error to get
> the right setup, and to separate useful web resources from outdated ones
> (there are many of these - why do people never put dates on their
> websites?). And it could be that you find the tools are too hard to use
> for some reason, such as debugging problems or difficulties integrating
> with an IDE.
> And I don't think you'll find anything hosted on DOS 5.0. To put it
> mildly, DOS is dead and buried. You want something that can run from
> the Windows command prompt and/or Linux shells.
>
> mvh.,
>
> David
>
Reply by ●December 10, 20122012-12-10
--- In m..., David Brown wrote:
>
> AFAIK, IAR's assembler for the msp430 is free (zero cost) and
> unlimited - it is only their compilers that have code limits.
> But it is about a decade since I used it, so I might be out of
> date...
I use the IAR assemblers and linkers for the 8051, MSP430, ARM and RX platforms. All are free and unlimited in code size. it is the first place I go to for a new processor tool set. The devil you know is always better than the one you don't.
Blakely
--
Blakely LaCroix
Minneapolis, Minnesota, USA
>
> AFAIK, IAR's assembler for the msp430 is free (zero cost) and
> unlimited - it is only their compilers that have code limits.
> But it is about a decade since I used it, so I might be out of
> date...
I use the IAR assemblers and linkers for the 8051, MSP430, ARM and RX platforms. All are free and unlimited in code size. it is the first place I go to for a new processor tool set. The devil you know is always better than the one you don't.
Blakely
--
Blakely LaCroix
Minneapolis, Minnesota, USA
Reply by ●December 10, 20122012-12-10
On Mon, 10 Dec 2012 15:44:26 +0100, you wrote:
>On 10/12/2012 01:27, Jon Kirwan wrote:
>> On Sun, 9 Dec 2012 15:30:58 -0800 (PST), Reg wrote:
>>
>> > Daniel Beer has done a very good job w/ mspdebug which makes
>> > reading and writing flash simple.
>> >
>> > http://mspdebug.sourceforge.net/
>> > http://wiki.noccylabs.info/wiki/MSPDebug
>>
>> Thanks, again.
>>
>> > BTW there are a variety of minor differences between mspgcc
>> > and IAR or CCS. Nothing too difficult once you find out how
>> > to specify things, but a C program that compiles w/ IAR will
>> > probably need to be modified for use w/ mspgcc. The
>> > m...@lists.sourceforge.net
>> mailing list is a good
>> > source of help.
>>
>> Right now, I'm focused on assembly coding. This helps me vet
>> out issues regarding linkers (gives me a thorough
>> understanding of how segmentation is viewed; whether or not
>> common, overlapping segments can be arranged; if duplicates
>> of segments can be constructed in the linker file; and so on.
>>
>> I am NOT currently planning on writing about AT&T style
>> assembly source code. That decision is subject to a lot of
>> things I also don't yet know, though. So I'm not spending
>> time on gas, yet.
>>
>> But I may change my mind.
>>
>> Thanks a lot!
>>
>> Jon
>
>What is your target audience here? There are not many people interested
>in writing in pure assembly any more.
Apparently, that isn't quite as true as you seem to suggest.
I regularly get emails from students I don't know asking for
help because their class work requires MSP430 assembly coding
and no C. Just answered one of these two days ago, in fact.
>I think it is a great thing for
>developers to do at least some assembly programming - it is the best way
>to get familiar with a processor, and to understand what is really going
>on inside the chip. But I also know that very few people actually want
>to take the time to learn it. Are you sure it is worth spending much
>time on?
I'm still in the process of researching that question.
>Having said that, I have a couple of points about assembly programming
>on the msp430 that may help you:
>
>AFAIK, IAR's assembler for the msp430 is free (zero cost) and unlimited
>- it is only their compilers that have code limits. But it is about a
>decade since I used it, so I might be out of date... C-Spy worked for
>debugging assembly code, but IMHO it was hideous to use for assembly.
>Again, my experience is dated, so may be of little worth - and I'm sure
>the IAR people in this group can give you more up-to-date information.
The IAR assembler is what I'm used to using, too. But I
decided to get familiar with other possibilities as part of
the above research.
>The "AT&T" style assembly in binutils GAS is for x86 code. GAS for the
>msp430 uses basically the same assembly syntax as any other msp430
>assembler.
So, that's interesting. I'll get right to checking that out.
Thanks for clueing me in.
>Of course, there are always small differences in assemblers,
Oh, yeah. I just wrote some code for the CCS assembler (is
that from TI? I think so, but I'm not positive) and there are
substantial differences in the pseudoops. And the linker
control files, as well.
>especially for different directives. But GAS is almost certainly the
>most feature-rich assembler you can find for the msp430 (or most other
>targets), and it is the only good assembler that is fully free and works
>on virtually all host OS's. If you want to discount it because you find
>it hard to install, or don't like the documentation, or other good
>technical reasons, then that's fair enough. But please don't dismiss it
>due to a misunderstanding about the syntax!
Thanks, again. If the syntax isn't using % for registers and
is instead no more different from IAR's assembler than is
CCS's, then I intend to spend lots of time with it. I
appreciate your letting me know it's not so different. I will
get right down to using it, very soon.
>IMHO, the free tools - binutils and gcc - should always be your first
>choice when looking for tools for hobby use or educational use (I think
>they should also be the first choice for professional use too, but
>opinions differ there!).
It's important to me that this is true. But my experiences
with gbd on ARM targets was enough to make me VERY WARY of
the idea of trying to write something for neophytes. (You
asked my target audience and there it is -- people with ZERO
experience but with either a classroom driven need and a
feeling of inadequacy because "I just don't get it" or else
self-motivated people who are fear they aren't smart enough.
There is more to that target audience... but that will set
the stage.) I struggled to find out why things weren't
working right, had to study many different expositories on
the commands and what they did, before I was finally able to
pull together the half-dozen or so additional details
required to get it up and running and usable on my physical
target. And I have LOTS OF EXPERIENCE. I can only imagine
what this means for someone who doesn't believe in
themselves, has no experience at all, and no set of concepts
to work from in navigating through "web descriptions" that
are mostly written for folks with at least some modest
knowledge as a base. It's not just GBD itself, because it
depends upon other tools being properly installed, too. It's
understandable... of course. But only to someone with some
idea how these tools work and why the situation is as it is.
It could be frightening to people just starting out and a
very difficult "hill" to climb. Worse, I'd have to WRITE
about it. And that could be a GREAT DEAL OF WORK to not only
research, but then much more to write well about and then
test that writing on people until I got it honed and fine
tuned. I do NOT relish the work ahead there.
If you know of a link that does this thoroughly for various
target types, not just ARM but at least two or three other
targets as well, and does it for someone with ZERO knowledge
beforehand (or else provides all of the necessary background
as well), I'd LOVE to read it. It could help reduce my work a
great deal to see it done.
>The tools are truly free and unlimited, they
>work on all systems, and they have features that generally rival or
>exceed those of commercial toolchains. I think it is always worth
>trying them first - and asking for help in the appropriate place (the
>mspgcc mailing list is the best choice in this case) as necessary. You
>might find you have to do a little research or trial and error to get
>the right setup, and to separate useful web resources from outdated ones
>(there are many of these - why do people never put dates on their
>websites?). And it could be that you find the tools are too hard to use
>for some reason, such as debugging problems or difficulties integrating
>with an IDE.
Well, in some ways I love the tools. In some ways,... in my
past experience it's also an epic struggle. It's not just
gdb. That's one detail. But even learning how to google
around and _recognize_ which pages tell you the better
information and then being able to _interpret_ what is
written there... that itself requires a lot of writing to
help a neophyte get to the point where they can self-direct.
The other approach, just telling them where to go in certain
cases, will be dated long before I get a chance to finish
writing. A way to fix this is to make it all on the web and
to keep updating it.... but I won't live forever and,
frankly, I do have another life, too. So this is part of the
context I'm considering, as well. Reality about my own
limitations.
>And I don't think you'll find anything hosted on DOS 5.0. To put it
>mildly, DOS is dead and buried. You want something that can run from
>the Windows command prompt and/or Linux shells.
There, I'm considering the idea of a (physically and
resource) small system (not unlike Geoff's Maximite) that is
based entirely on a DOS-like system for the command line
parsing and program execution. The whole thing could directly
drive any usual monitor attached, plus keyboard, for very
little money. Monochrome is all that is needed and the
Maximite is VERY FRUGAL about this -- if you haven't examined
the design and implementation, you might want to do so.
Maximite cost would be perhaps $30, plus a spare monitor and
keyboard. It's an idea I'm researching, but considering DOS
instead. PC/104 systems can be had for almost nothing.
Anyway, probably will come to nothing, but DPMI access into
protected mode does already exist and I have stacks of retail
boxed DOS 5.0 systems to use in researching this. Just a
random thought there. Nothing I expect will pan out.
Jon
>On 10/12/2012 01:27, Jon Kirwan wrote:
>> On Sun, 9 Dec 2012 15:30:58 -0800 (PST), Reg wrote:
>>
>> > Daniel Beer has done a very good job w/ mspdebug which makes
>> > reading and writing flash simple.
>> >
>> > http://mspdebug.sourceforge.net/
>> > http://wiki.noccylabs.info/wiki/MSPDebug
>>
>> Thanks, again.
>>
>> > BTW there are a variety of minor differences between mspgcc
>> > and IAR or CCS. Nothing too difficult once you find out how
>> > to specify things, but a C program that compiles w/ IAR will
>> > probably need to be modified for use w/ mspgcc. The
>> > m...@lists.sourceforge.net
>> mailing list is a good
>> > source of help.
>>
>> Right now, I'm focused on assembly coding. This helps me vet
>> out issues regarding linkers (gives me a thorough
>> understanding of how segmentation is viewed; whether or not
>> common, overlapping segments can be arranged; if duplicates
>> of segments can be constructed in the linker file; and so on.
>>
>> I am NOT currently planning on writing about AT&T style
>> assembly source code. That decision is subject to a lot of
>> things I also don't yet know, though. So I'm not spending
>> time on gas, yet.
>>
>> But I may change my mind.
>>
>> Thanks a lot!
>>
>> Jon
>
>What is your target audience here? There are not many people interested
>in writing in pure assembly any more.
Apparently, that isn't quite as true as you seem to suggest.
I regularly get emails from students I don't know asking for
help because their class work requires MSP430 assembly coding
and no C. Just answered one of these two days ago, in fact.
>I think it is a great thing for
>developers to do at least some assembly programming - it is the best way
>to get familiar with a processor, and to understand what is really going
>on inside the chip. But I also know that very few people actually want
>to take the time to learn it. Are you sure it is worth spending much
>time on?
I'm still in the process of researching that question.
>Having said that, I have a couple of points about assembly programming
>on the msp430 that may help you:
>
>AFAIK, IAR's assembler for the msp430 is free (zero cost) and unlimited
>- it is only their compilers that have code limits. But it is about a
>decade since I used it, so I might be out of date... C-Spy worked for
>debugging assembly code, but IMHO it was hideous to use for assembly.
>Again, my experience is dated, so may be of little worth - and I'm sure
>the IAR people in this group can give you more up-to-date information.
The IAR assembler is what I'm used to using, too. But I
decided to get familiar with other possibilities as part of
the above research.
>The "AT&T" style assembly in binutils GAS is for x86 code. GAS for the
>msp430 uses basically the same assembly syntax as any other msp430
>assembler.
So, that's interesting. I'll get right to checking that out.
Thanks for clueing me in.
>Of course, there are always small differences in assemblers,
Oh, yeah. I just wrote some code for the CCS assembler (is
that from TI? I think so, but I'm not positive) and there are
substantial differences in the pseudoops. And the linker
control files, as well.
>especially for different directives. But GAS is almost certainly the
>most feature-rich assembler you can find for the msp430 (or most other
>targets), and it is the only good assembler that is fully free and works
>on virtually all host OS's. If you want to discount it because you find
>it hard to install, or don't like the documentation, or other good
>technical reasons, then that's fair enough. But please don't dismiss it
>due to a misunderstanding about the syntax!
Thanks, again. If the syntax isn't using % for registers and
is instead no more different from IAR's assembler than is
CCS's, then I intend to spend lots of time with it. I
appreciate your letting me know it's not so different. I will
get right down to using it, very soon.
>IMHO, the free tools - binutils and gcc - should always be your first
>choice when looking for tools for hobby use or educational use (I think
>they should also be the first choice for professional use too, but
>opinions differ there!).
It's important to me that this is true. But my experiences
with gbd on ARM targets was enough to make me VERY WARY of
the idea of trying to write something for neophytes. (You
asked my target audience and there it is -- people with ZERO
experience but with either a classroom driven need and a
feeling of inadequacy because "I just don't get it" or else
self-motivated people who are fear they aren't smart enough.
There is more to that target audience... but that will set
the stage.) I struggled to find out why things weren't
working right, had to study many different expositories on
the commands and what they did, before I was finally able to
pull together the half-dozen or so additional details
required to get it up and running and usable on my physical
target. And I have LOTS OF EXPERIENCE. I can only imagine
what this means for someone who doesn't believe in
themselves, has no experience at all, and no set of concepts
to work from in navigating through "web descriptions" that
are mostly written for folks with at least some modest
knowledge as a base. It's not just GBD itself, because it
depends upon other tools being properly installed, too. It's
understandable... of course. But only to someone with some
idea how these tools work and why the situation is as it is.
It could be frightening to people just starting out and a
very difficult "hill" to climb. Worse, I'd have to WRITE
about it. And that could be a GREAT DEAL OF WORK to not only
research, but then much more to write well about and then
test that writing on people until I got it honed and fine
tuned. I do NOT relish the work ahead there.
If you know of a link that does this thoroughly for various
target types, not just ARM but at least two or three other
targets as well, and does it for someone with ZERO knowledge
beforehand (or else provides all of the necessary background
as well), I'd LOVE to read it. It could help reduce my work a
great deal to see it done.
>The tools are truly free and unlimited, they
>work on all systems, and they have features that generally rival or
>exceed those of commercial toolchains. I think it is always worth
>trying them first - and asking for help in the appropriate place (the
>mspgcc mailing list is the best choice in this case) as necessary. You
>might find you have to do a little research or trial and error to get
>the right setup, and to separate useful web resources from outdated ones
>(there are many of these - why do people never put dates on their
>websites?). And it could be that you find the tools are too hard to use
>for some reason, such as debugging problems or difficulties integrating
>with an IDE.
Well, in some ways I love the tools. In some ways,... in my
past experience it's also an epic struggle. It's not just
gdb. That's one detail. But even learning how to google
around and _recognize_ which pages tell you the better
information and then being able to _interpret_ what is
written there... that itself requires a lot of writing to
help a neophyte get to the point where they can self-direct.
The other approach, just telling them where to go in certain
cases, will be dated long before I get a chance to finish
writing. A way to fix this is to make it all on the web and
to keep updating it.... but I won't live forever and,
frankly, I do have another life, too. So this is part of the
context I'm considering, as well. Reality about my own
limitations.
>And I don't think you'll find anything hosted on DOS 5.0. To put it
>mildly, DOS is dead and buried. You want something that can run from
>the Windows command prompt and/or Linux shells.
There, I'm considering the idea of a (physically and
resource) small system (not unlike Geoff's Maximite) that is
based entirely on a DOS-like system for the command line
parsing and program execution. The whole thing could directly
drive any usual monitor attached, plus keyboard, for very
little money. Monochrome is all that is needed and the
Maximite is VERY FRUGAL about this -- if you haven't examined
the design and implementation, you might want to do so.
Maximite cost would be perhaps $30, plus a spare monitor and
keyboard. It's an idea I'm researching, but considering DOS
instead. PC/104 systems can be had for almost nothing.
Anyway, probably will come to nothing, but DPMI access into
protected mode does already exist and I have stacks of retail
boxed DOS 5.0 systems to use in researching this. Just a
random thought there. Nothing I expect will pan out.
Jon
Reply by ●December 10, 20122012-12-10
On Mon, 10 Dec 2012 16:24:09 -0000, you wrote:
>--- In m..., David Brown wrote:
>>
>> AFAIK, IAR's assembler for the msp430 is free (zero cost) and
>> unlimited - it is only their compilers that have code limits.
>> But it is about a decade since I used it, so I might be out of
>> date...
>
> I use the IAR assemblers and linkers for the 8051, MSP430,
> ARM and RX platforms. All are free and unlimited in code
> size. it is the first place I go to for a new processor tool
> set. The devil you know is always better than the one you
> don't.
>
>Blakely
Do you know how IAR enforces the code size limitations? If it
isn't at link-time, which from the above it must not be, then
how do they detect it? Certainly, not just based on
seperately compiled C/C++ modules. Those could be made short.
It would have to be the aggregate size and that would only be
known at link-time. Is there some kind of special "watermark"
in the object files that the linker uses?
Jon
>--- In m..., David Brown wrote:
>>
>> AFAIK, IAR's assembler for the msp430 is free (zero cost) and
>> unlimited - it is only their compilers that have code limits.
>> But it is about a decade since I used it, so I might be out of
>> date...
>
> I use the IAR assemblers and linkers for the 8051, MSP430,
> ARM and RX platforms. All are free and unlimited in code
> size. it is the first place I go to for a new processor tool
> set. The devil you know is always better than the one you
> don't.
>
>Blakely
Do you know how IAR enforces the code size limitations? If it
isn't at link-time, which from the above it must not be, then
how do they detect it? Certainly, not just based on
seperately compiled C/C++ modules. Those could be made short.
It would have to be the aggregate size and that would only be
known at link-time. Is there some kind of special "watermark"
in the object files that the linker uses?
Jon
