As Dean Camera wrote: > > Assuming things are working well one shouldn't need the drain > > stuff as you mention. I was never sure why the drain trips up > > Dean's MK2 code, but it does seem to be the problem.
> By the time the drain code is called, my code has already switched the > direction on the USB AVR's data endpoint -- since the USB AVRs don't > supported bidirectional endpoints (having an IN and an OUT on the same > index) I have to work around it via manual switching. That's pretty normal though; only the control endpoint is usable in both directions, data EPs need one EP per direction. > However, having > the host read from the IN address when the USB AVR has swapped the > direction to OUT apparently causes libUSB or another layer to choke and > abort the session. Rather than adding any kind of hack, we should analyze the actual problem on this. After all, the other USB-based tools have the same problem. Even though they are using a different chip on the USB interface, they have one EP per direction. 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? (It probably has too few pins wired to outside to act as a real programmer, but if it can be reproduced already without a target connected, it might do the job.) > Disabling the drain code for USB makes sense to me at least - I'd > recommend having it disabled for all USB tools by default, with the > command line option to turn it back on as you suggest. Having it on but > only for some USB tools would only lead to confusion. I would avoid that kind of hackery if possible. -- 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
