Praca Dyplomowa

POLITECHNIKA ŚLĄSKA WYDZIAŁ AUTOMATYKI, ELEKTRONIKI I INFORMATYKI

KIERUNEK INFORMATYKA

PRACA DYPLOMOWA MAGISTERSKA

Opracowanie sterownika dysku twardego dla systemów typu

embedded z procesorem PowerPC

Prowadzący: Autor:

mgr inż. Jarosław Paduch Jacek Kościesza

Konsultant:

dr inż. Michał Jamicki (ADESCOM Polska Sp. z o.o.)

Gliwice 2007

PRACA DYPLOMOWA MAGISTERSKA Opracowanie sterownika dysku twardego dla systemów typu embedded z procesorem PowerPC

2


3

SSPPIISS TTRREEŚŚCCII

1. Temat i założenia pracy ........................................................................................................ 5

2. Środowisko sprzętowe i programowe.................................................................................. 7

2.1. Opis systemu embedded ................................................................................................ 8

2.2. Schematy układów systemu embedded ......................................................................... 9

2.3. Opis mikrokontrolera PowerPC 405GP ....................................................................... 13

2.4. Charakterystyka dysku twardego ................................................................................. 21

2.4.1. Budowa dysku twardego .................................................................................. 21

2.4.2. Standard ATA (interfejs równoległy) .............................................................. 22

2.5. Narzędzia projektowe i testowo-uruchomieniowe....................................................... 33

3. Projektowanie i implementacja oprogramowania ........................................................... 35

3.1. Model procesu tworzenia oprogramowania ................................................................. 35

3.2. Architektura tworzonego oprogramowania ................................................................. 37

3.3. Interfejs konfiguracji i obsługi systemu embedded ..................................................... 39

3.4. Sterownik dysku twardego ........................................................................................... 41

3.4.1. Zaimplementowane rozkazy ............................................................................ 41

3.4.2. API sterownika................................................................................................. 42

3.4.3. Struktury danych .............................................................................................. 47

3.4.4. Implementacja sterownika ............................................................................... 49

3.5. Testy ............................................................................................................................. 51

3.5.1. Testy szybkości komunikacji z kontrolerem dysku ......................................... 51

3.5.2. Test obciążenia procesora podczas transferu DMA ......................................... 52

3.6. System plików .............................................................................................................. 54

3.6.1. API systemu plików ......................................................................................... 54

3.6.2. Implementacja systemu plików........................................................................ 55

3.7. Powłoka........................................................................................................................ 57

4. Testowanie i uruchamianie ................................................................................................ 58

5. Wnioski ................................................................................................................................ 63

6. Dodatki ..................................................................................... Error! Bookmark not defined.

7. Literatura............................................................................................................................. 71


4


5

1. Temat i założenia pracy

Temat

Tematem pracy jest „Opracowanie sterownika dysku twardego dla systemów typu

embedded z procesorem PowerPC”. System embedded (wbudowany) jest tu rozumiany jako

system komputerowy specjalnego przeznaczenia, który staje się integralną częścią

obsługiwanego przez niego sprzętu [15]. Oprogramowanie jest realizowane przy współpracy

z firmą ADESCOM Polska Sp. z o.o.

Geneza tematu

Powodem zaproponowania realizacji powyższego tematu jest potrzeba rozszerzenia

funkcjonalności bramy VoIP firmy ADESCOM Polska Sp. z o.o. o obsługę dysków twardych.

Cel pracy

Głównym celem tematu pracy jest opracowanie sterownika dysku twardego dla systemów

typu embedded z procesorem PowerPC oraz szczegółowej dokumentacji opisującej API

(ang. Application Programming Interface) sterownika.

Dodatkowo należy oszacować pewne parametry związane ze sterownikiem

i wykorzystywaną platformą sprzętową, takie jak:

szybkość transferu w poszczególnych trybach transmisji danych (PIO, DMA, UDMA),

obciążenie procesora podczas transferu DMA.

W tym cel należy opracować i wykonać odpowiednie testy.

Następnie konieczne jest przetestowanie poprawności działania sterownika oraz

użyteczności API sterownika. W tym celu należy zaimplementować system plików FAT-32.

Założenia

Współpraca z firmą ADESCOM Polska Sp. z o.o. wpłynęła na specyficzne podejście do

tworzonego oprogramowania. Konieczne stało się zastosowanie pewnych metod i narzędzi, aby

stworzone oprogramowanie było zgodne z oczekiwaniami firmy. Potrzebne stały się więc

metody inżynierii oprogramowania [1].

Pierwszym ważnym krokiem było sformułowanie i spisanie założeń. Założenia zostały

przedstawione i pogrupowane poniżej:


6

1. Platforma sprzętowa:

W projekcie musi być zastosowany mikrokontroler PowerPC 405GP,

Wykorzystane zostaną dyski twarde z równoległym interfejsem ATA (ang. Parallel ATA),

Jak największa część oprogramowania powinna być napisana w języku C, niezbędne

fragmenty w asemblerze,

Mikrokontroler będzie podłączony do elektroniki dysku poprzez port EBC (ang. External Bus

Controller), ewentualnie za pośrednictwem układu PLD (ang. Programmable Logic Device).

2. Sterownik:

Budowa sterownika powinna oddzielać część zależną i niezależną od sprzętu,

Musi być opracowane i dobrze udokumentowane API sterownika,

Sterownik dysku ma być zgodny ze specyfikacją ATA/ATAPI-7,

Sterownik musi udostępniać następujące tryby transmisji danych: PIO, DMA, UDMA.

3. Testy:

Należy zaprojektować, zaimplementować i wykonać testy sprawdzające:

szybkość transferu danych w poszczególnych trybach pracy sterownika,

obciążenie procesora podczas transferu danych w poszczególnych trybach pracy sterownika.

4. System plików:

Musi zostać zaimplementowany system plików FAT-32 w celu przeprowadzenia testów

poprawności działania sterownika i użyteczności API sterownika,

Powinno być zaimplementowane minimum funkcjonalności systemu plików, potrzebne

do przeprowadzenia opisanych powyżej testów.

5. Powłoka:

Należy stworzyć powłokę (ang. Shell), która umożliwi wydawanie poleceń i otrzymywanie

informacji zwrotnych (np. wyniki testów, parametry, aktualny stan oprogramowania i urządzeń).

6. Inne:

Komentarze w kodzie źródłowym powinny być napisane w języku angielskim,

Wykonawca powinien informować klienta o postępach co najmniej raz na 2 tygodnie,

Ostateczny termin oddania projektu (skończone, przetestowane oprogramowanie

i napisana dokumentacja) to 30 sierpnia 2006 r.


7

2. Środowisko sprzętowe i programowe

Środowisko sprzętowe wykorzystywane do realizacji tematu pracy składa się

z następujących elementów:

System embedded z mikrokontrolerem PowerPC 405GP,

Dysk twardy z interfejsem równoległym PATA,

Debugger sprzętowy JTAG firmy Wind River,

Komputer typu PC, który wraz z debuggerem służył do pisania i uruchamiania

oprogramowania oraz do komunikacji z systemem embedded poprzez łącze szeregowe

i program terminalowy.

Konfiguracja środowiska sprzętowego została przedstawiona na Rys. 2.0.1.

Rys. 2.0.1 Konfiguracja środowiska sprzętowego.

Na środowisko programowe składa się następujące oprogramowanie:

Środowisko Cygwin,

Kompilator gcc-3.3.1, programy narzędziowe binutils-2.14,

Edytor tekstowy Notepad++,

Środowisko programistyczne dla PowerPC – SingleStep.7.5,

Program terminalowy HyperTerminal wykorzystywany do komunikacji z systemem

embedded, przy użyciu łącza szeregowego interfejsem RS-232.


8

2.1. Opis systemu embedded

Wykorzystany system embedded jest systemem komputerowym (ang. Single Board

Computer) opartym na 32-bitowym procesorze PowerPC 405GP. Posiada 16 MB pamięci

Synchronous DRAM oraz pamięć Flash służącą do zapisania na stałe wykorzystywanego

oprogramowania. Posiada także 40-pinowe złącze EIDE, do którego można podłączyć dysk

twardy z interfejsem Parallel ATA. Wyprowadzono w nim również złącze interfejsu debuggera

JTAG oraz złącze interfejsu RS-232. Informacje o stanie systemu sygnalizują diody LED.

Opisany system embedded powstał na bazie wcześniejszego projektu firmy ADESCOM

Polska Sp. z o.o. o nazwie AMON. Główna modyfikacja polegała na umożliwieniu podłączenia

do systemu dysku twardego – a więc dodaniu złącza EIDE, buforów oraz kilku innych układów.

Po zaprojektowaniu i wykonaniu systemu, został on przetestowany poprzez uruchomienie na nim

systemu Embedded Linux. W szczególności przetestowana została część odpowiedzialna za

podłączenie dysku twardego. Testowanie polegało na podłączeniu dysku twardego i sprawdzeniu

poprawności jego obsługi w trybie PIO, wykorzystując istniejące sterowniki linuxowe. Testy

przeszły pomyślnie.

Schemat blokowy systemu embedded jest przedstawiony na rysunku Rys. 2.1.1.

Rys. 2.1.1 Schemat blokowy systemu embedded [25].

PowerPC

405GP

SDRAM (16 MB)

Układ

PLD

Złącze

EIDE

EBC

GPIO

DMA

RS-232

JTAG

Bufory

Diody LED

UART

JTAG


9

2.2. Schematy układów systemu embedded

Na schematach zostały umieszczone tylko elementy istotne z punktu widzenia tematu

pracy. Bloki funkcjonalne oraz ważniejsze sygnały zostały zaznaczone kolorami zgodnymi

ze schematem blokowym z poprzedniego rozdziału.

Rys. 2.2.1 Schemat układu z mikrokontrolerem PowerPC 405GP [25].

Na schemacie (Rys. 2.2.1) znajduje się zaznaczony na niebiesko mikrokontroler PowerPC

405GP (A3001E) wraz z częścią istotnych wyprowadzeń. Kolorem filetowym zaznaczony jest

schemat zegara systemowego z oscylatorem kwarcowym (U3012) 33.3 MHz. Kolorem


10

brązowym zaznaczone jest złącze JTAG (A3002). Diody LED (D3000-D3003) wykorzystywane

do sygnalizacji stanu systemu embedded oznaczono kolorem żółtym. Sterowane są one układem

GPIO. Kolorem zielonym zaznaczone są ważniejsze sygnały:

sygnał zegarowy PerClk (Per_clk), z którym jest synchronizowane próbkowanie danych

przy transferach danych z lub do dysku,

sygnał IDE_INT, sygnalizujący żądanie obsługi przerwania związanego z dyskiem twardym.

Rys. 2.2.2 Schemat podłączenia pamięci SDRAM do mikrokontrolera PowerPC 405GP [25].


11

Na schemacie (Rys. 2.2.2) znajduje się zaznaczony na niebiesko mikrokontroler PowerPC

405GP (A3001B) wraz z częścią wyprowadzeń potrzebnych do podłączenia pamięci SDRAM.

Kolejne dwa układy (U3008, U3019), zaznaczone kolorem pomarańczowym, to pamięć

Synchronous DRAM w konfiguracji: 2 układy x 1M x 16-Bit x 4 Banki (czyli 2 x 64Mbit).

Rys. 2.2.3 Schemat przedstawiający układ wyprowadzeń złącza EIDE oraz buforów [25].


12

Na schemacie (Rys. 2.2.3) znajduje się zaznaczone na jasno-zielony kolor 40-pnowe złącze

EIDE (CON3001). Ciemno-zielonym kolorem zaznaczone są dwa 16-bitowe, dwukierunkowe

bufory trójstanowe (U3015, U3016) mające na celu zwiększenie obciążalności poszczególnych

sygnałów.

Układ U3015 buforuje sygnały adresowe oraz sterujące. Kierunek przepływu danych jest

ustawiony na stałe (1DIR oraz 2DIR podłączone do GND) od portu B do portu A.

Układ U3015 buforuje dwukierunkowe linie danych. Kierunek przepływu danych jest

sterowny poprzez sygnał IDE_DIR, natomiast sterowanie stanem bufora (uaktywniony lub

wprowadzony w stan wysokiej impedancji) odbywa się poprzez sygnał IDE_nOE.

Oba sygnały sterujące pracą bufora (IDE_DIR, IDE_nOE) są wypracowywane przez układ

PLD (U3018A) na podstawie równań w języku VHDL:

IDE_nOE <= ‘0’

IDE_DIR <= P_nOE or (IDE_nCS0 and IDE_nCS1)

Rys. 2.2.4 Schemat podłączenia układu programowalnego PLD [25].


13

2.3. Opis mikrokontrolera PowerPC 405GP

Wybór procesora miał związek nie tylko z samym sterownikiem dysku twardego, ale

również z bramą VoIP firmy ADESCOM Polska Sp. z o.o. której funkcjonalność ma być

rozszerzona o obsługę dysków twardych.

Założenia:

procesor ma być 32 bitowy, aby można było na nim uruchomić system operacyjny

Embedded Linux,

musi posiadać MMU (ang. Memory Management Unit) w celu ochrony pamięci,

musi posiadać bogaty zestaw peryferów (DMA, interfejs do pamięci SDRAM i Flash,

PCI, Ethernet),

powinien to być procesor tzw. mainstream (czyli typowy, w głównym nurcie przemysłu

elektronicznego) a wynika z tego:

dostępność narzędzi (oprogramowania),

dobre przetestowanie procesora,

niska cena,

łatwa przenośność oprogramowania na inne procesory.

Biorąc pod uwagę powyższe założenia oraz doświadczenie zespołu programistów firmy

ADESCOM Polska Sp. z o.o. w tworzeniu oprogramowania dla procesora PowerPC, wybrany

został procesor PowerPC 405GP firmy AMCC.

Opis procesora:

PowerPC 405GP to 32-bitowy procesor embedded typu RISC (ang. Reduced Instruction Set

Computer). Maksymalna częstotliwość pracy wykorzystywanego egzemplarza wynosi 200 MHz.

Jest procesorem typu big endian, chociaż posiada wsparcie dla operacji little endian (formaty

zapisu danych różniące się kolejnością bajtów).

PowerPC 405GP posiada dużą liczbę zintegrowanych peryferiów, między innymi:

układ wejść/wyjść GPIO (ang. General Purpose Input/Output),

dwa porty szeregowe UART,

układ kontrolera pamięci SDRAM,

interfejs magistrali zewnętrznej EBC (ang. External Bus Controller),

układ kontrolera DMA [22].


14

Najważniejsze bloki funkcjonalne architektury mikrokontrolera PowerPC 405GP, z punktu

widzenia tematu pracy, przedstawia rysunek Rys. 2.3.1.

Rys. 2.3.1 Schemat blokowy PowerPC 405GP [22].

Układ taktowania:

Ustawienia taktowania wewnętrznych i zewnętrznych magistral w PowerPC 405GP jest

w dużym stopniu konfigurowalne. Konfiguracja polega na dobraniu odpowiedniej częstotliwości

SysClk wynikającej z zastosowanego rezonatora kwarcowego, ustawieniu odpowiednich

rejestrów w celu dobrania częstotliwości pracy procesora (CPU Clock). Następnie po ustawieniu

odpowiednich rejestrów (dzielniki częstotliwości) wyznacza się częstotliwość taktowania

pamięci SDRAM (MemClkOut), magistrali OPB, układów UART oraz najważniejszego

parametru z punktu widzenia obsługi kontrolera dysku twardego – zegara PerClk, który

bezpośrednio wpływa na szybkość transferu danych pomiędzy elektroniką dysku, a systemem

embedded.


15

Rysunek Rys. 2.3.2 przedstawia możliwości konfiguracji taktowania poszczególnych

podukładów mikrokontrolera PowerPC 405GP.

Rys. 2.3.2 Konfiguracja taktowania magistral i podukładów mikrokontrolera

PowerPC 405GP [22].

Odpowiednie ustawienie taktowania poszczególnych magistral miało bardzo istotne

znaczenie przy:

optymalizacji szybkości transferu danych pomiędzy dyskiem twardym i systemem

embedded,

dopasowaniu zmian i czasu trwania odpowiednich sygnałów związanych z EBC, DMA

do specyfikacji ATA/ATAPI-7,

ustawianiu timerów i rejestrów konfiguracyjnych UART.


16

Układ wejść/wyjść (GPIO):

Układ kontrolera GPIO zlokalizowany na magistrali OPB (ang. On-chip Peripheral Bus)

umożliwia kontrolę maksymalnie 23 wejść/wyjść. Każdy z modułów wejścia/wyjścia jest

multipleksowany z innymi sygnałami aby zmniejszyć ilość wyprowadzeń procesora [22].

W systemie embedded poprzez GPIO (sygnały GPIO6-GPIO9) kontrolowane są diody LED

sygnalizujące stan systemu. Inne wykorzystywane sygnały związane z kontrolerem GIPO to:

IRQ0 (GPIO17) (ang. Interrupt Request) używany do zgłaszania żądania obsługi

przerwania przez dysk twardy,

PerCS6, PerCS7 (GPIO15, GPIO16) używane jako sygnały sterujące, które wybierają

odpowiednią grupę rejestrów kontrolera dysku twardego (wybór grupy rejestrów

Command Block Register lub Control Block Register)

Układ wejść/wyjść szeregowych (UART):

PowerPC 405GP posiada dwa układy UART (wykorzystano tylko jeden). Pomimo

zaawansowanych cech kontrolera UART (jak np. 16-bajtowy bufor nadawczy i odbiorczy FIFO)

do celów tematu pracy wystarczyła podstawowa jego konfiguracja [22].

W systemie embedded UART wykorzystany był do komunikacji pomiędzy systemem,

a komputerem typu PC, który poprzez klawiaturę, monitor i program terminalowy pośredniczył

w komunikacji pomiędzy użytkownikiem, a systemem embedded.

Układ kontrolera pamięci SDRAM:

Układ kontrolera pamięci SDRAM zapewnia 32-bitowy interfejs do pamięci SDRAM, z

opcjonalnym ECC (ang. Error Checking and Correction). Zapewnia elastyczne, w pełni

programowalne dopasowanie ustawień czasowych dla różnorodnych pamięci SDRAM [22].

Podstawowa konfiguracja banków pamięci zapisana w pliku konfiguracji rejestrów

(dostarczonym wraz z oprogramowaniem SingleStep 7.7.5) jest wgrywana każdorazowo wraz

z oprogramowaniem, działała poprawnie i wydajnie. Nie było potrzeby ręcznej konfiguracji

banków pamięci, konfiguracja została jednakże sprawdzona pod względem wydajności na etapie

optymalizacji transferów DMA.


17

Układ kontrolera przerwań:

PowerPC 405GP zawiera uniwersalny kontroler przerwań UIC (ang. Universal Interrupt

Controller), który zapewnia kontrolę, informacje statusowe oraz komunikację pomiędzy

poszczególnymi wewnętrznymi i zewnętrznymi źródłami przerwań i rdzeniem procesora [22].

Ważna okazała się możliwość konfiguracji wyzwalania przerwania poprzez odpowiednią

polaryzację sygnału przerwania oraz ustawienie czułości na zbocze lub poziom. Dzięki temu

bezproblemowa była konfiguracja przerwania zewnętrznego (External IRQ0) pochodzącego od

elektroniki dysku twardego.

Inne wykorzystane i obsłużone źródła przerwań to przerwania od układów: UART, DMA,

PIT (ang. Programmable Interval Timer) oraz szereg przerwań programowych (ang. Traps),

które obsługują sytuacje błędne, np. odwołanie do nieistniejącej komórki pamięci.

Układ kontrolera magistrali zewnętrznej (EBC):

Układ kontrolera magistrali zewnętrznej umożliwia bezpośrednie podłączenie pamięci

SRAM, Flash oraz innych urządzeń peryferyjnych, np. kontrolera dysku twardego. W celu

wyeliminowania potrzeby stosowania dodatkowych układów dekodujących adresy, EBC

zapewnia osiem programowalnych sygnałów Chip Select, które pozwalają zamapować

podłączane pamięci lub urządzenia w przestrzeni adresowej procesora PowerPC 405GP.

Zależności czasowe sygnałów Chip Select, magistrali danych oraz sygnałów sterujących są

programowalne. Umożliwia to dostosowanie zależności i ograniczeń czasowych poszczególnych

sygnałów, związanych z podłączeniem dysku twardego, do specyfikacji ATA/ATAPI-7.

Dostosowanie szerokości magistrali danych (16-bitów w przypadku dysku twardego) do różnych

urządzeń odbywa się poprzez ustawienie dedykowanych rejestrów. Po odpowiedniej konfiguracji

pamięci i urządzeń w rejestrach interfejsu EBC komunikacja z nimi znacznie się upraszcza –

wystarczy odczytać lub zapisać komórkę pamięci pod którą zamapowana jest pamięć lub

urządzenie. Wszystkie sygnały związane z transferem danych są generowane automatycznie

(Rys. 2.3.4), zgodnie z konfiguracją danego banku kontrolera EBC.


18

Rys. 2.3.3 Sygnały interfejsu EBC oraz sposób podłączenia urządzeń [22].

Rys. 2.3.4 Pojedynczy odczyt (po lewej) i zapis (po prawej) [22].


19

Układ kontrolera DMA:

Układ kontrolera DMA umożliwia autonomiczne transfery danych (bez interwencji

procesora) pomiędzy pamięcią i urządzeniami oraz z pamięci do pamięci. W PowerPC 405GP

kontroler dostarcza 4 kanały DMA, każdy z nich posiada niezależny zbiór rejestrów

konfiguracyjnych takich jak: rejestr kontrolny, adresu źródłowego, adresu docelowego, licznika

oraz rejestr konfiguracji trybu scatter/gather (tryb umożliwiający automatyczne wgrywanie

rejestrów konfiguracyjnych danego kanału z pamięci – bez konieczności ręcznego ich programowania).

Ponieważ kontroler DMA działa w trybie master na obu magistralach PLB oraz OPB –

może czytać i zapisywać dane spod każdego adresu dostępnego przez PowerPC 405GP. Dotyczy

to także zamapowanych w pamięci urządzeń podłączonych do interfejsu EBC, np. podłączonego

do tego interfejsu dysku twardego [22].

Rys. 2.3.5 Sygnały DMA urządzenia podpiętego do interfejsu EBC [22].


20

Rys. 2.3.6 Transfer DMA z urządzenia do pamięci (po lewej) i z pamięci do urządzenia

(po prawej) [22].

Sposób generacji sygnałów związanych z transferem DMA nie jest idealnie dopasowany do

przebiegów opisanych w specyfikacji ATA/ATAPI-7, jednakże kontroler DMA posiada opcje

konfiguracyjne pozwalające na współpracę z kontrolerem dysku. Nie ma natomiast bezpośredniej

możliwości uruchomienia trybu UDMA, ponieważ w kontrolerze DMA procesora PowerPC

405GP dane są odczytywane i zapisywane tylko na jednym zboczu sygnału taktującego.


21

2.4. Charakterystyka dysku twardego

2.4.1. Budowa dysku twardego

W dysku twardym można wyróżnić następujące trzy główne bloki funkcjonalne:

Nośnik danych – zestaw talerzy zamocowanych na wspólnej osi, pokrytych specjalną

warstwą o właściwościach ferromagnetycznych,

Część mechaniczną realizującą dostęp do nośnika – głowica umieszczona na

specjalnym ramieniu oraz układ pozycjonujący,

Kontroler dysku (zintegrowana elektronika) – sterujący pracą całego urządzenia

i komunikujący się z otoczeniem [4].

Rys. 2.4.1.1 Budowa dysku twardego

Dyski twarde pierwszej generacji posiadały, w obrębie obudowy, jedynie układy

elektroniczne, które ściśle współpracowały z elementami wykonawczymi sterowania części

ruchomych oraz wzmacniacze bezpośrednio związane z głowicami odczytująco-zapisującymi.


22

Sterowaniem tymi elementami oraz obróbką danych (między innymi pozycjonowanie głowic nad

określoną ścieżką, odszukanie metryki sektora, zdekodowanie sygnału, oddzielenie danych od

zegara, kontrola i korekcja danych, przesłanie bloku danych do pamięci) zajmował się

zewnętrzny kontroler dysku. Rozwiązanie to miało liczne wady: do nowego modelu dysku

twardego potrzebny był zwykle nowy kontroler, przesyłanie danych pomiędzy dyskiem

i kontrolerem zwiększało podatność na zakłócenia i ograniczało prędkość transmisji. Gwałtowny

spadek cen układów elektronicznych doprowadził do sytuacji, że opłacalne stało się wyposażanie

każdego dysku twardego we własny, ściśle do niego dopasowany kontroler [2]. Skróceniu uległa

droga sygnałów, co spowodowało spadek podatności na zakłócenia i zwiększyło możliwą do

uzyskania prędkość transmisji. Dzięki istnieniu zintegrowanego kontrolera i ścisłego standardu

jego obsługi sterowanie dyskiem twardym sprowadza się do wydawania odpowiednich poleceń

kontrolerowi dysku twardego, przesyłu/odbioru danych i oczekiwania na zakończenie komendy

lub komunikat o błędzie [4].

2.4.2. Standard ATA (interfejs równoległy)

ATA (ang. AT Attachment) jest nazwą interfejsu urządzeń pamięci masowych. Standard

ATA jest cały czas rozwijany przez komitet techniczny T13 [11] – najnowsza wersja standardu

to ATA/ATAPI-7.

Standard ATA definiuje interfejs składający się z pojedynczego układu sterującego (host

lub host adapter) oraz jednego lub dwóch urządzeń (w realizacji tematu pracy urządzeniem może

być tylko dysk twardy). Jedno urządzenie jest skonfigurowane jako Device 0 (Master), drugie

jako Device 1 (Slave) [13].

Rys. 2.4.2.1 Interfejs ATA

DEVICE 1 DEVICE 0 HOST


23

Zadaniem host adaptera w komputerach PC jest generacja sygnałów, które nie występują w

magistrali systemowej lub występują w postaci zanegowanej [4]. Ponieważ w przypadku

wykorzystywanego systemu embedded, dysk twardy jest podłączony do mikrokontrolera

PowerPC 405GP, rolę host-adaptera spełniają odpowiednie układy mikrokontrolera, bufory oraz

układ PLD.

Złącze fizyczne

Dostęp do kontrolera dysku 3.5 calowego odbywa się poprzez 40 żyłowy płaski przewód

połączeniowy (dla szybszych trybów UDMA wymagany jest przewód 80 żyłowy, gdzie każda

linia sygnałowa przedzielona jest sygnałem masy). Współcześnie posiada on 3 równouprawnione

wtyki: jeden do host-adaptera, drugi do urządzenia master, trzeci do opcjonalnego urządzania

slave [4].

Rys. 2.4.2.2 Układ wyprowadzeń złącza 40-pinowego [2], [4], [13]

GND

DD8

DD9

DD10

DD11

DD12

DD13

DD14

DD15

key

GND

GND

GND

SPSYNC

GND

~IOSC16

~PDIAG

DA2

~CS1

GND

~RESET

DD7

DD6

DD5

DD4

DD3

DD2

DD1

DD0

GND

DMARQ

~DIOW

~DIOR

IORDY

~DMACK

INTRQ

DA1

DA0

~CS0

~DASP


24

Nr linii Nazwa sygnału Znaczenie

1 ~RESET Reset do stanu początkowego

2 GND Masa

3 DD7 Linia danych (dwukierunkowa), bit 7
















19 GND Masa

20 - Blokada wtyku

21 DMARQ Żądanie obsługi DMA

22 GND Masa

23 ~DIOW Zapis rejestru we/wyj

24 GND Masa

25 ~DIOR Odczyt rejestru we/wyj

26 GND Masa

27 IORDY Zakończono dostęp do rejestru we/wyj

28 SPSYNC(CSEL) Synchronizacja obrotów dysku

29 ~DMACK Potwierdzenie przydziału kanału DMA

30 GND Masa

31 INTRQ Żądanie obsługi przerwania

32 ~IOSC16 Możliwość dostępu do 16-bitowych rejestrów we/wyj

33 DA1 Linia adresowa, bit 1

34 ~BLID (~PDIAG) Rozpoznawanie typu kable (40 lub 80 żyłowy)



37 ~CS0 Wybór grupy rejestrów 0x1F0

38 ~CS1 Wybór grupy rejestrów 0x3F0

39 ~DASP Połączenie z napędem Slave

40 GND Masa

Tabela 2.4.2.3 Znaczenie sygnałów złącza 40-pinowego [2], [4], [13]


25

Komunikacja z kontrolerem

Komunikacja z kontrolerem odbywa się poprzez zestaw rejestrów CBR. Podzielone są

one na dwie grupy:

Podstawowa (ang. Command Block Registers), adres bazowy 0x1F0,

Dodatkowa (ang. Control Block Registers), adres bazowy 0x3F0.

Wybór danej grupy odbywa się poprzez sygnały ~CS0 (wybór grupy podstawowej) i

sygnał ~CS1 (wybór grupy dodatkowej). Adres rejestru to adres bazowy plus adres DA

(wynikający ze stanów linii adresowych DA0 – DA1). Kierunek transmisji (odczyt lub zapis)

ustawia się poprzez aktywację linii ~DIOR (odczyt) lub ~DIOW (zapis). Znaczenie rejestru może

być inne w zależności od kierunku operacji (odczyt lub zapis) [2].

~CS0

~CS1

DA2

DA1

DA0

Rejestry CBR

Adres1 Odczyt (~DIOR) Zapis (~DIOW)

0 1 0 0 0 Rejestr danych

(ang. Data Register)

Rejestr danych

(ang. Data Register) 0x1F0

0 1 0 0 1 Rejestr błędów

(ang. Error Register)

Rejestr właściwości

(ang. Features Register) 0x1F1

0 1 0 1 0 Rejestr liczby sektorów

(ang. Sector Count Register)

Rejestr liczby sektorów

(ang. Sector Count Register) 0x1F2

0 1 0 1 1 Adres LBA (bity 0-7)

(ang. LBA Low)

Adres LBA (bity 0-7)

(ang. LBA Low) 0x1F3

0 1 1 0 0 Adres LBA (bity 8-15)

(ang. LBA Mid)


(ang. LBA Mid) 0x1F4

0 1 1 0 1 Adres LBA (bity 16-23)

(ang. LBA High)


(ang. LBA High) 0x1F5

0 1 1 1 0

Rejestr napęd/adres LBA

(bity 24-27)

(ang. Device Register)

Rejestr napęd/adres LBA

(bity 24-27)


0x1F6

0 1 1 1 1 Rejestr stanu

(ang. Status Register)

Rejestr poleceń

(ang. Command Register) 0x1F7

1 0 1 1 0 Alternatywny rejestr stanu

(ang. Alternate Status Register)

Rejestr sterujący urządzenia

(ang. Device Control Register) 0x3F6

1 0 1 1 1 Aktualnie Nieużywany Nieużywany 0x3F7

1 1 X X X Magistrala w stanie wysokiej

impedancji Nieużywany Nie

dotyczy

1 0 0 X X

1 0 1 0 X

0 0 X X X Stan zabroniony

Rys. 2.4.2.4 Rejestry CBR standardu ATA [4], [12]

1 adresacja stosowana w komputerach PC, gdzie np. 0x1F0 oznacza rejestr nr 0 (rejestr danych) z grupy

podstawowej (adres bazowy 0x1F0)


26

Nazwa rejestru Opis

Rejestr danych

(ang. Data Register)

Rejestr danych jest dwukierunkowym portem danych o szerokości 16 bitów.

Umożliwia wymianę danych z kontrolerem dysku twardego (odczytuje się z niego

sekwencje bajtów podczas np. operacji czytania sektora i zapisuje dane, które

chcemy umieścić na nośniku podczas operacji zapisu sektora). Dostęp do

tego rejestru jest możliwy, gdy bit nr 3 (DRQ) rejestru statusu jest jedynką.

Rejestr błędów

(ang. Error Register)

Rejestr tylko do odczytu. Zawiera informacje o stanie wykonania ostatniego

polecenia. Zawartość rejestru jest określona gdy bit nr 0 (ERR/CHK)

rejestru stanu jest jedynką.

Rejestr właściwości

(ang. Features Register)

Rejestr tylko do zapisu. Zawartość tego rejestru staje się parametrem

komendy, gdy rejestr rozkazów jest zapisywany.

Rejestr liczby sektorów

(ang. Sector Count Register)

Rejestr przechowuje liczbę sektorów, które będą objęte działaniem zadanej

operacji (odczyt, zapis, weryfikacja). W czasie wykonywania operacji

zawartość rejestru jest stale dekrementowana, dzięki czemu w rejestrze, przez

cały czas działania rozkazu, znajduje się liczba sektorów do przetworzenia.

Rejestr LBA Low Rejestr zawiera bity 0-7 adresu LBA (ang. Logical Block Addressing)

pierwszego sektora, którego dotyczy rozkaz.

Rejestr LBA Mid Rejestr zawiera bity 8-15 adresu LBA pierwszego sektora, którego dotyczy

rozkaz.

Rejestr LBA High Rejestr zawiera bity 16-23 adresu LBA pierwszego sektora, którego dotyczy

rozkaz.

Rejestr napędu


Rejestr umożliwia określenie, do którego z napędów (Device 0 lub Device 1)

adresowany jest bieżący rozkaz, zawiera bity 24-27 adresu LBA.

Rejestr stanu

(ang. Status Register)

Rejestr tylko do odczytu. Zawiera informacje o ostatnio wykonanym

rozkazie. Jego stan jest ustalany zaraz po wykonaniu rozkazu lub po

wystąpieniu błędu. Dopóki bit nr 7 (BSY) jest jedynką, wszystkie inne bity

rejestru zawierają nieokreślone dane. Odczyt rejestru stanu jest

równocześnie potwierdzeniem odebrania sygnału zgłoszenia przerwania

(powoduje dezaktywację żądania na linii INTRQ). Właściwości tej nie ma

alternatywny rejestr stanu.

Rejestr rozkazów

(ang. Command Register)

Rejestr tylko do zapisu. Wpisuje się do niego kod rozkazu, który jest

realizowany natychmiast po jego wpisaniu (wszelkie parametry rozkazu,

czyli inne rejestry należy zapisywać przed zapisaniem rejestru rozkazów).

Alternatywny rejestr stanu

(ang. Alternate Status Register)

Rejestr zawiera te same informacje, co rejestr stanu. Różnica polega na tym,

że jego odczyt nie potwierdza odbioru sygnału zgłoszenia przerwania.

Rejestr sterujący

(ang. Device Control Register)

Rejestr tylko do zapisu. Służy do ustalania zachowania się kontrolera (czy

wyzwalane są przerwania) oraz do wymuszenia programowego resetu kontrolera.

Tabela 2.4.2.5 Opis rejestrów kontrolera [2], [4], [12]


27

Cykl programowania kontrolera:

Obsługa dysku twardego polega na przekazywaniu kolejnych rozkazów kontrolerowi dysku

twardego oraz odpowiedniej reakcji w odpowiedzi na ich wykonanie. Pełna realizacja rozkazu

określana jest jako cykl rozkazowy, w którym wyróżnia się trzy fazy:

Przekazywanie parametrów i rozkazu

Polega na załadowaniu parametrów rozkazu do rejestrów pomocniczych kontrolera,

a następnie zapisaniu odpowiedniego polecenia (numer rozkazu) do rejestru rozkazów.

Kontroler rozpoczyna wykonywanie rozkazu tuż po zapisie rejestru rozkazów [4]. Rys. 2.4.2.7

przedstawia zależności czasowe sygnałów przy zapisie do rejestrów kontrolera dysku.

Przekazywanie danych

W tej fazie następuje wymiana danych pomiędzy kontrolerem dysku twardego,

a pamięcią systemu. Dane przekazywane są w jednym z trzech trybów: PIO, DMA lub

UDMA. Nie wszystkie rozkazy wymagają przekazywania danych – a więc nie każdy

rozkaz posiada tą fazę [4]. Rysunki 2.4.2.7, 2.4.2.9 i 2.4.2.11 przedstawiają zależności

czasowe sygnałów przy transferze danych w poszczególnych trybach.

Faza końcowa

W fazie końcowej kontroler informuje o zakończeniu wykonywania rozkazu zgłaszając

przerwanie. Jeśli przerwanie jest wyłączone można się o tym dowiedzieć odczytując

odpowiednie rejestry – stanu oraz błędów [4]. Rys 2.4.2.7 przedstawia zależności

czasowe sygnałów przy odczycie rejestrów kontrolera dysku.

Tryby transmisji:

PIO

Tryb PIO (ang. Programmed Input/Output) jest klasyczną metodą przesyłania danych

pomiędzy kontrolerem dysku twardego, a pamięcią systemu. Przesył danych polega na

odczycie lub zapisie portu danych (16-bitowy rejestr danych). Wyróżnić można pięć

trybów PIO, różniących się prędkością przesyłu danych [2]:

Tryb Maksymalny transfer [MB/s]

PIO-0 3,33

PIO-1 5,22

PIO-2 8,33

PIO-3 11,11

PIO-4 16,66

Tabela 2.4.2.6 Tryby transmisji PIO [2]


28

Parametry czasowe trybów PIO Mode 0 [ns] Mode 1 [ns] Mode 2 [ns] Mode 3 [ns] Mode 4 [ns]

t0 Cycle time (min) 600 383 330 180 120

t1 Address valid do DIOR-/DIOW (min) 70 50 30 30 25

t2 DIOR-/DIOW- pulse width 8-bit (min) 165 125 100 80 70

t2i DIOR-/DIOW- recovery time (min) - - - 70 25

t3 DIOW- data setup (min) 60 45 30 30 20

t4 DIOW- data hold (min) 30 20 15 10 10

t5 DIOR- data setup (min) 50 35 20 20 20

t6 DIOR- data hold (min) 5 5 5 5 5

t6Z DIOR- data tristate (max) 30 30 30 30 30

t9 DIOR-/DIOW- to address valid hold 20 15 10 10 10

Rys. 2.4.2.7 Zależności czasowe w trybie PIO oraz przy zapisie i odczycie rejestrów

kontrolera dysku2 [2], [4], [13]

DMA

W trybie DMA (ang. Direct Memory Access) transfer odbywa się bez bezpośredniej

kontroli procesora. Transferem steruje kontroler DMA. Przed uruchomieniem transferu

należy tylko skonfigurować kanał DMA, ustawiając odpowiednie parametry oraz

włączając kanał. Rozpoczęciem i przebiegiem transferu danych steruje kontroler DMA.

Wyróżnić można trzy tryby DMA (Multiword DMA), różniące się prędkością przesyłu

danych [2]:

2 Adres ADDR składa się z linii adresowych DA0 ÷ DA2 oraz sygnałów ~CS0, ~CS1


29


DMA-0 4,16

DMA-1 13,33

DMA-2 16,66

Tabela 2.4.2.8 Tryby transmisji DMA [2]

Parametry czasowe trybów DMA Mode 0 [ns] Mode 1 [ns] Mode 2 [ns]

t0 Cycle time (min) 480 150 120

tD DIOR-/DIOW- asserted pulse width (min) 215 80 70

tE DIOR- data access (max) 150 60 50

tF DIOR- data hold (min) 5 5 5

tG DIOR-/DIOW- data setup (min) 100 30 20

tH DIOW- data hold (min) 20 15 10

tI DMACK to DIOR-/DIOW- setup (min) 0 0 0

tJ DIOR-/DIOW- to DMACK hold (min) 20 5 5

tKR DIOR- negated pulse width (min) 50 50 25

tKW DIOW- negated pulse width (min) 215 50 25

tLR DIOR- to DMARQ delay (max) 120 40 35

tLW DIOW- to DMARQ delay (max) 40 40 35

tM CS(1:0) valid to DIOR-/DIOW- (min) 50 30 25

tN CS(1:0) hold (min) 15 10 10

tZ DMACK- to read data released (max) 20 25 25

Rys. 2.4.2.9 Zależności czasowe w trybie DMA [13]


30

UDMA

Tryb Ultra DMA uzyskano poprzez zmiany w protokole DMA, polegające na

wykorzystaniu obydwu zboczy sygnału taktującego do wyzwalania przesyłu słowa

danych. Dzięki temu udało się dwukrotnie zwiększyć prędkość transmisji danych

w stosunku do trybu DMA o tej samej częstotliwości sygnałów. Wprowadzono również

mechanizm kontroli spójności transmitowanych danych oparty o kody CRC.

Zmniejszona została także podatność na przekłamania wywoływane odbiciami

sygnałów na skutek niedopasowania impedancji.


UDMA-0 16,66

UDMA-1 25,00

UDMA-2 (UDMA/33) 33,33

UDMA-3 (UDMA/44) 44,44

UDMA-4 (UDMA/66) 66,64

UDMA-5,6 (UDMA/100) 99,96

UDMA-7 (UDMA/133) 133,28

Tabela 2.4.2.10 Tryby transmisji UDMA [2]

Rys. 2.4.2.11 Zależności czasowe w trybie UDMA [13]


31

Rys. 2.4.2.11 (cd.) Zależności czasowe w trybie UDMA [13].

Różnice w kolejnych wersjach standardu ATA:

Pierwszy z serii standardów ATA został wprowadzony w 1981 roku i stanowił

z historycznego punktu widzenia pozycję wyjściową do dalszych rozszerzeń. Transmisja danych

odbywała się w trybie PIO-0 lub PIO-1, ale maksymalna prędkość transmisji nie przekraczała

4 MB/s. W standardzie ATA-2, który został wprowadzony w 1994 roku dodano kolejne tryby

PIO-3 i PIO-4 wraz ze sprzętowym mechanizmem regulującym prędkość przekazu (sygnał

IORDY). Wprowadzono również tryby DMA-0 ÷ DMA-2. Maksymalna prędkość transmisji

doszła w ten sposób do poziomu 16.66 MB/s. Poprawki w wersji standardu ATA-3 (z 1996 roku)

ograniczyły się do implementacji trybu gwarantującego pewną formę zabezpieczenia dostępu do

danych (ang. Secure Mode) oraz systemu nadzoru i autodiagnostyki S.M.A.R.T. (ang. Self


32

Monitoring Analysis and Reporting Technology). Standard ATA/ATAPI-4 wprowadzono w 1997

roku. Pojawił się w nim tryb Ultra DMA, z maksymalną prędkością transmisji 33.33 MB/s oraz

wprowadzono obsługę urządzeń innych niż dyski twarde (np. CD-ROM). Dla potrzeb tych

urządzeń powstał nowy logiczny interfejs określany mianem ATAPI (ang. AT Attachment Packet

Interface). Standard ATA/ATAPI-5 wprowadza możliwość transferu z prędkością około 100 MB/s

natomiast ATA/ATAPI-6 wprowadza technologię AAM (ang. Automatic Acoustic Management)

oraz model 48-bitowego adresowania LBA (ang. Logical Block Addressing). Używana we

wcześniejszych wersjach standardu adresacja CHS (ang. Cylinder Head Sector) została uznana

za przestarzałą, od tej pory zaleca się stosowanie adresacji LBA. Standard ATA/ATPI-7 jest

wysoce kompatybilny z ATA/ATAPI-6 (jeśli chodzi o interfejs równoległy). Wprowadzono

w nim tryb UDMA o prędkości transmisji 133.28 MB/s, dokonano kilku drobnych zmian

w rozkazach, ale główną zmianą było wprowadzenie interfejsu Serial ATA.

Kolejne wydania standardu ATA/ATAPI są ze sobą kompatybilne. Oznacza to, poprawną

pracę starych dysków twardych ze sterownikiem zgodnym z ATA/ATAPI-7, jak również pracę

nowych urządzeń ze starszymi sterownikami (oczywiście w takim przypadku urządzenie nie

będzie wykorzystywało w pełni swoich możliwości)


33

2.5. Narzędzia projektowe i testowo-uruchomieniowe

Wykorzystanie środowiska programistycznego SingleStep 7.7.5, które dostępne było tylko

dla systemów z rodziny Microsoft Windows, przesądziło o pracy pod tym systemem

operacyjnym. Wygoda korzystania z powłoki bash systemu Linux oraz innych programów

standardowo dostarczanych z Linuxem skłoniły mnie do zainstalowania Cygwina, który może

pod pewnymi względami zrekompensować brak systemu Linux. Pod Cygwinem został

skonfigurowany i skompilowany jako kompilator skrośny (ang. Cross Compiler) kompilator

GCC w wersji 3.3.1.

Opis używanych narzędzi:

Środowisko Cygwin:

Cygwin jest Linuxo-podobnym środowiskiem przeznaczonym dla systemu operacyjnego

Microsoft Windows. Składa się z biblioteki cygwin1.dll, która zachowuje się jak warstwa

emulująca API Linuxa (zapewniając pokaźną część funkcjonalności API Linuxa) oraz zbioru

narzędzi przeniesionych z Linuxa. [16]

Użycie Cygwina pozwoliło na wykorzystanie odpowiednio skonfigurowanego kompilatora

GCC (ang. GNU Compiler Collection) wraz z zestawem programów narzędziowych GNU

Binutils oraz na zautomatyzowanie procesu kompilacji dzięki zastosowaniu programu make oraz

innych narzędzi dostarczonych z oprogramowaniem Cygwin [15].

GCC 3.3.1

GNU Compiler Collection wspiera języki C, C++, Objective-C, Fortran, Java, i Ada oraz

zawiera biblioteki dla tych języków [17]. Jest kompilatorem przenośnym – można go uruchomić

na większości dostępnych dzisiaj platform. Produkuje kod wynikowy na wiele typów procesorów

– nie tylko dla procesorów używanych w komputerach osobistych, ale również dla

mikrokontrolerów (np. dla mikrokontrolera PowerPC 405GP). GCC jest nie tylko kompilatorem

natywnym (ang. Native Compiler), ale również kompilatorem skrośnym (ang. Cross Compiler),

który produkuje kod wynikowy na inny system niż ten na którym jest uruchomiony [10].

Kompilator GCC jest dobrze przetestowany i posiada solidne wsparcie w postaci ruchu

Open Source. Doświadczenie pracowników firmy ADESCOM Polska Sp. z o.o. związane z GCC

również przyczyniło się do wybrania tego kompilatora.


34

SingleStep 7.7.5

Oprogramowanie SingleStep 7.7.5 firmy Wind River jest przeznaczone dla procesorów

PowerPC. Łączy w sobie debugger programowy oraz narzędzie wspierające debuggowanie

sprzętowe. W pełnej integruje się z debuggerem sprzętowym takim jak używany przeze mnie

visionPROBE II. Wspiera projektantów oprogramowania w początkowej fazie pracy z systemem

embedded dzięki możliwości inicjalizowania rejestrów oraz konfiguracji pamięci. [21].

SingleStep zapewnia wygodny sposób debuggowania, oferując wielookienkowy interfejs do

podglądu i modyfikacji źródła programu, pamięci, rejestrów i zmiennych. Pewnym minusem SingleStep

jest brak wersji dla systemu operacyjnego Linux (jest dostępny na systemy MS Windows oraz Solaris).

VisionPROBE II

VisionPROBE II jest sprzętowym narzędziem umożliwiającym debuggowanie poprzez

komunikację z warstwą sprzętową interfejsu JTAG (ang. Joint Test Action Group) wbudowaną

w mikrokontroler. VisionPROBE II zapewnia szybkie połączenie równoległe pomiędzy aplikacją

wspierającą proces debuggowania (np. oprogramowaniem SingleStep), a docelowym

mikrokontrolerem. Umożliwia kontrolę wykonania programu: uruchamianie i zatrzymywanie,

ustawianie sprzętowych i programowych punktów wstrzymania (ang. Breakpoint), wykonanie resetu

systemu, wykonywanie pojedynczych instrukcji, wywoływanie funkcji oraz wychodzenie z funkcji [20].

Notepad++

Notepad++ jest rozbudowanym edytorem tekstowym dla systemu MS Windows,

rozpowszechnianym na licencji GNU GPL. Obsługiwane języki programowania to: C, C++,

Java, C#, XML, HTML, PHP, JavaScript, VHDL, makefile i wiele innych. Program koloruje

składnie, podświetla pary nawiasów, obsługuje autouzupełnianie, wyszukiwanie i zamianę za

pomocą wyrażeń regularnych, edycję z podziałem ekranu, zakładki. Funkcjonalność edytora

można powiększać za pomocą makr oraz wtyczek (np. przydatną wtyczką jest okienko z listą

funkcji znajdujących się w danym pliku źródłowym) [15], [26].

HyperTerminal

HyperTerminal firmy Microsoft jest programem narzędziowym używanym do łączenia się

z innymi komputerami, które pracują pod kontrolą odmiennych systemów operacyjnych.

Program był wykorzystywany do komunikacji z systemem embedded poprzez komputer typu

PC, wykorzystując bezpośrednie połączenie kablowe poprzez interfejs RS-232 [15].


35

3. Projektowanie i implementacja oprogramowania

3.1. Model procesu tworzenia oprogramowania

Do procesu tworzenia oprogramowania zastosowany został model kaskadowy. W tym

modelu podstawowe czynności specyfikowania, tworzenia, zatwierdzania i ewolucji są

odrębnymi fazami procesu takimi jak specyfikowanie wymagań, projektowanie

oprogramowania, implementacja i testowanie [1].

Rys. 3.1.1 Model kaskadowy (cykl życia oprogramowania) [1].

Wady modelu kaskadowego:

Nieelastyczny podział na rozłączne etapy,

Zobowiązania muszą być podejmowane w bardzo wczesnej fazie procesu,

Trudności z reagowaniem na zmieniające się wymagania klienta.

Definiowanie wymagań

Projektowanie systemu

i oprogramowania

Implementacja

i testowanie jednostek

Integracja i testowanie

systemu

Działanie i pielęgnacja


36

Wynikiem każdej fazy powinien być co najmniej jeden dokument, który będzie podlegał

akceptacji klienta. W praktyce zostały stworzone następujące dokumenty:

Założenia projektu (dokumentacja wymagań użytkownika),

Architektura (schematy blokowe, modele systemu)

Analiza i specyfikacja wymagań systemowych (projekt testów, wstępna specyfikacja

API sterownika i systemu plików, podział komend specyfikacji ATA/ATAPI-7, które

zostaną/nie zostaną zaimplementowane)

Harmonogram (wstępna wersja)

Dokumentacja oprogramowania

Dokumenty z fazy implementacji i testowania nie były tworzone. Sprawdzenie i akceptacja

tych faz przez klienta odbyło się w formie prezentacji działania oprogramowania i konsultacji

wyjaśniającej klientowi działanie i implementację. Integracja oprogramowania z systemem

docelowym nie była częścią tej pracy. Pielęgnacja systemu polegała na usunięciu ewentualnych

błędów w oprogramowaniu (sterowniku dysku twardego) wykrytych w okresie 2 miesięcy od

daty ostatecznego oddania, potwierdzonego protokołem odbioru dzieła.

Model kaskadowy został wybrany z kilku powodów:

Klient jest z branży informatycznej, dlatego nietrudno znaleźć „wspólny język”,

Wymagania definiowane przez klienta są jasne i zrozumiałe,

Małe prawdopodobieństwo zmian wymagań,

Termin zakończenia projektu jest narzucony odgórnie,

Projekt wykonuje jedna osoba,

Projekt można względnie łatwo podzielić na fazy, odpowiadające modelowi

kaskadowemu.

Przy powyższych założeniach i faktach wady modelu kaskadowego stają się mało istotne.


37

3.2. Architektura tworzonego oprogramowania

Tworzone oprogramowanie można podzielić na kilka modułów, które w całości zostały

przeze mnie stworzone na potrzeby projektu . Poszczególne części zależą od siebie i można je

przedstawić w sposób hierarchiczny. Rys. 3.2.1 przedstawia architekturę systemu, na którą

składa się wykorzystywany sprzęt oraz tworzone w trakcie realizacji tematu pracy

oprogramowanie.

Rys. 3.2.1 Architektura systemu

Najniżej w hierarchii jest warstwa sprzętowa. Wykorzystywany system embedded,

a w szczególności zastosowany mikrokontroler PowerPC 405GP wpływa bezpośrednio na

implementację dwóch kolejnych warstw oprogramowania. Interfejs konfiguracji i obsługi

systemu embedded stanowi warstwę ściśle zależną od sprzętu. Konfiguruje i pozwala

wykorzystywać podstawowe układy mikrokontrolera. Zawiera funkcje, makra i definicje stałych

wykorzystywane przez warstwy znajdujące się wyżej w hierarchii, uniezależniając te warstwy od

wykorzystywanego sprzętu.

Kolejną warstwą, najważniejszą z punktu widzenia tematu pracy jest sterownik dysku

twardego. Podzielony jest na kilka modułów. Część sterownika zależna od sprzętu to przede

wszystkim konfiguracja kontrolera EBC oraz DMA, a także funkcje pozwalające na

komunikację z kontrolerem dysku twardego – które są wykorzystywane przez wyższą


38

warstwę. Granica pomiędzy częścią sterownika zależną od sprzętu, a warstwą interfejsu

konfiguracji i obsługi systemu embedded, jest dosyć „płynna”, jednak, ze względu na

ścisły związek ze sterownikiem, została umieszczona w warstwie sterownika. Następna

część sterownika jest niezależna od sprzętu, realizuje ona zasadniczą funkcjonalność

sterownika dysku twardego – protokoły wykonania poszczególnych rozkazów (przygotowanie

i przekazanie rozkazu, sterowanie transferem danych, kontrola poprawności wykonania).

Testy parametrów (szybkość transferu, obciążenie procesora przy transferach DMA) są po

części zależne od sprzętu – stąd ich specyficzne umiejscowienie w warstwie sterownika

(Rys. 3.2.1). Hierarchicznie najwyższą częścią warstwy sterownika jest API sterownika

(ang. Application Programming Interface). Jest to zbiór funkcji pozwalających

wykorzystać możliwości sterownika dysku twardego. Z API sterownika korzysta warstwa

systemu plików.

Warstwa systemu plików pozwala wykorzystać i przetestować napisany sterownik

w praktyce. Zaimplementowany został system plików FAT-32, ze względu na jego prostotę oraz

dobrą dokumentację. Napisany system plików nie jest kompletny (np. brak obsługi błędów),

zawiera tylko funkcjonalność niezbędną do przetestowania sterownika dysku twardego. Operacje

odczytu, zapisu i kopiowania plików pozwoliły na gruntowne przetestowanie poprawności

działania sterownika oraz użyteczności jego API.

Warstwa umożliwiająca komunikację z użytkownikiem to powłoka. Przyjmuje

polecenia od użytkownika, wywołuje odpowiednie funkcje i wyprowadza wyniki

wykonywanego rozkazu. Użytkownik komunikuje się z systemem embedded za

pośrednictwem komputera typu PC, z uruchomionym programem terminalowym. Dane

pomiędzy komputerem, a systemem embedded są przesyłane za pomocą łącza szeregowego

(interfejs RS-232).

Kolejne rozdziały dokładniej opisują poszczególne warstwy oprogramowania.


39

3.3. Interfejs konfiguracji i obsługi systemu embedded

Warstwa interfejsu konfiguracji i obsługi systemu embedded pozwala wykorzystywać

podstawowe układy mikrokontrolera. Zawiera funkcje, makra i definicje stałych

wykorzystywane przez warstwy znajdujące się wyżej w hierarchii, uniezależniając je od

wykorzystywanego sprzętu. Konfiguruje i pozwala wykorzystać podstawowe ustawienia

mikrokontrolera, kontroler przerwań, timery, obsługę diod LED oraz zapewnia komunikację ze

światem zewnętrznym poprzez obsługę kontrolera UART.

Plik nagłówkowy PPC405GP.H oraz plik PPC405GP.C są ściśle związane

z mikrokontrolerem PowerPC 405GP. Zawierają definicje pewnych stałych związanych

z procesorem (np. rozmiary zmiennych, adres wektora przerwań, adres stosu) oraz inne stałe

wykorzystywane w pozostałych modułach. Zdefiniowane są też funkcje i makra odpowiedzialne

za dostęp do poszczególnych grup rejestrów mikrokontrolera (zawierające odpowiednie

instrukcje asemblera) oraz ułatwiające dostęp do pamięci, a także związane z konwersją little/big

endian.

Plik INT.S zawiera dwie, napisane w asemblerze, funkcje obsługi przerwań pochodzących

od źródła zewnętrznego w stosunku do rdzenia procesora (ang. External interrupt) oraz

pochodzących od programowalnego timera PIT (ang. Programmable Interval Timer). Najpierw

zapamiętywane są w pamięci wszystkie zmieniane rejestry procesora, następnie wywoływana

jest funkcja związana z właściwą obsługą przerwania, a na koniec przywracane są poprzednie

wartości rejestrów.

Plik nagłówkowy INTERPT.H zawiera definicje związane z przerwaniami (np. adresy

poszczególnych przerwań – tablica przerwań), makra przypisujące poszczególne przerwania do

odpowiednich sekcji kodu (wykorzystywane przez linker do umieszczenia funkcji obsługi

przerwań w odpowiednich miejscach w pamięci) oraz makra związane z zachowywaniem

i przywracaniem rejestrów. Plik INTERPT.C zawiera konfigurację uniwersalnego kontrolera

przerwań UIC (ang. Univesal Interrupt Controller), funkcję włączającą i wyłączającą przerwania

oraz ciała funkcji obsługi przerwań.

Plik nagłówkowy TIME.H zawiera definicje związane z wewnętrznym timerem

mikrokontrolera PowerPC 405GP – adresy odpowiednich rejestrów i wyliczenia związane

z jednostką czasu. W pliku TIME.C znajdują się funkcje związane z czasem (opóźnienia,


40

konfiguracja, odczyt timera) oraz funkcje związane z badaniem przekroczenia czasu oczekiwania

na pewne zdarzenia (ang. Timeout).

Plik nagłówkowy LED.H oraz plik LED.C zawierają konfigurację kontrolera GPIO, który

między innymi steruje diodami LED oraz funkcje związane z obsługą diod LED informujących

o stanie systemu embedded.

Plik nagłówkowy UART.H zawiera definicje związane z konfiguracją oraz obsługą

kontrolera UART. W pliku UART.C znajdują się funkcje, które można podzielić na trzy grupy:

Konfiguracja kontrolera UART oraz podstawowe funkcje związane z odbieraniem

i wysyłaniem znaków i łańcuchów,

Odpowiednia konwersja oraz wysyłanie liczb i ciągów znaków w różnych formatach,

Funkcje związane z obsługą łańcuchów (ang. String).


41

3.4. Sterownik dysku twardego

3.4.1. Zaimplementowane rozkazy

Standard ATA/ATAPI-7 definiuje wiele rozkazów, duża ich część jest opcjonalna.

Zaimplementowane zostały tylko podstawowe rozkazy, zdefiniowane w standardzie

ATA/ATAPI-7 jako obligatoryjne. Rozkazy związane z zarządzaniem zasilaniem, trybami

bezpieczeństwa, technologią SMART i inne nie związane bezpośrednio z możliwością odczytu

i zapisu sektorów danych na dysku twardym nie zostały zaimplementowane.

Tabela 3.4.1.1 zawiera listę zaimplementowanych w sterowniku rozkazów, wraz z ich

krótkim opisem:

Nazwa rozkazu (HDD.H) Nazwa rozkazu (ATA/ATAPI-7)

Opis

CMD_EXECUTE_DEVICE_

DIAGNOSTIC

EXECUTE

DEVICE

DIAGNOSTIC

Wykonanie tego rozkazu powoduje wykonanie przez

urządzenia wewnętrznych testów diagnostycznych. Jeśli

oba urządzenia są obecne – oba wykonują rozkaz bez

względu na to, które urządzenie jest wybrane.

CMD_FLUSH_CACHE FLUSH CACHE

Ten rozkaz jest wywoływany w celu wyczyszczenia przez

urządzenie bufora zapisu. Jeśli w buforze są jakieś dane, są

one zapisywane na nośnik.

CMD_IDENTIFY_DEVICE IDENTIFY

DEVICE

Rozkaz IDENTIFY DEVICE umożliwia pobranie

informacji o parametrach urządzenia.

CMD_READ_DMA READ DMA Umożliwia odczyt danych używając protokołu transmisji

DMA.

CMD_READ_SECTORS READ

SECTOR(S)

Rozkaz odczytuje od 1 do 256 sektorów (ustawione w

rejestrze liczby sektorów).

CMD_READ_VERIFY_

SECTORS

READ VERIFY

SECTOR(S)

Rozkaz analogiczny do READ SECTOR(S), z tym

wyjątkiem, że urządzenie odczytuje dane z nośnika, ale nie

odbywa się transfer danych do hosta, bit DRQ nie jest

ustawiany na jedynkę.

CMD_SET_FEATURES SET

FEATURES

Ten rozkaz służy do ustawiania parametrów pracy

urządzenia.

CMD_WRITE_DMA WRITE DMA Umożliwia zapis danych używając protokołu transmisji

DMA.

CMD_WRITE_SECTORS WRITE

SECTOR(S)

Rozkaz zapisuje od 1 do 256 sektorów (ustawione w

rejestrze liczby sektorów).

CMD_READ_BUFFER READ BUFFER Rozkaz READ BUFFER umożliwia odczyt aktualnej

zawartości bufora sektorowego urządzenia.

CMD_WRITE_BUFFER WRITE

BUFFER

Ten rozkaz umożliwia zapis zawartości jednego sektora do

bufora sektorowego urządzenia.

Tabela 3.4.1.1 Lista zaimplementowanych rozkazów [12]


42

Oprócz komend podanych wyżej zaimplementowane zostały komendy związane z 48-

bitową adresacją LBA o niemal identycznej funkcjonalności do powyższych. Różnica polega na

możliwości zaadresowania większej liczby sektorów (dyski powyżej 128 GB) oraz możliwości

podania większej (niż 256) liczby sektorów, których dotyczy rozkaz.

Nazwa komendy związanej z adresacją 48-bitową różni się od jej odpowiednika 28-biotwego

przyrostkiem EXT.

Nazwa rozkazu (HDD.H) Nazwa rozkazu

(ATA/ATAPI-7) Opis

CMD_FLUSH_CACHE_EXT FLUSH CACHE EXT Patrz rozkaz CMD_FLUSH_CACHE

CMD_READ_DMA_EXT READ DMA EXT Patrz rozkaz CMD_READ_DMA

CMD_READ_SECTORS_EXT READ SECTOR(S) EXT Patrz rozkaz CMD_READ_SECTORS

CMD_READ_VERIFY_SECTORS_EXT READ VERIFY SECTOR(S)

EXT

Patrz rozkaz

CMD_READ_VERIFY_SECTORS

CMD_WRITE_DMA_EXT WRITE DMA EXT Patrz rozkaz CMD_WRITE_DMA

CMD_WRITE_SECTORS_EXT WRITE SECTOR(S) EXT Patrz rozkaz CMD_WRITE_SECTORS

3.4.2. Opis funkcji interfejsu sterownika (API)

API sterownika (ang. Application Programming Interface) jest specyfikacją funkcji, które

umożliwiają korzystanie ze sterownika dysku twardego, jednocześnie ukrywając szczegóły

implementacji. Warstwą, która korzysta z API sterownika jest system plików. Deklaracje

wszystkich funkcji API sterownika znajdują się w pliku nagłówkowym HDD.H.

Ponieważ sterownik nie wykrywa podłączonych urządzeń3, gdyż część dysków twardych

nie przestrzega ściśle tej części specyfikacji ATA/ATAPI-7, która umożliwiałaby jednoznaczną

identyfikację urządzenia – należy przed kompilacją zmodyfikować definicje informujące o

podłączonych urządzeniach. Definicje te znajdują się w pliku HDD.H:

#define DEVICE_0 XXX

#define DEVICE_1 XXX

gdzie XXX to:

DEV_HDD – gdy do danego interfejsu jest podłączone urządzenie będące dyskiem twardym,

DEV_NONE – gdy do danego interfejsu nie jest podłączone żadne urządzenie.

3 Taka detekcja jest możliwa do zaprogramowania, jednak na użytek realizacji tematu pracy (gdzie konfiguracja

podłączonych urządzeń się nie zmienia) wystarczyło zdefiniować konfigurację podłączonych urządzeń w kodzie

sterownika.


43

Lista funkcji wchodzących w skład API sterownika:

void hdd_driver_config(int pio_mode, int dma_mode, char lba_mode,

char blocking)

int hdd_soft_reset()

int hdd_devices_diagnostic()

int hdd_identify_device(char dev, char *buffer)

int hdd_set_features(char dev, short subcmd, long long param,

short feature)

int hdd_flush_cache(char dev)

int hdd_read_verify_sectors(char dev, unsigned long long lba, int

count)

int hdd_read_buffer(char dev, char *buffer)

int hdd_write_buffer(char dev, char *buffer)

int hdd_read_sectors(char dev, unsigned long long lba, int count,

char *buffer)

int hdd_write_sectors(char dev, unsigned long long lba, int

count, char *buffer)

Opis funkcji interfejsu sterownika:

Nazwa void hdd_driver_config(int pio_mode, int dma_mode, char

lba_mode, char blocking)

Opis Służy do konfiguracji sterownika dysku (wyzwalanie przerwań, tryb DMA, tryb

adresacji LBA, tryb blokujący lub nieblokujący). Dodatkowo funkcja resetuje

informacje o ostatnio wykonanej komendzie (pola struktury last_cmd).

Parametry

wejściowe

pio_mode: ustawiamy tryb PIO (PIO_POLLING lub PIO_INTERRUPT).

Pierwszy tryb sterownika nie wykorzystuje przerwań, drugi wykorzystuje,

dma_mode: ustawiamy tryb DMA (DMA_NONE lub DMA_MDMA).

Pierwsza wartość ustawia brak trybu DMA (wykorzystywany będzie tryb

PIO), natomiast druga wartość ustawia tryb Multiword DMA (wszędzie gdzie

to możliwe będzie wykorzystywany tryb DMA),

lba_mode: ustawiamy tryb adresacji LBA (LBA28 lub LBA48). Ustawienie

trybu LBA48 umożliwia obsługę dysków większych niż 128GB oraz

odczyt/zapis więcej niż 256 sektorów jednym rozkazem.

blocking: ustawienie trybu blokującego (BLOCKING) lub nieblokującego

(NONBLOCKING)

Wartości

zwracane

Brak


44

Nazwa int hdd_soft_reset()

Opis Wykonuje programowy reset podłączonych urządzeń (jeśli oba urządzenia są

obecne to resetowane jest zarówno urządzenia DEVICE_0 (MASTER), jak

i DEVICE_1 (SLAVE)). Jeśli tryb PIO ustawiony jest na PIO_POLLING, i nie

ma włączonego trybu DMA (tryb DMA ustawiony na DMA_NONE) to

wyłączane jest generowanie przerwań od urządzeń.

Parametry

wejściowe

Brak

Wartości

zwracane

OK: jeśli nie było błędu

FAILED: w przypadku błędnego zakończenia

Nazwa int hdd_devices_diagnostic()

Opis Urządzenia wykonują wewnętrzną diagnostykę. (jeśli oba urządzenia są obecne

to zarówno urządzenie DEVICE_0 (MASTER), jak i DEVICE_1 (SLAVE)

wykonują wewnętrzną diagnostykę).

Rozkaz CMD_EXECUTE_DEVICE_DIAGNOSTIC.

Parametry

wejściowe

Brak

Wartości

zwracane



Nazwa int hdd_identify_device(char dev, char *buffer)

Opis Wybrane urządzenie wykonuje rozkaz CMD_IDENTIFY_DEVICE (urządzenie

przesyła 512 bajtów informacji o sobie). Informacje są zapisane do miejsca

w pamięci wskazanego przez drugi parametr. Dodatkowo wypełniane są pola

struktury dev_info[dev] w celu zachowania pewnych istotnych informacji

o urządzeniu.

Rozkaz CMD_IDENTIFY_DEVICE

Parametry

wejściowe

dev: wybór urządzenia, które ma wykonać rozkaz (MASTER lub SLAVE)

*buffer: wskazuje miejsce w pamięci, gdzie zostaną zapisane dane

Wartości

zwracane




45

Nazwa int hdd_set_features(char dev, short subcmd, long long

param, short feature)

Opis Ustawia pewne cechy urządzenia takie jak: tryb transmisji (tryby PIO: PIO 0 ÷

PIO 4, tryby DMA: DMA 0 ÷ DMA 2), włączenie/wyłączenie pamięci podręcznej

zapisu (ang. Write Cache), włączenie/wyłącznie trybu look ahead itd.

Przykładowo poniższe wywołanie ustawia tryb transmisji Mulitword DMA w trybie 2:

hdd_set_features(MASTER, SET_TRANSFER_MODE, 0,

FEATURE_MULTIWORD_DMA_MODE | MODE_2)

Rozkaz CMD_SET_FEATURES

Parametry

wejściowe


subcmd: wybór podkomendy (SET_XXX), czyli cechy, którą chcemy

ustawić (jego wartość jest zapisywana w rejestrze właściwości)

param: parametr zależny od podkomendy (jego wartość jest zapisywana

w rejestrach lba)

feature: parametr (FEATURE_XXX) jest zależny od podkomendy (jego

wartość jest zapisywana w rejestrze liczby sektorów)

Wartości

zwracane



Nazwa int hdd_flush_cache(char dev)

Opis Wymusza zapis danych znajdujących się w pamięci podręcznej zapisu

(ang. Write Cache) na nośnik.

Rozkaz: CMD_FLUSH_CACHE oraz CMD_FLUSH_CACHE_EXT

Parametry

wejściowe


Wartości

zwracane



Nazwa int hdd_read_verify_sectors(char dev, unsigned long

long lba, int count)

Opis Odczytuje określoną ilość sektorów z wybranego urządzenia, bez wykonywania

transferu do systemu embedded.

Rozkazy: READ_VERIFY_SECTORS oraz READ_VERIFY_SECTORS_EXT

Parametry

wejściowe


lba: adres pierwszego sektora, który ma być odczytany

count: liczba sektorów, które mają być odczytane

Wartości

zwracane




46

Nazwa int hdd_read_buffer(char dev, char *buffer)

Opis Odczytuje zawartość bufora sektorowego (ang. Sector Buffer) kontrolera dysku.

Rozkaz CMD_READ_BUFFER

Parametry

wejściowe



Wartości

zwracane



Nazwa int hdd_write_buffer(char dev, char *buffer)

Opis Zapis zawartości jednego sektora do bufora sektorowego (ang. Sector Buffer)

kontrolera dysku.

Rozkaz CMD_WRITE_BUFFER

Parametry

wejściowe


*buffer: wskazuje miejsce w pamięci, gdzie znajdują się dane

Wartości

zwracane



Nazwa int hdd_read_sectors(char dev, unsigned long long lba,

int count, char *buffer)

Opis Odczytuje określoną ilość sektorów z wybranego urządzenia.

Rozkazy CMD_READ_SECTORS, CMD_READ_SECTORS_EXT, CMD_READ_DMA,

CMD_READ_DMA_EXT

Parametry

wejściowe





Wartości

zwracane



Nazwa int hdd_write_sectors(char dev, unsigned long long lba,

int count, char *buffer)

Opis Zapisuje określoną ilość sektorów do wybranego urządzenia.

Rozkazy CMD_WRITE_SECTORS, CMD_WRITE_SECTORS_EXT, CMD_WRITE_DMA,

CMD_WRITE _DMA_EXT

Parametry

wejściowe




*buffer: wskazuje miejsce w pamięci, gdzie znajdują się dane

Wartości

zwracane




47

3.4.3. Struktury danych

Kluczowe struktury danych wykorzystane w sterowniku dysku twardego przechowują

informacje o konfiguracji sterownika, o podłączonych urządzeniach oraz o rezultacie ostatnio

wykonanego rozkazu.

Strukturą odpowiedzialną za przechowywanie konfiguracji sterownika dysku twardego jest

hdd_driver typu THdd_driver:

struct THdd_driver

{

char *sector_buffer; // pointer to sector buffer

char pio_mode; // PIO mode (polling or interrupt)

char dma_mode; // DMA mode (no dma mode or multiword dma)

char lba_mode; // LBA mode (28-bit or 48-bit)

char blocking; // blocking or non blocking mode

int data_block; // size of transfer data block

char protocol; // command protocol

} hdd_driver; // hdd driver configuration

Jest ona wypełniana przez funkcję API hdd_driver_config(), która konfiguruje

sterownik. Struktura zawiera wskaźnik na bufor sektorowy, informacje o wykorzystywanym

trybie transmisji, używanym trybie adresacji, ustawieniu trybu blokującego lub nieblokującego,

wielkość przesyłanego w rozkazach bloku danych oraz o aktualnie wykonywanym protokole.

Wewnętrzny bufor, mogący przechować cały sektor danych, jest zdefiniowany następująco:

char hdd_sector_buffer[SECTOR_SIZE];

Struktura dev_info[2] typu TDevice_info przechowuje informacje związane

z obsługiwanym urządzeniem (dyskiem twardym):

// device info sturcture

struct TDevice_info

{

char type; // device type: DEV_HDD or DEV_NONE

short dma_mode; // DMA mode supported

short lba_mode; // LBA mode supported

short no_iordy_mode; // IORDY may be supported

short iordy_mode; // IORDY mode supported (flow control)

short ata; // ATA major version

short lba48; // LBA 48-bit address supported

short aam; // automatic acustic management

short multiword_dma; // multiword dma (modes supported and selected)


48

unsigned int num_addr_sect; // total number of addressable sectors

short max_sect_multiple; // max sector number in multiple mode

short pio; // info about PIO mode

short udma; // info about UDMA mode

short reset_result; // info about hdd reset result

} dev_info[2]; // important informations about device 0

// (MASTER) and device 1 (SLAVE) from

// identify device command

Informacje te pobierane są od kontrolera dysku twardego i zapisywane w strukturze przez

funkcję API hdd_identify_device() (rozkaz IDENTIFY DEVICE)

Ostatnią bardzo ważną strukturą danych jest last_cmd typu TLast_cmd. Zawiera

informacje o ostatnio wykonanym rozkazie: urządzenie, którego dotyczył rozkaz, zawartość

kluczowych rejestrów kontrolera, informacje o ewentualnym błędzie, przekroczeniu czasu

operacji, informacje o zakończeniu transferu danych:

struct TLast_cmd

{ char dev; // selected device: MASTER or SLAVE

short sect_count; // Sector Count Register

short lba_low; // LBA-Low Register

short lba_mid; // LBA-Mid Register

short lba_high; // LBA-High Register

short device; // Device Register

short error_reg; // Error Register

int error; // there was error: TRUE or FALSE

int timeout; // there was timeout: TRUE or FALSE

int eot; // end of transfer (DMA): TRUE or FALSE

} last_cmd; // informations about last executed command


49

3.4.4. Implementacja sterownika

Oprogramowanie sterownika dysku twardego można podzielić na część zależną

i niezależną od sprzętu.

Implementacja części zależnej od sprzętu:

Część zależna od sprzętu to przede wszystkim konfiguracja kontrolera EBC i DMA,

funkcje związane z ustawianiem transferu DMA oraz adresy i makra związane z odwołaniem do

rejestrów CBR kontrolera dysku twardego.

W pliku nagłówkowym EBC.H znajdują się definicje związane z ustawieniami kontrolera

EBC (adresy odpowiednich rejestrów oraz konfiguracje dla różnych trybów PIO). W pliku

EBC.C znajduje się funkcja odpowiedzialna za konfigurację banków kontrolera EBC. Dwa banki

wykorzystywane są do komunikacji z kontrolerem dysku twardego (jeden bank przeznaczony jest

na rejestry z grupy Commmand Block Registers, drugi na rejestry z grupy Control Block Registers).

W pliku nagłówkowym DMA.H znajdują się definicje związane z kontrolerem DMA

(adresy rejestrów, konfiguracje dla różnych trybów DMA). W pliku DMA.C znajdują się

funkcje odpowiedzialne za konfigurację kontrolera oraz funkcje ustawiające transfer danych

(w trybie DMA) pomiędzy dyskiem twardym i pamięcią.

Również w pliku nagłówkowym HDD.H można znaleźć definicje i makra zależne od

sprzętu. Adresy poszczególnych rejestrów kontrolera dysku twardego są ściśle związane

z interfejsem EBC mikrokontrolera PowerPC 405GP. Makra GET_HDD_REG

i SET_HDD_REG odpowiedzialne za pobieranie i zapisywanie zawartości rejestrów CBR mogą

również wymagać modyfikacji podczas przenoszenia sterownika na inną platformę sprzętową.

Implementacja części niezależnej od sprzętu:

Najwyżej w hierarchii funkcji związanych ze sterowaniem dyskiem twardym znajdują się

funkcje związane z API sterownika. Większość tych funkcji wiąże się z rozkazem lub pewną

grupą rozkazów kontrolera dysku twardego. Na podstawie konfiguracji sterownika wybierany jest

jeden z rozkazów i wywoływana jest funkcja związana z odpowiednim protokołem transmisji

danych. Tak jest np. z funkcją hdd_read_sectors(), która implementuje rozkazy: CMD_READ_SECTORS,

CMD_READ_SECTORS_EXT, CMD_READ_DMA i CMD_READ_DMA_EXT, wszystkie służące do

odczytania żądanej liczby sektorów z nośnika. To, który rozkaz jest wykonany, zależy od


50

aktualnej konfiguracji trybu transmisji oraz trybu adresacji (ta konfiguracja jest zapamiętana

w strukturze hdd_driver i ustawiana przy wywołaniu funkcji API hdd_driver_config()).

Funkcje wywoływane wewnątrz API są podzielone na grupy związane z trybem adresacji

(28-bitowa lub 48-bitowa) oraz odpowiednim protokołem opisanym w specyfikacji ATA/ATAPI-7:

Non-data command protocol – nie są przesyłane żadne dane pomiędzy systemem

embedded a kontrolerem dysku twardego. Funkcje:

hdd_cmd_non_data_lba28()

hdd_cmd_non_data_lba48()

PIO data-in command protocol – transfer danych w trybie PIO, dane przesyłane są

z kontrolera do systemu embedded. Funkcje:

hdd_cmd_pio_data_in_lba28()

hdd_cmd_pio_data_in_lba48()

PIO data-out command protocol – transfer danych w trybie PIO, dane przesyłane są

z systemu embedded do kontrolera dysku twardego. Funkcje:

hdd_cmd_pio_data_out_lba28()

hdd_cmd_pio_data_out_lba48()

DMA command protocol – transfer danych w trybie DMA. Funkcje:

hdd_cmd_dma_lba28()

hdd_cmd_dma_lba48()

Każda z powyższych funkcji wywołuje dwie inne. Pierwsza z nich hdd_cmd_lba28 lub

hdd_cmd_lba48 (w zależności od ustawionego trybu adresacji) służy do ustawienia

odpowiednich parametrów wykonywanego rozkazu (zapis odpowiednich rejestrów kontrolera)

oraz zlecenia wykonania danego rozkazu kontrolerowi (poprzez zapis numeru rozkazu do

rejestru rozkazów). Druga funkcja służy już do właściwej obsługi rozkazu zgodnie z protokołem

do którego należy. Nazwa tej drugiej funkcji jest taka jak w zestawieniach podziału na protokoły

powyżej, z pominięciem przyrostka 28 lub 48 – gdyż jest to część wspólna funkcjonalności

związanej z danym protokołem, niezależnie od trybu adresacji. Sam transfer danych odbywa się

w różnych miejscach programu, w zależności od trybu transmisji. Gdy jest to tryb PIO

z wyłączonymi przerwaniami (tryb PIO_POLLING) to transfer odbywa się w funkcji związanej

z danym protokołem. Jeśli jest to tryb PIO z włączonymi przerwaniami (tryb PIO_INTERRUPT)

to transfer odbywa się w funkcji obsługi przerwania. W przypadku trybu DMA wywoływana jest

funkcja ustawiająca kanał DMA, a transfer odbywa się poza procesorem.


51

3.5. Testy

W celu oszacowania pewnych parametrów związanych ze sterownikiem dysku twardego

i wykorzystywaną platformą sprzętową zaprojektowano dwa testy: test szybkości transferu

danych pomiędzy kontrolerem dysku twardego, a pamięcią systemu embedded (w trybie PIO

oraz DMA) oraz test obciążenia procesora podczas transferów DMA.

3.5.1. Testy szybkości komunikacji z kontrolerem dysku

Przeprowadzony test szybkości komunikacji z kontrolerem dysku twardego polega na

zmierzeniu prędkości przesyłu danych pomiędzy kontrolerem dysku twardego, a pamięcią

systemu embedded. Mierzony jest czas przesłania jednego sektora, czyli 512 bajtów. Do pomiaru

czasu jest wykorzystany wewnętrzny timer mikrokontrolera PowerPC 405 GP. Timer ten jest

inkrementowany z szybkością pracy procesora CPU_SPEED, czyli 133 MHz, oznacza to

inkrementacje timera co CPU_TIME ≈ 7.5 ns.

Ogólny wzór na prędkość transmisji danych pomiędzy kontrolerem dysku twardego,

a pamięcią systemu embedded jest następujący:

][bytes/secIMETRANSFER_T

SFEREDBYTES_TRAN V

Aby test został uaktywniony konieczne jest zdefiniowanie stałej HDD_TRANSFER_SPEED

(w pliku PPC405GP.H) przed kompilacją:

#define HDD_TRANSFER_SPEED

W zmiennej transfer_start zapamiętywany jest czas, tuż przed rozpoczęciem

transferu, a następnie w zmiennej transfer_end zapamiętywany jest czas, tuż po zakończeniu

transferu. Zapamiętanie czasu jest realizowane za pomocą jednej instrukcji asemblera, dzięki

czemu nie ma to większego wpływu na pomiar.

transfer_time = transfer_end – transfer_start przechowuje czas transferu

(jednostką jest CPU_TIME ≈ 7.5 ns). W tej postaci czas transferu jest wyświetlany po

zakończeniu przesyłania danych.


52

Prędkość transferu można wyliczyć korzystając ze zmierzonego czasu oraz ze wzoru:

[MB/s] 1000 ns CPU_TIME*imetransfer_t

bajtów 512 V

Tabela 3.5.1.1 przedstawia czas transferu dla poszczególnych trybów

Tryb PIO 1.35 ÷ 1.65 MB/s

Tryb DMA ≈11.8 MB/s

Tabela 3.5.1.1 Czas transferu dla trybów PIO i DMA

Uzyskana niska prędkość trybu PIO wynika z braku optymalizacji pętli w której

dokonywany jest transfer (odczyt lub zapis rejestru danych kontrolera). Wykonanie takiej

optymalizacji nie jest skomplikowane – należy zastąpić fragment w języku C odpowiednim

fragmentem kodu w asemblerze. Nie zostało to zrobione, gdyż nie było takiej potrzeby –

sterownik będzie cały czas pracował w trybie DMA, którego prędkość transmisji została

maksymalnie zoptymalizowana. Uzyskana prędkość transferu DMA na poziomie 12 MB/s jest

niższa niż maksymalna prędkość w trybie DMA-2 (16.66 MB/s) z powodu istnienia wąskiego

gardła w transmisji, jakim jest kontroler DMA procesora PowerPC 405GP.

3.5.2. Test obciążenia procesora podczas transferu DMA

Przeprowadzony test obciążenia procesora podczas transferu DMA polega na zmierzeniu

obciążenia procesora PowerPC 405 GP podczas wykonywania transferu danych pomiędzy

kontrolerem dysku twardego, a pamięcią systemu embedded (SDRAM) w trybie DMA. W celu

wyznaczenia szukanej wartości mierzony jest czas wykonania dwóch pętli. Pierwsza jest

wykonywana bez uaktywnionego transferu DMA, podczas wykonywania drugiej odbywa się

transfer DMA (odczytywanych jest 255 sektorów z dysku twardego). Ponieważ przy transferze

DMA procesor pracuje wolniej, druga pętla będzie się wykonywała dłużej. Porównanie

zmierzonych czasów pozwoli obliczyć obciążenie procesora:

[%] 100% DMA m transferez petli wykonaniaczas

DMA transferubez petli wykonaniaczas1 L


53

Aby test został uaktywniony konieczne jest zdefiniowanie stałej CPU_LOAD_TEST (w pliku

PPC405GP.H) przed kompilacją:

#define CPU_LOAD_TEST

Najpierw mierzony jest czas wykonania pętli for (wykonuje się 0x4000 razy) bez

aktywnego transferu DMA. Za pomocą wewnętrznego timera mikrokontrolera PowerPC 405GP

zapamiętywany jest w zmiennej loop_start czas tuż przed rozpoczęciem pętli, następnie

wykonywana jest pętla, a na końcu zapamiętywany jest w zmiennej loop_end czas tuż po

zakończeniu pętli.

asm volatile("mfspr %0, 0x10C" : "=r" (loop_start):);

for(loop_i=0; loop_i<0x4000; loop_i++)

;

asm volatile("mfspr %0, 0x10C" : "=r" (loop_end):);

loop_time = loop_end – loop_start daje czas wykonania pętli (jednostką jest

CPU_TIME ≈ 7.5 ns).

Następnie w analogiczny sposób mierzony jest czas wykonania drugiej pętli. Różnica

polega na zleceniu transferu DMA, a następnie odczekaniu pewnego dobranego doświadczalnie

czasu, aby transfer DMA zdążył się rozpocząć przed wykonaniem pętli z pomiarem:

// zlecamy odczyt 255 sektorów z dysku (transfer DMA)

hdd_read_sectors(MASTER, 0x837, 255, large_buffer);

// Czekamy,aby transfer zdążył się rozpocząć


;

// wykonujemy pomiary tak jak przy pierwszej pętli

asm volatile("mfspr %0, 0x10C" : "=r" (loop_start):);


;

asm volatile("mfspr %0, 0x10C" : "=r" (loop_end):);

Obliczone obciążenie procesora PowerPC 405GP podczas transferu DMA pomiędzy

kontrolerem dysku twardego, a pamięcią systemu embedded (SDRAM) kształtowało się na

poziomie:

L = 1.5 %.

Wynika z tego, że obciążenie procesora przy transferze DMA jest niewielkie. Dzięki temu

wykorzystanie sterownika dysku twardego w trybie DMA dla zastosowanej platformy sprzętowej

jest bardzo opłacalne – w czasie transferu danych pomiędzy kontrolerem dysku twardego,

a pamięcią systemu embedded procesor będzie mógł się zająć innymi zadaniami.


54

3.6. System plików

System plików FAT-32 został wybrany ze względu na jego prostotę oraz dobrą

dokumentację. Jest on odmianą systemu plików FAT (ang. File Allocation Table), opracowanego

na przełomie lat 70. i 80. na potrzeby systemu operacyjnego MS-DOS [4].

Ponieważ system plików nie był głównym celem niniejszej pracy – nie jest dokładnie

opisywany. Opis specyfikacji systemu plików FAT-32 można znaleźć w pracy [28], natomiast

opis implementacji, na której się wzorowałem znajduje się w pracy [4].

3.6.1. Opis funkcji interfejsu systemu plików (API)

Funkcje wchodzące w skład API systemu plików zostały opracowane na podstawie

analogicznych funkcji środowiska Unix [6]. Analogia dotyczy nazw funkcji, parametrów oraz

działania poszczególnych funkcji. Dokładniejszy opis wszystkich funkcji znajduje się w kodzie

źródłowym.

Lista funkcji wchodzących w skład API systemu plików:

int open(char *fullname, int flags)

int close(int fd)

long long seek(int fd, long long offset, int origin)

int read(int fd, char *buf, unsigned int n)

int write(int fd, char *buf, unsigned int n)

int create(char *fullname)

int delfile(char *fullname)

int mkdir(char *fullname)

int deldir(char *fullname)

int opendir(char *fullname)

int copy(char *source, char *dest, unsigned int n)

int get_char(int fd)

int put_char(int fd, char c)


55

3.6.2. Implementacja systemu plików

Istotną rzeczą w zaimplementowanym systemie plików FAT-32 jest sposób

przechowywania pewnych kluczowych danych związanych z jego działaniem. Najważniejsze są

struktury i funkcje ułatwiające poruszanie się po bieżącym katalogu – mapy katalogu.

Ponieważ każdy katalog traktowany jest jak specyficzny plik zawierający 32-bajtowe wpisy

katalogowe (ang. Directory Entry), tak jak wszystkie pliki w systemie plików FAT, składa się on z

łańcucha klastrów. Powiązania między kolejnymi klastrami zdefiniowane są w tablicy alokacji plików

FAT (ang. File Allocation Table). Numer pierwszego klastra katalogu głównego znajduje się w

strukturze fat32_data.root_cluster. Do wygodnego poruszania się po bieżącym katalogu

tworzone są specjalne mapy: mapa zawierająca listę klastrów tworzących katalog oraz mapa katalogu,

zawierająca informacje o plikach i podkatalogach znajdujących się w danym katalogu. Konieczne było

przyjęcie pewnych ograniczeń, co do ilości klastrów tworzących katalog, a co za tym idzie – ilości

wpisów w danym katalogu. Przyjęto maksymalnią liczbę 256 wpisów w katalogu, na podstawie której

można obliczyć maksymalną ilość klastrów tworzących katalog. Tworzeniem map katalogów zajmuje

się funkcja int fat32_build_map(unsigned int cluster), która jako parametr przyjmuje

pierwszy klaster danego katalogu. Funkcja przechodzi po wszystkich klastrach katalogu (zgodnie z

informacjami w tablicy FAT), tworząc mapę klastrów katalogu w tablicy clusters_map[] [4].

Mapa klastrów, które tworzą aktualny katalog:

// clusters map of directory

unsigned int clusters_map[MAX_DIR_CLUSTERS];

Następnie analizowane są wszystkie 32-bitowe wpisy w katalogu i tworzona jest mapa

użytecznych wpisów, czyli informacji o plikach lub podkatalogach. W strukturze dir_map[]

przechowywana jest informacja o numerze klastra, w którym jest wpis (w postaci indeksu tablicy

clusters_map[]), pozycji w klastrze oraz nazwie, rozszerzeniu i atrybutach wpisu [4]:

// directory map

struct TMapEntry

{

char cluster_ind;

char cluster_pos;

char name[DE_NAME_LEN+1];

char ext[DE_EXT_LEN+1];

char attr;

} dir_map[MAX_MAP_ENTRIES];


56

W strukturze de (ang. Directory Entry) typu TDirEntry przechowywane są wszystkie

informacje związane z danym wpisem:

struct TDirEntry

{

char name[DE_NAME_LEN+1], ext[3+1];

char attr;

char NTres;

char create_time_tenth;

short create_time;

short create_date;

short last_access_date;

short first_cluster_high;

short write_time;

short write_date;

short first_cluster_low;

unsigned int file_size;

// extra field

unsigned int first_cluster;

};

// directory entry

struct TDirEntry de;

Rys. 3.6.2.1 Powiązanie struktur map katalogu [4].

: :

…

dir_map[]

cluster_ind cluster_pos

Klaster katalogu

: :

custers_map[]

: :

: :

de[]

Wpis


57

W pliku nagłówkowym FAT32.H znajdują się definicje stałych związanych z konfiguracją

systemu plików, takich jak: wielkość klastra, ilość maksymalnych wpisów w katalogu, wielkość

wpisu w katalogu, ilość sektorów na klaster, informacje związane z blokiem BPB (ang. BIOS

Paremeter Block), atrybuty plików, nazwy pól wpisu katalogowego, tryby otwarcia plików.

Kolejną grupą stałych są wartości zwracane przez poszczególne funkcje – ułatwiające

wyszukiwanie błędów związanych z systemem plików. Następnie znajdują się deklaracje

opisanych powyżej globalnych struktur danych oraz deklaracje funkcji. W pliku FAT32.C

znajdują się ciała wszystkich funkcji związanych z systemem plików – zarówno funkcje

wchodzące w skład API, jak i funkcje wewnętrzne.

3.7. Powłoka

Powłoka (ang. Shell) jest częścią oprogramowania stanowiącą interfejs użytkownika.

Umożliwia wydawanie poleceń przez użytkownika i otrzymywanie informacji zwrotnych. Jest

zaimplementowana jako nieskończona pętla, oczekująca na komendy od użytkownika. Każdy

znak wprowadzony na klawiaturze komputera PC jest wysyłany do systemu embedded poprzez

program terminalowy oraz łącze szeregowe. Powłoka przechwytuje wysłany znak,

wykorzystując funkcje związane z interfejsem UART. Z wysłanych znaków alfanumerycznych

formowana jest w buforze komenda. Bufor komend jest odporny na przepełnienie – po

przekroczeniu założonej długości komendy wysyłany jest odpowiedni komunikat, a bufor jest

czyszczony. Reakcja na inne znaki np. backspace jest zgodna z oczekiwaniem – kasowany jest

ostatnio wprowadzony znak.. Naciśnięcie klawisza enter powoduje uruchomienie wprowadzonej

komendy. Łańcuch w buforze komend jest porównywany z zaprogramowanymi komendami,

jeśli wykryta jest zgodność to uruchamiana jest funkcja związana z daną komendą.


58

4. Testowanie i uruchamianie

Testowanie jest rozumiane jako zbiór czynności wykonywanych z intencją wykrycia

w programie jak największej liczby błędów. Celem testowania programu jest upewnienie się, że

program rozwiązuje to zadanie, do którego został zaprojektowany, i że w każdych warunkach

daje poprawne wyniki [27].

Uruchamianie (ang. Debugging) to proces znajdowania i usuwania z programu błędów

pierwotnych, do którego przystępujemy po stwierdzeniu (w etapie testowania) dowodów lub

symptomów istnienia błędu [27]. W procesie uruchamiania wykorzystywany był debugger

sprzętowy VisionPROBE II oraz współpracujące z nim oprogramowanie SingleStep. Ustawianie

pułapek, śledzenie wykonania programu krok po kroku, analiza zawartości pamięci i rejestrów

oraz odpowiednio dobrane dane testowe pozwoliły znaleźć wykryte błędy. Cennym narzędziem

w procesie uruchamiania okazał się też oscyloskop.

Testowanie następowało po każdym zakończonym etapie implementacji.

W pierwszym etapie zapoznawania się z systemem embedded napisane zostały funkcje

i makra odpowiedzialne za dostęp do poszczególnych rejestrów mikrokontrolera, ułatwiające

dostęp do pamięci, konfigurację stosu (PPC405GP.H oraz PPC405GP.C). Przetestowanie tego

modułu polegało na użyciu napisanych funkcji i makr do konfiguracji podstawowych ustawień

mikrokontrolera i kontrolera GPIO. Możliwość przeglądania zawartości pamięci i rejestrów

(dzięki programowi SingleStep i debuggerowi VisionPROBE II) pozwoliła zweryfikować

poprawność konfiguracji. Po napisaniu obsługi diod LED (LED.H i LED.C) oraz funkcji

opóźnień (TIME.H i TIME.C) możliwe stało się uruchomienie i przetestowanie programu typu

„Hello World” dla systemów embedded – czyli mrugania diodą.

Następnie dopisana została podstawowa obsługa przerwań (INT.S, INTERPT.H,

INTERPT.C) oraz funkcje związane z timerem PIT. Pozwoliło to ulepszyć program mrugania

diodą LED, dzięki wykorzystaniu przerwań i timera. Na tym etapie testowanie polegało na

obserwacji zachowania systemu embedded (diod, które sygnalizowały pewne zdarzenia) oraz

analizie zawartości pamięci i rejestrów.

Kolejnym ważnym krokiem było skonfigurowanie kontrolera UART oraz napisanie funkcji

związanych z komunikacją (wysyłanie/odbieranie znaków i łańcuchów). Testowanie polegało na


59

sprawdzeniu poprawności wysłanych łańcuchów pomiędzy komputerem PC z oprogramowaniem

HyperTerminal i systemem embedded (połączonych kablem szeregowym RS-232).

Po napisaniu i przetestowaniu funkcji komunikacyjnych możliwe stało się napisanie

powłoki (ang. Shell) – czyli fragmentu oprogramowania, które przyjmuje i uruchamia polecenia

wprowadzane przez użytkownika i wyprowadza wyniki jego działania. Testowanie polegało na

oprogramowaniu pewnych podstawowych poleceń, np. zmiany stanu jednej z diod LED

poleceniem led9 lub wypisaniu wersji powłoki poleceniem shell i obserwacji, czy ich

działanie jest zgodne z oczekiwaniem oraz czy obsługa interfejsu użytkownika jest względnie

wygodna.

Następnym etapem było nawiązanie komunikacji z kontrolerem dysku twardego. Po

analizie specyfikacji ATA i dokumentacji mikrokontrolera PowerPC 405GP została dobrana

i oprogramowana odpowiednia konfiguracja kontrolera EBC. Testowanie tej konfiguracji

polegało na próbie odczytania rejestru statusu (ang. Status Register) kontrolera dysku oraz próbie

zapisania i odczytania konkretnej wartości do rejestrów kontrolera dysku twardego. Próby te

zakończyły się niepowodzeniem. Przy próbie odwołania się do zamapowanych w pamięci

rejestrów kontrolera dysku twardego mikrokontroler zachowywał się w sposób

nieprzewidywalny. Proces uruchamiania (debuggowania) polegał na wykonaniu programu krok

po kroku i analizie zawartości rejestrów. Pozwoliło to na znalezienie błędu – niewłaściwego

zamapowania rejestrów kontrolera dysku twardego (wpisania ich pod zły adres), przez co

następowało odwołanie do nieistniejącej komórki w pamięci i wywołanie przerwania

programowego sygnalizującego ten błąd. Ponieważ obsługa wyjątków nie była napisana –

działanie programu było nieprzewidywalne.

Po tych problemach zaimplementowana została podstawowa obsługa pułapek (ang. Traps),

polegająca na wypisaniu przyczyny błędu i zawartości pewnych rejestrów ułatwiających proces

debuggowania. Poprawienie błędnego zamapowania rejestrów nie poskutkowało jednak udaną

próbą komunikacji z kontrolerem. Po dłuższym czasie ponownej analizy zależności czasowych w

specyfikacji ATA, dokumentacji kontrolera EBC i schematów systemu embedded znaleziono

błąd w sprzęcie: niewłaściwe podłączenie linii adresowych pomiędzy EBC i kontrolerem dysku.

Błąd uniemożliwiał zaadresowanie rejestrów o adresie nieparzystym (np. rejestru stanu, który

jako pierwszy próbowano odczytać). Po przerobieniu płytki przez sprzętowca udało się odczytać

rejestr statusu, który wskazywał, że z dyskiem jest wszystko w porządku i oczekuje na komendy.


60

Niepowodzeniem zakończyły się jednak próby zapisania pewnej wartości do rejestru, a następnie

jej odczytania. Tu pomocny okazał się oscyloskop, dzięki któremu wykryto kolejny błąd w

sprzęcie – niewłaściwe sterowanie liniami ~1OE i ~2OE układu bufora trójstanowego

HD74LVC16245 przez układ PLD (przy próbie zapisu do rejestrów kontrolera dysku, bufor

przełączał porty w stan wysokiej impedancji uniemożliwiając zapis). Błędny okazał się fragment

programu w języku VHDL sterujący układem PLD, po jego poprawieniu możliwy był odczyt i

zapis rejestrów kontrolera dysku twardego.

Następnie podjęto próbę wykonania rozkazu IDENTIFY DRIVE (urządzenie przesyła 512

bajtów informacji o sobie) oraz odczytania numeru wersji i nazwy modelu dysku. W trakcie

testowania tej części wyniknęły problemy z konwersją big/little endian. Po napisaniu

odpowiednich funkcji konwertujących, udało się odczytać numer i nazwę modelu dysku zgodnie

z oznaczeniami na obudowie dysku.

W dalszym etapie napisano funkcjonalność związaną z trybem PIO (protokoły PIO DATA IN,

PIO DATA OUT, NON DATA, rozkazy READ SECTOR(S) oraz WRITE SECTOR(S)).

Testowanie polegało na zapisie i odczycie sektorów specjalnie przygotowanymi danymi

testowymi oraz weryfikacji poprawności przeprowadzonych operacji.

Napisanie części funkcjonalności systemu plików pozwalającej na odczyt plików pozwoliło

na dalsze przetestowanie sterownika dysku twardego. Testowanie polegało na odczycie krótkich

plików tekstowych, ich wypisaniu i porównaniu z oryginałem. Ten test pozwolił też na

przetestowanie systemu plików – zweryfikował poprawność odczytu danych z tablicy FAT,

informacji zawartych w katalogu i odczyt kolejnych sektorów pliku tekstowego. Analiza

zawartości zmiennych i krokowe wykonanie programu pozwoliły szybko zlokalizować

i naprawić błędy.

Następnie przyszła pora na uruchomienie trybu DMA. Przy testowaniu tu również pojawiły

się problemy. Odczyt działał dobrze, natomiast zapis nie działał zgodnie z oczekiwaniem.

Zamiast przygotowanych danych na nośnik zapisywany był tylko krótki kilku-bajtowy ich

fragment, a reszta sektora wypełniona była inną, ale tą samą, wartością. Problemem okazały się

sygnały związane z kontrolerem GPIO: PerCS6, PerCS7 (GPIO15, GPIO16; sterujące sygnałami

kontrolera: ~CS0, ~CS1) używane jako sygnały sterujące, które wybierają odpowiednie grupy

rejestrów w elektronice dysku twardego. W normalnych warunkach (brak transferu DMA) oba

sygnały są w stanie logicznym „1”, czyli nie jest wybrana żadna grupa rejestrów (magistrala jest


61

w stanie wysokiej impedancji). Przy odwołaniu do rejestru kontrolera odpowiedni sygnał jest

generowany (ustawiany w stan logiczny „0”) automatycznie przez kontroler EBC. Przy

transferze DMA jest inaczej – według specyfikacji ATA oba sygnały powinny być w stanie

logicznym „0”, czyli wybrane (ang. Asserted). W związku z tym na czas transferu DMA

przestawiane jest sterowanie tymi sygnałami na tryb „ręczny” i ustawiane jest na nich logiczne

„0”. Po tych zmianach zapis w trybie DMA zaczął działać poprawnie.

Gdy działał już tryb PIO oraz DMA sterownika dysku twardego przystąpiono do

restrukturyzacji (ang. Refactoring) kodu sterownika. Podzielono kod na funkcje tak aby

poszczególne części odpowiadały protokołom opisanym w specyfikacji ATA/ATAPI-7 oraz aby

uprościć dodawanie następnych rozkazów. Były to bardzo poważne zmiany w kodzie,

uniemożliwiające testowanie przed ich pełnym wprowadzeniem. Testowanie przeprowadzono po

wszystkich zmianach, polegało ono na użyciu wcześniej przygotowanych testów, gdyż

funkcjonalność się nie zmieniła. Proces uruchamiania polegał na śledzeniu krok po kroku

wykonania programu i poprawianiu znalezionych drobnych błędów.

Kolejnym krokiem było napisanie testów, które umożliwiłyby zmierzenie szybkości

transferu danych pomiędzy pamięcią systemu embedded i kontrolerem dysku twardego (w obu

trybach: PIO i DMA). Gdy wyniki były już znane przystąpiono do próby optymalizacji szybkości

transferu. Polegała ona na dobraniu odpowiednich ustawień kontrolera EBC oraz DMA, tak aby

timing wszystkich sygnałów związanych z transferem danych był zgodny ze specyfikacją

ATA/ATAPI-7, ale równocześnie dawał jak najlepsze rezultaty – jeśli chodzi o prędkość

transmisji. Był to etap żmudnej analizy dokumentacji, po której nastąpiły zmiany parametrów

obydwu kontrolerów oraz etap testowania, który polegał na wielokrotnych zapisach i odczytach

sektorów z równoczesnym sprawdzaniem ich poprawności.

Testy i optymalizacja szybkości transferu w trybie DMA ujawniły wąskie gardło jakim jest

kontroler DMA mikrokontrolera PowerPC 405GP. Po analizie dokumentacji dotyczącej

wydajności układu DMA i pewnych obliczeniach, podjęta została decyzja o nie

implementowaniu trybu UDMA.

Następnie dopisana została reszta funkcjonalności systemu plików – pozwalająca na zapis

plików, tworzenie katalogów i plików. Testowanie między innymi polegało na kopiowaniu

plików znajdujących się na dysku i sprawdzaniu ich wierności z oryginałem.


62

Sprawdzenie poprawności zdefiniowanego API sterownika dysku twardego polegało na

praktycznym jego wykorzystaniu poprzez wyższą warstwę w hierarchii oprogramowania –

system plików. Pozwoliło to na dopracowanie API i upewnienie się, że niczego nie brakuje.

Niezależność sterownika od wykorzystywanego, podczas prac rozwojowych nad

oprogramowaniem, dysku twardego została sprawdzona przez podłączenie i próbę obsługi dwóch

innych dysków (inne parametry, producent). Podczas tych prób wykryte zostały różnice

związane z obsługą diagnostyki – jeden z dysków, pomimo pozytywnie wykonanej diagnostyki,

zwracał sygnaturę niezgodną ze specyfikacją ATA/ATAPI-7. Innych problemów nie wykryto.

Etap końcowego testowania zaczął się od przygotowania specjalnie dobranych danych

testowych na dysku. Dysk został podłączony do komputera PC pod systemem operacyjnym

Microsoft Windows XP, aby zagwarantować poprawność stworzonych danych.. Na dysku

utworzono cztery partycje, wszystkie sformatowane systemem plików FAT-32 (klaster wielkości

4096 bajtów). Następnie na każdą partycję przegrana została utworzona wcześniej hierarchia

katalogów i plików. Utworzono cztery katalogi grupujące pliki o podobnych wielkościach

w ramach katalogu oraz 10 katalogów, każdy z kopią dużego pliku tekstowego (około 2GB). Po

podłączeniu dysku do systemu embedded wykonano test polegający na wykonaniu kopii pliku

w każdym z 10 katalogów, na każdej partycji. Duży rozmiar pliku pozwolił na przetestowanie

ogromnej liczby operacji odczytu/zapisu sektorów. Format pliku (zwykły tekst ASCII) pozwolił

na lokalizowanie błędnych fragmentów (różniących się fragmentów kopii i oryginału)

linux’owym programem diff oraz edytorem Notepad++. Po wykonaniu wszystkich operacji

kopiowania, dysk był ponownie podłączany do komputera PC, a poszczególne pliki (kopia

i oryginał) były porównywane poprzez obliczenie sygnatury md5sum. Ten test pozwolił na

wykrycie pewnych błędów w systemie plików oraz poważnego błędu w samym sterowniku

dysku twardego. Błąd w sterowniku polegał na niewłaściwej obsłudze przerwania pochodzącego

od dysku twardego. Przed właściwą obsługą przerwania nie był zapamiętywany (a po obsłudze

odzyskiwany) rejestr CR (ang. Compare Instructions) przechowujący wynik ostatniej instrukcji

porównania. Powodowało to przedwczesne zakończenie kopiowania pliku średnio w połowie

przypadków. Błąd został znaleziony dzięki żmudnemu procesowi śledzenia programu krok po

kroku, wykorzystaniu pułapek (ang. Breakpoints) oraz analizie zawartości zmiennych.


63

5. Wnioski

Sterownik dysku twardego opracowany jest dla systemu embedded z procesorem PowerPC

405GP, ale wyraźny podział na część zależną i niezależną od sprzętu umożliwia przeniesienie

go na inną platformę sprzętową,

Niektóre sygnały związane z kontrolerem dysku twardego są podłączone do systemu

embedded za pośrednictwem układu PLD (FPGA firmy Altera). Wykorzystanie tego układu

było przydatne w fazie rozwoju oprogramowania, jednakże w końcowym projekcie nie jest

on niezbędny. Można go wyeliminować wprowadzając nieznaczną modyfikację w sprzęcie,

jednocześnie obniżając koszty systemu,

Przenośność oprogramowania ułatwia kod napisany w przeważającej części w języku C.

Fragmenty napisane w asemblerze procesora PowerPC 405GP są nieliczne i niezbędne

(obsługa przerwań, odwołania do poszczególnych grup rejestrów, pomiar czasu

w krytycznych czasowo fragmentach kodu).

Wykorzystanie interfejsu równoległego PATA, a nie nowocześniejszego i lepszego

szeregowego SATA spowodowane było głównie ograniczeniami zastosowanej platformy

sprzętowej. Wykorzystywane w SATA magistrale, pracujące w systemie różnicowym

wymagałyby zbyt daleko idących zmian w platformie sprzętowej, pociągających za sobą zbyt

duże koszty w stosunku do zalet Serial ATA. Niewątpliwymi zaletami interfejsu SATA

w stosunku do PATA są:

Mniejsze zakłócenia i przesłuchy spowodowane obniżeniem poziomu napięć logicznych

sygnałów,

Większe prędkości transmisji,

Wygodny (cienki i giętki) oraz mniej podatny na uszkodzenia kabel przyłączeniowy,

Brak problemu Master/Slave, brak problemu arbitrażu,

Możliwość podłączania do działającego systemu (ang. Hot Plugged)

Funkcje poprawiające przepustowość (np. Queuing Overlapping) [2],


64

Sterownik jest zgodny z najnowszym standardem ATA/ATAPI-7. Nie stanowi to problemu

jeśli chodzi o wykorzystanie starszych dysków twardych, gdyż kolejne wydania standardu

ATA/ATAPI są ze sobą kompatybilne. Oznacza to, poprawną pracę starych dysków

twardych ze sterownikiem zgodnym z ATA/ATAPI-7, jak również pracę nowych urządzeń ze

starszymi sterownikami (oczywiście w takim przypadku urządzenie nie będzie

wykorzystywało w pełni swoich możliwości) [2]. Standard ATA/ATAPI-7 jest w dużym

stopniu kompatybilny ze starszym standardem ATA/ATAPI-6, w szczególności jeśli chodzi

o interfejs równoległy. Napisany sterownik dysku twardego był testowany z dyskiem starszej

generacji. Jego obsługa była poprawna,

Zastosowanie trybu UDMA (przy niskich prędkościach transmisji) okazało się nieopłacalne,

a przy wyższych niemożliwe do wykonania przy zastosowanej platformie sprzętowej.

W trybie UDMA obydwa zbocza sygnału taktującego wyzwalają przesłanie jednego

słowa danych. W układzie DMA mikrokontrolera PowerPC 405GP nie ma bezpośrednio

takiej możliwości, trzeba by to zrealizować za pośrednictwem układu PLD. Konieczność

zastosowania układu PLD w końcowej wersji systemu embedded zwiększyłaby koszty

sprzętu, co stawia pod znakiem zapytania sens takiego rozwiązania – lepiej zastosować

sprzętowy kontroler ATA.

W specyfikacji trybu UDMA nastąpiły zmiany w protokole w stosunku do trybu DMA.

Oprogramowanie trybu UDMA pociągałoby za sobą spore zmiany w sterowniku. Dodatkowo

w UDMA/33 wprowadzono mechanizm kontroli spójności transmitowanych danych oparty

na kodach CRC, co wprowadziłoby konieczność napisania dodatkowego fragmentu kodu.

Napisanie i przetestowanie oprogramowania implementującego tryb UDMA oczywiście

pociąga za sobą koszty [2]. Koszty te mogłyby być akceptowalne, gdyby udało się uruchomić

tryb UDMA w którymś z szybszych trybów transmisji (dodatkowym atutem jest kontrola

transmitowanych danych). Zastosowanie szybszych trybów (powyżej górnej granicy

najszybszego trybu DMA – Multiword DMA 2, charakteryzującego się maksymalnym

transferem 16.66 MB/s) okazało się niemożliwe.

Wydajność układu DMA jest ściśle związana z ustawieniami zegara systemowego oraz

częstotliwości zegara w poszczególnych układach peryferyjnych mikrokontrolera (ustawiana

poprzez dzielniki zegara systemowego). Rys. 2.3.2 w rozdziale drugim przedstawia

konfigurację taktowania magistral i podukładów mikrokontrolera PowerPC 405GP.


65

Najważniejszym parametrem wpływającym na szybkość transferu danych pomiędzy

pamięcią systemu embedded a elektroniką dysku twardego jest PerClk (ang. Peripheral Bus

Clock). Podczas transferów EBC wszystkie zmiany sygnałów związanych z EBC oraz

próbkowanie danych jest synchronizowane z PerClk. Ważnym czynnikiem jest również

częstotliwość taktowania pamięci MemClkOut [22].

Mając na uwadze powyższe parametry, dobrane zostały odpowiednie wartości rejestrów

konfigurujące dzielniki częstotliwości:

SysClk = 33.3 Mhz

PFWD = 11 (divide by 6)

PFBD = 11 (divide by 4)

PDC = 00 (divide by 1)

EBDP = 00 (divide by 2) [22]

Dzięki takim ustawieniom częstotliwość pracy magistrali PLB (ang. Processor Local

Bus), częstotliwość pracy pamięci została ustawiona na maksymalną dopuszczalną wartość

dla zastosowanej pamięci SDRAM – 133 MHz.

Chociaż maksymalna częstotliwość pracy procesora wynosi 200 MHz, przy

powyższych ustawieniach wynosi ona 133 MHz. Takie ustawienie częstotliwości pracy

procesora jest konieczne, aby uzyskać najwyższe możliwe częstotliwości pracy pamięci oraz

układu EBC. Zmniejszenie częstotliwości pracy procesora nie wpływa bezpośrednio na

szybkość transferu danych w trybie DMA, pomiędzy kontrolerem dysku twardego,

a pamięcią systemu embedded.

Wartość PerClk ustawiamy przypisując odpowiednią wartość dzielnika EBDP

(ang. Peripheral Bus Divide Ratio from PLB). Najniższa wartość tego dzielnika to 2 (EBDP =

00). Ponieważ częstotliwość pracy PLB wynosi 133 MHz, częstotliwość zegara PerClk

wynosi 2

133MHzczyli 66.5 MHz.

Stąd PerClk ≈ 15 ns.

Mając na uwadze ustawienia układu EBC oraz DMA (wynikające z dopasowania

przebiegów czasowych odpowiednich sygnałów według specyfikacji ATA/ATAPI 7) dla

najszybszego trybu DMA-2 można obliczyć maksymalną wydajność układu DMA [24], [22].


66

Dane i założenia potrzebne do obliczeń:

PerClk ≈ 15 ns

Ustawienia układu DMA dla trybu DMA-2

Ustawienia kanału DMA (DMA Channel Control Register):

PSC (ang. Peripheral Setup Cycles) = 0

PWC (ang. Peripheral Wait Cycles) = 4

PHC (ang. Peripheral Hold Cycles) = 0

PW (ang. Peripheral Width) = 1 (16 bits)

Zakładamy odczyt danych (transfer z dysku do pamięci systemu embedded)

Bufor układu DMA (32 bajty) jest włączony

Parametr b = 4 (dodatkowe opóźnienie zależne od dzielnika SDRAM:EBC oraz

wartości PHC) [24]

Parametr c = 9 (dodatkowe opóźnienie zależne od dzielnika SDRAM:EBC, wartości

PHC, PF oraz SDRAM CAS Latency) [24]

Szukane:

A – czas w ns potrzebny na odczytanie 32 bajtów danych

B – czas w ns potrzebny na transfer jednej porcji danych (gdy bufor układu DMA

nie jest pełny)

C – czas w ns potrzebny na transfer jednej porcji danych (gdy bufor układu DMA

jest pełny)

Obliczenia:

PerClkCBA PW 125 [ns]

bPHCPWCPSCB 1 [ns]

cPHCPWCPSCC 1 [ns]

Czyli:

940410 B [ns]

1490410 C [ns]

223515149151514912 15 A [ns]

Stąd szybkość transferu wynosi: 3.142235

32

ns

bajty[MB/s]


67

Wyliczone w ten sposób szybkości transferu reprezentują górny limit wydajności

układu DMA mikrokontrolera PowerPC 405GP. W praktyce wydajność będzie mniejsza

z kilku powodów:

W wyliczeniach nie jest brany pod uwagę czas potrzebny na odświeżanie pamięci SDRAM,

Zakładano brak transakcji na magistrali PLB innych niż związanych

z rozpatrywanym transferem DMA (a takie występują – chociażby pobieranie

instrukcji programu i danych z pamięci SDRAM),

Założeniem był brak innych transakcji DMA o wyższym priorytecie.

Zmierzona w praktyce szybkość transferu wynosi około 11.8 MB/s

Nie da się uzyskać większych szybkości transferu z powodu kilku ograniczeń:

Ustawienia zegarów wpływających na szybkość transferu są już maksymalne,

Nie ma możliwości zmian parametrów układu DMA – są one optymalne tzn.

zapewniające największą szybkość transferu, przy zachowaniu zgodności ze

specyfikacją ATA/ATAPI 7.

Testy pozwalające zmierzyć szybkość transferu danych pomiędzy kontrolerem dysku

twardego, a pamięcią systemu embedded pozwoliły na zoptymalizowanie poszczególnych

trybów pracy sterownika. Optymalizowany był głównie tryb DMA. Tryb PIO był optymalizowany

na poziomie zależności czasowych sygnałów interfejsu EBC, ale nie na poziomie pętli w

której odbywa się transfer (czyli kopiowanie z lub do rejestru danych kontrolera). Dobra

optymalizacja trybu PIO nie była potrzebna, gdyż docelowo sterownik będzie cały czas

pracował w trybie DMA. Testy szybkości transferu pozwoliły też wyciągnąć pewne wnioski

np. zadecydowały o dokładnej analizie wąskiego gardła systemu embedded, jakim okazał się

kontroler DMA procesora PowerPC 405GP oraz o nieimplementowaniu trybu Ultra DMA.

Test obciążenia procesora podczas transferów danych pomiędzy kontrolerem dysku

twardego, a pamięcią systemu embedded w trybie DMA pozwolił na wyciągnięcie wniosków

na temat wąskiego gardła w transferach oraz możliwości optymalizacji transferów. Przy tak

małym obciążeniu procesora podczas transferów DMA (około 1.5 %) sensowne stały się

modyfikacje częstotliwości pracy poszczególnych układów. W rezultacie zwiększono

szybkość transferu poprzez zwiększenie częstotliwości pracy zegara PerClk, równocześnie

obniżając taktowanie procesora ze 150 MHz do 133 MHz (co było konieczne do zwiększenia

częstotliwości zegara PerClk).


68

Zaimplementowany system plików FAT-32 pozwolił przetestować poprawność działania

sterownika dysku twardego (poprzez wykonywane testów związanych z operacjami na

plikach) oraz przetestować użyteczność API sterownika (poprzez wykorzystanie funkcji

wchodzących w skład API w kodzie systemu plików). Napisana funkcjonalność systemu

plików stanowi minimum, potrzebne do przeprowadzenia testów sterownika. Nie ma na

przykład obsługi wyjątków i błędów (np. koniec miejsca na dysku twardym, problem

z odczytaniem jakiegoś sektora, niespójny system plików).

Powłoka doskonale sprawdziła się jako interfejs użytkownika. Wczesne jej napisanie bardzo

ułatwiło początkowe testowanie oprogramowania. Dzięki wykorzystaniu obsługi komend

można było przetestować poszczególne fragmenty programu, sprawdzając uzyskane wyniki

na monitorze komputera PC.

Kod źródłowy posiada komentarze w języku angielskim, ze względu na możliwość

wykorzystania kodu przez obcokrajowców. Nazwy zmiennych, funkcji starałem się tak

dobrać, aby kod stał się „samokomentujący”.

Ostateczny termin zakończenia projektu został przesunięty o około miesiąc, ze względu na

niedoszacowany stopień skomplikowania tworzonego oprogramowania, a w związku z tym

czas tworzenia projektu.

W trakcie dotychczasowego użytkowanie systemu nie otrzymano żadnego zgłoszenia o usterce.

Niezbędnym narzędziem przy programowaniu systemów embedded okazał się debugger

sprzętowy. Dzięki możliwości kontroli wykonania programu oraz sprawdzenia zawartości

wszystkich rejestrów i pamięci proces uruchamiania znacznie się uprościł.

Przydatnym narzędziem w poszukiwaniu błędów okazał się oscyloskop. Dzięki sprawdzeniu

zachowania się linii adresowych, danych oraz innych linii sterujących przy uruchomieniu

danego fragmentu kodu udało się wykryć błędy w programie, a także sprzęcie.

Przy programowaniu systemów embedded należy mieć na uwadze błędy w sprzęcie.

Zastosowany system embedded był przetestowany poprzez uruchomienie na nim systemu

operacyjnego Linux. W szczególności przetestowana była część sprzętowa odpowiedzialna

za komunikację z dyskiem twardym. Problemy, które napotkano dotyczyły jednak

konkretnego, wykorzystywanego przy realizacji tematu pracy, egzemplarza systemu


69

embedded. Po napotkaniu problemów z nawiązaniem komunikacji z elektroniką dysku

twardego i długich poszukiwaniach znaleziono następujące błędy w sprzęcie:

niewłaściwe podłączenie linii adresowych pomiędzy EBC i kontrolerem dysku (błąd

uniemożliwił zaadresowanie rejestrów o adresie nieparzystym (np. rejestru stanu, który

jako pierwszy próbowano odczytać)

linie ~1OE i ~2OE bufora HD74LVC16245 były niewłaściwie sterowane poprzez układ

PLD (przy próbie zapisu do rejestrów kontrolera dysku, bufor przełączał porty w stan

wysokiej impedancji uniemożliwiając zapis)

niekontaktujaca jedna linia magistrali danych (pomiędzy EBC i kontrolerem dysku)

Procesor PowerPC 405GP posiada bardzo dobrą dokumentację – User’s Manual [22].

Zapewniło to wygodne programowanie we wczesnej fazie projektu. Wyjątkiem jest kiepski

opis asemblera. Konieczne było przejrzenie zasobów Internetu w celu znalezienia

dokładniejszej dokumentacji i przede wszystkim przykładów.

Problemowa okazała się kompilacja odpowiednio skonfigurowanego kompilatora GCC pod

Cygwinem. Konieczne było odpowiednie dobranie wersji komilatora GCC (3.3.1),

programów narzędziowych binutils(2.14) oraz modyfikacja kilku linijek kodu kompilatora,

tak aby problemy z kompilacją nie występowały.

Korzystanie ze środowiska Cywin, programu make i kompilatora GCC uprościło

kompilowanie oprogramowania do minimum. Poprzez zastosowanie wcześniej

przygotowanego skryptu, kompilacja i łączenie poszczególnych fragmentów programu

sprowadzało się do wydania jednego polecenia.

Wszystkie warstwy architektury systemu, opisane na rysunku Rys. 3.2.1 zostały napisane

przeze mnie – nie korzystałem z żadnych bibliotek.

Wykorzystanie metod inżynierii oprogramowania pozwoliło lepiej zorganizować pracę nad

projektem, niestety nie uchroniło przed przekroczeniem terminu realizacji.

Testowanie od najwcześniejszego etapu projektu jest niezwykle ważne. Warto poświęcić

godzinę na przetestowanie właśnie napisanego kodu, niż zostawić testowanie na koniec –

kiedy znalezienie błędu może zająć kilka dni. Dobrym podejściem jest najpierw napisanie

testów, a dopiero później testowanej funkcjonalności.


70

Bardzo przydatne jest jak najwcześniejsze oprogramowanie podstawowej obsługi pułapek

(ang. Trap), czyli przerwań programowych wywoływanych przy błędnym zachowaniu

programu np. odwołaniu do nieistniejącego adresu w pamięci. Taka podstawowa obsługa

polegała na wypisaniu komunikatu o rodzaju błędu, wypisaniu wartości rejestrów, które

umożliwią zlokalizowanie błędu i wejście w nieskończoną, pustą pętlę.

Zastosowanie systemu plików FAT32 spowodowało konieczność zastosowania konwersji

little na big endian. [4] Wszystkie odmiany systemu FAT były zaprojektowane dla

komputerów typu PC, które są maszynami z rodziny little endian. Ma to swoje

odzwierciedlenie w strukturze systemu plików, w którym w przypadku liczb

przechowywanych na kilku bajtach (16- lub 32-bitowe), bajty ułożone są w kolejności od

najmniej do najbardziej znaczącego (adresy rosną). Mikrokontroler PowerPC 405GP jest

typu big endian4, stąd konieczność dokonywania konwersji.

Główny cel pracy został osiągnięty. W końcowym efekcie uzyskano:

Przetestowany, działający sterownik dysku twardego dla założonej platformy

sprzętowej,

Opracowane, zaimplementowane i przetestowane API sterownika,

Szczegółową dokumentację API sterownika,

Oszacowanie parametrów związanych ze sterownikiem i wykorzystywaną platformą

sprzętową:

Szybkość transferu w poszczególnych trybach transmisji danych,

Obciążenie procesora podczas transferu DMA,

Testy pozwalające oszacować powyższe parametry,

System plików FAT-32 w podstawowej funkcjonalności, pozwalającej przetestować

poprawność działania sterownika oraz użyteczność API.

Z powodu ograniczeń wykorzystywanej platformy sprzętowej nie został

zaimplementowany w sterowniku dysku twardego tryb Ultra DMA

4 chociaż istnieje możliwość ustawienia pewnych obszarów jako little endian


71

6. Literatura

1. Ian Sommerville: „Inżynieria oprogramowania”, WNT, Warszawa 2003

2. Piotr Metzger : „Anatomia PC”, wydanie VIII, Helion, Gliwice 2003

3. Andrew S. Tanenbaum, Albert S. Woodhull: „Operating systems: Design and

Implementation“, Second Edition

4. Paweł Marks: “Pamięci masowe w systemach mikroprocesorowych”, BTC, Warszawa 2006

5. Hektor Garcia-Molina, Jeffrey D. Ullman, Jennifer Widom: „Implementacja systemów

baz danych”, WNT, Warszawa 2003

6. Brian W. Kernighan, Dennis M. Ritchie: „Język ANSI C“, WNT, Warszawa 2002

7. Karim Yaghmour: “Building Embedded Linux Systems”, O'Reilly April 2003

8. Matt Welsh, Matthias, Kalle Dalheimer, Lar Kaufman: „Linux“, O’Reilly, Warszawa 2000

9. Byte Craft Limited: “First Steps with Embedded Systems”, 2002

10. Brian Gough: “An introduction to GCC”, Network Theory Limited, 2004

11. Technical committee T13 AT Attachment

http://www.t13.org/

12. Information Technology - AT Attachment with Packet Interface - 7

Volume 1 – Register Delivered Command Set, Logical Register Set (ATA/ATAPI-7 V1)

http://t13.org/docs2004/d1532v1r4b-ATA-ATAPI-7.pdf

13. Information Technology - AT Attachment with Packet Interface - 7

Volume 2 – Parallel Transport Protocols and Physical Interconnect

(ATA/ATAPI-7 V2)


14. Information Technology - AT Attachment with Packet Interface – 7

Volume 3 – Serial Transport Protocols and Physical Interconnect (ATA/ATAPI-7 V3)


15. Encyklopedia internetowa Wikipedia

http://pl.wikipedia.org/wiki/

16. Cygwin: Linux-like environment for Windows

http://www.cygwin.com/

http://www.t13.org/




http://pl.wikipedia.org/wiki/

http://www.cygwin.com/


72

17. GCC, the GNU Compiler

http://gcc.gnu.org/

18. Information for Developers of Products Using ATA (PATA, IDE/EIDE), Serial ATA

(SATA), ATAPI, CF, CE-ATA and Other ATA Related Interfaces

http://www.ata-atapi.com/

19. Hard disk drives

http://www.pcguide.com/ref/hdd/

20. VisionPROBE II product information (datasheet)

http://www.windriver.com/products/development_tools/debuggers_emulators/vision

probe2/visionPROBE_II_DS.pdf

21. SingleStep with vision product information (datasheet)

http://www.windriver.com/products/development_tools/debuggers_emulators/single

step_vision/singlestep_vision.pdf

22. PowerPC 405GP – User’s Manual: UM2005

https://www.amcc.com/MyAMCC/retrieveDocument/PowerPC/405GP_GPR/PPC4

05GP_UM2005_v1_02.pdf

23. Arthur Griffith: “GCC: The Complete Reference”, The McGraw-Hill Companies, Inc., 2002

24. PowerPC 405GP – DMA Performance v1.01

https://www.amcc.com/MyAMCC/retrieveDocument/PowerPC/405GP_GPR/PPC4

05GP_AN2053_DMAPerformance__v1_01.pdf

25. AMON board schematics (ADESCOM Inc.)

26. Notepad++ - edytor tekstu

http://notepad-plus.sourceforge.net/uk/site.htm

27. Praca zbiorowa pod redakcją Przemysława Szmala: “Inżynieria programowania”,

Wydawnictwo Politechniki Śląskiej, Gliwice 2003

28. FAT32 File System Specification, Microsoft Corporation, 2000

http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx

http://gcc.gnu.org/

http://www.ata-atapi.com/

http://www.pcguide.com/ref/hdd/

http://www.windriver.com/products/development_tools/debuggers_emulators/visionprobe2/visionPROBE_II_DS.pdf

http://www.windriver.com/products/development_tools/debuggers_emulators/visionprobe2/visionPROBE_II_DS.pdf

http://www.windriver.com/products/development_tools/debuggers_emulators/singlestep_vision/singlestep_vision.pdf

http://www.windriver.com/products/development_tools/debuggers_emulators/singlestep_vision/singlestep_vision.pdf

https://www.amcc.com/MyAMCC/retrieveDocument/PowerPC/405GP_GPR/PPC405GP_UM2005_v1_02.pdf

https://www.amcc.com/MyAMCC/retrieveDocument/PowerPC/405GP_GPR/PPC405GP_UM2005_v1_02.pdf

https://www.amcc.com/MyAMCC/retrieveDocument/PowerPC/405GP_GPR/PPC405GP_AN2053_DMAPerformance__v1_01.pdf

https://www.amcc.com/MyAMCC/retrieveDocument/PowerPC/405GP_GPR/PPC405GP_AN2053_DMAPerformance__v1_01.pdf

http://notepad-plus.sourceforge.net/uk/site.htm

http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx

Praca Dyplomowa

Documents

Transcript of Praca Dyplomowa