Kiedy potrzebujemy systemu operacyjnego w projekcie systemu wbudowanego?

Napisałem dużo czystego kodu dla procesorów PIC i x86. Czy ktoś może mi powiedzieć, jak i kiedy powinienem potrzebować systemu operacyjnego? I odwrotnie, z jaką aplikacją lub sytuacją można sobie poradzić, czy bez systemu operacyjnego?

Moja ogólna zasada polega na tym, że powinieneś rozważyć system operacyjny, jeśli produkt wymaga jednego lub więcej z poniższych: stosu TCP / IP (lub innego złożonego stosu sieciowego), złożonego interfejsu GUI (być może takiego z obiektami GUI, takimi jak okna i zdarzenia ) lub system plików.

Jeśli kodowałeś goły metal, prawdopodobnie znasz architekturę programu super-loop . Jeśli wymagania dotyczące oprogramowania układowego produktu są wystarczająco proste, aby można je było wdrożyć za pomocą super-pętli, którą można utrzymywać (i miejmy nadzieję rozszerzalną), prawdopodobnie nie potrzebujesz systemu operacyjnego.

Wraz ze wzrostem wymagań oprogramowania super-pętla staje się coraz bardziej złożona. Gdy wymagania programowe są tak liczne, że super-pętla staje się zbyt złożona lub nie może spełnić wymagań systemu w czasie rzeczywistym, nadszedł czas, aby rozważyć inną architekturę.

Architektura RTOS pozwala podzielić wymagania dotyczące oprogramowania na zadania. Prawidłowe wykonanie upraszcza realizację każdego zadania. A dzięki ustalaniu priorytetów zadań RTOS może ułatwić spełnienie wymagań w czasie rzeczywistym. RTOS nie jest jednak panaceum. RTOS zwiększa ogólną złożoność systemu i otwiera cię na nowe rodzaje błędów (np. Zakleszczenia). Jako alternatywę dla RTOS można rozważyć i opartą na zdarzeniach architekturę maszyn stanów (takich jak QP ).

Jeśli twój produkt ma sieć, złożony GUI i system plików, możesz być w punkcie, w którym powinieneś rozważyć w pełni funkcjonalne systemy operacyjne, takie jak VxWorks, Windows lub Linux. W pełni funkcjonalne systemy operacyjne będą zawierały sterowniki dla szczegółów niskiego poziomu i pozwolą skupić się na aplikacji.

To naprawdę zależy od twojej definicji „systemu osadzonego”. Być może niektórzy twierdzą, że jeśli nie jest to programowanie bez systemu operacyjnego, nie jest ono osadzone (co wyklucza twoje pytanie), ale nie zgadzam się z tym - argumentowałbym, że każdy system, który jest przeznaczony do wykonywania tylko jednej funkcji, tzn. aby uruchomić tylko jedną konkretną „aplikację”, można ją nazwać systemem osadzonym.

To powiedziawszy, powinno być dość łatwo wyobrazić sobie sytuacje, które skorzystałyby z usług pełnego systemu operacyjnego. Na przykład tam, gdzie pracuję, dość często zdarza się, że ludzie budują sprzęt testowy na pakiecie do projektowania oprzyrządowania, który działa na oknach. Systemy te są skonfigurowane do uruchamiania w konfiguracji stacji testowej i blokują ogólne użycie (aby zapobiec uszkodzeniu stacji) i prawdopodobnie są to systemy osadzone.

Jednak samo kupowanie gotowych modułów we / wy, podłączanie ich do komputera do montażu w stojaku i rozbudowywanie konfiguracji w graficznym interfejsie użytkownika może nie kwalifikować się jako projekt systemu wbudowanego . W przypadku nieco mniej gotowej sytuacji rozważ niestandardowy kontroler procesu z układem FPGA, dla którego chcesz wykonać fantazyjne rejestrowanie danych. Możesz osadzić soft-core procesor (z istniejącym BSP) i uruchomić linux w czasie rzeczywistym, aby uruchomić stos sieciowy (do logowania i NTP itp.) I zrobić wszystko inne w logice.

Moja (bardzo niejasna) zasada jest taka, że ​​jeśli potrzebujesz więcej niż jednego wątku kontroli (powiedz co najmniej jedno urządzenie, które wymaga protokołu lub automatu stanów plus coś innego do zrobienia), wtedy niektóre z oprogramowania OSish ułatwi ci życie

Stare pytanie, ale i tak skomentuję.

Nawet jeśli nie masz stosów sieciowych lub podobnych, w miejscu, w którym potrzebujesz harmonogramu zadań, ponieważ masz wystarczająco dużo procesów we wbudowanej aplikacji, możesz rozważyć RTOS. Pisanie prostego harmonogramu wielozadaniowości opartej na liczniku czasu nie jest trudne, ale upewnienie się, że zablokowany proces nie zablokuje pozostałej części aplikacji, i takie może zająć trochę czasu, zanim wszystko będzie dobrze. Musisz zaimplementować system priorytetowy z pewnym rodzajem zabezpieczenia, aby spowolnić procesy w kolejce, jeśli się nie zakończyły.

RTOS zapewnia również takie funkcje, jak ochrona pamięci i tym podobne, co znacznie ułatwia śledzenie niektórych typowych gaf w kodzie C, ale proste mikrokontrolery mogą po prostu nie być w stanie poradzić sobie ze złożoną ochroną pamięci. Np. MSP430 pozwala oddzielić kod i dane na wysokim poziomie, ale nie ma precyzyjnej kontroli dostępu do pamięci.

System operacyjny faktycznie wypełnia lukę między sprzętem a oprogramowaniem (poprzez sterownik urządzenia). Innymi słowy, zapewnia programistom platformę stosunkowo wysokiego poziomu, co ostatecznie zmniejsza złożoność kodu. Ponadto system operacyjny zapewnia silną i elastyczną platformę do wykonywania aplikacji.