Plug and play
Inom datorer är en plug and play ( PnP ) enhet eller datorbuss en med en specifikation som underlättar igenkänningen av en hårdvarukomponent i ett system utan behov av fysisk enhetskonfiguration eller användaringripande för att lösa resurskonflikter. Termen "plug and play" har sedan dess utökats till en mängd olika applikationer där samma brist på användarinställningar gäller.
Expansionsenheter styrs och utbyter data med värdsystemet genom definierade minnes- eller I/O- utrymmesportadresser, direkta minnesåtkomstkanaler , avbrottsbegäran och andra mekanismer, som måste vara unikt associerade med en viss enhet för att fungera. Vissa datorer gav unika kombinationer av dessa resurser till varje kortplats på ett moderkort eller bakplan . Andra konstruktioner tillhandahöll alla resurser till alla platser, och varje kringutrustning hade sin egen adressavkodning för de register eller minnesblock den behövde för att kommunicera med värdsystemet. Eftersom fasta tilldelningar försvårade utbyggnaden av ett system använde enheter flera manuella metoder för att tilldela adresser och andra resurser, såsom fasta byglar, stift som kunde kopplas ihop med tråd eller avtagbara remmar, eller omkopplare som kunde ställas in för särskilda adresser. Eftersom mikroprocessorer gjorde massmarknadsdatorer överkomliga, var mjukvarukonfiguration av I/O-enheter fördelaktig för att möjliggöra installation av icke-specialistanvändare. Tidiga system för programvarukonfiguration av enheter inkluderade MSX -standarden, NuBus , Amiga Autoconfig och IBM Microchannel. Till en början krävde alla expansionskort för IBM PC: n fysiskt val av I/O-konfiguration på kortet med bygelband eller DIP-switchar , men alltmer ISA-bussenheter arrangerades för mjukvarukonfiguration. År 1995 Microsoft Windows en omfattande metod för att räkna upp hårdvara vid uppstart och allokera resurser, som kallades "Plug and Play"-standarden.
Plug and play-enheter kan ha resurser tilldelade endast vid uppstart, eller kan vara hotplug- system som USB och IEEE 1394 (FireWire).
Historik för enhetskonfiguration
Vissa tidiga kringutrustningar för mikrodatorer krävde att slutanvändaren fysiskt klippte några ledningar och lödde ihop andra för att göra konfigurationsändringar; sådana förändringar var avsedda att vara i stort sett permanenta under hårdvarans livslängd.
I takt med att datorer blev mer tillgängliga för allmänheten, utvecklades behovet av att mer frekventa ändringar skulle göras av datoranvändare som inte var skickliga på att använda lödkolvar. Istället för att skära och löda anslutningar, utfördes konfigurationen med byglar eller DIP-switchar . Senare automatiserades denna konfigurationsprocess: Plug and Play.
MSX
MSX - systemet, som släpptes 1983, designades för att vara plug and play från grunden och uppnådde detta genom ett system av slots och subslots, där var och en hade sitt eget virtuella adressutrymme , vilket eliminerade enhetsadresserande konflikter i själva källan. Inga byglar eller någon manuell konfiguration krävdes, och det oberoende adressutrymmet för varje plats gjorde att mycket billiga och vanliga chips kunde användas, tillsammans med billig limlogik . På mjukvarusidan levererades drivrutinerna och tilläggen i kortets eget ROM, vilket kräver inga diskar eller någon form av användaringripande för att konfigurera programvaran. ROM-tilläggen abstraherade alla hårdvarudifferenser och erbjöd standard-API:er som specificerats av ASCII Corporation .
NuBus
1984 utvecklades NuBus -arkitekturen av Massachusetts Institute of Technology (MIT) som ett plattforms-agnostiskt perifert gränssnitt som helt automatiserade enhetskonfigurationen. Specifikationen var tillräckligt intelligent för att den skulle kunna fungera med både big endian och little endian datorplattformar som tidigare varit inkompatibla med varandra. Detta agnostiska tillvägagångssätt ökade dock gränssnittskomplexiteten och krävde stödchips på varje enhet, vilket på 1980-talet var dyrt att göra, och förutom dess användning i Apple Macintoshes och NeXT -maskiner, var tekniken inte allmänt använd.
Amiga Autoconfig och Zorro buss
1984 utvecklade Commodore Autoconfig -protokollet och Zorro-expansionsbussen för sin Amiga -linje av expanderbara datorer. Det första offentliga framträdandet var i CES-datormässan i Las Vegas 1985, med den så kallade "Lorraine"-prototypen. Precis som NuBus hade Zorro-enheter absolut inga byglar eller DIP-switchar. Konfigurationsinformation lagrades på en skrivskyddad enhet på varje kringutrustning, och vid uppstart tilldelade värdsystemet de begärda resurserna till det installerade kortet. Zorro-arkitekturen spred sig inte till allmän datoranvändning utanför Amigas produktlinje, utan uppgraderades så småningom som Zorro II och Zorro III för den senare iterationen av Amiga-datorer.
Mikrokanalarkitektur
1987 släppte IBM en uppdatering till IBM PC känd som Personal System/2- serien av datorer som använder Micro Channel Architecture . PS/2 var kapabel till helt automatisk självkonfigurering. Varje bit av expansionshårdvara gavs ut med en diskett som innehöll en speciell fil som användes för att automatiskt konfigurera hårdvaran för att fungera med datorn. Användaren skulle installera enheten, slå på datorn, ladda konfigurationsinformationen från disken och hårdvaran tilldelade automatiskt avbrott, DMA och andra nödvändiga inställningar.
Diskarna utgjorde dock ett problem om de skadades eller försvann, eftersom de enda alternativen vid den tiden att få ersättningar var via post eller IBM:s uppringda BBS -tjänst. Utan diskarna skulle all ny hårdvara vara helt värdelös och datorn skulle ibland inte starta alls förrän den okonfigurerade enheten togs bort.
Micro Channel fick inte brett stöd eftersom IBM ville utesluta klontillverkare från nästa generations datorplattform. Alla som utvecklade för MCA var tvungna att underteckna sekretessavtal och betala royalties till IBM för varje såld enhet, vilket satte en prispremie på MCA-enheter. Slutanvändare och klontillverkare gjorde uppror mot IBM och utvecklade sin egen öppna standardbuss, känd som EISA. Följaktligen försvann MCA-användningen förutom i IBM:s stordatorer.
ISA och PCI självkonfiguration
Med tiden inkorporerade många Industry Standard Architecture (ISA)-kort, genom egenutvecklade och varierade tekniker, hårdvara för att självkonfigurera eller tillhandahålla programvarukonfiguration; ofta kom kortet med ett konfigurationsprogram på disk som automatiskt kunde ställa in den mjukvarukonfigurerbara (men inte självkonfigurerande) hårdvaran. Vissa kort hade både byglar och mjukvarukonfiguration, med vissa inställningar kontrollerade av var och en; denna kompromiss minskade antalet byglar som måste ställas in, samtidigt som man undvek stora kostnader för vissa inställningar, t.ex. icke-flyktiga register för en basadressinställning. Problemen med nödvändiga byglar fortsatte, men minskade sakta eftersom fler och fler enheter, både ISA och andra typer, inkluderade extra hårdvara för självkonfigurering. Men dessa ansträngningar löste fortfarande inte problemet med att se till att slutanvändaren har rätt mjukvarudrivrutin för hårdvaran.
ISA PnP eller (legacy) Plug & Play ISA var ett plug-and-play-system som använde en kombination av modifieringar av hårdvara, system-BIOS och operativsystemsmjukvara för att automatiskt hantera resursallokering. Den ersattes av PCI- bussen under mitten av 1990-talet.
PCI plug and play (autokonfiguration) är baserad på PCI BIOS-specifikationen på 1990-talet, PCI BIOS - specifikationen ersattes av ACPI på 2000-talet.
Legacy Plug and Play
1995 släppte Microsoft Windows 95 , som försökte automatisera enhetsdetektering och konfiguration så mycket som möjligt, men fortfarande kunde gå tillbaka till manuella inställningar om det skulle behövas. Under den första installationsprocessen av Windows 95, skulle det försöka att automatiskt upptäcka alla enheter installerade i systemet. Eftersom fullständig automatisk detektering av allt var en ny process utan fullt branschstöd skrev detekteringsprocessen hela tiden till en loggfil för förloppsspårning under upptäcktsprocessen. I händelse av att enhetssondering skulle misslyckas och systemet skulle frysa, kunde slutanvändaren starta om datorn, starta om upptäcktsprocessen och installationsprogrammet skulle använda spårningsloggen för att hoppa förbi den punkt som orsakade den tidigare frysningen.
Vid den tidpunkten kunde det finnas en blandning av enheter i ett system, några som kan konfigureras automatiskt och vissa fortfarande använder helt manuella inställningar via byglar och DIP-switchar. Den gamla DOS-världen låg fortfarande på lur under Windows 95, och system kunde konfigureras för att ladda enheter på tre olika sätt:
- endast via Windows 95 enhetshanterarens drivrutiner
- med hjälp av DOS-drivrutiner som är inlästa i konfigurationsfilerna CONFIG.SYS och AUTOEXEC.BAT
- använder både DOS-drivrutiner och Windows 95 enhetshanterardrivrutiner tillsammans
Microsoft kunde inte hävda full kontroll över alla enhetsinställningar, så konfigurationsfiler kan innehålla en blandning av drivrutinsposter som infogats av den automatiska konfigurationsprocessen i Windows 95, och kan även inkludera drivrutinsposter som infogats eller ändrats manuellt av datoranvändarna själva. Enhetshanteraren i Windows 95 kan också erbjuda användarna ett urval av flera halvautomatiska konfigurationer för att försöka frigöra resurser för enheter som fortfarande behöver manuell konfiguration.
Även om vissa senare ISA-enheter kunde konfigureras automatiskt, var det vanligt att PC ISA-expansionskort begränsade sig till ett mycket litet antal val för avbrottsbegäran. Till exempel kan ett nätverksgränssnitt begränsa sig till endast avbrott 3, 7 och 10, medan ett ljudkort kan begränsa sig till avbrott 5, 7 och 12. Detta resulterar i få konfigurationsval om några av dessa avbrott redan används av någon annan enhet.
Hårdvaran på PC-datorer begränsade dessutom alternativen för enhetsexpansion eftersom avbrott inte kunde delas, och vissa multifunktionskort skulle använda flera avbrott för olika kortfunktioner, till exempel ett seriellt kort med dubbla portar som kräver ett separat avbrott för varje serieport.
På grund av denna komplexa driftsmiljö gav den automatiska identifieringsprocessen ibland felaktiga resultat, särskilt i system med ett stort antal expansionsenheter. Detta ledde till enhetskonflikter inom Windows 95, vilket resulterade i att enheter som skulle vara helt självkonfigurerande inte fungerade. Den opålitliga enhetens installationsprocessen ledde till att Plug and Play ibland kallas Plug and Pray .
Fram till cirka 2000 kunde PC-datorer fortfarande köpas med en blandning av ISA- och PCI-platser, så det var fortfarande möjligt att manuell ISA-enhetskonfiguration kunde vara nödvändig. Men med successiva versioner av nya operativsystem som Windows 2000 och Windows XP, hade Microsoft tillräckligt med inflytande för att säga att drivrutiner inte längre skulle tillhandahållas för äldre enheter som inte stödde automatisk identifiering. I vissa fall tvingades användaren köpa nya expansionsenheter eller ett helt nytt system för att stödja nästa version av operativsystemet.
Aktuella plug and play-gränssnitt
Flera helt automatiserade datorgränssnitt används för närvarande, som vart och ett inte kräver någon enhetskonfiguration eller annan åtgärd från datoranvändarens sida, förutom mjukvaruinstallation, för de självkonfigurerande enheterna. Dessa gränssnitt inkluderar:
- IEEE 1394 (FireWire)
- PCI , Mini PCI
- PCI Express , Mini PCI Express , Thunderbolt
- PCMCIA , PC Card , ExpressCard
- SATA , Serial Attached SCSI
- USB
- DVI , HDMI
För de flesta av dessa gränssnitt finns mycket lite teknisk information tillgänglig för slutanvändaren om gränssnittets prestanda. Även om både FireWire och USB har bandbredd som måste delas av alla enheter, kan de flesta moderna operativsystem inte övervaka och rapportera mängden bandbredd som används eller är tillgänglig, eller att identifiera vilka enheter som för närvarande använder gränssnittet. [ citat behövs ]
Se även
externa länkar
- Plug and play i Windows 2000 på ZDNet
- https://community.rapid7.com/docs/DOC-2150 Arkiverad 2013-05-12 på Wayback Machine