1.2 CPU, Memory, and Input/Output
A complete microcomputer is a team. The CPU transforms and coordinates, memory preserves, input observes, and output acts or reports. No member can replace all the others.
The arrows are important. They show roles in a transfer, not permanent one-way laws for every physical connection. A keyboard usually supplies data; a display usually receives results; memory must both supply and accept information.
The CPU: execute and coordinate
The CPU follows instructions. Internally it contains circuits that perform operations, small fast storage locations called registers, and control logic that organizes each step.
At this point, use a simple model:
- the CPU reads an instruction;
- it obtains any required data;
- it performs an operation;
- it stores or outputs the result.
The CPU does not magically know the temperature, the pressed key, or the program. Those values must arrive through input or memory.
Memory: preserve bits at addressed locations
Memory is a collection of numbered locations. The number identifying a location is its address. A location holds a pattern of bits, and the meaning of that pattern depends on how the system uses it.
The same memory system may hold:
- instructions, which tell the CPU what operation to perform;
- data, which represents numbers, characters, sensor values, images, or intermediate results.
Consider these three locations:
| Address | Contents | Possible meaning |
|---|---|---|
| 20 | 00000101 | instruction code or number 5 |
| 21 | 00000011 | operand or number 3 |
| 22 | 00001000 | result or number 8 |
Bits do not carry labels saying “instruction” or “temperature.” Their location, the current instruction, and the program's rules provide meaning.
Two broad memory ideas will reappear later:
- volatile memory loses its contents when power is removed;
- non-volatile memory retains contents without continuous power.
For now, the key idea is simpler: memory lets the system use information after the instant it was produced.
Input and output connect the physical and digital worlds
An input device converts an outside event into information the computer can use. An output device converts a computed result into an observable action.
| Physical event | System role | Digital information |
|---|---|---|
| A key is pressed | Input | key code |
| Temperature changes | Input | measured value |
| A number appears on a screen | Output | pixel or character command |
| A fan starts | Output | motor-control signal |
Some peripherals play both roles. A touch screen displays pixels and senses touches. A network interface receives and transmits messages. Classify the current transfer, not only the name of the device.
Lab 1 — route each transfer yourself
Choose a mission, then dispatch one data transfer at a time. The lab checks the route as a sequence, so a wrong turn is identified where it first breaks the dependency.
Try all three missions. Notice that “save” requires a CPU-to-memory transfer, whereas merely displaying a value does not necessarily require saving it.
Worked example: displaying a stored target
Suppose a thermostat must display its saved target temperature.
1. The CPU requests the value at the target-temperature memory address. 2. Memory sends the stored bits to the CPU. 3. The CPU interprets or formats the number. 4. The CPU sends display data to the output device.
The essential information path is therefore:
Memory → CPU → OutputIf the user changes the target using buttons, the full story may be:
Input → CPU → Memory
└→ OutputThe CPU is on the route because it applies the program's rules. Memory is on the route only when the value must be retrieved or preserved.
Systems fail through missing dependencies
Thinking in components makes faults easier to localize.
| Symptom | Plausible broken dependency |
|---|---|
| A correct program disappears after power-off | non-volatile storage or loading path |
| Buttons work, but nothing is visible | output path or display |
| Old readings display, but new readings never arrive | input device or input path |
| Inputs and display work, but results are nonsensical | CPU execution, program, or working data |
A symptom rarely proves a single physical cause. Diagnosis begins by finding what still works, because every successful behavior confirms several dependencies.
For example, if a saved welcome message appears after reset, then at least some CPU execution, memory reading, and output activity are working. That evidence narrows the search.
Lab 2 — diagnose by changing the system
In the repair clinic, disconnect and reconnect components while a live dependency table predicts the symptoms. Use the smallest repair that restores every required dependency.
Do not solve by turning everything on immediately. First predict one component, test it, and use the change in symptoms as evidence.
Checkpoint
You should now be able to answer four questions about any simple microcomputer:
1. What information enters, and through which input? 2. What instructions and data must memory preserve? 3. What transformation or decision must the CPU perform? 4. What result leaves, and through which output?
These roles explain what the parts contribute. The next section explains when the CPU reads and performs instructions by following the stored-program instruction cycle.