Jak działają systemy operacyjne czasu rzeczywistego?

W RTOSes najważniejszymi parametrami, o które należy zadbać, są mniejsze opóźnienia i determinizm czasowy. Co przyjemnie robi, postępując zgodnie z określonymi zasadami i sztuczkami.

Podczas gdy w GPOs, wraz z akceptowalnymi opóźnieniami, parametrami krytycznymi jest wysoka przepustowość. nie można liczyć na determinizm czasu.

RTOSes mają zadania, które są znacznie lżejsze niż procesy / wątki w GPOS.

Nie chodzi o to, że są w stanie dotrzymać terminów, chodzi raczej o to, że mają ustalone terminy, podczas gdy w zwykłym systemie operacyjnym nie ma takiego terminu.

W zwykłym systemie operacyjnym Harmonogram zadań nie jest zbyt rygorystyczny. Oznacza to, że procesor wykonuje tak wiele instrukcji na sekundę, ale czasami może tego nie robić. Na przykład zadanie może być poprzedzone, aby umożliwić wykonanie zadania o wyższym priorytecie (i może trwać dłużej). W RTO procesor zawsze wykona taką samą liczbę zadania.

DODATKOWO zazwyczaj istnieje limit czasu do wykonania zadań, po którym zgłaszana jest awaria. Nie dzieje się to w zwykłym systemie operacyjnym.

Oczywiście jest o wiele więcej szczegółów do wyjaśnienia, ale powyższe są dwoma ważnymi aspektami projektowania, które są używane w RTO.

Twój RTO jest zaprojektowany w taki sposób, że może zagwarantować czas ważnych wydarzeń, takich jak obsługa przerw sprzętowych i budzenie procesów uśpienia dokładnie wtedy, gdy muszą być.

Ten dokładny czas pozwala programiście mieć pewność, że jego (powiedzmy) rozrusznik wypuści impuls dokładnie wtedy, gdy będzie musiał, a nie kilkadziesiąt milisekund później, ponieważ system operacyjny był zajęty innym nieefektywnym zadaniem.

Jest to zwykle dużo prostszy OS niż pełnoprawny Linux lub Windows, po prostu dlatego, że łatwiej jest analizować i przewidywać zachowanie prostego kodu. Nic nie stoi na przeszkodzie, aby pełnoprawny system operacyjny, taki jak Linux, był używany w środowisku RTOS i ma rozszerzenia RTOS. Ze względu na złożoność bazy kodu nie będzie w stanie zagwarantować tak małej skali, jak mniejszy SYSTEM OPERACYJNY.

Harmonogram RTOS jest również bardziej rygorystyczny niż harmonogram ogólnego przeznaczenia. Ważne jest, aby wiedzieć, że harmonogram nie zmieni Twojego zadania priorytet, ponieważ działasz od dawna i nie masz żadnych interaktywnych użytkowników. Większość systemów operacyjnych zmniejszyłaby wewnętrzny priorytet tego typu procesu, aby faworyzować krótkoterminowe interaktywne programy, w których interfejs nie powinien być postrzegany jako opóźniony.

Pomocne może okazać się odczytanie źródła typowego RTO. Istnieje kilka przykładów open-source, a następujące linki przyniosły trochę szybkiego wyszukiwania:

• FreeRTOS
• eCos

Komercyjny RTO, który jest dobrze udokumentowany, dostępny w postaci kodu źródłowego i łatwy w obsłudze to µC/OS-II . Ma bardzo liberalną licencję do użytku edukacyjnego, a (lekko Nieaktualna wersja) jego źródłem może być związał się z książką opisującą swoją teorię działania z wykorzystaniem rzeczywistej implementacji jako przykładowego kodu. Książka jest MicroC OS II: jądro czasu rzeczywistego autor: Jean Labrosse

Używałem µC / OS-II w kilku projektach na przestrzeni lat i mogę go polecić.

Nie używałem RTOS, ale myślę, że tak to działa.

• Jako aplikacja mogę mieć wątek lub timer, który PROSZĘ O/S, aby działał 10 razy na sekundę ... i może O / S zrobi to, przez większość czasu, ale nie ma gwarancji, że zawsze będzie w stanie ... ten brak gwarancji jest dlaczego nazywa się to "miękkim". Powodem, dla którego O / S może nie być w stanie jest to, że inny wątek może być utrzymanie system zajęty robi coś innego. Jako aplikacja, mogę zwiększyć mój priorytet wątku na przykład HIGH_PRIORITY_CLASS, ale nawet jeśli to zrobię, O / S nadal nie ma API, którego mogę użyć do żądania gwarancji , że będę uruchamiany w określonych godzinach.

• "twardy" O/S w czasie rzeczywistym ma (wyobrażam sobie) interfejsy API, które pozwalają mi żądać gwarantowanych plastrów wykonania. Powód, dla którego RTO może dać takie gwarancje, że jest gotów abendować wątki, które zajmują więcej czasu niż oczekiwano / niż są dozwolone.

Ważne są aplikacje w czasie rzeczywistym, a nie SYSTEM OPERACYJNY w czasie rzeczywistym. Zazwyczaj aplikacje w czasie rzeczywistym są przewidywalne: wiele testów, inspekcji, analiza WCET, dowody,... zostały wykonane, które pokazują, że terminy są przestrzegane w określonych sytuacjach.

Zdarza się, że RTOSes pomaga w tej pracy (budowanie aplikacji i weryfikowanie jej ograniczeń RT). Ale widziałem aplikacje działające w czasie rzeczywistym na standardowym Linuksie, polegające bardziej na sprzęcie niż na projektowaniu systemu operacyjnego.

... cóż ...

System operacyjny czasu rzeczywistego stara się być deterministyczny i dotrzymywać terminów, ale wszystko zależy od sposobu pisania aplikacji. Możesz zrobić RTO bardzo Nie w czasie rzeczywistym, jeśli nie wiesz, jak napisać "właściwy" kod.

Nawet jeśli wiesz jak napisać właściwy kod: Chodzi bardziej o bycie deterministycznym niż szybkim.

Kiedy mówimy o determinizmie to

1) determinizm zdarzeń

Dla każdego zestawu wejść kolejne stany i wyjścia systemu są znane

2) determinizm czasowy

... znany jest również czas reakcji dla każdego zestawu wyjść

Oznacza to, że jeśli masz zdarzenia asynchroniczne, takie jak przerwania, Twój system nie jest ściśle mówiąc deterministyczny. (i większość systemów używa przerwań)

Jeśli naprawdę chcesz być deterministyczny przepytaj wszystko.

... ale może nie trzeba być w 100% deterministycznym

Odpowiedź podręcznika / wywiadu brzmi "deterministyczne uprzedzenie". System ma gwarancję przeniesienia kontroli w ograniczonym okresie czasu, jeśli proces o wyższym priorytecie jest gotowy do uruchomienia (w kolejce gotowości) lub zostanie stwierdzone przerwanie (zazwyczaj wejście zewnętrzne do CPU/MCU).

W rzeczywistości nie gwarantują dotrzymania terminów; to, co robią, to zapewnienie środków do rozpoznawania przekroczeń terminów i radzenia sobie z nimi. "Twarde" systemy RT to zazwyczaj te, w których brak terminu jest katastrofalny i wymagane jest pewne wyłączenie, podczas gdy "miękkie" systemy RT to takie, w których kontynuowanie pogorszonej funkcjonalności ma sens. Tak czy inaczej RTO pozwala zdefiniować odpowiedzi na takie przekroczenia. Systemy Non RT nie wykrywają nawet przekroczeń.

"zasadniczo musisz zakodować każde" zadanie " w RTO tak, aby zakończyło się w skończonym czasie."

To jest rzeczywiście poprawne. RTO będzie miało zaznaczenie systemowe zdefiniowane przez architekturę, powiedzmy 10 milisekund., ze wszystkimi zadaniami (wątkami) zaprojektowanymi i zmierzonymi do wykonania w określonym czasie. Na przykład w przetwarzaniu danych audio w czasie rzeczywistym, gdzie częstotliwość próbkowania dźwięku wynosi 48 kHz, istnieje znana ilość czasu (w milisekundach), w którym prebuffer stanie się pusty dla każde kolejne zadanie, którym jest przetwarzanie danych. Dlatego korzystanie z RTO wymaga poprawnego doboru buforów, oszacowania i pomiaru czasu, a także pomiaru opóźnień między wszystkimi warstwami oprogramowania w systemie. Wtedy terminy mogą być spełnione. W przeciwnym razie wnioski nie dotrzymają terminów. Wymaga to analizy najgorszego przypadku przetwarzania danych w całym stosie, a gdy najgorszy przypadek jest znany, system może być zaprojektowany na powiedzmy 95% czasu przetwarzania przy 5% bezczynności (przetwarzanie To może nigdy nie wystąpić w jakimkolwiek rzeczywistym użyciu, ponieważ w najgorszym przypadku przetwarzanie danych może nie być dozwolonym stanem we wszystkich warstwach w dowolnym momencie).

Przykładowe diagramy czasowe do projektowania aplikacji sieciowej systemu operacyjnego w czasie rzeczywistym są w tym artykule w EE Times, instrukcje dotyczące produktu: poprawa jakości głosu w czasie rzeczywistym w telefonii VoIP design http://www.eetimes.com/design/embedded/4007619/PRODUCT-HOW-TO-Improving-real-time-voice-quality-in-a-VoIP-based-telephony-design

Zasadniczo musisz zakodować każde" zadanie " w RTO tak, aby zakończyło się w skończonym czasie.

DODATKOWO twoje jądro przeznaczyłoby określone ilości czasu na każde zadanie, próbując zagwarantować, że pewne rzeczy wydarzyły się w określonym czasie.

Zauważ, że nie jest to jednak łatwe zadanie. Wyobraź sobie takie rzeczy jak wirtualne wywołania funkcji, w OO bardzo trudno jest określić te rzeczy. Również RTO muszą być starannie zakodowane w odniesieniu do priorytetu, to może wymagać, aby zadanie o wysokim priorytecie zostało przydzielone procesorowi w ciągu milisekund x, co może być trudne do wykonania w zależności od sposobu działania harmonogramu.