"The Search for the HolyGrail"
© Doug Johnson, WRD, 7/31/02
I started my embedded career in Dec. 1976, fresh out of Engineering
School, with Texas Instruments (TI). I was hired because I was the
only engineering graduate my soon-to-be boss could find who had
ANY microprocessor experience on his college resume. (In my senior
year, I designed and built a scanning keyboard and digit multiplexed
LED display available, including a computer design class where we
studied, among other things, the architecture of the PDP-8.
TI didn't spend time training new (graduate) Engineers, they pretty
much expected them to get to work right away. Our training was done
by the “sink-or-swim” method, which turns out to be
remarkably poignant. The group that hired me designed and built
machine tools that were used to manufacture structural housings
for military ordinances. Our group consisted primarily of Mechanical
Engineers, and when I first started, my boss and I were the only
EE's. The machines we designed and automated were large drill and
tap machines. They were roughly circular and had a hydraulic index
table in the center. Multiple drilling and tapping stations on hydraulic
slides surrounded the index table, and would sequentially extend
and retract, thus drilling and tapping the work in the center. These
machines were good sized (they would just fit in a 10x10 room) and
were chock full of large (3-5 hp) 240VAC motors.
My boss had designed a suite of four PC boards that we used to automate
these machines. The CPU board had an 8080 CPU, an 8224 clock-generator,
a socket for a 2704 / 2708EPROM (512 and 1K bytes respectively),
and a pair of 2112 static ram chips (256 bytes total). There was
a 16 output board that used CA3081 transistor packs for open collector
outputs signals, and a 16 input board that used resistor dividers
to divide the 12vdc input signals from the limit switches, to 5v
which connected directly to the microprocessors input buffers. (At
the time, neither of us knew about opto-couplers. This dreadful
situation ultimately provided an unequaled leaning experience as
I was later assigned to find out why our machines didn’t “work
right” all the time.) The fourth board contained eight 555
one-shots that were triggered by writing to them. The micro could
then poll the outputs to see when they expired. PCB mounted trimpots
were used to set the times, and were available at the edge of the
board. This was quite an innovative idea, as all machine timing
parameters: dwells; drill times; extend/retract times, etc., were
implemented using this timer board. While the machine was running,
you could tweak these times, using the trimpots, and the settings
were non-volatile.
As I recall, I was given about a week to familiarize myself with
the hardware, and
demonstrate proficiency with the 8080 assembly language. My boss
had built a
development system that consisted of an 8080 System Design Kit,
an ASR33 Teletype (110 baud), a 2704 / 2708 Prom Programmer and
a single stepper. Writing an assembly language program entailed
hand coding, hand assembling, and then entering the HEX machine
code into the development system using the Teletype. The development
system was used to burn the EPROM, which was then installed into
the target system. The single stepper was used to find any problems.
I remember a major debugging "breakthrough" occurred when
one of us had the idea to connect the function generator to the
single stepper, and with the turn of a knob, you could zip through
the code that was OK, and then slow down when approaching a problem
area.
I'm sure that at the time, we all felt we were productive, but the
process I just described is prehistoric.
Over the next few years, I witnessed, some mind-bending "process"
improvements, all of which were implemented by the people I was
working with, some of which I contributed to:
• Someone in another group had written a cross assembler that
ran on TI's
minicomputers. This meant that (with a secret clearance) I could
gain access to TI's computing centers, enter my assembly source
code on a terminal, and have the mini-computer assemble the code,
and punch the resulting machine code onto paper tape. We then added
a paper tape reader to our development system and experienced a
tremendous improvement in accuracy and efficiency.
• One of our subsequent new engineers, (he was a ME, but remains
to this day one of the most enlightened computer control guys I've
ever known) wrote a simple, context saving, round-robin task scheduler
for us to use. (This was in '77 or '78.) I remember him explaining
it to me, and being dumbstruck by the shear idea of it. This was
probably the defining moment in my understanding the significance
of intellectual vision and capability... that enormous productivity
gains are possible, even when its
not known at the time there is a process shortcoming.
• Another improvement came when I modified our development
system to use a Bipolar PROM for system decoding, to provide a bank
switch on a portion of the system RAM. This let us download the
untested program into RAM, bank switch that portion so that it now
started at 0000H (where the program is intended to reside, and where
it will reside when burned into a EPROM), and run the new program
out of RAM, starting at 0000H. You could boot back into the development
system, make some patches,
and then bank back into the RAM for further debugging. This broke
the
"burn and churn" cycle burning & erasing EPROM’s
for each iteration.
A carefully considered comparison of the above "improved"
process, to the "prehistoric" process in place when I
started at TI illustrates what's at stake:
“For the enlightened developer, it's not good enough to
simply address the
current requirement. You must search for a solution that not only
makes your life easier now, but also makes your life easier in the
future.
This is what I mean by the "Search for the Holy Grail".
I've seen the results, and it's
worth the effort.
Imagine what would happen, if every time you encountered
an embedded requirement you:
1. Crafted a software module that satisfied the requirement, and.......
2. Did so in a general way that applied
to many types and flavors of similar
requirements, and.....
3. Made it fit within a system architecture that was built around
the concept
of reusability?
How long does it take before your "system" accounts for
most of the requirements of
your next embedded project?
This is exactly what I've been doing for the past 25 years. During
that time, if you count the very first developments that used the
RTOS written at TI (my currently RTOS is a direct descendant), my
"Holy Grail" has been fine-tuned on over 100 embedded
developments.
|
