Nov 2007: Rev 2.3

New firmware supports JTAG IO speed selection (1MHz to 4kHz). This firmware is required for software version 1.2.

May 2007: Rev 2.2 (16MHz clock)

There's a new firmware after one year of development. This one requires 16MHz clock and works again faster; AVR flash read timings in "extreme" io_speed are up to 15kb/s (requires device to be programmed to run at 8MHz or above). JTAG IO is how 1.3us/bit, (450ns LOW and at least 480ns HIGH). Furthermore, the red LED displays programmer activity. Support for an additional RESET pin for OpenOCD was added. Old Rev 2.0 firmware discontinued.

May 2006: Rev 2.0

New firmware revision supports pipelining (i.e. it's again faster) and implements waveform command which allows programming of JTAG devices (like CPLDs). Old firmware discontinued.

Mar 2006: Rev 1.2

New firmware revision allows SPI clock speed selection (faster and slower modes than Rev 1.1; see the set io_speed command). Hence, you are no longer forced to run the device to be programmed with a frequency ot at least 1MHz (internal clock). Old firmware discontinued.

Jan 2006: Rev 1.1 (8MHz internal clock)

New firmware revision improves programming speed by a factor of 6 compared to Rev 1.0.

Jul 2005: Rev 1.0 (1MHz internal clock)

This is the initial release of the firmware and I've used the USB-AtmelPrg interface cable presented on these pages to successfully program an ATMega8515-based device.

The microcontroller inside the USB-AtmelPrg device runs a self-written firmware which communicates with the host computer using the FTDI SIO on the one hand and with a programmable device on the other hand. The firmware is written in C and compiled using free AVR-GCC.

The source code of the firmware is currently not publically available. I may decide to release it in the future, though.
However, I provide the firmware binary image to be programmed into the flash storage of the ATMega8 so that everybody can build and use the USB-AtmelPrg interface cable presented on these pages. (There's no EEPROM content required.)

This version should be run with a clock of 16MHz (I use an external crystal with two 15pF load capacitors as presented in the circuit schematic), hence you need to program the CKSEL fuses accordingly (fuseL=0b11101111=0xef).

You can skip this tech talk if not interested: The usual factory default for Atmel's AVR RISCs is to use the internal RC oscillator at 1MHz. Hence, it is assumed that the device to be programmed runs at a clock speed of at least 1MHz. Since most of these devices need serial clock LOW/HIGH times of at least 2 clock cycles (2us), and each byte to be read/written requires to transfer a 32bit command across the SPI wires, the theoretical maximum transfer rate is 7.8kb/sec (kb meaning 1024 bytes).

Since we must expect clocks to run at slightly different speeds, a 6.25% (125ns) safety margin is added to the SCK (serial clock) timings. Furthermore, there is some overhead talking to the USB and waiting for the host computer to supply the next data packet resulting in a measured net transfer rate of 4.55kb/sec (58% of the theoretical maximum) using the Rev 1.1 firmware. To decrease the effect of USB/host computer latency, pipelining (with 3 queued packets) was introduced in firmware Rev 2.0 further increasing transfer rate to 5.7kb/sec. This is 73% of the theoretical maximum. Rev 2.2 can further decrease USB overhead while retaining the same IO speed and achieves 6.2kb/sec (79%). Note that there are additional speed grades which can be used if the target runs fast enough ("fast": 10.5kb/sec, "extreme": 15.5kb/sec).

To summarize: The Rev 1.1 firmware (8MHz clock) is 6 times faster than the Rev 1.0 firmware (1MHz clock). The Rev 2.0 firmware (also 8MHz clock) is again 25% faster and Rev 2.2 adds another 10%. The theoretical maximum is another factor 1.23 more but since this is much smaller than 2 (i.e. we cannot double the speed any more), it is not worth the effort for additional throughput optimization.

Actually, data is read in chunks of 64 bytes which takes 9.5ms on the AVR RISC side (note: theoretical minimum 8.2ms without safety margin) and 1.6ms on the FTDI SIO side. Since the cycle time (buffer-to-buffer) was measured to be 13..15ms, most of the lost time is USB communication between FTDI SIO and host computer so the firmware is not to be blamed. Hence, you may measure different timings when using a different USB host controller in your computer. Changing usb_latency and busy_poll_usec using the programmer's set command may slightly increase the transfer rate.
Now, since firmware revision 2.0, pipelining is supported (pipeline size of 3 packets) thereby decreasing the effective buffer-to-buffer cycle rate and increasing the transfer rate from 4.55kb/sec (Rev 1.1 firmware without pipelining) to 5.7kb/sec.

Remember: The current firmware (Rev 2.2 and above) must be run at a frequency of 16MHz. Otherwise, SPI timings will be incorrect. You can run this firmware at any lower frequency but it will be painfully slow (factor 16 when run at 1MHz!). It cannot be run at more than 16MHz since the SCK pulses will then be too short for a 1MHz controller (the one to be programmed). 16MHz is actually the highest allowed frequency for the applied ATMega8, so this is also a technical limit.

Since Rev 1.2, the firmware supports different IO speed selections, see the set io_speed command. (But you still need to run the ATMega8 at a frequency of 16MHz.) The above speed considerations are valid for the default ("normal") IO speed.

You can skip this tech talk if not interested: SVF file downloading initially took a minute for an XC9572XL, so I decided to bundle several SVF commands into a waveform request which brought programming down to about 12 seconds. Then, after implementing pipelining (with a pipeline of 3 packets), time was further reduced to 6.7 seconds.

(The following refers to Rev. 2.1 firmware; Rev. 2.2 has 450ns LOW and at least 480ns HIGH and an average of 1.3us/bit during a burst.) The theoretical minimum time required to program such a CPLD is dominated by the sleep timings for erasing and flash writing (accumulated: 2761msec for a XC9572XL erase, program and verify SVF file) and lies somewhere around 3 seconds. The waveform output code in the firmware will generate TCK pulses which are 375ns LOW and the rest of the time HIGH yielding a cycle time of 2.4 to 3.8us per bit with an average of 2.875us/bit. A complete waveform request has 256 bits and hence takes 736us. The current firmware can't run faster although the CPLD would have no problem if we went more quickly. However, there is no point in changing this since it does not at all dominate the timing; most of the time which is not spent waiting for flash operations is spent waiting for the USB: To make this evident: With a cycle time of 736us (see above) and FTDI IO operations added, the programmer needs less than 1ms per waveform request while the actual cycle time depends on the USB host controller and is somewhere between 4ms and 5ms for my setup. USB speed is no issue since the consumed USB bandwidth is below 35kb/s (a request has about 70 bytes and remember that the nibble IO requires to transrer 2 nibble-bytes per real byte) and each waveform request (140 real bytes) takes 3 USB-1.1 packets (max. 64 bytes per packet).

First, the EEPROM accessed by FT245BM USB-controller should be programmed using e.g. as explained here. The identification strings you put in there don't matter much, just make sure to get the important information right. This is what I am using:

EEPROM Content:
  vendor:          0x0403
  product:         0x6002
  self_powered:    1
  remote_wakeup:   1
  BM_type_chip:    1
  isochronous:     in: 0,  out: 0
  susp_pull_downs: 0
  use_serial:      0
  usb_version:     0,  change_usb_version: 0
  max_power:       250
  manufacturer:    "WieserLabs (06/2005)"
  product:         "USB-AtmelPrg"
  serial:          "Rev. 2/1"

Note that this information is meant to identify the interface cable's hardware, and not its firmware. The firmware identification is built statically into the firmware's flash image. Hence, "Rev. 2/1" denotes board layout revision 2/1.