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

[Brian Dean]

On Sun, Nov 23, 2003 at 03:52:52AM +0100, Jan-Hinnerk Reichert wrote:

> However, during the process some interesting questions arose...
> 
> 1) Why is "config.h" included that often?
> "config.h" acts like a kind of include-all, this makes it hard to 
> detect dependencies.

config.h is a bit of a catch-all.  It contains prototypes and variable
declarations used by many of the source files.  Probably if it didn't
seem importantant enough to have it's own header file, it ended up in
'config.h'.  Maybe it's time for some house cleaning?

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

One might be able to simplify the usage by doing something like this:

        old_cycle_count = save_cycle_count();

        /* erase chip */

        restore_cycle_count(old_cycle_count++);

All the common error checking, and checks for whether the cycle count
is actually saved and restored could be done inside the two functions
above which would simply the code a bit for each programmer's erase
function.

It's probably just an oversight that it's not handled by the avr910.

Hmmm, while you're looking at things, I noted a while back that the
PPI "exit specs" (-E option) is no longer handled correctly.  Looks
like the parallel port is unconditionally put back the way it was when
we found it.

Also, some parallel port programmers have a buffer.  If so, -E needs
to also assert the buffer enable signal since, presumably, the /RESET
line could be going through the buffer.

I haven't had a chance to look at that yet, though.

-Brian
-- 
Brian Dean
address@hidden
http://www.bsdhome.com/
http://www.bdmicro.com/