Generate the version number used in the Autotools builds
via a script from the top-level CMakeLists.txt and git
information instead of manual editing.
This script mimics what the avrdude top-level CMakeLists.txt
does for composing AVRDUDE_FULL_VERSION.
Consequently, maintainers do not need to edit the version numbers
in the "src/configure.ac" file's "AC_INIT(...)" line any more.
However, unlike the cmake based builds, this does not print the
commit hash in the "avrdude --help" message or in the "avrdude.conf"
file's "avrdude_conf_version = " line. That will come later.
These are the six build types supported and what avrdude
versions cmake and the autoconf builds actually produce:
cmake autoconf
git clone release 7.2 7.2
git clone non-release 7.2-DATE+HASH 7.2-DATE
git archive release 7.2 7.2
git archive non-release 7.2 7.2
dist tarball release N/A 7.2
dist tarball non-release N/A 7.2-DATE
Sometimes when building with the Autoconf buildsystem,
the avrdude-html/ subdir already exists and therefore
renaming the newly built avrdude/ subdir to avrdude-html/
cannot succeed.
Removing the old avrdude-html/ subdir first fixes that.
Previously, the code would limit the clock to 1Mhz. If a higher clock
was specified, it would be set to 1.024Mhz (0x400 khz).
This commit removes this artificial limit, while still preventing
overflowing the two bytes available in the command (effectively limiting
to 65535 kHz).
The original limit seems inappropriate, because the JTAGEICE3 and ATMEL
ICE actually support higher clocks than the old limit. For SPI, the
JTAGICE3 documents supporting up to 1.875Mhz and the ATMEL ICE up to
5Mhz. In practice the JTAGEICE3 (with the newer EDBG version where it
becomes pretty much identical to the ATMEL ICE) also works up to 5Mhz.
When trying to set higher values, the behaviour seems to depend on the
current value. The programmer seems to either keep the previous value
(e.g. from 3Mhz to 10Mhz), or use 8kHz / 125μs (e.g. from 5Mhz to
10Mhz). In any case, the value read back afterwards (and printed with
-v) reflects the actual value.
Also note that the code also applies a lower limit of 1kHz (to ensure
the raw value sent to the device, in kHz, is never zero), but in
practice sending a value of lower than 8kHz ends up setting 8kHz
(125μs). This is also the minimum value in the device documentation.
This commit was tested with:
Programmer Type : JTAG3_ISP
Description : Atmel AVR JTAGICE3 in ISP mode
ICE HW version : 2
ICE FW version : 3.55 (rel. 130)
