How Computers Are Used As Components

A computer appears as a component in any of a number of systems that interact with their environments to solve interesting problems. It often helps to think of these systems as though they were collections of people solving the given problem, to anthropomorphize them, in order to get a feel for what is going on.

For example, consider the problem of providing traffic control at a pedestrian crossing. One could imagine a police officer or school crossing guard as a solution to this problem: The officer observes the pedestrians, and when one wishes to cross the street, the officer stops traffic while one or more pedestrians cross. At some point, the officer decides to halt the stream of pedestrians to give the automobile traffic use of the crossing.

The overall task can be broken down into simpler tasks:

A system thus needs analogs of the officer's eyes, hands and brain to carry out the task. If we think about existing systems for traffic control at pedestrian crossings, we see some of these analogs immediately: The officer's eyes are replaced by a button the pedestrian presses to signal a desire to cross, and the officer's hands are replaced by the lights that signal the traffic and the pedestrians. It is not so obvious, however, what is replacing the officer's brain. That replacement is hidden away in a box that sometimes makes whirring and clicking noises as the cycle of control progresses.

The process of deciding when to respond to pedestrian requests and when to stop allowing pedestrians to cross can be carried out by an algorithm based upon button presses and time. You already know from your elementary programming course (or equivalent experience) how to develop algorithms that accept inputs and deliver outputs based upon those outputs. Thus you can see how a computer that is a component of the pedestrian crossing control system could replace the officer's brain.

We can generalize this reasoning to say that the computer is the component of a system that carries out algorithm(s) to make decision(s) affecting the behavior of that system. Other components of the system obtain information to be input to the algorithm(s) from the environment, and still others control the environment on the basis of information developed by the algorithm(s).

What We Need To Understand

In order to be able to design systems with computers as components, we need to understand both what the computers can do internally and how they can interact with their environment. Generally speaking, you should know what computers can do internally. This course therefore focuses on how the computer interacts with its environment.

The details of environment interaction are highly specific to the kind of interaction being carried out. They depend upon the way in which the system is put together as well as upon the individual characteristics of the hardware. A system designer must have a good understanding of the capabilities and operation of the major classes of device interface, as well as of the low-level details of how the computer interacts with these interfaces.

The Capabilities of the Central Processor

We begin by looking at the overall system architecture and the role of the central processor as its algorithmic engine. This engine remains our focus for the next three weeks, as we gain familiarity with ways to express algorithms for it. During that period we examine addressing modes and procedures in detail, introducing many of the central processor instructions through examples illustrating these two important concepts. These examples will also illustrate how programs are written in the native language of the machine, and how we control complexity by decomposing a program into modules. The first exam covers this material.

Using Devices via their Interfaces

A basic understanding of the behavior of the central processor is necessary to be able to construct algorithms that control the interfaces to the rest of the system. Thus we are now in a position to improve and build upon this understanding by writing simple algorithms to communicate with the environment. That communication may involve streams of characters, on/off signals, or sequences of samples from continuous signals. In each case, the information is represented within the central processor as a bit pattern.

The simple algorithms work, but they require the central processor to concentrate exclusively on one task. Interrupts can be used to switch the central processor's attention among several tasks, and more complex device interfaces can take over some of the detail of environmental interaction.

Once we have the possibility of dealing with a multitude of devices operating at different rates, we need to be able to buffer data in order to handle bursts of information arriving too fast to process. (Of course the average data rates must be within our processing capabilities.)

In addition to being able to respond to interrupts generated by devices, the central processor must have access to some absolute notion of time, such as we get from our wristwatches. Without this, there would be no way for the central processor to schedule events like halting the flow of pedestrians at the crossing. The second exam covers this material.

Managing Concurrency

Like the human brain, the central processor must be able to switch its attention smoothly from one task to another. It must ensure that in the tasks do not interfere with one another, yet may cooperate when required. Management of loosely-coupled processes turns out to be a very tricky problem that requires careful design and a deep understanding of certain aspects of the underlying hardware. Because many of these processes carry out identical operations, they share code. Such shared code must be written in a particular style in order to avoid unwanted interactions among the processes using it.

The more tasks a system must handle, the more likely it is that problems will arise within individual tasks. It is therefore increasingly important to separate tasks with firewalls, so that if one task fails it does not corrupt others. One obvious way of separating tasks is to use memory protection to prevent one task from overwriting another's storage.

Floating-Point Numbers

Although the samples of a continuous signal are represented as integer values in some relatively small range, they are considered to be drawn from a much larger universe of real values. Computations on these samples generally involve the larger universe; it is only when results of those computations must be output that they are again mapped into the small integers acceptable to the output device. Floating-point numbers simplify the representation of numeric values with large ranges. Their representation consists of two parts, which must be separated for computations. Code to manipulate floating-point numbers is quite slow and bulky, so a separate coprocessor is normally used for dealing with these values. The coprocessor works very closely with the central processor, requiring an interaction protocol that is quite different from the ones used for device interface chips.

A Typical Application

With a thorough understanding of the capabilities of the embedded computer and its interfaces to the outside world, we can approach a typical problem: control of an automobile suspension. In this problem the computer must maintain the position of the axle relative to the body in the face of disturbances due to road surface, cornering, acceleration and deceleration. In the process of maintaining that position, however, it must provide a comfortable ride.