MSP430 Development with Linux
Linux embedded development doesn't only mean embedding Linux in a product, it also means using Linux as a development platform for embedded microprocessors. The majority of computer processors are not on the desktop or in Beowulf clusters, they are embedded in the millions of devices that you use every day: your alarm clock, microwave, thermostat, car, cell phone and so on. Linux can be used to develop software for embedded projects using microprocessors like the Microchip PIC, Atmel AVR, Philips LPC ARM and TI MSP430 devices.
You don't need to be a professional developer to have fun with these tiny computer devices. The development tools are inexpensive, and the hardware required is minimal. Soldering skills and some experience writing in C are really all you need to get started creating a controller for your next Sumo Bot, remote controlled helicopter or digital lock.
The Texas Instruments (TI) MSP430 family of microprocessors have a wide range of features:
Power consumption as low as 0.1uA in off mode.
Multiple 16-bit timers with capture/compare.
PWM outputs, which are very useful for robotics.
A/D converters for monitoring sensors.
SPI and Asynchronous UARTs for communications.
Integrated LCD display controllers.
Multiple clock sources for low-power sleep modes.
The '430 family includes more than 80 devices in four major groups. Flash, where the program is stored, ranges from a paltry 1KB to an extravagant 60KB. The available RAM is as large as 5KB or as small as 128 bytes.
Of course, 128 bytes isn't much RAM, but it is enough to get the job done for small projects. Many of my embedded projects are written in assembly code to conserve space, but with the MSP430, I have found myself using C as the primary language. Instead of using a commercial compiler or IDE, I have chosen to use the GNU GCC toolchain, which has had MSP430 support added to it. The GCC compiler does a pretty good job of generating code, and C is certainly the better choice if the the code is going to be maintained over a number of years. There's nothing worse than returning to heavily optimized assembly project five years later and trying to make adjustments without the whole system crumbling to its knees.
With the Microchip PIC processors that I wrote about in 1998, the development process was a bit tedious. I would write some code, compile it, flash the PIC, wonder why it didn't work and then repeat. I used a couple of I/O lines and LEDs as debugging tools, but there's only so much information that you can grok from two flashing LEDs. I really had no way to know exactly what was going on inside the processor when things went wrong. One solution could have been to buy an In Circuit Emulator (ICE). An In Circuit Emulator is a device you plug in to the socket where the processor normally goes. It emulates the CPU and lets you examine every instruction, memory locations and much more. But the $1,200+ US price for an ICE was out of my reach.
Today, things are much easier for both the the hobbyist and professional. Many of the newer processors include built in real-time debugging support using the IEEE Std 1149.1 JTAG specification. This six-wire interface allows real-time debugging of the software running on the target device. You can step through your code, watch registers and memory locations change, insert breakpoints and modify RAM on the fly. This is a dramatic improvement over the old 1- or 2-bit diagnostic line.
Instead of dropping a dozen c-notes on expensive debugging tools, you can get a parallel port JTAG adapter from Olimex for the amazing price of $15 US. This allows people to debug their code with interactive debuggers like gdb instead of relying on blinking LEDs and serial ports.
MSP430 support was added to GCC by a group headed by Dimitry Diky and Chris Lichti. Their project includes the gcc compiler, linker, libraries, gdb debugger and a closed-source interface to the parallel JTAG adapter. The main emphasis of the mspgcc project has been on the Windows. Getting it working on Linux is a bit of a struggle, involving compiling the alternate toolchain, libraries and so on. Maybe I'm getting old, lazy or just used to .deb and .rpm packages, but these days, I prefer not to fight with the software I'm installing. Running rpm -Uhv <package> saves my energy for debugging my MSP430 code.
Thanks to Stephan Linz and his Cross Development Kit for MSP430, I don't need to spend more than five minutes installing development tools. He has done all the hard work getting mspgcc compiled and packaged as RPMs. Stephen also has created Cross Development Kits for the AVR processor and the Altera soft core NIOS, if you are interested in those target processors. If I ever need to write code for the AVR, I know where to go.
The cdk4msp project is available from SourceForge, and here is a minimal list of the packages that need to be installed from the cdk4msp SourceForge download page:
Additional document packages can be downloaded, depending on your preference for man pages, info files, PDF or HTML pages. I have successfully used these packages on Fedora Core releases 1 through 4, and although I haven't tried any other RPM-based distributions, I expect them to work just fine. These RPM packages function as a self-contained unit, and don't depend on any outside packages.
Install the packages in this order with the following commands:
rpm -Uhv cdk-msp-base-0.2-20031111.i386.rpm rpm -Uhv cdk-msp-binutils-2.14-20031106.i386.rpm rpm -Uhv cdk-msp-libc-20031101cvs-20031102.noarch.rpm rpm -Uhv cdk-msp-gcc-3.3.2-20031106.i386.rpm rpm -Uhv cdk-msp-gdb-5.1.1-20031106.i386.rpm rpm -Uhv cdk-msp-jtag-lib-20031101cvs-20031102.i386.rpm rpm -Uhv cdk-msp-gdb-proxy-5.1.1-20031106.i386.rpm rpm -Uhv cdk-msp-examples-libc-20031101cvs-20031102.noarch.rpm rpm -Uhv cdk-msp-examples-mspgcc-20031101cvs-20031102.noarch.rpm
The install places everything in the directory tree below /opt/cdk4msp. Take a look at the examples in /opt/cdk4msp/examples/mspgcc and the documents in /opt/cdk4msp/doc, info and man directories, depending on which style of documentation you installed.
|September 2015 Issue of Linux Journal: HOW-TOs||Sep 01, 2015|
|September 2015 Video Preview||Sep 01, 2015|
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
- Optimization in GCC
- Using tshark to Watch and Inspect Network Traffic
- September 2015 Issue of Linux Journal: HOW-TOs
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python