WISP : Wouter's In - System flash PIC Programmer

This design is shown for 'historic' reasons only.
Wisp648 is an up-to-date Wisp-like programmer, based on the 16F648A.

According to Marten Toonder, a dutch author of fairy-tale-like cartoon stories, a wisp is a special kind of wasp. The sting of a wisp makes the unfortunate receiver tell only the truth while the pain lasts.


WISP's highlights are:

WISP is an in-system (also called in-circuit) programmer, so WISP is connected directly to a system which contains the 16f84 which is to be programmed. The target circuit must be compatible with the WISP programmer. There is no need to remove the 16f84 from the target circuit, it could even be soldered permanently. A simple 4 or 5 wire connection to the target is sufficient.

WISP supports a rapid development cycle: without even touching the target hardware you can program the target, reset and start it, and communicate with it.

WISP is a production programmer because it can set the voltage at which it verifies the correct programming. The distinction between a production programmer and a prototype programmer is that a production programmer must be able to verify the correct programming (check the content of the program memory) at the extremes of the Vcc which will be used in the application. This is more relevant for the EPROM-based PIC than for the EEPROM/FLASH-based PICs that WISP can program.

To use WISP as a production programmer, it must be calibrated. This requires only the WISP tool, a multimeter and some patience.

WISP can either take its power from the target circuit, in which case a stable 5V @ 100mA must be available from the target PICs pins, or it can deliver power to the target (via the same pins). In the latter case a wall-mounted transformer must be plugged into the WISP. In both cases the voltage which is needed to enable programming on the 16f84 (12-14V) is created from the 5V by a charge pump. When the target delivers the power, WISP can not control the voltage, hence in this case it can not be used as a production programmer.

WISP uses a serial interface with a simple protocol. The timing of the communication does not affect the programming process.

WISP provides a serial passthrough which is usefull when you want to communicate with your target system. The same serial line which is connected to WISP can be passed on to the target system's lines RB6 + RB7. The passthrough is implemented in software, so it is limited to baudrates of 19k2 and lower.


The WISP hardware consists of

A full bridge rectifies whatever is supplied on the power connector. The result is shared via WBus (CON2-3) pin 1. C1 must be able to withstand 40V (20V AC on the power plug, plus some margin). Without intervention from the PIC (RB4-RB7 are inputs) R13-R15 cause a 5V voltage at IC1 pin 2. Various other voltages can be created by assigning the pins RB4-RB7 to input, high or low (4^3 = 81 combinations). The relation between the PIC RB4-RB7 setting and the resulting voltage is too complex to predict, even with 1% resistors, so the PIC's EEPROM is used to store the RB4-RB7 settings used for the various usefull voltages (4.0V - 6.0V is steps of 0.1V).

While programminging the charge pump is exercised at around 100KHz by PIC pins RB2 and RB3. It produces a Vpp of 3 times Vdd minus 3 diode drops. While sending or receiving a character the PIC firmware does not operate the charge pump. Capacitor C6 bridges these periods (one character at 19k2 = 500uS).

The PIC uses a standard 10MHz Xtal with accompanying capacitors. The 'reset circuit' R7 is simple but compatible with the WISP requirements, so a WISP can program the PIC in another WISP. The LED D6 can be switched on and off by the PIC to give some feedback to the user.

The target connector CON4 provides the ground and the three programming lines (to be connected to RA3, RA4 and MCLR). The resistors offer some protection against wrong connections. PIC pin RA4 (open drain) is used to control the target's MCLR line. R6 makes it possible to load C6, pull RA4 low to reset the target, and then let RA4 float to get the target in programming mode using the remaining charge in C6. To get the target in run mode RA4 is pulled down long enough to discharge C6 (to Vdd minus three diode drops), and then RA4 is floated. The reset circuit in the target should then keep the MCLR pin high enough.

The target connector also provides a Vdd connection. This can be used to power the target from WISP or to power WISP from the target.

This picture shows the first WISP on a PCB. It is an older version which could not control the target's Vcc (7805 instead of LM317). The connections to the left ar the WBus connections (in and out). To the right are the target connector and the power connector (not connected here: the target delivers the power). Note that the DB5 and DB9 connectors are of the cheapest variety. Only one row of these connectors is used, so they can be soldered directly to the copper side of the PCB.

I made the WISP schematic and PCB using the IVEX schematics and PCB software. I'm not sure I can recommend their software (it is very buggy), but in the end I did succeed and they offer a free version up to 100 pins. If you are going to use it, save your design very often!

A suitable connection between WISP and the target PIC can be made via a dedicated connector on the target circuit (for instance a berg header or an 8-pin DIL socket), or directly to the chip using a DIL test clip. The cable from WISP to the target should be not be too long. Half a meter worked fine for me.

This picture shows a PIC on a breadboard with the test clip on it. I could not get an 18-pin clip, so I used a 16-pin clip instead.

WISP must be able to drive the targets MCLR pin via a relatively high impedance (5k), up to the 14V programming voltage. This rules out direct use of a capacitor to time the reset. Some WISP compatible reset circuits are:

Three notes about the schematic:


The firmware (the software running on the 16f84) for WISP is available as hex file. The same file can be used for either a 16c84, a 16f84 or a 16f84A, each with a 10MHz Xtal. The sources are also available.


The WISP firmware supports a simple ASCII protocol, which adheres to the WBus definition. This makes it possible to connect a number of WISPs or other devices which adhere to this protocol to the same serial line.

Some knowledge of the WISP protocol might be needed when you want to port the existing WISP tool, create a new one, or simply want to test your WISP hardware using a terminal emulator. For a simple PC-to-WISP connection this requires only a 9-pin serial extension cable. Some WBus key features are:

This is great for laptops, non-dos systems etc. Due to the below-spec voltages WISP provides on the RS-232 lines it might be incompatible with some rs232 ports.


The WISP tool is a command-line program which can be used to control the WISP hardware. It is available as source or as executable for DOS/Windows. It is written in TurboPascal.

The XWisp tool is both a command-line and windows interface program which can also be used to control the WISP hardware. It is available as Python source. It will run on all kinds of Windows, but also on Linux and most other operation systems.

The WISP protocol is simple, so it should be possible to write your own host software. If you do so consider making it freely available and drop me an email so I can add a link to this page.


Besides the html files the following is available for downloading: NOTES on the PCB: the component side shows the diode bridge and the LED in a wrong orientation. The bridge + should be to the elco + and the round side of the LED should be towards the D15 connector. The LM317 is also shown wrong: the metal side should be towards the edge of the PCB, not towards the centre.


With suitable host PC software a WISP should be able to program all eeprom/flash based PICs. WISP can not be used to program OTP PICs because on those chips the 12-14V is used to power (not just enable) the programming, so much more current is needed that WISp can provide.

The currently supported target chips are:

To program a chip that has LVP capability (16f62x and 16f87x) it might be needed to tie the LVP pin (RB3 on 16f87x, RB4 on 16f62x) low (using for instance a 10k resistor).


There are plenty commercial and free 16f84 programmers available, so why did I create yet another one? One answer is 'just for the fun', the other is that I wanted a programmer which fits my special needs and I did not want to buy a commercial product.

I have succesfully used my own variant of the RS232-powered programmer for some time (three cheers for the abundance of free 16f84 hardware designs and support software!) but I grew tired of the (relatively) long development cycle. For me the steps were:

The reasons for this elaborate development cycle are:

So I decided to make my own programmer to shorten the development cycle. I had just bought a bunch of 16c84 chips so I used one of those and put the features in software (on the 16c84 and on the host machine) instead of using pure hardware which would possibly have been cheaper but certainly less flexible. I'm a software professional and only a hardware amateur and my scope (second hand HP, all tubes and germanium, 40 kilo!) had just died, so I felt more comfortable debugging software than hunting hardware bugs.

WISP has speeded up my development cycle tremendously: download-and-run takes about 10 seconds. The next step is to replace the slow and primitive MPLAB assembler by something better and faster, but that is a different project.


26-JUL-2001 2.00 (first use of this history section)
cleanup, mention other targets than 16x84