Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00168 008419 10460406 na godz. na dobę w sumie
RTLinux - system czasu rzeczywistego - książka
RTLinux - system czasu rzeczywistego - książka
Autor: , , Liczba stron: 116
Wydawca: Helion Język publikacji: polski
ISBN: 83-7197-898-7 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> systemy operacyjne >> linux
Porównaj ceny (książka, ebook, audiobook).
Systemy czasu rzeczywistego stanowią specyficzną, ale bardzo ważną dziedzinę współczesnej informatyki. Złożoność samego przetwarzania w czasie rzeczywistym oraz fakt, że oprogramowanie czasu rzeczywistego jest implementowane najczęściej w niewidocznych, najniższych warstwach systemów informatycznych, sprawia, że te elementy są ukryte przed przeciętnymi użytkownikami, a wiedza na ich temat jest niewielka i trudno dostępna.

Typowymi i najliczniejszymi przedstawicielami systemów czasu rzeczywistego są systemy sterowania procesów przemysłowych, często należące do klasy systemów określanych jako wbudowane. Ich zadaniem jest sterowanie liniami technologicznymi, obrabiarkami, robotami, układami napędowymi itp. W życiu codziennym systemy te stosowane są stosowane w nowoczesnych aparatach fotograficznych do określania parametrów ekspozycji, w samochodach do sterowania bezpośrednim wtryskiem paliwa oraz w osobistych komputerach kieszonkowych.

Książka opisuje RTLinux, darmowy system operacyjny czasu rzeczywistego oparty na Linuksie. Nowoczesna architektura i szeroki wybór platform, na których pracuje, czyni go interesującym dla wszystkich osób potrzebujących takiego systemu.

  • Architekturę Linuxa i modyfikacje wprowadzone w systemie RTLinux
  • Instalację i konfigurację RTLinuxa
  • Tworzenie aplikacji czasu rzeczywistego
  • Prosty system pomiarowy czasu rzeczywistego Uzupełnieniem książki są dodatki opisujące dokładnie pełną listę funkcji implementowanych przez RTLinux, a także przykłady ich praktycznego wykorzystania.
  • Znajdź podobne książki Ostatnio czytane w tej kategorii

    Darmowy fragment publikacji:

    IDZ DO IDZ DO PRZYK£ADOWY ROZDZIA£ PRZYK£ADOWY ROZDZIA£ SPIS TREĎCI SPIS TREĎCI KATALOG KSI¥¯EK KATALOG KSI¥¯EK KATALOG ONLINE KATALOG ONLINE ZAMÓW DRUKOWANY KATALOG ZAMÓW DRUKOWANY KATALOG TWÓJ KOSZYK TWÓJ KOSZYK DODAJ DO KOSZYKA DODAJ DO KOSZYKA CENNIK I INFORMACJE CENNIK I INFORMACJE ZAMÓW INFORMACJE ZAMÓW INFORMACJE O NOWOĎCIACH O NOWOĎCIACH ZAMÓW CENNIK ZAMÓW CENNIK CZYTELNIA CZYTELNIA FRAGMENTY KSI¥¯EK ONLINE FRAGMENTY KSI¥¯EK ONLINE Wydawnictwo Helion ul. Chopina 6 44-100 Gliwice tel. (32)230-98-63 e-mail: helion@helion.pl RTLinux – system czasu rzeczywistego Autorzy: Kazimierz Lal, Tomasz Rak, Krzysztof Orkisz ISBN: 83-7197-898-7 Format: B5, stron: 116 Systemy czasu rzeczywistego stanowi¹ specyficzn¹, ale bardzo wa¿n¹ dziedzinê wspó³czesnej informatyki. Z³o¿onoġæ samego przetwarzania w czasie rzeczywistym oraz fakt, ¿e oprogramowanie czasu rzeczywistego jest implementowane najczêġciej w niewidocznych, najni¿szych warstwach systemów informatycznych, sprawia, ¿e te elementy s¹ ukryte przed przeciêtnymi u¿ytkownikami, a wiedza na ich temat jest niewielka i trudno dostêpna. Typowymi i najliczniejszymi przedstawicielami systemów czasu rzeczywistego s¹ systemy sterowania procesów przemys³owych, czêsto nale¿¹ce do klasy systemów okreġlanych jako wbudowane. Ich zadaniem jest sterowanie liniami technologicznymi, obrabiarkami, robotami, uk³adami napêdowymi itp. W ¿yciu codziennym systemy te stosowane s¹ stosowane w nowoczesnych aparatach fotograficznych do okreġlania parametrów ekspozycji, w samochodach do sterowania bezpoġrednim wtryskiem paliwa oraz w osobistych komputerach kieszonkowych. Ksi¹¿ka opisuje RTLinux, darmowy system operacyjny czasu rzeczywistego oparty na Linuksie. Nowoczesna architektura i szeroki wybór platform, na których pracuje, czyni go interesuj¹cym dla wszystkich osób potrzebuj¹cych takiego systemu. W ksi¹¿ce znajdziesz opisane: • Architekturê Linuxa i modyfikacje wprowadzone w systemie RTLinux • Instalacjê i konfiguracjê RTLinuxa • Tworzenie aplikacji czasu rzeczywistego • Prosty system pomiarowy czasu rzeczywistego Uzupe³nieniem ksi¹¿ki s¹ dodatki opisuj¹ce dok³adnie pe³n¹ listê funkcji implementowanych przez RTLinux, a tak¿e przyk³ady ich praktycznego wykorzystania. Spis treści Wstęp ...................................................z............................................ 5 Rozdział 1. Linux a czas rzeczywisty ...................................................z............... 11 Jądro systemu ...................................................e...................................................e..............11 Szeregowanie procesów ...................................................e.................................................12 Rozdzielczość szeregowania ...................................................e..........................................12 Wywołania systemowe...................................................e...................................................e13 Przerwania sprzętowe...................................................e...................................................e..13 Pamięć wirtualna ...................................................e...................................................e.........13 Optymalizacja wykorzystania zasobów systemowych ...................................................e..14 Rozdział 2. RTLinux ...................................................z........................................ 15 Podstawowe założenia...................................................e...................................................e.15 Architektura systemu...................................................e...................................................e...15 Wirtualny system przerwań...................................................e............................................17 Zadania czasu rzeczywistego ...................................................e.........................................18 Szeregowanie zadań ...................................................e...................................................e....19 Odmierzanie czasu ...................................................e...................................................e......21 Komunikacja międzyprocesowa ...................................................e....................................23 Kolejki czasu rzeczywistego...................................................e....................................23 Pamięć dzielona ...................................................e...................................................e....24 Synchronizacja i wzajemne wykluczanie ...................................................e................24 Rozdział 3. Instalacja i konfiguracja systemu RTLinux ........................................ 27 Pakiet...................................................e...................................................e...........................27 Historia...................................................e...................................................e..................27 Autorzy ...................................................e...................................................e.................28 Licencja...................................................e...................................................e.................29 Zawartość...................................................e...................................................e..............30 Mini-RTL...................................................e...................................................e..............31 Przebieg instalacji ...................................................e...................................................e.......32 Wybór dystrybucji ...................................................e...................................................e32 Wymagania sprzętowe ...................................................e.............................................33 Wymagania dla środowiska programistycznego ...................................................e.....34 Źródła pakietów ...................................................e...................................................e....36 Przebieg instalacji ...................................................e...................................................e.37 Kompilacja jądra ...................................................e...................................................e.........38 Konfiguracja i kompilacja RTLinuksa...................................................e...........................40 4 RTLinux — system czasu rzeczywistego Moduły czasu rzeczywistego ...................................................e.........................................43 Uruchamianie modułów systemowych ...................................................e....................43 Uruchamianie modułów czasu rzeczywistego użytkownika ......................................47 Rozdział 4. Aplikacje czasu rzeczywistego ...................................................z........ 49 Standard POSIX ...................................................e...................................................e..........49 Struktura systemu RT-Linux...................................................e..........................................54 Źródła pomocy przy programowaniu zadań czasu rzeczywistego .............................56 Kompilacja modułów ...................................................e...................................................e..57 Przykładowe problemy spotykane w aplikacjach RTLinuksa ..........................................57 Aplikacja „Hello World!” ...................................................e........................................57 Zadania czasu rzeczywistego...................................................e...................................59 Kolejki czasu rzeczywistego...................................................e....................................60 Obsługa przerwań systemowych...................................................e..............................63 Obsługa sygnałów czasu rzeczywistego w procesach Linuksa ..................................64 Zegar i funkcje konwersji czasu ...................................................e..............................66 Pamięć dzielona ...................................................e...................................................e....68 Mechanizmy synchronizacji międzyzadaniowej ...................................................e.....69 Rozdział 5. Prosty system pomiarowy czasu rzeczywistego ................................. 73 Multimetr METEX 3650CR — dane techniczne...................................................e...........73 Komunikacja z multimetrem...................................................e..........................................74 Sterownik portu szeregowego ...................................................e........................................75 Moduł obsługi multimetru...................................................e..............................................78 Uwagi końcowe...................................................e...................................................e...........85 Rozdział 6. Podsumowanie ...................................................z............................. 87 Dodatek A Pełna lista funkcji implementowanych przez system RTLinux............. 89 Funkcje charakterystyczne dla systemu ...................................................e.........................89 Podzbiór funkcji interfejsu POSIX, implementowany przez wersję 3.1...........................91 Opcjonalne funkcje POSIX zależne od konfiguracji ...................................................e.....93 Zmienne warunkowe POSIX ...................................................e.........................................93 Semafory POSIX...................................................e...................................................e.........93 Funkcje o ograniczonym zakresie używania ...................................................e.....................94 Dodatek B Przykładowe programy z wykorzystaniem API systemu RTLinux ......... 95 Przechwytywanie przerwań...................................................e............................................95 Sygnały czasu rzeczywistego w procesach Linuksa ...................................................e......97 Dodatek C Architektura i386, a wielozadaniowe systemy operacyjne ................. 99 Zarządzanie pamięcią w trybie chronionym ...................................................e..................99 Segmentacja ...................................................e...................................................e..........99 Stronicowanie (pamięć wirtualna) ...................................................e.........................101 Ochrona ...................................................e...................................................e.....................102 Przerwania i obsługa wyjątków...................................................e....................................103 Zarządzanie zadaniami...................................................e.................................................105 Bibliografia ...................................................z................................. 109 Skorowidz...................................................z................................... 111 Rozdział 2. RTLinux Podstawowe założenia Dosyć oczywistym rozwiązaniem, eliminującym wcześniej wymienione wady, wydaje się być modyfikacja jądra Linuksa. Taką drogę właśnie wybrali twórcy systemu KURT (http://www.ittc.ku.edu/kurt/). Konieczne zmiany to między innymi: wprowadzenie wy- właszczającego szeregowania procesów o stałym priorytecie, zwiększenie rozdzielczości szeregowania i wprowadzenie zegara wyższej rozdzielczości. Osiągnięty kompromis pozwolił na stworzenie systemu o łagodnych (ang. firm) ograniczeniach czasowych. Całkowicie inną drogę do osiągnięcia cech systemu operacyjnego (ale o twardych ograni- czeniach czasowych — ang. hard real-time operating system) wybrali twórcy RTLinuksa [2, 3]. Inspiracją w tym wypadku była architektura eksperymentalnego systemu MERT, zbudowanego przez badaczy z Bell Labs w latach siedemdziesiątych. W zamierzeniach system miał mieć możliwość uruchamiania zarówno aplikacji czasu rzeczywistego, jak i zwykłych programów. Intencją projektantów systemu MERT było stworzyć nie jeden system operacyjny, który wspiera obydwa typy prizetwarzania, lecz sprawić, aby system czasu rzeczywistego i system ogólnego przeznaczenia współistniały razem. Twierdzili oni, że … dostępność wyrafinowanego systemu ogólnego przeznaczenia na tym samym komputerze, co system czasu rzeczywistego, dostarcza potężnego narzędzia, które może być wykorzystane w projektach interfejsu człowiek-maszyna dla aplikacji czasu rzeczywistego... [1]. Architektura systemu Bazując na ideach systemu MERT — RTLinux oddziela mechanizmy systemu operacyj- nego czasu rzeczywistego od systemu operacyjnego ogólnego zastosowania. RTLinux działa traktując zwykłe jądro Linuksa jako zadanie pod kontrolą niewielkiego i prostego systemu operacyjnego czasu rzeczywistego. W istocie, Linux jest zadaniem tła (ang. idle task) dla RTLinuksa, wykonywanym jedynie wtedy, gdy żadne z zadań czasu rze- czywistego nie ubiega się o procesor. Z założenia zadanie Linuksa nigdy nie może zablo- 16 RTLinux — system czasu rzeczywistego kować przerwań i zapobiec wywłaszczeniu siebie. Technicznym kluczem do osiągnięcia tego jest dodanie programowej warstwy emulującej sprzętowy mechanizm kontroli prze- rwań. Linux nigdy nie może zablokować przerwań sprzętowych. Kiedy podejmuje taką próbę, część czasu rzeczywistego przechwytuje ten fakt, zaznacza odpowiednio i oddaje sterowanie z powrotem do jądra Linuksa. Niezależnie od trybu, Linuksowi nie pozwala się na zwiększenie opóźnienia odpowiedzi na przerwanie czasu rzeczywistego. Kiedy zo- staje zgłoszone przerwanie, jądro RTLinuksa przechwytuje je i decyduje, co z nim zrobić. Jeśli aktualnie istnieje procedura obsługi przerwania, pochodząca z zadania czasu rze- czywistego — zostaje wywołana. Kiedy przerwanie jest obsługiwane przez Linuksa (lub współdzielone z nim), jest oznaczane jako oczekujące. Po wykryciu próby włączenia przerwań przez jądro Linuksa wszystkie oczekujące przerwania są emulowane i wywo- ływane są odpowiednie procedury obsługi. Bez znaczenia jest to, w jakim trybie działa Linux. W trybie użytkownika, w trybie systemowym czy nawet w sekcji krytycznej jądra, RTLinux jest w stanie zareagować na przychodzące przerwania. Techniczne aspekty dyskutowanych rozwiązań poddane są szczegółowej analizie w podrozdziale „Wirtualny systemi przerwań”. RTLinux separuje mechanizmy jądra czasu rzeczywistego i mechanizmy jądra zwykłego systemu (rysunek 2.1). Tak więc każdy z osobna może być optymalizowany niezależnie. Jest tak zaprojektowany, że wyeliminowane są sytuacje, w których musi czekać na zwol- nienie jakichkolwiek zasobów przez Linuksa. RTLinux nie alokuje pamięci, nie dzieli sekcji krytycznych ani nie synchronizuje żadnych struktur danych, z wyjątkiem sytuacji niezbędnych do współdziałania obydwu systemów. Rysunek 2.1. Architektura systemu RTLinux [21] Mechanizmy komunikacyjne używane do wymiany danych pomiędzy zwykłymi pro- cesami a zadaniami czasu rzeczywistego są nieblokujące po stronie RTLinuksa. Nigdy nie występuje przypadek, że zadanie czasu rzeczywistego czeka na zakolejkowanie lub po- branie danych z kolejki. Jedną z kluczowych zasad projektowych RTLinuksa jest, aby pozostawić go jak naj- mniejszym i jak najprostszym. Im mniej spraw do „załatwienia” po stronie RTLinuksa i im więcej po stronie Linuksa, tym lepiej. Tak więc startem systemu, inicjalizacją urzą- dzeń, ładowaniem modułów, systemem plików i dynamicznym przydzielaniem zasobów zajmuje się zwykły system. Zadaniem RTLinuksa jest dostarczenie bezpośredniego dostępu do sprzętu dla wątków czasu rzeczywistego, szeregowanie, dostarczanie me- chanizmów odmierzania czasu i technik komunikacji mięidzyprocesowej. Rozdział 2. ♦ RTLinux 17 Wirtualny system przerwań Jądro Linuksa jest duże i monolityczne. Wielu ludzi zaangażowanych w jego rozwój często używa wyłączania przerwań w celu ochrony sekcji krytycznych. Rodzi to wspomniane już wcześniej reperkusje. Niezbędna korekta takiego stanu rzeczy pociągnęłaby szereg zmian w jądrze, jednak bez gwarancji wystarczająco dobrych wyników dla przetwarzania czasu rzeczywistego. W systemie RTLinux problem ten został rozwiązany przez Victora Yodaikena [1, 2] poprzez zastosowanie programowej warstwy emulacji pomiędzy jądrem Linuksa a sprzę- towym układem kontroli przerwań. Wszystkie wystąpienia makr cli, sti, iret w kodzie źródłowym jądra zostały zastąpione makrami: S_CLI, S_STI, S_IRET. W ten sposób emulator jest w stanie wykryć każdą próbę wyłączenia i włączenia przerwań przez jądro Linuksa. cli — wyzerowanie znacznika IF zezwolenia na przerwanina w rejestrze stanu procesora. sti — ustawienie znacznika IF zezwolenia na przerwanian. iret — instrukcja powrotu z procedury obsługi przerwanina. Budowę dwóch pierwszych makr przedstawia listing 2.1 (zapis w konwencji assem- blera AT T). Listing 2.1. Budowa makr S_CLI oraz S_STI 5A .+ OQXN5(+( 5A56+ UVK RWUJHN RWUJN- 40 .A 5 RWUJNH 5A+4 6  Makro S_CLI powoduje, że zamiast rzeczywistego wyłączenia przerwań przez procesor zerowana jest odpowiednia zmienna w emulatorze. Jeśli nastąpiło przerwanie i zmienna jest ustawiona, emulator wywołuje bezpośrednio procedurę obsługi przerwania ustaloną przez jądro Linuksa. W przeciwnym razie, gdy przerwania są wyłączone, fakt zgłoszenia przerwania jest zapamiętywany bitowo w zmiennej, przechowującej informacje o wszyst- kich oczekujących przerwaniach. Kiedy Linux na powrót próbuje włączyć przerwania, wszystkie oczekujące przerwania są emulowane. Makro iS_STI rzeczywiście włącza prze- rwania i przygotowuje stos procesora jak w przypadku wywołania przerwania: odkłada na niego flagi procesora, rejestr segmentowy jądra i adres powrotu, w tym wypadku adres ten oznaczony jest etykietą 1:. Makro S_IRET wykonuje całą pracę emulatora przerwań (listing 2.2). 18 RTLinux — system czasu rzeczywistego Listing 2.2. Budowa makra S_IRET 5A+4 6 RWUJFU RWUJNGCZ RWUJNGFZ OQXN- 40 .A 5GFZ OQXFZFU ENK OQXN5(4 3GFZ CPFN5(/#5-GFZ DUHNGFZGCZ L\H 5A .+ UVK LOR5(+ 6 GCZ  OQXN5(+( RQRNGFZ RQRNGCZ RQRFU KTGV Makro najpierw zachowuje używane rejestry i ustawia rejestr segmentowy danych na segment jądra, w celu dostępu do zmiennych globalnych. Następnie za pomocą „maski bitowej” wskazującej wszystkie niezamaskowane przerwania odrzuca te przerwania, które nie mają być wywoływane. Rejestr edx, zawierający wynik maskowania, jest przeszu- kiwany w celu detekcji oczekujących przerwań. Ustawiony bit w omawianym rejestrze powoduje wywołanie odpowiedniej procedury przerwania w jądrze Linuksa. Jeśli nie ma żadnych oczekujących przerwań, wykonywany jest bezpośredni powrót z przerwania. Instrukcja iret w procedurze obsługi przerwania, zamieniona przez RTLinuksa na S_IRET, spowoduje odnalezienie następnego oczekującego przerwania, aż do wyczer- pania całej listy. Wszystkie potencjalne przerwania, które mogą nadejść w czasie między poszukiwaniem oczekującego przerwania a jego wywołaniem, są opóźnione w wywołaniu co najwyżej do następnej instrukcji S_STI lub S_IRET. Zadania czasu rzeczywistego Zadania czasu rzeczywistego są zdefiniowanymi przez użytkownika programami, wykonywanymi pod kontrolą jądra czasu rzeczywistego. Zadania czasu rzeczywistego wprowadzone przez RTLinuksa znacznie różnią się od zwykłych procesów. Odmienność ta objawia się przede wszystkim prostotą i szybkością działania. Zadania RTLinuksa wykonują się we wspólnej przestrzeni adresowej (w przestrzeni jądra) z maksymalnym poziomem uprzywilejowania i bezpośrednim dostępem do urządzeń. Szeregowanie zadań na tym samym poziomie ochrony przy użyciu programowego sposobu przełączania kon- tekstu zadania daje wiele korzyści. Przełączanie kontekstu zadania jest proste i sprowadza się do zapamiętania i odtworzenia rejestrów procesora. Odpada narzut czasowy związany ze zmianą trybu uprzywilejowania procesora, który podczas przełączania z trybu syste- mowego do trybu użytkownika zajmuje kilkadziesiąt tiaktów procesora, podczas gdy inne Rozdział 2. ♦ RTLinux 19 instrukcje — poniżej dziesięciu taktów. Niebagatelny jest również czas zyskiwany przy zaniechaniu zmiany rejestru bazowego jednostki zarządzającej pamięcią i związanego z tym czyszczenia rejestrów asocjacyjnych procesora, czyli unieważnienia rejestrów związanych z TLB (ang. translation lookaside buffer). Rezygnacja z mechanizmu stro- nicowania i ochrony pamięci godzi niestety w integralność systemu. Każdy błąd w pro- gramie może mieć skutek w postaci zawieszenia całego systemu. Brak ochrony pamięci uniemożliwia wykorzystanie prostych mechanizmów śledzenia programów i znajdowania błędów. Z drugiej strony jednak wspólna przestrzeń adresowa pozwala zadaniom czasu rzeczywistego komunikować się i dzielić dane bezpośrednio (poprzez zmienne globalne) bez konieczności użycia złożonych technik komunikacji imiędzyprocesowej. W odróżnieniu od zwykłych procesów Linuksa, procesy czasu rzeczywistego są tzw. „procesami lekkimi” (ang. light-weight processes) lub „wątkami” (ang. threads) ze względu na szybkość i łatwość przełączania. Nie są jednak wątkami w rozumieniu takim, jak w systemach operacyjnych np. Solaris czy Windows NT. Najbardziej adekwatną nazwą dla tej kategorii procesów jest „zadanie”. Taka też nazwa będzie używana dla określenia procesów RTLinuksa. Dodatkowo jednak użycie pojęcia „wątek” w kontekście systemu RTLinux w dalszej części pracy również oznaczać będzie zadanie czasu rzeczywistego. Mechanizmem, na którym zasadza się cała idea procesów wykonywanych w przestrzeni jądra, jest mechanizm modułów ładowalnych, wykorzystywany w prawie każdej nowo- czesnej instalacji Linuksa. Technika ta, opcjonalna dla jądra Linuksa, jest krytyczna dla działania RTLinuksa, gdyż wsparcia dla modułów ładowalnych wymagają zarówno poszczególne moduły funkcjonalne tego systemu, jak i programy napisane przez użyt- kownika. Moduły stanowią „kawałki” jądra w postaci plików obiektowych (skompilowane, ale nieskonsolidowane), które mogą być zarówno dynamicznie linkowane i dołączane do rezydującej w pamięci części jądra podczas działania systemu (bez konieczności czaso- chłonnego restartu), jak i odłączane od jądra (również biez restartu). Szeregowanie zadań Planista (ang. scheduler) zajmujący się szeregowaniem zadań w systemie RTLinux stanowi odrębny moduł. Jedynym jego zadaniem jest planowanie przydziału procesora zadaniom według określonego algorytmu. Standardowo RTLinux używa algorytmu sze- regowania bazującego na stałych priorytetach zadań, w którym do wykonania wybierane jest zawsze gotowe zadanie o najwyższym priorytecie — Priority-Based Rate Monotonic Scheduling Algorithm (RMS). Jeśli istnieje kilka zadań o tym samym priorytecie, do wykonania wybierane jest to zadanie, które w kolejce zadań zostało odnalezione jako pierwsze. Zadaniom nie przydziela się „szczeliny czasowej”, tak jak to jest w systemach z podziałem czasu. Zakłada się, że zadanie samo odda procesor lub zostanie wywłasz- czone przez zadanie o wyższym priorytecie. W RTLinuksie nic nie stoi na przeszkodzie, aby zaimplementować inny, własny algorytm planowania zadań czasu rzeczywistego. Zmiana algorytmu szeregowania sprowadza się do wprowadzenia zmian w funkcji po- dejmującej decyzję: TVNAUEJGFWNG i ewentualnie w strukturze zadania, jeśli występuje taka potrzeba. 20 RTLinux — system czasu rzeczywistego W przeciwieństwie do innych znanych systemów operacyjnych, RTLinux nie buduje oddzielnej kolejki procesów gotowych, które czekają na przydział procesora. Wszyst- kie zadania tworzą jedną kolejkę. Stan konkretnego zadania zapisywany jest w jego strukturze. Od momentu, gdy RTLinux przystosowany został do działania z wykorzy- staniem symetrycznej wieloprocesorowości, dla każdego procesora tworzona jest od- rębna struktura TVNAUEJGFAERWAUVTWEV, zawierająca między innymi kolejkę procesów do wykonania na danym procesorze. Ważniejsze pola struktury TVNAUEJGFAERWAUVTWEV to:        UVTWEVTVNAVJTGCFAUVTWEV TVNAEWTTGPV — wskaźnik do aktualnie wykonywanego zadania; UVTWEVTVNAVJTGCFAUVTWEVTVNANKPWZAVCUM — struktura reprezentująca zadanie Linuksa; UVTWEVTVNAVJTGCFAUVTWEV TVNAVCUMAHRWAQYPGT — wskaźnik do struktury zadania obecnie zajmującego koprocesor; UVTWEVTVNAVJTGCFAUVTWEV TVNAVCUMU — kolejka zadań czasu rzeczywistego (jednokierunkowa lista struktur zadań czasu rzeczywiistego, zadanie Linuksa również istnieje w tej kolejce); UVTWEVTVNAVJTGCFAUVTWEV TVNAPGYAVCUMU — lista nowo utworzonych zadań, oczekujących na dodanie do kolejki TVNAVCUMU ENQEMKFAVENQEM — zegar używany przez jednostkę szeregującą do odmierzania czasu; KPVUEJGFAHNCIU — wewnętrzne flagi planisty, związane między innymii z odmierzaniem czasu. Struktura zadania TVNAVJTGCFAUVTWEV reprezentuje wszelkie dane potrzebne do zarzą- dzania, szeregowania i przełączania kontekstu. Zawiera ona między innymi następu- jące pola:       UVTWEVTVNAUEJGFARCTCOUEJGFARCTCO — określa atrybuty, według których zadanie jest szeregowane (np. priorytet); 46.A(27A 106 :6HRWATGIU — przechowuje kontekst (rejestry) koprocesora; KPVWUGUAHR — pole to wskazuje, czy dane zadanie używa koprocesora, czy też nie; jeśli zadanie nie korzysta z obliczeń zmiennoprzecinikowych, nie jest konieczne zapamiętywanie i odtwarzanie kontekstu koprocesora; KPV 27 — zawiera identyfikator procesora, do którego kolejki jest przydzielone zadanie; JTVKOGAVTGUWOGAVKOG — pole zawiera godzinę „budzenia” dla zadań okresowych; dla zadań nieokresowych ma wartość HRTIME_INFINITY; JTVKOGAVRGTKQF — niezerowa wartość w tym polu określa odstęp czasu pomiędzy kolejnymi wznowieniami zadania (zadanie periodyczne);i Rozdział 2. ♦ RTLinux 21    KPVGTTPQAXCN — służy do przechowywania numerów części błędów zaistniałych podczas działania zadania; KPVOCIKE — to pole służy jedynie do prostego sprawdzenia poprawności struktury zadania; jego wartość różna od stałej RTL_THREAD_MAGIC oznacza, że struktura zadania nie jest prawidłowa; TVNAUKIUGVAVRGPFKPI — zmienna ta przechowuje sygnały sterujące stanem zadania: RTL_SIGNAL_SUSPEND, RTL_SIGNAL_WAKEUP, RTL_SIGNAL_TIMER, RTL_SIGNAL_CANCEL, RTL_SIGNAL_READY;  TVNAUKIUGVAVDNQEMGF — przechowuje maskę aktywnych sygnałów. Schemat algorytmu szeregowania przy użyciu pseudokodu znajduje się na listingu 2.3. Listing 2.3. Algorytm szeregowania implementowany przez RTLinuksa TVNAUEJGFWNG ] HQT MCľF[RTQEGUTGCNVKOG Y[DKGT\IQVQY[RTQEGUQPCLY[ľU\[ORTKQT[VGEKG KH Y[DTCPQRTQEGU ] HQT MCľF[YUVT\[OCP[RTQEGUTGCNVKOGQY[ľU\[ORTKQT[VGEKGPKľRTKQXT[VGV Y[DTCPGIQRTQEGUW Y[DKGT\RTQEGUMVÎT[RQYKPKGPD[èY\PQYKQP[PCLYE\GħPKGL KH Y[DTCPQYUVT\[OCP[RTQEGU WUVCY\GICTPCE\CUDWF\GPKCRTQEGUW _ Y\PÎYY[DTCP[RTQEGU _ Wartości priorytetów zadań czasu rzeczywistego można ustalać na etapie ich tworzenia lub później, w trakcie ich działania. Wyższa wartość liczbowa oznacza wyższy priorytet. Prawidłowy zakres wartości priorytetów jest ustalany iprzez dwie funkcje:   UEJGFAIGVARTKQTKV[AOCZ KPVRQNKE[ — zwraca maksymalną wartość priorytetu; obecnie zwracana wartość jest stała i wynosi 1000000; UEJGFAIGVARTKQTKV[AOKP KPVRQNKE[ — zwraca minimalną wartość priorytetu; standardowo funkcja ta zwraca wartość 0 (zero). Priorytet szczególnego zadania, jakim jest Linux, nie mieści się w podanym zakresie. Jego priorytet, jak już zostało zaznaczone wcześniej,i jest najniższy i wynosi –1. Odmierzanie czasu Precyzyjne odmierzanie czasu jest bardzo ważne dla prawidłowego działania planisty i zadań czasu rzeczywistego. Pewne zadania potrzebują aktywowania w określonym mo- mencie czasu, oczekiwania na zdarzenie przez określony czas, bądź to uruchamiania co pewien okres. Niedokładność w odmierzaniu czasu powoduje odchylenia od zaplano- wanych terminów i jest zjawiskiem bardzo niekorzystnym. 22 RTLinux — system czasu rzeczywistego Powodem, dla którego w większości uniwersalnych systemów operacyjnych istnieją zegary o niskiej rozdzielczości, jest użycie okresowych przerwań od sprzętowego układu zegarowego. Niska rozdzielczość jest kompromisem pomiędzy dokładnością zegara a cza- sem spędzanym przez system na obsłudze przerwań zegarowych. W RTLinuksie zamiast generowania przerwań zegarowych (periodycznych) generowane są przerwania po upływie zadanego czasu (time-out). Programowalne kontrolery czasu w komputerach klasy PC używając takiego trybu pracy pozwalają na uzyskanie rozdzielczości czasu na pozio- mie 1 mikrosekundy. Dodatkowo taki sposób działania zapewnia znaczne ogranicze- nie kosztów stałych obsługi przerwań zegarowych. Korzyści z tego trybu pracy ilustruje przykład 2.1. W komputerach PC jest to programowalny układ czasowny Intel 8254. Przykład 2.1. Wykorzystanie przerwania po upływie o2kreślonego czasu Jeśli jedno zadanie musi być wykonywane co 331 jednostek czasu, a inne co 1 027 jed- nostek (brak jest dobrego wspólnego podzielnika), to w typowej obsłudze zegara trzeba zliczać poszczególne takty i inicjować zadanie po określonej liczbie taktów. W trybie programowania „na żądanie” (ang. one-shot mode) licznik czasowy jest najpierw progra- mowany na wygenerowanie przerwania po 331 jednostkach czasu, a następnie przepro- gramowany na następne przerwanie po 691 jednostkach (zakładając, że przeprogramo- wanie zegara trwa 5 jednostek czasu). Niestety, jak już wspomniano, czasochłonne programowanie zegara w jednoprocesoro- wych komputerach klasy PC ogranicza wartość minimalnego kwantu czasu do pojedyn- czych mikrosekund. W systemach wieloprocesorowych sytuacja jest znacznie korzyst- niejsza z powodu obecności układu regulatora czasowego wysokiej częstotliwości. Warto wspomnieć, że bardzo precyzyjnej techniki mierzenia upływu czasu dostarcza rodzina procesorów Pentium. Procesory takie i zgodne z nimi posiadają wbudowany licznik wysokiej rozdzielczości (ang. Time Stamp Counter), zerowany przy starcie procesora i zwiększany po każdym cyklu zegara taktującego. Ten licznik może być odczytywany przy użyciu specjalnej instrukcji RDTSC (Read Time Stamp Counter), która zwraca 64-bitową liczbę taktów procesora. Przepełnienie tego licznika jest praktycznie niemożliwe. Zakładając użycie procesora pracującego z częstotliwością 4 GHz, przepełnienie licznika nastąpi dopiero po ponad 146 latach nieprzerwanej pracy komputera. W obecnej chwili planista systemu RTLinux udostępnia dwa tryby działania zegara: okresowy (RTL_CLOCK_MODE_PERIODIC) i „na żądanie” (RTL_CLOCK_MODE_ ONESHOT). Okresowe przerwania o częstotliwości 100 Hz są emulowane dla jądra Linuksa. Realizowane jest to stosunkowo prosto: aby zainicjować przerwanie, ustawiany jest odpowiedni bit w zmiennej przechowującej informacje o przerwaniach oczekujących na obsługę. Przy następnym powrocie z dowolnego przerwania (makro S_IRET) lub przy „odblokowywaniu” przerwań (makro S_STI) procedura obsługi zegara w jądrze Linuksa zostanie wywołana. Rozdział 2. ♦ RTLinux 23 Komunikacja międzyprocesowa Główną zasadą RTLinuksa jest maksymalne uproszczenie i zminimalizowanie rozmiaru tej części aplikacji, która działa w czasie rzeczywistym. Oznacza to, że pierwotna aplikacja powinna być podzielona w taki sposób, że wszelkie operacje wymagające spełnienia ograniczeń czasowych i bezpośredniego dostępu do sprzętu wykonuje zadanie czasu rze- czywistego, zaś całą resztę działań (np. zapis danych na dysk, wizualizacja danych), które nie są z natury ograniczone czasowo, bierze na siebie zwykły proces wykonywany w prze- strzeni użytkownika. Konsekwencją takiej architektury jest konieczność zastosowania dodatkowych kanałów komunikacyjnych. Niestety, do komunikacji pomiędzy zadaniem czasu rzeczywistego i zwykłym procesem nie można wykorzystać (całkiem bogatego zbioru) mechanizmów komunikacji międzypro- cesowej, jakie oferuje standardowy Linux. Jego jądro może zostać wywłaszczone w do- wolnym momencie. Tak więc żadne wywołanie systemowe Linuksa zmieniające systemo- we struktury danych nie może być bezpiecznie użyte prziez zadanie czasu rzeczywistego. RTLinux sam dostarcza więc kilku mechanizmów komunikacji. Najważniejszymi są kolejki czasu rzeczywistego (ang. real-time FIFOs, RT-FIFOs) i pamięć dzielona. Do synchronizacji procesów czasu rzeczywistego oraz wzajemnego wykluczania system ten oferuje semafory i muteksy (omówione w podrozdziale „Mechanizmy synchronizacji międzyzadaniowej” w rozdziale 4.). Kolejki czasu rzeczywistego Kolejki czasu rzeczywistego (RT-FIFO) są buforami alokowanymi w przestrzeni jądra, które realizują algorytm „pierwszy przyszedł, pierwszy obsłużony” (First In First Out). Dla odróżnienia od zwykłych kolejek, będących standardowym mechanizmem IPC (ang. inter-process communication) Linuksa, kolejki czasu rzeczywistego będą nazywane RT-FIFO. Mogą być odczytywane i zapisywane zarówno przez procesy linuksowe, jak i zadania RTLinuksa. Kolejki RT-FIFO są jednokierunkowe: aplikacja nie może wyko- rzystywać tej samej kolejki do czytania i zapisywania jednocześnie. Do uzyskania dwu- kierunkowego połączenia należy użyć dwóch kolejek. Kolejki RT-FIFO są urządzeniami znakowymi o numerze głównym (ang. major number) 150. Są tworzone podczas instalacji RTLinuksa i istnieją w katalogu /dev/ jako urządzenia o nazwach /dev/rtf0, /dev/rtf1, i tak dalej, aż do /dev/rtfN, gdzie N (standardowo 64) oznacza maksymalną liczbę kolejek czasu rzeczywistego ustaloną podczas kompilacji systemu. Wymienione urządzenia są obsługiwane przez oisobne moduły RTLinuksa. Po stronie czasu rzeczywistego na interfejs kolejek RT-FIFO składają się operacje: tworzenie, niszczenie, czytanie i zapis kolejki. Odczyt i zapis są operacjami niepodziel- nymi i nieblokującymi. Dla zwykłych procesów Linuksa kolejki RT są widoczne jako zwykłe pliki o wspomnianych wyżej nazwach, dlatego do operowania na nich (wykony- wania operacji we/wy na plikach) może zostać użyte standardowe API (ang. Application Programing Interface). W najprostszym przypadku dostęp do kolejek RT-FIFO można zrealizować przy pomocy skryptu powłoki lub polecenia ijednowierszowego. 24 RTLinux — system czasu rzeczywistego Pamięć dzielona Pamięć dzielona może służyć do wymiany większych ilości danych pomiędzy zadaniem czasu rzeczywistego a zwykłym procesem. Jest to najszybszy sposób komunikacji pomię- dzy zadaniami, ze względu na prostotę i brak zaangażowania systemu w realizację tej techniki, nie uwzględniając oczywiście mechanizmu odwzorowywania pamięci i prze- chwytywania wyjątków. Używanie pamięci wspólnej pozwala wielu zadaniom korzystać z tych samych da- nych. Niestety, zapis do pamięci dzielonej wymaga postępowania według określone- go protokołu w celu zachowania integralności danych. W przeciwieństwie do kolejek, przy użyciu pamięci wspólnej możliwa jest wymiana danych w postaci struktur. Jedynym limitem rozmiaru pamięci dzielonej jest rozmiar fizycznej pamięci dostępnej w systemie komputerowym. Synchronizacja i wzajemne wykluczanie W każdym środowisku wielozadaniowym procesy mogą na siebie oddziaływać. W przy- padku korzystania ze wspólnej przestrzeni adresowej współbieżny dostęp do danych dzie- lonych może powodować ich niespójność. W celu zapewnienia wyłącznego dostępu do zasobu konieczne jest użycie pewnych mechanizmów wzajemnego wykluczania i syn- chronizacji. Dla systemów czasu rzeczywistego, oprócz zachowania integralności zasobu dzielonego i uniknięcia zakleszczeń, ważnym problemem jest minimalizacja inwersji priorytetów. Inwersja priorytetów oznacza fakt zajmowania zasobu dzielonego przez zadanie o niskim priorytecie, podczas gdy w systemie istnieje zadanie o wyższym priorytecie, oczekujące na dostęp do tego samego zasobu. Zakleszczenie (ang. deadlock) jest sytuacją, w której zbiór procesów czeka w nieskoń- czoność na zdarzenie, które może być spowodowane tylko przez jeden z oczekują- cych procesów. Przykład 2.2. Inwersja priorytetów Rozważmy dla przykładu dwa procesy okresowe, które chcą mieć wyłączny dostęp do pewnego logicznego zasobu. W systemie ze statycznym priorytetem zadań może dojść do sytuacji, gdzie niskopriorytetowy proces zarygluje (ang. lock) zasób i zostanie wywłasz- czony przez proces o wyższym priorytecie. Kiedy drugi proces będzie próbował uzyskać dostęp do zasobu, zostanie zablokowany. Jeśli w tym momencie pojawi się trzeci proces, o średnim priorytecie, wywłaszczy proces niskopriorytetowy i będzie się wykonywać kosztem procesu o najwyższym priorytecie. Ponieważ zadanie o średnim priorytecie wykonuje się, gdy istnieje zadanie o wyższym priorytecie, de facto priorytety zadań są odwrócone (ang. priority inversion). Rozdział 2. ♦ RTLinux 25 Dla uniknięcia takiego niekorzystnego zjawiska w literaturze [4, 22] poświęconej tej tematyce zostało zaproponowanych kilka modeli dostępu do zasobów dzielonych. Dla pokazania istoty problemu rozważmy dwa z nich, przy założeniu, że dla procesów (zadań) i zasobów prawdziwe są następujące stwierdzenia:     do procesów przypisane są statyczne priorytety, zasoby są dostępne w sposób wzajemnie wykluczający siię, używany jest scheduler planujący zadania na podstawie ich priorytetu (gdzie procesor dostaje gotowe zadanie o najwyższym piriorytecie), zasoby, do których proces ma dostęp, są znane z góry, iprzed uruchomieniem procesu. Najprostszą techniką dostępu do danych dzielonych wydaje się być protokół bazujący na dziedziczeniu priorytetów (ang. priority-inheritance protocol), w którym proces uży- wający zasobu potrzebnego procesowi o wysokim priorytecie dziedziczy jego priorytet dopóki, dopóty nie przestanie korzystać z zasobu będącego przedmiotem sporu. Po zwol- nieniu zasobu jego priorytet uzyskuje pierwotną wartość, zatem możliwość wywłaszczenia procesu niskopriorytetowego w jego sekcji krytycznej przez proces o średnim priorytecie zostaje wyeliminowana. Niestety, takie rozwiązanie niesie ze sobą poważne zagrożenia. Jeśli w rozważanym poprzednio przykładzie proces, który odziedziczył wysoki priorytet w sposób zagnieżdżony, zażąda dostępu do drugiego zasobu aktualnie używanego przez zablokowany proces o wysokim priorytecie, nastąpi zaikleszczenie (ang. impas). Ponieważ dziedziczenie priorytetów nie eliminuje niedopuszczalnego w systemach czasu rzeczywistego zakleszczenia procesów, twórcy systemu RTLinux nie stosują tego pro- tokołu w obiektach synchronizacji, służących do ochrony zasobów dzielonych. Z całkiem bogatej rodziny protokołów dostępu, bazujących na stałym priorytecie, RTLinux im- plementuje protokół CSP (ang. Ceiling Semaphore Protocol). Działanie protokołu opiera się na pojęciu pułapu priorytetu, przypisanego do zasobu. Pułap zasobu ma wartość równą najwyższemu priorytetowi spośród procesów, które mogą go zająć. Idea dzia- łania protokołu CSP polega na ustawianiu priorytetu procesu, który posiadł zasób, na wartość pułapu tego zasobu. Proces działa z priorytetem równym pułapowi zasobu aż do jego zwolnienia. Przykład 2.3. Działanie protokołu CSP Rozważmy dla przykładu procesy p1, p2 i p3 o relacji priorytetów p1 p2 p3, które próbują uzyskać wyłączny dostęp do zasobu R, jak na rysunku 2.2. Rysunek 2.2. Działanie protokołu Ceiling Semaphore Protocol [22] 26 RTLinux — system czasu rzeczywistego Rysunek 2.2 prezentuje następującą sekwencję zdarzeń, przy założeniu, że pułap zasobu R jest równy 1: t = 0: pojawia się p3 i wykonuje się; t = 1: p3 żąda i zajmuje zasób R, p3 dziedziczy pułap priorytetu równy 1; t = 2: pojawia się p2, lecz p3 wykonuje się dalej, jako proces o wyższym prioryteciie; t = 3: pojawia się p1, lecz dalej wykonuje się p3, ponieważ p1 nie ma wyższego priorytetu; t = 4: p3 kończy sekcję krytyczną zwalnia R i wraca do poprzedniego priorytetu; t = 5: wykonuje się p1; t = 6: p1 alokuje R ; t = 7: p1 kończy sekcją krytyczną, wykonuje się i kończy; t = 8: wykonuje się p2; t = 9: p2 zajmuje R; t =10: p2 kończy sekcję krytyczną, wykonuje się i kończy; t =11: p3 wykonuje się i kończy. Protokół CSP posiada kilka zalet:    Po pierwsze, protokół zabezpiecza przed wystąpieniem zaikleszczenia. Po drugie, unika częstego przełączania kontekstu — w iporównaniu z innymi protokołami ze swojej klasy. Trzecią zaletą jest zredukowana złożoność w trakcie wykonywania, protokół jest przejrzysty i przewidywalny. Wadą, jakiej można się dopatrzyć, jest zwiększony czas odpowiedzi, można to zauważyć w przykładzie 2.3. Jeśli proces p3 zajmie zasób R, jego priorytet zostanie podwyższony do pułapu R, w tym wypadku do 1. Wykonywanie procesu p2 zostanie zablokowane, nawet jeśli nie będzie oczekiwał na zwolnienie zasobu. Obecnie RTLinux dostarcza podstawowych mechanizmów synchronizacji i wzajemnego wykluczania w postaci semaforów i muteksów zgodnych z POSIX. Oprócz podstawowych operacji ryglowania (ang. lock) i zwalniania zasobu (ang. unlock) za pomocą semaforów możliwe jest również ryglowanie warunkowe. W takim wypadku przy wykonywaniu ope- racji „czekaj” na semaforze podawany jest limit czasu, przez jaki zadanie może czekać na podniesienie semafora. Muteksy (ang. mutex — mutual exclusion) mogą opcjonalnie zostać wyposażone w atrybuty pozwalające na realizację omawianego protokołu CSP przy dostępie do zasobów. Możliwość korzystania z tego protokołu jest ustalana przy kon- figuracji i instalacji RTLinuksa.
    Pobierz darmowy fragment (pdf)

    Gdzie kupić całą publikację:

    RTLinux - system czasu rzeczywistego
    Autor:
    , ,

    Opinie na temat publikacji:


    Inne popularne pozycje z tej kategorii:


    Czytaj również:


    Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: