Re: [avrdude-dev] Yet another config parameter

[Joerg Wunsch]

As Brian Dean wrote:

> > m128: If entering programming mode failed, then toggle /RESET.
> > m163: If entering programming mode failed, then toggle SCK.
> 
> But the code was doing what the M163 said - pulsing SCK.

Except that Eric changed it in his private Windows version before to
toggle /RESET, since he saw it that way in the m128 docs.  That
failed on just my m163 board.

>  I suspect
> that the doc for the M128 is a typo, not sure about that.

The docs for the mega8 and mega16 also describe you ought to give
/RESET a pulse. :-/

So perhaps it's all the newer chips?

>  I've never
> had a report of some chips being able to enter programming mode while
> others have not.

``Absence of evidence is no evidence of absence.'' :-)

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.  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.

Btw., i remember that i /sometimes/ already had problems with this
particular make of the m163 board before, under FreeBSD...  They
suddenly went into the "Device not responding" mode for whatever
reason, even though the chip itself worked well still.  Don't know
what might be wrong with that little board...  It's very mystic.  It
also works at the first attempt under Windows if i do /not/ power up
the board externally (so the programmer has to supply power).  Under
FreeBSD, it works with its own power supply (OK, could be timing,
/dev/ppi IO is slower).  Under FreeBSD, i cannot get it to work
reliably at all with programmer-supplied power...  Remember, that's
all on the same notebook, with the same programmer hardware.

> I suspect it might be a timing thing - note that the
> inb() / outb() function you are using, if they are directly accessing
> the registers of the parallel port, will operate much faster than the
> FreeBSD and Linux ioctl()'s.

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.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/