(Extended Linear Address Record)
Replace the change from r928 (handling of 0x8000000 offset in AVR32
files) by a completely different logic that no longer breaks hex files
for other devices starting with an offset; also apply a similar change
to S-record files, as well as when writing files.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@1017 81a1dc3b-b13d-400b-aceb-764788c761c2
- Make all internal functions "static".
- Make sure each module's header and implementation file match.
- Remove all library-like functionality from main.c, so only
the actual frontend remains in main.c.
- Add C++ brackets to all header files.
That effectively leaves the various module C files as something like
an "avrdude library", with main.c being the currently only frontend
program for that library. In theory, it should be possible to write
different frontends using the same library backend functions though.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@722 81a1dc3b-b13d-400b-aceb-764788c761c2
and binary numbers.
Closes bug #16129: more output formats for fuse bits (avrdude
enhancement request)
* fileio.c: Implement fileio_num() and the itoa_simple() helper function.
* fileio.h: Add new file formats to FILEFMT.
* main.c: Parse the new file formats.
* avrdude.1: Document all this.
* doc/avrdude.texi: (Ditto.)
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@654 81a1dc3b-b13d-400b-aceb-764788c761c2
specify byte values on the command line instead of via a file. This
can be good for specifying fuse bytes and eliminates the need to
create single-byte files or using interactive terminal mode for these
single-byte memories. Requested by several folks on the mailing list.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@317 81a1dc3b-b13d-400b-aceb-764788c761c2
This was intended to be used for identifying code in the field for
incoming bug reports, but I've never really found it all that useful.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@171 81a1dc3b-b13d-400b-aceb-764788c761c2
serial programming instructions are not very orthoganal, i.e., the
"read fuse bits" instruction on an ATMega103 is an entirely different
opcode and data format from the _same_ instruction for an ATMega163!
Thus, it becomes impossible to have a single instruction encoding
(varying the data) across the chip lines.
This set of changes allows and requires instruction encodings to be
defined on a per-part basis within the configuration file. Hopefully
I've defined the encoding scheme in a general enough way so it is
useful in describing the instruction formats for yet-to-be invented
Atmel chips. I've tried hard to make it match very closely with the
specification in Atmel's data sheets for their parts. It's a little
more verbose than what I initially hoped for, but I've tried to keep
it as concise as I could, while still remaining reasonably flexible.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@100 81a1dc3b-b13d-400b-aceb-764788c761c2
file. This makes supporting other programmers much easier.
Rename AVRprog.pdf to avrprog.pdf.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@67 81a1dc3b-b13d-400b-aceb-764788c761c2
only via main() so that the exitspecs are properly applied.
When reading input data from a file, remember how many bytes were read
and write and verify only that many bytes.
Don't complain when an input file size is smaller than the memory size
we are programming. This is normal.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@44 81a1dc3b-b13d-400b-aceb-764788c761c2
more modular pieces.
Also, accept command abbreviations as long as they are not ambiguous.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@38 81a1dc3b-b13d-400b-aceb-764788c761c2
joerg_wunsch
bdean
bsd