RTOS dla systemów wbudowanych

57

Widziałem wiele artykułów, które mówią mi, że powinienem używać RTOS do zarządzania czasem i zasobami. Mój czas nie pozwolił mi na własne badania, więc przychodzę do chiphakera po radę.

Korzystam z mikrokontrolerów o niskim zużyciu zasobów (MSP430, PIC) i szukałem RTOS, których mogę użyć.

Do momentu:

  1. Koszt zasobów systemu
  2. Zalety systemu
  3. Wady systemu
  4. Triki implementacyjne
  5. Sytuacje, w których RTOS powinien / nie powinien być używany.

Nie używam systemów takich jak arduino, projekty, z którymi pracuję, nie są w stanie pokryć kosztów takiego systemu.

Kortuk
źródło
2
Jestem zdezorientowany co do tego, za co to zostało odrzucone. Jeśli głosujący może przekazać mi opinię, postaram się uniknąć takiego działania w przyszłości.
Kortuk
1
tak samo. To świetne pytanie ....
Jason S
Przyjąłem pytanie, ponieważ nawet sądząc, że jest to kwestia otwarta, miałem wiele świetnych odpowiedzi i chciałem nagrodzić co najmniej jednego pisarza za ten wysiłek.
Kortuk

Odpowiedzi:

29

Nie miałem dużego osobistego doświadczenia z RTOS-em innym niż QNX (co jest ogólnie świetne, ale nie jest tanie i miałem naprawdę złe doświadczenia z konkretnym sprzedawcą płyt i podejście QNX do innych systemów niż ich najczęstsze), co jest zbyt duże dla PIC i MSP430.

Korzyści z RTOS znajdziesz w takich obszarach jak

  • zarządzanie wątkami / planowanie
  • komunikacja między wątkami + synchronizacja
  • I / O w systemach ze stdin / stdout / stderr lub portami szeregowymi lub obsługą Ethernetu lub systemem plików (w większości MSP430 lub PIC, z wyjątkiem portów szeregowych)

Dla urządzeń peryferyjnych PIC lub MSP430: dla portów szeregowych użyłbym bufora pierścieniowego + przerywa ... coś, co piszę raz na system i po prostu ponownie używam; inne urządzenia peryferyjne Nie sądzę, aby można było znaleźć wsparcie z RTOS, ponieważ są one tak specyficzne dla danego dostawcy.

Jeśli potrzebujesz taktowania solidnego jak na mikrosekundę, RTOS prawdopodobnie nie pomoże - RTOS ograniczają taktowanie, ale zwykle mają jitter synchronizacji w harmonogramie z powodu opóźnień przełączania kontekstu ... QNX działający na PXA270 miał jitter w dziesiątkach mikrosekund typowych, maksimum 100-200us, więc nie użyłbym go do rzeczy, które muszą działać szybciej niż około 100Hz lub które wymagają taktowania znacznie dokładniejszego niż około 500us. W przypadku tego rodzaju rzeczy prawdopodobnie będziesz musiał zaimplementować własną obsługę przerwań. Niektóre RTOS dobrze się z tym bawią, a inne sprawią, że będzie to królewski ból: twój czas i ich czas mogą nie być w stanie dobrze współistnieć.

Jeśli harmonogram / harmonogram nie jest zbyt skomplikowany, lepiej użyć dobrze zaprojektowanej maszyny stanów. Gorąco polecam przeczytanie Practical Statecharts w C / C ++, jeśli jeszcze tego nie zrobiłeś. Zastosowaliśmy to podejście w niektórych naszych projektach, w których pracuję, i ma ono pewne realne zalety w porównaniu z tradycyjnymi maszynami stanu do zarządzania złożonością ... co jest naprawdę jedynym powodem, dla którego potrzebujesz RTOS.

Jason S.
źródło
Pracuję w firmie startupowej, w której najbardziej doświadczeni faceci od systemów wbudowanych są właśnie po studiach (tj. Ja i inny facet, który pracuje ze mną od około 2 lat). Bardzo dużo czasu spędzam ucząc się o praktyce branżowej podczas tygodnia pracy. Jak czytałem, zostałem poinformowany o wszystkim oprócz naszego najtańszego systemu, RTOS byłby dużym ulepszeniem.
Kortuk
Wydaje się, że istnieje bardzo mało zasobów system RTOS dla takich rzeczy, jak PIC i MSP430, które mogą pomóc w stworzeniu systemu deterministycznego z bardzo skomplikowanego, a także znacznie oczyszczają nasze zarządzanie utrzymywaniem oddzielnych modułów. Należę do dwuosobowego zespołu, który skutecznie zbudował system zbierania i routingu danych w terenie. Teraz, gdy patrzę na RTOS, widzę, że jest idealny do tego, co zaprojektowaliśmy.
Kortuk
Przepraszamy za korzystanie z trzech miejsc na posty, twoja odpowiedź jest bardzo pomocna, szukam rozwiązania o bardzo niskim poziomie zasobów, ale ta informacja jest cenna, dziękuję za pomoc.
Kortuk
nie przejmuj się liczbą komentarzy (IMHO jedną rzeczą, której brakuje w strukturze StackExchange, jest obsługa dyskusji ... format Q / A obejmuje większość rzeczy, ale nie niektóre) ... brzmi, jakbyś miał całkiem dobry pogląd na to, co szukasz. Nie spojrzałem na FreeRTOS, o którym wspomniał Steve, ale jeśli został on przeniesiony do niskiej klasy mikrokontrolerów, być może wykona potrzebne zarządzanie harmonogramem.
Jason S
Wydaje się, że zapisuje stan każdego wątku przez stos (coś w rodzaju 50 instrukcji push / pull) i może obsłużyć przerwania czasowe. Mój system normalnie używałby przerwania portu do przełączania wątków, ale zadanie wygląda na wykonalne. Chciałbym, aby ten typ strony prowadził dyskusję w lepszym formacie.
Kortuk
26

Czy próbowałeś FreeRTOS ? Jest bezpłatny (podlega Warunkom użytkowania) i został przeniesiony zarówno do MSP430, jak i do kilku wersji PIC.

Jest niewielki w porównaniu do niektórych innych, ale ułatwia to także naukę, zwłaszcza jeśli wcześniej nie korzystałeś z RTOS.

Dostępna jest (niewolna) licencja komercyjna, a także wersja IEC 61508 / SIL 3.

Steve Melnikoff
źródło
Dziękuję tonie, przyjrzę się temu w ciągu tygodnia, pozostawiam pytanie otwarte na inne odpowiedzi, ale jesteś świetną pomocą!
Kortuk
12

Właśnie dowiedziałem się o NuttX RTOS, który może nawet działać na systemie 8052 (8-bitowym). Nie ma wielu portów, ale wygląda interesująco. POSIX może być zaletą, ponieważ może sprawić, że część twojego kodu stanie się trochę bardziej przenośna, jeśli przejdziesz do bardziej zaawansowanego procesora i chcesz uruchomić system Linux lub QNX w czasie rzeczywistym.

Nie mam żadnego doświadczenia z komercyjnymi RTOS, ale od lat używam domowych! Świetnie pomagają w dzieleniu się tworzeniem kodu między wielu programistów, ponieważ w zasadzie każdy z nich może otrzymać „zadanie” lub „wątek” do pracy z ich strony. Nadal musisz koordynować, a ktoś musi nadzorować cały projekt, aby upewnić się, że każde zadanie dotrzyma terminu.

Polecam również zbadanie Rate Monotonic Analysis lub RMA podczas korzystania z RTOS. Pomoże Ci to zagwarantować, że Twoje najważniejsze zadania dotrzymają terminów.

Chciałbym również przyjrzeć się ramom programistycznym QP-nano Miro Samka, które mogą współpracować z RTOS lub bez niego i nadal dają ci możliwość działania w czasie rzeczywistym. Dzięki niemu dzielisz swój projekt na hierarchiczne maszyny stanów zamiast tradycyjnych zadań. Jason S wspomniał o książce Miro w swoim poście. Doskonała lektura!

Jay Atkinson
źródło
9

Jedną z rzeczy, które uważam za przydatne na wielu maszynach, jest prosty przełącznik stosów. Tak naprawdę nie napisałem żadnego dla PIC, ale spodziewałbym się, że to podejście zadziała dobrze na PIC18, jeśli oba / wszystkie wątki wykorzystają w sumie 31 lub mniej poziomów stosu. W 8051 główną rutyną jest:

_taskswitch:
  xch a, SP
  xch a, _altSP
  xch a, SP
  gnić

Na PIC nie pamiętam nazwy wskaźnika stosu, ale procedura mogłaby wyglądać mniej więcej tak:

_taskswitch:
  movlb _altSP >> 8
  movf _altSP, w, b
  movff _STKPTR, altSP 
  movwf _STKPTR, c
  powrót

Na początku programu wywołaj procedurę task2 (), która ładuje altSP z adresem alternatywnego stosu (16 prawdopodobnie działałby dobrze dla PIC18Fxx) i uruchamia pętlę task2; ta rutyna nie może nigdy powrócić, inaczej rzeczy umrą bolesną śmiercią. Zamiast tego powinien wywoływać _taskswitch, ilekroć chce uzyskać kontrolę nad głównym zadaniem; główne zadanie powinno wtedy wywołać _taskswitch, ilekroć chce ustąpić drugiemu zadaniu. Często można mieć słodkie małe rutyny, takie jak:

void delay_t1 (unsigned short val)
{
  zrobić
    taskwitch ();
  while ((bez znaku krótkie) (millisecond_clock - val)> 0xFF00);  
}

Zauważ, że przełącznik zadań nie ma możliwości „czekania na warunek”; obsługuje tylko spinwait. Z drugiej strony przełącznik zadań jest tak szybki, że próba przełączenia zadań () w czasie, gdy inne zadanie czeka na wygaśnięcie timera, przełączy się na inne zadanie, sprawdzi timer i wróci szybciej niż typowy przełącznik zadań ustalą, że nie trzeba przełączać zadań.

Należy pamiętać, że wielozadaniowość kooperacyjna ma pewne ograniczenia, ale pozwala uniknąć konieczności blokowania i innego kodu związanego z muteksami w przypadkach, w których niezmienniki tymczasowo zakłócone można szybko przywrócić.

(Edytuj): Kilka zastrzeżeń dotyczących zmiennych automatycznych i takich:

  1. jeśli procedura, która korzysta z przełączania zadań, jest wywoływana z obu wątków, generalnie konieczne będzie skompilowanie dwóch kopii procedury (prawdopodobnie poprzez #włączenie tego samego pliku źródłowego z różnymi instrukcjami #define). Każdy podany plik źródłowy albo będzie zawierał kod tylko dla jednego wątku, albo będzie zawierał kod, który zostanie skompilowany dwukrotnie - raz dla każdego wątku - dzięki czemu mogę używać makr typu „#define delay (x) delay_t1 (x)” lub # zdefiniować opóźnienie (x) opóźnienie_tx (x) "w zależności od używanego wątku.
  2. Uważam, że kompilatory PIC, które nie widzą wywoływanej funkcji, założą, że taka funkcja może zniszczyć wszystkie rejestry procesora, unikając w ten sposób potrzeby zapisywania jakichkolwiek rejestrów w procedurze przełączania zadań [fajna korzyść w porównaniu z zapobiegawcza wielozadaniowość]. Każdy, kto rozważa zastosowanie podobnego przełącznika zadań dla dowolnego innego procesora, musi znać stosowane konwencje rejestru. Przesuwanie rejestrów przed zmianą zadania i usuwanie ich po nich jest łatwym sposobem na załatwienie spraw, zakładając, że istnieje wystarczająca ilość miejsca na stosie.

Wspólna wielozadaniowość nie pozwala całkowicie uniknąć problemów związanych z blokowaniem i tym podobnych, ale naprawdę znacznie upraszcza rzeczy. Na przykład w prewencyjnym systemie RTOS z kompaktowaniem modułu wyrzucania elementów bezużytecznych należy zezwolić na przypięcie obiektów. Gdy używasz przełącznika kooperacyjnego, nie jest to konieczne, pod warunkiem, że kod zakłada, że ​​obiekty GC mogą się przesuwać w dowolnym momencie wywołania funkcji taskwitch (). Kompaktowy kolektor, który nie musi się martwić o przypięte obiekty, może być znacznie prostszy niż ten, który ma.

supercat
źródło
1
Świetna odpowiedź. Myślę, że byłoby interesujące uzyskać linki do zasobów dotyczących zbliżania się do mojego RTOS. Moim celem było uzyskanie wysokiej jakości RTOS od dostawcy, który wykonał pracę zapewniania ciężkiego czasu rzeczywistego, ale dla mnie może to być zabawny projekt hobbystyczny.
Kortuk
1
Fajnie, nigdy nie myślałem o zadaniach jako o zmianie SP ...
NickHalden,
1
@JGord: Zrobiłem małe przełączniki zadań na 8x51 i na DSP TI. Pokazany powyżej 8051 jest przeznaczony do dokładnie dwóch zadań. DSP jeden jest używany z czterema i jest nieco bardziej skomplikowany. Miałem jednak szalony pomysł: można było obsłużyć cztery zadania, używając trzech przełączników zadań. Za każdym razem, gdy jedno z dwóch pierwszych zadań chce zmienić zadanie, powinno wywoływać TaskSwitch1 i TaskSwitch2. Gdy jedno z dwóch drugich zadań chce przełączać zadania, powinno wywoływać Taskswitch1 i Taskswitch3. Załóżmy, że kod zaczyna się na stosie 0, a każdy przełącznik zadań ma ustawiony odpowiedni numer stosu.
supercat
@JGord: Hmm ... to nie do końca działa; wydaje się, że daje 3-krotny round-robin i ignoruje trzeci przełącznik. Cóż, eksperymentuj i myślę, że prawdopodobnie znajdziesz dobrą formułę.
supercat
7

Użyłem Salvo na MSP430. Było to bardzo lekkie w kwestii zasobów procesora i, pod warunkiem przestrzegania zasad implementacji, bardzo łatwe w użyciu i niezawodne. Jest to współpracujący system operacyjny i wymaga, aby przełączniki zadań były wykonywane na poziomie zewnętrznego wywołania funkcji funkcji zadania. To ograniczenie pozwala systemowi operacyjnemu na pracę na bardzo małych urządzeniach pamięciowych bez użycia dużej ilości miejsca na stosie przy zachowaniu kontekstów zadań.

Na AVR32 używam FreeRTOS. Znowu bardzo wiarygodny, ale miałem pewne rozbieżności w konfiguracji / wersji między wersją publikowaną przez FreeRTOS a wersją dostarczaną z frameworkiem Atmel. Ma to jednak tę zaletę, że jest bezpłatne!

uɐɪ
źródło
5

Grudniowe wydanie Everyday Practical Electronics zawiera część 3 serii poświęconej systemom operacyjnym czasu rzeczywistego dla PIC (w kolumnie PIC n 'Mix) i zawiera szczegółowe informacje na temat konfigurowania FreeRTOS z MPLAB i PICKit 2. Dwa poprzednie artykuły (które ja nie widziałem) wydaje się, że omawiał zalety różnych RTOS i zdecydował się na FreeRTOS. Gdy bieżący artykuł skonfiguruje środowisko programistyczne, przystępują do projektowania binarnego zegara cyfrowego. Wygląda na to, że na ten temat będzie jeszcze co najmniej jedna część.

Nie jestem pewien, jak EPE jest dostępne w USA, ale wydaje się, że istnieje sklep w USA połączony z ich witryną i mogą być dostępne kopie elektroniczne.

Amos
źródło
4

Kompilator CCS dla PIC jest wyposażony w prosty RTOS. Nie próbowałem tego, ale jeśli masz ten kompilator, łatwo byłoby eksperymentować.

Jeanne Pindar
źródło
1
Próbowałem tego jako mojego pierwszego. To nie jest RTOS w żadnym prawdziwym znaczeniu tego słowa. W żaden sposób nie ma charakteru zapobiegawczego. Wymaga regularnego używania komend wydajnych, aby RTOS mógł zdecydować, kto będzie następny, musisz celowo wprowadzać je na wypadek, gdyby inny program musiał przejąć kontrolę.
Kortuk
2
Myślę, że nadal nazywa się to RTOS. Wygląda na to, że ma harmonogram współpracujący zamiast harmonogramu w pełni wyprzedzającego.
Jay Atkinson
Tak, technicznie wciąż jest to RTOS, ale miałem i nadal mam dla niego bardzo niewielką wartość. Wiem, że to sprawa osobista, ale dla mnie musi być zapobiegawcza, aby być cennym. Nadal daje +1, ponieważ była to dobra odpowiedź i wartościowa.
Kortuk
3

Ściśle powiązane pytanie: https://stackoverflow.com/questions/1624237/multithreading-using-c-on-pic18

Davidcary
źródło
Dzięki! Wygląda na to, że większość ludzi nie dostała pytania, ale wciąż jest interesujące.
Kortuk
Zadałem pytanie na SO, zapraszając użytkownika do E&R po pomoc!
Kortuk
Wydaje mi się, że „dostaliśmy” pytanie dotyczące SO, było to pytanie inne, ale związane z tym pytaniem. Co do twojego komentarza dotyczącego certyfikacji; to zależy od wielu rzeczy. Patrząc na odpowiedzi tutaj, podoba mi się odpowiedź DoxaLogos odnosząca się do QP-nano; moje doświadczenie sprawia, że ​​wolę kod sterowany zdarzeniem niż wątki i niejawne przełączanie kontekstu wątków.
Janm
2

Nie powiedziałeś wiele o swojej aplikacji. To, czy korzystasz z RTOS, zależy w dużej mierze od tego, co musisz zrobić w PIC. Jeśli nie robisz kilku różnych rzeczy asynchronicznych, które wymagają ścisłych ograniczeń czasowych lub masz uruchomionych kilka wątków, wtedy RTOS może być przesadzony.

Istnieje wiele sposobów organizacji czasu na mikrokontrolerze w zależności od tego, co najważniejsze:

  1. Stała częstotliwość klatek: w przypadku PIC z serwosterownikiem, który musi na przykład działać z częstotliwością 1000 Hz. Jeśli wykonanie algorytmu PID zajmuje mniej niż 1 ms, możesz wykorzystać pozostałą część milisekundy do wykonania innych zadań, takich jak sprawdzenie magistrali CAN, odczyt czujników itp.

  2. Wszystkie przerwania: wszystko, co dzieje się w PIC, jest wywoływane przez przerwanie. Przerwaniom można nadać priorytet zgodnie z ważnością zdarzenia.

  3. Trzymaj go w pętli i rób wszystko tak szybko, jak to możliwe. Może się okazać, że zapewnia to odpowiednie ramy czasowe.

Rocketmagnet
źródło
Rozumiem inne metody, ale chcę rozszerzyć na RTOS. Będę wykonywać wiele zadań i mieć trudny system czasu rzeczywistego, ale jestem gotów zacząć bez wymagań ciężkiego czasu rzeczywistego. Dziękuję za poświęcenie czasu na odpowiedź, ale chcę nauczyć się RTOS, aby móc go używać w sytuacjach wysokiego zapotrzebowania.
Kortuk