Plug and Play (abbr. PnP), traducido literalmente como "Plug and play (trabajo)" es una tecnología diseñada para identificar y configurar rápidamente dispositivos en una computadora y otros dispositivos técnicos. Según la interfaz de hardware y la plataforma de software (SO, BIOS), el procedimiento Plug and Play se puede realizar en la etapa de arranque del sistema o en modo de intercambio en caliente ; esto se hace, por ejemplo, para interfaces USB e IEEE 1394 [1] .
Algunos de los primeros sistemas informáticos, como el Apple II , pueden requerir que el usuario vuelva a soldar y corte los pines en las placas de expansión para reconfigurarlos [2] . Esta técnica de reconfiguración era compleja y reducía drásticamente la vida útil del equipo.
A medida que las computadoras estuvieron disponibles para una audiencia cada vez más amplia, comenzaron a requerirse tecnologías de reconfiguración más simples, más convenientes y más accesibles. Inicialmente se propusieron puentes (jumpers) y DIP switches en lugar de cortar y soldar conductores para cambiar la configuración de las tarjetas de expansión .
| Izquierda: bloques de puentes de varios tamaños. Derecha: bloque de interruptores DIP con 8 interruptores | |
Posteriormente, se automatizó el proceso de reconfiguración de las tarjetas de expansión [3] .
Lanzado en 1983, MSX [4] se diseñó originalmente como un sistema Plug and Play. Esto se implementó utilizando un sistema especialmente organizado de ranuras de expansión , cada una de las cuales, incluidas las subranuras en el caso de usar un expansor de ranuras (slot expander) [5] , tenía su propio espacio de direcciones virtuales, lo que eliminó la propia fuente para posibles conflictos de direcciones. entre dispositivos. Para configurar el sistema no fue necesario cambiar puentes ni realizar ningún otro procedimiento en modo manual. Un espacio de direcciones independiente hizo posible el uso de microcircuitos baratos en dispositivos de expansión. La capa de lógica intermedia, que realizaba la retransmisión de las direcciones virtuales a las reales, también resultó muy barata de implementar.
Por el lado del software, los controladores y las extensiones de software se enviaron en memoria de solo lectura , ubicada en tarjetas de expansión. Esto permitió a ASCII Corporation crear un sistema que no requería discos de controladores ni manipulación del software por parte del usuario durante la instalación de hardware adicional. Las extensiones de BIOS instaladas en ROM (ROM Extensions en terminología MSX) proporcionaron la implementación de una capa de abstracción de hardware (HAL) , que permitió que el software funcionara con la API estándar del dispositivo, sin prestar atención a las peculiaridades de su implementación de hardware.
Desarrollada en 1984 en el Instituto Tecnológico de Massachusetts , la arquitectura de bus de expansión NuBus fue concebida [6] como una interfaz de plataforma neutral con una configuración completamente automática de los dispositivos conectados a ella. La especificación de la interfaz incluso incluía soporte simultáneo para representaciones de números big endian y little endian , lo que solía ser una de las razones de la incompatibilidad de la plataforma. Sin embargo, la mayor complejidad de implementar una interfaz de plataforma neutral, que requería chips más caros, fue un factor en la década de 1980 que impidió la adopción generalizada de esta interfaz.
En 1984, Commodore desarrolló el protocolo Autoconfig y el bus de expansión Zorro para su familia de computadoras personales Amiga . El desarrollo fue presentado por primera vez al público en el Consumer Electronics Show , celebrado en Las Vegas en 1985, bajo el nombre de "Lorraine", este prototipo de tecnología. Al igual que NuBus , los dispositivos conectados al bus Zorro no requerían puentes ni interruptores DIP. La información sobre la configuración del dispositivo se almacenó en la ROM de la tarjeta de expansión y el sistema host asignó los recursos que necesitaba a la tarjeta durante el arranque. La arquitectura Zorro no fue ampliamente adoptada por la industria y en gran medida no se usó fuera de la línea de productos Amiga . Sin embargo, se ha actualizado sucesivamente a Zorro II y Zorro III de 32 bits .
En 1987, IBM lanzó una línea actualizada de modelos de PC IBM , conocida como la familia Personal System/2 , utilizando un nuevo bus de expansión, Micro Channel Architecture [7] . El PS/2 era capaz de una autoconfiguración totalmente automática . Cada uno de los dispositivos de expansión venía con un disquete que contenía un archivo especial para configurar el sistema. El usuario instaló una placa de expansión, encendió la computadora, insertó un disquete y la computadora asignó automáticamente interrupciones, canales DMA y otros recursos requeridos por la placa.
En comparación con las implementaciones en los sistemas mencionados anteriormente, este esquema de configuración automática tenía una desventaja: el disquete podía dañarse o perderse, y la única forma de restaurar el archivo de configuración necesario era recibirlo de la empresa por correo o descargarlo. de la BBS de IBM . Sin el disco, el nuevo dispositivo era completamente inútil y la computadora no podía arrancar correctamente hasta que el dispositivo fuera desconectado del bus de expansión. Al mismo tiempo, la ventaja de este enfoque era la posibilidad teórica de actualizar la información necesaria para el funcionamiento del dispositivo.
El bus MCA no recibió un amplio apoyo [8] porque IBM impidió su uso por parte de fabricantes independientes de computadoras compatibles con IBM-PC . Cada uno de los desarrolladores de dispositivos compatibles con MCA firmó un acuerdo de confidencialidad con IBM y tuvo que pagar tarifas de licencia en cada dispositivo, lo que aumentó su costo.
Lanzado por un consorcio de nueve fabricantes de computadoras compatibles con IBM-PC , el estándar EISA se posicionó como una alternativa a MCA. Tenía una implementación Plug and Play extremadamente similar basada en los archivos de configuración que venían con los disquetes. Sin embargo, a diferencia del MCA, una computadora con un dispositivo EISA no configurado aún podría iniciarse y continuar sin acceso de software al dispositivo.
Al igual que Micro Channel, EISA no se adoptó ampliamente, y la tecnología en sí y la implementación plug and play basada en ella no se desarrollaron más.
El bus ISA apareció antes de que la tecnología Plug and Play comenzara a introducirse en los sistemas que lo utilizan. En este sentido, las tarjetas de expansión que trabajaban con este bus usaban una amplia variedad de técnicas de configuración, incluidos puentes, interruptores DIP, controladores y utilidades propietarios, y otros métodos en varias combinaciones. La aparición de las tarjetas Plug and Play en forma de especificación de Microsoft complicó aún más este sistema, especialmente porque los diferentes sistemas operativos implementaron Plug and Play de diferentes maneras.
La gravedad del problema con la configuración de tarjetas ISA para usuarios finales se eliminó, más bien, no por la introducción de Plug and Play, sino por la salida gradual de este estándar de circulación generalizada. La especificación Microsoft ISA PnP mencionada, también conocida como Legacy Plug and Play , incluía requisitos para las modificaciones de hardware y BIOS y el comportamiento del sistema operativo. Perdió su relevancia a medida que se extendió el estándar PCI , en el que originalmente se implementó la tecnología Plug and Play.
En 1995, Microsoft lanzó Windows 95 , que por primera vez intentó automatizar la detección de dispositivos instalados y su configuración. En la medida en que generalmente fue posible y con la implementación del modo de volver a la configuración manual del sistema, si es necesario. Durante el proceso de instalación inicial de Windows 95, intentó identificar inicialmente todos los dispositivos instalados en el sistema. En la medida en que este proceso no estaba completamente respaldado por la industria y no tenía compatibilidad con versiones anteriores, el sistema operativo escribió un registro en el que marcaba los intentos de detección automática de dispositivos. Si, como resultado de este procedimiento, la computadora se colgó, el usuario aún tenía la oportunidad de forzar su reinicio. El proceso de autodetección de la configuración del equipo durante su nuevo arranque continuaba con el salto de su fase, que anteriormente provocaba el cuelgue. De esta forma, el sistema podría pasar gradualmente por el procedimiento de determinación de la configuración de la computadora hasta el final [9] .
Aunque la implementación original de VMEbus no era Plug and Play, varias extensiones y estándares derivados, como VME64x, admiten Plug and Play. En general, la situación con la configuración de placas compatibles con VMEbus se puede comparar con la situación con las placas ISA: los estándares no totalmente aceptados se combinan con soluciones privadas de fabricantes individuales en combinaciones arbitrarias.
En la actualidad, la principal agudeza del problema con la detección automática de la configuración de las computadoras por parte del sistema operativo para computadoras de uso general se ha eliminado durante mucho tiempo. La gran mayoría de dispositivos, interfaces de expansión y sistemas operativos admiten procedimientos Plug and Play.
Estas interfaces incluyen
y muchos otros.
Al mismo tiempo, en la mayoría de los casos, el usuario se ve privado del control sobre las complejidades de configurar sus dispositivos y las interfaces periféricas de la computadora. Por ejemplo, las interfaces como FireWire y USB comparten el ancho de banda entre todos los dispositivos conectados a un puerto particular en esa interfaz, pero el usuario no tiene control sobre cómo se comparte el ancho de banda entre estos dispositivos. Se proporciona automáticamente por medio del sistema operativo.