For devices connected through a real serial device rather than
USB, there is no transport-layer serial number available.
stk500v2.c (and jtag3.c) tried to always call this function.
Closes#1254
* Silence compiler warnings
* Fix a fall-through error in switch
* Slightly reformat programmer info printout
Now the target voltage is printed out along with the HW version, FW version and serial number, and they all allign nicely. When in ISP mode, the "SCK period" value is printed _after_ the target voltage readout, and _before_ the additional clocks the programmer holds, such as JTAG, PDI and UPDI clocks.
Co-authored-by: Stefan Rueger <stefan.rueger@urclocks.com>
Currently, only some JTAG3 compatible programmers are able to detect that the connected target's main clock speed actually is too low for for the programmer.
In this case, these will return 0xCC.
* Print parms output to stdout
* Flush terminal writes and other minor changes
* Prepare terminal for periodic calls to programmer to reset bootloader WDT
* Only show progress reports for memories > 32 bytes or on -vv
* Freeze progress bar on serious error
* Allow cached r/w byte routines to be used in pgm->read_byte and pgm->write_byte
* Change avrdude_message(MSG_XYZ, ...) to msg_xyz(...)
* Define and use pmsg_xyz(...) instead of msg_xyz("%s: ...", progname, ...)
* Review and change avrdude_message() levels
- Introduce new levels warning, error and ext_error
- Distribute info level to info, warning, error, ext_error
- Assign levels (more) consistently
- Unify grammar, punctuation and style of messages
* Use imsg_xyz() to print indented messages
* Show function name in errors and warnings on -v
* Reduce effective verbosity level by number of -q above one
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
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.