Firmware Development with Eclipse
Most people who work with me know I'm not a big fan of Eclipse though I do use it from time to time for typical Java tasks. I also used it several years ago with CDT to do C++ development for some GIS projection code and it worked well for that task. Recently, I used Eclipse for something I've never used it for before: writing firmware. I like building GPS related devices and software applications and bought an Olimex SAM7 P256 development board so I could start learning the ARM core architecture and specifically the SAM7 microcontroller from Atmel. The SAM7 (S256 flavor) is a 32bit RISC microcontroller that has 256KB of built-in flash memory for holding firmware and 64KB of RAM. It incorporates two serial ports, an analog to digital interface, a plethora of digital GPIO ports, built-in USB physical level support, and has SPI (Serial Parallel interface) which is a low-level (register level) mechanism commonly used for communicating with external flash devices like SD and MMC cards. The device runs on 3.3 volts and needless to say, has a lot of functionality packed into a low-power package that is smaller than a postage stamp. The Olimex development board which incorporates the SAM7 looks like this:
This board breaks out all the GPIO and serial interfaces, adds a themistor for measuring temperature, a few buttons to exercise GPIO, and provides a JTAG interface. JTAG is a physical and electrical standard used to both flash new firmware into embedded devices but also used to source-level debug embedded code running directly on the platform — in the olden days, this functionality was encapsulated by a huge machine, ICE (in-circuit emulator), which cost thousands of dollars. In fact, one of the ways the iPhone was cracked was through a builtin JTAG interface embedded deep in the iPhone. JTAG is one of those ubiquitous technologies that flies under the radar – it is everywhere if you know where to look. I bought a JTAG for ARM programming device (~ $70) which works in conjunction with Eclipse and a package of GNU ARM cross-compiler tools called Yagarto (Yet Another GNU ARM Toolchain.) That tool chain, along with an excellent tutorial written by Jim Lynch, got me up and writing C code for the SAM7 in about 1/2 hr (not counting download times.) This is a picture of my setup – the Olimex board connected through JTAG to the Olimex JTAG programmer which is USB to my laptop development environment:
In order to use JTAG, Yagarto incorporates an open source JTAG middleware piece called OpenOCD (Open On-Chip Debugger.) OpenOCD's main task is to be the mediator between the Eclipse, ARM cross-compiler binaries, GNU GDB and the JTAG programming device itself. OpenOCD's gdb service is not used to flash the device, just debug with it, but OpenOCD software is involved with flashing the device. There's a special build target in the Eclipse project that defines an OCD script for flashing the device. Using Eclipse and OpenOCD, I was able to single-step through lines of C code in my Eclipse environment though the code was running directly on the SAM7 board. Considering everything that was going on in order to make that happen and considering the cost of the software development tools was $0, this is nothing short of impressive. Some shortfalls in the environment that I found were mainly 1) productivity tools for embedded development in Eclipse are very lacking. For example, I wanted to easily be able to look at a hex dump of memory, but there's no simple way to do that (no way that I found.) 2) after running through one session with OpenOCD and JTAG, in order to reflash my device, I had to unplug the device which kills/disconnects OpenOCD, and then reconnect to reflash it. 3) there are some odd breakpoint issues with OpenOCD and JTAG which limited the ability to set hardware breakpoints…I would often have to clear all breakpoints right after starting a JTAG debug session before I could get anything running again. There are other commercial embedded tools that work much better but cost thousands of dollars to get into. So, given the price and functionality of this solution, I can live with those limitations – this package was good enough for me to develop an SPI SD/MMC flash memory card driver, for example. I also developed a non-interrupt serial driver with it. It's plenty good to do real work with. So, there's a new use of Eclipse that partially redeemed it in my eyes.


