avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avrdude-dev] [bug #21079] slow EEPROM write: unchanged bytes should be


From: Tamas Fenyvesi
Subject: [avrdude-dev] [bug #21079] slow EEPROM write: unchanged bytes should be skipped
Date: Fri, 14 Sep 2007 15:16:31 +0000
User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; i-NavFourF; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

URL:
  <http://savannah.nongnu.org/bugs/?21079>

                 Summary: slow EEPROM write: unchanged bytes should be
skipped
                 Project: AVR Downloader/UploaDEr
            Submitted by: fenyvesi
            Submitted on: Friday 09/14/07 at 15:16
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: Tamas Fenyvesi
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Hello,
I've just tried out avrdude5.4 with USBisp (a fast programming tool) and I
found (e.g. on ATmega128) it is some three times slower to write the 4k EEPROM
than the 128k flash.

This is a bad combination of
a.) being EEPROM write not paged in serial prg mode and
b.) that AVRdude doesn't skip the positions that not exists in .eep file.
It sweeps all the area byte by byte even for burning one 0xff (i.e.
nothing).

However, Datasheet writes 0xff bytes can be skipped at erased device.
On the other hand, EEPROM content can be preserved from erasing so it's not
sure that all given byte position has been empty.

1. One possibile speed enhancement is to write only the bytes that are
described in .eep file.

2. Even better to read all the EEPROM (at least the bytes that exist in .eep
file), and to compare each byte with the new values. Only changing
bytepositions shall be written.

3. Similarly, empty (all 0xff) FLASH pages should be skipped.

4. All FLASH areas that are not mentioned in .hex can be skipped. User
program won't intentionally jump over there. OK, this might be optional by a
command line switch (e.g. "fillout").

Best regards,
Tamas





    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?21079>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]