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

[Klaus Rudolph]

Brian Dean wrote:
> 
> 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?

No, I don´t think so. In the avrstudio you must check a box for this
option.


>  I could be missing it, but I don't see an explicit
> command or parameter that says to use parallel mode over serial. 

So you need a method to probe for the correct mode. Any idea?


> 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.
>
You are right if this is for the final version. But to do a test it
is easy because you can´t distroy anything during the work.
As I todl you, I would later move the differnce back in the original
files.

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

Where I can find the fuse programming start point for this? I don´t know
it
but I looked not for it :-)



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

Yes, if there is no init and destroy things for changing handlers and so
on. In c++ that is easy but 
if we have here some handcrafted destructors... I don´t know.


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

OK. But I think the hurdle is much higher for all that. 
I have no idea how to put all that new ideas in the code and I don´t
know how long 
that should need. can you help me?

> 
> What am I missing?

I think the problem is that there is no auto detection for serial or
parallel 
mode with stk 500. 



Regards
        Klaus