[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: |
Sun, 30 Nov 2003 22:09:30 +0100 |
User-agent: |
KMail/1.5.1 |
On Sunday 30 November 2003 21:13, Brian Dean wrote:
> On Sun, Nov 30, 2003 at 08:35:52PM +0100, Jan-Hinnerk Reichert
wrote:
> > I mean enqueue the erase operation in "updates" and have it done
> > in do_op(). And perhaps make it selectable by "-U", later.
>
> Ah, ok. I'm not sure this is really necessary, though. It would
> make parsing the -U option more difficult and the parameters don't
> really fit the -U option. For example, an erase unconditionally
> erases the FLASH and sometimes the EEPROM on some parts depending
> on current fuse bit settings. Thus, supply the <memory> field of
> the -U parameter does not apply and would be confusing. Also, the
> <filename>:<type> fields do not apply either.
Okay, then skip the "-U" part.
> > This way you can do things like Read EEPROM, Erase, Write Flash,
> > Rewrite EEPROM in one call.
>
> You can do this now. Remember, unless specified otherwise, an
> erase is performed before writing FLASH memory:
>
> avrdude -p <part> -U eeprom:r:ee_save.hex:i -U flash:w:test.hex -U
> eeprom:w:ee.hex
Unfortunately, this does the erase _before_ the read of the EEPROM. If
you do the erase in do_op(), you could insert an erase just before
the first write.
However, it is not 100% clear, where the erase should be placed.
So, let's try a theoretical approach:
What we want, is that multiple -U options give the same result as
multiple invocations with the -U options passed one at a time.
For this, we need to do a chip erase just before every flash write (I
don't really think that someone will try multiple flash writes in one
invocation, but he is certainly allowed to ;-)
However, a user might think that it is perfectly okay to do:
avrdude [...] -U eeprom:w:ee.hex -U flash:w:test.hex
If we change the autoerase behaviour to do an erase before the eeprom
write, the user gets what he wants, but it is different from:
avrdude [...] -U eeprom:w:ee.hex
avrdude [...] -U flash:w:test.hex
So either we leave behind the theoretical approach or we forbid
combinations that could lead to unexpected behaviour (from the user's
perspective)
BTW: I don't think that any of this is urgent, since I haven't seen
any complaints about strange behaviour, yet.
/Jan-Hinnerk
Re: [avrdude-dev] chip_erase and cycle_count cleanup, Jan-Hinnerk Reichert, 2003/11/30