Plug-and-Play is perceived by many to be a very simple ...



Table of Contents

Section Page

Abstract………………………………………………………………………. 3

1. Introduction…………………………………………………………………... 4

2. History of Plug-and-Play……………………………………………………... 5

3. Installation of Hardware Components………………………………………... 6

a. Understanding Hardware and Software Devices/Drivers…………….. 6

b. Addresses and their Allocation……………………………………….. 7

c. Assigned Memory to Devices……………………………………….... 8

d. IRQs and what they mean…………………………………………….. 8

e. DMA channels………………………………………………………... 9

4. Plug-and-Play Allocation of these Resources………………………………… 10

5. What’s Necessary in you’re your System Today for Plug-and-Play…………. 11

6. Why the Title Plug-and-Pray…………………………………………………..12

7. Future of Plug and Play………………………………………………………..13

8. Conclusion……………………………………………………………………. 13

9. Bibliography………………………………………………………………….. 15

10. Attachments

a. Current hardware standards that are fully PnP compatible…………... 16

b. Diagram of Plug-and-Play at System Boot…………………………… 17

Abstract

Plug-and-Play is basically defined as the ability of a computer system to automatically configure new hardware devices. Thus, in a perfect world where Plug-and-Play works exactly as all the claims of manufacturers say, ‘you plug it in, it runs, you’re done”. A dream system where no DIP switches, jumpers, memory allocation, IRQ channel declarations or anything else needs to be acknowledged by the user, other then that he/she placed the hardware device is in there. They need to know nothing about any of the ‘magic’ that happens to make it work. Yet, Plug-and-Play seems to fail at consistently meeting all of these claims. The technology cannot be condemned and thrown out though because of a few failures in its still early life. Plug-and-Play does run into some errors in performance at this time, but the complexity of what it’s trying to perform for the user is very detailed and it can simplify some very difficult tasks for novice computer users. To truly understand this value of Plug-and-Play you must take a detailed look at the steps required in installing new hardware devices and how it performs at these steps.

Introduction

Today’s computer technology is advancing at a tremendous speed, which only seems to be ever increasing. The diversity of devices that can be added to computers for expanding their abilities can be both a benediction and a malediction. An average computer user can find the configuration and resource allocation necessary to install these devices to their system as the malediction component expanding the system. The reason for this hassle in adding devices is due to the multiple non-standard devices that are available on the market. This may very well be the most difficult and time-consuming part of maintaining a computer or upgrading its hardware with today’s expanding technologies.

Plug-and-Play is perceived by many to be a very simple concept and the actual execution of it is perceived to be the same, but the implementation to make it perform in the manner that many manufacturers claim is much more then a facile task. The concept has raised a great deal of attention and focus from PC experts, professors, magazines and the public in general. For this reason Plug-and-Play has been proclaimed to be everything from a ‘revolutionary idea’ to a nothing more then ‘plug-and-pray’. Yet, before any individual can make a decision on Plug-and-Play as a valuable technological tool or merely a computer science myth they must understand the “ins and outs” of plug-and-play.

For now we’ll oversimplify the definition of Plug-and-Play, until we get a more detailed look behind the concept. Plug-and-Play is a hardware and software standard for automatically informing software (device drivers) where it can find various pieces of hardware (devices) such as modems, network cards, video cards, etc. What this means is that Plug-and-Play's task is to pair up the physical devices with the software (device drivers) that operates them and form channels of communication from each physical device to its driver. For this to happen, Plug-and-Play assigns the following "bus-resources" to both the drivers and hardware: I/O addresses, IRQs, DMA channels (ISA bus only), and memory regions. This allocation of resources by Plug-and-Play is sometimes referred to as "configuring", but it’s only a low level form of configuring.

Looking at the definition of Plug-and-Play at such a generic level a basic outline can be constructed for the basic design rules of a play-and-play device. These simplified rules are:

1. The device is completely configurable by software. (No mechanical switches

or jumpers are allowed.)

2. The device can uniquely identify itself to any inquiring software.

3. The device is capable of reporting to the system about the resources it requires to operate.[1]

These rules may seem very simple, but there’s an extreme amount of technical detail behind how they are achieved between physical devices, software devices (device driver), and the system.

History of Plug-and-Play

The multiple problems that arise in upgrading hardware components of a computer are the problems that Plug-and-Play attempts to solve. In an attempt to resolve these problems, the Plug and Play (also called PnP) the first form of Plug and Play was actually first made available on the EISA and MCA buses. In 1988 the Gang of Nine (AST Research, Compaq Computer, Epson, Hewlett-Packard, NEC, Olivetti, Tandy, WYSE, and Zenith Data Systems) released the Enhanced Industry Standard Architecture (EISA) to counter IBM’s Micro Channel Architecture, ending IBM’s control of the PC standard. EISA was a bus architecture designed for PCs using an Intel 80386, 80486, or Pentium microprocessor. These buses are 32 bits wide and support multiprocessing. Along with these basics, EISA also had many unique features, not found in any bus before it:

• All EISA compatible devices are supposed to be fully software configured

• The Motherboard BIOS are supposed to automatically resolve conflicts to get any given system working

• EISA devices are supposed to uniquely identify themselves and their resource needs to any inquiring software

Micro Channel Architecture (MCA) was introduced by IBM in 1987, but got even less public attention, then EISA would get less then a year later. MCA was designed to take the place of the older AT bus, the architecture used on IBM PC-ATs and compatibles. MCA had many of the same basic features as EISA, but received little support from its own manufacturers.

A third, and much smaller, standard to appear at the time with some features resembling Plug-and-Play was from the Personal Computer Memory Card International Association (PCMCIA). PCMCIA is an organization consisting of approximately 500 companies that have developed a standard for small, credit card-sized devices. Originally designed for adding memory to portable computers, the PCMCIA standard has been expanded several times and is now suitable for many types of devices. There are in fact three types of PCMCIA cards. They’re supposed to grant you the ability to exchange PC Cards on the fly, without rebooting your computer. All three have the same rectangular size (85.6 by 54 millimeters), but different widths

• Type 1 cards (3.3 mm thick) are used for adding additional ROM or RAM to a PC.

• Type 2 cards (5.5 mm thick) are often used for modem and fax modem cards.

• Type 3 cards (10.5 mm thick), which is sufficiently large for portable disk drives.

As with the cards, PCMCIA slots also come in three sizes:

• Type 1 slots can hold one Type 1 card

• Type 2 slots can hold one Type 2 card or two Type 1 cards

• Type 3 slots can hold one Type 3 card or a Type 1 and Type 2 card

It did not take long for MCA to eventually die, where as EISA buses and PCMCIA technology still exist today with weak spots in the market. The market failed to accept the new architecture found in MCA and EISA at the time. Possibly because IBM failed to push their architecture because what they had was selling and working well enough at the time. IBM was gaining the stronghold on the market in that technology field, and at the point it’s theorized that they incorporated the idea of “why fix something, if it’s not broken.”

Plug-and-Play didn’t really hit the mainstream until 1995 with the release of Windows 95 and PC hardware designed to work with it. Microsoft developed specifications with cooperation from Intel and many other hardware manufacturers before the release of Windows 95. The goal of Plug and Play is to create a computer whose hardware and software work together to automatically configure devices and assign resources, to allow for hardware changes and additions without the need for large-scale resource assignment tweaking. As the name suggests, the goal is to be able to just plug in a new device and immediately be able to use it, without complicated setup maneuvers.

Installation of Hardware Components

Understanding Hardware and Software Devices/Drivers

How a computer system identifies its physical devices and software devices is the first important concept of Plug-and-Play. All systems contain a CPU (processor) for computing and RAM memory for data and program storage. There are also multiple devices within the computer, such as disk-drives, a video card, a keyboard, network cards, modem cards, sound cards, the USB bus, serial and parallel ports, etc. Along with a computer having a power supply to provide electric energy, various buses on a motherboard to connect the devices to the CPU, and a case to put all this into. This run down merely allows a novice to computer organization get an idea of the many components interconnected in a computer, and an understanding that drivers are necessary for all of these devices. From here, it’s beneficial to take a look at the evolution of hardware components and their drivers.

In the early days of computer systems all devices had their own plug-in cards (printed circuit boards). Today, in addition to plug-in cards, many "devices" are small chips statically mounted on the "motherboard". Along with this, cards that plug into the motherboard may hold one or more devices. A person may sometimes also refer to memory chips as devices, but they are not plug-and-play in the sense of the topic here.

For any computer system to work properly, each device has to be under the control of its "device driver". The device driver is software that is a part of the operating system and runs on the CPU. This driver may possibly be loaded as a module. Making this even more complicated is the fact that a particular device driver that is selected depends on the type specific device. A device must be assigned a particular driver that will work for that type of device. Thus, for example, each type of sound card has it’s own corresponding driver. There is no universal driver for all manufacturers’ sound cards, network cards, modems, etc.

To control a device, the CPU (under control of the device driver) sends commands (as well as data) to and reads from the various devices. For this to occur each device driver must know the address of the device that it controls. Knowing the address of this device is analogous to establishing a communication channel; though the physical "channel" is really the data bus inside the PC. The data bus is also shared with almost all other devices.

This idea behind the communication channel is very simplified in comparison to what it actually is though. An "address" for any device is actually a range of addresses. Along with this, there is also a reverse part of the channel that allows devices to send a request for help to their device driver. To better understand the complexity behind device addressing, there needs to be a more detailed look at this addressing system.

Addresses and Their Allocation

PCs have three types of address spaces: I/O, main memory, and configuration.[2] These three types of addresses share the same bus inside the PC. The way that a PC determines which space belongs to which address is by the voltage on certain dedicated wires of the PC's bus. These voltage levels designate that the space belongs to I/O, main memory, or configuration.

On a PCI bus, configuration addresses make-up a unique address space just like I/O addresses do. What type a memory address is on the bus (I/O address, or configuration address) depends on the voltage found on other wires (traces) of the bus. Addresses units are labeled as bytes, and a single address is only the location of a single byte. Yet, I/O and main memory addresses need more than a single byte, so a range of bytes is often used for addresses allocated to devices. The starting address of these ranges is labeled the "base address".

Originally devices were located in I/O addresses, but now they can use address space in main memory. In allocating I/O address to these devices there are two steps to remember:

1. Set the I/O address on the card (@ one of the registers)

2. Let its device driver know this I/O address

The first step is a simple one that occurs by the hardware device setting the address it will use in a register, but from there comes the more difficult parts as the device driver must obtain this address. These two steps must be done automatically, by software, or by entering the data manually into files. [3]

From here a common problem is found to arise with Plug-and-Play devices, because it’s required that before a device driver can use an address it must be set on the physical device. Yet, since device drivers will regularly start up soon after you boot the computer, drivers will try to access the device before a Plug-and-Play configuration program has set the address. This will often lead to an error in booting your PC.

Assigned Memory to Devices

In many cases devices are assigned address space in main memory. This is often referred to as "shared memory", "memory-mapped IO", or "IO memory". This memory is actually physically located on the device. Along with using this "memory", a device may also use conventional IO address space.

In plugging in a new device, you are also plugging in a memory module for main memory. When Plug-and-Play selects and assigns an address for a device, it often assigns a high memory address to the device so that it doesn't conflict with main memory chips. This memory may either be ROM (Read Only Memory) or shared memory. Shared memory is called this because it’s shared between the device and the CPU, which is running the device’s driver. Just as IO address space is shared between the device and the CPU, shared memory serves as a means of information "transfer" between the device and main memory. Though it’s IO, it’s still necessary for the card and the device driver to know where it is.

ROM on the other hand is different, because it’s most likely a program, possibly a device driver, which will be used with the device. In the case of ROM, it may need to be shadowed, meaning it’s copied to your main memory chips, in order to run faster. Once this occurs it’s no longer "read only".

IRQs and What They Mean

Other then the address, there is an Interrupt number that must be handled. The device driver knows the address of the hardware device, so it can send information and data to the device, but the Interrupt Number is what allows the device to send information to the device driver.

The system puts a voltage on a dedicated interrupt wire, located inside the bus, which is often reserved for each particular device. This voltage signal is called an Interrupt ReQuest (IRQ). There are the equivalent of 16 such wires in a PC and each of these leads to a particular device driver. For each wire there is a unique IRQ number. For a device to communicate back to its controller it must put its proper signal on the correct wire and the controller must listen for that interrupt on the proper wire. The IRQ number kept in the device defines which wire it sends help requests through. A device’s driver needs to know this IRQ number so that the device driver knows which IRQ line to listen on.

An Interrupt ReQuest is a devices way of calling out to the processor, and saying “I need help, show me some attention”. Device interrupts are fed to the processor using a special piece of hardware called an interrupt controller. The interrupt controller has 8 input lines that take requests from one of 8 different devices. The controller then passes the request on to the processor, telling it which device issued the request (which interrupt number triggered the request, from 0 to 7).

Originating with the IBM AT, a second interrupt controller expanded the system, as part of the expansion in the ISA system bus from 8 to 16 bits. The two interrupt controllers are cascaded together, in order to not alter the original controller. Thus, the first interrupt controller still has 8 inputs and a single output going to the processor. The second one has the same design, but it takes 8 new inputs, to double the number of interrupts, and its output feeds into input line 2 of the first controller. If any of the inputs on the second controller become active, the output from that controller triggers interrupt #2 on the first controller, which then signals the processor.

Thus, IRQ2 is now being used to cascade the second controller, so the AT's designers changed the wiring on the motherboard to send any devices that used IRQ2 over to IRQ9 instead. This means that any older devices that used IRQ2 now uses IRQ9, and if you set any device to use IRQ2 on an AT or newer system, it is really using IRQ9.

After the processor receives a request an Interrupt Controller, it passes it along to the device driver for that particular device. From here the device driver needs to know why the interrupt was issued (help was called), and take appropriate action(s) toward it.[4] Each driver has a built in routine that handles the response to an interrupt signal it receives, known as an Interrupt Handler.

A major difference between Plug-and-Play devices and those that must be manually installed comes in assigning IRQ numbers. In manually installing a new device to your system, it’s often required to set an IRQ number for the device by setting a DIP switch. This is a physical task that many computer owners of today, are not knowledgeable about and requires that an individual remove the cover to made adjustments inside their PC. Yet, with Plug-and-Play devices this manual alteration of your system (setting a DIP switch) is not required.

DMA Channels

DMA channels are another aspect important to Plug-and-Play that is only associated with the ISA bus. DMA stands for direct memory access, a technique that’s used for transferring data from main memory to a device without passing it through the CPU. This is where a device is permitted to take over the main computer bus from the CPU and transfers bytes directly to main memory. Without DMA channels the system would require that such a process took two steps:

1. Reading from I/O memory space for the device and putting these bytes into the CPU

2. Writing these bytes from the CPU to main memory

With DMA channels these two previous steps can usually be combined into one single step:

1. The process of sending the bytes directly from the device to memory along these channels.

The device needs to have such capabilities built directly into its hardware, so not all devices can do DMA. Computers that have DMA channels can transfer data to and from devices much more quickly than computers without DMA channels. One weakness to ISA buses with DMA capabilities is that the CPU can't do too much since the main bus is being used by the DMA transfer.

The DMA controller, built into the system chipset on modern PCs, manages standard DMA transfers. The original PC and XT had only one controller and supported 4 DMA channels (0 to 3). Originating with the IBM AT, a second DMA controller was added. Similar to the second interrupt controller added at the same time the second interrupt controller is cascaded with the first. With the two DMA controllers though, the first DMA controller is cascaded to the second and in the case of IRQs the second controller is cascaded to the first. This creates 8 DMA channels (0 to 7), and DMA 4 is usable, unlike with IRQ channels. All of the DMA channels, except channel 4 are accessible to devices on the ISA system bus because channel 4 is used to cascade the two controllers together. There is no rerouting as found with IRQ2 and IRQ9, because all of the original DMA channels (0 to 3) are still directly usable.

When a device on an ISA bus wants to do DMA it issues a DMA request (DRQ) using dedicated DMA request wires very similar to an interrupt request. DMA could actually be handled with interrupts but this would lead to some delays, so it's faster to do it by having a special type of interrupt known as a DMA request. DMA requests are numbered, much like interrupts, so as to identify which device is making the request. This number is represents the DMA channel. The return signal from a DMA request, known as a DMA Acknowledgement Signal, must operate on this same channel to be acknowledged by the device that originally sent the DMA request. Since DMA transfers and the main bus operate on the same channel, this number is also used to figure which one is using the channel. The motherboard holds registers that store the current status of each "channel". Thus, a device must know its DMA channel in order to issue a DMA request, and stores this number on a register found on the device itself.

As for the PCI bus, it doesn't actually have DMA but it has what is known as bus mastering. It works something like DMA, and may even sometimes be called DMA. This allows devices to temporarily become bus masters and transfer bytes as if the bus master was the CPU. This doesn't use any channel numbers since the organization of the PCI bus is such that the PCI hardware knows which device is currently the bus master and which device is requesting to become a bus master. Thus there is no allocation of DMA channels for the PCI bus.

Plug-and-Play Allocation of these Resources

The discussion of all resources necessary for the installation and implementation of a new device into a computer system shows the complex tasks that Plug-and-Play is supposed to simply for users. For a device to function properly in a system the piece of hardware must be linked to its specific device driver (controller). To link these components bus-resources must be allocated (I/O, Memory, IRQ's, DMA's) to both the physical device (hardware) and the device driver (software). For Plug-and-Play, the configuration register data is generally lost when the PC is powered down, so that the bus-resource data must be supplied to each device again as the PC is booted up.

A large load of the work involved in making Plug-and-Play function is performed by the system BIOS during the booting. At the appropriate step during the boot process, the BIOS will follow a procedure to determine and configure any Plug-and-Play devices it finds in your system. Here is a general layout of the steps the BIOS follows during boot, when managing a PCI-based Plug and Play system:

1. Create a resource table of the available IRQs, DMA channels and I/O addresses; those not already reserved for system devices.

2. Locate and identify all Plug-and-Play devices on the PCI and ISA buses.

3. Load the last known system configuration from the ESCD[5].

4. Compare the current configuration to the last known configuration.

(If they are unchanged, the system will continue with the boot; the rest of the boot-up continues from here.

5. If the configuration is unique from the previous record, the system begins reconfiguration. (Starting with the resource table by eliminating any resources being used by non-PnP devices.)

6. Check the BIOS settings to see if any new system resources have been reserved for use by non-Plug-and-Play devices and eliminate any of these from the resource table.

7. Assign resources to Plug-and-Play cards from the remaining resources in the table, and inform the devices of their new assignments.

8. Update the ESCD by saving the new system configuration.

(From here the rest of boot-up will continue.)

What’s necessary in your system today for Plug-and-Play

The hardware on most systems today, through the system chipset and system bus controllers, is capable of handling Plug-and-Play devices. This is built in to modern PCI-based systems, as this system was designed with Plug-and-Play in mind. Most of these same systems also support Plug-and-Play on their ISA bus, with special circuitry to link the two together for sharing resource information. Where older PCs with ISA-only or VL-bus system buses generally do not support Plug-and-Play.

Many of the devices that are available to add into your system today can be found with Plug-and-Play compatibility. Plug-and-Play is now supported for a wide variety of devices, from modems and network cards inside the box to printers and even monitors outside it. These devices must be Plug-and-Play aware so they can identify themselves when requested, and be able to accept resource assignments from the system when they are made.

The system BIOS plays an important role in making Plug-and-Play work. Routines built into the BIOS perform the actual work of collecting information about the different devices and determining what should use which resources. The BIOS also communicates this information to the operating system, which uses it to configure its drivers and other software to make the devices work correctly. Many older PCs have an outdated BIOS, but otherwise have support for Plug-and-Play in hardware and can be made fully Plug-and-Play compatible with a BIOS upgrade.

The last thing to look at is the operating system. This must be designed to work with the BIOS (and thus indirectly, with the hardware as well). The operating system sets up all low-level software, such as device drivers, that are necessary for the device to be used by applications. The operating system also notifies the user of changes to the configuration, and allows changes to be made to resource settings. Currently, the only mainstream operating system to declare full Plug-and-Play support is Windows 95.

Why the title Plug and Pray

Plug-and-Play, by the definition alone, writes itself off as the cure for all new hardware device implementation into your system. Yet, what happens when you use Plug-and-Play devices is you’re turning over control of your system’s configuration to your computer. Your computer can be top of the line for the time and it will still not bas as smart as a human. The system can take care of the simple situations, but can only do what it’s programmed to do and may not be able to handle more complicated ones. Your system might not know what to do when it has to move multiple components around in order to make the proper room and allocate the proper location to new devices. What this means is that the more complex your setup, the more likely you will need to manual "tweak" whatever Plug-and-Play comes up with by default. Then on some occasions and Plug-and-Play configuration may make things more complicated then taking the extra time and effort in the first place to manually install the device.

Plug-and-Play can often be set on performing an installation in a certain way. Instances may occur where the BIOS and operating system lock on putting a device at a location where you don’t want it or it conflicts with current devices in the system. Plug-and-Play may attempt to assign system resources (IRQs, Addresses, DMA channels, or etc.) that are already taken to new incoming devices because of failure to properly reorder and arrange multiple devices that are already in a system. This reflects back on the problem of Plug-and-Play not being so intelligent that it can restructure the location or arrangement of multiple resources to better organize a system for an incoming device. In many cases problems with Plug-and-Play are due to incorrect system configuration, manual overrides of Plug-and-Play devices through the Windows Device Manager, or incorrect BIOS settings.

Other minor problems also arise in Plug-and-Play where older systems or older components on a system (operating system, BIOS, hardware, etc.) are not fully compatible to Plug-and-Play. Many versions of Windows 95 still have problems with Plug-and-Play, which have supposedly been discovered and fixed with newer versions of Windows. This is true for hardware devices, which have also improved on their Plug-and-Play abilities over time. Yet, still today there are hardware and software devices on the market that are not Plug-and-Play compatible with one another. With two components that must be compatible with and share the same capabilities with one another, the odds of getting the two devices to function properly begins to decrease.

The problems with Plug-and-Play are less common now than they were in the first years that it was announced, but it is still a new advancement in technology. Technology as complex as Plug-and-Play, involving so many parts of a system, can be expected to contain bugs that need to be discovered and corrected. The time to fix such bugs is not something that can be fixed over night.

Future of Plug-and-Play

It’s very difficult to define the future of a technology that is still, in many peoples’ minds, in the development stage. As machines improve and Plug-and-Play approaches the peak of it’s learning curve with its users (like all new technology), then Plug-and-Play configuration of resources will improve, as well as users’ ability to work with the configuration it gives them. The user’s ability to understand Plug-and-Play configuration and the improvements in Plug-and-Play’s ability to perform more complex configurations of a system will increase hand-in-hand with time.

From more of a market analysis point of view the claims of manufacturers as having improved Plug-and-Play devices will continue to grow, because the idea of device installation being as simple as having to do nothing more then placing the device in the PC attracts buyers. Yet, with a market that’s growing and expanding as rapidly as computer technology, operating systems, BIOS, and system designs cannot keep it’s Plug-and-Play capabilities up to the pace of the current market.

This doesn’t mean that Plug-and-Play will not continue to improve with time. Manufacturers of devices are going to be the ones that find a way for their components to correspond with the Plug-and-Play performance of the majority of systems. When a device can’t be easily added to the majority of systems in the popular market, then that device’s manufacturer looses money. In no way will this solve all the problems, because there will always be an array of smaller producers for computer components and technology. Yet, most device and component producers will work toward making their products meet the Plug-and-Play capabilities of the popular market computer manufacturers.

To truly solve the problems found in Plug-and-Play there must be a stronger and stricter set of universal protocols on system devices/components. If you keep all manufacturers to having to meet more specific protocols in the devices they produce, then Plug-and-Play can be structured around these well-defined protocols. Thus, by meeting these protocols, then hardware, software devices, operating systems, BIOS and all other parts of a system will function more smoothly with each other.

All of these changes are not over night fixes for Plug-and-Play mistakes, but over time can make a change. There’s no time in the future when the idea behind Plug-and-Play will disappear from computers. Computers have become a common technology found in households across the world, and as long as there is a strong market and common use for them, the computer novice will rely heavily on Plug-and-Play.

Conclusion

The concept of Plug-and-Play takes on a very large task in claiming to make the instillation of new components into your computer system as simple as: “plug it in and watch it work”. In some instances Plug-and-Play can do some amazing things without the user needing to alter any of the settings in his or her computer. For novice computer users and individuals with a poor knowledge in computer structure, this may be a lifesaver; but for others it takes out the much-desired feeling of control and organization in personally installing new components to their computer system. It is important to remember in all this that Plug-and-Play is not a miracle worker and cannot do everything for you in all instances or should be perceived as that.

Plug-and-Play is still relatively new in the history of computers and will continue to improve with technology advancements. As card vendors release more Plug-and-Play devices and system vendors sell more PnP systems, installing new hardware will get easier. Thus, strengthening Plug-and-Play as a tool in computer systems. A good look at the advancements made in Plug-and-Play, since becoming a more visibly mainstream technology, will come from how successful Plug-and-Play may be in new and improving operating systems, such as Windows ME, XP and future systems.

Bibliography

Bigelow, Stephen J., Bigelow, Steven (1999). The Plug and Play Book. NewYork,

NY: McGraw-Hill Companies. 0071347747.

Dvorak, John C. (1994). “The Upgradability Scam.” PC Magazine., v13 n7, 93.

Ikeya, Brian (2002). “PCMCIA” URL:

Manes, Stephen (1994). “Plug and what? And when?” Information Week., 489, 80.

Steers, Kirk, (1995). “Does Plug and Play work?” PC World., v13, n8, 99-101.

(2001). “Plug-and-Play Problems.” Computer Reseller News., Sept. 24, 76.

Attachment 1: Current hardware standards that are ‘fully’ PnP compatible

PnPISA ISA bus cards

PCI bus cards

EISA bus cards

MCA bus cards

PCMCIA devices

EISA motherboards

MCA motherboards

PCI motherboards

Plug-and-Play motherboards (Plug-and-Play BIOS)

Plug-and-Play Comport devices

Plug-and-Play port devices (IEEE-1284)

Plug-and-Play Monitors (Vesa DDC)

(More devices, as advertised by specific companies ‘claim’ to be Plug-and-Play compatibles. This is a list as collected from searching through recent manufacturers that have licensed an instance of an above component as being Plug-and-Play compatible.)

-----------------------

[1] If the world was perfect and plug-and-play worked to it’s greatest abilities, then the device would also identify the preferred resources it wished to be allocated, as well as alternative sets of resources.

[2] The exception is that older ISA Buses lacks the configuration address space.

[3] Manual configuration of hardware devices can often lead to multiple problems, as users fail to realize or remember that they must allocate a memory address for the device as well as get this address to the device driver.

[4] For ISA bus each device generally requires an individual IRQ number. Yet, on a PCI bus and other special cases IRQ sharing is permitted.

[5] ESCD – Extended System Configuration Data - a format for storing information about Plug-and-Play devices in the BIOS. Windows and the BIOS access the ESCD every time you reboot your computer.

-----------------------

Boot System

Locate & Identify: Plug-and-Play Devices & non Plug-and-Play Devices on the PCI and ISA buses

Load the last System Configuration from ESCD

ESCD (Extended System Configuration Data)

Compare the current configuration to the last configuration.

If(original configuration == new configuration)

Continue Boot Process from this point

Else (begin reconfiguration)

Check BIOS to see if new system resources have been reserved by non-PnP devices and eliminate these from the resource table

Assign Resources to Plug-and-Play cards from remaining resource table

Update the ESCD by saving the new system configuration and continue Boot Process from this point

Diagram of Plug-and-Play at System Boot

by Garron D. Combs

Plug and Play, or Plug and Pray

CS 350: Computer Organization

Spring 2002

Section 2

Garron D. Combs

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download