Spiffchorder Progress

As I mentioned when the parts arrived, I recently decided I wanted to build myself a Spiffchorder to play with, and, more generally, play with the VUSB Stack, which provides software USB for most AVR microcontrollers, using a few cents worth of extra passive components. This seems to be an excellent generic solution to the “Modern computers don’t have hobby-accessible I/O” problem for most applications. I’ve actually been using a VUSB device for a while since my usbtiny AVR programmer is an ATTiny2313 running VUSB with some additional support chips and code.

When I ordered parts, Newark was out of suitably-packaged ATMega168 chips, and their larger (RAM/ROM), pin-compatible sibling the ATMega328p was so close in cost I would have ordered them anyway. There is a warning(#8) about -p suffix chips (stands for PicoPower, meaning some additional power staving features) and VUSB, but it seems to be a simple problem with naming conventions in the interrupt vectors, and is fixed in recent versions.
I’ve been grabbing an hour here and there to put it together over the last week. So far, I’ve already spent some time on one of my favorite activities…

which produced a nice tight board (The back isn’t quite as neat, and the socket I ended up using suuccckkkks)

which, as far as I’ve discovered, had only one assembly error (the pull-up network on D- was between ground and… ground because I counted wrong), which was easily remedied.
While I was assembling I also put together a half-assed first approximation keyboard to test with

Which will eventually be upgraded… I’m thinking something flexible that can be clipped to the outside of my left pants pocket, or flopped on a flat surface such that the clip maintains the curvature, but I really just want to play with it and see how (un?)comfortable it is to use a chording keyboard. Maybe I’ll get bored and build a key-glove, those always look fun (and useless).

Now for the real problems… even after I fixed the wiring glitch, and touched up the code (minor fixes to make it recognize the 328p and set the fuses correctly), I wasn’t getting anything when plugged into USB. I borrowed a 168 from another project (and transparently swapped in a 328p there) to test the vanilla code, and it resulted in a board that generates a stream of errors like

usb 2-1.1.3: new low speed USB device using ehci_hcd and address 15
usb 2-1.1.3: device descriptor read/64, error -32

when plugged into any of my various Linux boxes. I then decided to upgrade the VUSB version (the one the 0.98 release is built against is truly ancient), which only took a few minutes of tampering to set up the usbconfig.h (and Makefile) to work with the Spiffchorder sources and IDs. Unfortunately, this only fixed the 328p problem… it now does exactly the same thing as the vanilla 168 version, and produces a string of USB enumeration errors when plugged in.

My understanding is that -32 errors are usually something to do with devices that aren’t correctly handled by ECHI (USB2) mode controllers, but a device that requires you disable ehci mode on a modern computer is pretty much useless, and it doesn’t appear VUSB should have that limitation. This is my current working tree, it seems to be at least as sound as the distributed version; when I get it working I’ll ping the original author about the update, and replace these if it turns out to be a software problem. I’m going to hook it up to some instrumentation on campus tomorrow to see if I can find the problem, I suspect something screwy with the voltages on the USB Data lines.