- Add prog_modes to part and programmer definitions; prog_mode is a bitwise
or of programming modes
+ PM_SPM: Bootloaders, self-programming with SPM/NVM Controllers
+ PM_TPI: t4, t5, t9, t10, t20, t40, t102, t104
+ PM_ISP: SPI programming for In-System Programming (typ classic parts)
+ PM_PDI: Program and Debug Interface (xmega parts)
+ PM_UPDI: Unified Program and Debug Interface
+ PM_HVSP: High Voltage Serial Programming (some classic parts)
+ PM_HVPP: High Voltage Parallel Programming (most non-HVSP classic parts)
+ PM_debugWIRE: Simpler alternative to JTAG (a subset of HVPP/HVSP parts)
+ PM_JTAG: some classic parts, some xmega
+ PM_aWire: AVR32 parts
- Add mcuid, a unique id in 0..2039, to part definition for urclock programmer
- Add n_interrupts, the number of interrupts, to part definition
- Add n_page_erase to part definition (# of pages erased during NVM erase)
- Implement a simple calculator in config_gram.y so numeric values can be
expressed as simple expressions such as PM_SPM | PM_UPDI
- Introduce a new method of assigning simple components to the grammar without
touching config_gram.y via an eligible-component list in config.c; numeric
expressions on the rhs of an assignment resolve to integer values
- Update documentation in avrdude.conf.in and avrdude.texi
Done by adding code in developer_opts.c that allows to inject part
or memory parameters into a semi-automated rewrite of avrdude.conf
This is a generic method, whereby an external program can, eg.,
scrape atdf files for the right parameters and put them into a
source table into developer_opts.c
- Then write parts description with -p*/i
- Use the output in a new avrdude.conf
- Output again with -p* (no /i) and use that for final avrdude.conf
- Remove table entries
Some manual editing is still necessary to cater for the
@HAVE_PARPORT_BEGIN@ etc sections. This commit also fixes
superfluous whitesapce at the end of avrdude.conf.in lines
Although the avrdude.conf file has changed much, the internal
representation in avrdude has not. This can be verified by
exporting the raw internal data through
avrdude -c*/r -p*/r >/tmp/avrdude.raw
before the change and by comparing again after the change:
avrdude -c*/r -p*/r | diff - /tmp/avrdude.raw
In order to get meaningful const properties for the PROGRAMMER, AVRPART and
AVRMEM arguments, some code needed to be moved around, otherwise a network of
"tainted" assignments risked rendering nothing const:
- Change void (*enable)(PROGRAMMER *pgm) to void (*enable)(PROGRAMMER *pgm,
const AVRPART *p); this allows changes in the PROGRAMMER structure after
the part is known. For example, use TPI, UPDI, PDI functions in that
programmer appropriate to the part. This used to be done later in the
process, eg, in the initialize() function, which "taints" all other
programmer functions wrt const and sometimes requires other finessing with
flags etc. Much clearer with the modified enable() interface.
- Move TPI initpgm-type code from initialize() to enable() --- note that
initpgm() does not have the info at the time when it is called whether or
not TPI is required
- buspirate.c: move pgm->flag to PDATA(pgm)->flag (so legitimate
modification of the flag does not change PROGRAMMER structure)
- Move AVRPART_INIT_SMC and AVRPART_WRITE bits from the flags field in
AVRPART to jtagmkII.c's private data flags32 fiels as FLAGS32_INIT_SMC and
FLAGS32_WRITE bits
- Move the xbeeResetPin component to private data in stk500.c as this is
needed by xbee when it saddles on the stk500 code (previously, the flags
component of the part was re-dedicated to this)
- Change the way the "chained" private data are used in jtag3.c whilst
keeping the PROGRAMMER structure read-only otherwise
- In stk500v2.c move the STK600 pgm update from stk500v2_initialize() to
stk500v2_enable() so the former keeps the PROGRAMMER structure read-only
(for const assertion).
- In usbasp change the code from changing PROGRAMMER functions late to
dispatching to TPI or regular SPI protocol functions at runtime; reason
being the decision whether to use TPI protocol is done at run-time
depending on the capability of the attached programmer
Also fixes Issue #1071, the treatment of default eecr value.
This commit changes the philosophy whenever avrdude.conf encounters the
same memory of a part for the second time or whenever a memory is
described that, through inheritance, already existed: AVRDUDE no longer
zaps the memory, it rather extends it.
Therefore, avrdude.conf.in's entry for ATmega128RFA1, which inherits from
the ATmega2561, needs a line `load_ext_addr = NULL;` in its flash memory
description to zap the inherited load_ext_addr SPI command.
Other than this, avrdude.conf.in needs no other change in order to effect
the same internal representation proving earlier updates to the .conf.in
file correct that manually ensured inheritance of memory contents.
This feature has been designed with the sometimes quite flakey direct
(parallel or serial port attached) bitbang programming adapters in
mind that were quite common about two decades ago.
With parallel ports vanishing from modern PCs almost completely, and
the advent of various USB-attached low-cost programming devices,
this class of programmers disappeared almost completely.
Furthermore, the fuse combinations that were covered by the feature
are no longer around on all recent AVR devices, so for an ever
increasing number of devices, safemode already became meaningless and
was turned off anyway.
With the prospective version 7.x release, it's a good point in time to
introduce a major change like this one.
