Re: [avrdude-dev] Problems reading writing fuses to at90s1200 with stk500

[Brian Dean]

On Wed, Feb 25, 2004 at 08:36:42PM +0100, Klaus Rudolph wrote:

> Jan-Hinnerk Reichert wrote:
> 
> > Are you sure that newer firmware also uses 0x7x commands in serial
> > mode?
> 
> I?m shure that the new firmware use in serial mode also the universal
> command.
> So nothing must changed here :-)))

What exactly is required to make the STK500 use parallel programming
mode instead of serial programming mode?  Does it use it automatically
if it detects a chip in the socket, and the chip supports parallel
programming mode?  I could be missing it, but I don't see an explicit
command or parameter that says to use parallel mode over serial.  I
only see the case where parameters are passed (command 0x42) that
indicate which programming modes are supported, and command 0x45 that
indicates some additional parallel programming signals, but not
anything that says for it to use programming mode.

> So the parallel mode is "only" a complete add on without any other
> change.
> 
> For my opinion it is quite simple to copy the stk500.c to stk500p.c
> and start there.  The selection must be done at startup from command
> line with an other programmer selection like "avrdude -c stk500p
> ..."  All needed things should be walk like say ever walk. After all
> changes done and tested through all users a time the stk500 could
> diff agains stk500p and the serial part of stk500.c move to
> stk500s.c, the generic part stay at stk500.c and the parallel things
> handled in stk500p.c

It seems overkill to copy the code and have two STK500 support files,
one that uses universal command for fuse bytes, and the other that
uses STK500 specific commands.

Why not instead introduce new programmer entry points for
reading/writing fuse bytes.  These would be initialized to the
existing "universal command" method by default.

It shouldn't be too hard to make the 'open' or 'initialize' routine
query the firmware, and change the default entry points for the fuse
reading/writing functions to be its own (better) replacements than the
defaults, based on the firmware revision.  Each programmer could do
this if desired, not just the STK500.  Or if a programmer does
nothing, they just get the default which would operate as it does
today.  We already do this for some other memory programming, i.e., if
the specific programmer has a more efficient method for programming
the flash, it's own supplied routine is used instead of the more
generic default routine.

What am I missing?

-Brian