avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avrdude-dev] [bug #40831] LUFA AVRISP-MKII fails with avrdude 6.0.1


From: Colin O'Flynn
Subject: Re: [avrdude-dev] [bug #40831] LUFA AVRISP-MKII fails with avrdude 6.0.1
Date: Sun, 21 Sep 2014 08:36:46 -0300

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:address@hidden 
Sent: September-21-14 6:34 AM
To: address@hidden
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. ;-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]