Introduction

Industrial Design with Microcomputers
Steven K. Roberts (1981)
Prentice-Hall

0.0 A SHORT HISTORY

Somewhere in the midst of the 1970s, the “microelectronics revolution” that was already well underway escalated into a meta-revolution. First tentatively, and then with unreserved gusto, the major IC manufacturers turned their collective resources to the development and marketing of microprocessors.

The effect on the engineering community was immediate and profound. Some engineers, eyes bright with excitement, plunged headlong into this strange new form of system design which promised liberation from random logic. Others, more set in their ways, flipped uncomfortably past the growing profusion of maga­zine articles about micros, preferring to maintain complacent confidence in their existing specialties rather than become awkward beginners in this bizarre technol­ogy. Thus the “old dog” syndrome surfaced with a vengeance, and companies faced with competitive market realities began searching far and wide for people who could take the magical single-chip processors and make them dance. There were a few safe niches wherein the meek could take shelter from the onrush of alien concepts. But not for long.

Bit by bit, microprocessors began chipping away, so to speak, at even such traditionally nondigital edifices as TV circuit design, automotive electronics, large appliances, and communications systems. Manufacturers grew more and more frantic, some desperate West Coast operations even paying their employees healthy bounties to bring in new talent. It became clear to even the stodgiest of anti-micro diehards that this incomprehensible new technology was here to stay. Some became managers.

There was good reason for this meta-revolution. Aside from the sublime pleasures to be had in the world of microprocessor system design, there were some compelling economic advantages. In a nutshell, the need for new and dedi­cated hardware configurations for each and every product or custom controller could be eliminated and replaced with an elegant black box, appropriately inter­faced with the rest of the world and coaxed into operation through the creation of “software.”

This new approach to design was not, of course, free from the tyranny of the trade-off. The apparent economic freebie gained with the elimination of all that custom hardware had to be weighed against the new and unfamiliar costs of software design… and interface design… and the learning curves associated with a host of foreign concepts.

But “the market” was forceful in its demands. Brutal reality tipped the trade-off more and more in favor of micros — in nearly any application character­ized by the need for a controller. Now, years later, the question is not whether to use a microprocessor, but how.

0.1 THE DOCUMENTATION OF MAGIC

This book is a concession to reality. Despite the maturity of the technology (or perhaps because of it), it is exceedingly difficult for a design engineer to meaning­fully approach his or her first micro development projects armed only with a manufacturer’s data book. Despite the ready availability of “complete documen­tation,” there is something missing: a set of heuristics which integrate all that new product-specific data with the broad design concepts already possessed by the en­gineer. What are the boundaries between the processor and the rest of the world? How do you handle asynchronous events? How can you develop hardware and software independently, then put these two unknowns together and make them fit? What about noise and other manifestations of unavoidable universal truth?

How smart does this box have to be, anyway?

Tough ones. A look in the data book provides the number of nanoseconds between the start of a memory write pulse and the end of valid bus data; it even provides details of the instruction set and some suggested circuit configurations.

But between that and an industrial control system that must, glitchless, keep a production batcher going 24 hours a day, there is a great void. One of the ulti­mate objectives of this book is to fill that void with light and substance.

Prior to our excursion into the world of microprocessor system design, it is worthwhile to spend a moment considering just how we presume to accomplish such a feat.

This is not a normal textbook.

The classical approach to education seems, alas, to possess a fundamental flaw. It is well typified by the experience of engineering school, you walk in as a freshman and are immediately assailed by a wide variety of essentially random bits of data, ranging from Boyle’s Law to the formulas for X-ray diffraction in a crys­tal; from limits and differentials to DO loops. It’s all great and useful stuff, of course, but unless you already have a very sophisticated conceptual framework into which it can be fit, it may as well be a sequence of pseudorandom numbers.

An exaggeration, perhaps, but consider the thought processes that are taking place as these seemingly unconnected facts and concepts are presented in relent­less staccato bursts throughout those first few bewildering semesters. Your mind, architecturally defined at every level as an associative processor, optimized for storage of information within the context of information already stored, is sud­denly being asked to behave just like a computer. “Remember this, and this, and this. Don’t worry, it will all fit together someday.”

An associative system like the brain is forced into an unnatural and uncom­fortable mode when required to retain random data for later assimilation. In most cases, by the time the long-heralded “fitting together” rolls around in the en­gineering curriculum, much of the component data that was forcibly injected in dozens of classrooms is either associated inappropriately or lost entirely.

This is a great tragedy, and has been responsible for more than a few in­cidents of attrition. It is not uncommon for highly creative and intelligent people to feel so uncomfortable in this backward educational structure that they recoil in dismay and disappointment from engineering, incorrectly judging it to be a dry and colorless pursuit.

Well, all is not lost. The solution is completely obvious, and is, in fact, likely to be found in almost any situation in which one person explains — to someone he knows — how something works. The key here is “someone he knows.”

Hmmmm.

Human communication (bear with me — we’ll get to microprocessors in a moment) is a phenomenon of much wider information bandwidth than is detect­able in the linguistic content of the utterances involved. When you describe a con­cept to a friend, your words carry substantially more meaning than their dictionary definitions, for their primary function is the gradual modification of some aspect of your friend’s internal model of the world — a model that you share to some de­gree. It is thus unnecessary (and boring) to reduce your explanation of the con­cept to its absolute, explicit form; it’s much more efficient to take advantage of established contexts and mutually meaningful symbols.

A good professor recognizes this intuitively, and treats interaction with a class more as a continuous process of synchronous model building than its oppo­site: a series of discrete, open-loop lectures which assume nothing but a set of prerequisites defined by a curriculum. The problem is with books. Textbooks.

When someone, either in academia or industry, seats himself before a type­writer (or, hopefully, a word processing system) and writes something called a textbook, a strange phenomenon seems to take place. All contextual frameworks that contain the material are stripped away, leaving just the facts. However ex­pertly the writer develops these facts into concepts and usable tools, there is still, too often, a sharp boundary between the textbook and the real world. This gives textbooks a bad name.

That’s depressing. Despite the obvious necessity of interacting with the real world to gain a deeper and more useful understanding than can be had by just reading about it, it would seem that a textbook on some subject could be made to fit the optimal learning modes of the human brain a bit more than most of them do. The reason most of them don’t may be that those shared internal models of the world I rhapsodized about a moment ago simply do not exist between the lone writer at his machine and the anonymous reader, somewhere… out there.

Well. Let’s consider that problem.

I have, in all likelihood, never met you, and probably never will. I have no way of knowing whether you are reading this book for a class at an engineering school, trying to enhance your value to your employer as a system designer, ad­ding to your understanding of microprocessors simply because they are fun, or just browsing in a library. So what am I supposed to do, abandon all ideas of shared context just because you could be anybody in the world? Start convention­ally with binary numbers, two’s-complement arithmetic, Boolean algebra, and all that other tedious stuff? Provide a list of prerequisite readings? All of the above? None of the above?

Yup, you got it —- the answer is (E). Here are my assumptions, and buried within them is our shared context: You already have enough general knowledge about electronics and digital logic to recognize gates and deal with circuitry. You already know that the ideal “textbook world” (that word certainly does have a bad name!) of zero-rise-time pulses, noise-free circuits, and lumped constants is not exactly what actually exists out there (and if you don’t know that, don’t panic — it becomes obvious very quickly). You are at least intelligent enough to deal with engineering at the philosophical as well as the “crank-turning” level, and your healthy childhood curiosity somehow survived the schooling to which you have already been subjected. (It doesn’t matter whether you are reading this as course material or as “professional upgrade” material —- our purposes are iden­tical.)

That doesn’t seem like much of a shared context, does it? We’re going to build 400-odd pages of information about microprocessors on that?

Sure, because we’re going to deliberately develop it as we go along. If, at certain points, some background knowledge is required outside the domain of this book, I’ll throw in references that will let you make a subroutine call without crashing your stack.

We have already abused the prefix “meta-” once herein; why not go for broke and cockily call this a meta-textbook?

Let’s do it.

Return to the home page of Industrial Design with Microcomputers, by Steven K. Roberts (1981)