Go to file
Stefan Rueger d74b17b9b4
Provide cached byte-wise read/write API (#1106)
* 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.
2022-10-05 22:16:15 +01:00
.github/workflows GitHub Actions: Update apt index before installing packages 2022-09-29 22:02:04 +02:00
atmel-docs Just to make sure this won't get lost over time, make a copy of 2015-11-02 21:13:28 +00:00
src Provide cached byte-wise read/write API (#1106) 2022-10-05 22:16:15 +01:00
tools Allow for overriding make tool from environment 2021-12-10 22:34:57 +00:00
.editorconfig Add GitHub build action for CMake project 2021-12-20 17:52:37 +01:00
.gitattributes Add .gitattributes and .gitignore, remove .cvsignore 2021-12-16 23:24:32 +01:00
.gitignore Add cscope.out to list of ignored files 2022-01-13 22:43:03 +01:00
AUTHORS Mention Hans Eirik Bull for his recent contributions 2022-02-01 23:26:20 +01:00
CMakeLists.txt CMake: Add initial support for texinfo docs 2022-09-04 16:55:16 +02:00
COPYING Revert "Hint about possibly differing licensing terms." 2022-01-04 12:53:27 +01:00
INSTALL Update toplevel files. 2021-12-18 22:32:50 +01:00
NEWS Update NEWS 2022-09-24 13:29:04 +01:00
README.md Update documentation link to new URL 2022-04-10 11:28:39 -07:00
build.sh add extended parameter "disable_no_sc" for linuxspi programmer 2022-09-20 01:32:12 +09:00

README.md

AVRDUDE

Build Status

AVRDUDE - AVR Downloader Uploader - is a program for downloading and uploading the on-chip memories of Microchips AVR microcontrollers. It can program the Flash and EEPROM, and where supported by the programming protocol, it can program fuse and lock bits. AVRDUDE also supplies a direct instruction mode allowing one to issue any programming instruction to the AVR chip regardless of whether AVRDUDE implements that specific feature of a particular chip.

AVRDUDE was originally written in 2003 by Brian S. Dean. Since 2006, AVRDUDE has been maintained by Jörg Wunsch, with the help of various contributors.

The latest version of AVRDUDE is always available here:
https://github.com/avrdudes/avrdude

Documentation

Documentation for current and previous releases is on Github Pages.

Getting AVRDUDE for Windows

To get AVRDUDE for Windows, install the latest version from the Releases page.

Alternatively, you may build AVRDUDE yourself from source.

Getting AVRDUDE for Linux

To install AVRDUDE for Linux, install the package avrdude by running the following commands:

sudo apt-get install avrdude

Alternatively, you may build AVRDUDE yourself from source.

Getting AVRDUDE for MacOS

On MacOS, AVRDUDE can be installed through Mac Ports.

Alternatively, you may build AVRDUDE yourself from source.

Using AVRDUDE

AVRDUDE is a command-line application. Run the command avrdude without any arguments for a list of options.

A typical command to program your HEX file into your AVR microcontroller looks like this:

avrdude -c <programmer> -p <part> -U flash:w:<file>:i

For instance, to program an Arduino Uno connected to the serial port COM1 with a HEX file called blink.hex, you would run the following command:

avrdude -c arduino -P COM1 -b 115200 -p atmega328p -D -U flash:w:objs/blink.hex:i

There are many different programmers and options that may be required for the programming to succeed.

For more information, refer to the AVRDUDE documentation.