stk500 initialization routine. However, allow one to use the -F
option to ignore a bad return code from that function. I think this
still allows what Joerg intended, i.e., providing a way to still get
into terminal mode so that one can recover from setting bad STK500
values which may keep the chip from entering programming mode.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@359 81a1dc3b-b13d-400b-aceb-764788c761c2
anywhere specified to be written by any of the -U requests.
To remain backward compatible with previous versions, disable this
feature if any of the old-style memory specification operations are
specified (-i, -o).
Implement the -D option to explicitly disable the auto erase default.
Deprecate the old-style memory specification options (-f, -i, -I, -m,
and -o) in favor of the new -U option which allows one to operate on
multiple memories on a single command line.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@356 81a1dc3b-b13d-400b-aceb-764788c761c2
memory read or written (or up to where continuous 0xff begins in the
case of flash memory). An 'int' should be plenty big enough for that.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@354 81a1dc3b-b13d-400b-aceb-764788c761c2
fixes stk500 problem where number of bytes written is less than a page.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@348 81a1dc3b-b13d-400b-aceb-764788c761c2
argument is a 4 field string (fields seperated by colons) which
indicate what memory type to operate on, what operation to perform is
(read, write, or verify), the filename to read from, write to, or
verify against, and an optional file format field. Multple -U options
can be specified to operate on more than one memory at a time with a
single invocation. For example, to update both the flash and the
eeprom at the same time one can now specify the following:
avrdude -p -e -U flash:w:main.hex:i -U eeprom:w:eeprom.hex:i
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@341 81a1dc3b-b13d-400b-aceb-764788c761c2
reported that this patch fixes verify errors on the Windows platform
that are apparently timing related. Submitted by: Alex Shepherd
<ashepherd@wave.co.nz>, who indicates that this patch was based on
code from the UISP project.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@340 81a1dc3b-b13d-400b-aceb-764788c761c2
* doc/avrdude.texi: Document the -q option.
Fix some typos left over from pasting in man output.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@339 81a1dc3b-b13d-400b-aceb-764788c761c2
Extend ATmega8 calibration memory to support all 4 calibration bytes.
Savannah bug #3835. Submitted by Francisco T. A. Silva
<ftas@geodigitus.com.br>.
Add a few AVR910 programmer device codes. Savannah bug #3569 - sorry
I can't tell who submitted this to give proper credit.
Add support for the ATtiny12. Submitted by Pontifex <pontifex@isys.ca>
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@332 81a1dc3b-b13d-400b-aceb-764788c761c2
resides above the last non-0xff data value in the address space. Only
do this for flash memory since writing a 0xff to flash is a no-op.
This has the affect of creating smaller output files when dumping
memory contents from flash if the program in flash does not consume
the whole memory space. It also results in shorter programming times
when avrdude is asked to load a file into flash that has lots of 0xff
filled data past the last non-0xff data value.
I think this is basically where Alexey was going with his s-record
routine, but this should have a similar affect for all the I/O
routines. The main difference is that Alexey's also optimized 0xff
from the beginning of the address space and was not limited to flash.
I think that these optimizations should be limited to the flash since
it is currently the only memory that treats 0xff as special.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@331 81a1dc3b-b13d-400b-aceb-764788c761c2
output routines (don't optimize away 0xff data before and after non
0xff data). Also, fix a bug where the data contents sometimes weren't
written out completely.
Initial bug reported by Tom Harris <TomH@optiscan.com>. Fixes
provided by Alexey V.Levdikov <tsar@kemford.com>.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@330 81a1dc3b-b13d-400b-aceb-764788c761c2
main.c : print out '<stdin>' and '<stdout>' instead of '-' when using
stdio for I/O.
Thanks to Francisco T. A. Silva <ftas@geodigitus.com.br> for catching
this, and the error fixed by the previous commit as well.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@325 81a1dc3b-b13d-400b-aceb-764788c761c2
file format type to 'immediate mode' where the filename is assumed to
be the memory data itself.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@318 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@317 81a1dc3b-b13d-400b-aceb-764788c761c2