1. A blinky LED: Above all else, (besides the power LED) there needs to be a LED which blinks under software control (perhaps a process, or event loop which toggles the state of the LED); that way you know at a glance if the LED is still blinking that the board is still sane, and that at least something in software-land is still running. If the LED stops changing state, then something bad has happened.
2. A serial console: This is arguable just as important, as a blinky LED, but I’ve made it #2 on the list just because I think more people need to know that blinky LEDs are important. However, a serial console allows you to provide a command line interface to the target, and in the case of an embedded Linux project, to be able to get a root prompt. This vastly simplifies debugging the product.
3. JTAG header: I have brought up boards before with only a blinky LED and serial port, however having JTAG sure makes it a lot easier. It is very annoying to get a board to work with, which hasn’t brought out the JTAG lines to a header, and you have a difficult problem to debug. Not to mention that debugging the hardware or writing a bootloader is infinitely easier if you have JTAG. Many COTS development boards come with working hardware and an existing bootloader though, which is why JTAG is at position #3 in this list.
4. Ethernet port: This may seem like an odd request, as many products don’t include an Ethernet port, despite the chips being used supporting Ethernet. Many of the boards I’ve worked with will have a break-out board which provides such things as a DB9 for the serial console and a JTAG header. How hard would it be to include an Ethernet port on the same break-out board? Ethernet provides a fast way of transferring files back and forth (from target to host), allows for nfs mounted root filesystems (for embedded Linux), and is increasingly being used for remote debugging (via gdb and eclipse). Ethernet also opens new possibilities for manufacturing and rework, as you can transfer data to and from the target at much higher speeds than over a serial port.

I find many embedded developers have similar lists of “must haves” for embedded projects. However in my experience, the hardware we are given to work with don’t always follow these rules. The thing is that we’d all get the job done a lot faster, if we just had the right interfaces to work with.

However, most of the projectors I’ve used since then, if they had any data port at all, had a USB port instead. However, each projector used that USB port differently, supporting no more than 2 of the following features in any one case:

• serial-over-USB used with a custom program to make the remote control work the computer
• HID-over-USB which makes the remote control appear as a mouse and keyboard
• USB mass storage which makes the projector look like a thumb drive which contains other drivers or programs for the projector
• Video-over-USB which allows the projector to show video via USB instead of VGA

These are all great individually, but why not support all of them. With the processors and chipsets available today, and that much of the firmware is probably shared between the projectors made by the same manufacturer (lowering implementation costs), why can’t all of these features be available via one USB 2.0 cable?

• serial-over-USB for controling the features of the projector and switching it on and off
• HID-over-USB to make the projector remote control appear as a mouse and keyboard
• Optional Video-over-USB (which sadly doesn’t seem to be entirely standardized yet)
• Audio-over-USB so any speaker built into the projector doesn’t need extra audio cables
• USB mass storage which makes the projector look like a thumb drive containing manuals, drives, and such
• Even Ethernet-over-USB might be useful for providing a sink for streamed video from other computers on the network

All that in one package would be a very good use of the USB port on the back of a projector. And since most of these uses of USB are standardized, would work on just about any operating system out there.

At the end of 2008 our HP OfficeJet 7310 multi-function printer/scanner/fax started having problems. The scanner started to make the left side of all scanned images green. This of course meant that the scanner, copier, and fax were basically useless, which left the printer. Getting it fixed cost more than a new printer (it was beyond waranty), so when it started to choke on print jobs, it was time to get a new one.

Despite this experience, I’ve always liked HP printers; certainly the 7310 was great until it started to break. Linux support for most HP printers is excellent. Mac OSX support is excellent too. I even hear they work well with Windows. So when I started looking for a replacement, I went back to HP to see what was available.

I needed a replacement multi-function device which had the following capabilities:

• Ethernet or wireless connected (who wants to plug a shared USB printer into your otherwise wireless laptop?)
• Supports duplex printing (save a few trees)
• Has a page feeder on the scanner which supports duplexing
• Can work as a copier
• Can work as a fax machine

After looking at the available options, the HP OfficeJet J6480 seemed to be the right replacement; it had the right specifications, and price. I ordered it from the HP website just before Christmas, and hoped it would arrive soon. As promised it arrived a few days later.

I briefly connected it to Ethernet to setup wireless. I know I’m supposed to be able to do it without connecting a Ethernet cable, but I don’t like using wireless to configure devices (I find wired generally more reliable than wireless). Bringing up the web interface for the J6480 made configuring the device quick and painless. The administration interface was well laid out and obvious. It also made setting up wireless very easy; cutting and pasting is much easier and reliable than having to type in a password (or WEP key) with the buttons on the front panel of the printer. Once wireless was configured, merely unplugging the Ethernet cable and turning on the wireless radio (a well marked button near the card reader) was enough to get it connected to the wireless access point. Success.

Then it was time to configure my Debian Laptop to be able to use the printer and scanner from the J6480. After making sure I had the lastest versions of hplip and hpijs installed, it was just a matter of running hp-setup which walks you through installation. hp-setup sometimes picks up the wireless router IP address instead of the printer itself, so it helps to specify the IP yourself if it is known (I tend to use static IP addresses for everything). All this would look something like this on Debian or Ubuntu Linux.

$ sudo apt-get update
$ sudo apt-get install hplip hpijs
$ sudo hp-setup 192.168.1.37

It worked first time, and even set up fax support (although I haven’t tested whether fax works yet). Both printing and scanning (via SANE or the web) worked flawlessly, every bit as well as my previous HP multi-function device.

Then it was on to the other OS in our house: OSX. There’s nothing much to tell here; I ran the installer on the included CDROM, and it configured the printer/scanner/fax support for OSX (and installed at least 200MB of other HP software). Again, it worked flawlessly, allowing seamless printing, faxing, and scanning from the Mac desktop. However, there was a pleasant surprise: “Scan to” support had been added to the mac.

The HP 7310 that I had before this had this “scan to” button which allowed you to scan things directly into applications on a properly setup Windows computer (running the appropriate HP software). This was great if you ran Windows, as since this is a network connected device it isn’t necessarily near your computer. This often requires you to walk some distance to the scanner. It was a neat feature, however I never used it as I didn’t run Windows myself. I always thought it would be a nice feature to have however. Well, it now works in Mac OSX, and rather well I might add. You put the document into the scanner, press “scan to”, select the computer you want to send the document to, then the format and application you want the scanned document sent to. So for instance you can scan as a JPEG to iPhoto, as a PDF to Preview, or use OCR to send text to Word. And all this from the front panel of the multi-function-device. Cool.

Hopefully the next version of hplip will support “scan to” for Linux as well.

Since then I had been looking for a good, flexible, automatic backup system. It seemed there were many good backup systems out there, but none of them seemed to do all the things that I wanted them to do:

• Works without user intervention (users forget to backup).
• Doesn’t require installing special client software
• Works on mobile systems which aren’t always available when backups are being made
• Backs up many different operating systems (Linux, Mac, Windows, etc)
• Stores backups in an efficient manner, for many years, on network attached storage (tapes are a pain)
• Is Free/Open-Source Software.

In 2003, backuppc came to my attention. It seemed to fit all my criteria and more. I started to use it, and since then I’ve been pleasantly surprised how backuppc has met my needs over the years. But the most important thing was that every time I added a new device to my network environment, most of the time backuppc has been able to be used to back it up.

Backuppc easily backed up all my existing computers when I first started using it. With laptops, if they were on and available via wifi at night, they backed up with everything else. However, if they were off or away, they backed up as soon as they were available again. Sometimes this meant a backup during the middle of the day when they returned, however at least they were being backed up. Whenever we needed to get back an older version of a file, or restore a mistakenly deleted file from any of our computers, backuppc was up to the task.

After using it for a few years, we bought my wife an ibook. Backuppc was immediately put to work backing up this new OSX based laptop; it was just so easy to do. Then I bought a Nokia N800. It also was trivially backed up with backuppc as if it were a laptop.

The following assumes you already have your backuppc server setup and are successfully backing up other computers already.

After installing openssh on the n800 from here and rsync (which can be found in the maemo extras repository), you need to do some work on the backuppc server.

For this example, we’ll assume the n800′s hostname is “n800tablet” and the username is “joeblogs”. Change these to suite your needs.

First you need to create the setup file called /etc/backuppc/n800tablet.pl

$Conf{XferMethod} = 'rsync';
$Conf{RsyncShareName} = ['/'];
$Conf{BackupFilesExclude} = {
    '/'    => [qw(
        /dev /proc /sys /tmp
        /mnt/initfs/proc /mnt/initfs/sys /mnt/initfs/tmp
        /var/cache /var/lock /var/run /var/tmp
    )],
};

Then you need to setup ssh to be able to connect to the n800, and tell backuppc about the new config file:

# su - backuppc
$ ssh-copy-id -i ~/.ssh/id_dsa.pub root@n800tablet
Password:
$ exit
# echo "n800tablet 0 joeblogs" >> /etc/backuppc/hosts
# /etc/init.d/backuppc restart

I was reminded of all these things a few days ago. I messed up my n800 to the point of being unable to boot. I needed to reflash it, however that meant wiping out my data and settings. The n800 has it’s own backup system (to SD card), but I hadn’t run it for a while (remember when I said above that users forget to backup?). However, I was also using backuppc, so I had recent backups! Once I had the n800 working again, I restored all the other files I didn’t have in my 6 month old n800 backup.

Good job I had backuppc.