Hi Colin,
Yes, of course ultimately I'd love to get AVRDUDE out-of-the-box
compatible with my programmer. However, I realize Joerg et. al. may feel
differently, since my firmware is only a clone of the real thing, and
limited by the hardware platform that I have designed it for. I don't
really expect Joerg or the other developers to put in extra effort to
make my clone firmware work correctly.
That said, I think we have the potential for some quick fixes here that
shouldn't impact users of the real-deal.
The first is the fixing of the endpoint selection, which currently
blocks all users of AVRDUDE from using my clone programmer completely,
as the workaround I have for the second incompatibility involves using
different endpoint addresses to the real units, which AVRDUDE-HEAD
ignores. If we can fix the endpoint detection code, users will be able
to use the "libUSB compatibility mode" firmware I built to work around
the second issue.
The second issue is the serial drain code in AVRDude tripping up my
limited bidirectional endpoint code. Turning this code off eliminates
the need for my compatibility mode firmware, and makes my clone
completely out-of-the-box AVRDUDE compatible. However, that may have
ramifications I am not aware of, so Joerg would need to weigh in.
Cheers!
- Dean
On 15/09/2014 9:06 AM, Colin O'Flynn wrote:
Hi Dean/Joerg,
Keeping my reply on the list & not bugtracker as not directly related to
that bug:
Do you think it's worth fixing the issue forcing the separate endpoints?
AFAIK the issue is triggered by a call to usbdev_drain() which might be
possible to work around (read: just disable for avr-isp2).
I only ask as if this is fixed it might add another complication to the
system, and I don't know if it would become worth making two separate
AVR-ISPmk2 programmers at that point. One has the 'libusb' fixes and assumes
the two separate endpoints, (i.e. called avrisp2lufa or whatever), one
always assumes endpoints are as in Atmel AVRISP-MK2.
I assume it would be possible to differentiate between the 3 programmers and
enable the correct code (i.e.: Atmel AVR-ISPMK2, LUFA AVR-ISPMK2 in
AVRStudio Mode, LUFA AVR-ISPMK2 in LIBUSB Mode). But it might become a
ungainly/difficult to maintain into the future, and ultimately be easier at
some point in time say screw it to the users, and make them specify exactly
what they want.
Regards,
-Colin O'Flynn
-----Original Message-----
From: avrdude-dev-bounces+coflynn=newae....@nongnu.org
[mailto:avrdude-dev-bounces+coflynn=newae....@nongnu.org] On Behalf Of Dean
Camera
Sent: September-13-14 4:54 AM
To: Dean Camera; Larry Viesse; Joerg Wunsch; Ron Snijders;
avrdude-dev@nongnu.org
Subject: [avrdude-dev] [bug #40831] LUFA AVRISP-MKII fails with avrdude
6.0.1
Follow-up Comment #4, bug #40831 (project avrdude):
Since there is already a read endpoint fallback in usb_libusb.c:
if (fd->usb.rep == 0)
{
avrdude_message(MSG_INFO, "%s: usbdev_open():
cannot find a read endpoint, using 0x%02xn",
progname,
USBDEV_BULK_EP_READ_MKII);
fd->usb.rep = USBDEV_BULK_EP_READ_MKII;
}
Should we either set the usb.rep value to 0 in the upper tool layer, or
explicitly zero it out in the usb layer?
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?40831>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
_______________________________________________
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
_______________________________________________
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
