Microcontroller enumerates as USB printer — can be programmed by printing

This is a fascinating concept. We’re not sure of its usefulness, but it definitely stands on its own just for the concept. [Dean Camera] just added a new HID class to the LUFA project that lets you flash AVR chips by printing to them. This means once you have a file like the one seen open in Notepad above, you can just click on File, then on Print, and the firmware will be uploaded to the chip.

[Dean] is the creator of the LUFA project and still likes to get his hands dirty hacking around with it. This idea came to him while he was exploring the concept of using the MIDI protocol to program a chip. That didn’t pan out because of the way Microsoft has handled MIDI in newer versions of Windows. But he did get the idea of making LUFA identify itself as a simple USB printer. He dug into the specification and figured out how to do that. Once Windows connects to the device it doesn’t really care what data gets sent to it. So [Dean] wrote a parser for the bootloader which could accept the incoming hex code and write it to the chip’s program memory.

If you mean HID usage table #7, then no, that’s keyboard/keypad usages. If you mean USB device class 7, then yes, that’s the printer class. Not the HID class. It’s a USB device class, but it is not equal to or part of the HID class. All HID-compliant interfaces have interface device class set to 3, while all printers have interface device class set to 7. They are different things; printer class is USB, but that does not make it HID.

Wow, I feel silly. I actually design+program microcontroller systems for actual printers, and so use this exact method all the time… on printers. It never once dawned on me to use this method on non-printer devices!
Although alternatives exist for USB-enabled MCUs (E.G. DFU specification or mass storage class), printer ports can also be set up for serial or parallel ports. Very nice.

Just in the spirit of pedantry, HP’s implementation was markedly more complex, at least on their nicer printers. Since the printer has a full PCL/PJL implementation(sometimes Postscript as well) you can send it full programs, with reasonably alarming capabilities, just by ‘printing’ them(such programs can result in printed output; but tend to suppress that, since nobody wants to waste paper spewing an entire firmware update). Effectively, the printer’s OS would execute, with full permissions(since there wasn’t a permissions model) any commands sent to it, with ‘security’ being provided by the assumption that well-behaved users would only send commands that printed documents, rather than performed filesystem operations or other shenanigans.

Since HP’s printer security model is somewhere between ‘pitiful’ and ‘nonexistent’, the full power of the PCL/PJL environment was available to anybody with the ability to send a job to the printer. Pretty much analogous to take a knife to a gunfight, or a traditionally-single-user OS without filesystem permissions to the public internet.

The system in this hack is much simpler, no interpreter involved, just a way to dump a data blob directly to storage(and, thankfully, since there is no ‘hook it up to the office LAN and let everybody have access’ use case for a microcontroller being flashed’ the total lack of access control isn’t an issue, unlike the HP case).