Re-purposing the Orangutan USB Programmer?

I have a project that would only require a couple (as in 2) of general I/O pins, plus the specific hardware already on the Pololu USB programmer (USB Mini-B connector, USB->Serial adapter, and an ATMega48 with a 20MHz clock all in a nice compact little board). It occurs to me that it could be a really useful as just a development board.

I have a friend who just got a summer software development job. I don’t even know what the lab he’s working for does (and probably neither does he at this point) but the program he was hired to work on outputs some sort of data as virtual key-presses (so it can type text into any other program). What they want is to be able to plug their computer into any other computer, have it show up as a generic USB keyboard, and thus be able to type the same text output into programs on other computers, maybe running different operating systems, definitely without installing any drivers. Apparently they thought this could all be handled in software with just a USB Male A to Male A cable between standard USB ports on both computers. I don’t know a whole lot about USB interface programming, but I don’t think it’s such a simple task to get a USB host controller to pretend to be an HID compliant device instead.

I got to thinking about how I would do it, initially thinking about the line of AVRs with USB support, but then I came across this little gem: AVR-USB, USB bit-bang routines for AVRs, including sample projects where the AVR acts as a generic USB Keyboard. It would be simple to redirect the ASCII output of their software to a USB virtual serial port, read it into an AVR UART, then bit-bang it out to another computer pretending to be just a USB keyboard. I was all set to start designing a board, but then it dawned on me that the Pololu USB programmer already had almost all the components I was mentally laying out (short of a second USB connector).

I wonder if you guys would consider releasing a schematic, the PCB layout, or even just a little more pinout information on the ATMega48 connections. Specifically I’m interested in:

  1. What pins on the ATMega48 go to the programming header, the CP2102 chip (I have a guess), the LEDs, and the six “unused pins”? I suspect the “unused pins” are a 6 pin ISP header for the ATMega48, which would make my day.

  2. Would be answered by 1, but is the ATMega48 running on the +5V USB bus voltage, or on the +3.3V line from the CP2102 chip? I’m hoping for the latter, but I could also use zener diodes or voltage-divider resistors to drop the output voltage if necessary.

  3. Is that a 20MHz oscillator, like on the original Baby Orangutans? Anything over 12MHz would also be just great.

  4. Are there any hardware/layout differences between the A and B revisions of the programmer, or just the pre-loaded firmware? Do you have any revision A boards lying around you would like to sell off, knowing that they wouldn’t be used as programmers (and thus couldn’t be used to try to program an un-powered target)?

Of course I would be completely voiding the warranty, it’s one of the things I do best!


Hi, Adam,

There’s no secret in the schematic; I’ll try to get you a copy soon, if you still want it after you see this post. Here are a few quick answers off the top of my head:

  1. The available hardware is used on the AVR, so the UART is used for connecting to the CP2102, and the SPI pins are used for the programming connection. The extra pins are for in-circuit programming of the AVR, so they are mostly the same pins as on the programming connector.

2, 3. The AVR is running at 20 MHz at 5V. 20 MHz lets us do 115.2 kbps serial, but it also requires operation at a higher voltage.

  1. The B revision of the controller has an extra I/O line tied to the target device’s Vcc line so that we can see if there is power there. I don’t think we have any A revisions available assembled. There might be a few bare PCBs lying around, but I assume you don’t want to assemble them since the CP2102s are even more of a pain to solder than the ATmega48s. Also, the B revision uses an ATmega168.

- Jan

Mega168? Sweet! I should have guessed when I saw you could firmware-update the new revision, I forgot the ATMega48 doesn’t have the separate bootloader section. I should totally throw on a copy of Ben’s ASCII-Hex bootloader.

Actually I should totally remember that this is John’s job (my friend) and not mine, but it’s hard not to get excited about little projects like this. Running at 5V is no problem, I’ll just make sure he knows to include components to drop the voltage on the USB data lines. And I’m sure he’ll want an assembled version, university labs have notoriously bad documentation, but the lab that hired him made it clear that any hardware development he does should be minimal, so that it can be duplicated by others when he’s gone after the summer.

If I ever end up hacking one for one of my own little projects I’ll probably go with Revision B too, but just for the extra I/O line brought out to the six pin header, I haven’t given up on surface mount soldering. Actually I’ve had very good luck with hot-air rework and some fine-pitch components recently, and I just got the MPJA combo soldering iron and hot-air station as a graduation present from my parents-in-law (with the hot-tweezer accessory, how did they know?!?). I haven’t needed to solder any components with only underside contacts since my attempt at upgrading my old Orangutan, but that did sort of work before it died, and I’m not afraid to try again!


Oh well, looks like they would rather install software on both computers than develop even a bit of hardware (it’s a software lab after all), so I think they’re just going to use VNC or something.

I would still be interested in seeing a schematic of the programmer at some point, but no rush. Looking at the pictures though I’m a bit confused. It looks like what should be the target VCC pin on the unpopulated programming header is connected to both GND and AVCC on the AVR, or am I all turned around?


I think you have something turned around. The Vcc pin is on the upper right of those six pads (next to the square pad), and the trace you see coming out of there goes to pins 18 and 20, which are Avcc and Aref, on the AVR.

- Jan

Aah, I am turned around, but not so literally.

I was counting pins from the corners, but I was looking at the 28-MLF chip pinout on the datasheet by mistake, not the 32-MLF pinout. Everything else matched up well, but that was quite confusing!