Rozpocznijmy odpowiedź na to pytanie od spojrzenia wstecz na epokę programowania "bare-metal". Czym jest tego rodzaju programowanie? W informatyce "gołe urządzenie" odnosi się do procesora wykonującego instrukcje bezpośrednio na fizycznym sprzęcie logicznym bez interweniującego systemu operacyjnego. Oznacza to, że program "bare-metal" działa bezpośrednio na fizycznym procesorze. Autor artykułu wspomina swoje początki z programowanie dla systemów wbudowanych - około 2008 roku zaczynał on na studiach od pisania programów dla mikrokontrolerów opartych na architekturze '51 (od układu 8051). Jednakże, odkąd skończył studia informatyczne, większość jego programów była wykonywana na komputerze PC. To było zupełnie inne doświadczenie - programy działające na samym procesorze to zarówno zupełnie inne podejście, inny sposób myślenia, jak i problemy, typowe dla tego oprogramowania. Można pogrupować je w kilka zbiorów:
Konkurencja
W przypadku programów typu bare-metal istnieje gdzieś w kodzie nieuchronnie ogromna pętla while (1), która zawiera niemalże całą logikę całego projektu. Każda operacja w niej wywołuje jedną lub więcej funkcji opóźniających i są one wykonywane szeregowo, gdy CPU uruchamia funkcję opóźnienia, pozostałe operacje muszą czekać. W ten sposób większość czasu procesora jest tracona na puste pętle, co powoduje dość niską wydajność obliczeniową pisanego w ten sposób kodu.
Modułowość
Z perspektywy projektu całego oprogramowania, zasada wysokiej spójności i niskiego sprzężenia jest zawsze podkreślana w procesie rozwoju software. Jednak moduły w oprogramowaniu typu bare-metal zwykle są od siebie bardzo zależne – nie jest wygodne projektowanie oprogramowania ze słabo sprzężonymi elementami, co utrudnia tworzenie dużych projektów na systemach tego rodzaju. Wynika to między innymi z:
* Jak wspomniano powyżej - większość operacji systemu jest zebranych w ogromnej pętli while (1) i trudno jest ją podzielić na mniejsze moduły;
* Programiści muszą uważać, przy używaniu funkcji opóźniających, gdy używany jest zegar nadzorujący (watchdog). Jeśli czas opóźnienia jest zbyt długi, główna funkcja nie ma możliwości zresetowania watchdoga, wtedy podczas wykonywania jakiejś operacji uruchomiony zostanie watchdog.
Tak więc w przypadku programowania dla systemu bare-metal jest wiele rzeczy do analizy, nawet podczas wywoływania funkcji opóźnienia. Im bardziej złożony jest projekt, tym na więcej należy uważać.
Ekosystem
Wiele zaawansowanych składników oprogramowania musi zależeć od implementacji systemu operacyjnego niższego poziomu. Na przykład:
* Autor napisał, iż opracował projekt open-source oparty na „FreeModbus”, który planował przenieść na różne platformy, pod uwagę brano nawet płytki bare-metal. Jednak w porównaniu z wygodą dostosowania go do różnych systemów operacyjnych, niektóre funkcje są zbyt skomplikowane, aby można je było po prostu zaimplementować na wszystkich płytkach bez systemu operacyjnego. Z drugiej strony wiele implementacji musi być projektowanych od podstaw na różnych platformach sprzętowych ze względu na brak wspólnych elementów, co jest dosyć nudnym i czasochłonnym zadaniem. Na razie ta implementacja stosu Modbus nadal nie działa na płytkach bare-metal.
* Wiele zestawów programistycznych (SDK) dla interfejsu WiFi, dostarczanych przez duże firmy, takie jak Realtek, Texas Instruments czy MediaTek, można uruchomić tylko na systemie operacyjnym. Nie publikują oni kodu źródłowego dla oprogramowania sprzętowego do modyfikacji przez użytkownika, więc nie można ich używać w środowisku bare-metal.
Czas rzeczywisty
W przypadku niektórych obszarów aplikacji konieczna jest obsługa systemu pracującego w czasie rzeczywistym. W takiej sytuacji niektóre krytyczne kroki oprogramowania muszą zostać uruchomione w dokładnie określonym czasie. Na przykład w systemach sterowania przemysłowego urządzenia mechaniczne muszą wykonywać swoje działania we wcześniej ustalonej kolejności i w określonym czasie. Jeśli nie można zapewnić deterministycznej możliwości pracy w czasie rzeczywistym, system ulec może awarii, która może np. zagrozić życiu pracowników. Na platformach bare-metal, gdy wszystkie funkcje są zablokowane w jednej dużej pętli while (1), niemożliwe jest utrzymanie pracy w czasie rzeczywistym.
Możliwość ponownego użycia
Możliwość ponownego wykorzystania kodu zależy bezpośrednio od modułowości. Jasnym jest, że nikt nie chciałby wielokrotnie wykonywać tej samej pracy, zwłaszcza podczas pisania kodu. Ale na różnych platformach sprzętowych z różnymi chipami ta sama funkcja musi być inaczej implementowana, z uwagi na konieczność dostosowana systemu do innego sprzętu, którego implementacje w dużym stopniu zależą od sposobu realizacji systemów niskopoziomowych. Czasami koniecznym jest wynajdywanie koła na nowo.
Zalety systemów operacyjnych
Jak wspomina autor artykułu, w 2010 roku, po raz pierwszy użył on systemu operacyjnego na platformie wbudowanej. Seria mikrokontrolerów STM32 zaczęła być wtedy popularna, a wraz z nimi systemy operacyjne dla mikrokontrolerów. Dzięki ich zaawansowanym funkcjom wiele osób używało na nich takich systemów. Autor w swoim projekcie wykorzystał system RT-Thread, dla którego dostępne jest wiele gotowych do użycia komponentów. Jest to, do dzisiaj, podstawowy system operacyjny dla mikrokontrolerów, z jakiego korzysta autor tekstu. Systemy operacyjne mają kilka zalet. Poniżej omówmy szereg z nich:
Modułowość
W systemie operacyjnym całe oprogramowanie można podzielić na wiele zadań (zwanych wątkami), każdy wątek ma własną niezależną przestrzeń do wykonywania go. Są one od siebie zupełnie niezależne, co poprawia modułowość całego kodu.
Konkurencja
Gdy wątek wywołuje funkcję opóźnienia, automatycznie przekazuje wolny procesor innym potrzebującym wątkom, co poprawia wykorzystanie całego procesora i ostatecznie współbieżność wykonywania programu.
Czas rzeczywisty
System RTOS (ang. system operacyjny czasu rzeczywistego) został zaprojektowany jako zoptymalizowany system operacyjny dla pracy w czasie deterministycznym. Każdy wątek wykonywany przez procesor ma swój określony priorytet. Ważniejsze wątki mają wyższy priorytet, mniej ważne wątki mają niższy. W ten sposób gwarantowana jest wysoka wydajność całego oprogramowania w czasie rzeczywistym.
Efektywność rozwoju
System operacyjny zapewnia zunifikowaną warstwę abstrakcji dla różnych interfejsów, co ułatwia gromadzenie komponentów programowych wielokrotnego użytku i poprawia wydajność programowania.
System operacyjny jest wytworem mądrości grupy deweloperów. Wiele typowych funkcji oprogramowania, takich jak semafory, powiadamianie o zdarzeniach, skrzynka pocztowa, bufor pierścieniowy, lista łańcuchów jednokierunkowych czy lista dwukierunkowa itd. są wpisane w system operacyjny, gdzie tworzą pewną warstwę abstrakcji w celu przygotowania tych funkcji do użycia.
Systemy operacyjne, takie jak Linux czy RT-Thread, implementują standardowy zestaw interfejsów sprzętowych dla sprzętu, znany jako struktura sterowników urządzenia. Dlatego też inżynierowie oprogramowania muszą tylko skupić się na rozwoju swojego software i nie muszą się już martwić o podstawową obsługę sprzętu czy na nowo wynajdować koło.
Ekosystem oprogramowania
Bogactwo ekosystemu tworzenia oprogramowania przenosi proces zmian ilościowych na zmiany jakościowe. Poprawa modułowości i możliwości ponownego wykorzystania kodu w systemach operacyjnych pozwala na hermetyzację, opartych na systemie operacyjnym, przyjaznych dla elementów wbudowanych, komponentów programowych wielokrotnego użytku, które nie tylko mogą być używane w projektach oprogramowania wysokopoziomowego, ale także mogą być udostępniane potrzebującym programistom wbudowanym - maksymalizując wartość tworzonego przez nich oprogramowanie.
Autor, jako ogromny fan otwartego oprogramowania, udostępnia wiele software na swoim repozytorium na GitHubie. Zanim zaczął udostępniać oprogramowanie typu open source rzadko rozmawiał z innymi o swoich projektach, ponieważ uważał, że ponieważ ludzie używają różnych chipów lub platform sprzętowych, kod taki jest z trudem przenaszalny na inny sprzęt. Dzięki systemom operacyjnym możliwość ponownego wykorzystania oprogramowania jest znacznie większa, a wielu ekspertów może teraz komunikować się ze sobą w sprawie tego samego projektu. Mogą oni być nawet z różnych krajów. To zachęca coraz więcej ludzi do dzielenia się swoją pracą i mówienia o swoich projektach.
Źródło: https://www.embedded.com/why-a-bare-metal-developer-moved-to-operating-systems/
Konkurencja
W przypadku programów typu bare-metal istnieje gdzieś w kodzie nieuchronnie ogromna pętla while (1), która zawiera niemalże całą logikę całego projektu. Każda operacja w niej wywołuje jedną lub więcej funkcji opóźniających i są one wykonywane szeregowo, gdy CPU uruchamia funkcję opóźnienia, pozostałe operacje muszą czekać. W ten sposób większość czasu procesora jest tracona na puste pętle, co powoduje dość niską wydajność obliczeniową pisanego w ten sposób kodu.
Modułowość
Z perspektywy projektu całego oprogramowania, zasada wysokiej spójności i niskiego sprzężenia jest zawsze podkreślana w procesie rozwoju software. Jednak moduły w oprogramowaniu typu bare-metal zwykle są od siebie bardzo zależne – nie jest wygodne projektowanie oprogramowania ze słabo sprzężonymi elementami, co utrudnia tworzenie dużych projektów na systemach tego rodzaju. Wynika to między innymi z:
* Jak wspomniano powyżej - większość operacji systemu jest zebranych w ogromnej pętli while (1) i trudno jest ją podzielić na mniejsze moduły;
* Programiści muszą uważać, przy używaniu funkcji opóźniających, gdy używany jest zegar nadzorujący (watchdog). Jeśli czas opóźnienia jest zbyt długi, główna funkcja nie ma możliwości zresetowania watchdoga, wtedy podczas wykonywania jakiejś operacji uruchomiony zostanie watchdog.
Tak więc w przypadku programowania dla systemu bare-metal jest wiele rzeczy do analizy, nawet podczas wywoływania funkcji opóźnienia. Im bardziej złożony jest projekt, tym na więcej należy uważać.
Ekosystem
Wiele zaawansowanych składników oprogramowania musi zależeć od implementacji systemu operacyjnego niższego poziomu. Na przykład:
* Autor napisał, iż opracował projekt open-source oparty na „FreeModbus”, który planował przenieść na różne platformy, pod uwagę brano nawet płytki bare-metal. Jednak w porównaniu z wygodą dostosowania go do różnych systemów operacyjnych, niektóre funkcje są zbyt skomplikowane, aby można je było po prostu zaimplementować na wszystkich płytkach bez systemu operacyjnego. Z drugiej strony wiele implementacji musi być projektowanych od podstaw na różnych platformach sprzętowych ze względu na brak wspólnych elementów, co jest dosyć nudnym i czasochłonnym zadaniem. Na razie ta implementacja stosu Modbus nadal nie działa na płytkach bare-metal.
* Wiele zestawów programistycznych (SDK) dla interfejsu WiFi, dostarczanych przez duże firmy, takie jak Realtek, Texas Instruments czy MediaTek, można uruchomić tylko na systemie operacyjnym. Nie publikują oni kodu źródłowego dla oprogramowania sprzętowego do modyfikacji przez użytkownika, więc nie można ich używać w środowisku bare-metal.
Czas rzeczywisty
W przypadku niektórych obszarów aplikacji konieczna jest obsługa systemu pracującego w czasie rzeczywistym. W takiej sytuacji niektóre krytyczne kroki oprogramowania muszą zostać uruchomione w dokładnie określonym czasie. Na przykład w systemach sterowania przemysłowego urządzenia mechaniczne muszą wykonywać swoje działania we wcześniej ustalonej kolejności i w określonym czasie. Jeśli nie można zapewnić deterministycznej możliwości pracy w czasie rzeczywistym, system ulec może awarii, która może np. zagrozić życiu pracowników. Na platformach bare-metal, gdy wszystkie funkcje są zablokowane w jednej dużej pętli while (1), niemożliwe jest utrzymanie pracy w czasie rzeczywistym.
Możliwość ponownego użycia
Możliwość ponownego wykorzystania kodu zależy bezpośrednio od modułowości. Jasnym jest, że nikt nie chciałby wielokrotnie wykonywać tej samej pracy, zwłaszcza podczas pisania kodu. Ale na różnych platformach sprzętowych z różnymi chipami ta sama funkcja musi być inaczej implementowana, z uwagi na konieczność dostosowana systemu do innego sprzętu, którego implementacje w dużym stopniu zależą od sposobu realizacji systemów niskopoziomowych. Czasami koniecznym jest wynajdywanie koła na nowo.
Zalety systemów operacyjnych
Jak wspomina autor artykułu, w 2010 roku, po raz pierwszy użył on systemu operacyjnego na platformie wbudowanej. Seria mikrokontrolerów STM32 zaczęła być wtedy popularna, a wraz z nimi systemy operacyjne dla mikrokontrolerów. Dzięki ich zaawansowanym funkcjom wiele osób używało na nich takich systemów. Autor w swoim projekcie wykorzystał system RT-Thread, dla którego dostępne jest wiele gotowych do użycia komponentów. Jest to, do dzisiaj, podstawowy system operacyjny dla mikrokontrolerów, z jakiego korzysta autor tekstu. Systemy operacyjne mają kilka zalet. Poniżej omówmy szereg z nich:
Modułowość
W systemie operacyjnym całe oprogramowanie można podzielić na wiele zadań (zwanych wątkami), każdy wątek ma własną niezależną przestrzeń do wykonywania go. Są one od siebie zupełnie niezależne, co poprawia modułowość całego kodu.
Konkurencja
Gdy wątek wywołuje funkcję opóźnienia, automatycznie przekazuje wolny procesor innym potrzebującym wątkom, co poprawia wykorzystanie całego procesora i ostatecznie współbieżność wykonywania programu.
Czas rzeczywisty
System RTOS (ang. system operacyjny czasu rzeczywistego) został zaprojektowany jako zoptymalizowany system operacyjny dla pracy w czasie deterministycznym. Każdy wątek wykonywany przez procesor ma swój określony priorytet. Ważniejsze wątki mają wyższy priorytet, mniej ważne wątki mają niższy. W ten sposób gwarantowana jest wysoka wydajność całego oprogramowania w czasie rzeczywistym.
Efektywność rozwoju
System operacyjny zapewnia zunifikowaną warstwę abstrakcji dla różnych interfejsów, co ułatwia gromadzenie komponentów programowych wielokrotnego użytku i poprawia wydajność programowania.
System operacyjny jest wytworem mądrości grupy deweloperów. Wiele typowych funkcji oprogramowania, takich jak semafory, powiadamianie o zdarzeniach, skrzynka pocztowa, bufor pierścieniowy, lista łańcuchów jednokierunkowych czy lista dwukierunkowa itd. są wpisane w system operacyjny, gdzie tworzą pewną warstwę abstrakcji w celu przygotowania tych funkcji do użycia.
Systemy operacyjne, takie jak Linux czy RT-Thread, implementują standardowy zestaw interfejsów sprzętowych dla sprzętu, znany jako struktura sterowników urządzenia. Dlatego też inżynierowie oprogramowania muszą tylko skupić się na rozwoju swojego software i nie muszą się już martwić o podstawową obsługę sprzętu czy na nowo wynajdować koło.
Ekosystem oprogramowania
Bogactwo ekosystemu tworzenia oprogramowania przenosi proces zmian ilościowych na zmiany jakościowe. Poprawa modułowości i możliwości ponownego wykorzystania kodu w systemach operacyjnych pozwala na hermetyzację, opartych na systemie operacyjnym, przyjaznych dla elementów wbudowanych, komponentów programowych wielokrotnego użytku, które nie tylko mogą być używane w projektach oprogramowania wysokopoziomowego, ale także mogą być udostępniane potrzebującym programistom wbudowanym - maksymalizując wartość tworzonego przez nich oprogramowanie.
Autor, jako ogromny fan otwartego oprogramowania, udostępnia wiele software na swoim repozytorium na GitHubie. Zanim zaczął udostępniać oprogramowanie typu open source rzadko rozmawiał z innymi o swoich projektach, ponieważ uważał, że ponieważ ludzie używają różnych chipów lub platform sprzętowych, kod taki jest z trudem przenaszalny na inny sprzęt. Dzięki systemom operacyjnym możliwość ponownego wykorzystania oprogramowania jest znacznie większa, a wielu ekspertów może teraz komunikować się ze sobą w sprawie tego samego projektu. Mogą oni być nawet z różnych krajów. To zachęca coraz więcej ludzi do dzielenia się swoją pracą i mówienia o swoich projektach.
Źródło: https://www.embedded.com/why-a-bare-metal-developer-moved-to-operating-systems/
