GunFire - the GPL chip programmer software

Why and how the original GunProg project was started

The original intention was to make a universal programmer, ie. the hardware, which could program any chip. Software was obviously required to support this, but the hardware was the original intention.

Programmer hardware which supports any chip already exists - there are many of these available commercially. These beasts are expensive though, most still have DOS front ends, and there's no guarantee that they'll be kept up-to-date with new devices. The plan was to design some hardware which could be home-brewed relatively cheaply (I was aiming at sub-Ł100 for a 40-pin programmer, compared to commercial ones which start at Ł300 and go up from there), and then produce some open-source software which would control it, so anyone could add support for whatever devices they wanted just by writing a DLL.

I worked on the hardware for a year, on and off (more off than on, to be honest - maybe 6 months of a few evenings went into it). I got a lot of stuff worked out, but found that I really needed a bit of a rethink. So I thought I'd get going on the software instead. The software to talk to this was obviously needed anyway, so I'd have some code ready to talk to the hardware when I went back to doing the hardware.

I always knew I would be making the designs and code freely available. I decided I needed some better distribution method than just a personal website, and also maybe some method of maintaining an off-site backup in case of emergencies like a house fire. After investigating a bit, SourceForge seemed the natural choice for hosting the project. After some deliberation I chose the name GunProg as an abbreviation of "GPL universal programmer".

Feature creep

After I'd done some work on the software, I sat thinking about how to work adding support for new devices to the program. I then realised, "Wouldn't it be neat if I could use any programming hardware with this software? After all, the programming algorithm for a device never changes, all that needs to change is the driver software to run the programmer." Everyone who designs a chip programmer (and there are many PIC programmers out there!) invariably writes their own software. Everyone reinvents the wheel on the programming algorithm and the user interface, just in order to drive the programmer hardware. As an engineer, the waste of time in this is overwhelming.

If devices could be added as DLLs, so could programmers. Obvious really. Then the program would need to have some way of checking between the two, to make sure that the programmer can do everything that the device requests of it. That's where it started to get more tricky, but in general I thought (and still think! :-) this was a very workable idea.

The start of the GunFire project

With the change in direction, the software no longer really fitted within the goals of the GunProg project. To avoid having GunProg heading in two different (and conflicting) directions, I decided it would be more logical to split the whole thing in half. GunProg would remain the project for the programmer hardware, whilst the new project would cover the generic programming software. I knew the new project had to partially inherit its name from the old project, so I decided on the name "GunFire". I felt this was a good dynamic name, and it sounded right to me. Nuff said.

Interesting concepts for GunFire

One concept I came up with which I've never seen before is the "adaptor" idea. An adaptor sits between the device and the programmer. Generally these would be things like cables between an in-circuit programming setup and the programmer, but they could also have extra functionality such as switches, etc. The device and programmer have to check whether the facilities the device requires can be met by the programmer, and if not, you can't program that device. With an adaptor, you could kludge some add-on to the programmer (eg. an expansion board), and it would now support the device. And for coding, you'd only have to write code to support the new hardware, you wouldn't have to write code for the programmer as well.

I also plan on allowing a device to be programmed by more than one programmer. An adaptor can be used to handle the fan-out of pins to the correct places. You could then for example use the PC serial port and parallel port simultaneously to program a device; the serial port would be one "programmer" and the parallel port would be a second "programmer".

From the start, this was intended to be cross-platform. I don't have any Linux experience and my PC is only set up with Win98, so the initial version will be Windows-only. However I've designed everything with porting in mind, so the changeover should be as painless as possible - the only stuff to change will be the low-level code which accesses OS-specific or machine-specific functions.

I'll probably be using the wxWindows toolkit to build a cross-platform user interface, unless someone persuades me that some other cross-platform toolkit is better. Conversations on SlashDot with people who've used both suggested that Qt was a better choice, but Trolltech no longer offer a free Windows version of the Qt toolkit, so wxWindows is the leading alternative. I don't really care so long as it's easy to use, is free (as in beer) and seems to work. The main requirement is just that the toolkit must be cross-platform, because I don't intend to write this separately for every platform. This obviously rules out Windows-only toolkits such as MFC.