spcomputing

No, it is just saying that there is no "basic communication" with the chip. Before any flashing, the USBtiny or any ISP through AVRDUDE does a chip check. The 0x000000 means no reply. Does the Uno board power up when you connect the USBtiny? Try this to test the USBtiny. Switch the ISP header to the '328 and send:

spcomputing

The other type for -p at90usb82 would be for DFU programming mode via USB cable?

No, the USB access to the Atmega8/16u2 through FLIP does not use AVRDUDE, so the part (-p at90usb82) used is actually ATMEGA8U2 or ATMEGA16U2 in the FLIP software. If you are to program the DFU through the header with a USBtiny, then AVRDUDE is used with the Arduino IDE. I am using the README.TXT included with the Arduino IDE for the Atmega8u2:

\arduino-1.0.1\hardware\arduino\firmwares\readme.txt

Quote

rduino Uno and Mega 2560 Firmwares for the ATmega8U2

This directory contains the firmwares used on the ATmega8U2 on the ArduinoUno and Arduino Mega 2560. The arduino-usbdfu directory contains the DFUbootloader on the 8U2; the arduino-usbserial directory contains the actualusb to serial firmware. Both should be compiled against LUFA 100807. Thetwo .hex files in this directory combine the dfu and serial firmwares intoa single file to burn onto the 8U2.

Note on USB Vendor IDs (VID) and Product IDs (PID): The arduino-usbdfuproject uses Atmel's VID and MCU-specific PIDs to maintain compatibilitywith their FLIP software. The source code to the arduino-usbserialproject includes Atmel's VID and a PID donated by them to LUFA. ThisPID is used in LUFA's USBtoSerial project, which forms the basis forarduino-usbserial. According to the LUFA documentation, this VID/PIDcombination is:

"For use in testing of LUFA powered devices during development only, by non-commercial entities. All devices must accept collisions on this VID/PID range (from other in-development LUFA devices) to be resolved by using a unique release number in the Device Descriptor. No devices using this VID/PID combination may be released to the general public."

The production version of the arduino-usbserial firmware uses theArduino VID. This is only for use with official Arduino hardware andshould not be used on other products.

While I have not tested the "actual" part of -p m16u2 or -p m8u2 the -p at90usb82 works well as documented. I also tested -p at90usb162 with the same success. I am not sure if -p ATmega8U2 or -p ATmega16U2 will respond with much success since they are only descriptors:

Sorry, I don't mean to get too off the subject. Just trying to make some sense of things.

Quote

While I have not tested the "actual" part of -p m16u2 or -p m8u2 the -p at90usb82 works well as documented. I also tested -p at90usb162 with the same success. I am not sure if -p ATmega8U2 or -p ATmega16U2 will respond with much success since they are only descriptors:

I think the arduino-1.0.1\hardware\arduino\firmwares\arduino-usbserial\makefile explains it.

Quote

# MCU name(s)# Since the ATMEGA8U2 part is not directly supported by the current# versions of either avrdude or dfu-programmer, we specify a dummy# part; AT90USB82 which is close enough in memory size and organizationMCU = atmega8u2MCU_AVRDUDE = at90usb82MCU_DFU = at90usb82

spcomputing

# MCU name(s)# Since the ATMEGA8U2 part is not directly supported by the current# versions of either avrdude or dfu-programmer, we specify a dummy# part; AT90USB82 which is close enough in memory size and organization

Nice find hiduino! I haven't explored all the Arduino IDE files as of yet