eeprom, efuse, hfuse, and lfuse on a single command line. Much of the
output had to be ommitted from the example since the texi commands for
formatting the example don't allow page breaks within the example. If
someone knows a better way to format it, please feel free to do so.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@361 81a1dc3b-b13d-400b-aceb-764788c761c2
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/avrdude@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/avrdude@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/avrdude@354 81a1dc3b-b13d-400b-aceb-764788c761c2
Add the supported programmer list to the manual.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@343 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/avrdude@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/avrdude@340 81a1dc3b-b13d-400b-aceb-764788c761c2
Submitted by Larry Barello <larryba@barello.net>.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@333 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/avrdude@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/avrdude@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/avrdude@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/avrdude@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/avrdude@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/avrdude@317 81a1dc3b-b13d-400b-aceb-764788c761c2
Daniel Williamson <dannyw@maconmgt.co.uk>
and
Ruwan Jayanetti <rjayanetti@sri.crossvue.com>
The resulting part definition used was actually somewhat of a merge of
the two submitted definitions.
Thanks for the contributions!
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@302 81a1dc3b-b13d-400b-aceb-764788c761c2
name when checking to see if we should default to the default_serial
port instead of the default_parallel port. This has us do the right
thing for the new 'avrisp' programmer.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@262 81a1dc3b-b13d-400b-aceb-764788c761c2
command be 128 bytes. This cuts 6 seconds off the programming time
for uploading a 6K file into an AT90S8515 vs the time loading the same
file using a 16 byte buffer, and the response feedback is still good.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@261 81a1dc3b-b13d-400b-aceb-764788c761c2
all on non-paged-memory parts. The problem was that the page size was
defaulting to 256 (maximum for the stk500), but the timeout for a
response from the stk500 before declaring it dead was only 0.5
seconds. But it takes much longer than 0.5 seconds to program 256
bytes, so we just weren't waiting long enough.
Fix this in two ways - increase the timeout to 5 seconds, and decrease
the page size to 16 bytes for non-paged parts. The programming time
for 16 bytes is short enough to provide the user with some feedback
that something is happening.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@260 81a1dc3b-b13d-400b-aceb-764788c761c2
itself is paged as it doesn't appear to work otherwise.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@259 81a1dc3b-b13d-400b-aceb-764788c761c2
causes some shift-reduce conflicts, but I think they are OK.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@255 81a1dc3b-b13d-400b-aceb-764788c761c2
haven't been specified in the config file for the part.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@250 81a1dc3b-b13d-400b-aceb-764788c761c2
Jason Kyle for the needed protocol information.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@248 81a1dc3b-b13d-400b-aceb-764788c761c2
$HOME/.avrduderc. Entries from .avrduderc take precedence over those
from the system wide config file in ${PREFIX}/etc/avrdude.conf.
Track and display the config file name and line number when we print
out the available parts and programmers. This is useful in case
someone has overridden a definition in their .avrduderc file and is
wondering why the definition in the system wide config file is not
being used.
Remove the default programmer 'stk500' from the distributed config
file.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@222 81a1dc3b-b13d-400b-aceb-764788c761c2
one of the programmers to be tagged "default" within its definition.
Also, axe the notion of a compiled-in default programmer. It is
kind've pointless now that nearly all configuration comes from the
config file, thus, avrdude is not very useful without the config file,
and thus, having a programmer compiled-in offers little or no benefit.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@218 81a1dc3b-b13d-400b-aceb-764788c761c2
This adds 'default_parallel' and 'default_serial' keywords to the
grammar, which take quoted string arguments.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@214 81a1dc3b-b13d-400b-aceb-764788c761c2
programming mode. Use 'retry_pulse' in the per-part specification
that can currently take values of 'reset' or 'sck', the default being
'sck' which preserves the previous behaviour. Some newer parts
indicate that /RESET should be pulsed, while older parts say to pulse
SCK.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@212 81a1dc3b-b13d-400b-aceb-764788c761c2
the last commit. Those were just there for testing.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@209 81a1dc3b-b13d-400b-aceb-764788c761c2
say whether parts support these programming modes or not. Possible
values for 'serial' are 'yes' or 'no'. Possible values for 'parallel'
are 'yes', 'no', or 'pseudo'. Add a bit mask of flags to the AVRPART
structure to capture these settings. Use these within
stk500_initialize() to set the device parameters correctly.
Defaults for 'serial' and 'parallel' are 'yes' unless specified
otherwise.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@208 81a1dc3b-b13d-400b-aceb-764788c761c2
PAGEL and BS2 signals and the disposition of the reset pin
('dedicated' or 'io').
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@202 81a1dc3b-b13d-400b-aceb-764788c761c2
its own file par.c, leaving low level parallel port accessor routines
in ppi.c to help with portability. Change the programmer type to
'PAR' now instead of 'PPI' - 'PAR' represents the parallel port
programmer type.
Be more liberal with 'static' function declarations within the
programmer implimentation files - these functions should never be
called directly - always use the programmer function references.
There are still a few places in 'main.c' that directly reference the
parallel programmer explicitly (par_getpinmask). These should be
fixed somehow.
Axe a few unused functions.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@190 81a1dc3b-b13d-400b-aceb-764788c761c2
existed on a private system. Commits made by 'bsd' on the old system
were made by Brian Dean (bdean on the current system).
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@179 81a1dc3b-b13d-400b-aceb-764788c761c2
from stk500.h - don't know how those got in there (pointed out by Ted
Roth).
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@173 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
This change represents a name change only. There is currently an
effort to port AVRPROG to other platforms including Linux and Windows.
Since Atmel's programmer binary that's included within their AVR
Studio software is named AVRPROG.EXE on the Windows OS, there is the
chance for confusion if we keep calling this program AVRPROG as well.
Up until now the name hasn't really been a problem since there was no
chance to confuse 'avrprog' on Unix with Atmel's AVRPROG because
Atmel's tools only run on Windows. But with the Unix 'avrprog'
possibly being ported to Windows, I felt a name change was the best
way to avoid problems.
So - from this point forward, my FreeBSD Unix program formerly known
as AVRPROG will subsequently be known as AVRDUDE (AVR Downloader/UploaDEr).
This change also represents a time when the AVRDUDE sources move from
my own private repository to a public repository. This will give
other developers a chance to port AVRDUDE to other platforms and
extend its functionality to support additional programming hardware,
etc.
So goodbye AVRPROG, welcome AVRDUDE!
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@170 81a1dc3b-b13d-400b-aceb-764788c761c2
"non-paged" parts. Take advantage of that and use the faster internal
routines of the STK500 for those parts as well.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@162 81a1dc3b-b13d-400b-aceb-764788c761c2
supports paged reads and writes. This greatly decreases the
program/verify time from about 4.5 minutes down to about 10 seconds in
a 12K program size test case.
Print out the hardware and firmware version for the STK500 if verbose
is enabled.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@161 81a1dc3b-b13d-400b-aceb-764788c761c2
that programmers other than the direct parallel port connection can be
supported.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk/avrdude@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/avrdude@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/avrdude@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/avrdude@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/avrdude@144 81a1dc3b-b13d-400b-aceb-764788c761c2
Brian S. Dean