* ppi.c: Include system dependant parallel port interface file.
(ppi_open): Add call to ppi_claim().
(ppi_close): Add call to ppi_release().
* ppi.h: Define ppi_claim() and ppi_release() as NOPs if not previously
defined.
* stk500.c: Include inttypes header to quell compiler warning.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@184 81a1dc3b-b13d-400b-aceb-764788c761c2
care, bison does, and this is normally the way it's meant to be
anyway.
git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@182 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@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@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@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@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@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@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@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
Theodore A. Roth
Joerg Wunsch
Brian S. Dean