Korzyści z RTOS vs Bare Metal do programowania MCU?

Uwaga: To pytanie konkretnie wspomina o dwóch RTOSach, ale jest bardziej ogólne i prawdopodobnie może na nie odpowiedzieć każdy, kto napisał wcześniej kod C dla wbudowanych RTOS, i którego oprogramowanie działało bezpośrednio na MCU.

Chciałbym dowiedzieć się więcej na temat wbudowanych RTOS i pisać dla nich aplikacje. Obecnie patrzę na Embox i RIOT, ponieważ są otwarte, nowoczesne, aktywne i wydają się mieć doskonałą dokumentację. Mój cel składa się z dwóch faz: Faza 1 polega na ustaleniu, jak skompilować i sflashować te systemy operacyjne do MCU (prawdopodobnie AVR lub ARM). Faza 2 polega następnie na napisaniu prostego programu C (w zasadzie demona bezgłowego), który ewoluowałby z czasem jako „aplikacja hobbystyczna”. Następnie sflashowałem / wdrożyłem ten program na tym samym MCU, a tym samym pomyślnie wdrożyłem pakiet aplikacji składający się z Embox / RIOT i mojej aplikacji znajdującej się na nim.

Zanim przejdę drogą, która ostatecznie prowadzi do ślepych uliczek , natknąłem się na ten artykuł , który całkiem nieźle wyjaśnia, dlaczego aplikacje czasu rzeczywistego, napisane w C / asemblerze i flashowane na MCU, tak naprawdę nie potrzebują RTOS pod nimi .

Więc teraz jestem naprawdę zdezorientowany i kwestionuję niektóre moje podstawowe rozumienie teorii obliczeń. Chyba próbuję podjąć decyzję, czy w ogóle użyć Embox / RIOT:

• Pozostań na kursie i korzystaj z „stosu aplikacji” na MCU obu aplikacji OS +; lub
• Posłuchaj ostrzeżenia tego artykułu i po prostu skorzystaj z MCU z uruchomioną aplikacją „bare metal”

Oczywiście pierwsza z nich to więcej pracy, więc lepiej mieć dobry powód / korzyści z pójścia tą drogą. Pytam więc: jakie są rzeczywiste korzyści, jakie te (i podobne) osadzone RTOS oferują twórcom aplikacji MCU / C? Z jakich konkretnych funkcji mogłaby skorzystać moja aplikacja C (być może nie zmieniając kierownicy?) Dzięki zastosowaniu RTOS? Co zostaje utracone przez porzucenie RTOS i przejście na czysty metal?

Proszę o konkretne przykłady tutaj, a nie o medialny szum, który pojawia się, gdy przechodzisz do wpisu wikipedii dla RTOS ;-)

Programy mikrokontrolera składają się z szeregu zadań . Powiedzmy, że chciałeś wykonać teleskopowy uchwyt teleskopowy. Do zadań należałoby:

• Pobierz nowy bajt danych wejściowych z bufora szeregowego USB.
• Sprawdź, czy otrzymaliśmy kompletne polecenie.
• Jeśli tak, wykonaj to polecenie.
• Odczytaj czujniki aktualnej pozycji teleskopu.
• Ustaw odpowiednią moc wyjściową, aby kontrolować następny krok silników.

Jest to dość typowy zestaw zadań dla czegoś, do czego byłby używany mikrokontroler, i są dość łatwe do zarządzania za pomocą nieskończonej pętli, na przykład:

while(TRUE) {
  uint8_t input = readUsbBuffer();
  parseCommand(input);
  readSensors();
  setMotors();
}

Jeśli będziesz dodawać i dodawać funkcje, w końcu zaczniesz napotykać typowe problemy, dla których chcesz tworzyć abstrakcje, takie jak:

• Twój bufor jest przepełniony, więc chcesz się upewnić, że zadanie może przerwać inne zadania, zanim się przepełni.
• Chcesz oszczędzać baterię, śpiąc, gdy nic nie jest potrzebne.
• Chcesz mieć pewność, że wszystkie zadania zostaną wykonane prawidłowo. Jeśli readSensorstrwa to zbyt długo, chcesz móc przerwać i wrócić do tego później.
• Chcesz móc zresetować jedno zadanie bez wpływu na inne.
• Chcesz, aby wyciek pamięci lub inny błąd w jednym zadaniu nie usuwał innych zadań.
• Chcesz mieć możliwość przydzielania różnym priorytetom różnych zadań.
• Chcesz mieć możliwość piaskownicy niezaufanego zadania.
• Chcesz móc wykonywać zadania w różnym tempie. Być może twoje czujniki można odczytać tylko 10 razy na sekundę, ale chcesz wykonać krok silnika 100 razy na sekundę.

Jeden lub dwa z tych elementów można stosunkowo łatwo obsługiwać ręcznie. Jeśli masz dość tego rodzaju problemów na tyle często, że zaczynasz uogólniać je na biblioteki, w zasadzie wymyśliłeś RTOS. Jeśli zarządzanie zadaniami twojego programu jest wystarczająco złożone, nawet jeśli nie korzystasz z gotowego systemu RTOS, ostatecznie nie uda ci się go odkryć na nowo.

Jednak z mojego doświadczenia wynika, że ​​linia, w której chcesz mieć RTOS, jest bardzo zbliżona do linii, w której chcesz mikroprocesor zamiast mikrokontrolera. Jeśli spodziewasz się, że oprogramowanie układowe stanie się tak skomplikowane, zwykle lepiej jest przejść od początku do mikroprocesora.

Napisałem własną bibliotekę wielowątkową dla ARM Cortex-M0.

Było to zaledwie kilka stron kodu, a pierwsza jego wersja nie trwała dłużej niż jeden dzień do pisania i debugowania.

Dużą zaletą roll-your-own jest to, że znasz kod i możesz go przenieść do układów, które RTOS może nie obsługiwać. Poza tym spędzasz mniej czasu na zastanawianiu się nad pytaniami typu „czy to się zawiesi. Próbuję jednocześnie używać funkcji A i B.” Ponieważ napisałeś kod, znasz odpowiedź.

Wątek jest najważniejszą rzeczą, jaką otrzymujesz z RTOS, i okazuje się, że nie jest to taka wielka sprawa do wdrożenia. Rzadko potrzebujesz wielu funkcji RTOS. Ale jeśli nie spełnisz swoich wymagań i okaże się, że tak, skorzystaj z RTOS.