avrdude benchmark results discussion

[mcuee]

Using this locked discussion to discuss questions found during carrying out benchmark testing.
https://github.com/avrdudes/avrdude/wiki/avrdude-benchmark-for-Flash-and-EEPROM-programming

@stefanrueger

I was looking at the following two sets of test results which does not seem right. Please help to check why -c urclock is much slower in terms of flash programming. Thanks. I tend to think Optiboot is taking some shortcuts here.

	-c pgm	-p part	Fl-ewv	Fl-r	EE-wv	EE-r	Comments
✅	urclock	ATmega328P	9.38 s	4.60 s	--	--	-b 115200 old Optboot o4.4 --s-h-r--, FT232RL, STK500v1
✅	arduino	ATmega328P	2.92 s	5.08 s	--	--	-b 115200 old Optboot o4.4 --s-h-r--, FT232RL, STK500v1
✅	urclock	ATmega328P	4.38 s	1.38 s	--	--	-b 1000000 -xbootsize=512 MiniCore Optiboot o8.0 -?s-?-r--, FT232RL, STK500v1
✅	arduino	ATmega328P	1.98 s	2.07 s	--	--	-b 1000000 MiniCore Optiboot o8.0 -?s-?-r--, FT232RL, STK500v1

Run log for the first set of test results.

$ ./test-avrdude -e ./avrdude.exe -b -d 0 -t . -s -p "-c urclock -P COM11 -b 115200 -p ATmega328P"
Testing ./avrdude.exe version 7.3

The benchmark shows the wall clock time of avrdude carrying out the following tasks
  - Fl-ewv: erase flash, then write a sketch with three sections separated by holes, and verify
  - Fl-r: read the entire flash memory and write to file
  - EE-wv: write data to EEPROM with two data sections separated by a hole, and verify
  - EE-r: read the entire EEPROM memory and write to file

The sketch and data payload is roughly one sixth of the respective memory size

| | `-c pgm` | `-p part` | Fl-ewv | Fl-r | EE-wv | EE-r | Comments |
|:-:|--:|--:|--:|--:|--:|--:|:--|
Prepare "-c urclock -P COM11 -b 115200 -p ATmega328P" and press 'enter' or 'space' to continue. Press any other key to skip
✅   9.383 s: flash -U write/verify holes_rjmp_loops_32768B.hex
✅   4.598 s: flash -U read all flash
|✅|urclock|ATmega328P| 9.38 s| 4.60 s|--|--| -b 115200 |

$ ./test-avrdude -e ./avrdude.exe -b -d 0 -t . -s -p "-c arduino -P COM11 -b 115200 -p ATmega328P"
Testing ./avrdude.exe version 7.3

The benchmark shows the wall clock time of avrdude carrying out the following tasks
  - Fl-ewv: erase flash, then write a sketch with three sections separated by holes, and verify
  - Fl-r: read the entire flash memory and write to file
  - EE-wv: write data to EEPROM with two data sections separated by a hole, and verify
  - EE-r: read the entire EEPROM memory and write to file

The sketch and data payload is roughly one sixth of the respective memory size

| | `-c pgm` | `-p part` | Fl-ewv | Fl-r | EE-wv | EE-r | Comments |
|:-:|--:|--:|--:|--:|--:|--:|:--|
Prepare "-c arduino -P COM11 -b 115200 -p ATmega328P" and press 'enter' or 'space' to continue. Press any other key to skip
✅   2.920 s: flash -U write/verify holes_rjmp_loops_32768B.hex
✅   5.080 s: flash -U read all flash
|✅|arduino|ATmega328P| 2.92 s| 5.08 s|--|--| -b 115200 |

[stefanrueger]

I tend to think Optiboot is taking some shortcuts here

Yes, exactly: Optiboot does not erase the flash on a CE command but returns an STK_OK code (pretending it had deleted flash). -c urclock recognises the Optiboot bootloader by its hash value, knows about the Optiboot bug and repairs the bug by sending additional write page commands with empty payload 0xff bytes. This is what costs the time. This becomes obvious (I think) if you drop the -b option for test-avrdude; then some of the additional tests should fail for -c arduino.

[mcuee]

I see. Thanks for highlighting the difference between Optiboot and urboot, and how -c urclock addresses the issue.

[mcuee]

• Increase XMEGA/PDI programming speed #1831 (reply in thread)

From @dl8dtl

The AVRISPmkII was known to be the fastest programmer for all Atmel-originating AVRs. (Not sure about what is the fastest programmer for current UPDI AVRs.)

From @MCUdude

I haven't not been able to get more than 7-8 MHz out of my Power Debugger, which is essentially an Atmel ICE with more memory for debugging. The SNAP/Pickit4 is much, much slower.

[mcuee]

Early discussions: STK600 probably beats AVRISPmkII by a bit.

• Flash Read and Write Speed Benchmark #1022

[dl8dtl]

Early discussions: STK600 probably beats AVRISPmkII by a bit.

* [Flash Read and Write Speed Benchmark #1022](https://github.com/avrdudes/avrdude/discussions/1022)

Maybe, but it's been way more expensive.