d134dc8fff
Implementation for an "alias" keyword. By now, only applied inside memory descriptions. * Make "mem_alias" a separate nonterminal. The previous implementation attempt caused a syntax error in yacc code, and separating mem_alias on the same level as mem_spec appears to be the cleaner solution anyway. * Maintain real memory aliases. Instead of duplicating the aliased memory with a new name, maintain a second list of memory aliases (per device) that contains a pointer to the memory area it is aliased to. That way, a memory name can be clearly distinguished between the canonical one and any aliases. * Check p->mem_alias != NULL before touching it * Add avr_find_memalias() This takes a memory region as input, and searches whether an alias can be found for it. * We need to add a list structure for the mem_alias list, always. By that means, mem_alias won't ever be NULL, so no need to check later. Also, in avr_dup_part(), duplicate the alias list. * In a memory alias, actually remember the current name. * In avr_dup_part(), adjust pointers of aliased memories While walking the list of memories, for each entry, see if there is an alias pointing to it. If so, allocate a duplicated one, and fix its aliased_mem pointer to point to the duplicated memory region instead of the original one. * Add avr_locate_mem_noalias() When looking whether any memory region has already been defined for the current part while parsing the config file, only non-aliased names must be considered. Otherwise, a newly defined alias would kick out the memory definition it is being aliased to. * When defining a mem_alias, drop any existing one of that name. * Actually use avr_find_memalias() to find aliases * Add declaration for avr_find_memalias() * When defining a memory, also search for an existing alias If the newly defined name has the same as an existing alias, the alias can be removed. Note that we do explicitly *not* remove any memory by the same name of a later defined alias, as this might invalidate another alias'es pointer. If someone defines that, the alias name just won't ever be found by avr_locate_mem(). |
||
---|---|---|
.github/workflows | ||
atmel-docs | ||
src | ||
tools | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
AUTHORS | ||
CMakeLists.txt | ||
COPYING | ||
INSTALL | ||
NEWS | ||
README.md | ||
build.sh |
README.md
AVRDUDE
AVRDUDE - AVR Downloader Uploader - is a program for downloading and uploading the on-chip memories of Microchip’s 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
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.