OK, I've never met that limit, since I've never used Kickstart in
anything other than assembler mode

Al

On 11/12/2012 7:56 PM, Paul Curtis wrote:
>> I have always used the IAR assembler, and keep it updated, and have never
>> known it not to generate assembler.
> The IAR assembler generates a relocatable object module; IAR removed the
> facility for the KickStart compilers to generate an assembler input file
> (thus eliminating, by devious means, the circumvention of the 4K KickStart
> limit).
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore Development Platform http://www.soldercore.com
> Start a New Thread

> I have always used the IAR assembler, and keep it updated, and have never
> known it not to generate assembler.

The IAR assembler generates a relocatable object module; IAR removed the
facility for the KickStart compilers to generate an assembler input file
(thus eliminating, by devious means, the circumvention of the 4K KickStart
limit).

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com

Start a New Thread

On 10/12/2012 21:19, Jon Kirwan wrote:
> 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 hadn't expected that to be the case - but I am glad it is. As I said
earlier, I think it is a good thing that more people learn at least
basic assembly programming for microcontrollers before working with C.
(Though I think C, and in some cases C++, is a better choice for most
professional development work once you have a thorough understanding of
the microcontroller.) So if people are wanting to program in assembly,
and you want to help them with that, then I wish you the best of luck
here. We all benefit if new students learn better.

>
> >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.
>

Directives are /always/ different for different assemblers. And there
are differences in things like the way registers are named ("r1", "R1",
"SR", "sr", etc.) - though it is often worth having an include file with
macros for common names, or to rationalise the names of directives or
opcodes. In my early years as an embedded developer, most of my
programming was done in assembly on a variety of microcontrollers, so I
used a made heavy use of include files and macros to get a fair amount
of consistency between them. For example, the macro "ConstB 1, 2, 3,
..." would define a table of literal bytes, expanding to ".db",
".define", ".byte", etc., according to the assembler in question. I
don't know whether you want to do something like that for flexibility
(letting people easily use different msp430 assemblers), or try to keep
everything "native" to the assembler in question. Of course, if you
want to keep "native", then you will want to pick one assembler and
stick to it, for the sake of your sanity!

> >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.

Of course, once you look at more advanced features, assemblers (and
linkers) diverge more. For example, GAS has some "polymorph"
instructions such as "bne label". This will be interpreted as "jne
label" if the target label is in range for the "jne" instruction, or
"jeq +4; br label" if it is out of range. If you get in the habit of
using features like this with one tool, then moving to another assembler
will be a pain.

>
> >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.

I can well understand your point. gdb is not a simple tool, and its
flexibility can be a big disadvantage in learning. It is fantastic that
you can learn about one tool and use it on a dozen different processors
- but if you only want to use it on one processor, then it can be very
confusing to read documentation that talks about a dozen other
processors. Also remember that gdb is only part of a typical debugging
setup. You normally have some sort of hardware proxy program between
gdb and the hardware debugger (such as "msp430-gdbproxy" or "openocd"
for ARM), and you normally have some sort of gui front-end to the
debugger such as Eclipse (/I/ often find command-line gdb debugging
useful, but it's not everyone's cup of tea). Again, this flexibility
can be fantastic - you can swap out back-end debugger hardware or use
different gui front-ends. But again, it can be highly confusing and
hard to figure out what is going on (or what is going wrong).

I have had cases where the gdb based debugging simply worked perfectly
out of the box, and I have had cases where it has been a lot of effort
and trial-and-error to get things working. I wish I could give you an
easy answer or recipe here, but I can't. All I can say is that a
difficult time getting gdb working with one toolset on one target does
not imply that it will be difficult in other cases. It has been a long
time since I've actually done jtag debugging on an msp430 - most of my
msp430 work in recent years has been building on existing systems, and
I've done it without jtag debugging. But again the msp430gcc mailing
list can give you good advice.

As a general point, debug configuration is one of the main selling
points of a lot of "commercial open source" toolchains where you pay for
a ready-to-run setup of an IDE (typically Eclipse), gcc, libraries
(sometimes specialised libraries written by the supplier, rather than
standard libraries such as newlib or ulibc), gdb, debug proxies, all the
setup, scripts, wizards, etc., needed to glue it together seamlessly,
and of course professional support and documentation. There are several
such "commercial open source" toolchains for ARM, including Code
Sourcery, Code Red, and Rowley (they have their own libraries, and I
think their own IDE, but use gcc for compilation). I don't know of any
for the msp430 as yet - but I expect once TI and Red Hat release
pre-packaged msp430 gcc toolsets then it will be a similar system (I
have no idea what pricing model they will use). But in cases where you
can use such pre-packaged toolchains, debugging is /usually/ as simple
as with any commercial toolchain. (Of course, debugging with commercial
toolchains can be problematic too.)

>
> >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.
>

Systems like this have been totally outclassed by tiny Linux systems. I
can well understand the idea of having a small, cheap, self-contained
system with tools installed and everything ready to run. But for the
same price as the Maximite you can get a Raspberry Pi running full
Linux. That means you have a /real/ command line to work with, you have
HDMI to connect to almost any TV or monitor, USB to connect any keyboard
and mouse, Ethernet, etc. And with a full Linux system you can use a
decent programmer's editor or IDE (though you might want something
relatively light like CodeBlocks rather than the ubiquitous Eclipse -
the Rasberry Pi is powerful for its size and cost, but Eclipse is
perhaps a bit heavy for it).
If you absolutely must look at DOS (the key reasons I see being that
with such a limited system, there is less to go wrong, less to learn,
and less to distract the user), then FreeDOS would be your first port of
call.

mvh.,

David

Start a New Thread

On 10/12/2012 17:22, Onestone wrote:
> 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.
>

As I said, it's been a while since I've done much pure assembly
programming on the msp430 - but it was all done with the IAR tools
(since the msp430 port of binutils and gcc were not around at the time).
C-Spy always gave me the feeling that assembly debugging was very much
a minor feature, and that you had to use C to get more solid debugging.
I suppose that's fair enough - after all, IAR make their living
selling C (and C++) toolchains, not from giving away free assembly
tools. And while I didn't like C-Spy for debugging, I too have seen worse.

mvh.,

David
> 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
> >
> >
> >
> >
Start a New Thread

I have always used the IAR assembler, and keep it updated, and have
never known it not to generate assembler.

Al

On 11/12/2012 8:58 AM, Paul Curtis wrote:
> On 10 Dec 2012, at 20:21, Jon Kirwan wrote:
>
>> 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?
> The linker enforces the restriction because it knows which tool generated the object code. TI engineered a way around this limitation at one point (IIRC, for SimpliciTI or something) by taking the assembly code output of the compiler and feeding it to the assembler (with some modifications? No idea) such that it did not count towards the 4K compiled code limit. I assume there was a to-and-fro with IAR about it, and then IAR removed the ability of KickStart tools to generate assembly code output.
>
> This is what I recall from a few years ago. It may not be current, and I don't have the enthusiasm to test it out again.
>
> -- Paul.
>
> Start a New Thread

For a small, cheap assembly language development system for multiple targets a Raspberry Pi running Linux and Alfred Arnold's portable assembler, AS, seems pretty hard to beat if AS meets your syntax requirements.

http://john.ccac.rwth-aachen.de:8000/as/cpulist.html

There is the problem of loading the resulting image to the target which is unfortunately somewhat target specific. However 2 or 4 wire variants of JTAG or serial line boot loaders seem to be the norm on recent systems, so it should be possible to design an addon board for the Pi that could be customized as needed. The 17 GPIO pins ought to be adequate for anything and even allow for software configuration of a wide range of programming voltages and currents. The hard part would be making it easy to understand how to configure it for a particular target.

Reg





Start a New Thread

On Mon, 10 Dec 2012 22:42:10 +0000, you wrote:

>>> 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.)
>
> Surely, giving them something that would have immediate
> feedback, with a feeling that they are in control and it
> isn't beyond them, is a great place to start.

The scope of what I'm considering isn't just assembly. Some
people may want to start out that way and I'm researching the
scope.

But just to be argumentative and for only that sake, I
started out with binary machine code. Then assembly code,
later on. I didn't learn BASIC. I didn't learn FORTRAN. Not
until later on. I started with a very simple CARDIAC (you may
remember it.) My next step was an IBM 1130 assembler. Then I
went to BASIC and FORTRAN and AlGOL-68. I wrote an assembler
and linker and an operating system soon after. Then I built
an Altair 8800 kit, spent two months diagnosing problems with
the 4k dynamic card designs (which were profoundly WRONG, by
design.) Then I started a business developing software for
small businesses (no packaged software then.) And then I
worked on Unix v6. Much since then, of course.

Issue is, not everyone fits in the same box. There are many
paths to nirvana. Some of the more well-worn paths I'm not
interested in duplicating, because business already does
that. There is no need for me there. I'm considering other
paths "to heaven."

>> PRINT 1 + 2
>3

I know. Same thing that totally excited Paul Allen when it
"finally worked."

I completely get that. A good teaching tutorial will also
cause the reader to make MANY mistakes, so that they can also
learn what it looks like when something is wrong. They need
to become familiar with the errors as much as the successes.

> Starting with assembly code and a whole bunch of
> instruction, at a low level, is no substitute for getting
> stuff done with instant gratification. They'd work using
> things that they understand, like 1/3 being 0.333333. They
> wouldn't need to think "how do I divide two numbers, there
> no instruction for it?" They wouldn't be confused that
> printing 1/3 shoves out a zero. They wouldn't need to think
> about binary to ASCII output, or about where the characters
> "go".

You talk as though these things are mutually exclusive. For
some concepts, yes. But not all. Anyway, this is something
I'm researching now. So I am not well prepared to give
argument about this. I simply am not sure I agree with each
brick you've laid them out above into a foundation that leads
to an always-true conclusion you may also have made.

In any case, I'm still searching out my muse on this stuff.

>>> 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.
>
>Raspberry Pi; simple economies of scale working here.

As a developer's system that supports multiple targets? Hmm.

>> 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.
>
> I think that just isn't material. If you want to introduce
> somebody to programming, there isn't anything more
> accessible than a small computer where BASIC *is* the OS
> after switching it on.

I kind of liked the front panel on a PDP-8/e or a PDP-11/20.
Pretty acessible if you ask me. Just at a different level.

I'm also a little more interested in addressing something
that isn't already in the bead-sight of business. And I don't
think anyone in business will care much about what I write or
do for that reason.

Jon
Start a New Thread

>> 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.)

Surely, giving them something that would have immediate feedback, with a feeling that they are in control and it isn't beyond them, is a great place to start.

> PRINT 1 + 2
3
>

Starting with assembly code and a whole bunch of instruction, at a low level, is no substitute for getting stuff done with instant gratification. They'd work using things that they understand, like 1/3 being 0.333333. They wouldn't need to think "how do I divide two numbers, there no instruction for it?" They wouldn't be confused that printing 1/3 shoves out a zero. They wouldn't need to think about binary to ASCII output, or about where the characters "go".

>
>> 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.

Raspberry Pi; simple economies of scale working here.

> 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.

I think that just isn't material. If you want to introduce somebody to programming, there isn't anything more accessible than a small computer where BASIC *is* the OS after switching it on.

-- Paul.

Start a New Thread

On 10 Dec 2012, at 20:21, Jon Kirwan wrote:

> 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?

The linker enforces the restriction because it knows which tool generated the object code. TI engineered a way around this limitation at one point (IIRC, for SimpliciTI or something) by taking the assembly code output of the compiler and feeding it to the assembler (with some modifications? No idea) such that it did not count towards the 4K compiled code limit. I assume there was a to-and-fro with IAR about it, and then IAR removed the ability of KickStart tools to generate assembly code output.

This is what I recall from a few years ago. It may not be current, and I don't have the enthusiasm to test it out again.

-- Paul.

Start a New Thread

--- In m..., Jon Kirwan wrote:
>
> 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
>

Good question. I seem to recall that when I ran the MSP430 assembler from within the IDE, I got the size restriction. I remember this only because it surprised me. It never shows up when I run the Assembler and Linker directly - i.e command line within a procedure file - which is how I alway use them.

Blakely

Start a New Thread