Parallel AVR programmer

This programmer is designed to program Atmel AVR microcontrollers in either parallel or serial mode, while connected to a host machine using RS232.

It's controlled by an 8051 (actually developed using a Dallas DS5000) and should work with most variants, since it doesn't use any special features. I hope it won't be too difficult to modify for use with an 8031 (external ROM) or one of Don's DT103 Simmsticks.

Functionality

The programmer follows the recommendations of Atmel's AVR910 application note and should support 1200C, 1200D and 8515A. It does NOT yet support the 8252. I don't know what the difference is between the 1200C and 1200D, but I treat them both the same, as does the AVR910 programmer.

It has been (slightly) tested on an AT90S1200A-16PC and an AT90S8515-8PC, using Jon Anders Haugum's avrp programmer driver for Linux and Atmel's aprogwin under MS-Windows 95.

This design is far from finished - although it works for me as presented, there are various changes I want to make to both hardware and software. It would probably be a bad idea to spend a lot of time designing a PCB for it in this form.

There are absolutely no guarantees regarding the fitness of this programmer for purpose : if it doesn't work, you have the software and the circuit - fix it. But please tell me what you fixed. Suggestions for improvements are welcome and will be dealt with in my copious free time.

E&OE, YMMV, etc. etc.

Interfaces

The programmer currently runs only Atmel's programming protocol at 19200baud. However, it was originally intended to be driven using the Kermit protocol and only changed when Jon released avrp. It is still my intention to complete the Kermit interface, as I feel it's a more reliable way to drive a serial stream than Atmel's protocol. However, I'll continue to support the Atmel protocol interface.

AVRs are connected to the programmer through ZIF sockets (one 40 pin and one 20 pin). It's obvious that the serial interface can be brought out for in-system programming (and there wouldn't be a lot of point in having it without such a connection) but this needs to be used carefully at present as it's 5V only and might damage a 3V target system. I intend to buffer this interface to make it safer before I use it much.

Note that Atmel suggest that a serial / parallel programmer should operate in parallel mode when addressed using their protocol and make no suggestions as to how serial mode should be selected. This programmer starts in parallel mode but may be switched into serial mode with the command string 'mSS', or back into parallel mode with 'mPP'. Since this feature doesn't conform to the Atmel spec, it may well have to be removed : I don't recomend that driver software should be changed to make any use of it. Create a script for your favourite comms program if you want to use this option.

Hardware

Hardware is fairly minimal, but unfortunately, hardware documentation is at the moment especially poor. I may do a PCB design, but it might be easier to use a DT103 Simmstick and whatever else is needed to provide RS232 etc.

My prototype is handwired on groundplane matrix board and the complexity is well within the scope of this method : the components are an 8751, crystal, MAX232, power supply, a TL431 regulator and a handful of discrete components. In the short term, I'll describe this circuitry with a few tables and ASCII diagrams : eventually, I hope I'll add a PostScript circuit diagram.

Connections from 8051 to programmer hardware (standard 8051 connections such as power, ground, reset, xtal are not listed). Various bits of the source code assume that an 11.0592MHz processor crystal is used - the critical parts are in the uart and timer setup areas, and most of the timeouts defined in the programming spec rely on these - but there may be odd exceptions, especially if you use one of the really fast (reduced-clock-division) 8051 replacements.

8051 pin                    Target 20 pin socket  Target 40 pin socket

1  P1.0                     12  pb0               1  pb0
2  P1.1                     13  pb1               2  pb1
3  P1.2                     14  pb2               3  pb2
4  P1.3                     15  pb3               4  pb3
5  P1.4                     16  pb4               5  pb4
6  P1.5                     17  pb5/mosi          6  pb5/mosi
7  P1.6                     18  pb6/miso          7  pb6/miso
8  P1.7                     19  pb7/sck           8  pb7/sck

10 P3.0 RXD   (rs232 input driver  - MAX232 or similar)
11 P3.1 TXD   (rs232 output driver - MAX232 or similar)
12 P3.2                     3   rdy/bsy           11 rdy/bsy
13 P3.3                     5   xtal1             19 xtal1
14 P3.4       (set low to enable VPP/reset supply)
15 P3.5       (set low : Vpp = 12V; set high : Vpp = 5V)
16 P3.6       (reserved for use as a write line)
17 P3.7       (set low to enable 5V VDD supply)

21 P2.0                     6  oe                 12 oe
22 P2.1                     7  wr                 13 wr
23 P2.2                     8  bs                 14 bs
24 P2.3                     9  xa0                15 xa0
25 P2.4                     11 xa1                16 xa1

The VDD control only needs to provide a 5V supply when P3.7 is at 0V - I wired it like this :

                     2n3906
  5V supply ----+-----e   c-------+----- 47R ----------- To Vdd
                |       b         |           20-pin skt pin 20
               10k      |         27k         40-pin skt pin 40
                |       |         |
  P3.7 ---------+--10k--+         |
                                  |      +-------------- To Gnd
                                  |      |    20-pin skt pin 10
                                  |      |    40-pin skt pin 20
                                  |      |
                                 gnd    gnd

The VPP control should be

0v when P3.4 is high,
5V when P3.4 is low and P3.5 is high,
12V when P3.4 is low and P3.5 is low.

                       2n3904
15V supply ---+-------c   e----+------+----+-- 47R -- To Vpp / rst
              |         b      |      |    |
             1k2        |     100p   27k   |     20-pin skt pin 1
              |         |      |      |    |     40-pin skt pin 9
              +---------+      +------+    |
              |         |             |    |
              c         c             |    |
P3.4 --10k--b     TL431   r----+------+    |
              e         a      |      |    |
      2n3904  |         |      |     27k   1k
              |         |      |      |    |
              |         |      |      |    |
             gnd       gnd     |     gnd  gnd
                               |
                    +---15k----+
         1n914      |          |
P3.5 ----------|<|--+-- 15k ---+

Almost none of the above components are critical : they're selected on the basis of what was in my junkbox. The only exceptions are the ratios of the resistors (27k and 7k5) around the TL431, which set the 5V and 12V levels. This circuit will provide a more accurate 5V level than it does a 12V level, but neither appears to be particularly fussy. (A TL431 is a shunt regulator which acts to maintain 2.5V at it's reference terminal .. a zener with an external feedback loop.)

Software

Sources for the programmer can be found here, or you can just take the Intel hex file. It was assembled using Alfred Arnold's ASL assembler under Linux. This assembler is also available in an MS-DOS version.

Intellectual Property Rights

I retain the copyright to this design, but permit it to be used for any commercial or non-commercial purpose provided that my copyright notice remains in the code and that no more restrictive copyright conditions are applied by the user in respect of any parts of this design that are copied. Any changes made to the design and submitted to me for inclusion in this archive should expect redistribution to be made under similar conditions.

Wishlist

Kermit interface: The kermit protocol module is working and now only needs to be interfaced to the programming module. This will initially be set up to accept binary files only : it may be possible to transfer text files (e.g. Intel hex and Atmel's "generic format") later. The most irritating difficulty in implementing a proper comms protocol is the shortage of RAM on the 8051 : with only 128 bytes, you can't have a decently sized packet buffer. One of the nice features about Kermit is that it will negotiate packet buffer size, allowing me to have a safe buffer limit of only 64 bytes and the possibility of shrinking it still further if I need the space. This limit could also be increased on an 8052 or similar.
Alternate hardware: The DT103 hardware provides for PWM rather than linear control of Vpp. This is quite a nice idea, especially if I extend the project to cover devices that need different programming voltages as the scheme I've used quickly becomes cumbersome. I'd prefer though, to use software PWM to avoid having to use a specific 8051 variant, and this will mean a fairly low modulation rate with consequent long settling times when the voltage is changed. I'll have a play with this, but don't yet know whether I'll complete it. I tried to use port bits that would suit the DT103 usage, but didn't take any notice of the simmstick motherboard requirements. A simmstick design might need a new motherboard anyway, to provide for the necessary ZIF sockets. Someone with more experience of Simmsticks might like to advise me here ..; A problem with any controller-based design like this is that you can't build it unless you can program the microcontroller. One way to avoid this is to use a controller which can itself be loaded by a much simpler serial method : another possibility is to use an external EPROM. The use of port pins on this design is such that an external EPROM could be used, with the loss of port 2. The controls I've connected to port 2 are therefore chosen to be fairly easy to replicate on an external latch, and this is why I've kept the 8051 /WR pin free rather than using it to control VDD (as it does on the DT103).
Other targets: As well as supporting additional AVRs as they become available (which I hope will be trivial, since they're intended to have a common interface) I hope to support a small number of other controllers too - notably Atmel's other flash parts (including the 82S52 and 89C2051) and if possible traditional 8051 CMOS and NMOS controllers.
Feeping Creaturism: This programmer is sadly lacking in flashing lights, switches, buzzers, hooters, selftest routines etc. These shortfalls may well be addressed at some point (especially the flashing lights).

Other AVR programmers

There are several other AVR programmer designs available : some commercial and some free (or partially free). Most use the PC parallel port to drive the AVR in serial programming mode and hence cannot write to the fuses controlling serial programming and RC oscillator. These low-cost programmers also tend to rely on MS-DOS or MS-Windows specific software. If you want a minimal cost solution, you should probably use one of these designs instead of this one.

Jerry Meng's programmer is very, very cheap to make (no active components) but I can't find any source code for it.

Steve Bolt's programmer is a little more complicated but does include sources. (This site has some very interesting robotics stuff too ..)

Elektor magazine for December 1997 has an interesting variation - serial programming via the serial port. It uses DTR to drive RESET, RTS and CTS for data and TXD for serial clock. The article is incomplete, since you have to purchase the software on a floppy (and the magazine is already overpriced) but it's a neat idea and probably not too difficult to finish off ...

There are some AT89C2051 programmer designs around that use additional ciruitry to execute parallel-mode programming without the use of a microcontroller - these might be adapted for use with the AVR. I believe it may also be possible to drive only a subset of the parallel programming lines to execute the 'write fuses' command, while executing serial programming commands for the remainder. This might be a method of making a low-cost programmer that can configure the fuses, but I haven't tested the idea and I don't know of any existing designs that do this.

Contact me

I'd be delighted to hear from anyone using this design in similar or modified form, or just to discuss alternatives. Send me mail at fangorn-webmaster@ntlworld.com.

Please note that spam (unsolicited advertising matter) is not welcome and will incur an unspecified processing charge dependent on the cost of recovery. Any such mail sent to this address acknowledges acceptance of these conditions.