that programmers other than the direct parallel port connection can be
supported.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@159 81a1dc3b-b13d-400b-aceb-764788c761c2
the 'dump <memtype>' command without any address information,
and the end of memory is reached, wrap back around to zero on
the next invocation.
CHANGELOG - describe changes
main.c - update version number
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@157 81a1dc3b-b13d-400b-aceb-764788c761c2
first pull /RESET low for a short period of time before enabling the
buffer chip. This sequence allows the AVR to be reset before the
buffer is enabled to avoid a short period of time where the AVR may be
driving the programming lines at the same time the programmer tries
to. Of course, if a buffer is being used, then the /RESET line from
the programmer needs to be directly connected to the AVR /RESET line
and not via the buffer chip.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@156 81a1dc3b-b13d-400b-aceb-764788c761c2
appeared in version 2.1.0, but was changed to a 4 byte counter in
version 2.1.1. Reminded by Joerg Wunsch.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@150 81a1dc3b-b13d-400b-aceb-764788c761c2
cycle count stored at the end of EEPROM. It seems as though Atmel was
greatly conservative in claiming a 1000 count reliability for the
FLASH. I current have a part that has been reprogrammed 173330 times,
and counting.
Fix a compiler warning.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@144 81a1dc3b-b13d-400b-aceb-764788c761c2
that it is tracked no matter where the erase was initiated: command
line mode or interactive mode, without code duplicaiton.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@141 81a1dc3b-b13d-400b-aceb-764788c761c2
undergone. This utilizes the last two bytes of EEPROM to maintain a
counter that is incremented each time the part is erased.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@138 81a1dc3b-b13d-400b-aceb-764788c761c2
Display the correct memory name in an error message (previously
hardcoded).
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@137 81a1dc3b-b13d-400b-aceb-764788c761c2
overwriting user-modified configs.
Add read/write instructions for all memory types for ATMEGA103,
ATMEGA128, ATMEGA16, and ATMEGA8.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@132 81a1dc3b-b13d-400b-aceb-764788c761c2
Fix setting of status LEDs under various write-fail conditions.
Add a flag to indicate that a memory type requires the device to
possibly be powered off and back on after a write to it. This is due
to a hardware problem on some Atmel devices, see:
http://www.atmel.com/atmel/acrobat/doc1280.pdf
Add greater verbosity to the part-display code when verbose>1 to
display avrprog's encoding of the defined programming instructions.
This is primarily for debugging purposes.
Part updates:
* add the AT90S4414 part
* add fuse and lock bit access instructions for the AT90S1200,
AT90S4434, and AT90S8515.
* add the pwroff_after_write flag to the fuse bits for the AT90S2333
and AT90S4433 parts
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@123 81a1dc3b-b13d-400b-aceb-764788c761c2
Make the BUFF pin a mask like VCC to allow multiple pins to be
asserted at the same time (STK200 has two buffer enable lines).
Add the STK200 programmer.
Fix EEPROM address line selection for several parts.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@109 81a1dc3b-b13d-400b-aceb-764788c761c2
used to make the instruction input more readable in the config file.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@102 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@100 81a1dc3b-b13d-400b-aceb-764788c761c2
Brian S. Dean