The cumulative time for typical user tasks depends on the flash and EEPROM
size of the part. This commit computes a size-normalised time. Lower is
better. This avrbench number still depends on the part, but less so than
the cumulative time of the tasks.
The summary line is put in vertical bars to make creation of markdown
tables easier.
This executes five tests for typical programming tasks:
- Write/verify a "difficult" sketch to flash: two code sections and one
data section separated by "holes" of different sizes
- Dump all flash, eg, to make a backup
- Write/verify a "difficult" eeprom data file with holes
- Dump all eeprom, eg, to make a backup
- Chip erase (bootloaders are expected to page erase flash apart from
the bootloader itself) and spot check whether flash was erased
The reported times are realistic times with overhead of starting avrdude,
resetting the board via DTR/RTS, establishing comms, including erasing the
flash before writing/verifying the sketch and disengaging the chip.
$ test-avrdude -b -d 0 \
-p "u7.7/weu-jPrac -c urclock -P ch340 -p m328p -b 1000000" \
-p "u7.7/-eu-jPrac -c urclock -P ch340 -p m328p -b 1000000"
Testing avrdude version 7.3-20240225 (20788712)
Prepare "u7.7/weu-jPrac -c urclock -P ch340 -p m328p -b 1000000" and press 'enter' or 'space' to continue. Press any other key to skip
✅ 2.174 s: flash -U write/verify holes_rjmp_loops_32768B.hex
✅ 1.339 s: flash -U read all flash
✅ 1.415 s: eeprom -U write/verify holes_pack_my_box_1024B.hex
✅ 1.034 s: eeprom -U read all
✅ 1.604 s: chip erase and spot check flash is actually erased
✅ 7.566 s: benchmark for u7.7/weu-jPrac -c urclock -P ch340 -p m328p -b 1000000
Prepare "u7.7/-eu-jPrac -c urclock -P ch340 -p m328p -b 1000000" and press 'enter' or 'space' to continue. Press any other key to skip
✅ 2.001 s: flash -U write/verify holes_rjmp_loops_32768B.hex
✅ 1.333 s: flash -U read all flash
✅ 1.405 s: eeprom -U write/verify holes_pack_my_box_1024B.hex
✅ 1.029 s: eeprom -U read all
✅ 1.618 s: chip erase and spot check flash is actually erased
✅ 7.386 s: benchmark for u7.7/-eu-jPrac -c urclock -P ch340 -p m328p -b 1000000
Note the benchmark line with the cumulative time for all five tasks
As it can happen that there is a leftover `src/ac_cfg.h` when
running an out of tree cmake build (you might have run `cmake .`
or `./src/bootstrap`), the out of tree cmake build must look
for `ac_cfg.h` in its builddir first (e.g. `build_linux/src/`).
Otherwise the cmake build picks up and uses whatever data happens
to be in `src/ac_cfg.h`.
Both the MSVC and GCC C processors are documented to look in the
location of the `#include` directive for the included file first
for double quoted includes, so the old `#include "ac_cfg.h"` was
exactly the wrong thing to do. clang probably does the same, and
ISO C specifies the sequence of places to look for include files
as implementation defined.
So this changes all occurrences of `#include "ac_cfg.h"` to
`#include <ac_cfg.h>` which follows the sequence of `-I` or `/I`
directives as cmake builds add via `include_directories` or
`target_include_directories`.
Fixes: https://github.com/avrdudes/avrdude/issues/1706
When there is no `src/ac_cfg.h` (e.g. a fresh `git clone` or after
a working dir cleanup like `git -f -d -x`), running `cmake` will
complain about not being able to find `ac_cfg.h`.
This is probably because cmake looks for source files in the
`CMAKE_CURRENT_SOURCE_DIR`, but when cmake creates `ac_cfg.h`
it does so ´CMAKE_CURRENT_BINARY_DIR`, which is often different.
Anyway, this makes the location of files generated by `configure_file`
explicit as `CMAKE_CURRENT_BINARY_DIR`, and uses that same location
in the source file list for the `libavrdude` target (instead of just
`ac_cfg.h` with the implicit `CMAKE_CURRENT_SOURCE_DIR`) and adds the
same source file to the `avrdude` target to allow cmake to determine
the dependencies properly.
Directly use the AVRDUDE_FULL_VERSION macro instead of first
defining an initialized variable which is never changed and
then using that variable.
This means one less layer of indirection both for the computer
and for the programmer to go through when trying to understand
the code.
Developer options are added to part names or wildcards by a / suffix
followed by a the option characters. However, some part variant names also
contain a slash, eg, AVR64DB64-E/MR. This commit gives priority to such a
variant name and does not interpret the slash as developer option.
Have the autotools place their m4 files into the auto-m4/
subdir to separate them from our own m4 files.
Not using AC_CONFIG_MACRO_DIRS for backwards compatibility.
Add the GIT_COMMIT_HASH to the version message printed by
"avrdude -?" and in the avrdude.conf avrdude_conf_version line.
So the autotools buildsystem now produces the identical
version message as the cmake buildsystem does.
This m4 quotes many more macro arguments and deals with the
setting of variables.
* Set variable default values to avoid accidental use of
env var values from the caller of the configure script
* rewrap some longer lines
* Remove AC_SUBST([FOO], [$FOO]) type no-ops. AC_SUBST([FOO])
does the same.
Calling AVRDUDE_FULL_VERSION just VERSION in parts of the build
process, and AVRDUDE_FULL_VERSION in others, is unnecessarily confusing.
So call it AVRDUDE_FULL_VERSION everywhere.
