Vysoké učení technické v Brně. Fakulta informačních technologií DIPLOMOVÁ PRÁCE Hynek Urbiš

Vysoké učení technické v Brně Fakulta informačních technologií

DIPLOMOVÁ PRÁCE

2002

Hynek Urbiš

Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatně pod vedením Doc. Ing. Zdeňka Kotáska, CSc. a uvedl jsem všechny literární prameny a publikace, ze kterých jsem čerpal.

……………………… Hynek Urbiš

Tímto bych chtěl poděkovat svému vedoucímu Doc. Ing. Zdeňku Kotáskovi, CSc za cenné informace, které mi poskytl. Rovněž bych chtěl poděkovat za podporu, které se mi dostalo z jeho strany při řešení diplomové práce.

Abstrakt Tato diplomová práce popisuje jedno z možných řešení, jak připojit IDE zařízení pomocí USB sběrnice k počítači. Pro tyto účely byl navržen adaptér s obvodem Philips ISP 1581, který realizuje převod IDE rozhraní na USB rozhraní. Celý adaptér je řízen procesorem Atmel AT89C52. Návrh adaptéru byl proveden v rámci semestrálního projektu. Tato práce se zabývá způsobem, jakým bude připojené zařízení začleněno do hostitelského systému Windows 2000. Všechna možná řešení bylo nutno důkladně analyzovat a zvolit jedno pro navrhovaný adaptér. Součástí řešení je i implementace řidícího programu adaptéru, který musí korektně spolupracovat s hostitelským systémem a zároveň řídit komunikaci s IDE zařízením.

Klíčová slova : USB, Velkokapacitní zařízení, IDE, ATAPI, SCSI, Atmel, x51, Philips, ISP1581

Abstract This diploma thesis describes one of the feasible solutions how to interface IDE device to computer via USB port. For these purposes, an adapter based on Philips ISP 1581 was developed. The adapter converts USB interface to IDE interface and is controlled by Atmel AT89C52. The design of the adapter had been solved in my term project. This thesis describes possible solution how to integrate a device connected via this adapter into the Windows 2000 system. Before one of the feasible solutions was implemented, all possible solutions had to be analyzed and the most suitable one chosen to solve the problem. The principles of adapter firmware programming are described in the diploma project as well. This software which runs on the processor in the adapter must cooperate properly with the host system and control IDE device.

Key Words : USB, Mass Storage, IDE, ATAPI, SCSI, Atmel, x51, Philips, ISP1581

Obsah 1. Úvod 2. Charakteristika USB a IDE rozhraní

9 10

2.1. IDE rozhraní 2.2. USB rozhraní 2.3. Základní požadavky na adaptér

10 10 11

3. Současný stav daného problému

12

3.1. Stanovení požadavků na adaptér 3.2. Zhodnocení dosažených parametrů

12 12

4. Začlenění adaptéru do systému

14

4.1. Všeobecné výhody a nevýhody jednotlivých přístupů 4.1.1. Zařízení vyžadující pro správnou funkci vlastní ovladač 4.1.2. Zařízení, které patří do definované třídy zařízení a nepotřebuje vlastní ovladač 4.2. Podrobná analýza obou přístupů s ohledem na navrhovaný adaptér 4.2.1. Vlastní ovladač 4.2.2. Třída velkokapacitních USB zařízení (Mass Storage Class) 4.3. Výběr vhodného řešení

5. Třída velkokapacitních zařízení

14 14 16 16 16 18 19

20

5.1. Podmínky nutné pro správnou funkci 5.2. Vlastní protokol 5.2.1. Rozšiřující příkazy pro řidící koncový bod 0 5.2.2. Formát protokolu

6. IDE Rozhraní

20 20 21 22

26

6.1. Fyzické rozhraní 6.1.1. Topologie připojení 6.1.2. Význam jednotlivých signálů 6.1.3. Adresa registrů 6.2. Význam jednotlivých registrů 6.2.1. Data register 6.2.2. Error register 6.2.3. Features register 6.2.4. Sector Count register 6.2.5. Sector Number register, LBA (7:0) 6.2.6. Cylinder Low register, LBA (15:8) 6.2.7. Cylinder High register, LBA (23:16) 6.2.8. Device/Head register, LBA (27:24) 6.2.9. Command register 6.2.10. Status register 6.2.11. Alternate Status register

26 26 28 29 30 30 30 31 31 31 31 31 31 32 32 33

7

6.2.12. Device Control register 6.3. Komunikační protokoly 6.3.1. Identifikace a reset jednotky 6.3.2. Adresování u diskových jednotek 6.3.3. Typy přenosů dat 6.3.4. Kategorie příkazů 6.3.5. Popis vybraných příkazů

33 33 34 34 35 36 37

7. SCSI rozhraní 7.1. 7.2. 7.3. 7.4.

38

Základní charakteristika Transport příkazů Charakteristika některých příkazů Význam SCSI příkazů při komunikaci s adaptérem

8. Změny v obvodovém zapojení 9. Řidící program adaptéru

38 39 42 42

43 45

9.1. Základní charakteristika mikrokontroléru 9.2. Struktura programu 9.2.1. Obsluha přerušení 9.2.2. Rozdělení paměti 9.2.3. Pojmenovaná paměťová místa, konstanty, zdrojové soubory 9.3. Charakteristika jednotlivých bloků 9.3.1. Inicializace 9.3.2. USB část – koncový bod 0 9.3.3. USB část – koncový bod 1 9.3.4. Inicializace a komunikace s IDE zařízením 9.3.5. Transport a překlad SCSI příkazů na IDE

10. Závěr

45 45 46 46 47 47 47 48 52 53 54

55

10.1. USB protokol 10.2. Obvod Philips ISP 1581 10.3. IDE zařízení 10.4. Zhodnocení dosažených parametrů

55 56 56 57

Literatura Přílohy

59 61

8

1. Úvod Problematika připojování periferních zařízení k počítači je velmi rozsáhlá. Existuje mnoho možností, jak dané zařízení připojit, při čemž každé řešení má svá specifika. Pro každý problém je nutné zvážit, které požadavky jsou klíčové a na které není nutné klást tak velký důraz. Tímto problém se zabývá i tato práce, jejímž hlavním cílem je návrh a realizace adaptéru pro připojení IDE zařízení k počítači pomocí USB sběrnice. Celý problém lze rozdělit do tří částí. První se týká především návrhu samotného HW, který bude převod obou rozhraní fyzicky realizovat. Druhá část se týká začlenění adaptéru a připojených zařízení do operačního systému hostitelského počítače. S tímto problémem souvisí také třetí část problému, a to způsob, jak bude adaptér řízen a jak bude s hostitelem komunikovat. Všechny tyto problémy jsou řešeny v rámci mého ročníkového [1], semestrálního [2] a diplomového projektu. Problematika USB sběrnice a komunikace po ní je rozebrána v ročníkovém projektu. Semestrální projekt se zabýval obvodovým návrhem adaptéru bez jakéhokoli programového vybavení. V této diplomové práci tedy zbývá dořešit způsob začlenění zařízení do operačního systému a na základě zvoleného řešení implementovat řidící program adaptéru. Díky nově získaným poznatkům bylo nutné provést drobné změny v obvodovém návrhu adaptéru. Ten byl již realizován formou zapojení na nepájivém kontaktním poli. Obvod pro komunikaci po USB a IDE rozhraní byl připojen pomocí zhotoveného přípravku. Z těchto důvodů tyto dodatečné změny nečinily žádné vážné potíže. Celá práce je rozdělena do několika kapitol. Jednotlivé části se mohou zabývat analýzou daného problému spolu s naznačením možných řešení nebo mohou podat vysvětlení, proč bylo zvoleno konkrétní řešení a jakým způsobem byl problém vyřešen. Druhá kapitola velmi stručně uvádí základní charakteristiky obou rozhraní spolu s velmi zevrubnými popisem požadavků na adaptér. Tato kapitola je zde pro čtenáře, kteří neměli možnost seznámit se s předchozí dokumentací k tomuto problému. Třetí kapitola má za úkol seznámit čtenáře se současným stavem podobných zařízení na trhu. Důraz je především kladen na to, jak je dané řešení zdokumentováno a zda lze některé poznatky využít při vlastním návrhu. Jsou zde také zhodnoceny již dosažené parametry navrhovaného adaptéru. Kapitola čtvrtá rozebírá možné způsoby začlenění adaptéru a připojených zařízení do operačního systému hostitelského počítače. S tímto problémem úzce souvisí použitý komunikační protokol a také řidíci program adaptéru. Kapitola pátá popisuje zvolené řešení z kapitoly předchozí. Má především za úkol vysvětlit použitý komunikační protokol a způsob, jakým jsou data a požadavky přenášeny. Kapitola šestá vysvětluje všechny základní rysy IDE rozhraní. Podobně je koncipována i kapitola sedmá. Ta má za úkol vysvětli základní principy SCSI rozhraní. V kapitole osmé jsou popsány změny v obvodovém zapojení adaptéru. Většina informací uvedených v předchozích kapitolách je nutná pro správné pochopení výkladu o řidícím programu adaptéru. Tato problematika je popsána v kapitole deváté. Kapitola desátá má za úkol shrnout všechny dosažené výsledky spolu s vysvětlením, kterých parametrů se povedlo dosáhnout a kterých ne.

9

2. Charakteristika USB a IDE rozhraní V této části práce jsou popsány základní rysy obou rozhraní. Všechny vlastnosti a požadavky na dané rozhraní jsou definovány v příslušné specifikaci [3][6]. Následující podkapitoly slouží k nastínění problematiky návrhu daného adaptéru a celkovému uvedení čtenáře do problému.

2.1. IDE rozhraní Touto zkratkou je označeno paralelní rozhraní uvnitř počítače pro připojování zařízení, které slouží především pro ukládání uživatelských dat. Ve většině případů se jedná o pevné disky nebo jednotky CD-ROM. Samotné rozhraní používá speciální 40 žilový datový kabel. Dalším omezujícím faktorem je nemožnost připojovat tato zařízení za chodu. IDE rozhraní bylo navrhnuto jako vnitřní součást počítače a nepředpokládalo se, že by uživatel měl mít možnost toto rozhraní běžně používat pro připojení externích zařízení. Protože téměř všechny počítače kategorie PC mají toto rozhraní integrováno na základních deskách, objevilo se na trhu velké množství zařízení, které se připojují právě pomocí tohoto rozhraní. Není nutné zdůrazňovat, že díky tomuto masovému rozšíření jsou ceny zařízení připojených pomocí IDE rozhraní relativně nízké. Zvláštní skupinou jsou ATAPI zařízení. Tato zařízení využívají pro komunikaci s hostitelem fyzicky IDE rozhraní, avšak nepoužívají běžné IDE příkazy. Pro komunikaci se používá tzv. paketový přenos, kdy je požadavek na zařízení zabalen do paketu a do zařízení je dopraven celý paket jako datová struktura. Oproti tomu zařízení, které nepodporují paketový přenos, používají pro komunikaci s hostitele registrově orientovaný přístup. V tomto případě jsou parametry příkazu zapsány do registrů disku a následně je zapsán příkaz do příkazového registru. Typickým představitelem ATAPI zařízení jsou jednotky CD-ROM, kdy formát a obsah paketů vychází ze specifikace SCSI. Konkrétně se jedná o třídu SCSI zařízení, které ke komunikaci využívají příkazů patřící do skupiny MMC (Multi Media Command). Za zmínku stojí i maximální přenosová rychlost, která je podle poslední revize specifikace až 133MB/s. Je taktéž zaručena zpětná kompatibilita zařízení.

2.2. USB rozhraní Tato zkratka označuje univerzální sériovou sběrnici. Při návrhu tohoto rozhraní byl kladen důraz především na maximální možnou flexibilnost při připojování zařízení. V současné době je toto rozhraní součástí běžně používaného počítače. Hlavní výhodou je možnost připojovat zařízení za chodu. Celkově je podporováno velké množství zařízení a spolu s rozbočovači, což jsou zařízení pro rozšíření USB portů, je možno připojit k jednomu počítači až 127 zařízení. Důraz byl také kladen na nenáročnost obsluhy, kdy nejsou po uživateli požadovány žádné technické znalosti a veškerou detekci a konfiguraci zařízení provede samotný operační systém. V současné době existují dvě verze USB specifikace. Ta první je starší, je označována jako USB 1.1. a podporuje tzv. Low Speed zařízení a Full Speed zařízení. Low Speed zařízení jsou schopna komunikovat maximální rychlostí 1,5 Mb/s a Full Speed rychlostí 12Mb/s. Novější verze označovaná jako USB 2.0 podporuje navíc High Speed zařízení, která jsou schopna komunikovat až na rychlosti 480Mb/s. Novější specifikace je zpětně kompatibilní a k High Speed hostiteli lze připojit i Low Speed zařízení. Je nutné si uvědomit, že

10

celková přenosová kapacit je mezi zařízeními sdílená. USB zařízení můžu být buď zcela specifické a pak je ve většině případů nutné dodat k zařízení ovladač od výrobce pro konkrétní operační systém. Nebo se jedná o zařízení, které patří do některé definované třídy. K takovémuto zařízení pak není nutné dodávat ovladač. Ovladač je již součástí operačního systému a ten již umí toto zařízení řídit. Při návrhu takovéhoto zařízení je nutné splnit některé požadavky a případně se přizpůsobit používaným protokolům. Ve většině případů je to ale jednodušší, než vyvíjet svůj vlastní a spolehlivý ovladač.

2.3. Základní požadavky na adaptér V předchozích dvou kapitolách jsou uvedeny základní rysy obou rozhraní. Už z této zběžné specifikace jsou patrné výhody a nevýhody jednotlivých rozhraní. Z těchto důvodů by navrhovaný adaptér měl využít především silné stránky jednotlivých rozhraní a ty slabé co nejvíce potlačit. Velmi jednoduše lze adaptér charakterizovat takto : • • • •

Měl by umožňovat připojovat a odpojovat IDE zařízení za chodu počítače. Měl by být co nejednodušší na obsluhu. Měl by podporovat co možná největší množství IDE kompatibilních zařízení. Adaptér by neměl ovlivňovat výkonnost připojených zařízení.

Následující obrázek (Obrázek 2.1 Základní blokové schéma adaptéru) velmi zhruba znázorňuje blokové schéma adaptéru.

Obrázek 2.1 Základní blokové schéma adaptéru

11

3. Současný stav daného problému V daný okamžik se již na trhu začínají objevovat zařízení pro ukládání dat připojená k počítači pomoci USB sběrnice. Ve většině případů se jedná o jednoúčelové řešení od daného výrobce pro konkrétní zařízení. Nelze tedy tohoto adaptéru využít k připojení jiných zařízení. Druhou skupinou jsou univerzální adaptéry. Typickým přestavitelem je adaptér pro převod SCSI na USB nebo IDE na USB. Většina těchto zařízení je však podle USB specifikace verze 1.1 a při rychlostech dnešních zařízení je to dosti omezující faktor. Společným jmenovatelem výše uvedených řešení je absence jakékoli dokumentace. Vývoj HW je ve většině případů časově a především finančně náročný. Je tedy logické, že firmy, které jsou schopné daný produkt dodat, si chrání své know-how před zneužitím. Z pohledu návrhu adaptéru nezbývá než konstatovat, že ačkoli se již na trhu podobná zařízení někdy vyskytují, vzhledem k absenci dokumentace je nutné provést návrh adaptéru zcela znovu od samotného počátku. Celkově lze adaptéry pro převod těchto rozhraní považovat za velmi flexibilní a užitečné nástroje, v tomto případě v kombinaci s pevným diskem o velikosti 2,5“, které se používají především v přenosných zařízeních, získáme zařízení pro ukládání dat s obrovskou kapacitou. Při vhodné realizaci může být samotný adaptér velmi malý. Jistou vadou na kráse může být nutnost použití externího napájení. Samotný adaptér má nízkou spotřebu energie, bohužel to stejné nelze prohlásit o pevných discích. Hlavní výhodou všech USB zařízení je možnost připojit a odpojit zařízení za chodu.

3.1. Stanovení požadavků na adaptér Celý problém bylo nutné důkladně analyzovat a stanovit požadavky na navrhovaný adaptér. Všechny klíčové požadavky jsou uvedeny v následujících bodech : • • • • • • •

USB část by měla být podle specifikace verze 2.0. Data z IDE zařízení by neměla procházet přes řidící mikrokontrolér. Adaptér by měl podporovat dvě IDE zařízení. Adaptér by měl podporovat jak diskové, tak ATAPI zařízení. Měla by být zajištěna zpětná kompatibilita IDE zařízení. Při komunikaci s IDE zařízením by měl být použit co možná nejrychlejší komunikační protokol. Adaptér a připojená zařízení by měly být do systému začleněny co možná nejjednodušším způsobem.

3.2. Zhodnocení dosažených parametrů Problematika výběru obvodu pro komunikaci po USB a připojení IDE zařízení a řidícího mikrokontroléru je podrobně popsána v semestrálním projektu [2]. Z pohledu návrhu obvodové části adaptéru mohu konstatovat, že všechny požadavky na HW část adaptéru byly splněny. Podrobné blokové schéma zapojení je zobrazeno na následujícím obrázku (Obrázek 3.1 Podrobné blokové schéma zapojení). Zbývající požadavky na programové vybavení jak na straně hostitele, tak na straně

12

adaptéru jsou předmětem této práce a zhodnocení, zda byla daná kriteria splněna, bude uvedeno v závěru této práce.

Obrázek 3.1 Podrobné blokové schéma zapojení LCD display a stavové LED diody slouží především k ladícím účelům. Tato zařízení mohou být z adaptéru odstraněna nebo po úpravě řidícího programu mohou sloužit k informování uživatele o právě probíhajících operacích. Z psychologického pohledu by bylo vhodné zachovat alespoň stavové diody, aby uživatel měl přehled o stavu zařízení. Zařízení se může někdy nacházet ve stavu, kdy čeká na nějakou událost, ale vnější pozorovatel má pocit, že se nic neděje.

13

4. Začlenění adaptéru do systému Z pohledu USB sběrnice existují dva způsoby, jak může USB zařízení poskytnout své prostředky operačnímu systému. Toto členění vyplývá ze samotné definice univerzální sériové sběrnice [3]. • •

USB zařízení má ovladač dodaný výrobcem zařízení – přes tento ovladač jsou systému nabízeny všechny poskytované prostředky zařízení. USB zařízení patří do nějaké třídy zařízení – zařízení splňuje všechny požadavky dané třídy a systém je schopen sám využít všechny nabízené prostředky.

4.1. Všeobecné výhody a nevýhody jednotlivých přístupů V této části se pokusím výstižně shrnout výhody a nevýhody výše uvedených přístupů při připojování USB zařízení k hostitelskému systému. Všechny tyto úvahy jsou vztaženy k operačnímu systému Windows. U jiných operačních systémů lze očekávat velmi podobný přístup.

4.1.1. Zařízení vyžadující pro správnou funkci vlastní ovladač V současné době je psaní ovladačů pro operační systém velmi náročná záležitost. U systému Windows se prosazují především WDM ovladače (Windows Driver Model) [7]. Programátor musí mít dosti rozsáhlé znalosti o daném problému. Je třeba také zdůraznit, že veškerý kód ovladače běží v režimu jádra operačního systému. Tento kód není nijak hlídán a může přistoupit kamkoli. Pokud je ovladač naprogramovaný špatně, může změnit cokoli a stabilita systému je velmi vážně ohrožena. Většina takovýchto chybných operací končí zatuhnutím systému. Z výše uvedeného plyne, že i ladění vlastního ovladače je velmi náročná záležitost. Ovladače jsou koncipovány tak, že směrem nahoru ve struktuře ovladačů poskytují své služby ovladačům umístěným výše a zároveň mohou využívat služeb ovladačů umístěných ve struktuře pod daným ovladačem. Jedná se o zásobníkovou strukturu, kdy jeden ovladač může poskytovat své služby i více ovladačům nad sebou současně. Na nejnižší vrstvě se nacházejí ovladače, které ovládají příslušný HW. Požadavek na dané zařízení je potom vložen na vrchol zásobníku a ten je postupně zpracováván tak, že prochází směrem dolů jednotlivými ovladači zásobníku daného zařízení. Pokud daný ovladač je schopen požadavek splnit, tak danou operaci vykoná a výsledek operace pošle stejnou cestou, ale opačným směrem ve struktuře ovladačů. Příklad struktury ovladačů je zobrazen na následujícím obrázku (Obrázek 4.1 Příklad struktury ovladačů). Zvláštním typem ovladače je tzv. filtrový ovladač. Nejedná se o skutečný ovladač, ale o kód, který je schopen transformovat požadavky do jiné podoby, která je ovšem významově stejná. Celá koncepce se snaží minimalizovat duplicitu a nadbytečnost v jakékoli podobě. V případě dvou SCSI řadičů v systému si to lze představit tak, že v systému je pouze jeden obecný ovladač pro komunikaci po SCSI a dva ovladače pro konkrétní SCSI řadiče. Tyto ovladače transformují standardní požadavky do podoby vhodné pro konkrétní SCSI řadiče v systému. Stejným způsobem je také vyřešeno ovládání dvou fyzických USB hostitelů v systému. Tato technika je zobrazena na dalším obrázku (Obrázek 4.2 Vícenásobný výskyt zařízení stejného typu).

14

Obrázek 4.1 Příklad struktury ovladačů

Obrázek 4.2 Vícenásobný výskyt zařízení stejného typu

15

4.1.2. Zařízení, které patří do definované třídy zařízení a nepotřebuje vlastní ovladač Pokud chceme připojit USB zařízení do systému s využitím této koncepce, musí zařízení splňovat některé požadavky. Tento fakt lze považovat částečně za omezující, avšak existence příslušného ovladače v operačním systému značně zjednodušuje a urychluje návrh celého zařízení. Existuje několik základních kategorií, do kterých zařízení může patřit. Každá kategorie, třída zařízení může byt rozdělena do dalších podkategorií. Tyto podtřídy se mohou navzájem lišit a definovat své vlastní požadavky na připojené zařízení i když připojují zařízení stejného typu. Omezení a požadavky se týkají především použitého komunikačního protokolu a konfigurace jednotlivých koncových bodů USB zařízení. V následujících bodech jsou uvedeny některé třídy zařízení společně se základní charakteristikou. •

• • • •

HID Class (Human Input Device) – volně přeloženo se jedná o všechna polohovací a ovládací zařízení, která využívá člověk a pomocí nichž ovládá počítač. Tato kategorie je rozdělena do podtříd pro klávesnice, myši, pákové ovladače a podobná zařízení. Printer Class – třída zařízení, která umožňují tisk. Audio Class – třída zařízení pro práci se zvukem. IrDA Class – třída zařízení pro komunikaci pomocí infračerveného záření. Mass Storage Class – třída pro připojování zařízení uchovávající velké objemy dat. Tato kategorie je zajímavá z pohledu návrhu daného adaptéru.

Tento výčet slouží pouze k seznámení čtenáře s problematikou tříd USB zařízení a není kompletní. Všechny požadavky a veškerá dokumentace k jednotlivým kategoriím je dostupná na stránkách organizace starající se o vývoj USB sběrnice [8].

4.2. Podrobná analýza obou přístupů s ohledem na navrhovaný adaptér Cílem této podkapitoly je analyzovat oba přístupy z pohledu návrhu daného adaptéru a na základě zhodnocení obou přístupů vybrat jeden, pomocí kterého bude adaptér začleněn do operačního systému.

4.2.1. Vlastní ovladač V tomto případě lze problém rozdělit do dvou částí, které spolu navzájem souvisejí. První část problému se týká vlastního ovladače. Velmi důležité je zvolit vhodné umístění ovladače v již existující struktuře ovladačů. Existují dva přístupy. Nový ovladač bude začleněn tak, že se bude snažit využívat všechny dostupné služby již existujících ovladačů. Výsledkem je co možná nejjednodušší ovladač. Druhý přístup je celkově méně efektivní. Předpokládá se, že všechny požadavky bude zpracovávat vytvářený ovladač a bude na jedné straně spolupracovat pouze s operačním systémem a na druhé straně s připojeným zařízením. V tomto případě je tento přístup velmi neefektivní. Musela by se implementovat veškerá logická správa disku včetně souborových systémů. První přístup předpokládá zařazení nového ovladače tak, že veškerou logickou správu budou mít na starost již instalované ovladače a operační systém. Navrhovaný ovladač by se musel tvářit jako běžný IDE hostitel. Otázka ovšem zní, kam přesně tento nový ovladač v již existující struktuře ovladačů začlenit. S tímto souvisí i druhá část problému. Tím je používaný protokol pro komunikaci ovladače s adaptérem. Celý problém

16

je dosti komplikovaný, protože podrobná dokumentace ke skutečné implementaci správy diskových zařízení v systému Windows je jen velmi těžko k sehnání. Podrobnou dokumentaci se mi nepovedlo obstarat a čerpal jsem pouze z informací uvedených v MSDN [9]. Z této dokumentace vyplynulo, že samotný operační systém podporuje pouze SCSI zařízení. Všechna ostatní zařízení připojená pomocí jiného rozhraní jsou připojena pomocí speciálního ovladače, který transformuje SCSI příkazy na příkazy kompatibilní s daným rozhraním. Přibližná struktura ovladačů pro ovládání diskových a podobných IDE zařízení je uvedena na následujícím obrázku (Obrázek 4.3 Přibližná struktura ovladačů IDE rozhraní).

Obrázek 4.3 Přibližná struktura ovladačů IDE rozhraní Samotné psaní WDM ovladačů je velmi náročná činnost. Stále se musí mít na paměti bezchybnost ovladače. Toho lze docílit pouze důkladným testováním. Musíme mít na paměti drobné odlišnosti jednotlivých verzí Windows. WDM ovladače podporují pouze systémy Windows 98, Windows NT, Windows 2000 a Windows XP. Je také nutné správně ošetřit krizové situace, jako je například odebrání ovladače za provozu. Důležitá je také správná funkce podpory úspory elektrické energie. Typickým problémem je ovladač, který nepodporuje režimy úspory energie, a celý systém potom nemůže přejít do některého z úsporných režimů. Dosti podrobně je tento problém popsán v [7].

17

4.2.2. Třída velkokapacitních USB zařízení (Mass Storage Class) Tato kategorie zařízení je definovaná v implementačním fóru [8] společnosti vyvíjející USB sběrnici. Primárně je tato třída určena pro připojování všech zařízení, která jsou schopna uchovávat velké množství uživatelských dat. V rámci tohoto standardu [4] existuje několik podtříd, které definují používané příkazy a jsou vhodné pro určité skupiny zařízení. Všechny USB zařízení musí mít koncový bod číslo 0 nakonfigurován pro řidící přenosy. Pomocí tohoto koncového bodu hostitelský systém připojené zařízení detekuje a nakonfiguruje. Pro tuto třídu existují dvě možné konfigurace ostatních koncových bodů USB zařízení pro přenos požadavků a dat z připojeného zařízení a zpět. •

•

In a Out Bulk EndPoint – pro přenos dat, příkazů a stavu zařízení je použita jedna In Bulk roura (směrem k hositeli) a jedna Out Bulk roura (směrem od hostitele). Přenosy typu Bulk lze charakterizovat takto : není definovaná žádna doba, za kterou musí být data doručena. Jakmile je v časovém schématu sběrnice prostor, jsou přenášena data tohoto typu. U tohoto typu přenosu je zaručena bezchybnost a uspořádanost dat. Tato konfigurace koncových bodů je v terminologii velkokapacitních zařízení označovaná jako Bulk Only. In, Out Bulk EndPoint a Interrupt EndPoint – charakteristika obou Bulk koncových bodů je stejná jako v předchozím případě, pro přenos stavových informaci směrem k hostiteli se používá Interrupt roura. Tu lze charakterizovat takto : je zaručena bezchybnost a uspořádanost přenášených dat, je definována maximální doba, za jakou musí být data přenesena od vzniku požadavku. Tato konfigurace koncových bodů je v terminologii velkokapacitních zařízení označovaná jako CBI (Control, Bulk, Interrupt).

Každá z těchto dvou možných konfigurací používá svůj vlastní protokol. V rámci tohoto protokolu jsou přenášeny i požadavky na zařízení. Formát požadavků na zařízení je částečně volitelný, většinou vychází z již existujícího protokolu. Používaný protokol zařízení specifikuje ve svém Device Deskriptoru, a to položkou SubbClass Code, což odpovídá podtřídě dané třídy zařízení. Přehled používaných příkazů spolu s přibližnou charakteristikou je uveden v následujících bodech. Za zmínku jistě stojí fakt, že všechny použité příkazy jsou založeny na SCSI protokolu, což koresponduje s principem ovládání diskových zařízení v operačním systému Windows. •

• • • • •

Reduced Block Command – redukovaná skupina příkazů určená pro zařízení s blokově orientovaným přístupem k datům na médiu. Tato sada převzala pouze některé příkazy ze skupiny všech příkazů pro blokově orientované zařízení. Typickým představitel této skupiny zařízení je pevný disk SFF-8020i, MMC-2 – příkazy používané pro přístup mechanikám DVD a CD-ROM, ze specifikace MMC-2 vychází také specifikace ATAPI příkazů na IDE rozhraní QIC-157 – tato skupina příkazů je určena pro přístup k páskovým zařízením UFI – skupina příkazů určená pro disketové jednotky SFF-8070i - skupina příkazů určená pro disketové jednotky a další zařízení, kterým bude vyhovovat existující sada příkazů Transparent SCSI – standardní sada SCSI příkazů

18

Problém výběru skupiny příkazů, které bude adaptér podporovat, je trošku složitější, než se může na první pohled zdát. Příslušnost USB zařízení do příslušné třídy a podtřídy je definována v deskriptoru zařízení. Tyto informace hostitelský systém získává v okamžiku detekce a konfigurace zařízení. Z toho plyne, že v okamžiku detekce USB zařízení by adaptér už musel mít informace o připojených IDE zařízeních. Tento problém je relativně jednoduše řešitelný. Druhý problém je ovšem závažnější. Pokud má adaptér podporovat dvě IDE zařízení, a mohou to být jak disky tak ATAPI zařízení, musíme vyřešit problém transportu příkazů pro diskové zařízení a pro ATAPI zařízení současně. Tento problém by se dal vyřešit existencí dvou nezávislých rozhraní (interface) v USB zařízení, což specifikace umožňuje. Každé zařízení by mělo své rozhraní, které patří do třídy velkokapacitních zařízení a používalo by příslušný protokol. Toto řešení neúměrně zvětšuje složitost řidícího programu mikrokontroléru. Procesor má rovněž omezené paměťové možnosti. Z těchto důvodů je možné použít pouze jedno rozhraní (interface) spolu s plnou sadu SCSI příkazů a k rozlišení obou IDE jednotek použít logické číslo jednotky LUN (Logic Unit Number). Toto číslo je vždy specifikováno v každém záhlaví požadavku na zařízení. Jednotlivé požadavky nemohou být zpracovány překrývaně, a tím je vyřešen i problém souběžného přístupu k IDE zařízením. Protože protokol používaný v konfiguraci Bulk Only je o něco jednoduší a zároveň je tato problematika lépe zdokumentována, věnoval jsem větší pozornost právě tomuto možnému řešení spolu s plnou sadou SCSI příkazů.

4.3. Výběr vhodného řešení V předchozí části této kapitoly jsou pospány všechny základní rysy obou přístupů spolu s analýzou vztaženou k danému problému. Na základě těchto poznatků je nutné vybrat jedno řešení a využít je při návrhu adaptéru. Za předpokladu, že se pro navrhovaný adaptér vytvoří nový ovladač, získám možnost specifikovat si svůj vlastní protokol pro komunikaci se zařízením. O tom, jaký formát příkazů bude použit, rozhoduje umístění ovladače v celkové struktuře ovladačů. Je možné implementovat překlad příkazů v samotném ovladači. Druhým možným řešením při použití vlastního ovladače je pouze posílat požadavky přímo zařízení a to si je transformuje do vhodné podoby a následně zpracuje. V tomto případě by se jednalo o velmi jednoduchý ovladač. Nevidím však důvod, proč instalovat do systému nový ovladač, když obdobný je v něm již obsažen. Řešení s vlastním jednoduchým ovladačem je ekvivalentní s zařazením navrhovaného adaptéru do příslušné třídy USB zařízení. Jak je uvedeno výše, tvorba ovladačů je zdlouhavá a náročná činnost a z těchto důvodů je lepší se tomuto problému vyhnout. To byl ten hlavní důvod, proč jsem navrhovaný adaptér zařadil do třídy velkokapacitních zařízení a využil již existující protokol včetně sady plných SCSI příkazů. Další výhodou je možnost připojit zařízení bez nutnosti instalovat ovladače z diskety. Tato výhoda se týká pouze systémů Windows 2000 a Windows XP. U systému Windows NT a Windows 98 je nutné k adaptéru dodat inf soubor, který systému řekne, jak má zařízení ovládat a který svůj ovladač má použít. USB rozhraní se používá na jiných SW i HW platformách. Pokud tedy zařízení patří do nějaké třídy a daný systém podporuje danou třídu, je zajištěna funkčnost těchto zařízení. Při hledání dokumentace k velkokapacitním zařízením jsem narazil na diskusní skupiny věnované platformě MacOS. Ze zběžného studia příspěvků vyplynulo, že tuto třídu zařízení podporuje i tento systém a adaptér by měl být funkční i v těchto systémech.

19

5. Třída velkokapacitních zařízení Tato kapitola má za úkol seznámit čtenáře s komunikačním protokolem používaným u velkokapacitních zařízení s využitím jednoho In Bulk a jednoho Out Bulk koncového bodu. Pro úplné pochopení všech principů a porozumění všem termínům v této a následujících kapitolách je nutné mít základní znalosti o logické struktuře USB sběrnici [3][1]. Tyto informace si lze nejlépe doplnit v dokumentaci k USB, a to v části věnované formátu paketů (kapitola 8, Protocol Layer) a struktuře používaného protokolu včetně všech používaných standardních příkazů (kapitola 9,USB Device Framework) [3]. Další informace k této třídě zařízení lze získat v [5].

5.1. Podmínky nutné pro správnou funkci Pokud má adaptér správně komunikovat, musí být splněno několik základních podmínek. Zařízení musí mít nastaveny správně příznaky příslušnosti k dané třídě. Toto nastavení lze uskutečnit dvěma způsoby. Do dané třídy patří buď celé zařízení, nebo alespoň jedno z rozhraní (interface). Klíčové jsou tyto položky v deskriptorech zařízení. • • •

bInterfaceProtocol – hodnota této položky musí být nastavena na 50h. Toto číslo říká, že rozhraní (interface) používá pouze Bulk Only konfiguraci koncových bodů bInterfaceClass – hodnota této položky musí být nastavena na 08h. Tato hodnota určuje třídu velkokapacitních zařízení. bInterfaceSubClass – hodnota této položky určuje, která skupina příkazů bude používána. Navrhovaný adaptér bude používat plné SCSI příkazy, a proto musí být hodnota této položky 06h.

Názvy položek odpovídají konfiguraci zařízení, kdy každé rozhraní (interface) může patřit do jiné třídy zařízení. Pokud celé zařízení patří do dané kategorie, je nastavení obdobné. Tuto strategii jsem volil z důvodu další rozšířitelnosti. Pokud bych chtěl doimplementovat diagnostické funkce adaptéru, přidal bych pouze další rozhraní (interface), které by nepatřilo do žádné třídy. Pokud by celé zařízení patřilo do příslušné třídy, nebylo by to možné. Pro správnou funkci je dále nutné nakonfigurovat jeden koncový bod směrem k hostiteli a jeden směrem k zařízení. Oba koncové body jsou typu Bulk. Jednou ze zvláštností této třídy zařízení je, že sériové číslo výrobku uložené v textovém řetězci v deskriptoru zařízení může obsahovat pouze znaky 0 až 9 a velká písmena A až F.

5.2. Vlastní protokol Tato podkapitola se zabývá vlastním protokolem. V tomto okamžiku se stává komunikace pomocí USB sběrnice transparentní. Celé si to lze představit tak, že máme dvě roury. Jednu pro dopravu dat směrem k hostiteli a jednu směrem od hostitele. Tuto transparentnost velmi jemně narušují pouze dva příkazy, o které je rozšířena sada příkazů pro detekci a konfiguraci USB zařízení. Tato komunikace probíhá na koncovém bodu 0 pro kontrolní přenosy.

20

5.2.1. Rozšiřující příkazy pro řidící koncový bod 0 Tato skupina příkazů je označována jako požadavky specifické pro danou třídu (class-specific request). Zpracování těchto příkazů probíhá stejně jako zpracování všech povinně implementovaných příkazů pro detekci a konfiguraci zařízení. Bulk-Only Mass Storage Reset – tento příkaz slouží pro reset zařízení v případě, kdy se z nějakého důvodu nepodaří komunikovat pomocí daného protokolu. Nulováním se rozumí incializace připojeného zařízení a ne reset adaptéru a obvodu pro komunikaci po USB sběrnici. Po provedení tohoto příkazu jsou znovu zinicializovány koncové body, které používá zařízení třídy velkokapacitních zařízení, a je znovu inicializován program pro zpracování protokolu. Formát příkazu je uveden v následující tabulce (Tabulka 5.1 Formát příkazu Bulk-Only Mass Storage Class). Názvy a význam položek vychází z USB specifikace. bmRequestType

bRequest

wValue

wIndex

wLength

Data

00100001b

11111111b

0000h

Interface

0000h

None

Tabulka 5.1 Formát příkazu Bulk-Only Mass Storage Class V položce wIndex je specifikováno, pro které rozhraní (inteface) USB zařízení je příkaz určen. Hodnota None v položce Data určuje, že je použito pro potvrzování schéma bez přenosu dat. Get Max LUN – pomocí tohoto příkazu zjistí hostitel počet logických jednotek zařízení (LUN). Pokud zařízení nepodporuje více logických jednotek, může vrátit chybu (STALL). Každé SCSI zařízení může v sobě integrovat více logických zařízení. Lze si to představit jako multifunkční zařízení, které umí tisknout, scanovat, posílat faxy a je připojeno k počítači pomocí jednoho SCSI rozhraní. Každé takovéto zařízení dostane přiděleno své číslo logické jednotky, pomocí kterého je následně adresováno. V navrhovaném adaptéru bude této techniky využito pro rozlišení IDE jednotek. Formát příkazu je opět uveden v následující tabulce (Tabulka 5.2 Formát příkazu Get Max LUN). bmRequestType

bRequest

wValue

wIndex

wLength

Data

10100001b

11111110b

0000h

Interface

0001h

In

Tabulka 5.2 Formát příkazu Get Max LUN Položka wIndex určuje rozhraní (interface), pro které je příkaz určen, stejně jako v předchozím případě. Hodnota In v položce Data určuje, že bude použito schéma pro přenos dat směrem k hostiteli. Logické jednotky mohou být adresovány v rozsahu 0 až 15, a proto na zjištění počtu stačí jeden byte. Tato hodnota je uložena v položce wLength a určuje maximální množství dat, které může být posláno.

21

5.2.2. Formát protokolu Protokol nepodporuje přenos dat oběma směry v rámci jednoho požadavku. Skládá se ze tří částí, které na sebe navazují. V první fázi je doručen požadavek. Tento požadavek je zabalen do datové struktury pojmenované Command Block Wrapper (CBW). Následuje přenos dat směrem k hostiteli nebo k zařízení. V této fázi také nemusí být přenesena žádná data. Následuje přenos stavových informací o úspěšnosti nebo neúspěšnosti daného příkazu. Tato informace je zabalena do datové struktury pojmenované Command Status Wrapper (CSW). Tento princip je zobrazen na následujícím obrázku (Obrázek 5.1 Fáze protokolu pro transport příkazů). Žádný další příkaz nesmí být poslán dříve než zařízení vrátí informaci o tom, jestli předchozí příkaz byl úspěšně nebo neúspěšně zpracován.

Obrázek 5.1 Fáze protokolu pro transport příkazů Jak u CBW, tak u CSW jsou byty u více-bytový položek uspořádány tak, že významově nižší bity jsou na nižší adrese a významově vyšší bity jsou na vyšší adrese (little endian).

22

Command Block Wrapper (CBW) – Tato datová struktura je vždy 31 bytů dlouhá a každá položka je vždy zarovnána na násobek bytu. Využívá se k přenosu požadavků směrem k zařízení. Význam a uspořádání jednotlivých položek je zobrazeno v následující tabulce (Tabulka 5.3 Struktura CBW). Bit Byte

7

6

5

4

3

2

0-3

dCBWSignature

4-7

dCBWTag

8-11

dCBWDataTransferLength

12

bmCBWFlags

13 14 15-30

Rezervováno

1

0

bCBWLUN

Rezervováno

bCBWCBLength CBWCB Tabulka 5.3 Struktura CBW

Význam jednotlivých položek : • dCBWSignature – slouží pro snažší identifikaci začátku CBW. Hodnota uložená v těchto 4 bytech je vždy 43425355h. • dCBWTag – tato položka slouží k identifikaci jednotlivých požadavků. Tato hodnota je překopírována do CSW a hostitel si tímto způsobem ověřuje, že zařízení opravdu vrací výsledek příkazu na zadaný požadavek. Tato hodnota přiřazuje k CBW příslušný CSW, i když tento protokol nedovoluje zahájit zpracování dalšího požadavku, dokud nebyl vrácen stav předchozího požadavku. • dCBWDataTransferLength – velikost dat přenášených do zařízení nebo k hostiteli mezi CBW a CSW fází. Směr přenosu je určen příznakovým bitem. Pokud je velikost přenášených dat 0, nemá bit určující směr žádný význam a nebudou přenášena žádná data. • bmCBWFlags – v této položce má význam pouze bit 7, který určuje směr přenosu dat mezi CBW a CSW. Hodnota 0 určuje směr přenosu k zařízení, hodnota 1 směrem k hostiteli. Bit 6 je vypuštěn a měl by být nula, bity 0 až 5 jsou rezervovány a také nulové. • bCBWLUN – určuje číslo logické jednotky, pro kterou je příkaz určen. • bCBWCBLength – určuje délku platných dat v CBWCB, jedná se o délku příkazového bloku. Povolené délka je 1 až 16. • CBWCB – v této položce je přenášen samotný příkaz, podtřída, do které dané USB zařízení patří, určuje, která skupina příkazů bude v této části přenášena. SCSI příkazy mají několik formátů a délek. Skutečná délka příkazu je uložena v položce bCBWCBLength. Pokud je délka příkazu kratší než celková velikost CBWCB (16 bytů), musí se zbývající byty ignorovat.

23

Command Status Wrapper (CSW) – Tato datová struktura je vždy 13 bytů dlouhá a každá položka je vždy zarovnána na násobek bytu. Využívá se k přenosu výsledku požadavků směrem k hostiteli. Význam a uspořádání jednotlivých položek je zobrazeno v následující tabulce (Tabulka 5.4 Struktura CSW). Bit Byte

7

6

5

4

3

0-3

dCSWSignature

4-7

dCSWTag

8-11

dCSWDataResidue

12

bCSWStatus

2

1

0

Tabulka 5.4 Struktura CSW Význam jednotlivých položek : • dCSWSignature – slouží pro snažší identifikaci začátku CSW. Hodnota uložená v těchto 4 bytech je vždy 53425355h. • dCSWTag – hodnoto získaná z příslušného CBW. Tato značka určuje příslušnost toho CSW k CBW. Hostitel takto může ověřit správnou komunikaci. • dCSWDataResidue – tato hodnota určuje rozdíl mezi skutečnou a deklarovanou délkou přijatých nebo poslaných dat v závislosti na směru přenosu dat. • bmCSWStauts – v této položce je vrácen příznak toho, zda zaslaný požadavek byl nebo nebyl úspěšně zpracován. Nenulová hodnota indikuje chybu. Význam jednotlivých hodnot je uveden v následující tabulce (Tabulka 5.5 Návratové hodnoty CSW).

Hodnota

Význam

00h

Požadavek zpracován bez chyby

01h

Nepovedlo se zpracovat požadavek

02h

Chyba při komunikaci - zpracování některé fáze se nepovedlo

03h, 04h

Rezervováno (vynecháno)

05h až FFh

Rezervováno Tabulka 5.5 Návratové hodnoty CSW

Při práci se zařízením může dojít k chybě a ve většině případů je nutné pro odstranění problému provést reset části starající se o komunikaci pomocí tohoto protokolu a uvést ji do předem definovaného incializovaného stavu. Chyba se obvykle indikuje pomocí STALL na příslušném koncovém bodu. Uvedení zařízení do předem definovaného stavu se skládá z příkazu pro Mass Storega Reset a z následného vymazání STALL příznaků na koncových bodech daného rozhraní

24

(interface). Diagram na následujícím obrázku (Obrázek 5.2 Postup při pokusu o získání CSW) zobrazuje postup hostitele při pokusu o získání CSW po odeslání CBW včetně možných chybových stavů a způsobu jejich řešení.

Obrázek 5.2 Postup při pokusu o získání CSW

25

6. IDE Rozhraní Tato kapitola má za úkol přiblížit všechny rysy IDE rozhraní se zaměřením na způsob komunikace. Jedná se především o problematiku podporovaných protokolů spolu s maximální možnou přenosovou rychlostí. Bude zde uvedena i stručná charakteristika fyzického rozhraní. Znalosti o jednotlivých řidících vodičích rozhraní jsou nutné pro správné pochopení všech principů při komunikaci s IDE zařízením. Stále je nutné mít na paměti, že existují dvě základní skupiny IDE zařízení. První skupina se ovládá pomocí vestavěných registrů zařízení, typickým představitelem je pevný disk. Druhá skupina používá paketový přenos, příkazy jsou do jednotky přeneseny jako data, která jsou dekódována a následně interpretována. Do této skupiny patří všechna ATAPI zařízení, což jsou především jednotky DVD a CD-ROM. Podrobnější informace lze získat v dokumentaci věnované tomuto rozhraní [6].

6.1. Fyzické rozhraní 6.1.1. Topologie připojení Pomocí jednoho hostitele a jednoho datového kabelu mohou být připojena až dvě zařízení. První jednotka má číslo nula, též je někdy označovaná jako Master. Druhá jednotka má číslo jedna, je označovaná jako Slave. Pro správnou funkci je nutné správně nastavit propojky (jumpery) na obou jednotkách. Možné konfigurace připojení jsou zobrazeny na následujícím obrázku (Obrázek 6.1 Topologie připojení zařízení).

Obrázek 6.1 Topologie připojení zařízení

26

Za problematickou lze označit poslední konfiguraci zobrazenou na předchozím obrázku. U Ultra DMA přenosů vyžaduje specifikace zakončení kabelu. V tomto případě kabel není nijak zakončen a dochází k odrazům na vedení. Tato konfigurace nemusí být vždy funkční, případně může degradovat výkonnost zařízení a nelze ji doporučit. Každé jednotce lze nastavit adresu 0 nebo 1 (Master nebo Slave). Toto nastavení se provádí dvěma způsoby. •

•

Pomocí propojek – Každé jednotce se příslušná adresa nastaví pomocí příslušné propojky. Je tedy na uživateli, aby provedl nastavení korektně. Pokud budou mít obě jednotky stejnou adresu, nebude ve většině případů pracovat správně ani jedno zařízení. Některá zařízení vyžadují pro správnou funkci nastavení další propojky i v případě, kdy je k hostiteli připojena pouze tato jednotka. Tento mód bývá označován jako Single. Pomocí datového kabelu – Jeden z vodičů kabelu je označen CSEL. Tento vodič je na straně hostitele uzemněn. Pokud je jednotka nastaven v režimu Cable Select, určuje se adresa daného zařízení z logické hodnoty na tomto pinu daného konektoru. Jeden z konektorů kabelu sloužících k připojení zařízení nemá tento signál k danému pinu připojen. Pokud je logická hodnota nula na tomto pinu, jednotka si přiřadí adresu 0. Pokud je nezapojen, vyhodnotí tento stav jako logickou jedničku a adresa zařízení bude 1. Tento princip přidělování adresy je zobrazen na následujícím obrázku (Obrázek 6.2 Adresa jednotek při nastaveném Cable Select).

Obrázek 6.2 Adresa jednotek při nastaveném Cable Select Výše uvedené požadavky je nutné mít vždy na paměti při konfiguraci a připojování IDE zařízení. Ve většině případů je nefunkčnost zařízení způsobena díky špatnému nastavení adresy. Specifikace nevyžaduje po hostiteli, aby dokázal pracovat s jednou připojenou jednotkou s adresou nastavenou na 1, tedy Slave. Tato vlastnost je čistě na vůli výrobce. Navrhovaný adaptér tuto funkci nepodporuje. Pro komunikaci s využitím protokolu Ultra DMA na rychlostech 66, 100 a 133 Mb/s specifikace vyžaduje použití modifikovaného datového kabelu. Mezi vodiče pro přenos informací je vložen další vodič, který je uzemněn. Díky tomu je dosaženo další odstínění za cenu zdvojnásobení počtu vodičů. Zpětná kompatibilita mezi novým a starým typem kabelu je zaručena. Obvod Philips ISP1581 použitý v tomto adaptéru podporuje přenosy do maximální rychlosti 33Mb/s, a není tedy třeba použít nového 80 žilového kabelu.

27

6.1.2. Význam jednotlivých signálů V této podkapitole je popsán základní význam všech vodičů rozhraní. Některé signály jsou časově multiplexovány a mohou být aktivní v různých úrovních. Signál aktivní v nízké úrovni má před svým názvem pomlčku. Celkově je rozhraní založeno na 5V logice s možností přechodu některých signálů do stavu vysoké impedance. • • •

• •

•

• • • •

•

• •

-CS (1:0) – 2 bitový signál pro určení adresy registru disku. DA (2:0) – 3 bitový signál taktéž pro určení adresy registru disku. -DASP – časové multiplexovaný signál pro signalizaci přítomnosti jednotky 1 jednotce 0, následně je využíván k signalizaci činnosti jednotky. Tato indikace nemusí být synchronní s prováděním příkazů. DD (15:0) – 16 bitová datová sběrnice pro přenos příkazů i dat z a do zařízení. -DIOR, -HDMARDY, -HSTROBE – časově multiplexovaný signál. o -DIOR – pokud přistupujeme přímo k registrům jednotky, jde o výkonný signál pro čtení obsahu registru adresovaného signály -CS a DA. o -HDMARDY – signál pro indikaci připravenosti hostitele přijímat data od zařízení při DMA přenosech. o -HSTROBE – výkonný signál pro platnost dat při DMA přenosu od hostitele k zařízení. -DIOW, STOP – časově multiplexovaný signál. o -DIOW – pokud přistupujeme přímo k registrům jednotky, jde o výkonný signál pro zápis do registru adresovaného signály -CS a DA. o STOP – signál, kterým hostitel informuje zařízení, že DMA přenos byl ukončen. -DMACK – signál pro potvrzení požadavku zařízení na DMA přenos. DMARQ – požadavek DMA přenosu ze strany zařízení. INTRQ – zařízení signalizuje požadavek na přerušení a obsluhu hostitelským systémem. IORDY, -DDMARDY, DSTROBE – multiplexovaný signál pro prodloužení zápisového nebo čtecího cyklu nebo řízení DMA přenosu. o IORDY – tímto signálem zařízení hostiteli říká, že není ještě připraveno pro další zápisový nebo čtecí cyklus do registru. o –DDMARDY – slouží pro signalizaci hostiteli, že zařízení je připraveno na DMA přenos při přesunu dat od hostitele k zařízení. o DSTROBE – výkonný signál při DMA přenosu od zařízení k hostiteli, platná je nástupná i sestupná hrana. Přenos lze dočasně pozastavit přerušením generování tohoto signálu -PDIAG, -CBLID – signál pro získání dalších informací o zařízeních a typu kabelu. o -PDIAG – signál říkající jednotce 0, že jednotka 1 ukončila diagnostiku. o -CBLID – pomocí tohoto signálu lze za určitých okolnosti určit typ kabelu, pomocí kterého jsou zařízení připojena (80/40 žil). -RESET – signál pro HW reset obou IDE jednotek. CSEL – signál určující adresu zařízení, pokud si jednotka nastavuje adresu podle Cable Select a ne pomocí propojek.

28

6.1.3. Adresa registrů V následující tabulce (Tabulka 6.1 Adresy registrů) jsou uvedeny hodnoty signálu DA a –CS pro přístup k jednotlivým registrům zařízení. Některé registry jsou určeny pouze pro čtení nebo pro zápis. Pokud dojde k zápisu do registru určeného pouze pro čtení, dojde k zápisu do úplně jiného registru. Z těchto důvodů je v tabulce rozlišován typ operace s registrem.

CS1 L H H H H L L L

Adresa registru CS0 DA2 DA1 L x x L L x L H L L H H L H H H L L H L L H L H

Registr DA0 x x x L H L H L

L

H

L

H

H

L

H

H

L

L

L

H

H

L

H

L

H

H

H

L

L H

H H

H x

H x

H x

Čtení Data bus high impedence Data bus high impedence Data bus high impedence Alternate Status Data Error Sector Count Sector Number LBA (7:0) Cylinder Low LBA (15:8) Cylinder High LBA (23:16) Device/Head LBA (27:24) Status Špatná adresa

Zápis Device Control Data Features Sector Count Sector Number LBA (7:0) Cylinder Low LBA (15:8) Cylinder High LBA (23:16) Device/Head LBA (27:24) Command Špatná adresa

Tabulka 6.1 Adresy registrů Znak H označuje aktivní signál a znak L neaktivní signál. Tyto znaky neoznačují skutečnou úroveň signálu, ta se odvíjí od toho, zda je signál aktivní v nízké nebo ve vysoké úrovni. Pokud nemám signál vliv na výběr registru, je v příslušném políčku znak x.

29

6.2. Význam jednotlivých registrů Při práci s IDE jednotkou je třeba rozlišovat, zda se jedná o diskové zařízení ovládané pomocí registrů nebo ATAPI zařízení. Některé principy a přístupy jsou pro obě skupiny zařízení shodné, jiné jsou vyhrazeny pouze pro příslušnou skupinu. Obě skupiny zařízení mají registry, pomocí kterých se jednotka řídí, nebo se jí doručují pakety s příkazy. Význam jednotlivých bitů v příslušném registrů může být závislý na typu zařízení nebo právě zpracovávaném příkazu. Popis všech registrů včetně všech významných bitů je uveden níže. Tento popis je orientační, slouží pouze k seznámení s jejich významem a je nutný pro pochopení dalšího výkladu. Znak R označuje bit, který je rezervován, znak # bit, jehož význam je závislý na použitém příkazu, a znak O bit, který je vynechán oproti dřívější specifikaci.

6.2.1. Data register Jediný 16 bitový registr. Používá se k přímém přístupu k registrům jednotky v závislosti na hodnotě signálu DA a -CS a pro přenos dat. V případě přístupu k 8 bitovým registrům se musí horní byte tohoto registru ignorovat. Využívá se také k přenosu dat pomocí PIO protokolu, kdy přístup k němu plánuje řidící procesor. Při DMA přenosech se používá také k přenosu dat, ale o řízení se stará jednotka společně s hostitelem, což nemusí být řidící procesor. Data tak mohou být přenášena bez účasti procesoru pomocí přímého přístupu do paměti. Tohoto principu je využíváno v navrhovaném adaptéru, kdy data z jednotky jsou přenášena přímo do vyrovnávací paměti koncového bodu. Použitý obvod Philips v adaptéru podporuje standardní PIO a DMA protokol. Z tohoto důvodu je schopen přenášet data i v PIO režimu bez účasti procesoru, což běžný IDE hostitel nedokáže. Přístup : čtení, zápis

6.2.2. Error register Tento registr slouží pro indikaci úspěšnosti nebo neúspěšnosti právě vykonaného příkazu. Jeho obsah je platný, pokud není nastaven příznak BSY a DRQ a současně je aktivní příznak ERR. V tomto registru je také uložen výsledek diagnostiky jednotky po resetu (HW reset, SW reset a příkazem DEVICE RESET). Po vykonání příkazu pro diagnostiku jednotky je v tomto registru uveden výsledek pouze v případě nastaveného bitu ERR. 7

6

5

4

3

2

1

0

#

#

#

#

#

ABRT

#

#

Tabulka 6.2 Rozložení bitů Error registru ABRT – příznak říkající, že zpracování příkazu bylo přerušeno z důvodu špatného kódu příkazu, špatných parametrů nebo jiné chyby. Přístup : čtení

30

6.2.3. Features register Určený pro uložení parametrů právě zapisovaného příkazu. Obsah je specifický pro použitý příkaz. Do registru se může zapisovat pouze tehdy, když je BSY a DRQ rovno nule a zároveň není aktivní DMA přenos. Přístup : zápis

6.2.4. Sector Count register Příkazově závislý registr, většinou určuje počet sektorů zpracovaných daným příkazem. Zapisovat se smí pouze při nulových příznacích BSY a DRQ, rovněž nesmí být aktivní DMA přenos. Obsah registru je při čtení platný, pokud není nastaveno BSY. Obsah je při čtení také závislý na použitém příkazu. Přístup : čtení, zápis

6.2.5. Sector Number register, LBA (7:0) Příkazově závislý registr, většinou je v něm uložena adresa sektoru v adresování CHS nebo bity 0 až 7 LBA adresy při lineárním adresování. Zapisovat se smí pouze při nulových příznacích BSY a DRQ, rovněž nesmí být aktivní -DMACK. Obsah registru je při čtení platný pokud není nastaveno BSY a DRQ a jednotka není v režimu spánku. Obsah je při čtení závislý na použitém příkazu. Přístup : čtení, zápis

6.2.6. Cylinder Low register, LBA (15:8) Příkazově závislý registr, většinou je v něm uložen spodní byte cylindru při CHS adresování nebo bity 8 až 15 LBA adresy při lineárním adresování. Zapisovat do tohoto registru lze pouze při nulovosti BSY, DRQ a zároveň nesmí být nastaveno -DMACK. Při čtení je registr platný, pokud je BSY nulové a jednotka není v režimu spánku. Obsah je taktéž závislý na použitém příkazu. Přístup : čtení, zápis

6.2.7. Cylinder High register, LBA (23:16) Příkazově závislý registr, většinou je v něm uložen horní byte cylindru při CHS adresování nebo bity 16 až 23 LBA adresy při lineárním adresování. Zapisovat do tohoto registru lze pouze při nulovosti BSY, DRQ a zároveň nesmí být nastaveno -DMACK. Při čtení je registr platný, pokud je BSY nulové a jednotka není v režimu spánku. Obsah je taktéž závislý na použitém příkazu. Přístup : čtení, zápis

6.2.8. Device/Head register, LBA (27:24) Registr pro výběr jednotky, některé bity mohou být parametrem příkazů, většinou se používá na určení čísla hlavy při CHS adresování nebo pro zbývající bity LBA adresy při lineárním režimu adresování. Zapisovat se do něj může pouze při nulovosti BSY a DRQ, rovněž nesmí probíhat DMA přenos. Registr je při čtení platný, pouze když je BSY nulové. Pokud zařízení podporuje příkaz DEVICE RESET (ATAPI zařízení), je obsah platný i v režimu spánku, u ostatních zařízení ne.

31

7

6

5

4

3

2

1

0

O

#

O

DEV

#

#

#

#

Tabulka 6.3 Rozložení bitů Device/Head registru DEV – tento bit určuje, ke které jednotce se právě přistupuje. Pokud je tento bit nulový, přistupuje se k jednotce 0 (Master), pokud je bit jedničkový, přistupuje se k jednotce 1 (Slave). Přístup : čtení, zápis

6.2.9. Command register Registr určený pro zápis příkazu, který má jednotka zpracovat. Před zapsáním do tohoto registru musí být v příslušných registrech již parametry příkazu. Příkaz se smí zapsat, pouze pokud je BSY a DRQ nulové a není aktivní DMA přenos. Jedinou výjimkou je příkaz DEVICE RESET, který se může zapsat kdykoli a slouží k resetu této jednotky. Pokud existuje nevyřízená žádost o přerušení, je zápisem do tohoto registru automaticky smazána. Přístup : zápis

6.2.10. Status register Registr, ve kterém je uložen aktuální stav jednotky. Obsah je platný, pokud je nulový bit BSY. Pokud je aktivní žádost o přerušení, přečtením tohoto registru se automaticky zruší. 7

6

5

4

3

2

1

0

BSY

DRDY

#

#

DRQ

O

O

ERR

Tabulka 6.4 Rozložení bitů Status registru BSY – tento bit je nastaven v případě, že jednotka je zaneprázdněna. Většinou se tak stane po zapsání příkazu. Pokud je bit nastaven, je obsah většiny registrů neplatný. Přesný popis, kdy je tento bit nastaven a kdy ne, je uveden v dokumentaci k IDE rozhraní [6]. DRDY – tímto bitem jednotka hostiteli oznamuje, že je připravena zpracovat příkaz. DRQ – tento bit říká, že jednotka je připravena přenášet data. V tomto případě se používá plná šířka datové sběrnice. O tom, jaký typ přenosu a jakým směr bude použit, rozhoduje právě zpracovávaný příkaz. Po přenesení posledního slova je tento bit vynulován. Po zapsání příkazu je nastaven bit signalizující zaneprázdněnost jednotky nebo tento bit. ERR – tento příznak signalizuje chybu při zpracování příkazu (neplatný kód příkazu, špatné parametry nebo jinou chybu) Přístup : čtení

32

6.2.11. Alternate Status register Význam registru včetně jeho všech bitů je stejný jak u Status registru. Jediný rozdíl je v nulování požadavku přerušení. Při čtení tohoto registru nedojde ke zrušení požadavku o přerušení. Přístup : čtení

6.2.12. Device Control register Registr pro nastavení některých vlastností jednotky. Do tohoto registru lze zapisovat, a to pouze v případě neaktivního DMA přenosu. 7

6

5

4

3

2

1

0

R

R

R

R

R

SRST

nIEN

O

Tabulka 6.5 Rozložení bitů Device Control registru nIEN – maskovací bit přerušení jednotky, pokud je přerušení povoleno a jednotka je vybrána, přejde signál pro přerušení ze stavu vysoké impedance do aktivního režimu a podle potřeby je jednotkou nastaven. SRST provádí softwarový reset jednotky Přístup : zápis

6.3. Komunikační protokoly Tato podkapitola má za úkol seznámit čtenáře se základními principy při komunikaci s IDE jednotkou. Budou zde popsány i některé příkazy, které slouží pro základní konfiguraci a komunikaci zařízením. I v tomto případě je nutné brát na zřetel typ připojeného zařízení. Všechny příkazy lze rozdělit do několika skupin. Některé jsou povinné a některé volitelné. Další rozdělení souvisí s typem připojeného zařízení. Některé příkazy jsou určeny pro oba typy zařízení. Oproti tomu některé jsou určeny pouze pro diskové nebo ATAPI zařízení a druhá skupina zařízení je nesmí podporovat. Pro správnou komunikaci je vždy nutné splnit několik podmínek, které vždy platí (pokud není uvedeno jinak). Většina všeobecně platných požadavků je uvedena v následujících bodech. • • • • •

Žádný příkaz nesmí být zapsán pokud je nastaven bit BSY (zaneprázdněnost), jedinou výjimkou je příkaz DEVICE RESET. Pro většinu příkazů také musí být nastaven bit DRDY (připravenost jednotky). Dokud není příkaz zpracován, je vždy nastaven bit BSY nebo bit DRQ (požadavek na přenos dat. Signál pro přerušení je použit v případě, kdy došlo k nějaké události a je nutný zásah hostitele. Většinou je přerušení také vyvoláno, pokud se bit BSY změní z jedničky na nulu. Pokud dojde k zapsání příkazu v okamžiku, kdy je nastaven BSY nebo DRQ, může dojít k poškození dat a chování jednotky není definováno.

33

6.3.1. Identifikace a reset jednotky Po připojení napájení se každá jednotka inicializuje a provede svůj diagnostický test. Tyto operace jsou provedeny bez zásahu hostitele. Pokud jsou připojeny obě jednotky, oznámí jednotka s adresou jedna jednotce s adresou nula, zda diagnostika proběhla bez chyby. V okamžiku, kdy probíhá reset nebo diagnostika jednotky, je nastaven bit BSY. Reset také může vyvolat hostitel, rozlišuje se HW a SW. HW se provede nastavením signálu –RESET. SW reset lze provést nastavením bitu SRST. Tímto způsobem jsou znovu inicializovány obě jednotky současně. SW reset pouze vybrané jednotky podporují jen ATAPI zařízení pomocí příkazu DEVICE RESET. Po jakékoli výše uvedené operaci je v registrech jednotky uložen výsledek diagnostické testu a také signatura zařízení. Pomocí této signatury lze okamžitě poznat, zda se jedná o diskové nebo ATAPI zařízení.

Registr Sector Count Sector Number Cylinder Low Cylinder High Device/Head

Hodnota 01h 01h 00h 00h 00h

Registr Sector Count Sector Number Cylinder Low Cylinder High Device/Head

Tabulka 6.6 Signatura diskové jednotky

Hodnota 01h 01h 14h EBh 00h nebo 10h

Tabulka 6.7 Signatura ATAPI jednotky

Podle použitého typu resetu dojde k výchozímu nastavení některých parametrů. Tuto skutečnost je nutné si uvědomit především při fyzické komunikaci s jednotkou. Zařízení nastaví všechny komunikační protokoly na nejpomalejší. Pokud chce hostitel přečíst parametry jednotky včetně všech podporovaných protokolů, musí použít nejstarší protokol, který podporují všechny jednotky.

6.3.2. Adresování u diskových jednotek Jak šel vývoj diskových zařízení, vyskytlo se několik způsobů, jak specifikovat požadovaný sektor na disku. V současné době existují dva způsoby, jak sektor adresovat. Velikost sektoru disku je až na výjimky vždy 512 bytů. Cylinder, Head, Sector (CHS) – tento systém adresování se používal především u starších jednotek. Cylindr může mít hodnotu v rozsahu 0 až 65.535. Jednotka má více rotujících ploten na stejné ose. Cylindr si lze představit jako válec, který protíná magnetické plotny. Každý cylindr určí z každé strany na každé plotně soustřednou kružnici. Pomocí hlavy, která může nabývat hodnot v rozsahu od 0 do 15, se vybere jedna soustředná kružnice určená cylindrem. Všechny hlavy jsou vychylovány současně stejným mechanismem. Na každé takovéto soustředné kružnici jsou za sebou uloženy sektory. Díky otáčení ploten jsou postupně přístupné. Hodnota sektoru je v rozsahu 1 až 255. Cylindr se vybere vhodným vychýlením hlavy. Většinou je takto fyzicky uspořádán i disk. Skutečné počty hlaviček sektorů a cylindru se mohou lišit od logické struktury disku pro přístup k němu. Maximální hodnoty počtu hlav, cylindrů a sektorů jsou uloženy v řidícím programu disku a odpovídají kapacitě jednotky. V tomto režimu je možno adresovat maximálně 16.514.064 sektorů, což odpovídá diskové kapacitě

34

zhruba 8,4 Gb (7,87Gb výrobci disků nepoužívají pro předponu kilo 1024, ale 1000, díky tomuto „fíglu“ je výsledná kapacita disku „větší“) Na následujícím obrázku je znázorněna přibližná struktura disku při CHS adresování (Obrázek 6.3 Princip CHS adresování).

Obrázek 6.3 Princip CHS adresování Lineární režim adresování (LBA) – Z kapacitních důvodů bylo CHS adresování nahrazeno lineárním adresováním sektorů. Některé jednotky podporují oba režimy. Pokud je kapacita větší než maximální hodnota při CHS, nejsou zbývající sektory v CHS režimu přístupné. Při LBA režimu jsou sektory číslovány vzestupně od hodnoty nula až po maximální hodnotu danou kapacitou disku. Adresu sektoru lze převést z CHS na LBA a opačně.

6.3.3. Typy přenosů dat Protože IDE zařízení slouží především pro ukládání dat, je velmi důležité, jak rychle a s jakými nároky lze po zadání příkazu data z jednotky získat. Existují celkem tři způsoby, jak to lze provést. Základní charakteristiky jednotlivých režimů jsou popsány v následujících bodech. Registrový přístup – všechny informace, příkazy a data lze získat pouze přímým přístupem k registrům. Tento režim se používá pouze u velmi starých zařízení a po inicializaci jednotky do okamžiku než jsou přečteny identifikační údaje a vlastnosti jednotky. Po získání těchto údajů je zařízení i hostitel nastaven do maximálního možného režimu (většinou PIO nebo UDMA mód). PIO mód – v tomto případě se přenos dat z nebo do jednotky stará procesor, a to tak, že buď zapisuje, nebo čte z datového portu. Existuje několik režimů, které definují, za jakou minimální dobu lze provést další čtecí nebo zápisový cyklus. Tento způsob je dosti náročný na vytížení procesoru, a pokud jednotka i hostitel podporuje UDMA přenosy, použijeme raději tento protokol pro přístup k datům. UDMA mód – při tomto způsobu komunikace procesor provede pouze nastavení obou rozhraní a přestane se o přenos dat starat. Jak hostitel, tak jednotka má signály potřebné pro autonomní řízení přenosu dat. Požadavek o přerušení je vydán až v okamžiku, kdy je přenos dat ukončen nebo se vyskytne nějaká chyba.

35

Protože obě zařízení používají stejnou sběrnici, může se použít nejvýše komunikační protokol pomalejšího z obou jednotek. Je nutné si uvědomit tento princip v okamžiku, kdy k modernímu zařízení připojíme velmi starou jednotku. Dojde k obrovské degradaci výkonu nového zařízení.

6.3.4. Kategorie příkazů V následujících dvou tabulkách (Tabulka 6.8 Sada příkazů pro diskové zařízení, Tabulka 6.9 Sada příkazů pro ATAPI zařízení) jsou uvedeny všechny povinné příkazy IDE rozhraní. Jsou rozděleny do skupin podle typu zařízení, které je musí, mohou a nesmí podporovat. Tento výčet uvádím pouze pro lepší pochopení problematiky. Není úplný, a pokud zařízení podporuje některou další rozšiřující sadu příkazů, musí podporovat i všechny příkazy vztahující se k dané sadě. Typickou skupinou jsou příkazy pro DMA přenosy nebo sada pro obsluhu zařízení podporující výměnná média. Přesný popis a význam těchto a všech dalších příkazů je uveden v dokumentaci pro IDE rozhraní [6]. Zařízení, která nepodporují paketový přenos (diskové zařízení) Povinné příkazy Volitelné Zakázané EXECUTE DEVICE DIAGNOSTIC DOWNLOAD MICROCODE DEVICE RESET IDENTIFY DEVICE FLUSH CACHE INITIALIZE DEVICE PARAMETERS NOP READ DMA READ BUFFER READ MULTIPLE WRITE BUFFER READ SECTOR(S) READ VERIFY SECTOR(S) SEEK SET FEATURES SET MULTIPLE MODE WRITE DMA WRITE MULTIPLE WRITE SECTOR(S) Tabulka 6.8 Sada příkazů pro diskové zařízení Zařízení, která podporují paketový přenos (ATAPI zařízení) Povinné příkazy Volitelné Zakázané DEVICE RESET FLUSH CACHE DOWNLOAD MICROCODE EXECUTE DEVICE DIAGNOSTIC INITIALIZE DEVICE PARAMETERS IDENTIFY DEVICE READ BUFFER IDENTIFY PACKET DEVICE READ DMA NOP READ MULTIPLE READ SECTOR(S) READ VERIFY SET FEATURES SEEK PACKET SET MULTIPLE MODE WRITE BUFFER WRITE DMA WRITE MULTIPLE WRITE SECTOR(S) Tabulka 6.9 Sada příkazů pro ATAPI zařízení

36

Je nutné si uvědomit, že IDE specifikace použitá při tomto návrhu je z roku 1998 a některá zařízení staršího data výroby mohou mít problémy s kompatibilitou. U novějších zařízení se tento problém nedá očekávat. Podle této relativně staré specifikace byl proveden návrh IDE rozhraní obvodu Philips. Chtěl jsem se vyhnout případným problémům, a proto jsem při návrhu tohoto adaptéru použil stejnou verzi IDE dokumentace.

6.3.5. Popis vybraných příkazů V této části jsou stručně popsány některé příkazy, zaměřil jsem se především na ty, které mají významný vliv při řízení adaptéru. Vzhledem k použitému protokolu pro komunikaci po USB nemá smysl uvažovat o překrývaném zpracování příkazů nebo řazení příkazů do front, protože tento protokol nic takového nepodporuje. Tyto techniky dovolují zadat příkaz jednotce, ta jej začne zpracovávat a uvolní sběrnici. Od tohoto okamžiku je možno komunikovat s druhým zařízením na stejném datovém kabelu. IDENTIFY DEVICE, IDENTIFY PACKET DEVICE – jak už název obou příkazů napovídá, slouží k získaní informací o zařízení. Každá jednotka tímto příkazem pošle hostiteli všechny své důležité parametry. Některé z nich jsou uvedeny v následujících bodech • • • • •

Typ zařízení, zda se jedná o diskové nebo ATAPI zařízení. Podporované komunikační protokoly. Textový název zařízení, sériové číslo a např. verze firmware. U disků například podporované režimy adresování a jejich maximální hodnoty. Zda jednotka umožňuje výměnu média.

READ, WRITE – všechny varianty těchto příkazů slouží pro zápis nebo čtení z jednotky. Podle toho, jaký příkaz bude v konkrétním příkaze použit, se bude odvíjet použitý komunikační protokol. Rychlost přenosu bude dána nastavením rozhraní hostitele i zařízení. EXECUTE DEVICE DAIGNOSTIC – tento příkaz začnou provádět vždy obě jednotky a nezáleží na bitu určující adresu jednotky. Slouží ke spuštění interní diagnostiky jednotky. Výsledek této operace je uložen v registrech zařízení. Obdobná diagnostika se spouští i po resetu IDE rozhraní. SET FEATURE – tento příkaz slouží pro nastavení některých parametrů. Úplně typickým použitím je nastavování rychlosti přenosových protokolů. U tohoto příkazu se musí do Feature registru uložit identifikace vlastnosti, která je nastavována (Přenosové režimy, zapnutí podpory rozšiřujících příkazů apod.). PACKET – tento příkaz slouží pro předání příkazu od hostitele k ATAPI zařízení. Ve většině případů se jedná o 12 nebo 16 bytový Command Data Block (CDB). Formát těchto datových struktur vychází z SCSI specifikace. Jak už bylo uvedeno u základní charakteristiky IDE rozhraní, jedná se o skupinu MMC příkazů (MultiMedia Command).

37

7. SCSI rozhraní Cílem této části práce je poskytnout čtenáři základní informace o tomto rozhraní. Důraz zde bude kladen především na logickou strukturu a principy komunikace mezi zařízeními. O fyzickém propojení se zde nebudu vůbec zmiňovat. Jednak informace nejsou pro navrhovaný adaptér nutné a jednak je to dáno strukturou propojení jednotlivých vrstev SCSI rozhraní.

7.1. Základní charakteristika Toto rozhraní lze rozdělit na dvě části. Ta první definuje fyzické propojení zařízení a druhá stanovuje všechny požadavky na komunikační protokol. Oproti IDE je toto rozhraní značně flexibilní. Umožňuje transport příkazů a dat jak na paralelních, tak sériových rozhraních, aniž by se změnily základní principy komunikačního protokolu. Celý systém komunikace by se dal přirovnat k vrstvovému síťovému modelu, kde vyšší komunikační protokol využívá služeb nižšího a vůbec nemusí mít informace o fyzickém propojení. Tento princip je znázorněn na následujícím obrázku (Obrázek 7.1 Vrstvový model SCSI rozhraní).

Obrázek 7.1 Vrstvový model SCSI rozhraní Specifikace SCSI podporuje velké množství zařízení různých typů. Nejběžnějším představitelem jsou jednotky DVD/CD-ROM a disková zařízení. Není ovšem problém připojit pomocí tohoto rozhraní tiskárnu scaner nebo jiné zařízení. Jednotlivá zařízení jsou rozdělena do skupin. Každá skupina má definovanou sadu příkazů. Některé jsou povinné, některé volitelné. Podle těchto kategorií je rozdělena i dokumentace k tomuto rozhraní. Pro pochopení všech základních principů komunikace je nutné prostudovat dokumentaci popisující tzv. architekturní model. Zde je vysvětlena většina základních pojmů. Existuje sada příkazů, které musí podporovat všechna zařízení. Tomuto problému se věnuje další dokument. Pokud zařízení patří do nějaké kategorie, musí splňovat všechny požadavky definované pro danou třídu zařízení. Pro jednotlivé kategorie jsou opět definovány dokumenty, které tyto požadavky specifikují. S ohledem na navrhovaný adaptér jsem musel věnovat pozornost

38

dokumentům popisujícím architekturní model, všem povinným příkazům pro všechna zařízení, dokumentaci k zařízením s přímým přístupem (disky) a zařízením podporujícím multimediální sadu příkazů (DVD/CD-ROM jednotky).

7.2. Transport příkazů Jak již bylo uvedeno výše, každý příkaz patří do určité skupiny. Příkaz je zařízení doručen ve formě datového balíčku spolu s jeho parametry. Existuje několik možných velikostí těchto balíčků. Tato datová struktura je označovaná jako Command Data Block (CDB). Každý CDB začíná 1 bytem, který určuje samotný příkaz a také délku právě použité CDB. Tento blok dat může mít pevnou velikost nebo může být celková délka proměnná na základě zasílaných parametrů. V tomto případě je definovaná minimální délka. V této minimální části je uvedena skutečná délka příkazu, kterou zařízení zjistí po obdržení prvních bytů příkazu. Z pohledu navrhovaného adaptéru má smysl uvažovat pouze CDB s pevnou délkou. Z těchto možností navíc připadají v úvahu pouze 4. CDB může mít délku 4, 10, 12 nebo 16 bytů. V tento okamžik je dobré si uvědomit, že právě tento blok s příkazem CDB je přenášen v protokolu pro velkokapacitní zařízení v části CBW v položce nazvané CBWCB. Tato položka je velká maximálně 16 bytů a právě z tohoto důvodu plynou omezení na maximální velikost CDB pro navrhovaný adaptér. Informace o délce právě posílaného CDB je také uložena v položce dCBWDataTransferLength, opět v CBW části. Tímto způsobem jsou dopravovány SCSI příkazy přímo do USB zařízení za použití protokolu pro velkokapacitní zařízení. V následujících tabulkách jsou uvedeny všechny 4 možnosti CDB společně se základním popisem jednotlivých položek. Popis bude v tomto případě velmi stručný, avšak řidící program adaptéru musí správně zpracovat všechny položky. Bit

7

6

5

4

3

2

1

0

Byte 0

Operation Code

1 2

rezervováno (MSB)

Service Action Logical Block Address

3

Logical Block Address

4

Logical Block Address

5

Logical Block Address

6

Rezervováno

7

(MSB)

(LSB)

Parametry příkazu

8

Parametry příkazu

9

Control Tabulka 7.1 10 bytový Command Data Block

39

(LSB)

Bit

7

6

5

4

3

2

1

0

Byte 0

Operation Code

1 2

Rezervováno

Service Action

(MSB)

Logical Block Address

3

Logical Block Address

4

Logical Block Address

5

Logical Block Address

6

(MSB)

Aditional CDB Data

7

Aditional CDB Data

8

Aditional CDB Data

9

Aditional CDB Data

10

(LSB)

(MSB)

(LSB)

Parametry příkazu

11

Parametry příkazu

12

Parametry příkazu

13

Parametry příkazu

14

Rezervováno

15

Control

(LSB)

Tabulka 7.2 16 bytový Command Data Block

Bit

7

6

5

4

3

2

1

0

Byte 0 1

Operation Code Rezervováno

(MSB)

Logical Block Address

2

Logical Block Address

3

Logical Block Address

4

Parametry příkazu

5

Control Tabulka 7.3 6 bytový Command Data Block

40

(LSB)

Bit

7

6

5

4

3

2

1

0

Byte 0

Operation Code

1 2

rezervováno (MSB)

Service Action Logical Block Address

3

Logical Block Address

4

Logical Block Address

5

Logical Block Address

6

(MSB)

(LSB)

Parametry příkazu

7

Parametry příkazu

8

Parametry příkazu

9

Parametry příkazu

10

Rezervováno

11

Control

(LSB)

Tabulka 7.4 12 bytový Command Data Block Operation Code – tato položka se skládá ze dvou částí, spodních 5 bitů je vyhrazeno pro specifikaci příkazu a horní 3 bity určují délku CDB. Význam jednotlivých kombinací horních 3 je uveden v následující tabulce (Tabulka 7.5 Význam horních 3 bitů v Operation Code). Operation Code

Význam

000b

6 bytový příkaz

001b

10 bytový příkaz

010b

10 bytový příkaz

011b

Rezervováno

100b

16 bytový příkaz

101b

12 bytový příkaz

110b

specifikováno výrobcem

111b

specifikováno výrobcem

Tabulka 7.5 Význam horních 3 bitů v Operation Code Logical Block Address – jak už název napovídá, tato položka je vyhrazena pro identifikaci bloku v rámci zařízení (u diskových zařízení většinou sektor).

41

Parametry příkazu – podle potřeby mohou být v této části uloženy tyto parametry : Transfer Length, Parametr List Length, Alocation Length.

7.3. Charakteristika některých příkazů V této částí uvedu několik příkazů, které mají významný vliv na komunikaci se zařízením. Pro identifikaci zařízení se používá příkaz Inquiry. Zřízení odpoví na tento požadavek deskriptorem, který dané SCSI zařízení popisuje. V tomto případě se řidící program adaptéru tváří jako SCSI disk nebo jednotka CD-ROM. Tato situace se může jevit jako absurdní, když vezmeme v úvahu, že připojujeme IDE zařízení přes USB k počítači. Pokud jakýkoli SCSI příkaz skončí chybou, nastaví zařízení bit, kterým hostiteli signalizuje, že má zkontrolovat výsledek požadované operace. K těmto účelům slouží příkaz Request Sense. Informace o výsledku zpracování požadavku je strukturovaná do tří částí. V části Sense Key se vrací základní informace o výsledku operace. Pokud jsou bližší informace k dané chybě, jsou uvedeny v části Aditional Sense Key. Pokud lze i tuto informaci dále podrobněji specifikovat, je tato informace uložena v části Adtitional Sense Key Qualifier. To, že hostitel zašle příkaz Request Sense, ještě neznamená, že muselo dojít k chybě. Zřízení může v části Sense Key vrátit hodnotu No Sense, která říká, že k žádné výjimečné situaci nedošlo. Pokud se opět podíváme na navrhovaný adaptér, tak bit informující o výsledku operace je nahrazen položkou Status v části CSW protokolu pro velkokapacitní zařízení. Mezi typické příkazy lze zařadit příkazy pro čtení a zápis na médium (Read, Write). Trošku matoucí může být skutečnost, že příkazy se mohou vyskytovat v různých mutacích pro různé délky CDB. Dalo by se očekávat, že u těchto příkazů se v Operation Code změní pouze horní 3 bity specifikující délku CDB a spodních 5 bitů zůstane zachováno. Bohužel tomu tak není a libovolný příkaz má tedy jednoznačně přidělenu velikost CDB.

7.4. Význam SCSI příkazů při komunikaci s adaptérem Jak již bylo uvedeno v předcházejících kapitolách této práce, využívá se SCSI protokol včetně příkazů ke specifikaci požadavků, které má připojené velkokapacitní zařízení vykonat. Základní charakteristika uvedena v této kapitole je nedostačující k pochopení všech principů a zákonitostí při komunikaci po SCSI rozhraní. Proto i při tvorbě řidícího programu adaptéru bylo tuto specifikaci nutné podrobně prostudovat a všechny požadavky pro správnou komunikaci dodržet. Bližší informace k tomuto problému lze získat v [11] [12] [13] [14].

42

8. Změny v obvodovém zapojení Během vývoje programového vybavení adaptéru bylo třeba provést některé změny v zapojení. První problém se vyskytl již při oživování celého adaptéru. Celý návrh vycházel z dokumentace firmy Philips k danému obvodu [10]. Napájení obvodu bylo provedeno v souladu s doporučeným zapojením. Bohužel se ukázalo, že toto zapojení vede ke zničení obvodu při napájecím napětí 5V. Nebyla jiná možnost, než se pokusit navrhnout nové zapojení napájecí části. Toto zapojení vycházelo z popisu napájecích pinů a ukázalo se jako spolehlivé a použitelné. Největší změnou oproti původnímu zapojení je použití 3,3V externího stabilizátoru pro napájení obvodu. Toto napájecí napětí je připojeno pouze na jeden napájecí vývod. Při experimentování se zařízením se vestavěný nulovací obvod ISP 1581 neukázal jako dostatečně spolehlivý, a proto je nulovací vývod připojen k řidícímu mikrokontroléru. Ten provede reset obvodu v inicializační fázi programu. Pro snadnější ladění programu adaptéru jsem zapojení dovybavil LCD displayem a 16 LED diodami. K připojení těchto periferií jsem využil nepoužité brány P2. Data na těchto vodičích jsou časově multiplexována a slouží pro přenos informaci do LCD a také ke stavovým LED diodám. Informace pro diody jsou uschovány ve dvou záchytných registrech. Díky této koncepci je připojení těchto zařízení relativně jednoduché a nenáročné na počet použitých vývodů mikrokontroléru. Pokud bylo k adaptéru připojeno IDE zařízení s napájením a následně se celé zařízení připojilo k počítači, vyskytly se některé přechodové děje, které způsobovaly problémy. Tyto nedefinované stavy se týkaly dvou částí adaptéru. •

•

Philps ISP 1581 – signály pro komunikaci s IDE zařízením jsou ve fázi inicializace tohoto obvodu využity k nastavení rozhraní pro komunikaci s řidícím mikrokontrolérem, a to pomocí připojených odporů. Změnou jejich hodnot na rozumnou mez, která v žádném případě neohrozí funkci obvodu, se povedlo většinu těchto nedefinovaných stavů odstranit. Tyto změny neměly vliv na správnou komunikaci s IDE zařízením a také neovlivnily maximální proudové odběry z takto upraveného zapojení příslušného vývodu. LCD – toto zařízení má extrémně nízkou spotřebu elektrické energie. Při plné funkci se pohybuje okolo 2mA. Pokud není celý adaptér připojen k hostiteli a připojené IDE zařízení je napájeno, tak se díky propojení IDE rozhraní s obvodem Philips dostane malé napětí i na napájecí vývod LCD. Tato skutečnost vede k chybné programové inicializaci tohoto zařízení po připojení celého adaptéru k počítači. Pro správnou funkci je nutné před SW resetem LCD provést dočasné odpojení toho zařízení od napájení. Z 16 vývodů záchytných registrů pro LED je jeden použit pro odpojování napájecího napětí LCD a druhý pro ovládání podsvětlení displaye.

Další změny bylo třeba provést v propojení mikrokontroléru s IDE rozhraním. V původním návrhu je připojen pouze signál pro HW reset obou jednotek. Pokud má adaptér správně fungovat, musí mít informaci o tom, zda je k němu připojeno nějaké zařízení. IDE rozhraní má na několika pinech signálovou zem. Pokud tedy otestujeme, zda je příslušný vývod uzemněn, zjistíme, jestli je nějaká jednotka připojena. Takto testovaný signál samozřejmě nesmí být na straně adaptéru uzemněn.

43

Pro jednodušší detekci druhého IDE zařízení je k řidícímu mikrokontroléru připojen také signál DASP. Po inicializaci IDE rozhraní dává tímto signálem jednotka Slave jednotce Master signál najevo svoji přítomnost. Této vlastnosti využívá i navrhovaný adaptér. Poslední změna se týká externího napájení, které samotný adaptér ke své funkci nepotřebuje. Externí zdroj vyžadují pro svou funkci IDE zařízení. Pokud připojíme k adaptéru jednotku bez napájení, lze jen velmi těžko odhadnout, jak se takovéto zařízení bude chovat. Zkušenosti říkají, že každé zařízení se chová jinak a je třeba mít nezávislou informaci o tom, zda je externí napájení funkční. Z tohoto důvodu je přivedeno externí napájení, které se zde využívá k detekčním účelům také k adaptéru. Proto jsem využil jeho přítomnosti k napájení osvětlení LCD. Samotné osvětlení je energeticky dosti náročné a nelze použít napájení z USB sběrnice. Celkově již nelze očekávat žádné výrazné změny v obvodovém zapojení. Vše bylo otestováno na několika typech zařízení. Funkční jsou jak disky, tak CD-ROM jednotky. Testoval jsem i relativně stará zařízení, konkrétně se jednalo 3x rychlostí jednotku CD-ROM Mitsumi s rokem výroby 1993 a přibližně stejně starý disk značky Western Digital s kapacitou 425 MB. Opačným případem byla jednotka DVD/CD-ROM značky Pioneer s letošním rokem výroby a přibližně rok starý disk Western Digital s kapacitou 20 GB. V tomto případě jsem sledoval především parametry související s elektrickými vlastnostmi rozhraní. Všechny změny v obvodovém zapojení, které jsou popsány v této kapitole, jsou zahrnuty v dokumentaci k obvodovému zapojení. Tato dokumentace je součástí příloh.

44

9. Řidící program adaptéru Celý adaptér je řízen jednočipovým procesorem, který na základě událostí buď přímo řídí některé signály, nebo vydává příkazy připojenému obvodu pro převod IDE na USB. V této části práce je popsána přibližná struktura programu spolu s charakteristikou jednotlivých částí. Pro tuto aplikaci jsem zvolil jednočipový procesor firmy Atmel s instrukční sadou kompatibilní s Intel 51.

9.1. Základní charakteristika mikrokontroléru Tato řada procesorů používá Harwardskou koncepci, kdy je oddělena paměť pro kód a paměť pro data. Použitý mikrokontrolér má oproti původní řadě některé rozšíření bez nichž, by procesor nemohl celý adaptér řídit. Stručná charakteristika je uvedena v následujících bodech : • • •

• • • • • •

8 bitový procesor. 8 kb elektricky mazatelné paměti FLASH pro řidící program. 256 bytů paměti pro uchování dat za běhu programu. o Spodních 128 bytů je přímo adresovatelných. V této paměti jsou také 4 registrové banky po 8 registrech a 16 bytů bitově orientované paměti. o Horních 128 bytů je adresovatelných nepřímo. Do této části paměti lze přemístit zásobník. 3 časovače/čítače. Možnost přímo připojit až 64kb externí datové nebo programové paměti 4 vstupně/výstupní 8 bitové porty. 6 přerušení, z toho 2 externí a 2 úrovně priorit pro následnou obsluhu. Sériová linka s širokým rozsahem komunikačních rychlostí. Kmitočet krystalu až 24Mhz.

9.2. Struktura programu Veškeré programové vybavení pro tento procesor jsem psal v assembleru. Tento jazyk jsem považoval za vhodný, protože procesor je nedílnou součástí adaptéru a ne jen řidícím prvkem. Důležitou roli zde hraje především rychlost. Tato koncepce také dovoluje plnou kontrolu nad využitím paměti, případně periferních zařízení, která jsou součástí procesoru. Struktura programu vychází z použitého procesoru a především z obvodového zapojení adaptéru. Tak jak lze adaptér rozdělit na jednotlivé části obsluhující příslušné rozhraní, i řidící program se dá rozdělit podobným způsobem. Celý program reaguje především na události, a proto je smyčka hlavního programu relativně velmi krátká. Obsahuje pouze testování příznaků, zda nedošlo k nějaké události s následným voláním obslužné rutiny. Zdrojem většiny podnětů pro vykonání příslušné operace je externí přerušení, kterým obvod pro převod USB na IDE dává procesoru najevo, že je třeba zareagovat na vzniklou situaci. Pro ladění a zobrazování stavových informací byl adaptér dovybaven LCD displayem a 16 LED diodami. Zakomponování obsluhy těchto zařízení do programu adaptéru bylo navrženo tak, aby případné vyjmutí tohoto kódu bylo zcela bezproblémové.

45

9.2.1. Obsluha přerušení Řidící program adaptéru využívá pouze dvě přerušení. Jedno je externí a obsluhuje události obvodu pro převod USB na IDE a druhé je vyvoláno časovačem číslo 2 a stará se o pravidelnou obnovu stavových informací a LCD display. Externí přerušení – Jak již bylo uvedeno výše, toto přerušení se stará o události obvodu Philips, který fyzicky realizuje převod IDE na USB. Tento obvod je k mikrokontroléru připojen jako externí datová paměť a jeho jednotlivé registry se chovají jako paměťové buňky na příslušných adresách. Některé registry jsou vyhrazeny pro uložení příznaků. Z této obslužné rutiny nemůže být volán příslušný podprogram na zpracování dané události. Pokud by se tak stalo, tento podprogram by stále běžel v režimu obsluhy přerušení a nebylo by možné čekat na případnou další událost, protože zpracování stejného přerušení není možné. Z toho důvodu se pouze překopírují příznaky události, která přerušení způsobila. Je důležité si uvědomit, že nelze příznaky pouze překopírovat, ale musí se přidat k ještě nevyřízeným požadavkům. Pokud by se tak nestalo, nově příchozí přerušení by mohlo dosud nezpracované požadavky vymazat. Jednotlivé příznaky jsou následně testovány v hlavní smyčce programu. Přerušení od časovače 2 – Při každém přetečení časovače 2 je vyvolána rutina pro tento časovač. Nastavení režimu a registrů tohoto časovače ovlivňuje periodu, s jakou bude toto přerušení vyvoláno. Kód této rutiny se stará o obnovu stavových informací zobrazených na LED diodách pomocí záchytných registrů a také o aktualizaci informací zobrazených na LCD. V tomto případě se nejedná o zpracování žádné časově kritické události a perioda přetečení tohoto časovač je 100ms. Zastavením tohoto časovače lze zobrazování těchto informací zcela zakázat. Zobrazení stavových informací se neděje přímo, ale jednotlivé příznaky jsou pouze okopírovány na stavové LED diody.

9.2.2. Rozdělení paměti Jak už je uvedeno v základní charakteristice použitého procesoru, je třeba vhodně provést rozdělení paměti pro uchovávání stavových informací za běhu adaptéru. Použitá strategie je uvedena v následujících bodech : Registrové banky – Každé přerušení používá svou registrovou banku. Tímto způsobem nemůže dojít k přepsání informací. Taktéž jsou uchovány stavové informace a obsah střadače. Bitová oblast – K uložení některých příznaků stačí jednotlivé bity. K této oblasti paměti se také dá přistupovat po celých bytech. Zvolil jsem tedy rozložení bitů takové, aby bylo shodné s případným zdrojem informací. Díky tomu lze celkem asi 30 příznaků přerušení od obvodu Philips překopírovat pouhým kopírováním 6 bytů. Stejným způsobem lze aktualizovat i stavové informace na LED diodách. V tomto případě stačí překopírovat pouhé 2 byty. Tento přístup je efektivní a především velmi rychlý. Přímo adresovatelná oblast – V této části jsou uloženy stavové informace, pro jejichž uložení stačí většinou byte nebo dva, výjimečně čtyři. Tato paměť je téměř celá využita Nepřímo adresovatelná paměť – V této části je vyhrazen prostor pro uložení aktuálního příkazového bloku (CDB). Taktéž je zde vyhrazeno místo pro obsah LCD. Obsah těchto paměťových

46

buněk se v pravidelných intervalech daných přetečením časovače 2 překopíruje do paměti řadiče LCD, který je následně zobrazí. Podle počtu znaku daného LCD se musí vyhradit prostor v této paměti. Na počátek zbývajícího volného místa je při inicializaci nastaven ukazatel zásobníku. U tohoto typu procesoru se při uložení na zásobník adresa zvětšuje.

9.2.3. Pojmenovaná paměťová místa, konstanty, zdrojové soubory Programové vybavení pro navrhnutý adaptér je velmi rozsáhle a bylo nutné zvolit nějaký systém pro členění zdrojového kódu. Ze stejných důvodů jsou paměťová místa pojmenována. Tímto způsobem se zvětšuje přehlednost programového díla a taktéž je daleko jednodušší provádět případné změny. Nejvíce patrné je to v případě pojmenovaných konstant a paměťových míst. Jakákoli změna se projeví pouze v definici symbolu a není nutné zasahovat do vlastního kódu. Zdrojový kód je rozdělen do tématicky celků, které mají za úkol obsluhovat určitou část požadavků a událostí. Tyto části jsou vždy uloženy v samostatných souborech. Jména návěští jsou volena tak, aby bylo patrné, do které části programu příslušný kód patří. Podobnou koncepci jsem zvolil i při pojmenovávání paměťových míst procesoru. Většina definic je uvedena v hlavním souboru programu. Pouze názvy a adresy registrů obvodu pro převod IDE na USB jsou uloženy zvlášť, stejně tak jako deskriptory pro identifikaci USB zařízení. Jsou to konstanty uložené v paměti programu a procesor je dle potřeby načítá a posílá hostiteli.

9.3. Charakteristika jednotlivých bloků V následujících podkapitolách je uveden základní popis jednotlivých bloků řidícího programu. Důraz je kladen především na charakteristiku požadavků, které je daný kód schopen obsloužit. Vzhledem k rozsáhlosti obsluhy komunikace po USB je tato část dále rozdělena do dvou celků.

9.3.1. Inicializace Pro samotnou funkci adaptéru bez IDE zařízení není nutné připojení externího napájení. Po připojení adaptéru k hostiteli se procesor inicializuje a provede nastavení zbývajících částí adaptéru. Toto počáteční nastavení lze rozdělit do několika kroků : • • •

• • •

Inicializace obsluhy přerušení samotného mikrokontroléru. Nulování obvodu pro převod IDE na USB. Nastavení parametrů obvodu pro převod IDE na USB, které ovlivňují komunikaci s řidícím mikrokontrolérem. (polarita a průběh přerušovacího signálu, povolení přerušení pro jednotlivé události apod.) Inicializace LCD display, který používá standardní sadu příkazů pro tento typ zařízení. Je nutné provést SW reset tohoto zařízení. Spuštění obsluhy obnovy stavových informací. Nastavení USB části obvodu do výchozí konfigurace, kdy je hostitel schopen detekovat nově připojené zařízení. Tuto operaci je vhodné provést až jako úplně poslední, zamezí se tím případným nedefinovaným stavům.

47

9.3.2. USB část – koncový bod 0 Tento blok kódu zodpovídá za obsluhu veškeré komunikace na koncovém bodu 0. Pomocí této roury jsou doručovány adaptéru všechny standardní požadavky, které jsou povinně implementovatelné dle USB specifikace [3]. Některé požadavky mohou být určeny pro celé zařízení, vybrané rozhraní (interface) nebo konkrétní koncový bod. Pro potvrzení úspěšného nebo neúspěšného splnění požadavku se používá speciální sekvence paketů. Tyto podrobnosti jsou uvedeny ve specifikaci univerzální sériové sběrnice [3]. O tom ,zda daný požadavek je platný, rozhoduje také fáze konfigurace, ve které se zařízení nachází. Vždy když zařízení obdrží Setup paket od hostitele, který slouží pro předávní požadavků, obdrží také ve formě dat nejméně 8 bytů, jenž daný požadavek specifikují. Položky bmRequestType a bRequest jsou 1 bytové zbývající tři 2 bytové (wIndex, wLength, wValue). Všechny povinné požadavky společně se základní charakteristikou jsou uvedeny níže. Clear Feature – některé vlastnosti USB zařízení jsou za chodu konfigurovatelné a pomocí tohoto příkazu lze některé vlastnosti zakázat. Každá nastavitelná vlastnost může patřit celému zařízení, příslušnému rozhraní nebo koncovému bodu. Jak je patrné z tabulky (Tabulka 9.1 Význam jednotlivých položek pro příkaz Clear Feature), položka bmRequestType určuje adresáta v rámci zařízení. Adresát

bmRequestType

bRequest

wValue

wIndex

wLength

Data

Device Interface EndPoint

00000000B 00000001B 00000010B

Clear Feature

Feature Selector

0 Interface EndPoint

0

Žádná

Tabulka 9.1 Význam jednotlivých položek pro příkaz Clear Feature Get Configuration – každé USB zařízení může mít několik možných konfigurací. Hostitel si může vyžádat všechny konfigurace. Podle toho, která mu nejvíce vyhovuje přidělí jednu ze zaslaných konfigurací zpět zařízení. V rámci jedné konfigurace může existovat několik rozhraní (interface). V mém případě používám pouze jedno rozhraní patřící do třídy velkokapacitních zařízení. Pokud bych chtěl například doimplementovat vlastní diagnostické funkce, přidám do dané konfigurace další rozhraní, které to předchozí nijak neovlivní. V každém rozhraní existuje určitá konfigurace koncových bodů. Zvláštním případem je rozhraní, které nabídne ještě alternativní nastavení. Je to skupina rozhraní, ze kterých si hostitel muže vybrat pouze jedno, a toto rozhodnutí sdělit zařízení. Všechny výše uvedené informace jsou uvedeny v deskriptorech, které zařízení na požádání zašle hostiteli. Navrhovaný adaptér je pode USB specifikace verze 2.0. Z tohoto důvodu se musí rozlišovat, zda zařízení komunikuje na rychlosti Full speed nebo High speed. Pro každou rychlost je definovaná zvláštní sada deskriptorů. Tento příkaz slouží pro získání aktuální konfigurace zařízení. Pokud zařízení nebyla ještě žádná konfigurace přidělena, vrací hodnotu 0. Jednotlivé konfigurace jsou identifikovány 8 bitovým číslem. Tato hodnota je vrácena hostiteli jako odezva na tento požadavek. V následující tabulce (Tabulka 9.2 Význam jednotlivých položek pro příkaz Get Configuration) je uveden význam jednotlivých položek.

48

Adresát

bmRequestType

bRequest

wValue

wIndex

wLength

Data

Device Interface EndPoint

10000000B

Get Configuration

0

0

1

In

Tabulka 9.2 Význam jednotlivých položek pro příkaz Get Configuration Get Descriptor – tímto příkazem si hostitele vyžádá příslušný deskriptor zařízení. V rámci deskriptoru popisující zařízení je také uveden celkový počet možných konfigurací zařízení. Pokud je vydán požadavek na zaslání deskriptoru popisující zvolenou konfiguraci, jsou také automaticky poslány deskriptory rozhraní patřících do dané konfigurace. V rámci deskriptoru rozhraní jsou taktéž poslány informace o koncových bodech daného rozhraní. Existuje několik typů deskriptorů. Každý je specifikovaný pojmenovanou konstantou, je definována jeho struktura. Zvláštním typem jsou řetězcové deskriptory. Ty slouží k uchování textových informací o zařízení. Každý používaný jazyk má své číslo. Pokud zařízení podporuje více jazykových variant může, si hostitel vybrat, kterou jazykovou mutaci textových informací použije. Význam jednotlivých položek je opět zobrazen v následující tabulce (Tabulka 9.3 Význam jednotlivých položek pro příkaz Get Descriptor). Adresát

bmRequestType

bRequest

wValue

wIndex

wLength

Data

Device Interface EndPoint

10000000B

Get Deskriptor

Typ deskriptoru a jeho index

0 nebo identifikační číslo jazyka

Délka deskriptoru

In

Tabulka 9.3 Význam jednotlivých položek pro příkaz Get Descriptor Get Interface – pokud zařízení umožňuje výběr z více možných rozhraní (interface), může hostitel tímto příkazem zjistit právě vybrané rozhraní, které bylo zařízení přiděleno v rámci konfigurace zařízení. Pro identifikaci rozhraní je vyhrazen jeden byte, který se vrací jako výsledek příkazu hostiteli. Význam jednotlivých položek je zobrazen v následující tabulce (Tabulka 9.4 Význam jednotlivých položek pro příkaz Get Interface). Adresát

bmRequestType

bRequest

wValue

wIndex

wLength

Data

Device Interface EndPoint

10000000B

Get Interface

0

Číslo požadovaného rozhraní

1

In

Tabulka 9.4 Význam jednotlivých položek pro příkaz Get Interface Get Status – Pomocí tohoto příkazu může hostitel zjistit některé další informace o stavu zařízení. Některá zařízení mohou být napájena jak ze sběrnice, tak z externího zdroje. Tímto příkazem lze získat informace o současném stavu napájení. Stejným způsobem lze také zjistit, zda zařízení má právě zapnutou podporu vzdáleného probuzení. Výše uvedené stavové informace jsou vlastností zařízení. V současné specifikaci sběrnice nemají jednotlivá rozhraní žádné vlastnosti, které by bylo možno

49

pomocí tohoto příkazu hostiteli vrátit. U každého koncového bodu je udržován příznak, zda není pozastaveno přijímání nebo vysílání dat. Pokud je tedy adresován koncový bod, je vrácena informace o tom, zda je vybraný koncový bod pozastaven nebo ne. Data posílána hostiteli jsou vždy 2 bajty dlouhá a formát je závislý na adresátovi příkazu. Jednotlivé položky příkazu jsou uvedeny v následující tabulce (Tabulka 9.5 Význam jednotlivých položek pro příkaz Get). Adresát

bmRequestType

Device Interface EndPoint

10000000B 10000001B 10000010B

bRequest

wValue

wIndex

wLength

Data

0

0 Interface EndPoint

2

In

Get Status

Tabulka 9.5 Význam jednotlivých položek pro příkaz Get Stauts Set Address – tímto příkazem hostitel přikazuje zařízení nastavit si svou novou adresu, na které bude odpovídat na zaslané požadavky. Po připojení má každé zařízení vždy adresu 0. Po tomto příkazu zařízení musí komunikovat pouze na této adrese. Přidělená adresa se může pohybovat v rozsahu 0 až 127. Z tohoto rozsahu plyne omezení na počet současně připojených zařízení. Položky příkazů jsou uvedeny v tabulce (Tabulka 9.6 Význam jednotlivých položek pro příkaz Set Address). Adresát

bmRequestType

bRequest

wValue

wIndex

wLength

Data

Device Interface EndPoint

00000000B

Set Address

Přidělovaná adresa zařízení

0

0

Žádná

Tabulka 9.6 Význam jednotlivých položek pro příkaz Set Address Set Configuration – tímto příkazem zvolí hostitel jednu z nabízených konfigurací. Seznam konfigurací, které zařízení poskytuje, lze získat pomocí příkazu Get Descriptor. Pokud hostitel požaduje konfiguraci nula, znamená to, že zařízení má přejít do stavu, kdy není nakonfigurováno. U USB zařízení se rozlišuje několik vnitřních stavů během konfigurace. Zasláním příslušného příkazu může zařízení přejít do jiného stavu, případně se může vrátit o krok zpět. Význam jednotlivých položek je opět uložen v následující tabulce (Tabulka 9.7 Význam jednotlivých položek pro příkaz Set Configuration). Adresát Device Interface EndPoint

bmRequestType

bRequest

wValue

wIndex

wLength

Data

00000000B

Set Configuration

Identifikace přidělované konfigurace

0

0

Žádná

Tabulka 9.7 Význam jednotlivých položek pro příkaz Set Configuration Set Descriptor – ačkoli všechny příkazy zde uvedené patří do skupiny povinně implementovaných, zařízení může na tento příkaz odpovědět chybou a dát tak hostiteli najevo, že tento příkaz

50

nepodporuje. Za použití tohoto příkazu může hostitel modifikovat deskriptor USB zařízení nebo dokonce přidat zcela nový. Význam jednotlivých položek se odvíjí od příkazu pro získání deskriptoru. Stejnou strukturu budou mít i obdržená data. Význam jednotlivých položek je opět uveden v následující tabulce (Tabulka 9.8 Význam jednotlivých položek pro příkaz Set Descriptor). Adresát

bmRequestType

bRequest

wValue

wIndex

wLength

Data

Device Interface EndPoint

00000000B

Set Descriptor

Typ deskriptoru a jeho index

0 nebo identifikační číslo jazyka

Délka deskriptoru

Out

Tabulka 9.8 Význam jednotlivých položek pro příkaz Set Descriptor Set Feature – tímto příkazem lze nastavit některé vlastnosti zařízení. Pro smazání těchto nastavení slouží příkaz Celar Feature a na zjištění stavu se používá příkaz Get Status. Adresovanému koncovému bodu se může nastavit příznak Halt, který znemožňuje příjímání a vysílání dat. Takto pozastavený koncový bod vrací na všechny požadavky STALL. Celému USB zařízení se může povolit provést vzdálené probuzení, pokud je třeba. Pro účely testování kvality propojení mezi USB zařízením a USB hostitelem při komunikaci na rychlosti High speed existuje několik příznaků, které nastaví vysílací a přijímací část zařízení do definovaných stavů. Hostitel si tak může ověřit některé fyzické vlastnosti propojení. Význam jednotlivých položek příkazu je uveden v tabulce (Tabulka 9.9 Význam jednotlivých položek pro příkaz Set Feature). Adresát

bmRequestType

bRequest

wValue

Device Interface EndPoint

00000000B 00000001B 00000010B

Set Feature

Feature Selector

wIndex

wLength

Data

0

Žádná

0 Test Interface Selector EndPoint

Tabulka 9.9 Význam jednotlivých položek pro příkaz Set Feature Set Interface – Tímto příkazem si hostitel vybere rozhraní, které má zařízení používat. Tento výběr se může uskutečnit pouze za předpokladu, že zařízení nabízí výběr možných nastavení daného rozhraní. Tuto skutečnost se hostitel dozví v okamžiku, kdy si nechá poslat deskriptory zařízení. Význam jednotlivých položek je uveden v tabulce (Tabulka 9.10 Význam jednotlivých položek pro příkaz Set Interface). Adresát

bmRequestType

bRequest

wValue

wIndex

wLength

Data

Device Interface EndPoint

00000001B

Set Interface

Alternativní konfigurace

Číslo rozhraní

0

Žádná

Tabulka 9.10 Význam jednotlivých položek pro příkaz Set Interface

51

Synch Frame – tento příkaz má význam pouze u izosynchroního typu přenosu, kdy jsou data přenášena v pravidelných intervalech. Tímto způsobem hostitel sdělí zařízení číslo rámce, od kterého se bude provádět přenos dat v definovaných intervalech. Rozložení a význam položek je uveden v následující tabulce (Tabulka 9.11 Význam jednotlivých položek pro příkaz Synch Frame). Adresát

bmRequestType

bRequest

wValue

wIndex

wLength

Data

Device Interface EndPoint

10000010B

Synch Frame

0

Koncový bod

2

Out

Tabulka 9.11 Význam jednotlivých položek pro příkaz Synch Frame Seznam povinně podporovaných příkazů slouží k nastínění problematiky komunikace na USB sběrnici. Všechny uvedené příkazy souvisí pouze s USB sběrnicí a nemají nic společného se zařízením, které je pomocí této sběrnice připojeno. Třída velkokapacitních zařízení přidává k této skupině příkazů ještě dva povinně implementovatelné požadavky, které jsou uvedeny v kapitole věnované této problematice. Pro lepší orientaci je v dokumentaci obsah položky bRequest popsán slovně. Ve skutečnosti tyto názvy představují konstanty. Tento princip je uplatněn i pro položky specifikující Feature Selector a Test Selector. Položka bmRequestType popisuje další vlastnosti příkazu. Některé bity jsou vyhrazeny pro určení adresáta příkazu (zařízení, rozhraní, koncový bod), některé specifikují skupinu, do které příkaz patří (Standardní, Specifický pro třídu, Příkaz výrobce zařízení), a jeden je vyhrazen pro specifikaci směru přenosu dat. Při zpracovávání těchto příkazů se musí ověřovat obsah jednotlivých položek. O tom, zda vykonávání příkazu skončí chybou, nebo ne, také rozhoduje současný interní stav zařízení. V jistých stavech je použití některých příkazů zakázáno a není rovněž definováno, s jakým výsledkem tato operace skončí. Zpracování všech těchto událostí probíhá na koncovém bodu 0, po kterém nejsou většinou přenášena žádna uživatelská data do zařízení a zpět. Všechny tyto požadavky musí řidící program procesoru korektně obsloužit.

9.3.3. USB část – koncový bod 1 Na tomto koncovém bodu probíhá veškerá komunikace podle protokolu, který je nadefinován ve specifikaci pro třídu velkokapacitních zařízení, pouze za využití koncových bodů typu bulk. Teprve v okamžiku, kdy je USB zařízení nakonfirgurováno a je plně funkční podle specifikace, začne probíhat komunikace na tomto koncovém podle protokolu uvedeného v kapitole věnované třídě velkokapacitních zařízení. Z pohledu USB sběrnice je tento protokol chápan pouze jako přenos dat bez dalšího zkoumání významu. Od tohoto okamžiku lze USB rozhraní považovat za transparentní transportní vrstvu. Na jedné straně se data vloží do vyrovnávací paměti a na druhé straně se objeví. V okamžiku, kdy se na tomto koncovém objeví nová data, zahájí se zpracování. Data se přečtou a začne se zkoumat, zda odpovídají specifikaci použitého protokolu. Konkrétně se jedna o CBW. Pokud jsou všechny položky správné a mají smysluplný význam, jsou některé údaje uchovány pro následné odeslání CSW. Z bloku CBW je také překopírován samotný příkaz, který se má vykonat. V tomto případě používám plnou sadu SCSI příkazů. Právě získaný příkaz se předá části starající se o překlad příkazů do podoby vhodné pro IDE zařízení. V případě, že příkaz požaduje přenos dat, jsou tato data nakopírována z daného koncového bodu do IDE zařízení nebo naopak. Výsledek takovéto operace je

52

předán zpět a na jeho základě je odesláno CSW s patřičně nastavenou položkou pro výsledek právě zadaného příkazu. Před zpracováním prvního CBW příkazu se ještě provede reset IDE zařízení. Následuje sekvence příkazů, které ověří správnou funkci zařízení. Pokud jsou zařízení v pořádku, provede se přečtení vlastností každé připojené jednotky. Na základě těchto informací se nastaví jak fyzické rozhraní obvodu pro převod IDE na USB, tak rozhraní připojených jednotek. Teprve pokud všechny tyto požadavky proběhnou úspěšně, je povoleno zpracování prvního CBW bloku. Podrobnější popis posloupností při inicializaci je uveden v části věnované inicializaci a komunikaci s IDE zařízením.

9.3.4. Inicializace a komunikace s IDE zařízením Tato část obslužného programu adaptéru je zodpovědná za spolupráci s připojenými IDE zařízeními. Pro správnou funkci je třeba provést správnou detekci a nastavení všech parametrů rozhraní. Inicializace probíhá v těchto krocích : • • • •

•

Reset IDE zařízení. Provedení diagnostiky zařízení. Zjištění výsledku diagnostiky jednotlivých zařízení a určení typu zařízení na základě signatury v zanechané registrech jednotky. Pokud se jedná o diskové zařízení, je provedena identifikace pomocí příkazu IDENTIFY DEVICE, v případě ATAPI zařízení je identifikace provedena pomocí příkazu IDENTIFY PACKET DEVICE. Některé vlastnosti obou jednotek jsou uloženy v paměti mikrokontroléru po další použití. Nastavení IDE rozhraní obvodu Philips a konfigurace IDE zařízení.

Poslední bod konfigurace zařízení stojí za podrobnější popis. Během identifikace jednotky se musí uchovat některé informace pro další správnou funkci adaptéru. Tyto základní parametry jsou uvedeny v následujících bodech a rozděleny podle typu zařízení. Diskové zařízení – Jak už bylo uvedeno v základním popisu IDE rozhraní, lze sektory na disku adresovat dvěma způsoby. Pokud zařízení podporuje lineární adresování, musíme si uchovat informaci o maximální možné hodnotě sektoru. Pokud zařízení tento režim nepodporuje, jsou sektory adresovány v režimu CHS. I v tomto případě je nutné znát maximální hodnoty jednotlivých položek. SCSI příkazy používají pro identifikaci sektorů vždy lineární režim. Bez znalostí maximálních hodnot CHS by ani nebyl možný přepočet z LBA na CHS. Pro co možná nejvyšší přenosové kapacity se uchovávají informace o maximálním použitelném PIO režimu a případné podpoře DMA režimu. Dále se uchovává informace tom, zda jednotka podporuje výměnná média. Pokud ano, je třeba vědět, jestli zařízení podporuje oznámení při výměně média, nebo se musí IDE hostitel (v tomto případě obvod Philips s řidícím procesorem) na tu událost dotazovat. ATAPI zařízení – jak už bylo uvedeno, ATAPI příkazy posílané pomocí příkazu PACKET jsou odvozeny se ze skupiny MMC SCSI příkazů. ATAPI zařízení mohou podporovat buď 12 nebo 16 bytové CDB. Tuto informaci je nutné uchovat pro správnou transformaci příkazů od hostitelského systému. Problematika PIO a DMA režimů je stejná jak u diskových zařízení, stejně tak jak podpora výměnných médií.

53

Otázka použitých komunikačních protokolů a jejich rychlosti je aktuální zejména v případě dvou připojených zařízení. Všechny signály jsou přenášeny pomocí jednoho datového kabelu. Pokud je k hostiteli připojeno pouze jedno IDE zařízení, lze nastavit komunikační protokoly na nejvyšší možnou rychlost podporovanou zařízením (pokud to zvládne hostitel). V případě dvou jednotek se musí použít maximálně komunikační protokol pomalejší z nich. PIO režimy musí podporovat všechna zařízení. DMA protokol je volitelný, a pokud jej některé zařízení nepodporuje, nesmí být použit ani při komunikaci s druhým zařízením. Použitý obvod pro převod IDE na USB se chová jako IDE hostitel a podporuje PIO 0 až PIO 4 a DMA 0 až DMA 2. Teoretická hranice přenosové kapacity IDE rozhraní je v tomto případě 33MB/s.

9.3.5. Transport a překlad SCSI příkazů na IDE Tato část řidícího programu má za úkol transformovat SCSI příkazy do podoby vhodné pro IDE zařízení. Zde také probíhá transformace všech parametrů každého požadavku. U disků je to především volba jednoho z adresovacích režimů. Nemá smysl provádět transformaci LBA na CHS, pokud jednotka podporuje lineární režim adresování. Obdobné je to v případě použitého protokolu pro přenos načtených dat z disku nebo naopak. Řidící program má vždy snahu použít co nejvýkonnější komunikační protokol se zařízením. Výkonností se v tomto případě rozumí přenosová rychlost. Mezi IDE a SCSI rozhraním existuje několik principiálních rozdílů. Z tohoto důvodů jsou některé požadavky vyřízeny bez nutnosti přistoupit k IDE zařízení. Týká se to především požadavku na zjištění výsledku předchozí operace a identifikaci zařízení. Princip zpracování požadavků je zobrazen na následujícím obrázku (Obrázek 9.1 Transport a překlad SCSI příkazů) včetně zpracování protokolu pro velkokapacitní zařízení.

Obrázek 9.1 Transport a překlad SCSI příkazů

54

10. Závěr Během návrhu a realizace adaptéru se vyskytla řada problémů, které bylo třeba nějakým způsobem vyřešit. Většina potíží plynula z mé vlastní nezkušenosti a z neznalostí v oblasti USB sběrnice a IDE zařízení. Jedna věc je přečíst si dokumentaci k danému rozhraní a pochopit principy komunikace, druhá je všechny požadavky dané touto specifikací úspěšně implementovat Dovolím si tvrdit, že úspěšná implementace je daleko náročnější, protože musí korektně postihnout všechny možné stavy. Taktéž jsem se přesvědčil, že v dokumentaci není vždy vše jednoznačně popsáno a skutečné chování si lze ověřit pouze experimentováním. Získání těchto znalostí je většinou vykoupeno dlouhým testováním a někdy i zničením některých zařízení. Všechny takto získané informace jsou velmi cenné a ve většině případů není možné je získat jinou cestou. Nelze se proto divit, že si tyto znalosti firmy vyvíjející HW dosti úzkostlivě chrání. V další části této kapitoly se pokusím popsat zásadní problémy, které jsem musel vyřešit.

10.1. USB protokol Během implementace tohoto komunikačního protokolu se vyskytlo několik nejasností, případně odchylek od dokumentace. Bohužel oficiální podpora od implementačního fóra USB sběrnice stojí na rok 2500 USD a stala se tak pro mě nedosažitelnou. Největší problém byl především s protokolem pro třídu velkokapacitní zařízení. Ačkoli tato specifikace doplňuje standardní USB požadavky o příkaz Bulk-Only Mass Storage Reset a GetMaxLun, hostitel tyto příkazy nikdy nepoužil. V případě potřeby resetu části pro velkokapacitní zařízení provede hostitel bez zaváhání reset celého USB zařízení. Otázka zní, jak by se hostitel zachoval, kdyby připojované zařízení mělo více nezávislých rozhraní (interface). Daleko větší problém vznikl nepoužitím příkazu pro zjištění počtu logických jednotek. Hostitel automaticky předpokládá, že je připojeno pouze jedno logické zařízení. Díky této vlastnosti nemůže adaptér podporovat připojení dvou IDE zařízení. Se současnou koncepcí řízení adaptéru je tento problém neřešitelný. Tento nedostatek by bylo možné vyřešit tak, že by se přidalo ještě jedno nezávislé rozhraní pro třídu velkokapacitních zařízení. Každé IDE zařízení by tak získalo své vlastní rozhraní třídy velkokapacitních zařízení. Znamenalo by to především duplikovat a následně přepracovat část starající se o Mass Storage protokol. S využitím současného procesoru by to nebylo možné z paměťových důvodů. Programová paměť je téměř zaplněná. Taktéž by se musely přidat deskriptory popisující další rozhraní třídy velkokapacitních zařízení. Nově navržená koncepce adaptéru je zobrazena na následujícím obrázku (Obrázek 10.1 Nově navržená koncepce ovládání IDE zařízení). V tomto případě také stojí za úvahu, zda by nebylo vhodné před konfigurací USB části hostitelem provést detekci připojených IDE zařízení a podle typu zařízení upravit používaný protokol pro komunikaci se zařízením pro dané rozhraní (interface). Protože jsem při analýze možných připojení IDE zařízení a použitých protokolů nepředpokládal problémy s používáním logických jednotek, tuto variantu jsem z důvodů paměťových nároků a větší složitosti zavrhl. Ukazuje se, že je to asi jediné možné řešení. Tyto skutečnosti jsem nemohl ve fázi návrhu bohužel předpokládat.

55

Obrázek 10.1 Nově navržená koncepce ovládání IDE zařízení

10.2. Obvod Philips ISP 1581 Při návrhu obvodového zapojení adaptéru jsem měl potíže se získáním tohoto obvodu. Když jsem začal obvod zkoumat, zjistil jsem, že se jedná o funkční vzorek a výsledné chování obvodu konečné verze se může ještě nepatrně změnit. Funkčním vzorkem by se dala nazvat i dokumentace k tomuto obvodu, která není vždy dostatečně podrobná. Experimentováním se mi povedlo některé další informace získat. Za velmi nepříjemné ovšem považuji chyby v dokumentaci. Většinou když něco nefungovalo tak jak mělo, hledal jsem chyby ve svém řidícím programu. Skutečnost, že se obvod v některých případech chová jinak než je uvedeno v dokumentaci, mě velmi nemile překvapila. Celkem jsem narazil na tři neshody mezi dokumentací a chováním obvodu. Většina se týkala obsluhy přerušení. Počátkem května tohoto roku se na stánkách firmy Philips objevila nová revize dokumentace k nové revizi obvodu ISP 1581 [10]. Po předchozích špatných zkušenostech jsem ji také prostudoval a dozvěděl se některé důležité informace k funkci obvodu, bez jejichž znalostí by celý adaptér nemohl správně fungovat. Rovněž bylo přepracováno doporučené zapojení toho obvodu. To se týkalo především napájení a principiálně je toto zapojení shodné s tím, které jsem musel navrhnout.

10.3. IDE zařízení Na první pohled by se mohlo zdát, že pokud existuje podrobná dokumentace k rozhraní, nebude problém toto rozhraní použít. Přesvědčil jsme se, že opak je pravdou, což je obzvlášť markantní u IDE rozhraní. První IDE zařízení se objevilo v osobním počítači s procesorem Intel 86286. Tehdy se toto rozhraní označovalo jako ATA. Jak šel dopředu vývoj počítačů, vyvíjelo se i toto rozhraní a v současné době je ve fázi schvalování verze 7. V každé nové verzi se většinou přidávaly nové vlastnosti a ty nepotřebné se u nových jednotek vypouštěly. Každá nová revize tohoto rozhraní je koncipována tak, aby byla zpětně kompatibilní. Novější verze dokumentace už neobsahují všechny požadavky, které se musí splnit, aby starší zařízení bezchybně fungovala. Tato skutečnost mě také překvapila. Předpokládal jsem, že když je novější verze dokumentace zpětně kompatibilní, budou v ní uvedeny i všechny požadavky pro správnou funkci všech zařízení. Tento problém se stal aktuální v okamžiku, kdy jsem chtěl získat data z disku o kapacitě 425Mb a rokem výroby 1994. Přes veškerou snahu skončil pokus o čtení dat z disku vždy chybou. Protože jsem pro tuto skutečnost nenašel žádné vysvětlení v dokumentaci použité při návrhu, začal jsem pátrat ve starších revizích. Teprve u verze ATA-2 jsem narazil na poznámku, že pokud chce hostitel přistoupit k médiu u zařízení podle verze ATA-1, musí u některých jednotek nejdříve nastavit parametry překladu pro CHS přístup. Rovněž je

56

všeobecně známo, že s některými staršími disky značky Seagate (většinou s kapacitou do 1GB) jsou potíže. Tato zařízení většinou nebyla schopna spolupracovat s druhou jednotkou na stejném datovém kabelu. Měl jsem k testování i disk patřící do této kategorie. Při prvním požadavku pro přístup na disk řidící program adaptéru provede nulování IDE rozhraní a identifikaci jednotek. Rovněž adaptér provede diagnostiku obou jednotek pomocí příkazu Execute Diagnostic. Ačkoli je tento příkaz povinný, tento disk zrušil vykonávání toho příkazu. Rovněž nezapsal signaturu do svých registrů. Z těchto skutečností plyne, že výrobce tohoto disku se s IDE specifikací moc nezatěžoval. Implementace ovládání IDE rozhraní byl jeden velký kompromis mezi funkčností a co možná největším počtem podporovaných zařízení. Všechny tyto problémy vedly k neúměrnému prodloužení času, který jsem musel věnovat implementaci ovládání IDE disků. Díky tomu jsem se nemohl již věnovat jednotkám typu CD-ROM, a proto je adaptér zatím nepodporuje. Z pohledu ATAPI protokolu se s největší pravděpodobností jedná pouze o předávání 12 nebo 16 bytů dlouhých Command Data Block (CDB), ATAPI jednotce pomocí příkazu Packet. Tuto skutečnost jsem již nestihl ověřit.

10.4. Zhodnocení dosažených parametrů Se současným programovým vybavením je adaptér schopen připojit k počítači jedno diskové zařízení přes USB sběrnici. Pokud se tak stane, na hostitelském počítači se zobrazí informace o připojení nového USB zařízení, které patří do třídy velkokapacitních zařízení. Operační systém se pokusí přečíst informace z takto připojeného disku. Pokud objeví záznam o platném rozdělení disku, vytvoří pro každý nalezený oddíl logickou diskovou jednotku a přiřadí ji do systému. S takto vytvořenou jednotkou lze nakládat stejným způsobem, jako by to byl disk uvnitř počítače. Vzhledem k tomu, že zobrazování struktury souborů na disku má na starosti systém, neměl by být problém s různými souborovými systémy. V případě systému Windows XP a Windows 2000 není ani potřeba inf soubor. Stačí adaptér s diskem připojit k počítači a vše bude fungovat. V případě operačního systému Windows NT a Windows 98 je nutné k adaptéru dodat inf soubor, jenž operačnímu systému řekne, který svůj ovladač má použít a jak má zařízení ovládat. Některé základní desky počítačů podporují i start systému z USB zařízení. Protože navrhovaný adaptér patří do třídy velkokapacitních zařízení, měla by být funkční i tato vlastnost. Má základní deska tuto funkci nepodporuje, a proto jsem ji nemohl ověřit. Taktéž jsem neměl k dispozici žádné diskové zařízení s podporou protokolu UDMA a nemohl jsem ověřit jeho funkčnost. K testovacím účelům jsem měl pouze starší jednotky většinou se základním protokolem PIO 0. Při připojení na USB 1.1 jsem dosáhl přenosové kapacity zhruba 500kb/s a při USB 2.0 asi 600kb/s. Tyto přenosové rychlosti jsou dosti malé. Je to způsobeno relativně starým diskem, který jsem k testu použil, a také programovým vybavením adaptéru, které není optimalizováno na výkon. Při vývoji jsem se soustředil především na funkčnost. Teprve v okamžiku, kdy bude vše funkční, je vhodné provést úplnou optimalizaci. Díky problémům s IDE jednotkami jsem musel připojit celý adaptér k logickému analyzátoru a zkoumat průběhy jednotlivých signálů. Proto jsem mohl provést alespoň optimalizaci na úrovni registrů disku a přístupu k nim. Vzhledem k tomu, že jsem neměl vůbec žádné zkušenosti s IDE a USB rozhraním, považuji za úspěch, že připojené diskové zařízení funguje tak, jak má. Myslím si, že v tomto oboru jsou zkušenosti nesmírně důležité. Právě díky jejich absenci nemá adaptér takové parametry, jaké jsem si

57

představoval. Myslím si však, že kdybych v tomto okamžiku celé programové vybavení adaptéru přepracoval, dosáhl bych díky nově získaným zkušenostem daleko lepších parametrů. Pokud bych měl tento problém vyřešit znovu, provedl bych několik změn. Celková koncepce zapojení adaptéru by zůstala stejná, použil bych rychlejší řidící procesor s větší programovou pamětí. Mít více paměti pro ukládání dat za běhu programu by bylo vhodné především pro uložení dalších parametrů. Řidící program bych celý nepsal přímo v jazyce symbolických instrukcí. Použil bych vyšší programovací jazyk a pouze časově kritické operace bych napsal v assembleru. Princip začlenění adaptéru do operačního systému hostitele bych také ponechal stejný.

58

Literatura [1]

Urbiš, H. : USB sběrnice, [ročníkový projekt 2001], FEI VUT Brno, počet stran 40

[2]

Urbiš, H. : Návrh obvodů adaptéru pro převod rozhraní USB na rozhraní IDE, [semestrální projekt 2002], FEI VUT Brno, počet stran 30

[3]

Compaq, Hewlett-Packard, Intel, Lucent, Microsoft, NEC, Philips : Universal Serial Bus Specification, 2000, počet stran 622, dokument dostupný na adrese : http://www.usb.org/ (květen 2002), (http://www.usb.org/developers/data/usb_20.zip)

[4]

USB-IF : Universal Serial Bus Mass Storage Class Specification Overview, 2000, počet stran 7, dokument dostupný na adrese : http://www.usb.org/ (květen 2002), (http://www.usb.org/developers/data/devclass/usbmassover_11.pdf)

[5]

USB-IF : Universal Serial Bus Mass Storage Class - Bulk-Only Transport, 1999, počet stran 22, dokument dostupný na adrese : http://www.usb.org/ (květen 2002), (http://www.usb.org/developers/data/devclass/usbmassbulk_10.pdf)

[6]

Technical Committee T13 : ATA/ATAPI - 4, 1998, počet stran 323, dokument dostupný na adrese : http://www.t13.org/ (květen 2002), (http://www.t13.org/project/d1153r18.pdf)

[7]

Cant, C. : Writing Windows WDM DeviceDriver, Lawrence, Kansas, USA, R&D Books, 2000, počet stran 540

[8]

Universal serial bus implementation forum, http://www.usb.org/

[9]

Microsoft : Microsoft development network (MSDN)

[10] Philips : Datasheet ISP1581, 2000, počet stran 73, Dokument dostupný na adrese : http://www.philips.com/ (květen 2002), umístění dokumentu použitého při návrhu adaptéru : http://www-us9.semiconductors.com/acrobat/expired_datasheets/ISP1581-02.pdf, aktuální verze dokumentu : http://www-us9.semiconductors.com/acrobat/datasheets/ISP1581-03.pdf [11] Technical Committee T10, SCSI Architecture Model - 2 (SAM-2), 2002, počet stran 96, dokument dostupný na adrese : http://www.t10.org/ (květen 2002), (ftp://ftp.t10.org/t10/drafts/sam2/sam2r23.pdf) [12] Technical Committee T10, SCSI Primary Commands - 2 (SPC-2), 2001, počet stran 275, dokument dostupný na adrese : http://www.t10.org/ (květen 2002), (ftp://ftp.t10.org/t10/drafts/spc2/spc2r20.pdf)

59

[13] Technical Committee T10, SCSI Block Commands - 2 (SBC-2), 2002, počet stran 145, dokument dostupný na adrese : http://www.t10.org/ (květen 2002), (ftp://ftp.t10.org/t10/drafts/sbc2/sbc2r06.pdf) [14] Technical Committee T10, SCSI Multimedia Commands - 2 (MMC-2), 1999, počet stran 332, dokument dostupný na adrese : http://www.t10.org/ (květen 2002), (ftp://ftp.t10.org/t10/drafts/mmc2/mmc2r11a.pdf) [15] Skalický, P. : Mikroprocesory řady 8051, 2. rozšířené vydání, Praha, BEN – technická literatura, 2000, počet stran 159 [16] Atmel : Datasheet AT89C52, 1999, počet stran 23, dokument dostupný na adrese : http://www.atmel.com (květen 2002), (http://www.atmel.com/atmel/acrobat/doc0313.pdf)

60

Přílohy Příloha 1 - Demonstrace funkčnosti a začlenění adaptéru do hostitelského operačního sytému. Příloha 2 - Upravené obvodové zapojení adaptéru.

61

Příloha 1 - Demonstrace funkčnosti a začlenění do hostitelského operačního sytému

Obrázek 1 Odpojení nebo vysunutí HW

Obrázek 2 Správce zařízení

Obrázek 3 Vlastnosti velkokapacitního zařízení (adaptér)

Obrázek 4 Vlastnosti velkokapacitního zařízení (připojený disk)

Obrázek 5 Obsah připojeného disku

Příloha 2 - Upravené obvodové zapojení adaptéru.