Okay, this is probably above my skill level, really, but it looked fun. I have a Sparkfun USBTiny. It works. I made an attachment for it which has a pair of ZIF sockets and is wired up to support atmega328s in one of them, and the other has one set of pins for an attiny85, and one for an attiny84, so I can program any of those using the USBtiny. This also works.
I got the idea that if I had a USB header lying around (I do) and an attiny84 lying around (yup!), I could make a single board which contained both the programmer and the ZIF sockets, and where I wasn't holding the programmer-itself to plug it into a USB port. Sparkfun makes schematics available: https://www.sparkfun.com/product... (see the Documents tab; they include Eagle files.)
My schematic may be misleading because I was trying to use the board layout stuff to sketch out where I wanted things, so for instance, I don't think the schematic shows the right parts for the zener diodes, but I am in fact using 3.3V zener diodes.
So, where I'm at: The device doesn't get detected successfully by my computer as a USB device. It sort of starts to, but does not succeed:
[1739368.405665] usb 1-1: new low-speed USB device number 78 using xhci_hcd [1739368.557890] usb 1-1: New USB device found, idVendor=1781, idProduct=0c9f [1739368.557895] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [1739368.557898] usb 1-1: Product: FabISP [1739397.268827] usb 1-1: USB disconnect, device number 78 [1739430.373732] usb 1-1: new low-speed USB device number 79 using xhci_hcd [1739430.501883] usb 1-1: device descriptor read/64, error -71 [1739430.737630] usb 1-1: device descriptor read/64, error -71
Error -71 is sometimes a result of, for instance, using a charging cable rather than a data cable, but I've checked with a couple of cables and that's not the problem.
The vendor/product IDs are the values I expect for the device, so we're getting as far in the negotiation process as that. Replacing the firmware with a quickie arduino sketch that flashes some of the LEDs confirms that it does seem to be using the crystal, and running at the expected speed.
Unfortunately, that's about the limit of my experience/expertise. I don't have (I think) any suitable hardware for any kind of on-chip debugging. I have source for the USBTiny firmware, but don't know enough about it to diagnose it much. I was a bit surprised by the way this design handles the USB D+/D- lines; they're nominally 3.3V, so it's just using the chip's normal 5V lines and 3.3V zener diodes to pretend to be 3.3V. I would think this was sort of crazy-sounding, but empirically it works for the other model.
I don't think that the LEDs I added to the design are relevant, because my existing USBtiny addon board does the same thing, providing LED indicators of the five non-ground pins on the ISP header.
If I use the existing USBtiny, and connect its ISP header pins to the new board, avrdude can use it to talk to a chip in one of the ZIF sockets, so I'm pretty sure that the problem has to be something to do with the firmware or the USB wiring hookup. (More importantly, the ZIF sockets don't become relevant until the device is "up" enough to talk over USB.) The prebuilt firmware appears to be for an attiny84 at 16MHz. This slightly surprised me, as prior USBTiny designs were 12MHz, and there's one comment left in the code about 6 cycles being 0.5 microseconds, but empirically, the premade USBTiny has a metal bit labeled "16.000" that appears to be next to two capacitors, and it works. I haven't tried to rebuild the firmware, but I probably should, it just seems unlikely to result in differences.
Mostly looking for tips, suggestions, etc. I have done reasonably obvious things (check that all the points that are supposed to be wired together have continuity, and that none of them have continuity to any of the other networks). (Good thing, too, as one of the ground wires was intermittent-at-best and would definitely have caused problems.)