So any programmer that knows exactly which part it is connected to
can set the -p part option should the user not have done so.
Also no longer exits main without closing open programmer.
* If bootloaders are served, send word addresses for classic parts and
byte addresses for newer parts, eg, UPDI and PDI
* Load ext addr for stk500v1 bootloaders after grazing 64k boundaries
* Fix bootloader stk500v1 EEPROM r/w for classic parts with page size 1
* 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
* Look for ~/.config/avrdude/config configuration file
Traditionally per-user configuration files have been placed
in user's home directory with their names beginnig with a dot
to hide them from some tools like ls(1). However, the number
of programs following this convention have grown over time
to the point where the number of hidden files becomes inconvenient to
some users. For this reason the XDG Base Directory Specification[1]
specifies an alternate place to store configuration files under
~/.config directory.
This patch enables avrdude to look for ~/.config/avrdude/config
configuration file, if ~/.avrduderc doesn't exist.
[1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-0.8.html
* Safely concatenate directories and configurations files and minor changes in docs
* Make stats variable available for WIN32 again in main.c
* Utilise full usr_config[] array space
* Check for xdg-style avrdude.rc file first before fallback ~/.avrduderc
Co-authored-by: Stefan Rueger <stefan.rueger@urclocks.com>
* 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
* Fix writing of last word on DWORD TPI parts
* Add n_word_writes AVRMEM config option
* TPI word chunk mode in avr_write_mem
* Simplify addition of n_words_write mem component to grammar
Co-authored-by: Stefan Rueger <stefan.rueger@urclocks.com>
* Provide cached byte-wise read/write API
int avr_read_byte_cached(const PROGRAMMER *pgm, const AVRPART *p, const
AVRMEM *mem, unsigned long addr, unsigned char *value);
int avr_write_byte_cached(const PROGRAMMER *pgm, const AVRPART *p, const
AVRMEM *mem, unsigned long addr, unsigned char data);
int avr_flush_cache(const PROGRAMMER *pgm, const AVRPART *p);
int avr_chip_erase_cached(const PROGRAMMER *pgm, const AVRPART *p);
int avr_reset_cache(const PROGRAMMER *pgm, const AVRPART *p);
avr_read_byte_cached() and avr_write_byte_cached() use a cache if paged
routines are available and if the device memory is EEPROM or flash,
otherwise they fall back to pgm->read_byte() and pgm->write_byte(),
respectively. Byte-wise cached read always gets its data from the cache,
possibly after reading a page from the device memory. Byte-wise cached
write with an address in memory range only ever modifies the cache. Any
modifications are written to the device after calling avr_flush_cache() or
when attempting to read or write from a location outside the address range
of the device memory.
avr_flush_cache() synchronises pending writes to EEPROM and flash with the
device. With some programmer and part combinations, flash (and sometimes
EEPROM, too) looks like a NOR memory, ie, one can only write 0 bits, not 1
bits. When this is detected, either page erase is deployed (eg, with parts
that have PDI/UPDI interfaces), or if that is not available, both EEPROM
and flash caches are fully read in, a pgm->chip_erase() command is issued
and both EEPROM and flash are written back to the device. Hence, it can
take minutes to ensure that a single previously cleared bit is set and,
therefore, this routine should be called sparingly.
avr_chip_erase_cached() erases the chip and discards pending writes() to
flash or EEPROM. It presets the flash cache to all 0xff alleviating the
need to read from the device flash. However, if the programmer serves
bootloaders (pgm->prog_modes & PM_SPM) then the flash cache is reset
instead, necessitating flash memory be fetched from the device on first
read; the reason for this is that bootloaders emulate chip erase and they
won't overwrite themselves (some bootloaders, eg, optiboot ignore chip
erase commands altogether) making it truly unknowable what the flash
contents on device is after a chip erase.
For EEPROM avr_chip_erase_cached() concludes that it has been deleted if a
previously cached EEPROM page that contained cleared bits now no longer
has these clear bits on the device. Only with this evidence is the EEPROM
cache preset to all 0xff otherwise the cache discards all pending writes
to EEPROM and is left unchanged otherwise.
Finally, avr_reset_cache() resets the cache without synchronising pending
writes() to the device.
Now variants of chips that the JTAG ICE supports will not cause a warning when used with the original JTAG ICE mkI.
Also, The ATmega165 isn't officially supported by the ICE mkI, so this should be properly tested with the ICE mkI first.
This makes it possible for the application to start immedeatly after the program has been loaded.
Simply use '-E reset' or '-E noreset'. Default is no reset.
Closes#733
Stefan Rueger
MCUdude
mcuee
steelman
Dawid Buchwald
Dan Applegate
Marius Greuel
Shunichi Wakabayashi