[RTOS] vs Bare Metal - Zalety i wady w systemach embedded

Freddie Chopin napisał:

No widzisz... A RTOS napakowany dowolnie ciężkimi zadaniami, tak że układ obciążony jest w 100%, da radę - i to nie "od biedy" tylko "ot tak" - zmieścić się w kilkanaście-kilkadziesiat cykli zegara. Powiedzmy że w 100, czyli przy układzie który działa na 50MHz mieścisz się w dwie MIKROsekundy.

Na AVR'ach samo zrzucenie kontekstu zajmuje ponad 100 cykli:
http://www.freertos.org/implementation/a00016.html

Dodajmy do tego przywracanie kontekstu oraz kod sheudlera (który wcale taki prosty nie jest) i już tak szybko nie jest.

Wszystko się rozbija o to jak krytyczne jest obsłużenie danego zdarzenia w określonym czasie i czy na pewno konieczne jest wykonywanie jednocześnie kompresji/szyfrowania/transformaty fouriera etc.
Bo zazwyczaj krytyczne zadania są robione na przerwaniach a cała reszta w pętli głównej.

Freddie Chopin napisał:

- w tym momencie - N-A-T-Y-C-H-M-I-A-S-T, a nie dopiero przy następnym sprawdzaniu stanu flagi, nie po zakończeniu aktualnie realizowanej funkcji maszyny stanów, nie "za krótką chwilę", tylko natychmiast - wątek (lub wątki) który na dane oczekiwały zostaje odblokowany,
- jeśli odblokowany wątek ma odpowiednio wysoki priorytet (czyli jeśli programista określił, że zadanie odbioru tych danych jest "bardzo ważne"), to wątek ten wznowi swoje wykonywanie N-A-T-Y-C-H-M-I-A-S-T po powrocie z przerwania - jeśli zdarzenie było zgłoszone przez przerwanie - lub natychmiast po zgłoszeniu tego zdarzenia - jeśli zostało ono zgłoszone przez wątek.

N-A-T-Y-C-H-M-I-A-S-T po kolejnym "ticku" sheudlera (zazwyczaj 1ms/10ms)

jnk0le napisał:

N-A-T-Y-C-H-M-I-A-S-T po kolejnym "ticku" sheudlera (zazwyczaj 1ms/10ms)

RTOS ma instrumenty do tego, żeby nastąpiło to N-A-T-Y-C-H-M-I-A-S-T i zdarzenia/przerwania z tych instrumentów korzystają.

A AVRom dajmy już spokój.

Piotrus_999 napisał:

Prosze o uzasadnienie dlaczego nawet przy 16MHz "tyknięcie" ma zając 1ms (czyli 84000cykli), a nawet 10ms (840000 cykli).
Byc moze czegos nie rozumiem.

"Tyknięcia" to są zaprogramowane interwały w których RTOS ma przełączać konteksty, a nie że tyle czasu ma trwać przełączanie kontekstu.

Przykład "pobudzenia" schedulera do natychmiastowego wykonania zadania po otrzymaniu zdarzenia. Warunek jest taki, że task obsługujący zdarzenie musi mieć wysoki priorytet i być uśpiony.

http://www.freertos.org/taskresumefromisr.html

Piotrus_999 napisał:

Kolega mnie nie zrozumiał. Pytałem kolegę jnk0le dlaczego według niego NATYCHMIASTOWE przełaczenie zajmie shedulerowi od 16000 do 160000 cykli zegara 16MHz

michalko12 napisał:

"Tyknięcia" to są zaprogramowane interwały w których RTOS ma przełączać konteksty, a nie że tyle czasu ma trwać przełączanie kontekstu.

EDIT:
Z tego co znalazłem to jest to 15us @ 72MHz

http://stackoverflow.com/a/24906003/4676265

Piotrus_999 napisał:

Pytałem kolegę jnk0le dlaczego według niego NATYCHMIASTOWE przełaczenie zajmie shedulerowi od 16000 do 160000 cykli zegara 16MHz.

To Ty jego nie zrozumiałeś, bo on wcale tego nie napisał.

jnk0le napisał:

N-A-T-Y-C-H-M-I-A-S-T po kolejnym "ticku" sheudlera (zazwyczaj 1ms/10ms)

Dobrze by było, gdyby osoby nie mające pojęcia o RTOSach raczej obsługiwały ten wątek w trybie read-only - nie ma co się ośmieszać i niepotrzebnie tworzyć wymiany zdań mającej na celu prostowanie takich bzdur...

Moderowany przez tmf:

Freddie, celem wątków takich jak ten, o niczym, jest m.in. edukacja. Tylko dlatego jeszcze nie poleciało to do kosza. Więc korzystając z okazji dajmy szansę innym się wypowiedzieć, nawet jeśli nie mają racji.

Przełączenie kontekstu po wystąpieniu zdarzenia (gdy wątek o odpowiednio wysokim priorytecie na to zdarzenie czeka) następuje - ponownie to napiszę - N-A-T-Y-C-H-M-I-A-S-T. W tym przypadku "natychmiast" to czas potrzebny na zapisanie kontekstu jednego wątku i wczytanie kontekstu innego wątku - szczegóły techniczne zależą oczywiście od danej architektury, niemniej jednak cały taki proces zajmuje kilkadziesiąt-kilkaset cykli zegara. Proces ten rozpoczyna się N-A-T-Y-C-H-M-I-A-S-T po wystąpieniu zdarzenia.

Tick systemowy - typowo o okresie 1ms lub 10ms - służy tylko do poniższych rzeczy:
- round-robin scheduling, czyli wymuszanie zmiany kontekstu pomiędzy dwoma lub więcej wątkami o TYM SAMYM priorytecie, jeśli jeden z nich wykonuje się (bez blokowania) odpowiednio długo (zwykle kilka-kilkanaście-kilkaset ticków systemowych - np. 100ms),
- odliczanie timeoutów (blokowanie z timeoutem, usypianie wątków, ...),
- obsługa programowych timerów.

Tick systemowy i jego rozdzielczość nie ma NIC WSPÓLNEGO z czasem reakcji na zdarzenie.

Przykładowy kod obsługujący zmianę kontekstu dla ARM Cortex-M3/M4(F) - https://github.com/DISTORTEC/distortos/blob/m...ecture/ARM/ARMv7-M/ARMv7-M-PendSV_Handler.cpp + funkcja Scheduler::switchContext() ( https://github.com/DISTORTEC/distortos/blob/master/source/scheduler/Scheduler.cpp#L261 ). Kod przerwania PendSV - jeśli nie jest używane FPU - to 10 "prostych" instrukcji + 2 instrukcje ~8 taktowe, a więc powiedzmy że 30-40 cykli zegara. Do tego czas wejścia i powrotu z przerwania oraz czas potrzebny na wykonanie (prostej) funkcji Scheduler::switchContext() - ciężko mi tu znaleźć więcej niż ze 100 cykli.

Po wątku tym widać, że osoby kwestionujące zasadność istnienia RTOSów po prostu nie rozumieją ich możliwości...

Freddie Chopin napisał:

Po wątku tym widać, że osoby kwestionujące zasadność istnienia RTOSów po prostu nie rozumieją ich możliwości...

A ja po dzisiejszym dniu bym takie osoby kopal po tylkach Aktualnie w pracy mam na tapecie taki kod bez FreeRTOS-a na H8/300 z wlasnymi scheduler-ami Kod w zasadzie z brakiem dokumentacji i IMHO do napisania na nowo (ale na razie nie ma na to czasu). Dzisiaj walczylem miedzy innymi z wysypkami z powodu przepelnienia stosu itp. Zarabista praca gdy nie ma sie JTAG-a

Piotrus_999 napisał:

tplewa napisał:

Aktualnie w pracy mam na tapecie taki kod bez FreeRTOS-a na H8/300 z wlasnymi scheduler-ami Kod w zasadzie z brakiem dokumentacji i IMHO do napisania na nowo (ale na razie nie ma na to czasu). Dzisiaj walczylem miedzy innymi z wysypkami z powodu przepelnienia stosu itp. Zarabista praca gdy nie ma sie JTAG-a

Nawet jak sam to napiszesz to powodzenia zeby cos zmienic po roku
Ja kiedys popełnilem w php wiekszy projekt (tak ze 20-25k linii) bez zadnego frameworka (taki internetowy "bare metal" - tez byłem dzigit i stwierdzilem ze sam zrobie lepiej) i przyszła pora zmian to ni cholery nie rozumiem sam siebie. Bede musiał pewnie przepisac w cywilizowany sposób

Ja to dostalem w "spadku" po kims kod i musze sprawic aby to dzialalo + dodac pare funkcjonalnosci Za rok to bedzie juz nowy firmware napisany od podstaw No ale na razie termin goni i trzeba to "cos" doprowadzic do ladu i skladu Ot wlasnie koncepcja zastapienia RTOS-a tak sie konczy w praktyce tzn. ktos ma przewalone i na pewno nie ten co to wymyslil he he

Ciesze sie tylko ze szef super, firma luzna (taka rodzinna atmosfera) to nie mam jeszcze jakiegos stresu i moge sobie spokojnie z tym walczyc bez wiekszych nerwow (poza terminem). No ale i tak siedzenie nad takim kodem do przyjemnych nie nalezy

Freddie Chopin napisał:

niemniej jednak cały taki proces zajmuje kilkadziesiąt-kilkaset cykli zegara.
[...]
ciężko mi tu znaleźć więcej niż ze 100 cykli.

A dokładniej, to jest to ok. 1000 cykli, czyli 10x więcej (15us@72MHz)
http://stackoverflow.com/a/24906003/4676265

Jak już powołujesz się na wypowiedzi z internetu to wypadałoby przytoczyć trochę więcej a nie tylko to co potwierdza Twoja tezę. FreeRTOS nie jest jedynym systemem operacyjnym i na takim Keil RTX ten czas jest rowny 5us więc na oko 333 cykle przy 72MHz.

jnk0le napisał:

Freddie Chopin napisał:

niemniej jednak cały taki proces zajmuje kilkadziesiąt-kilkaset cykli zegara.
[...]
ciężko mi tu znaleźć więcej niż ze 100 cykli.

A dokładniej, to jest to ok. 1000 cykli, czyli 10x więcej (15us@72MHz)
http://stackoverflow.com/a/24906003/4676265

Ale żeś się uparł... Normalnie zaraz oscyloskop chyba wyciągnę i Ci zmierzę ile trwa zmiana kontekstu w moim systemie (;

Tak czy siak FreeRTOS jest ciekawym przypadkiem. W jego licencji jest informacja, że zabrania się wykonywania i publikacji jakichkolwiek porównań z innymi systemami, bo to niby "standardowa praktyka w branży". Rzeczywistość jest - wg mnie - taka, że FreeRTOS jest tak kiepsko napisany (a niestety tak właśnie jest), że takie porównanie z czymkolwiek innym byłoby miażdżące... Nie rozumiem jak to jest możliwe że ten system jest tak popularny...

---- EDIT ----

Proszę bardzo - zmierzyłem ile wynosi "N-A-T-Y-C-H-M-I-A-S-T" w moim systemie ( http://distortos.org/ ) w dosyć typowym przypadku - wątek czeka na semafor, który jest ustawiany przez przerwanie. Program testowy:


Wynik pomiaru na oscylogramie:



1.1us, co przy zegarze 168MHz daje jakieś 185 cykli zegara. Jest to czas potrzebny zarówno na zmianę kontekstu, obsługę przerwania, przestawianie pinu GPIO jak i obsługę semafora.

Tak z czystej ciekawości - jak by to wyglądało gdybyśmy mieli "ciężki" wątek A lub nawet kilka oraz B który czeka na semaphorę od IRQ ?

Dokładnie tak samo - oczywiście pod warunkiem, że wątek oczekujący na semafor ma wyższy priorytet niż ten który się aktualnie wykonuje. Nie ma żadnej różnicy czy kontekst jest przełączany "z" wątku IDLE czy jakiegokolwiek innego - tak czy siak trzeba zachować dokładnie tyle samo rejestrów i dokładnie tyle samo odtworzyć. W zasadzie w niektórych przypadkach gdy przełączenie nastąpiłoby _NIE_ z wątku IDLE, to mogłoby być nawet lepiej, ponieważ wątek IDLE może wprowadzać układ w stan uśpienia, a wyjście z niego może trwać minimalnie dłużej - wpłynęłoby to jednak na czas wejścia do przerwania, a nie na samo przełączenie kontekstu.

Sytuacja byłaby nieco inna, gdyby jakiś wątek korzystał z rejestrów FPU - wtedy czas przełączenia kontekstu będzie dłuższy, bo trzeba zachować i/lub odtworzyć jeszcze 32 rejestry FPU. Nawet to jednak nie ma wiele wspólnego z "ciężarem" - nie chcę się wdawać w szczegóły techniczne, więc sobie ten wątek daruję (; Skrótowa wersja - gdyby wątek "z" którego następuje przełączenie kontekstu i/lub wątek "do" którego następuje przełączenie kontekstu używały FPU, to całość może trwać dłużej - strzelam że nie dłużej niż 300 cykli w sumie w najgorszym przypadku.

Freddiego N-A-T-Y-C-H-M-I-A-S-T pod RTOS to czas składowania kontekstu plus czas ładowania nowego (plus narzut programowy schedulera). W przypadku rozwiązania czysto event-driven zwykłe "natychmiast" - to czas składowania kontekstu, czyli ponad trzykrotnie krócej niż w RTOS. Najgorsze "natchmiast" to odtwarzania i składowania kontekstu bez narzutu programowego schedulera.

Tak jakoś mnie naszło to pytanie bo main + IRQ_handler nie za bardzo wyglądają na pracę wątkową.

Bardziej to przypomina powrót ze zwykłego przerwania do pętli głównej (co oczywiście jest wydajniejsze od pełnego context-switchingu) i można by się przyczepić że z pełną funkcjonalnością RTOSa (np. na wzór 'xTaskResumeFromISR' które zajmuje te 1k cykli) może mieć nie wiele wspólnego.

jnk0le napisał:

Tak jakoś mnie naszło to pytanie bo main + IRQ_handler nie za bardzo wyglądają na pracę wątkową.

Bardziej to przypomina powrót ze zwykłego przerwania do pętli głównej (co oczywiście jest wydajniejsze od pełnego context-switchingu) i można by się przyczepić że z pełną funkcjonalnością RTOSa (np. na wzór 'xTaskResumeFromISR' które zajmuje te 1k cykli) może mieć nie wiele wspólnego.

No i znowu...

W moim systemie - jak zresztą w kilku innych, nieco mądrzejszych niż FreeRTOS - main() jest wątkiem. Gdy w main() wywoływana jest funkcja blokująca (w tym przypadku Semaphore::wait()), to następuje zablokowanie wątku main() i przełączenie do wątku IDLE. Przerwanie wykonuje się w trakcie gdy aktualnie wykonywanym wątkiem jest IDLE, a wątek main() "wisi" na semaforze.

Jeśli chcesz to dalej możesz się upierać przy swoim... Nie wiem czego Ci brakuje w tym przykładzie - zmodyfikuj sobie go jak chcesz, a ja go uruchomię i Ci pokażę, że wynik będzie taki sam niezależnie od tego czy działa tylko wątek IDLE czy 100 wątków liczących FFT.

BlueDraco napisał:

Freddiego N-A-T-Y-C-H-M-I-A-S-T pod RTOS to czas składowania kontekstu plus czas ładowania nowego (plus narzut programowy schedulera). W przypadku rozwiązania czysto event-driven zwykłe "natychmiast" - to czas składowania kontekstu, czyli ponad trzykrotnie krócej niż w RTOS. Najgorsze "natchmiast" to odtwarzania i składowania kontekstu bez narzutu programowego schedulera.

Event-driven o jakim piszesz to mit, którego jeszcze nikt nie widział i w którym trzeba sobie napisać wszystko od nowa, bo w obsłudze tych "eventów" w zasadzie nie można użyć ŻADNEJ funkcji standardowej - ot choćby wspomnianego liczenia sinusa z liczby typu double... Debatujemy o rzeczywistych i praktycznych rozwiązaniach, czy może o teoretycznych koncepcjach które wyglądają dobrze na papierze?

A jeszcze z innej beczki:
czy istnieje dobre rozwiązanie pośrednie dla sytuacji, gdy mamy tylko jeden wątek z nieokreślonym czasem wykonania (np. interakcja z operatorem przez klawiaturę i wyświetlacz), zaś cała reszta zadań ma być wykonywana w wariancie obsługi zdarzeń?
Sądzę, że jest to częsta sytuacja i może ktoś ten wariant przećwiczył?

A skąd pomysł, że interakcja z operatorem ma być "wątkiem z nieokreślonym czasem wykonania"? Przecież naciśnięcie klawisza jest zdarzeniem, które uruchamia odpowiednią procedurę obsługi.

Jeśli komunikacja z operatorem używa wielopoziomowego menu, to realizacja czegoś takiego wymaga zbudowania skomplikowanego automatu, z wieloma rozgałęzieniami i krótkim czasem przebiegu, by powrócić do pętli głównej, bez blokowania zadań sterowanych timerami. Chyba łatwiej jest taką procedurę interakcji zbudować jak statyczną procedurę, tyle że potrzebna jest wtedy możliwość jej przerwania i odtworzenia stanu po przydzieleniu czasu?

Możesz jaśniej?
Pytam, bo w takim Windows jakoś mi się udaje ogarniać kilka wątków w aplikacji i nie rozumiem sugestii.

Dodano po 29 [minuty]:

Teraz to nam się wątek na forum skomplikował, bo zamiast odpowiedzieć w kolejnym poście, odpowiedziałeś w poprzednim. To na marginesie...
Zamierzałem zrobić menu interaktywne w jednym wątku ze względu wyżej wspomnianego: prostota wykonania.
Oczywiście chętnie się zapoznam z pomysłem na menu w wielu wątkach.