Re: [avrdude-dev] [RFC] avrpart.c

[Brian Dean]

On Sun, Nov 23, 2003 at 09:13:50PM +0100, Jan-Hinnerk Reichert wrote:

> > > 2) Why are get_cycle_count() and put_cycle_count() used in
> > > "main.c" as well as in "par.c" and "stk500.c", but not in
> > > "avr910.c"? Testing showed that cycle-count is not working on
> > > avr910.c (except using -Y to set).
> > > Why is cycle-count not entirely implemented in "main.c"?
> >
> > The cycle count needs to be handled at the time of the chip erase,
> > and the chip erase is a per-progrmmer function, therefore, all
> > programmers need to implement it.  That said, it can probably be
> > simplified in each programmer's implementation by moving some of
> > the common code into common functions or maybe macros.  Everytime
> > the part is erased, a check needs to be made so know whether or not
> > to save the cycle-count from EEPROM before erasing the chip, and
> > then whether or not to increment the cycle-count, and store it
> > back.
> 
> Why not saving and restoring the count at the place where chip_erase 
> is called?

The routine 'put_cycle_count()' in main() is there to support the -Y
option only.  While the 'get_cycle_count()' is there to simply display
the current cycle count, independent of whether an erase was requested
or not.  So 'main()' does not actually duplicate the cycle count code
in the programmer's erase function.

One way to simplify a bit would be to create a higher level function
to do the erase, passing in the programmer as well as the 'do_cycles'
option flag.  That routine would save the cycle count, call the
programmer's erase function, then restore the cycle count.  Thus, the
saving and restoring could be removed from each programmer's
implementation and avoid code duplication there.  Also, the high level
erase function would be the one called from 'main.c' and 'term.c'
instead of the programmer's erase function.

Doing it that way instead of handing the cycle count at the places
where an erase happens would keep 'main.c' and 'term.c' from both
having to deal with the cycle count, and thus perhaps getting out of
sync in the way that is implemented.  Probably 'avr.c' or 'avrpart.c'
would be a good place for this new high level erase function that
knows how to save and restore the cycle count.

-Brian