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.
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.
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.
Sincerely,
David Smead
www.amplepower.com
www.amplepower.net
On Fri, 13 Apr 2007, Steve Underwood wrote:
N. Coesel wrote:
At 12:44 12-04-07 +0200, you wrote:
Grant Edwards wrote:
On 2007-04-11, [email protected] <[email protected]> wrote:
The latest compiler supports the extended CPU; the problem is
actually in the linker--I can't seem to make it recognise both
chunks of code space (that below and above the vectors).
Below is my original posting. I'm hoping someone knows the
answer now.
Getting the linker to recognise this extra space is easy. Getting it to
work in an easy, intuitive manner is hard.
Firstly, a CPU with a non-contiguous code space is just plain
f&*cked up.
No, it's not - but it *is* and extra headache. There are many
Given the huge number of ARM based controllers out there with extremely
competitive prices I think it it better to choose an ARM instead of a
larger MSP430 device with a memory kludge. Both can be programmed using GCC
toolchains, so code portability isn't an issue. Even porting MSP430 libc to
ARM is a piece of cake.
The MSP430 does two things really well - low power, especially for burst
mode applications, and analogue.
The ARM is only low power compared to most other microcontrollers.
Compared to an MSP430 it is a power hog. TI produces ARM
microcontrollers (overall, its the largest maker of ARM cores, though a
large percentage go into phone chips), and that business has very little
to do with the MSP430 business.
Most ARM microcontrollers have awful analogue performance, although some
good ones are appearing. The MSP430 tends to beat the best of them, though.
It seems most ARM based microcontrollers are riddled with bugs. Any
simplicity in code productions is more than offset by endless
workarounds in the peripherals. The microcontroller business can be
amongst the worst for buggy chips, but for some reason the ARM
controllers tend to be the worst of the bunch. Maybe too many makers
think that because they have a ready made core, they can throw a whole
controller together in a quick and dirty manner.
If you don't need the qualities the MSP430 gives you, there might be
other choices. If you do need them, the 430 still beats anything else
available, often by a large margin. The clunkiness of having interrupt
vectors in the middle of the address space is pretty minor overall. The
existing compilers for the MSP430X make this very transparent. Its
memory paging that makes things really clunky, and there is none of that
in the MSP430X design. Even a Pentium boots with the interrupt vectors
in the middle of its address space. :-)
The real limitation with the MSP430X right now is the tools. The IAR and
CCE compilers use 20/32bit function pointers, but only 16 bit data
pointers. This means code can sprawl all over the address space, with
only the interrupt routines caring about their location. However, any
application with a huge amount of data has to manage that data manually
and slowly. The compiler will not place any of it above 64k.
If all you care about is easy programming, see Dell. :-)
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
