Issue
102 January 1999
In
the Face of Medusa
Part
1:Developing Reliable Control
ENEMY
IDENTIFICATION
The
first problem is that any monocomplex embedded system
is a single point of failure. If the embedded ’x86
system croaks or jams up, the whole experiment may fail
unless an astronaut or scientist comes to its aid in
time. Besides, we all know those astronauts are just
in it for the thrill ride. The scientists do the real
work, right?
The
second problem I see is a lot of expensive add-on hardware
to accommodate the control of the valves, pumps, and
camera drive. And don’t forget taking temperature
readings and monitoring humidity. All of this is compounded
by more complex ’x86 firmware that’s
needed to monitor and failsafe the devices being controlled.
Complexity is directly proportional to cost. You do
the math.
I’m
sure you’ve all heard stories about how the NASA
folks lean toward redundancy to improve the safety factor.
Well, the same premise can be applied to the experiments
that fly too. But, it would be impractical to place
numerous embedded ’x86 systems within our
Medusa experiment.
First
of all, the price would be prohibitive and the space
allotted for the experiment is insufficient for that
much hardware. By the way, there’s no local power
company supplying the power, either.
So,
how can we make this experiment perform with a minimal
’x86 system using smaller peripheral processors?
My answer: a Micromint PicStic.
SHIP
IN THE DISTANCE
I
liken the PicStic to a ship in the distance. It may
look like a dinghy from afar, but as you come closer
to its hardware and get to know its power, it arrives
in port as an aircraft carrier with you as the captain.
The
PicStic is small, lightweight, inexpensive, and easy
to implement. You can choose from several variants depending
on your application’s requirements. For Medusa,
I chose the PicStic-4Q.
The
4Q is a rectangular solid with its longest side measuring
1.5”, and it takes up about 0.57421875 in.3. Power
consumption is less than 75 mW, and as long as the astronauts
are comfortable, the 4Q module is, too.
If
harsh environments are expected, you can obtain 4Qs
with extended industrial operating temperature ranges.
The device is housed in a protective cover with the
hardware features accessible via 32 dual-inline pins.
The pinout is shown in Figure 1.
Not
only is the 4Q rugged and economical, but it’s
also highly capable and easy to program. You can program
your ’x86 embedded firmware in C, BASIC,
or assembler, right? Same for the 4Q.
This
implies a minimal learning curve for any embedded programmer.
As you might have guessed, this module is based on Microchip’s
’16F84.
The
’16F84 is one of those EEPROM-based microcontrollers
that needs no special erasing lamps to clear the program
and data memory areas. The ’16F84 core is teamed
up with an I/O coprocessor to provide a wealth of I/O
pins and built-in functionality.
Instead
of writing every little bit of code to perform a simple
switch read, the 4Q’s firmware contains such routines.
You simply call them as you would in a desktop-based
BASIC program. All of the switch debounce software and
input code is already built into the PBASIC call.
