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

[Jan-Hinnerk Reichert]

On Sunday 23 November 2003 06:19, Brian Dean wrote:
> On Sun, Nov 23, 2003 at 03:52:52AM +0100, Jan-Hinnerk Reichert 
wrote:

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

House cleaning is always fun ;-)

IMHO we should first only move the functions and function prototypes 
in a first patch.

After that there can be several small patches, cleaning up the 
includes one by one.

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

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

I think so, too.

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

I can't see any error in the way ppiclrbits and ppisetbits are 
handled.  I would expect the mistake somewhere in or below 
getexitspecs().

I'm not familiar with option parsing stuff, so I think somebody else 
should take a look at this.

/Jan-Hinnerk