Plug and Play (förkortat PnP), ordagrant översatt som "Plug and play (arbeta)" är en teknik som är utformad för att snabbt identifiera och konfigurera enheter i en dator och andra tekniska enheter. Beroende på hårdvarugränssnittet och mjukvaruplattformen (OS, BIOS) kan Plug and Play-proceduren utföras vid systemstart eller i hot swap -läge - detta görs till exempel för USB- och IEEE 1394 -gränssnitt [1] .
Vissa tidiga datorsystem, som Apple II , kan kräva att användaren löder om och skär stift på expansionskort för att omkonfigurera dem [2] . Denna omkonfigurationsteknik var komplex och minskade drastiskt utrustningens livslängd.
När datorer blev tillgängliga för en allt bredare publik började det krävas enklare, bekvämare och mer tillgänglig omkonfigurationsteknik. Inledningsvis föreslogs byglar (jumpers) och DIP -switchar istället för att skära och löda ledare för att ändra konfigurationen av expansionskort .
| Till vänster: Bygelblock i olika storlekar. Höger: DIP-omkopplarblock med 8 brytare | |
Senare automatiserades processen med att omkonfigurera expansionskort [3] .
MSX [4] släpptes 1983 och designades ursprungligen som ett Plug and Play-system. Detta implementerades med hjälp av ett speciellt organiserat system av expansionsplatser , som var och en, inklusive subslots i fallet med användning av en slotexpander (slotexpander) [5] , hade sitt eget virtuella adressutrymme, vilket eliminerade själva källan för möjliga adresskonflikter mellan enheter. För att konfigurera systemet var det inte nödvändigt att byta byglar eller utföra några andra procedurer i manuellt läge. Ett oberoende adressutrymme gjorde det möjligt att använda billiga mikrokretsar i expansionsenheter. Lagret av mellanlogik, som utförde vidarebefordran av virtuella adresser till riktiga, visade sig också vara mycket billigt att implementera.
På mjukvarusidan levererades drivrutiner och programtillägg i skrivskyddat minne , som finns på expansionskort. Detta gjorde det möjligt för ASCII Corporation att skapa ett system som inte krävde drivrutinsdiskar eller någon användarmanipulation av programvaran under installationen av ytterligare hårdvara. BIOS-tillägg installerade på ROM (ROM-tillägg i MSX-terminologi) tillhandahöll implementeringen av ett hårdvaruabstraktionslager (HAL) , vilket gjorde att programvaran kunde fungera med standardenhets-API, utan att vara uppmärksam på särdragen i dess hårdvaruimplementering.
Utvecklad 1984 vid Massachusetts Institute of Technology , var NuBus expansionsbussarkitektur tänkt [6] som ett plattformsneutralt gränssnitt med helautomatisk konfiguration av enheter anslutna till den. Gränssnittsspecifikationen inkluderade till och med simultant stöd för stora endian och little endian representationer av siffror, vilket brukade vara en av anledningarna till plattformsinkompatibilitet. Den ökade komplexiteten i att implementera ett plattformsneutralt gränssnitt, vilket krävde dyrare chip, var dock en faktor på 1980-talet som förhindrade ett omfattande antagande av detta gränssnitt.
1984 utvecklade Commodore Autoconfig- protokollet och Zorro- expansionsbussen för deras Amiga -familj av persondatorer . Utvecklingen presenterades först för allmänheten på Consumer Electronics Show , som hölls i Las Vegas 1985, under namnet "Lorraine", denna prototypteknologi. Precis som NuBus krävde enheter anslutna till Zorro-bussen inga byglar eller DIP-switchar. Information om enhetens konfiguration lagrades i expansionskortets ROM och värdsystemet allokerade de resurser det behövde till kortet under uppstart. Zorro-arkitekturen användes inte allmänt av industrin och användes i stort sett oanvänd utanför Amigas produktlinje . Den har dock successivt uppgraderats till Zorro II och 32-bitars Zorro III .
1987 släppte IBM en uppdaterad linje av IBM PC -modeller , känd som Personal System/2 -familjen , med hjälp av en ny expansionsbuss, Micro Channel Architecture [7] . PS/2 var kapabel till helautomatisk självkonfigurering . Var och en av expansionsenheterna kom med en diskett som innehåller en speciell fil för att konfigurera systemet. Användaren installerade ett expansionskort, slog på datorn, satte in en diskett och datorn tilldelade automatiskt avbrott, DMA-kanaler och andra resurser som krävs av kortet.
Jämfört med implementeringarna i systemen som nämns ovan hade detta automatiska konfigurationsschema en nackdel: disketten kunde skadas eller gå förlorad, och det enda sättet att återställa den nödvändiga inställningsfilen var att ta emot den från företaget via post eller ladda ner den från IBM BBS . Utan disken var den nya enheten helt värdelös, och datorn kunde inte starta upp ordentligt förrän enheten kopplades bort från expansionsbussen. Samtidigt var fördelen med detta tillvägagångssätt den teoretiska möjligheten att uppdatera den information som är nödvändig för driften av enheten.
MCA-bussen fick inte brett stöd [8] eftersom IBM förhindrade dess användning av oberoende tillverkare av IBM-PC-kompatibla datorer . Var och en av utvecklarna av MCA-kompatibla enheter undertecknade ett sekretessavtal med IBM och var tvungna att betala licensavgifter för varje enhet, vilket ökade deras kostnad.
EISA-standarden släpptes av ett konsortium av nio tillverkare av IBM-PC-kompatibla datorer och placerades som ett alternativ till MCA. Den hade en extremt liknande Plug and Play-implementering baserat på konfigurationsfilerna som följde med disketterna. Men till skillnad från MCA kan en dator med en okonfigurerad EISA-enhet fortfarande starta och fortsätta utan programvara åtkomst till enheten.
Liksom Micro Channel var EISA inte allmänt antagen, och själva tekniken och plug and play-implementeringen baserad på den utvecklades inte vidare.
ISA-bussen dök upp innan Plug and Play-tekniken började introduceras i system som använder den. I detta avseende använde expansionskort som arbetar med denna buss en mängd olika konfigurationstekniker, inklusive byglar, DIP-switchar, proprietära drivrutiner och verktyg och andra metoder i olika kombinationer. Utseendet på Plug and Play-kort i form av en specifikation från Microsoft komplicerade detta system ytterligare, särskilt eftersom olika operativsystem implementerade Plug and Play på olika sätt.
Allvaret i problemet med att sätta upp ISA-kort för slutanvändare togs bort, snarare inte genom införandet av Plug and Play, utan genom att denna standard gradvis försvann från bred cirkulation. Den nämnda Microsoft ISA PnP-specifikationen, även känd som Legacy Plug and Play , inkluderade krav på både hårdvaru- och BIOS- modifieringar och operativsystembeteende. Den förlorade sin relevans som PCI- standarduppslag , där Plug and Play-tekniken ursprungligen implementerades.
1995 släppte Microsoft Windows 95 , som för första gången försökte automatisera upptäckten av installerade enheter och deras konfiguration. I den mån det i allmänhet var möjligt och med implementeringen av läget för att återgå till manuell konfiguration av systemet, om nödvändigt. Under den första installationsprocessen av Windows 95 försökte den initialt identifiera alla enheter installerade på systemet. I den mån denna process inte stöddes fullt ut av branschen och inte hade bakåtkompatibilitet, skrev operativsystemet en logg där det markerade försök att automatiskt upptäcka enheter. Om datorn, som ett resultat av denna procedur, hängde sig, hade användaren fortfarande möjlighet att tvinga den att starta om. Processen med automatisk upptäckt av datorkonfigurationen under den nya uppstarten fortsatte med att hoppa över dess fas, vilket tidigare orsakade hängningen. Således kunde systemet gradvis gå igenom proceduren för att fastställa datorns konfiguration till slutet [9] .
Även om den ursprungliga implementeringen av VMEbus inte var Plug and Play, stöder ett antal tillägg och härledda standarder, såsom VME64x, Plug and Play. Generellt sett kan situationen med att konfigurera VMEbus-kompatibla kort jämföras med situationen med ISA-kort – inte fullt accepterade standarder kombineras med privata lösningar från enskilda tillverkare i godtyckliga kombinationer.
För närvarande har den största akutheten av problemet med automatisk upptäckt av datorkonfigurationen av operativsystemet för allmänna datorer tagits bort för länge sedan. De allra flesta enheter, expansionsgränssnitt och operativsystem stöder Plug and Play-procedurer.
Dessa gränssnitt inkluderar
och många andra.
Samtidigt, i de flesta fall, är användaren berövad kontroll över krångligheterna med att ställa in sina enheter och perifera gränssnitt på datorn. Till exempel delar gränssnitt som FireWire och USB bandbredd mellan alla enheter som är anslutna till en viss port på det gränssnittet, men användaren har ingen kontroll över hur bandbredden delas mellan dessa enheter. Den tillhandahålls automatiskt med hjälp av operativsystemet.