Development System for the ancient Microchip PIC16F57 CPU

 

Microchip PICkit 2 Programmer with target system

The Microchip PIC16F57 is an ancient CPU, long superceded and only grudgingly sold by Microchip Inc. Indeed there is currently a 2-month wait for them. It has a tiny 2K word program memory and a microscopic 72 bytes RAM. Too small to use with C, To program it, you would need assembly language. Why would I want to waste time on something like that? 

I have a remote gate opener ('autogate') which I tinker with unmercifully. It is also underneath an powerhead mains power pole which seems to get struck by lightning a few times a year, so over the years I accumulated a stack of dead S-1 controller boards which I usually repair and reuse. Except for those few which had dead CPUs.

S-1 Autogate Controller Board

Now they are cheap enough: RM100 (USD25) will buy you one online. But repairing these last boards meant replacing the CPU, which meant writing the program for it. After some effort, I noticed that the CPU footprint is an exact match for the Microchip PIC16F57, and I even have one in my CPU tray.

Writing the program also means I can upgrade the CPU to a newer one, and maybe add WiFi connectivity as well. And since the Chinese can sell me the board cheaper than I can make it, it does not make sense to make my own PCB. To upgrade it I would first have to replicate its functions, and that means writing the program from scratch.

But before I can even do that I have to find an Assembler, device programmer and build a little target system (PIC16F57 CPU board) just to make sure the toolchain works.

Microchip's MPLAB Version 8.33 (an equally ancient version running on Microsoft Windows XP) works for me. It comes with the MPASM assembler which happened to support the PIC16F57. You can try your luck with the latest and greatest MPLAB, but if it does not work out, you can get Version 8.33 from the Microchip MPLAB archive. I run a Windows XP image from a Qemu-KVM virtual machine and use pk2cmd with my PICkit 2 programmer, but you will probably be quicker off the mark with a Windows XP laptop.

The next thing you need is a little PIC16F57 (ie target) board just to accept the PICkit 2 connector and also run a small test program.  

PIC16F57 target system

Then you need the test program which you feed into your MPLAB assembler and produce the hex file the PICkit 2 needs to program the CPU. Usually you can find such sample programs in the great wide Internet but for some reason, not for the PIC16F57. You can find the schematics, hex file and source code here in my github repository.

To program the PIC16F57 I use:

$./pk2cmd -PPIC16F57 -Fledblink.hex -M

To run it I use:

$./pk2cmd -PPIC16F57 -GC -T -R

Some notes of caution: my experience is a Microchip CPU in a new target system can be hard to start. The combination of your choice of oscillator affects the Power-on Reset Timer delay. The MCLR reset circuit also changes things. You also need to sort out you Reset and Watchdog Timer vectors without which you program will not start. Once you get past that it is usually plain sailing. Using a Microchip Development Kit makes real sense here, but they have long since abandoned the PIC16F57. Also having a known good toy program helps when you are trying to start the CPU.

Despite having only 2K the PIC16F57's memory is also segmented. The simplest way is to ensure the program sits within page zero 000-1FF. This is because subroutines calls only work within page 0. You can next just 2 levels of subroutines.

Lastly the digital output pins are set and cleared (ie BSF and BCF) using a Read-Modify-Write mechanism. This means the CPU does not keep a record (ie a register) of your IO bits. It also accesses IO 8 bits at a time and if it executes a write, it will first read the whole byte from the external circuits, modify the read data and writes back the 8 bits. This can have unexpected effects if you are not running within the electrical operating limits (ie driving too much current into an LED). Also a CPU IO write followed immediately by a read may execute too fast for the external circuit.

The RC system clock circuit is a little hard to time accurately because of its inherent inaccuracy and component tolerances. If your LED does not blink, you might need to adjust the delay intervals. If that fails, seek to dim the LED rather than blink it.

This is a hard-core RISC instruction set, running in a Harvard Architecture (ie program and data busses are separate). There is usually no substitute to reading every single word in the datasheet.

If this is your first time with assembly language, congratulations. You have talked to a CPU in its own language, mano a silicona, and it understood you. 

Good Luck, and Happy Trails.