Embedded microprocessor development can seem to be an expensive task, requiring lot's of specialized equipment that is beyond the means of most amateurs. While developing with PIC [3] microprocessors can be expensive, it doesn't have to be. PIC development can be done with just a handful of parts: an EEPROM eraser, some kind of programming language and a low cost programmer. This is the exact list of equipment that I use as I don't have access to the specialized 'professional' equipment either, but I do develop many useful projects with PIC's [1-2].

WHY PIC'S?

PIC's are an enabling technology. All those logic, control, communication and display functions that our projects need can be reduced to a single chip that can be reconfigured at will! At the same time we are able to add features to our projects that make them even more professional and easy to operate.

The simplest, popular PIC's have 13 I/O pins, are contained in a single 18 pin package and only need an external clock for operation. The PIC is truly the 90's version of the venerable 555 timer.

Most of the PIC's you will be using are either FLASH EEPROM based or a windowed EPROM type. This means that they may be programmed over and over. In fact the legs break off my parts long before the write/erase cycle limit of the PIC is ever reached! In higher volume commercial applications the devices are available at a lower cost in the so called "One Time Programming" version. This version allows the code to be burned into the PIC only once. Obviously this "cheaper" device won't be cheaper to use when developing new code, but when the code is stable a commercial manufacturer may opt to use this device to reduce costs.

BASIC USES FOR PICS

I break PIC applications up into two overlapping categories,

1) Standalone applications, such as Code Keyers, ID modules, etc. These applications for PIC's use the device as a programmable logic array. That is the program that you write for the PIC may take the place of 100's of discrete logic gates. These types of projects usually stand by themselves and have simple user interfaces that might include an LCD (see sidebar: Simple project displays) and some user interaction switches. The two meter receiver [2] is an example of this type of application.

2) The other application category is using the PIC as a PC interface. Since the PIC can communicate easily using RS232 connections you can use the PIC as a sophisticated "programmable UART". This follows the trend in the electronics industry towards "Virtual Instruments", that is electronics equipment that does not have front panels, but rather a communications interface to a computer that processes the instruments data and displays the instruments "Virtual Front Panel Controls". The Personal Network Analyzer [1] is an example of this kind of project.

These two categories may overlap, as in my 2 meter receiver project [2]. This project uses the PIC to operate a user interface including LCD display, knobs and switches or when it detects the presence of an RS232 connection it operates like a virtual radio with a PC controlling the receiver operation.

 

PC CONTROL OF A VIRTUAL INSTRUMENT

The key to operating a virtual instrument is the program that runs on the PC. MSDOS was a simple environment to operate from, but the availability of DOS based development tools is nonexistent except for shareware now (or usedware). This leaves Windows, and the tools here are quite good. Visual Basic from Microsoft is an very reliable and useful development tool. You may be able to find someone's old copy of Visual Basic 3 for Windows 3.1 or 95 development or if you want to start with the latest 32 bit versions: use Visual Basic 5 or 6 for Windows 95/98 programming.

Since each PC based language uses it's own specific way of controlling the serial port, it's impractical to list them all here, but the serial port is a commonly supported communication method under DOS and Windows so it's a part of all these languages. Check the languages manuals or help files for more specific information.

For an example of the PIC code that controls a virtual instrument via RS232, visit my web page on the personal network analyzer project [7] and download the PIC source code file.

HOW TO PROGRAM A PIC

Programming a PIC is really no harder than writing a small program for a PC, the exact sequence of steps is different, but it's not difficult. If you want to program in assembly language, the tools are free from Microchip [3]. Programming in higher level languages like, BASIC and C may be accomplished with low cost (under $100) tools [4-5]. These higher level language tools are usually referred to as compilers because they take the high level statements and "Compile" them to processor specific machine language. I program my projects in C, which is a high level language that keeps the code 'close' to the hardware. This is the perfect language for a PIC as controlling hardware is the whole idea, however BASIC is also a viable language to use for amateur projects.

Once a program (in whatever language you have chosen) is written the assembler or compiler will generate a binary image of the target PIC's memory. This image file is usually called a HEX file, because it is in a format called the Intel HEX 8 format. You don't need to know the technical details of this format for successful application of the PIC. Microchip's tools produce this format so most of the low cost programmers available support it as do the compiler manufacturers, it's become the 'de-facto' standard for PIC's.

All you really need to know is how to load this image file to you programmer and download it into your PIC (usually an simple task).

DEBUGGING AN APPLICATION

Debugging is where the fun starts (and stops, sometimes). The need for debugging can arise for two basic reasons, 1) Because the program doesn't appear to work as you planned or 2) Because you think up different features to add to your hardware as you are writing the programs. Professionals may debug with expensive In Circuit Emulators (ICE systems for short) that allow stepping the code line by line while connected to the target hardware. While this is the most effective way to see how the program actually works from a time point of view, it is usually beyond the means of most amateurs in terms of cost.

I use a slightly less time effective method that is allot more friendly to the pocket book however. Most applications are best built in stages. Each stage adds a function and that function is fully tested before adding the next function. This way the possible problem areas are kept small. If the program stops working after a new stage is added then you know to look at the new stage first! Sometimes the problems can be found by observing the hardware and then looking at the source code again, more often than not you will spot an obvious error and be able to correct it.

In fact the programs for the 2 meter receiver project [2] were built exactly this way. In past projects I have used the LCD display, so I reused this already tested code and used it for displaying program output when testing the other hardware code (described below). I have also used the PIC's built in A/D converter and built-in RS232 UART, so these subroutines were reused. I had not used an interrupt driven rotary encoder before with a PIC, so I wrote some simple programs to experiment with how to best do this. I even used a 16C84 processor for this development because I had a breadboard already built up and wanted to reuse that also. When I had the encoder working correctly, I added the switch inputs and worked on debouncing routines and getting the RC networks connected to these switches correct.

When all the lower level hardware control routines were built up and tested I started to build the final application safe in the knowledge that when I said "Read A Debounced Switch" if the program didn't work I would know it was the main programs logic and not the previously written and tested sub routines. This is in fact my first method of developing PIC applications, "Work on the hardware control stuff in small increments" this will save time in the long run.

This leads us to my second method of debugging on a 'Shoestring' namely, "Keep five or so PIC's in the EEPROM eraser at all times". Doing this allows almost instantaneous "Write -- Compile -- Program -- Test" cycles to happen. Many times during development I may only work with a piece of code for a few minutes before I decide it needs improvement (sometimes it just, flat, doesn't run at all). Being able to immediately get another blank PIC to shove in the programmer socket keeps the development cycle short and productive (much like it is on a PC). This will also save time in the long run at the minor expense of having a few extra PIC's laying around.

My third and last debugging tip is to use an RS232 link to a PC during development, to show what is happening inside the PIC during program execution. In the early stages I usually use the LCD display (if the project has one) to show what is happening in the program. I write to the display much like you would use "Print" statements in BASIC to print the values of internal variables or just to print out where the program is while it's running. As I get further along in the program I have the display tied into the main program and it's not really convenient to use it for debugging anymore.

At this point I switch to using an RS232 link. All of the better programming languages have built in RS232 serial commands that can be used on PIC's with UART's and even those that don't. My compiler recognizes non-UART devices and, the compiler automatically adds software routines that perform the RS232 input and output. These software routines may take up a little of your code space but they really help debugging.

In it's simplest form the RS232 link only uses one PIC pin. The C compiler I use can configure any I/O pin for RS232 I/O and there is usually one pin available for debugging purposes. The PIC RS232 pin is connected to the PC's RS232 receive pin, a ground is added to connect the PC's ground to the PIC's an off we go. Using any terminal program (Windows or DOS, configured for the right number of bits and BAUD rate) data can be viewed from the PIC as the program executes. If you need to pause the program at various points an RS232 input can be added to another of the PIC's pins and this can be used to have the PIC wait until it receives a character typed on the terminal program [8].

Using RS232 for debugging really reinforces debugging tip #2, that is you will probably be making rapid changes to the program as you move debugging "print" statements around and you will want to keep your efficiency high. You won't want to wait for the device to erase before trying the next experiment. So keep plenty of PIC's roasting in the EEPROM Eraser at all times.

I'm not suggesting that you just keep hacking code until it seems to work! Even the most experienced professionals "Learn by doing". I'm only suggesting that to "learn more by doing more", that your debugging efficiency be kept high.

On your next project you can probably reuse much of the code that you developed for your previous projects and speed your development time even more. As I described above, that's how many of the pieces for my projects are developed.

WHICH PIC's?

At first there seem to be a bewildering array of PIC's to choose from. The choice of which PIC's to use may well start at what the language you want to use or what your programmer can support. I use 4 devices for all of my 'Fun-type' projects, this keeps my costs down and always ensures that I will have devices available when I need them. I use a Microchip PicStart programmer which is on the expensive side, but it can also be used to program all of the current devices. I use the Mid range 16C6x, 16F84 and 16C7x devices. I chose these 4 basic devices for the following reasons,

16F84 - A low cost 18 pin device with moderate memory (1k). This device is used for basic control applications that won't be large, need analog input (i.e. an A/D converter) or use allot of I/O pins (My website [6] shows several robots that my kid's and I have built with this device). This is the most popular 'Hobbyist' PIC of all time (an older device was called the 16C84). This device is based on Flash memory and does not need to be erased before it can be reprogrammed.

16C71 - Like the 16F84, but it also has a 4 channel, 8 bit A/D converter built in. This device is used where I need to get analog signals into the PIC for control applications (like the network analyzer published in the January and February 1998 issues of QST). The newest replacement to this device is called the 16C711.

16C63 - This device is in a 28 pin package, contains one 5 bit I/O port and 2 - 8 bit I/O ports. The device also has a hardware UART and 4 k of memory. I use this device where I will need the execution speed of the built in UART, the extra ports (like this project) or the 4 k of memory for large complicated code projects.

16C73 - Like the 16C63 but also has a built in, 4 channel, A/D converter like the 16C71. This device is used in all the applications like the 16C63 would be used for, but where I also need to have an A/D converter (like the 2 meter receiver project).

With just these 4 devices I can keep my investment low and also do nearly any project that I would likely have the time to do anyway!

August 2000 Addendum: Since this article was first written in 1998, several new PIC's have come on the market. So my choice of PIC's has narrowed to the following,

• I still use the 16F84 for the reasons given above.
• For the larger 28 pin devices I have narrowed my choice to the 16F873. The 873 is a Flash device that includes a 10 bit A/D converter, so there really is no reason to stock two different parts (one non A/D and one with A/D) as I see it.
• Soon 28 pin Flash PIC's will be available that also have a 12 bit converter, and I expect to migrate to them.
• Soon PIC's with USB support will be available and I expect to migrate from RS232 control to USB control.

[1] Hageman, Steve. "Build your own network analyzer", QST, JAN 98 and FEB 98.

[2] Hageman, Steve. "Built this synthesized 2 meter receiver", QST, February 98.

[3] Microchip Technology, Chandler AZ, the makers of PIC uP's, www.microchip.com

[4] Micro Engineering Labs - Makers of PBASIC for the PIC, www.melabs.com

[5] CCS PCM, A C compiler for mid range PIC's, www.ccsinfo.com

[6] www.sonic.net/~shageman

[7] www.sonic.net/~shageman/pna.html

[8] Be sure to take note that since we are not using any handshaking lines with the RS232, set your terminal programs "Handshaking" parameters to either None or as it is sometimes called "No Flow Control".

Sidebar: Simple Project Displays

You may notice many articles now-a-days that include LCD character displays. Available from many manufacturers, these LCD's are really complete display subsystems {1}. They are commonly programmed in 4 bit nibbles and can display the full upper and lower case ASCII character set.

The displays are available in 16 character by one line to 40 characters by four lines and start at under $20.00. The displays are 40 pin devices, subtracting power and ground pins leaves 11 pins to deal with programming wise. Using the 4 bit mode saves on I/O pin's which with a PIC is usually important. In 4 bit nibble mode only 6 lines are needed. Another popular method is to use a PIC with the LCD display that is programmed to receive serial data. Scott Edwards Electronics popularized this low cost method. These serial adapters allow the display to be accessed with serial bit streams from a single PIC pin. Interesting enough these serial adapters are themselves usually built with PIC microprocessors.

The basics of using one of these displays comes down to 3 simple functions,

1) Initialize the display, this clears the entire display.

2) Set the line to write to (i.e. either the 1st or 2nd line). This also sets the cursor to the beginning of the line.

3) Write text to the display, you can either write single characters one by one to the display or write entire strings to the display. The display itself takes care of moving the character position after each character is displayed.

Translated into 'C' code these statements look like,

init_lcd(); // Initilize and clear the LCD Display

first_line(); // Set cursor to first line

write_lcd("Hello World..."); // Write something

second_line(); // Set cursor to second line

write_lcd("QST is the best"); // Write something else

A sample LCD display can be seen in the photo,

 

These are exactly the functions I include in my PIC projects that use the LCD displays. For an example of the actual code used to drive a display see my web page on the 2 meter receiver project {3}.

{1} For example see the OPTIREX character displays from Digi-Key, www.digikey.com

{2} Serial Backpak from Scott Edawards Electronics, www.seetron.com

{3} www.sonic.net/~shageman/2_meter.html

All commercial rights reserved.

Originally published in QST, March 1999 and copyrighted by the ARRL/QST.