I’m writing this in the hopes that it eases the pain of others.  You see, it took an annoying amount of web searching to find a satisfying resolution to all my woes.  Let me explain…no, there isn’t enough time….let me sum up.  The controller, or possibly a motor, went bad on my desktop’s hard drive.  After spending a full day desperately trying to resuscitate it, I put in a new hard drive, but I didn’t have a Vista installation disc handy, so I installed Ubuntu Linux on it.  Now, I could have tried using Ubuntu on my main desktop, I guess, except for one thing.  Mitch Hedberg once said “A mini bar is a machine that makes everything expensive.”  As much as I have used and loved Linux, I must confess– it’s an OS that makes everything incompatible.  Case and point– it didn’t work with my Bluetooth mouse and keyboard.  Both of them have a power-saving feature where they shut off until an I/O event, at which point they re-partner.  The Bluetooth system on Ubuntu wasn’t up to the task.  Besides that, I can’t run Adobe CS4 on Linux.

Anyway, I had to re-order the system recovery discs from Acer.  I popped them in and let them get to work, only to fail with the well-documented “Error: 0xd0000017″.  Of course, everyone knows what this hex number means, so I’ll just get on with it.  Actually, I’m lying.  Nobody knows.  I sure didn’t.

Error 0xd0000017 is basically an Acer recovery CD complaint that means “Waaaah!  This drive has stuff on it!  I can’t handle this!”  You very likely will experience this problem if you use these discs to replace a Linux install.  So, what to do?  Well, grab a handy Ubuntu CD or, in my case, USB stick.  You need to do this so that your root file system is not your hard drive.  Then, from there, you’re free to blow away your hard drive’s contents.  I only have the one drive, so it’s easy to find — /dev/sda.  A full wipe was thus easy to do with the following command:

dd if=/dev/zero of=/dev/sda

Note that that’s /dev/sda and not /dev/sda1.  Blow everything away, including the partition information.  After that, the Acer disks will run just fine.

I should note that this is a fairly slow process, however.  It took nearly 24 hours to clean out a 1.5 TB disc.  If anyone has advice on how that can go faster, please feel free to mention it in the comments.

I am not entirely sure why I haven’t posted here sooner.  I guess I felt it was best to get some time at the job under my belt before talking about it too much or I’d jinx it.  Either that or it’s my short attention span.  Either way, while a build grinds out, it’s time for an update.

I am alive and well and living on Ganymede.  Not really.  I’ve moved to San Jose.  Pretty much the week I arrived here, I’d gotten the matter of my unemployment handled.  I now work for Hewlett-Packard in their emerging technologies group.  I’m not really at liberty to talk about my project (even though it was leaked), but I can say I’m working on some new products for the company and I get to spend a lot of time working with a lot of open source material.  I think Dr. Boykin might be pleased.

Of course, I’m still living in a small space and don’t have my electronics equipment with me, so there hasn’t been much fun hardware hacking on that front.  On the software side, I’ll mention a follow-up to my EeePC.  I blew away the Asus-supplied Linux distro (known as Xandros) and replaced it with Easy Peasy.  I have to say that, while I haven’t used Easy Peasy heavily yet, it strikes me as not only as superior to Xandros on a netbook but possibly as one of the most attractive Linux distros I’ve ever seen.  Better still, of course, is that installing it involves removing the copy-on-write filesystem scheme used on Xandros, so I now suddenly have an attractive desktop environment, a full suite of development tools, and plenty of free space on the SSD to spare.  Developing from an SD card isn’t horrible, but it can get really slow.

One of the fun things I get to do at work is to muck around with extensions to an emulator.  If I can find a way to write about that on here without accidentally getting myself in trouble, I’ll make a future article of it.

With all my tools and components packed away until I move and get a new job, some of my focus is changing over to playing around with low-level software on two pieces of hardware that are stable and that I’m likely to have with me always — my laptop and my desktop.

My laptop, however, recently died and did so in a way that likely will require the attention of skilled technician to diagnose and repair.  I went though this sort of thing once before when my previous laptop had bad solder joints on the second RAM bay.  Generally speaking, the bench fee alone can be $100, and there’s no guarantee that it’ll get fixed.  So, I cashed in some Best Buy cards from Christmas and bought an Eee.  The general logic is that it’s a laptop that would let me do the basic things I need, including hunt for jobs, and it’d be a certain thing.  I must admit, too that the form factor is really nice, even if the keyboard is a bit small and laid out strangely.  I was also excited by the prospect of having a Linux-based laptop.  In the past, I’ve often found Linux fairly unstable on my computers, especially on my laptops.  Having a hardware platform assembled specifically to support Linux, however, was encouraging.

The first thing I wondered, though, was how hard it would be to get the kernel to compile.  As it turns out, it’s actually pretty easy to do, although there were some bumps and frustrations along the way.  There are some reasonable instructions over on the EEEUser Wiki, but I found that some clarification of these instructions was in order.

First, I think it’s a wise idea to get your kernel hacking environment set up BEFORE applying any of the automatic updates from Asus.  As of the writing of this article, none of the updates appear to be particularly necessary, and they also seem a bit broken, as apt-get keeps complaining about Picasa not being installed.  On top of that, one of the updates appears to install a very exotic version of glibc.  You’ve been warned.

Next, I strongly suggest that you install the development tools (gcc, etc) following the instructions that use the EEE SDK iso.  For my purposes, I purchased an SD card for my Eee and downloaded the iso onto it, then mounted the iso.  The instructions I’ve linked to tell you to add a line to your /etc/apt/sources.list file.  I do not, however, think it’s sufficient to add that line anywhere.  I recommend commenting out the other sources by prepending a # to each line, then adding the line that points to the packages in the mounted iso.  Once this is done, it’s pretty easy to get the build packages installed.

From there, downloading and building the kernel source from the instructions on the EeeUser Wiki was fairly straightforward.  It’s worth noting, however, that installing the build tools and the kernel source will take up enough storage that, on a 900A model like mine, you’ll have almost no space left on the disk.  Of course, there are great instructions out there on how to cut the fat from your RW partition, but I decided it’d be nicer to do all my kernel work off my SD card instead.  The reason for this is that the sectors on solid state storage will survive only so many writes, and compiling things definitely will involve doing a lot of writes.

The first problem I noticed with trying to get the kernel source on my SD card is that, even after I removed the SDK iso, my card seemed to lack any free space.  Since I was planning to just treat this as an extra mostly-permanent disc anyway, I went ahead and reformatted the SD card with the ext3 filesystem.  Then I had no trouble copying the kernel source over.

Unfortunately, this seemed to break the build, as make started returning this error to me:

`target pattern contains no `%’. Stop.’

Rummaging around online suggested that it might possibly be because make was processing a symbol with a colon in it.  That’s when it dawned on me that the culprit was the default mount point for the SD card: “/media/D:”.  Aha!  Making an extra mount point, in my case “/media/sdcard”, and mounting /dev/sdc1 (the SD card device) to this directory did the trick, and now I can build the kernel out of my SD card instead.

It’s worth noting that there are some mild limitations here.  The compiler and library are coming out of Asus’ SDK release, so you can’t necessarily pick and choose versions.  This also can limit the kernel versions that you can compile, and the instructions above basically give you the “canonical Eee kernel source”.  This is, however, very sufficient for my purposes, which include staying sharp on developing kernel modules and playing around with the driver code for the Eee.

And, of course, you can do your kernel hacking from pretty much anywhere, because the Eee is very small and light and it’s got a pretty good battery life.  I’ll have a VMWare machine set aside for my deeper diving and more serious work  This plucky little sub-notebook, though, is a perfect thing to kick around.

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.

“So, I found a display that I like, but it has to be hot-bar soldered, and I don’t think I’m set up to do that,” I said to Workplace Mentor.  “You’re looking at this the wrong way,” he replied.  “Choose the main processor first, then pick something that matches the right interface, and then concern yourself with how to attach it.  When you’re prototyping, it’s usually easy to roll around issues like how you’ll connect something.”  I hadn’t thought of that, and it sent me back to my desk.

I have been spending some of my free time trying to source parts for a new project.  I want to learn how to, from the ground up, build a platform and write a BSP from it.  This is something very much apart from what I do at work.  Generally speaking, I enter the process after we’ve already retained a vendor and our electrical engineers have had their turn, demanding the necessary hardware to support our features and so forth.  At that point, the evaluation boards have been cranked out and a sample BSP for a number of features exist.  Often, when I get involved in very low level work, it’s because the sample BSP presumed the existence of a chip that our hardware designers replaced in secret.

So, yeah…I could go out and buy an evaluation board for some ARM processor, complete with a rich boot loader and even a BSP and some sample apps.  I could.  Sparkfun has tons of them.  If I did, though, I wouldn’t really learn anything new.  Sure, I’d have some shiny pictures to put up here, but I’m still just following in someone else’s footsteps, and I do that at my job.

What Workplace Mentor said, though, sent me back to the drawing board a bit.  It wasn’t so much specifically a concern over interface versus hot bar soldering as much as it was a realization that I wasn’t thinking about all the various gating concerns.  I probably still am not, but it’s at least led me to settle in on some decisions.

First off, I flat out need to settle on a processor.  At this point, I think I’m going to go with an LPC2148.  I’ve come to this decision looking at a number of factors.  First off, it’s an ARM processor so I can leverage an existing stack of tools and have some expectation of how they’re going to work.  One of my frustrations with the SX and with the SX-Key tools was their poor reliability, and in the early phases of design here, I will very much be flying with one propellor (that one being a mix of wits and low-level tools) and I’d like to know that that one will serve me.

The next reason to choose an LPC2148 is that it’s used heavily in a number of SparkFun kits.  This means there’s a community of experimenters and hobbyists built around it.  It means that I can find sample schematics.  It means that I can ask questions and get input.  It means that I can look at sample code for boot loaders.  I may not want to follow in someone else’s footsteps, but it helps to have some signposts on the road.  I can get that with this particular model.  Yes, I could have gotten this with a number of different products.  I could have chosen an Atmel.  Well, I have an Atmel.  It’s on my Arduino.  I can hack at that if I want.  In fact, an Atmel might have been easier since I could get a DIP package for it.  But, I’d have had fewer pins and thus less flexibility.  So, I am choosing something that will challenge me where putting together hardware is concerned but which also has a community and which is a bit more, in my estimation, robust.

I could have chosen something with an embedded LCD controller if I wanted to head that way.  An LPC2478 would have been a good choice.  It has a similar architecture so I’d have gotten many of the similar benefits of familiar tools and similar code and maybe even a common community.  I’ve passed on this idea because I suspect it will be more complex to find parts necessary for prototyping.  At this point, I lack the requisite experience to prototype things without getting a solderless breadboard or at least a wire wrap board involved, and that means I need to be able to break out the leads of the processor readily.  The LPC2148 has an LQFP64 package, and I’ve not had much trouble finding breakout boards for it (such as this one).  The pickings for an LQFP208 package, however, have been much more slim.

What does all this mean for my overall project?  Specifically, what does it mean for driving a display?  Well, right now, I haven’t finished sourcing an appropriate display.  I do have some interesting leads, though.  One of them is this TFT QVGA LCD from Embedded Artists.  I like it because it largely because it’s already on a breakout board I can use for prototyping.  It otherwise comes with the usual features from a number of displays with an embedded controller– parallel and serial interface and a few other small bells and whistles.  Another interesting choice I’ve found is a funny little display controller called a PICASO.  This controller will handle the minutae of display, has an 8-frame buffer in QVGA mode, can take commands (including drawing commands) over standard serial connections, and even can interface a memory card via SPI.  It does a lot on only a few lines, and I like that, especially since the alternative is tying up several lines from the LPC2148 to handle display control.  On the other hand, it seems more geared to VGA display and I am not, at the present time, quite sure how it handles a small LCD TFT display.  The maker of the PICASO has an evaluation board with an LCD on it, but they have not responded to my questions regarding how they’ve hooked it up.

I’ve come to realize, though, that I have a ways to go before I MUST be concerned with this.  First, it’d be good to just get a prototype that can be programmed has a reset button, and can give me some debugging output via serial.  That alone is a huge leap in the right direction.

So, I guess that’s it for now.  Looks like I have some parts and new tools to buy.

My wife, the ever-wonderful Amy Hale, gave me a wonderful Christmas gift.  I now have an Arduino Duemilanove, an XPort shield kit, and a LED art kit.  Of course, the first thing I’ve considered is doing some web data-driven light art, so I just need to figure out what data I want to capture and visualize.  That’s the beauty of Arduino systems…everything is simple, componentized, and ready to use.  The high level language used to program the platform, Processing, really leaves you asking questions about the application of the platform instead of the implementation.  I don’t believe it’s the best way in the world to learn about the design of an embedded system, but for getting something done, it’s a system which is hard to beat.

A note to prospective gift buyers, though.  The XPort shield kit is just the platform for an Ethernet module but it is not an Ethernet module on its own.  The supplier may be offering the module as part of an extended kit, but the build instructions at Make suggest buying an XPort which will cost an additional $30 or so (after shipping, etc).  So, just remember this if you want to make the gift all-inclusive.

The other great thing is that now I have an Arduino, which I was actually planning on using to make a touch-screen prototype at work.  Again, the focus on componentization and a high-level programming environment makes this a good platform for quick prototyping.  When you can buy a TouchShield, drop it on the shield connector, and grab an extra Processing library and start looking at your prototype application…well, that’s a rapid prototyping dream.

I’ve been doing more part sourcing research on my completely made-from-scratch platform.  I’ll post about that separately.