Joerg Wunsch wrote:
That's pretty normal though; only the control endpoint is usable in both directions, data EPs need one EP per direction.
Indeedy, each non-control endpoint accepts only IN or OUT data. However, it's perfectly legal to have two logical endpoints share the same index but with opposite directions, giving the 0x02 (OUT) and 0x82 (IN) endpoint addresses used on the legacy Atmel tools. The issue here is that on the AVR8 devices the endpoint address is dictated by its logical index in the device, so endpoint index 2 in the USB AVR8 can only be given the USB endpoint address of 0x82, or 0x02 - you can't assign different logical endpoints to arbitrary endpoint addresses.
To get around that for the AVRISP-MKII Clone firmware (since the Jungo drivers and Atmel tools assume the 0x02 and 0x82 endpoint addresses) I just swap the direction of endpoint 2 in the USB AVR to the direction needed at that point in time based on the higher level protocol. It's a nasty, nasty hack, but as long as both sides stick to the published protocol it works a treat. Where it falls down is when AVRDUDE tries to read data from endpoint 0x82 in the serial drain function when I've already flipped around the direction of the bank inside the AVR, causing a USB transaction failure (invalid endpoint, since according to the USB AVR controller, 0x82 doesn't exist any more at that point in time).
Even though they are using a different chip on the USB interface, they have one EP per direction.
More advanced USB chipsets (XMEGA, newer UC3s, etc.) can freely allocate any logical endpoint address to any physical bank in the device, so you could allocate the first three endpoints to addresses 0x00, 0x02, and 0x82. If i ever port my code to the XMEGAs it will work just fine without hacks, but carries the 3.3V restriction which makes it more difficult to quickly use on parts if you're just throwing together a programmer from your parts bin.
If you tell me what to reproduce, I can run this through a hardware USB analyzer. What hardware do I need? I've got an RZRAVEN USB stick (employing an AT90USB1297) around, can I make that work?
Sure, that'll work fine. Presumably you have an AVR-GCC setup available (!) so just "git clone [email protected]:abcminiuser/lufa.git" or grab a tarball from https://github.com/abcminiuser/lufa/archive/master.tar.gz and extract it out. In the "Projects/AVRISP-MKII" folder edit the makefile "BOARD" value to "NONE" (this disables the LED twiddling code) and "make all" to generate the HEX file. I'm not sure if the RZUSBSTICK uses an 8MHz or 16MHz crystal, so set "F_CPU " in the makefile accordingly. By default, the firmware builds in the LibUSB compatibility mode, which uses the different 0x02 and 0x83 endpoints which breaks completely on the latest AVRDude as the heuristics doesn't find the new endpoint layout. To change this, comment out the LIBUSB_DRIVER_COMPAT in the "Config/AppConfig.h" header and recompile. If you can't do the above, let me know what configuration (F_CPU, USB endpoint compatibility mode) you need and I'll generate a binary for you. Note that this will cause naughty SPI/USART output from the AT90USB1287 when trying to contact a programming target, which might break other hardware on your board if you don't disable it. Cheers! - Dean _______________________________________________ avrdude-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/avrdude-dev
