Neil Wyper wrote:
On 6/21/07, *Rick Jenkins* <[email protected]
<mailto:[email protected]>> wrote:
The best thing about mspgcc is that, being based on a mature compiler
technology, it works very well nearly all of the time.
Having mspgcc based on gcc is great. I often develop code and run it
natively on Linux with GCC, then recompile the same code for use on an
MSP430. There are many benefits of using different ports of the same
compiler. For example, the makefiles I use for the MSP430 are almost
identical to the ones used for Linux (or Cygwin if you use Windows).
The compiler flags are mostly the same, and the learning curve is
reduced for each new target processor. I've also used GCC ports for
Arm, SuperH, and HC1x, so using a familiar toolchain is convenient.
Most commercial tools strongly encourage you to use their custom IDE,
which can get in the way of testing embedded code on a desktop PC.
For testing embedded MSP430 code, I often compile natively on Linux and
link in Python, to allow some really useful testing. GCC isn't a
requirement for this, but it is more convenient than other solutions.
Custom python modules emulate the hardware that the code will run on,
and provide simple GUIs for interacting with the test software in ways
that wouldn't be possible on the real hardware.
As far as mspgcc-specific toolchain issues go, I can only think of one
time that the compiler generated bad code that affected my work. A
newer version of mspgcc was available before I came across the bug, and
the problem was already fixed. If you don't consider time spent reading
this list, my time spent with MSPGCC is almost exclusively doing real
MSP430 work and not fixing with the toolchain.
Thanks Steve, Chris, Dmitri, and everyone else that has contributed to
MSPGCC.
Neil
I have had similar experiences. I try to use GCC for everything I do now.
I especially like your method of using Python to emulate the target platforms,
and wonder if you might say a few words about how to get started (to link
Python modules with code intended for MSP430).
Thanks to everyone for the excellent tools and contributions.
William
