A programming cable for the Atmel microcontroller is very simple. We just need 3 pins that we can toggle between 0V and 5V, and 1 pin that we can read. In addition, we have a ground reference.
Parallel port cable
We can do this directly from a parallel port - this just involves connecting the right pins on the parallel port to the right pins on the Mini:
My implementation:
The above design is taken from here. The tool we use for programming, AVRDude, calls this design dapa.
Serial port cable
We can use the control signals from a serial port similarly (reset=rts sck=dtr mosi=txd miso=cts). The serial port outputs +-12V, so we need a few zener diodes to transform this to 0V/5V[1]:
Schematic:
My version:
(bigger images attached)
AVRDude calls this design dasa. It also supports dasa2 and dasa3, which are similar, but with slightly different pinouts. dasa2 is reset=!txd sck=rts mosi=dtr miso=cts. dasa3 is reset=!dtr sck=rts mosi=txd miso=cts. I am including the design for dasa, since it is the only one I have used. The claim is that the dasa3 design may have better performance on some serial ports, since DTR was not designed to toggle quickly.
USB-to-serial and USB-to-parallel converters
It is possible to use dasa with a USB-to-serial converter, but the performance is very slow[2]. It is possible to use dapa with a USB-to-parallel converter, but the performance will be equally slow. In addition, I've heard the claim that some USB-to-parallel converters are meant solely to drive printers, and do not implement full parallel port functionality, and so would not work.
USBTiny programmer
The USBTiny is the simplest home-brew USB programming cable. It consists of an ATTiny2313 chip and a few passives, with the ATTiny2313 implementing USB in firmware. It is a very nice design, but slightly outside of USB spec, so may not work with all USB ports. In particular, it has been reported to have problems on Sony Vaio laptops. It also does not work on my Dell Inspiron XPS, although it does work if I use a USB hub between the Inspiron and the programmer. The claimed reason is that USB uses 3.3V signalling, whereas the Atmel uses 5V signaling, and while the USB spec guarantees that a device will not be damaged by 5V, the different signal levels give compatibility problems. People have reported successfully fixing this using zener diodes to level-shift the signals.
The basic schematic is:
To use this programmer under GNU/Linux, grab AVRDude 5.1 and USBTiny 1.3 (both are attached to this page). Placing both in a common directory, run:
tar xfvz avrdude-5.1.tar.gz
tar xfvz usbtiny-1.3.tar.gz
patch -p0 -i usbtiny-1.3/patches/avrdude-5.1.diff
cd avrdude-5.1
./configure
make
make install
cd usbtiny-1.3/spi
make
Assuming the ATTiny2313 is connected to be programmed with the serial cable from above, program it using:
avrdude -pt2313 -c dasa -P /dev/ttyUSB1 -U flash:w:main.hex
avrdude -pt2313 -c dasa -P /dev/ttyUSB1 -U lfuse:w:0xff:m
Put the ATTiny2313 in the USBTiny circuit. I tested mine with this command:
./avrdude -pm48 -c usbtiny -C ~pmitros/ilab/mini/usbtiny/avrdude-5.1/avrdude.conf -U hfuse:r:high.hex:i
As of the time of this writing, I have not done much testing on it. It does successfully program the Mini going through a USB hub.
Other USB cables
There are a few more USB cable designs
- A more complex one uses a USB-to-serial converter chip. I have not used this one either. This one has two advantages over the simple one above (which probably do not make up for the added complexity):
- The hardware design is similar to the Mini, so with this guy's firmware, it may be possible to use one Mini board to program another
- It implements the full STK500 spec, so it is possible to do things like timer calibations
- It uses a proper USB controller, so will work with any USB port
- In addition, Atmel makes the AVRATAVRIPSMKII programming cable, available from Digikey. It's fairly inexpensive (~$30), and works quite well. It uses a 6-pin header (Atmel's standard) instead of the 5 pin header we use (standard on hobbyist boards)[3]. The 6th pin takes VCC, which we need to run from the main header. I've used this to program the Mini. I just ran 5 hookup wires from the plug on the MKII to the header on the Mini, and so that I wouldn't forget the configuration, I put hot glue around the wires. The sixth wire goes to the VCC pin on the Mini:
Footnotes
1. We actually only need the zener diode clipping circuit on the output pins of the serial port. I usually place them on all the pins so that I can't accidentally damage something in the case of a wiring error. One could do this with the ground connection as well.
2. USB is moderately high latency (the numbers I've seen for low latency USB devices are order of magnitude is 1-30 ms, depending on device). Assuming AVRDude waits for each operation to finish before the next one, sending one bit requires 3 bit flips (3-90 ms). Sending one byte requires 24 bit flips (24-720ms). This gives ballpark of 1-42 bytes/second. What I saw when using a dasa cable with a USB-to-serial converter (5 bytes/second) was close to the middle of that, so I believe that was my problem. The adapter uses an FTDI USB-to-serial chip, most of which are designed to also be able to bit bang with the RS232 control pins, so I doubt choice of dasa lines was the problem - it ought to be able to flip all of them comparably quickly. The same dasa adapter worked at normal speed when it used an actual motherboard with a serial port.
3. There are 3 standard programming headers. Most hobbyist projects use a 5-pin, 1 row header like the one that we use. 1 row is convenient, since it also fits in protoboards, and in addition, the pins are in the same order as on the microcontroller, so it is easy to wire. This has 4 programming pins and ground. Atmel has an official header that has 6 pins in 2 rows: the four programming pins, power and ground. 2 row connectors do not interface nicely into protoboards. Atmel also has a 10 pin header, that adds more grounds, and an unconnected wire. I don't know if the additional grounds have any purpose – they provide better shielding, but I given the low speeds, I'd be surprised if that was an issue.