Kiedy potrzebujemy systemu operacyjnego w projekcie systemu wbudowanego?

22

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?

quantum231
źródło
2
Ponieważ nie wszystko, co musisz wiedzieć, uczy się w szkole. Jeśli uważasz, że musisz nauczyć się RTOS, wybierz platformę i naucz się jej.
Scott Seidman,
3
Pytanie o korzystanie z systemu operacyjnego we wbudowanym jest prawidłowe. Jednak EE.SE nie może ci pomóc w „dlaczego nie nauczyli mnie tego w szkole?” część. Pozwoliłem sobie to edytować.
Nick Alexeev
Cóż, jedynym powodem, dla którego spytałem o to, dlaczego nie uczyłem tego na moim uniwersytecie, jest to, że nigdy nie spotkałem jeszcze żadnego studenta EE, który mógłby zrobić na uniwersytecie. Wydaje mi się więc, że wcale nie odbywa się to na żadnym uniwersytecie.
quantum231
@ quantum231 Zrobiono to na moim uniwersytecie, NTNU - Norwegia.
CK

Odpowiedzi:

23

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.

kkrambo
źródło
8

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.

JustJeff
źródło
7

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

Taniwha
źródło
Konfiguracja RTOS wymaga pewnej pracy. O ile wysiłek związany z używaniem switchautomatów stanowych nie przekracza tego, switchmaszyny oparte na komputerach mogą być lepsze. Ponadto na platformach 8x51 i TMS2000 zaimplementowałem prosty oparty na stosach przełącznik współpracy. Brak logiki systemu operacyjnego, która decydowałaby, kiedy zmienić - za każdym razem, gdy jeden „wątek” uzna, że ​​może to zrobić przerwę, przełączy się na inny. Gdyby ten drugi wątek zauważył, że coś, na co czekał, jeszcze się nie wydarzyło, mógłby wrócić do pierwszego w krótszym czasie niż normalny system operacyjny spędziłby na decydowaniu o zmianie.
supercat
Warto rozróżnić prawdziwy „wielowątkowy” programowy „wątek” (który mocno wskazuje na system operacyjny) w porównaniu do prostszego przerwania odpowiadającego na stan sprzętowy.
Chris Stratton,
1

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.

Barleyman
źródło
0

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.

jak gdyby
źródło