Stamp vs PICs in Commercial Applications

copyright, Peter H. Anderson, Baltimore, MD, July, '98


The question often arises, "Should I use the Basic Stamp 2 in a commercial application". Like most apparently simple questions, there is no real simple answer. It depends on a good many things.

In the following I attempt to discuss a number of factors; e.g., cost, code security, code maintenance and performance capabilities for the Parallax Stamp and Microchip PICs having similar capabilities.

Please recognize that the PIC was used in the comparison because I am currently most familiar with this family of single chip processors. My observations probably could be extended to various Motorola processors and 8051 derivatives marketed by Dallas and Philips and numerous others.

Parallax BASIC Stamp 2.

Time to Market.

In a development environment, there really is no substitute for the Stamp in terms of the ease in testing concepts and this might be extended to actually implementing the product.

I really think the Basic Stamp 2 is to processors as sliced is to bread, during the development process. I know of no similar system which permits the very rapid "code and try" afforded by the Stamp and in some applications it may make sense to simply field this development tool as the final product.


The $49 price tag may at first appear prohibitive. But, on the other hand, the development time to transition the product to a PIC can be costly. If the Stamp is a necessary part of a relatively expensive product that costs several thousand dollars, the $49 just is not a very important factor.

If the design uses a printed circuit board you might give some thought to implementing the design much like our "Homebrew" Stamps. Buy the PBASIC2 interpreter IC from Parallax and other such parts as the 24LC16B EEPROM from such commercial suppliers as Arrow, Pioneer or Digikey. In quantities of 25 and 100 you should be able to cut the part costs to 0.5 to 0.3 of this $49 cost.

There are a few other advantages to implementing your own.

Loss of Program.

There has at times been a disturbing thread on the [STAMPS] list of experiences with the Stamp losing its program. I have not seen this, but a good many people have. Certainly it is clear that the PBASIC interpreter includes code to burn a block of memory and one might offer that if the PIC went into "never never land" during a power up condition, it could well execute this code and burn whatever garbage is in the buffer to the EEPROM.

In moving to a "Homebrew" you have access to the terminals associated with the 24LC16B EEPROM where the program is stored and thus you have access to the write protect lead. Of course, using this option would preclude you from writing to EEPROM within your program for storing calibration data, site dependent data or for logging data.

Maintaining Code in the Field.

The other advantage may be in maintaining your code. The obvious technique for fielding new software is to ship a disk and have someone run around with a laptop programming each Stamp based product in the field much like you and I use the Stamp during the development process. In having an implementation with the PIC and EEPROM physically separated, you might consider socketizing the EEPROM such that in providing an update you can simply ship a new EEPROM.

Lack of Security.

One big disadvantage in using a Stamp is that you are giving your code to the world. All anyone needs is the EEPROM. But, in most cases where the Stamp makes the most sense anyway, this may not be an important consideration. For example, a $100,000 machine tool. It's pretty hard to hide all the castings, shafts, cutters and gears from the competition and the question arises as to whether it is really important to hide the program. The design and manufacture of expensive machine tools requires an enormous amount of capital and a skilled work force and the competitiveness of a design probably is not going to depend on a BASIC Stamp program.

On the other hand, the lack of security could be a big problem with an innovative design where the program in the Stamp is what is driving the innovation. Twenty five years ago, there was a game, "Simon" where the full 8085 system was right there on cardboard and Atari cartridges were nothing but a PROM. Pretty easy to clone. But, in both of these cases, the idea was to cheaply bring the product to market for a year or so. By the time the competition tooled up, the demand had been satisfied. At the other extreme, Coca Cola has been successful in hiding their recipe for some hundred years. Somewhere in between is potting the circuitry with epoxy, but I don't think this will slow a determined competitor. Thus, the Stamp might be acceptable in an innovation having a brief life. For longer periods, I would tend more toward the PIC.

Lack of Watch Dog Timer.

Another disadvantage in using the Stamp is the lack of a watch dog timer. Thus, if it goes into "never never land" it will most probably stay there. However, this really is not a disadvantage in applications where the Stamp is "reset driven". This an operator may push a button or a master processor may reset the slave Stamp which may read its task, do the task, and report back with lamps or serial data. I would hesitate to use it in applications where it is operating independently over long periods of time without using an outboard watch dog timer.

Stamp Summary.

A summary is difficult. The major advantage in using the Stamp is "time to market". Disadvantages are cost, possible loss of program, lack of a watch dog timer and in fielding a design you are making your software public. But, these disadvantages may or not be factors in a specific design.

Microchip PIC.

Time to Market.

Although the Stamp certainly wins in the development process and it might win in "time to market", it should not win by all that much.

Indeed there is a learning curve associated with the PIC, it simply is not that steep and even if it is somewhat steep the first time, it becomes rather much like rolling off a log the next time around.

Consider that in the Spring, '98 term I had some 35 undergraduate students and by the end of the semester they were all writing code to "wakeup on change", fetch the time from a DS1602 timer and store the information in a 24LC65 EEPROM and on command, dump the data to a PC. This was done by students who were still struggling with programming in any language, still struggling with debugging skills and competing for limited resources and the entire course was done with no emulators.

Once an experienced programmer understands the operation of a DS1602 or a 24LC65 which I think is best done using a BASIC Stamp, I would think that this could be mapped over to a PIC within a day or two. Indeed the Stamp might win the race to market but, perhaps only by a week.

There is an argument that a wise industry strives to adopt one or two new technologies in a design so as to pull up the knowledge base of the work force. In redesigning a TouchTone receiver at Bell Labs we designed many new ICs and spent a considerable amount of time experimenting with active filters. The active filters didn't make it, but we were high enough on the curve that they were being used as a matter of course in other designs a year later. The idea was to invest a bit of money in developing the current design to make future designs more productive.

Along the same line I would advance the opinion that fielding a design using a PIC is adopting a new technology which pulls up the knowledge curve for future designs and this is true even if the "industry" is one person. Pay a bit now to reap greater rewards tomorrow.

My point is that I simply am not any too convinced that the Stamp's "time to market" advantage is any too real of an advantage, particularly when weighed with the other advantages of the PIC. (Don't you just hate it when someone manages to contradict themselves within just a few pages).

[Note. Many enthusiasts assume that mapping a design from a Stamp to a PIC can be achieved by blindly using the MicroEngineering Labs PICBasic Pro package. We did our weather PIC using the ME Labs package and it certainly helped in administering a large project spread over a number of people and in performing calculations, but some fifty percent of the code was assembly for a number of reasons. My hat certainly is off to MELabs, but effective use of the package and debugging demands that the user have a good command of assembly language coding.]


The Microchip family has become very large. Representative devices which might be used in place of a Stamp are 16F84, 16C558, 16C6X and 16C72.

In all of these cases the circuitry consists of simply the PIC and either a ceramic resonator or crystal oscillator and thus a typical per unit cost is from $3.50 to $7.00 per unit in 100 quantity. In the case of our Logic Probe which is implemented using a PIC12C508 with an internal RC clock the per unit cost is $1.10. This is clearly quite favorable when compared with a Stamp.


To my knowledge, all PICs include a provision for code protecting your intellectual property. We use it on all of our designs. Parallax uses it on their BASIC Stamp interpreter.

I have to assume this can be broken by someone with the determination and resources. You need only go to the Deja News search engine and search on 16C84 and you will probably find a few messages by folks who are pirating cable TV descrambler devices. But, the mere fact that PICs are used in such high demand type applications suggests that the successful pirating of your intellectual property is far more complex than with the Stamp where the pirate needs nothing more than a programmed 24LC16B EEPROM.

Field Maintenance.

The PIC16F84 is electronically erasable and it thus lends itself to a process of sending an update in the form of a hex file and reprogramming the device in place. Recognize however, that in shipping a hex file, you may have released your program to the world. If this really doesn't matter, the "program in place" capability may prove a real plus.

I offer quite a number of student designs which use one time programmable (OTP) PICs. We try to do our homework and thus far we have done pretty well in fielding designs that work. But, bringing a design to a close and shipping the first product is always a scarey experience. There is some comfort in knowing that if we did make some foolish error the world won't end. A PIC16C558 is less than $3.00 and we certainly can afford to ship an update in the form of a new programmed PIC.

I am inclined toward socketizing the PIC and shipping updates as programmed PICs. It's cheap, security is preserved and its a lot easier on than end user than pulling a laptop up under some tractor to burn a new version of the program into an existing PIC16F84.

Watch Dog Timer.

The PICs include an onboard watchdog timer which may be prescaled to provide a good deal of flexibility in providing various maximum timeout values. It's free.

In explaining the function of a watchdog timer to my students, I always offer the example of a pacemaker. "Where are you going to put the reset button?". I wouldn't want to be the designer of such a critical processor, but if pushed, there is no question that the processor better have a watch dog timer.

Other Features.

The Stamp certainly is innovative and powerful. But, there is no function that cannot be mapped over to a PIC quite quickly. Admittedly, I would have to give the DTMF function a bit of thought, but then again, I probably would use various timer capabilities of the PIC which are not used by the Stamp.

The Stamp does not provide for any interrupts whatever nor offer the user any access to counters and timers.

Thus, such simple functions as performing a task when a key is pressed, PWM or counting can be very frustrating in that they require the Stamp devote its entire resources to the specific task. With a PIC it is pretty simple to be constantly performing the PWM function, perform A/D measurements, count the number of rain drops and respond to a user depressing a key on a 4 by 4 keypad, all at the same time. This simply is not possible with the Stamp.

The Stamp is quite slow. The primary area where I have found this to be a problem is in interfacing with the Dallas 1-Wire devices. With a Stamp, you can't. With a PIC you can.


There is a definite niche for the Stamp in a commercial application where the task is not critical and the relatively high cost and lack of code security are not important and in fact, this includes many applications.

However, if there is any appreciable volume, a need for paying close attention to cost or code security or if the application is operating in an environment where a frequent reset is not possible, any of a number of Microchip PIC devices are probably a better alternative. In addition, the PIC offers a good many capabilities which permit the implementation of tasks which are impossible to perform with a Stamp.

As noted in the introduction, there really is no simple answer to the "Stamp or PIC in a commercial application". However, I am hopeful that given a specific application, this discussion aids in making the decision.