Two parts are considered variants here if one part name starts with the name
of the other, flash memory sizes are the same, flash page sizes are the same
and the number of interrupts are the same.
These assignments have been removed as they are redundant and only
imitate the single prog_modes = PM_... | PM_....; assignment. They
are still allowed in the grammar, and would still work.
flags now just hold parameters of the JTAG interface and some secondary
serial, parallel, pseudo parallel info. This separation brings clarity. It
used to be hard to augur whether a part has an ISP interface:
(part->flags & (AVRPART_HAS_PDI | AVRPART_AVR32 | AVRPART_HAS_TPI
| AVRPART_HAS_UPDI)) == 0 && (part->flags & AVRPART_SERIALOK) != 0
or had HVSP or HVPP capability, for that matter. Now it is just, eg,
part->prog_modes & PM_ISP
part->prog_modes & PM_HVPP
- 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
Change (int) poll_index >= (int) addr to poll_index+1 > addr as the former
might turn out to be implementation-defined. The latter is always defined
and what we want here (poll_index+1 won't overflow). Originally, the
condition was poll_index > addr-1, which was always false for addr=0 owing to
2^n modulo arithmetic of unsigned.
Also changed a few comparisons so they no longer are between signed
and unsigned integers reducing compiler warnings.
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.
Stefan Rueger
Marius Greuel
Alex Papazoglou