Re: [avrdude-dev] Yet another config parameter

[Brian Dean]

On Thu, Feb 20, 2003 at 09:43:55PM +0100, Joerg Wunsch wrote:

> 99 % of all current cases probably get away without any retry.  So if
> there's a problem in the retry logic, nobody will notice it.

True.

Hopefully since you are experiencing the problem you and Eric can work
out the fix to the code.  Since I haven't been able to reproduce it, I
haven't been able to code a fix, of course.  Obviously, since it could
be a latent bug that was just exposed by the addition of the Windows
port, that complicates narrowing down the exact problem.

If you want a config file parm to do some alternate behaviour, let me
know and I'll add it (or someone else can - just look at the changes I
recently made to add several new ones for an example).

> Eric
> made -vv echo back the parallel protocol request/responses (currently
> #if 0'ed out normally), and all my other boards (one AT90S1200, one
> AT90S2333, one ATmega128) always succeeded at the first request.

Are you saying that with the debugging code in place that it works,
but without the debugging code it doesn't work?  If so, then I'd say
with much greater certainty that it is a timing issue, or that the
already existing bug could be triggered by timing.  I don't know how
fast one can pulse a parallel port line using in/out instructions, but
the spec on the AVR chips typically say the pulse needs to be at least
2 ns for the clock pulse, and 32 ns between clock going low and MISO
becoming valid (looking at the ATmega163 data sheet).  Is it possible
that those limits are being exceeded by using in/out directly?

> Btw., i remember that i /sometimes/ already had problems with this
> particular make of the m163 board before, under FreeBSD...

I've never had a problem with my m163, keeping in mind your quote
about "absence of evidence" :-), which I agree with, BTW.

> reliably at all with programmer-supplied power...  Remember, that's
> all on the same notebook, with the same programmer hardware.

I think your laptop does not supply enough power.  Didn't you have
trouble with that before?  I think some (many) laptops cannot source
much power through the ppi signals and it is marginal for supplying
some of the larger chips.  I know that I could not power an 8515 I had
with the parallel port on my desktop machine using FreeBSD, but it
worked just fine using external power.  The speed of the external
crystal affects this a lot.  The same system powers the smaller
devices like 2313's without problems.

> I'd give the direct inb/outb a try under FreeBSD, too, mainly to see
> whether the speedup will be rather marginally or drastically.  If the
> latter, i contemplate we could also supply a FreeBSD driver that
> stacks on top of ppbus(4) and supports avrdude in a more timely
> fashion than ppi(4) can do (by moving the inner programming loop into
> the kernel).  That would improve the speed, while still keeping
> hardware access clearly in the kernel where it IMHO belongs to.  Just
> a thought.

I think you are right.  I see about a 3 times speedup when using the
STK-500 over the direct parallel port under FreeBSD.  I know that the
STK-500 is just doing what the parallel port code is doing, only
faster, so there is plenty of room for speed-up in the direct parallel
port case.  However, I don't really have the time to write a
driver/module for FreeBSD to provide faster access than what the ppi
interface can.  The other option would be to twiddle the I/O registers
directly like Eric is doing for the Windows port, but that would
require installing avrdude setuid root in order to gain access to
them.

-Brian