Device Controllers
5.1.2 Device Controllers
I/O units often consist of a mechanical component and an electronic compo- nent. It is possible to separate the two portions to provide a more modular and general design. The electronic component is called the device controller or adapter . On personal computers, it often takes the form of a chip on the par- entboard or a printed circuit card that can be inserted into a (PCIe) expansion slot. The mechanical component is the device itself. This arrangement is shown in Fig. 1-6.
The controller card usually has a connector on it, into which a cable leading to the device itself can be plugged. Many controllers can handle two, four, or even eight identical devices. If the interface between the controller and device is a stan- dard interface, either an official ANSI, IEEE, or ISO standard or a de facto one, then companies can make controllers or devices that fit that interface. Many com- panies, for example, make disk drives that match the SATA, SCSI, USB, Thunder- bolt, or FireWire (IEEE 1394) interfaces.
INPUT/OUTPUT CHAP. 5 The interface between the controller and the device is often a very low-level
one. A disk, for example, might be formatted with 2,000,000 sectors of 512 bytes per track. What actually comes off the drive, howev er, is a serial bit stream, start- ing with a preamble, then the 4096 bits in a sector, and finally a checksum, or ECC (Error-Correcting Code). The preamble is written when the disk is for- matted and contains the cylinder and sector number, the sector size, and similar data, as well as synchronization information.
The controller’s job is to convert the serial bit stream into a block of bytes and perform any error correction necessary. The block of bytes is typically first assem- bled, bit by bit, in a buffer inside the controller. After its checksum has been veri- fied and the block has been declared to be error free, it can then be copied to main memory.
The controller for an LCD display monitor also works as a bit serial device at an equally low lev el. It reads bytes containing the characters to be displayed from memory and generates the signals to modify the polarization of the backlight for the corresponding pixels in order to write them on screen. If it were not for the display controller, the operating system programmer would have to explicitly pro- gram the electric fields of all pixels. With the controller, the operating system ini- tializes the controller with a few parameters, such as the number of characters or pixels per line and number of lines per screen, and lets the controller take care of actually driving the electric fields.
In a very short time, LCD screens have completely replaced the old CRT (Cathode Ray Tube) monitors. CRT monitors fire a beam of electrons onto a flu- orescent screen. Using magnetic fields, the system is able to bend the beam and draw pixels on the screen. Compared to LCD screens, CRT monitors were bulky, power hungry, and fragile. Moreover, the resolution on today´s (Retina) LCD screens is so good that the human eye is unable to distinguish individual pixels. It is hard to imagine today that laptops in the past came with a small CRT screen that made them more than 20 cm deep with a nice work-out weight of around 12 kilos.
Parts
» The Second Generation (1955–65): Transistors and Batch Systems
» The Third Generation (1965–1980): ICs and Multiprogramming
» The Fourth Generation (1980–Present): Personal Computers
» System Calls for Process Management
» System Calls for Directory Management
» RESEARCH ON OPERATING SYSTEMS
» Implementing Threads in User Space
» Implementing Threads in the Kernel
» Making Single-Threaded Code Multithreaded
» Mutual Exclusion with Busy Waiting
» Avoiding Locks: Read-Copy-Update
» Scheduling in Interactive Systems
» Scheduling in Real-Time Systems
» The Dining Philosophers Problem
» The Readers and Writers Problem
» The Notion of an Address Space
» Page Tables for Large Memories
» DESIGN ISSUES FOR PAGING SYSTEMS
» Segmentation with Paging: MULTICS
» Segmentation with Paging: The Intel x86
» An Example Program Using File-System Calls
» Device-Independent I/O Software
» Disk Arm Scheduling Algorithms
» Preemptable and Nonpreemptable Resources
» Deadlock Detection with One Resource of Each Type
» Deadlock Detection with Multiple Resources of Each Type
» The Banker’s Algorithm for Multiple Resources
» REQUIREMENTS FOR VIRTUALIZATION
» TYPE 1 AND TYPE 2 HYPERVISORS
» TECHNIQUES FOR EFFICIENT VIRTUALIZATION
» ARE HYPERVISORS MICROKERNELS DONE RIGHT?
» Challenges in Bringing Virtualization to the x86
» VMware Workstation: Solution Overview
» ESX Server: VMware’s type 1 Hypervisor
» Multiprocessor Operating System Types
» Multiprocessor Synchronization
» Low-Level Communication Software
» User-Level Communication Software
» Network Services and Protocols
» File-System-Based Middleware
» Coordination-Based Middleware
» Authentication Using a Physical Object
» Authentication Using Biometrics
» Antivirus and Anti-Antivirus Techniques
» Model-Based Intrusion Detection
» Process-Management System Calls in Linux
» Implementation of Processes and Threads in Linux
» Implementation of the Linux File System
» NFS: The Network File System
» HISTORY OF WINDOWS THROUGH WINDOWS 8.1
» The Native NT Application Programming Interface
» The Win32 Application Programming Interface
» Implementation of the Object Manager
» Subsystems, DLLs, and User-Mode Services
» Job, Process, Thread, and Fiber Management API Calls
» Implementation of Processes and Threads
» Memory-Management System Calls
» Implementation of Memory Management
» Why Is It Hard to Design an Operating System?
» Static vs. Dynamic Structures
» Synchronous vs. Asynchronous Communication
» TRENDS IN OPERATING SYSTEM DESIGN
» SUGGESTIONS FOR FURTHER READING
Show more