RTOS dla systemów wbudowanych

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.

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.

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.

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!

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.

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!

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.

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ć.

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

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.