USB-AtmelPrg: Interface Cable Firmware
Firmware for USB-AtmelPrg Interface Cable (16MHz Version)
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.
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).
SPI: Speed and Timing Considerations
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.
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.
JTAG: Speed and Timing Considerations
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).
Configuring the USB Controller (FTDI SIO)
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.