It should be no surprise that, thanks to the Auduino platform, I reach for an AVR microcontroller first…at least for any project where an ARM SoC isn’t what I’m after.  Part of the success of both the AVR and the Arduino platform (which is based on the AVR) is the proliferation of tools.  When you’re working on a microcontroller, you’re flying with one propellor and not much else.  In fact, in any good embedded development shop, you’ll find at least one tools specialist whose full time (or nearly full-time job) is to cobble together the toolkit for the other engineers.  This person’s bread and butter is keeping everyone else from flying blind.

Suffice it to say, I love a good tool, and this could be one of the best I’ve seen in a long time…AVRSH, a command line and shell that directly exposes the features of an AVR.  Register manipulation, pin configs, fuses…it’s all in there, and you can interact with them using a very familiar interactive shell.  This is useful for two major reasons.  The first is for those times when you need to poke around and scope out how a chip feature really works.  Traditionally, I attack this by making a “dummy load” program and either single-stepping through it with debugger or watching the fireworks through JTAG.  If neither are available, I make the program have some long timing in it and I start attaching an oscope or LEDs to watch the state of lines.  This works, but it’s a crude process that’s infinitely improved by letting me more freely interact with the chip’s features myself.

The other way AVRSH is awesome is in general proptyping of a concept.  Because the only way to know if your program works is to build it, program your board with it, and watch the results, there’s an endless treadmill involved in early prototyping.  An interactive shell greatly improves this scenario, especially if you’re engaged in HW/SW co-design and need to watch how changes at one level impact another.

This is, effectively, the difference between exploring a cave by throwing wireless cameras in random directions and watching the video produced…and exploring a cave by picking up a flashlight and going for a stroll.

Make this a great scripting environment and basic embedded systems programming just became a first-class part of the Linux apps programming world.  With AVRs making such great controllers for robotic activities, how long before “Begone or I’ll replace you with 10 lines of Perl” really becomes true?

Hooray!  I can now create, build, and run C and C++ projects through Eclipse on Windows.  Through my bug report to the Eclipse CDT team, it came out that CDT was locking indefinitely while interacting with gcc.  On my box, gcc is provided through Cygwin.  The problem, however, came up because, thanks to my Processing environment, my Arduino environment, and my WinAVR tools, I had multiple versions of the cygwin1.dll file.  When gcc was executing, it was picking up the wrong one and this was causing it to hang.  CDT would hang along with it.

The CDT team is looking into correcting this.  In the meantime, though, if you experience hangs creating a new project in CDT, I suggest you follow the advice in the bug report.  Try this command:

gcc -E -P -v -dD <workspace>/.metadata/.plugins/org.eclipse.cdt.make.core/specs.cpp

And see the result.  Gcc will report a pretty thorough complaint if you’re having a problem similar to mine.  At that point, you just need to hunt down and remove the extra cygwin1.dll files.  When I did this, it didn’t appear to ruin my Processing environment.  I haven’t checked my Arduino environment, and I’ll need to reinstall my WinAVR tools.

Of course, if I can’t have all the tools concurrently, I’ll have to switch from Cygwin to MinGW.

Possibly the most important, and most overlooked, aspect of any embedded software shop (including board bringup and BSP development) is the software tool chain.  It’s hard to imagine that we live in an age when the availability of processing power has grown to such phenomenal ends yet people continue to use a tool chain barely updated since its invention in the 1980s.  In fact, a friend of mine (let’s call him Code Monster) who develops for a major game console company, has patents on nothing more than software tools.  We both agree a life spent making better embedded software engineering tools would be a life that hasn’t been wasted.

At work, we essentially use a variant on the “not since the 1980s” technology.  Most of the engineers use a text editor that provides text coloring and some searching, then switch over to Platform Builder for flashing and debugging.  Debugging is basically a mix of logging over Ethernet and a Microsoft-built system for injecting debug breaks and doing stack and memory analysis.  In short, it’s your standard debugger.  Now, granted, we could be using a more integrated system through Visual Studio, but we opt not to because it gives us a bit more control over the build process.

In fact, I understand the need for control like that, and that pushes most engineers to almost worship a minimal tool system, even if tools would make them more productive.  I do not, however, think it’s necessary to get control only through giving up productivity, and I’m trying to reflect that choice in my own tool stack at home.

In another life, I was a Java developer, and probably the most powerful tool for any Java developer, outside of Java itself (which is its own tool stack), is Eclipse.  I remember when I switched to Eclipse.  I was easily doing my work in half the time.  Its incredible powers to check my code without a recompile, place compiler errors in the IDE so code could be reviewed quickly, and auto-hint valid expressions (with documentation) all changed my work life.  I was no longer hunting through docs to remember a parameter list, or trying to remember what returned what.  I was free to focus on the things requiring real intelligence — algorithm design and general subsystem architecture.  If my team had been large enough to need tools for source control, bug tracking, and code review, Eclipse could have handled it, too.  To this day, I still haven’t seen a more rich tool set, and I think everyone should try it for at least a few months.  My mantra at work has often been “I’d get so much done if my tools stopped getting in my way.”  I’ve rarely opined that about eclipse.

Of course, if you escalate all warnings to errors, C and C++ have a type strength close to Java (within reason), so you could a very similar tool stack, even for embedded development.  Others seem to have caught on, and Eclipse has, for a few years, been working to make inroads on C developers through the Eclipse CDT project.  I figured I’d give it a try over the weekend, especially since you can adapt this IDE to become an Arduino development environment and I would, in the near future, like to start poking around in its boot code.

Unfortunately, it seems every project I create hangs Eclipse shortly after it makes the project folder and some of its metadata.  I don’t know what’s wrong yet.  I have a bug in with the CDT team and I will see if it’s Vista related by trying to install CDT from my computer at work.  The problem must be something simple because they’d have never released code with such a basic feature broken.  Watch this space!