This design is shown for 'historic' reasons only.
Wisp628 is an up-to-date Wisp-like programmer, based on the 16f628.
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.
highlights
WISP's highlights are: - it is an
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.
To use WISP as a production programmer, it must be calibrated. This requires only the WISP tool, a multimeter and some patience.
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.
hardware
The WISP hardware consists of
- a variable power supply (CON1, B1, IC1, R9-R15)
- a charge pump which creates the 12-14V programming enable voltage (lower right part: D3-D5, C4-C5)
- a PIC which controls it all (IC2)
- a target connector and a few resistors which provide some protection against wrong connections (lower left part: CON4, R3-R5, D2)
- a
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:
- just a 33k to Vdd (might not work when the Vdd switches on slowly)
- an RC plus diode (as proposed in Microchip's in-circuit programming guide)
Three notes about the schematic:
- The pin number of the DB9 connectors is WRONG: 5 should be 1, 4 should be unused etc. Sorry, I don't have the time right now to correct this (thanks Rob).
- With some computers a lower value of R2 is reqiured to get a good low level on the RS232 to the computer. A value of 560 ohm is reported to work well (thanks Angelos).
- The power distribution has fried my main board, so it might not be a good idea and I removed it from WBus. Leave out the connection between the positive side of C1 and the D9 connectors (on the PCB it is a wire, not a PCB trace).
firmware
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.
protocol
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:
- uses only GND, RxD, TxD;
- the timing of the programming process does not depend on the timing of the serial communication;
- the voltage levels can be low because the serial lines do not deliver power to WISP (actually the levels provided by WISP are way below RS-232 spec, but this is usually not a problem).
software
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.
downloading
Besides the html files the following is available for downloading: - the WISP firmware
targets
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:
- 16c84, 16f84, 16f84a
- 16f627, 16f628
- 16f870, 16f871, 16f872, 16f873, 16f874, 16f876, 16f877
rationale
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:
- on my Pentium2 machine assemble the source (using MPASM) and copy the hex file to a floppy;
- on my 486 machine close the wterm used in the previous cycle;
- start a DOS box with com84 and pip02;
- read the hex file from the floppy into pip02;
- remove the Xtal from the breadboard;
- connect the 486's rs232 line to the programming interface;
- program the 16f84 from pip02;
- exit pip02, remove com84 and close the DOS box
- connect the 486's rs232 line to the PIC serial lines;
- put the Xtal back in the target circuit;
- launch wterm to identify the next bug.
The reasons for this elaborate development cycle are:
- I can not program directly from the P2 machine, because pip02/com84 won't work (not even when I boot from a DOS flop).
- I don't want to run MPASM on the 486 because it is way too slow. (I guess that's partially my fault: I use an awfull lot of macro's.)
- I have only one free serial line on the 486.
- I can't connect the 486 and the P2 to the PIC circuit at the same time (ground loops or something like that).
- The programming does not work while the Xtal is in place. I guess I that's because I use a separate power supply instead of deriving the power from the rs232 lines like I should. But I don't want to take the 16f84 out each time I program it, and the serial line can not power my whole target circuit.
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.
