Hi All, > I don't really expect Joerg or the other developers to put in extra effort to make my clone firmware work correctly.
I've got a vested interest in making it work, as am using that code myself. And it seems your LUFA clone pops up all over the place, at least going by how many google hits I got for it & the problem when first looking into it. >> The second issue is the serial drain code in AVRDude tripping up my >> limited bidirectional endpoint code. >I'm not sure how useful all the draining stuff is at all if the backend is sitting on USB. Basically, it's there since the days when >programmer have been connected to real serial devices. Indeed, the original addition of the usb_drain() code has a comment about fixing an odd state in the JTAG-ICE, where I assume things get unsynchronized and it's sending more data than expected. 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. I globally disabled the drain stuff on my own build of AVRDude and haven't had problems, although I only have a few tools to test against. My thought was one of two options for doing this: 1) Turn it off on a per-programmer basis (i.e. for AVR-ISP MK2 only). Originally thought via the config file, although I now notice it might be possible to disable inside of usb_libusb.c for the AVR-ISPMK2 only, which would be the most clean option. 2) Turn if off globally, but with a command-line switch to re-enable it in case it broke something Let me know your thoughts - I'm happy to try contributing a patch for either option. I started up bug report #43268 to track the issue without stealing your bug report Dean ;-) Regards, -Colin O'Flynn -----Original Message----- From: Joerg Wunsch [mailto:j...@uriah.heep.sax.de] Sent: September-21-14 6:34 AM To: avrdude-dev@nongnu.org Cc: Colin O'Flynn; Dean Camera Subject: Re: [avrdude-dev] [bug #40831] LUFA AVRISP-MKII fails with avrdude 6.0.1 As Dean Camera wrote: > I don't > really expect Joerg or the other developers to put in extra effort to > make my clone firmware work correctly. Clone or not, that doesn't matter here. AVRDUDEs goal is to be able to talk to any known general-use AVR programmer around. > The first is the fixing of the endpoint selection, ... I don't mind improving that heuristics. The way it is now, I simply didn't spend any effort into an automatic selection, since basically, the EP numbers are written down in the Atmel protocol documents, so it wasn't envisioned they would ever change. If someone wants to put in a real heuristic here, please go ahead, and do it. The only requirement is that it doesn't break support for any of the official tools, or anything else using the libusb code by now. For the JTAGICE3, keep in mind there are two fundamentally different firmware levels that need to be supported. FW version up to 2.x use two bulk EPs for communication, plus one interrupt EP for event reporting, while 3.x firmware uses two interrupt EPs (HID class) for everything. So creating a heuristic that works with every device without being required to add special hacks based on individual product strings or PIDs is a bit of a challenge, but not impossible. > The second issue is the serial drain code in AVRDude tripping up my > limited bidirectional endpoint code. I'm not sure how useful all the draining stuff is at all if the backend is sitting on USB. Basically, it's there since the days when programmer have been connected to real serial devices. The current implementation of usbdev_drain() is meant to be as little intrusive as possible though: read from the EP until it tells there are no more data around. -- 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
