Dlaczego miałbym rozważyć użycie RTO dla mojego wbudowanego projektu?

Istnieje wiele powodów, dla których warto użyć RTO. Są one zróżnicowane i trudno powiedzieć, w jakim stopniu odnoszą się do twojej sytuacji. (Uwaga: mam tendencję do myślenia w ten sposób: RTOS implikuje twardy czas rzeczywisty, który implikuje preemptive kernel...)

• Rate Monotonic Analysis (RMA) - jeśli chcesz użyć Rate monotonic Analysis , aby zapewnić dotrzymanie terminów, musisz użyć prewencyjnego scheduler

• Dotrzymywanie terminów w czasie rzeczywistym - nawet bez korzystania z RMA, z pierwszeństwem RTO opartym na priorytetach, twój harmonogram może pomóc zapewnić dotrzymanie terminów. Paradoksalnie, RTO zazwyczaj zwiększa opóźnienie przerwania ze względu na sekcje krytyczne w jądrze, gdzie przerwania są zwykle maskowane

• Zarządzanie złożonością -- zdecydowanie RTO (lub większość smaków systemu operacyjnego) może w tym pomóc. Pozwalając projektowi na rozłożone na niezależne wątki lub procesy, i za pomocą usług systemu operacyjnego, takich jak kolejki wiadomości, muteksy, semafory, flagi zdarzeń, itp. aby komunikować się i synchronizować, Twój projekt (z mojego doświadczenia i opinii) staje się łatwiejszy do zarządzania. Pracuję nad większymi projektami, w których większość ludzi rozumie koncepcję ochrony wspólnych zasobów, więc wiele błędów rookie się nie zdarza. Ale uważaj, gdy przejdziesz do podejścia wielowątkowego, sprawy mogą stać się bardziej złożone, dopóki nie owiniesz głowy wokół problemów.

• Korzystanie z pakietów innych firm - wiele RTOSs oferuje inne komponenty oprogramowania, takie jak stosy protokołów, systemy plików, sterowniki urządzeń, Pakiety GUI, bootloadery i inne oprogramowanie pośredniczące, które pomagają budować aplikację szybciej, stając się prawie bardziej "integratorem" niż sklepem dla MAJSTERKOWICZÓW.

• Testowanie - tak, zdecydowanie można myśleć o każdym wątku sterowania jako testowalnym komponencie z dobrze zdefiniowanym interfejsem, zwłaszcza jeśli stosowane jest spójne podejście(np. zawsze blokowanie w jednym miejscu w kolejce komunikatów). Oczywiście nie jest to substytut jednostki, integracji, systemu itp. testuję.

• Robustness / fault tolerance - RTO może również zapewnić wsparcie dla MMU procesora (w Twoim przypadku PIC, to chyba nie ma zastosowania). Pozwala to każdemu wątkowi (lub procesowi) działać we własnej chronionej przestrzeni; wątki / procesy nie mogą "zanurzać się" w pamięci innych i deptać po niej. Parzyste regiony urządzeń (MMIO) mogą być wyłączone dla niektórych (lub wszystkich) wątków. Ściśle mówiąc, nie potrzebujesz RTO, aby wykorzystać MMU procesora (lub MPU), ale 2 działają bardzo dobrze ręka w rękę.

Ogólnie rzecz biorąc, kiedy mogę rozwijać się za pomocą RTO (lub jakiegoś typu prewencyjnego wielozadaniowego), wynik wydaje się być czystszy, bardziej modułowy, bardziej zachowawczy i łatwiejszy do utrzymania. Kiedy mam taką opcję, używam jej.

Należy pamiętać, że rozwój wielowątkowy ma trochę nauki krzywa. Jeśli dopiero zaczynasz korzystać z RTO/multithreaded development, możesz zainteresować się artykułami na temat wyboru RTO, [12]}I[57]} Wprowadzenie do prewencyjnego wielozadaniowości [12]}.

Wreszcie, mimo że nie prosiłeś o rekomendacje... Oprócz wielu komercyjnych RTOS, istnieją darmowe oferty (FreeRTOS będąc jednym z najpopularniejszych), A Quantum Platform jest frameworkiem sterowanym zdarzeniami bazuje na koncepcji obiektów aktywnych , która zawiera jądro prewencyjne. Istnieje wiele opcji, ale odkryłem, że posiadanie kodu źródłowego (nawet jeśli RTO nie jest wolne) jest korzystne, esp. podczas debugowania.