WRD Corp Contact Us WRD Corp
Who We Are
Case Studies

"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