I really should hold off on posting about my cool finds until I confirm that they’re in working order.  In the case of that Palm iii that I found, I finally popped some batteries in and it doesn’t appear to be very functional.  The backlight comes on but that’s about it.  If I hold the reset button down, it makes a whining noise.  This could be as simple as the OS image having deteriorated out of memory or it could be something more serious.  I’ll have to investigate further.

I guess if it wasn’t frustrating, it wouldn’t be engineering.

Recently, Motorola had a massive layoff and I was affected.  This isn’t really a source of great worry for me and Amy, and we’re relocating to the West Coast.  If you happen to need a computer science and digital design dilettante and you’re living in the Bay Area, Portland, or Seattle, please give me a ping!

Anyway, part of moving is going through your old things and figuring out what to throw out.  I recently rummaged through a storage box and found a bunch of very interesting things…an old bike light I wasn’t using (which contains, among other things, some useful ICs)…a digital camera (ripe for hacking or scavenging)…an old Nintendo Pikachu digital pet (looks easy to disassemble)…and, the real gem and the reason that I’m making this post…

At the bottom of the box, sitting there and looking back at me, almost as if to ask me where I’d been for nearly 10 years, was my old Palm iii.  I bought one back in the late 90s as a way to get into apps development for handheld devices.  It’s a fairly sad sight by modern standards, with a monochrome screen and text input through an inscruitable writing system, but it’s also a complete platform ready for hacks.  I recall that, back in the day, someone designed a tilt sensor for it and made a game similar to Labyrinth for it.  For a maker who’s living on severance money, this is a real, real find.

The first order of business, of course, is to create a flashing process.  I already found the flashing utility, so next will be either finding or, more likely, building a sync cable.  After that, I need to locate some documentation on its memory architecture and any firmware routines, because what I really want to do is write a new OS for it.  The limited space will likely make it a challenge, but something I’ve often found to be true is that writing an OS for a mobile device, even one with not many resources, is still more pleasant than working on the x86 architecture.

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!

My darling wife raided Makershed for my Christmas gifts.  Among them was a fun little project called the USB7, a set of 6 7-segment displays that are powered by, and interface through, a USB port.  It’s powered by an ATMega, not unlike an Arduino.  The kit itself just requires solder assembly, so a soldering iron, needle-nose pliers, and diagonal cutters will suffice for tools.  The PCB is phenomenally easy to work with, with clear silk-screen markings to tell you which components go where and in what orientation.  It’s probably the most user-friendly kit board I’ve ever seen!

As for the final result?  It’s actually very handy.  Getting the drivers for it installed was a touch fussy, but after that, it exposes a simple COM port and you can interact with the project using a terminal program.  Six characters and a newline…that’s all it takes to update the display.

What’s great about the simple protocol is that it actually lets you do some fairly complex things.  For example, you can use whitespace characters to create simple scrolling animation effects.  You can also configure LCD Smartie to work with it, exposing interesting goings-on in your host machine to the display.  The board also has a header for reprogramming the microcontroller.  I’m certainly going to have fun mucking about in the code because the USB interactions appear to be 100% in software.

In short, it’s a fun way to spend a couple hours and you get a really neat component at the end.  I highly recommend it, especially for beginners.

Picture below is from the creator’s site.  My digital camera is AWOL at the moment.

The USB7 in red (mine's in green). It lights up way better than the picture suggests.