Steve,
I didn't find the peripherals on the MSP430 all that weird. In fact the
ADC is very simple to initilize and have it automatically keep the
latest readings in memory. Yes, there is a little confusion about the
correct sequence of some operations, but peripheral code tends to be
written once and then reused from one application to another.
There are two reasons programmers should learn the assembly operations
for a microcomputer.
When you learn assembly operations you truly `own' the microcomputer,
and development tools. If you step through code using gdb at the C
source line level you get many unreasonable results due to optimization
- gdb isn't really where it claims to be. If you're debugging code that
interfaces to the hardware you need to be familiar with assembly
language. Once you get to the `printf' level of debugging then C is
all you need.
Most programmers won't write a real time preemptive task multiplexer,
but those who do will have to `mess with the stack'. As a very minimum
there will be some inline assembly instructions to do that. In fact, C
gets in the way here, even if you do such strange things as setjmp and
longjmp. In the end, some clean and clear assembly language makes the
operations more transparent.
Take the case of a timer interrupt that can preempt a running task. If
the interrupt comes in the middle of a system operation, such as
dispatching the next task, then evaluating task priority is probably not
desired. A decision has to be made - simply return to the interrupt
code, or enter code for a context switch, that is `mess with the stack'.
I would never advocate that assembly language be used for application
programs, but there are instances where it is the best language for the
job.
The MSP430 without expanded memory is a great product, but TI missed the
boat when they didn't bite the bullet and expand address size to 24 bits
and chuck the backwards memory layout with the 16-bit version. I was a
user of the TI9900 in a communications product of the early 1980s, but
TI didn't understand that OEM customers counted. See this URL for more
information:
http://chung.yikes.com/~leonard/mirrors/ti99/9900story.html.
The 9900 was a superior architecture for its era and could easily
compete today in modern silicon. I'm guessing that people who need more
memory space than 64K will come to realize that having to worry about
pointer size and data location aren't sufficient justification for very
low power consumption. Companies that take a step sideways and call it
an advancement are shortsighted and no amount of PR rationalization is
going to cover that.
On the other hand, people who ignore history won't have to read a lot of
rewrites.
Sincerely,
David Smead
www.amplepower.com
www.amplepower.net
On Sat, 14 Apr 2007, Steve Underwood wrote:
David Smead wrote:
Steve,
As you say, the MSP430 barely sips power, and with a fast 12-bit ADC
onboard its a great machine. We are, in fact, using an MSP430 in a
product that we sell many thousands annually. There are some other very
nice attributes of the MSP430, the instruction set being one of them.
The instruction set is nice - though I would encourage anyone to use C,
and never touch the instruction set. The peripherals are also nice. They
take a while to learn, compared to a lot of other people's peripherals,
because they can generally do more and have more bits to control.
However, people really like them when they get used to them. The are
very regular, and they don't keep changing from chip to chip. I think
the last point is a big one for many users.
MSP430 users seems to break down into 3 groups:
- those who need low power
- those who need good analogue performance
- those who just find it nice and easy to use
A lot of users fall in the third category.
Another nice feature is the non-segmented architecture. If you tend to
generate large tables and write `table execution functions', then direct
access to flash memory is most convenient. Such is not the case with
PIC and AVR machines where all data read from program memory has to go
through the Z register funnel.
This should serve as some kind of red flag for those looking at the
compiler and linker for the extended memory versions. When you have to
do anything special to access one part of memory versus another, you've
broken standard C and have introduced extra work initially, and should
you ever port the code to a different processor, you'll have to re-visit
your source files to extract the extra pragmas, macros, etc. Having
ported some AVR code to ARM code, I know it isn't quite as easy as it
might seem, especially where there are function calls to get data into
RAM just so a standard pointer can access it. Even when I wrote the AVR
code in the first place, revisiting it to convert it back to standard C
was painful.
I've also `ported' some MSP430 C code to an ARM, which really only
required some different header files before executing make. That's the
way it's supposed to work.
Complaining about interrupts in the middle of the address space seems a
bit silly to me, when you compare this to the dreadful clunkiness of
most other MCUs. I write models on my desktop, and usually run them with
good efficiency on an MSP430 with no changes to the code - though
obviously with some changes to initialisation, peripheral control, etc.
Bigger devices like the ARMs are like that, but few 8 and 16 bit MCUs are.
I have only found using IAR for the MSP430X to be a nuisance because I
have written things with small code and huge data. The interrupts are in
the middle of my data, and the compiler won't let me point freely across
the data. The latter is a compiler issue, though. The chip has no such
limitations. My program is probably a little unusual, too.
Yes, there are usually some work-arounds for ARM chip peripherals;
code density is not great; there is a steep learning curve to
assembly language; power consumption may not be low enough for some
applications; high resolution analog can only be found on some chips
from Analog; However, a pointer is a pointer and you never have to
worry about what size it is. In any program/data space bigger than 64K,
that's a big deal. In my opinion, a microcomputer that has segmented
memory is the worse kind of bug that bites over and over again.
Who programs an ARM in assembler, apart from a compiler developer? :-\
The ADI ARM MCUs are the only ones I know with reasonable analogue
performance. I've never seen a comparison of how well they turn out in
real world designs. Lots of people make grand claims for analogue
performance, which you have tremendous difficulty seeing in practice.
Regards,
Steve
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
