|
|
|
|
Plug-and-play
|
| |
|
| |
In computing, plug and play is a term used to describe the characteristic of a computer bus, or device specification, which facilitates the discovery of a hardware component in a system, without the need for physical device configuration, or user intervention in resolving resource conflicts.
Plug and play refers to both the traditional boot-time assignment of device resources and driver identification, as well as to hotplug systems such as USB and Firewire.
he beginnings of computing technology, the hardware logic was just a collection of building blocks, and the relationships between them had to be completely redesigned to accommodate different calculating operations.
Discussion
Ask a question about 'Plug-and-play' Start a new discussion about 'Plug-and-play' Answer questions from other users |
Encyclopedia
In computing, plug and play is a term used to describe the characteristic of a computer bus, or device specification, which facilitates the discovery of a hardware component in a system, without the need for physical device configuration, or user intervention in resolving resource conflicts.
Plug and play refers to both the traditional boot-time assignment of device resources and driver identification, as well as to hotplug systems such as USB and Firewire.
History of Device Configuration
In the beginnings of computing technology, the hardware logic was just a collection of building blocks, and the relationships between them had to be completely redesigned to accommodate different calculating operations. These changes were usually done by connecting some wires between modules and disconnecting others. The very earliest of mechanical computing devices such as the IBM punchcard accounting, tabulating and interpreting machines were programmed entirely in this manner, by the use of a quick-swap plugboard wired to route signals between configuration sockets.
As general purpose computing devices developed, these connections and disconnections were instead used to specify locations in the system address space where an expansion device should appear, in order for the device to be accessible by the central processing unit. If two or more of the same device were installed in one computer, it would be necessary to assign the second device to a separate, non-overlapping region of the system address space so that both could be accessible at the same time.
Some early microcomputing devices such as the Apple II required the end-user to physically cut some wires and solder others together to make these configuration changes. The changes were intended to be mostly permanent for the life of the hardware.
Over time the need developed for more frequent changes and for easier changes to be made by unskilled computer users. Rather than cutting and soldering connections, the header and jumper was developed. The header consists of two or more vertical pins arranged in an evenly-spaced grid. The jumper is a small conductive strip of metal clipped across the header pins. The conductive jumper strip is commonly encased in a plastic shell to help prevent electrical shorting between adjacent jumpers.
Jumpers have the unfortunate property of being easy to misplace if not needed, and are difficult to grasp in order to remove them from headers. To help make these changes easier, the DIP switch was developed, also known as a dual in-line package switch. The DIP switch has small either rocker or sliding switches enclosed in a plastic shell and usually numbered for easy reference. DIP switches usually come in units of four or eight switches; longer rows of switches can be made by combining two or more units. DIP switches are particularly useful where a long string of jumpers would be closely packed together or where four or more jumpers would be used in combination to configure one device function. DIP switches also have a particular advantage for configuration settings which are likely to be changed more frequently than once every few years. (Because of the inconvenience of setting them, jumpers are typically used for settings that are not expected to need to be changed unless the device is removed from one computer and installed in another, an infrequent occurrence for internal devices in consumer desktop PCs.)
Early self-configuring devices
As computing devices spread further out into the general population, there was ever greater pressure developing to automate this configuration process. One of the first major industry efforts towards self-configuration was done by IBM with the creation of their Personal System/2 line of computers using the Micro Channel Architecture (MCA). This took a giant leap forward, as expansion devices had absolutely no jumpers or DIP switches.
However, IBM's first attempt at self-configuration had a few major problems. In an attempt to simplify device setup, every piece of hardware was issued with a disk containing a special file used to auto-configure the hardware to work with the computer. (If the device required one or more drivers for specific operating systems, they were usually included on the same disk.) Without this disk the hardware would be completely useless and the computer would not boot at all until the unconfigured device was removed.
MCA also suffered for being a proprietary technology. Unlike their previous PC bus design, the AT bus, IBM did not publicly release specifications for MCA and actively pursued patents to block third parties from selling unlicensed implementations of it, and the developing PC clone market did not want to pay royalties to IBM in order to use this new technology. The PC clone makers instead developed EISA, an extension to the existing old non-PnP AT bus standard, which they also further standardized and renamed ISA (to avoid IBM's "AT" trademark). With few vendors other than IBM supporting it with computers or cards, MCA eventually failed in the marketplace. Most vendors of PC-compatibles stayed largely with ISA and manual configuration, while EISA offered the same type of auto-configuration featured in MCA. (EISA cards required a configuration file as well.)
In time, many ISA cards incorporated, through proprietary and varied techniques, hardware to self-configure or to provide for software configuration; often the card came with a configuration program on disk that could automatically set the software-configurable (but not itself self-configuring) hardware. Some cards had both jumpers and software-configuration, with some settings controlled by each; this compromise reduced the number of jumpers that had to be set, while avoiding great expense for certain settings, e.g. nonvolatile registers for a base address setting. The problems of required jumpers continued on but slowly diminished as more and more devices, both ISA and other types, included extra self-configuration hardware. However, these efforts still did not solve the problem of making sure the end-user has the appropriate software driver for the hardware.
See also
External Links
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2807178,00.html
|
| |
|
|
