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

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, aktualnystan 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 0HOST

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
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)
0x1F2
0 1 0 1 1
Adres LBA (bity 0-7)
(ang. LBA Low)
(ang. LBA Low)
0x1F3
0 1 1 0 0
(ang. LBA Mid)
(ang. LBA Mid)
0x1F4
0 1 1 0 1
(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
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 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/sec
IMETRANSFER_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
nsCPU_TIME*imetransfer_t
bajtów512
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%
DMAmtransferezpetliwykonaniaczas
DMAtransferubezpetliwykonaniaczas
1L 







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

Praca Dyplomowa

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Viewers also liked

Viewers also liked (13)

Similar to Praca Dyplomowa

Similar to Praca Dyplomowa (20)

Praca Dyplomowa