Piotr Nikiel – Wbudowane systemy operacyjne w sterowaniu

Piotr Nikiel1 – V rok
Koło Naukowe Informatyków
prof. dr hab. inż. Piotr Malecki, dr inż. Tomasz Gąciarz - opiekunowie naukowi
OPERATING SYSTEMS IN CONTROL OF MODELS AND ROBOTS
SYSTEMY OPERACYJNE W STEROWANIU MODELI I ROBOTÓW
Keywords: embedded operating system, realtime operating system, robotic control,
microcontrollers
Słowa kluczowe: wbudowane systemy operacyjne, systemy operacyjne czasu rzeczywistego,
sterowanie robotami, mikrokontrolery
The paper presents an operating system approach to microcontroller software
development. The operating system was developed by author of the paper, and is closely
related to author’s thesis: “A design of realtime operating system and its implementation on
a chosen microcontroller” (advisor: prof. Piotr Malecki). Special attention is paid to
advantages and disadvantages of the approach and to characteristics of the operating
system. An illustration to the approach is given by presenting a mechatronic system - a
flying model - whose software is based on the operating system.
1. Wprowadzenie
Mikrokontrolery
są
najbardziej
rozpowszechnionym
owocem
techniki
mikroprocesorowej. Przeważnie stosuje się je w układach sterowania, ale spotyka się także
inne zastosowania jak np. tzw. “tłumaczenie interfejsów”, obsługa czujników czy prosty
sposób realizacji (przeważnie nieskomplikowanych) systemów cyfrowych. O ile stworzenie
programu sterującego jedną czynnością, z niewielką ilością badanych wejść systemu jest na
ogół proste, o tyle budowa bardziej zaawansowanych systemów stawia programistę przed
coraz większymi trudnościami. W szczególności wraz ze wzrostem liczby procesów, które
muszą działać współbieżnie, znacząco wztasta poziom trudności realizacji oprogramowania.
Oprócz tego nieuniknione stają się trudności w zapewnieniu wymagań czasowych systemu
czy problemy wynikające ze współdzielenia pewnych elementów mikrokontrolera przez
różne procesy. System operacyjny wprowadza pewną warstwę abstrakcji i znacząco
upraszcza oprogramowanie.
Za tą argumentacją dodatkowo przemawia fakt, że współczesne rodziny
mikrokontrolerów są często wyposażone w wyjątkowo bogate i liczne układy peryferyjne.
Na przykład układ ATmega2561 firmy Atmel, będący jednym z największych
mikrokontrolerów
rodziny
AVR,
posiada:
6
rozbudowanych
układów
liczników/czasomierzy, 10 kanałów wyjścia cyfrowego PWM, ośmiokanałowy przetwornik
analogowo-cyfrowy, dwa porty szeregowe, magistralę SPI, magistralę I2C, układ
watchdoga, komparator analogowy, system przerwań zewnętrznych i 54 programowalne
linie wejścia-wyjścia cyfrowego. Oprogramowanie umożliwiające wydajne i równoległe
w czasie wykorzystanie choćby większości z wymienionych układów peryferyjnych jest
wyjątkowo trudne w realizacji.
Podejmując decyzję o zastosowaniu systemu operacyjnego należy również mieć
świadomość o wadach takiego podejścia. Na przykład praktycznie pewne jest, że
w przypadku systemu z jednym procesem wydajność obliczeniowa będzie niższa, niż bez
1
Adres e-mail autora: [email protected] lub [email protected]
zastosowania systemu operacyjnego. Ponadto trudno podać jakikolwiek zysk, który mógłby
zostać osiągnięty przy jednym procesie wraz z zastosowaniem tego rodzaju
oprogramowania.
Do znanych i ogólnie dostępnych systemów operacyjnych o profilu wbudowanym
należą m.in. uC/OS-II, FreeRTOS czy eCos. Ponadto istnieje wiele tego typu systemów,
które wymagają bardzo słonych opłat licencyjnych. W zamian otrzymuje się produkt
certyfikowany i dokładnie przetestowany, nadający się do zastosowań o najwyższych
wymaganiach niezawodności.
Wymienione systemy są dostępne w wersjach na różne rdzenie mikrokontrolerów
i mikroprocesorów. Łatwo można dostrzec szczególnie wysoką popularność wersji (czy też
tzw. “portów”) dla układów z rdzeniem ARM. Wynika to niewątpliwie z wyjątkowo
wysokiej wydajności obliczeniowej charakteryzującej ten rodzaj rdzenia.
Opisywany w tym referacie system operacyjny, będący dziełem autora referatu, jest
dostępny dla układów z rdzeniem AVR. Został przetestowany na układach ATmega16,
ATmega32, ATmega128 i ATmega2561.
2. Wbudowany system operacyjny
2.1. Ogólna charakterystyka wbudowanych systemów operacyjnych
Ze względu na potrzebę realizowania wielu czynności współbieżnie, wygodnie jest
oddzielić logicznie oprogramowanie tych czynności od siebie. Każdą taką niezależną
jednostkę nazywa się wtedy zadaniem lub procesem (pojęcia te są używane zamiennie).
Wielozadaniowy system operacyjny dostarcza podstaw do wygodnego sterowania pewną
liczbą zadań, włączając w to funkcjonalność wzajemnej synchronizacji i współpracy zadań.
Do sterowania procesami fizycznymi potrzebne jest oprogramowanie przewidywalne
w dziedzinie czasu i umożliwiające różne formy synchronizacji z czasem rzeczywistym.
W szczególności należy oczekiwać, że system operacyjny zapewni funkcje okresowego
wykonywania pewnych czynności oraz odmierzania odcinków czasu z wystarczającą
dokładnością.
Kluczową rolę w takim systemie operacyjnym pełni program szeregujący, częściej
nazywany schedulerem. Program szeregujący jest odpowiedzialny za wybór zadania, które
procesor otrzyma do wykonania i podejmuje ten wybór w zależności od różnych czynników
lub kryteriów. Istnieje wiele typowych strategii szeregowania, od najprostszych: FCFS
(ang. First Come, First Served - obsługuj zdarzenia w kolejności ich napływu) czy EDF
(ang. Earliest Deadline First - najpierw obsłuż zdarzenie z najkrótszym czasem
krytycznym) przez szeregowanie oparte na priorytetach, po bardzo skomplikowane
algorytmy biorące wiele różnych kryteriów pod uwagę. Różne strategie szeregowania zadań
będą skutkowały różnymi osiągami, np. średnim czasem oczekiwania na obsługę zdarzenia
czy wręcz możliwością (lub brakiem możliwości) nazwania oprogramowania systemem
czasu rzeczywistego.
System operacyjny powinien udostępniać pewien zestaw standardowych funkcji
i mechanizmów oraz interfejs programowania (ang. API - application programming
interface), który precyzyjnie określa sposób korzystania z nich. Do typowych mechanizmów
i podsystemów oferowanych przez system operacyjny zalicza się: zarządzanie pamięcią,
system plików, stos protokołów sieciowych, podsystem dostępu do niskich warstw sprzętu,
komunikację i synchronizację zadań (ang. IPC - interprocess communication), rozszerzenia
czasu rzeczywistego itp.
2.2. Szczegółowa charakterystyka zastosowanego systemu operacyjnego
Zastosowany system operacyjny został stworzony dla “większych” mikrokontrolerów
rodziny AVR (tj. na przykład serii ATmega). System można scharakteryzować następująco:
wielozadaniowy,
z zadaniami
definiowanymi
jako
funkcje
• system
języka C (podobnie do definiowania wątków w bibliotece pthread znanej z systemów
Unix). Jest możliwe tworzenia nowych zadań w trakcie pracy systemu (maksymalna
liczba zadań jest określona stałą kompilacji).
• system z mocnym szeregowaniem priorytetowym (dla danego priorytetu może być
przypisane tylko jedno zadanie) oraz z możliwością dynamicznej zmiany priorytetów.
• dostępny podsystem czasomierzy, umożliwiający realizację okresowych
i jednorazowych zdarzeń czasowych bez potrzeby tzw. aktywnego czekania (ang. busy
wait), tzn. zadanie czekające na zdarzenie czasowe przekazuje procesor innemu, mniej
uprzywilejowanemu zadaniu. System czasomierzy wymaga jednego z dostępnych
czasomierzy mikrokontrolera, w zamian oferując współbieżną realizację kilkunastu
zdarzeń czasowych.
• dostępne mechanizmy IPC: semafory binarne i przesyłanie wiadomości (oczekiwanie
na semafor lub na wiadomość nie wymaga aktywnego czekania)
• dostępne kolejki FIFO (które wykorzystywane są m.in. w strumieniu wyjściowym
portu szeregowego)
• dostępna prosta warstwa sieciowa, koncepcyjnie zbliżona do transmisji danych przez
protokół UDP/IP. Oprogramowanie warstwy posiada sterownik jednego z powszechnie
dostępnych układów transmisji bezprzewodowej.
• dostępne logowanie zdarzeń z interfejsem wyjściowym do specjalizowanego
urządzenia pełniącego funkcję “czarnej skrzynki”. Możliwe jest zlecenie jądru systemu
śledzenie i zapis przełączeń kontekstu, operacji na semaforach czy też jakichkolwiek
innych informacji potrzebnych do zalogowania razem z czasem ich wystąpienia.
• dostępne mechanizmy zabezpieczeń, np. system “ramcheck” śledzący ewentualne
przepełnienia buforów lub mogący wykryć błędy zewnętrznej szyny pamięci RAM.
• konfigurowalność (modularność): można wybrać tylko te elementy jądra systemu,
które istotnie są programiści potrzebne (w najprostszej wersji można pozostać przy
programie szeregującym bez podsystemów czasomierzy, semaforów, kolejek FIFO itp.).
• czas przełączenia zadań: ok. 30 µs przy zegarze systemowym 8 MHz (układy AVR są
dostępne z zegarami do 20 MHz - czas ten będzie odwrotnie proporcjonalny do
częstotliwości zegara, czyli przy 20 MHz będzie wynosił 12 µs).
• wykorzystanie pamięci RAM: system wymaga średnio 15 bajtów pamięci RAM na
struktury systemowe każdego zadania oraz pewną ilość pamięci na jego stos (przy
mniejszych zadaniach orientacyjnie może być to ok. 60 - 80 bajtów pamięci, zaś zadania
z duża ilością zmiennych lokalnych i wywołań procedur mogą wymagać nawet 200 lub
więcej bajtów). Do tej ilości pamięci należy doliczyć pewną ilość stałą dla systemu (np.
na bufor portu UART, itp.) która zależy od konfiguracji systemu. Dla odniesienia warto
podać, że mikrokontroler ATmega128 - jeden z największych w rodzinie AVR - posiada
4 kB pamięci RAM (można sprzętowo rozszerzyć pamięć RAM do 64 kB, ale z wielu
powodów nie zawsze będzie to zalecane).
Z systemem operacyjnym dostarczony jest skrypt do utworzenia obrazu pamięci
programu mikrokontrolera. Skrypt ten kompiluje źródła jądra systemu oraz źródła
programów użytkownika (w których zdefiniowane są zadania) i przygotowuje plik gotowy
do zaprogramowania pamięci Flash procesora.
3. Przykładowy system mechatroniczny i jego oprogramowanie
3.1. Część mechaniczna i elektroniczna
Prezentowany system można skrótowo określić “skomputeryzowanym modelem
latającym pionowego startu o napędzie elektrycznym czterosilnikowym”. Pierwotna
koncepcja konstrukcji takiego modelu została wymyślona przez autora niniejszej pracy
w 2005 roku. Po zapoznaniu się z różnymi dokonaniami miłośników modelarstwa
lotniczego okazało się, że taki rodzaj modelu - mimo, że stosunkowo mało popularny - jest
stosowany i najczęściej określa się go literą X (np. w języku angielskim: “RC X” - remote
controlled X).
Model posiada cztery silniki, których osie umieszczone są pionowo w normalnym
(roboczym) położeniu i zakończone śmigłami. Silniki są mocowane do konstrukcji na
czterech krawędziach krzyża greckiego, symetrycznie - stąd pochodzi symbol konstrukcji
X. Silniki naprzeciwległe obracają się w przeciwnych kierunkach, aby zneutralizować
wypadkowy moment obrotowy odczuwany przez konstrukcję modelu (brak zrównoważenia
spowodowałby obrót wokół własnej osi symetrii). Śmigła na przeciwległych silnikach są
przeciwskrętne (tj. prawoskrętne i lewoskrętne) - dzięki temu, mimo przeciwnych
kierunków obrotu, wszystkie 4 silniki generują użyteczny ciąg o zwrocie przeciwnym do
siły ciążenia.
Rysunek modelu w widoku “od góry” znajduje się na rys. 1. Na płycie CD załączonej
do opracowania znajdują się kolorowe zdjęcia opisywanego modelu.
Silniki zamontowane w modelu to silniki modelarskie firmy Graupner, typ Speed 400.
Są to silniki szczotkowe prądu stałego, nominalnie 7,2 V. Każdy silnik może pobierać
znaczny prąd, ponad 10 A. Pod komputerem pokładowym (zaznaczonym na rysunku)
znajduje się płytka mocy z sterownikami tych silników zrealizowanymi z użyciem
tranzystorów MOSFET.
Za zasilanie modelu odpowiada akumulator w technologii litowo-polimerowej. Posiada
on nominalne napięcie 7,4 V, pojemność 2100 mAh oraz dopuszczalny ciągły prąd
rozładowania 63 A. Energia akumulatora, oprócz zasilania silników, jest przetwarzana
impulsowo na napięcie 5 V (do zasilania komputera), 4 V (do zasilania oświetlenia) i 12 V
(do wielu zastosowań). Ponadto na płytce mocy znajduje się przetwornik A/C monitorujący
napięcie akumulatora.
Komputer pokładowy jest oparty na mikrokontrolerze ATmega2561. Mikrokontroler
jest połączony z następującymi obwodami i układami:
• 2 czujnikami przyspieszenia typu MXR7202 (przez 4 kanały przetwornika A/C)
• magistralą 1-wire (na której znajduje się przetwornik A/C mierzący napięcie
akumulatora)
• sterownikiem silników, za pomocą wyjść cyfrowych PWM
• portem szeregowym RS-232
• modemem bezprzewodowym (moduł RXQ21 firmy Telecontrolli) za pomocą
drugiego portu szeregowego i linii pomocniczych
• interfejsem “czarnej skrzynki”
• szeregiem wyjść cyfrowych załączających oświetlenie lub “klakson”
• interfejsem programowania
• magistralą I2C (na której znajduje się sensor temperatury)
Rysunek 1. Model widziany z góry. Miejsca oznaczone cyframi: 1- listwy z włókna węglowego
o przekroju 2x12 mm, 2- komputer pokładowy, pod nim znajdują się (niewidoczne na rysunku): płytka
mocy (ze sterownikiem silników) oraz akumulator, 3- rurki aluminiowe (pomocnicze), 4- silniki (pod
płaszczyzną rysunku) wraz ze śmigłami (nad płaszczyzną).
3.1. Oprogramowanie
W systemie działa równolegle kilka procesów (zrealizowanych jako zadania systemu
operacyjnego). W kolejności od najbardziej istotnego są to:
• fcontrold - odpowiada za analizę położenia robota i wyliczanie trajektorii ruchu oraz
wysyłanie stosownych przebiegów do sterownika silników. Odbiera od operatora
polecenia ruchu modelu (wznieś się, leć na wprost, itp.)
• adc - dokonuje pomiarów różnych wielkości za pomocą przetwornika A/C. Do
szczególnie istotnych mierzonych wielkości należą pomiary czujników przyspieszenia,
które są podstawowym żródłem informacji o ruchu i połoźeniu modelu.
• net - jest serwerem usług sieciowych, odpowiada za komunikację bezprzewodową
• fstatd - wysyła informacje o bieżącym położeniu, wychyleniu itp. przez interfejs
sieciowy do komputera operatora robota
• powerd - mierzy napięcie akumulatora oraz wygenerowane impulsowo napięcia,
w razie wyczerpania baterii wyłącza robota, a także odsyła pomiary do operatora
• scontrold - odbiera od operatora niekrytyczne polecenia nt. oświetlenia robota
itp. i realizuje je
• sstatd - wysyła niekrytyczne informacje (stan różnych elementów robota) do
operatora
• lights - steruje oświetleniem robota generując interesujące efekty wizualne
• ramcheck - nadzoruje pamięć RAM, ewentualne nadpisania buforów, itp.
• idle, init - są procesami systemowymi o znaczeniu podobnym do systemu Unix
Od strony funkcjonalnej oprogramowanie działa bardzo dobrze, wszystkie zastosowane
mechanizmy systemu operacyjnego funkcjonują zgodnie z oczekiwaniami. Nie mniej można
było zauważyć okresowe błędy transmisji magistralą 1-wire, której przebiegi realizowane
są programowo, z poziomu jednego z zadań w systemie (mikrokontrolery AVR nie
posiadają peryferyjnego układu magistrali 1-wire). Analiza przypadku prowadzi do
orzeczenia, że opóźnienie realizowane w jednym z zadań jest za krótkie jak na wybraną
częstotliwość zegara mikrokontrolera (potrzebne jest opóźnienie rzędu 60 - 90 µs, podczas
gdy czas przełączenia zadania wynosi około 30 µs, przy wybranej częstotliwości zegarowej
8 MHz).
Do sprawnego sterowania robota zostało utworzone oprogramowanie dla komputera
stacjonarnego lub przenośnego pozwalające na odbiór informacji wysyłanych przez
komputer pokładowy oraz wysyłanie komend do komputera pokładowego.
4. Wnioski
Zastosowanie
systemu
operacyjnego
pozwoliło
stworzyć
bardzo
przejrzyste i przewidywalne oprogramowanie, charakteryzujące się łatwością rozbudowy,
przy dużej równoległości kilku procesów i niełatwych wymaganiach. Rozbudowa
oprogramowania mikrokontrolerów jest najczęściej trudna, zwłaszcza przy wykorzystaniu
dużej ilości powiązanych ze sobą układów peryferyjnych.
Wysiłek włożony w projekt i implementację systemu operacyjnego jest wartościowy,
ponieważ takie oprogramowanie można wykorzystać w wielu różnych projektach
oprogramowania, tworząc od początku jedynie nowe, stosowne do potrzeb, zadania systemu
operacyjnego.