As Dean Camera wrote: > 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.
OK, thanks for the explanation. I finally understand the dilemma. > >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 > g...@github.com:abcminiuser/lufa.git" or grab a tarball from > https://github.com/abcminiuser/lufa/archive/master.tar.gz and > extract it out. As Colin already did all that for me, I could just proceed into testing it. As a result, I removed everything but the "return 0" from usbdev_drain(), so all is fine now. I still don't really understand why it only became apparent under Windows, while it worked fine under Linux (presumably also other Unices) even with the old drain code. But the above might explain the different behaviour I've seen between the LUFA clone and the Atmel ICE (where the drain code didn't leave any traces on the USB analyzer at all). Now, if someone wants to go ahead, and implement a real endpoint selection heuristic, we can hopefully solve the second issue. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) _______________________________________________ avrdude-dev mailing list avrdude-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avrdude-dev
