a device controller
The CPU speaks one language — read and write words at addresses — but a disk understands spinning platters and a network card understands voltage on a wire. A device controller is the translator and traffic warden that sits between the two. It is a small piece of hardware that manages one device (or a family of them) and presents a tidy set of registers to the CPU on one side, while driving the messy physical device on the other. Every keyboard, disk, screen, and network port reaches the CPU through such a controller.
A controller typically exposes three kinds of register that the CPU reads and writes (usually by memory-mapped I/O): a command or control register, where the CPU writes what it wants done ('read sector 4096', 'transmit'); a status register, which the CPU reads to learn the device's state ('busy', 'ready', 'error'); and data registers, which hold the bytes flowing in or out. The cooperating software on the CPU side is the device driver. A normal exchange is: driver writes a command, polls or waits for the status to say done, then moves the data — and for big transfers the controller can run DMA so the bytes go straight to memory without the CPU copying each one.
Why this matters: the controller is the boundary that makes the rest of the system device-independent. The CPU and operating system deal in commands and registers, not in the physics of magnetism or radio. Swap a spinning disk for an SSD and, as long as the controller speaks the same register protocol, most software does not care. The controller is also where a lot of a device's intelligence now lives — an SSD's controller runs the flash translation layer and wear leveling, hiding flash's quirks behind a simple 'read this block, write that block' face.
A disk controller's registers: write the block number into the command register and set the 'go' bit; the controller reads the platter, fills its data buffer, sets the 'done' bit in the status register, and (if asked) DMAs the data into RAM and raises an interrupt. The CPU never touched a platter.
Command in, status out, data through — the three-register pattern most controllers follow.
'Controller' here means the I/O controller for a device, not the memory controller (which manages DRAM) nor the processor's internal control unit. Same word, three different jobs — context tells them apart.