On 6/21/07, Rick Jenkins <[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
