[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avrdude-dev] chip_erase and cycle_count cleanup
From: |
Jan-Hinnerk Reichert |
Subject: |
Re: [avrdude-dev] chip_erase and cycle_count cleanup |
Date: |
Tue, 2 Dec 2003 00:03:02 +0100 |
User-agent: |
KMail/1.5.1 |
On Monday 01 December 2003 23:27, Theodore A. Roth wrote:
> On Mon, 1 Dec 2003, Jan-Hinnerk Reichert wrote:
> > > > - Why is cycle count reset at 0xffff?
> > >
> > > Good question. I think this is a bug. I think it should be
> > > compared against 0xffffffff. A long time ago the cycle count
> > > was 16 bits, but was later changed to 32 bits. This code was
> > > progably missed.
> >
> > There was another goodie in avr_get_cycle(). If the count was
> > 0xffffffff it was set to 0xffff. So, every check against
> > 0xffffffff was not doing anything.
>
> Instead of checking against 0xffffffff, shouldn't it check against
> a macro?
>
> #define CYCLES_ERASED ((uint32_t)-1)
>
> Then the code becomes:
>
> if (!do_cycles && ((rc >= 0) && (cycles != CYCLES_ERASED))) {
>
> This should guarantee that the number of ff's if correct for the
> size of the storage used. Plus you eliminate a magic number, and
> the code becomes a bit more readable.
Nice idea ;-)
However, there is only one occurance of this magic number left in my
version and this is in avr_get_cycle_count():
if (cycle_count == 0xffffffff) {
cycle_count = 0;
}
So, a zero count is read, if the counter has not been initialized.
This removes the need for additional adjustment in avr_chip_erase()
The only other check is in "main.c". Here the cycle count isn't
output, if it isn't been used. Now, this check is for zero (which has
the semantics: "We haven't counted anything, yet").
We could even drop the check in "main.c", but that would result in a
cycle count message at each invocation, probably confusing users who
don't use (or even know about) the cycle_count ;-)
BTW: Would you mind testing the patch on STK500 or PPI?
/Jan-Hinnerk