USB Programmer for AVR Microcontrollers version 1.0 (uavrp-1.0)

1. Why in the world?

I created custom hardware to program AVR microcontrollers over USB.
Originally I patched avrdude, but now I've written my own.  The
advantage of uavrp is that it runs on Windows and Unix, and that it
interfaces to my harware.

1.1. What can't it do?

It's really a stretch to call this release 1.0.  It has only been tested
programming the data space on an atmega16.  There aren't definitions
for most AVR parts.  Timings are wrong.  Etc.

2. Requirements

Python 2.2 or better, USB ports, libusb on Linux (libusb-win32 is
included in for Windows users)

3. Installation

3.1 Linux

First run "setup.py install" as root.  Then, in the file
/etc/hotplub/usb.usermap, copy the first non-comment line and change the
third and fourth fields to 0x03eb 0x0002.  Be careful to preserve the
format of the file.

Now, plug the programmer in, attach it to a part you don't care about,
and run
	$ uavrp-program.py
your part should be detected and erased, followed by an error about the
argument list (because no firmware was listed on the commandline)


3.2 Windows

Double click the installer and follow the directions onscreen.
Then plug in the programmer.  Install the driver located under the
Python directory, for example
	C:\python23\uavrp-driver\uavrp.inf

Now, attach the programmer to a part you don't care about and run
	C:\> uavrp-program
your part should be detected and erased, followed by an error about the
argument list (because no firmware was listed on the commandline)

4. Usage

uavrp currently only programs firmware, not eeprom.  Definitions for
only 2 parts (at90s2313, atmega16) exist, and only one has been tested.
(atmega16).

uavrp-program's only argument is an "ihex"-format image to be programmed
on the attached device.

5. Adding a new part

Support for a new part is added by creating a new class in
site-packages/uavrp.py.  A new part inherits from Programmer and a
number of other classes that describe the part (is the program memory
banked or unbanked?  Are there fuse bits?  Are there lock bits?) and
adds data to describe characteristics such as the format of the various
SPI packets, part signature and memory sizes.

A Template is constructed from a 32-bit hex number, followed by a list
of zero or more input parameters given as a bit shift and a bit mask,
followed by the output parameter given as a bit shift and a bit mask.
This is different to the way Atmel's documentation describes things.
 Template.fromstr() is a factory method which takes a specification
from the datasheets (such as "0010 1000 xxxx xxaa bbbb bbbb oooo oooo")
and creates a Template from it, with the following assumptions:
    * "aa" and "bb" should be taken together to specify the first
      argument in the template
    * "x" is treated as 0
    * "o" is the location of the output parameter (read from avr)
    * "i" is the location of the input parameter (written to avr)
"aa...bb", "o", and "i" must each be contiguous.  "H" must be turned into a
pair of Templates, XX_hi and XX_lo.

Example:
	class At90s2313(Programmer, unbanked_memory, unbanked_eeprom):
	    signature = 0x1e9101
	    read_program_lo = Template(0x20000000, [(8, 0x3ff)])
	    read_program_hi = Template(0x28000000, [(8, 0x3ff)])
	    
	    write_program_lo = Template(0x40000000, [(8, 0x3ff), (0, 0xff)])
	    write_program_hi = Template(0x48000000, [(8, 0x3ff), (0, 0xff)])

	    read_eeprom = Template(0xa0000000, [(8, 0x7f)])
	    write_eeprom = Template(0xc0000000, [(8, 0x7f)])

	    write_lock = Template(0xace00000, [(17, 0x3)])

	    chip_erase = Template(0xac800000) 

6. Future

Fixing the warnings printed by python2.3! (about unsigned ints becoming longs)

Obvious stuff, like reading flash, reading/writing firmware, lock bits
and fuse bits.  Getting the timing right, not just "good enough to
program my devices".  Supporting more devices.

Less obvious stuff, like "SPI16" to program 4 bytes at once, as a
speedup (since usb latency seems to be the biggest time suck)