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
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
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
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
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,
Digikey. In quantities of 25 and 100 you should be able to cut the part
costs to 0.5 to 0.3 of this
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
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
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
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.
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
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
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
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
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
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.
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
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.
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
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
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.