Witam!
Ostatnio zacząłem zajmować się RTOSami dla układów embedded, ogólnie tak dla rozwinięcia umiejętności bo na co dzień zajmuje się również systemami czasu rzeczywistego ale programuje je "bare matal". Czyli programowanie np. ARMa bez jakiegoś OSa.
Ogólnie punktem zapalnym dla rozpoczęcia nauki była pewna dyskusja z osobą która na co dzień bawi się RTOSami i mi zachwalała, jaki to RTOS nie jest wspaniały uniwersalny i prosty.
No i właśnie, po paru godzinach przesiedzianych nad artykułami z EP oraz nad tutkiem od FreeRTOS (klik), stwierdzam: że RTOS to w sumie nie jest takim super narzędziem (z tym, że mogę się strasznie mylić bo temat znam jak pisałem od kilku godzin
).
Ale do rzeczy, moje główne pytanie brzmi: Jaki uzysk daje używanie RTOS zamiast programowania "bare metal" pod C.
No i właśnie, teraz postaram się zaargumentować dlaczego tak sądzę.
No bo popatrzcie, wszyscy się cieszą że RTOS taki super, bo mamy wywłaszczenia, i się przerywają wątki i w ogóle możemy upakować procesy a scheduler sam się zajmie tym co i kiedy wywołać.
Tylko kurczę, przecież normalnie też możemy sobie takie coś zrobić ustawiając np. dla timerów (czy innych przerwań) konkretne priorytety i mieć ich nawet 30. I mieć taki 30 poziomowy program, a proces szumnie nazwany Idle Task to przecież nic innego jak program wykonywany w pętli gdzie jest najniższy poziom przerwań.
Więc ja osobiście, wolę sobie wywołać timer z jakąś częstotliwością (i odpowiednim priorytetem) i mieć to czarno na białym(oczywiście wykonywać jakiś kod w tym timerze). Nie widzę tutaj jakiegoś uzysku. Pracy jest więcej o może kilka linijek kodu (jednokrotny init timera).
Następna sprawa, tak szumnie nazywanie normalnych flag synchronizacyjnych muteksami i semaforami. No przecież to się w "tradycyjnych" systemach rozwiązuje zwyczajną flagą (tudzież kilkoma flagami) synchronizacyjną.
Dalej:
Kolega ten argumentował mi, że kompletnie olewam warstwę sprzętową bo do tego są już biblioteki, ja piszę tylko warstwę aplikacyjną. No i właśnie nie do końca. Bo w RTOSach dla jakichś konkretnych uC to znalazłem jedynie jakieś najprostsze API jak np. ustawienie pinów 1/0. O czymś takim jak np. proste funkcje (ale sprawdzone na 100%, najlepiej od producenta) do przesyłania po SPI to można zapomnieć. A więc skoro trzeba je pisać samemu, to argument o pisaniu samej aplikacji odpada.
A więc co tak ludzi i cały przemysł embedded przyciąga tak o RTOS? Bo ja szczerze powiedziawszy nie rozumiem.
Rozpatrzmy taki przykład z "Elektroniki Praktycznej" (7/2009). Autorem jest Krzysztof Paprocki.
No i autor przygotował taki kod do obsługi tego zadania:
No i OK. Autor tutaj użył 2 tasków i mutexa...wszystko cacy. Ale przecież równie dobrze można sobie uruchomić timer który będzie odliczał czas tych 500ms, i będę sprawdzał sobie i dwóch różnych miejscach kodu (gdy wywołuje funkcje odpowiedzialną za wpisanie do PWM) i ten czas minął (oczywiście będę go zerował po każdym użyciu i oczywiście pod wpływem flagi synchronizacyjnej będę decydował czy to w ogóle liczyć...pewnie wiecie o co chodzi więc nie ma się co rozpisywać).
Ale spójrzcie, mój kod będzie lżejszy i troszkę szybszy (bo scheduler mi się nie wcina). Nie będzie też jakiś cięższy do analizy czy napisania go.
I tak podsumowując:
Plusy i minusy
+ Faktycznie wygodniej czeka się na coś w wątkach. Po prostu ustawiam sobie czas który ma upłynąć (uzależniam się od cykli zegara) i zapominam o temacie. Nie muszę używać do tego dodatkowego timera.
+ MOŻE troszkę bardziej uporządkowany kod (ale pisząc rozsądnie "tradycyjnie", to kod też nie jest jakimś wielkim burdelem)
- Trzeba zaimplementować OSa co zajmuje czas i miejsce w procku. Dodatkowo czas na naukę nowego OSa.
- Biorąc po uwagę że nie ma wszystkich funkcji API do obsługi sprzętu (typu proste funkcje transmisyjne) to upada argument o pisaniu tylko aplikacji. Tu i tu trzeba pisać funkcje do obsługi sprzętu.
Mam wrażenie że implementacja RTOSów dla embedded, to po prostu wymysł ludzi, którzy całe życie programowali na PC i gdy musieli się przenieść na embedded to nie ogarnęli tematu do końca (i OK, bo w sumie dla nich wszystko się dzieje równolegle) to na siłę zaczęli implementować RTOSy. I tak już zostało.
Bo na prawdę, jak się staram, to nie mogę znaleźć na prawdę znaczącej przewagi nad programowaniem tzw. "bare metal".
A więc powtarzam moje pytanie do bardziej doświadczonych kolegów: Jaki uzysk daje używanie RTOS zamiast programowania "bare metal" pod C. Co w nim jest takiego, że w sumie cały przemysł teraz już pracuje tylko pod RTOSami?
Zaznaczam, że bardzo się staram dostrzegać te zalety, ale może moje nikłe doświadczenie w temacie nie pozwala mi ich dostrzec
Uff, 30 minut pisałem to pytanie
Pozdro!
Ostatnio zacząłem zajmować się RTOSami dla układów embedded, ogólnie tak dla rozwinięcia umiejętności bo na co dzień zajmuje się również systemami czasu rzeczywistego ale programuje je "bare matal". Czyli programowanie np. ARMa bez jakiegoś OSa.
Ogólnie punktem zapalnym dla rozpoczęcia nauki była pewna dyskusja z osobą która na co dzień bawi się RTOSami i mi zachwalała, jaki to RTOS nie jest wspaniały uniwersalny i prosty.
No i właśnie, po paru godzinach przesiedzianych nad artykułami z EP oraz nad tutkiem od FreeRTOS (klik), stwierdzam: że RTOS to w sumie nie jest takim super narzędziem (z tym, że mogę się strasznie mylić bo temat znam jak pisałem od kilku godzin
).
Ale do rzeczy, moje główne pytanie brzmi: Jaki uzysk daje używanie RTOS zamiast programowania "bare metal" pod C.
No i właśnie, teraz postaram się zaargumentować dlaczego tak sądzę.
No bo popatrzcie, wszyscy się cieszą że RTOS taki super, bo mamy wywłaszczenia, i się przerywają wątki i w ogóle możemy upakować procesy a scheduler sam się zajmie tym co i kiedy wywołać.
Tylko kurczę, przecież normalnie też możemy sobie takie coś zrobić ustawiając np. dla timerów (czy innych przerwań) konkretne priorytety i mieć ich nawet 30. I mieć taki 30 poziomowy program, a proces szumnie nazwany Idle Task to przecież nic innego jak program wykonywany w pętli gdzie jest najniższy poziom przerwań.
Więc ja osobiście, wolę sobie wywołać timer z jakąś częstotliwością (i odpowiednim priorytetem) i mieć to czarno na białym(oczywiście wykonywać jakiś kod w tym timerze). Nie widzę tutaj jakiegoś uzysku. Pracy jest więcej o może kilka linijek kodu (jednokrotny init timera).
Następna sprawa, tak szumnie nazywanie normalnych flag synchronizacyjnych muteksami i semaforami. No przecież to się w "tradycyjnych" systemach rozwiązuje zwyczajną flagą (tudzież kilkoma flagami) synchronizacyjną.
Dalej:
Kolega ten argumentował mi, że kompletnie olewam warstwę sprzętową bo do tego są już biblioteki, ja piszę tylko warstwę aplikacyjną. No i właśnie nie do końca. Bo w RTOSach dla jakichś konkretnych uC to znalazłem jedynie jakieś najprostsze API jak np. ustawienie pinów 1/0. O czymś takim jak np. proste funkcje (ale sprawdzone na 100%, najlepiej od producenta) do przesyłania po SPI to można zapomnieć. A więc skoro trzeba je pisać samemu, to argument o pisaniu samej aplikacji odpada.
A więc co tak ludzi i cały przemysł embedded przyciąga tak o RTOS? Bo ja szczerze powiedziawszy nie rozumiem.
Rozpatrzmy taki przykład z "Elektroniki Praktycznej" (7/2009). Autorem jest Krzysztof Paprocki.
Cytat:[...]Przedstawimy teraz przykład aplikacji działającej
z wykorzystaniem muteksów do ochrony
zasobów. Załóżmy sytuację, w której dwa zadania,
jeśli zaistnieje taka potrzeba, zmieniają wypełnienie
generowanego przez mikrokontroler
sygnału PWM. Nowowprowadzony współczynnik
wypełnienia nie może się zmieniać przez
czas 500 ms, a jeśli zostanie zmieniony to może
to spowodować nieprawidłowe działanie całego
systemu. Aby zabezpieczyć timer TIM3 pracujący
w roli generatora PWM, przed nieuprawnionym
dostępem zostanie wykorzystany muteks.
W systemie uruchomione są dwa zadania:
vTask25PWM() oraz vTask75PWM(). Wychylnie
joysticka na płytce ewaluacyjnej w górę powoduje
odblokowanie pierwszego zadania i, jak
nietrudno się domyślić, zmianę współczynnika
wypełnienia sygnału PWM na 25%. Przeciwna
pozycja joysticka (w dół) odblokowuje drugie
zadania, a tym samym ustawia wypełnienie
na 75%. Generator PWM – timer TIM3 – po
pełnym przemapowaniu steruje wyprowadzeniem
PC6, a więc diodą LD1. Efektem działania
aplikacji jest zmiana intensywności świecenia
diody w takt zmian położenia joysticka. Obecność
w systemie pracującego muteksa można
zaobserwować próbę zmian położenia joysticka
z częstotliwością większą niż 1 Hz. Muteks chroniący
zasób w postaci timera TIM3 nie pozwoli
na częstsze zmiany intensywności świecenia
diody LED niż co 500 ms.[...]
No i autor przygotował taki kod do obsługi tego zadania:
Kod: C / C++
Zaloguj się, aby zobaczyć kod
No i OK. Autor tutaj użył 2 tasków i mutexa...wszystko cacy. Ale przecież równie dobrze można sobie uruchomić timer który będzie odliczał czas tych 500ms, i będę sprawdzał sobie i dwóch różnych miejscach kodu (gdy wywołuje funkcje odpowiedzialną za wpisanie do PWM) i ten czas minął (oczywiście będę go zerował po każdym użyciu i oczywiście pod wpływem flagi synchronizacyjnej będę decydował czy to w ogóle liczyć...pewnie wiecie o co chodzi więc nie ma się co rozpisywać).
Ale spójrzcie, mój kod będzie lżejszy i troszkę szybszy (bo scheduler mi się nie wcina). Nie będzie też jakiś cięższy do analizy czy napisania go.
I tak podsumowując:
Plusy i minusy
+ Faktycznie wygodniej czeka się na coś w wątkach. Po prostu ustawiam sobie czas który ma upłynąć (uzależniam się od cykli zegara) i zapominam o temacie. Nie muszę używać do tego dodatkowego timera.
+ MOŻE troszkę bardziej uporządkowany kod (ale pisząc rozsądnie "tradycyjnie", to kod też nie jest jakimś wielkim burdelem)
- Trzeba zaimplementować OSa co zajmuje czas i miejsce w procku. Dodatkowo czas na naukę nowego OSa.
- Biorąc po uwagę że nie ma wszystkich funkcji API do obsługi sprzętu (typu proste funkcje transmisyjne) to upada argument o pisaniu tylko aplikacji. Tu i tu trzeba pisać funkcje do obsługi sprzętu.
Mam wrażenie że implementacja RTOSów dla embedded, to po prostu wymysł ludzi, którzy całe życie programowali na PC i gdy musieli się przenieść na embedded to nie ogarnęli tematu do końca (i OK, bo w sumie dla nich wszystko się dzieje równolegle) to na siłę zaczęli implementować RTOSy. I tak już zostało.
Bo na prawdę, jak się staram, to nie mogę znaleźć na prawdę znaczącej przewagi nad programowaniem tzw. "bare metal".
A więc powtarzam moje pytanie do bardziej doświadczonych kolegów: Jaki uzysk daje używanie RTOS zamiast programowania "bare metal" pod C. Co w nim jest takiego, że w sumie cały przemysł teraz już pracuje tylko pod RTOSami?
Zaznaczam, że bardzo się staram dostrzegać te zalety, ale może moje nikłe doświadczenie w temacie nie pozwala mi ich dostrzec
Uff, 30 minut pisałem to pytanie
Pozdro!
z reszta sie w 100% zgadzam 