logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Dlaczego programiści bare-metal przenoszą się na systemy operacyjne

ghost666 04 Sie 2020 16:37 4893 22
  • Dlaczego programiści bare-metal przenoszą się na systemy operacyjne
    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/
    O autorze
    ghost666
    Tłumacz Redaktor
    Offline 
    Fizyk z wykształcenia. Po zrobieniu doktoratu i dwóch latach pracy na uczelni, przeszedł do sektora prywatnego, gdzie zajmuje się projektowaniem urządzeń elektronicznych i programowaniem. Od 2003 roku na forum Elektroda.pl, od 2008 roku członek zespołu redakcyjnego.
    https://twitter.com/Moonstreet_Labs
    ghost666 napisał 11960 postów o ocenie 10197, pomógł 157 razy. Mieszka w mieście Warszawa. Jest z nami od 2003 roku.
  • #2 18854168
    m7m
    Poziom 12  
    Jak przeczytałem, że w systemach wbudowanych bez OS-a wszystko sprowadza się do jednej ogromnej pętli while, w której jest ukryta cała logika wykonywana szeregowo to stwierdziłem, że nie ma po co czytać dalej. Może dalej prawdę piszą, ale do tego momentu to bajki.
  • #3 18854240
    bobycob
    Poziom 21  
    Dziś przez "bare-metal" rozumie się często uruchomienie oprogramowania na maszynie fizycznej, a nie na wirtualnej.
  • #4 18854321
    szymon122
    Poziom 38  
    Z ciekawości to czy orientuje się ktoś, czy na współczesnych procesorach typu Intel i5 jest możliwość programowania właśnie w ten sposób? Pomińmy sens czegoś takiego, chodzi mi o to jak miałoby się to odbyć. Podczas rozruchu płyta główna próbuje znaleźć na dyskach system do uruchomienia. Jak zatem miałoby wyglądać bezpośrednio uruchomienie programu?
    Pozdrawiam.
  • #5 18854326
    bobycob
    Poziom 21  
    przykładem takiego programu może być:
    GRUB, memtest86+
    Bardziej bezpośrednio - piszesz bios ;)
    -------------- auto korekta ----------
  • #6 18854352
    fifi_22
    Poziom 8  
    Programy bare-metal wcale nie muszą być blokującymi krowami! Wystarczy trochę pomysłowości, przerwanie od timera i można robić prawie "wielowątkowe" cuda. Zresztą na małych prockach embedded jest to jedyne możliwe wyjście ze względu na brak np. pamięci. Cieszę się, że są jeszcze ludzie potrafiący zamigać przysłowiową diodą bez użycia OS-a.
  • #7 18854445
    khoam
    Poziom 42  
    fifi_22 napisał:
    Wystarczy trochę pomysłowości, przerwanie od timera i można robić prawie "wielowątkowe" cuda.

    Czyli napisać taki mini-OS :) Cały problem w tego rodzaju dyskusjach jest postawienie granicy pomiędzy tym, co jeszcze nie jest OS, a tym co już jest.
  • #8 18854631
    elektronik999
    Poziom 26  
    szymon122 napisał:
    procesorach typu Intel i5


    A mnie bardziej ciekawi ten firmware który w nich jest
  • #9 18854754
    Cersunited
    Poziom 16  
    khoam napisał:
    fifi_22 napisał:
    Wystarczy trochę pomysłowości, przerwanie od timera i można robić prawie "wielowątkowe" cuda.

    Czyli napisać taki mini-OS :) Cały problem w tego rodzaju dyskusjach jest postawienie granicy pomiędzy tym, co jeszcze nie jest OS, a tym co już jest.


    Tu chodzi bardziej o wygodę, szybkość tworzenia oprogramowania oraz debugowania. Również programistów łatwiej znaleźć dla danego RTOS'a niż dla konkretnego układu pod bare metal. Z tym "while" to głupota, równocześnie tak samo kiepski soft może być z OS'em. System operacyjny nie ma jakichś "magicznych mocy", sam jest oprogramowaniem działającym pomiędzy naszym kodem a sprzętem. OS to nie tylko zastąpienie "sleep'ów" i magiczna współbieżność, której nie da się dobrze zrobić na bare metal - a to trochę wynika z artykułu:) Są aplikacje gdzie FreeRTOS czy nawet WRS VXWorks nie wystarcza, jak również moduły które muszą być bare-metal, więc jednak chyba się da ;)
  • #10 18854896
    __Kai__
    Poziom 11  
    m7m napisał:
    Witam.
    Jak przeczytałem że w systemach wbudowanych bez os'u wszystko sprowadza się do jednej ogromnej pętli while w której jest ukryta cała logika wykonywana szeregowo to stwierdziłem że nie ma po co czytać dalej.
    Może dalej prawdę piszą ale do tego momentu to bajki.


    Nooo, a gdzie przerwania od timerów, które są dość dokładne? Czy nawet od sygnałów zewnętrznych... Jak się dobrze przyłożyć do szybkiego mikrokontrolera, to można uzyskać pseudo wielowątkowość...
  • #11 18854988
    elektryku5
    Poziom 39  
    Proste programy na uC da się tak pisać, że jedna pętla while czasem dodatkowo jakiś timer są w stanie całkiem wydajnie działać, starczy tak pisać funkcje, by nie blokowały na długi czas pętli głównej, w aplikacjach gdzie czasy nie są krytyczne sprawdzało mi się to nieźle.
  • #12 18855095
    khoam
    Poziom 42  
    Cersunited napisał:
    Również programistów łatwiej znaleźć dla danego RTOS'a niż dla konkretnego układu pod bare metal.

    Tu też jest bardzo cienka granica. Zwykle znajomość RTOS na danej architekturze sprzętowej to trochę za mało - trzeba się posiłkować rozwiązaniami typu "bare metal", trzeba mieć też wiedzę o ograniczeniach RTOS w danej architekturze.
  • #13 18855120
    OldSkull
    Poziom 28  
    ghost666 napisał:
    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.

    Jezu, jaka bzdura, a o przerwaniach oraz usypianiu procesora, cz zmianie trybów pracy w trakcie pracy to autor oryginalny nie słyszał? Sam popełniałem programy, w któych w While(1) kręciło się tylko zerowanie watchdoga i jakieś sprawdzanie czy się któreś przerwanie nie popsuło (co i tak z czasem kasowałem lub odchudzałem, gdy się okazywało, że wszystko działa). Do tego czasem ewentualnie wywoływanie (na podstawie zapisów z Timera) jakichś zdarzeń, które miały być wykonywane do określony, ale dość długi czas.

    ghost666 napisał:
    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.

    I kolejne bzdury. Właśnie przerwania z określonymi priorytetami daja gwarancję, że jakieś zadanie będzie wykonane zawsze. RTOSy mają często to do siebie, że jest dobrze dopóki jest dobrze, potem cały system się może wywalić przez jeden-kilka złych procesów. W systemie z przerwaniami zablokowaniu ulegną tylko te z niższym priorytetem.

    Generalnie autor ma trochę racji, ale używa zbyt wielu argumentów "z czapy". Pisze jakby ostatni raz "bare-metal" pisał na 8051 i kompletnie przespał epokę popularności tanich 8b AVR i Pic oraz tanich ARMów.

    OS jest lepszy w wielu aplikacjach przez wygodę. Na słabszych procesorach moze nie mieć sensu (bo. np. ograniczy z 20-40% mocy obliczeniowej i z 10-20% RAM, jak nie więcej), ale na mocniejszych przyspieszy pisanie oprogramowania. Szczególnie jesli procesów byłoby bardzo wiele. Generalnie zasada jest taka, że wszystko co można zrobić na OS, można zrobić i bez niego (tyle, że dłużej to zajmie), ale tylko część rzeczy, które można zrobić "bare-metal" można zrobić korzystając z OS.
    Moim zdaniem o ile jakieś normy nie narzucają czegoś przy korzystaniu z OS, to dla małych wolumenów produkcyjnych warto go używać (i zapłacić z 2 USD więcej za mocniejszy procesor), bo czas inżyniera i opóźnienie wdrożenia projektu kosztuje zbyt dużo. Ale jak ma być klepane milion sztuk lub więcej, to lepiej się przyłożyć na tańszym procesorze bez OS. Pomijam tutaj oczywiście wszelkie aplikacje, gdzie mamy potężny procesor (nawet i z 500MHz) dużo RAM i spore wymagania "wizualne" lub gotowe biblioteki pod OSy.
  • #14 18855287
    khoam
    Poziom 42  
    OldSkull napisał:
    Właśnie przerwania z określonymi priorytetami daja gwarancję, że jakieś zadanie będzie wykonane zawsze. RTOSy mają często to do siebie, że jest dobrze dopóki jest dobrze, potem cały system się może wywalić przez jeden-kilka złych procesów. W systemie z przerwaniami zablokowaniu ulegną tylko te z niższym priorytetem.

    W programach działających w oparciu o RTOS też wykorzystuje się przerwania z priorytetami. RTOS zazwyczaj umożliwia korzystanie z ISR, ponieważ automatycznie obsługuje operacje niskiego poziomu, takie jak zapisywanie i przywracanie kontekstu, co dodatkowo upraszcza tworzenie ISR. Używanie przerwań nie jest jakąś szczególną cechą tylko programowania "bare-metal".
  • #15 18855551
    Konto nie istnieje
    Poziom 1  
  • #16 18856257
    alek25
    Poziom 25  
    Od kiedy pamiętam czyli od ZX Spektrum czy C64 to nie pętla determinowała pracę procesora a system przerwań cyklicznie wywołujący procedury systemowe.
  • #17 18856304
    khoam
    Poziom 42  
    alek25 napisał:
    to nie pętla determinowała pracę procesora a system przerwań cyklicznie wywołujący procedury systemowe.

    Pętla nie determinuje pracy procesora, pętla nie pozwala na zakończeniu programu :)
  • #18 18856794
    koczis_ws
    Poziom 27  
    W sumie jak mi się wydaje OS to taki program"bare-metal" do którego wplecione są operacje aplikacji. Czyli da sie również bezpośrednio napisać efektywny program bo w końcu OS też ktoś napisał :)
  • #19 18856827
    Konto nie istnieje
    Poziom 1  
  • #20 18860408
    kaczodp
    Poziom 14  
    Jak nie potrafi się dobrze napisa programu bare-metal to i OS nie pomoże, może.
  • #21 18862376
    kuku
    Poziom 13  
    szymon122 napisał:
    Z ciekawości to czy orientuje się ktoś, czy na współczesnych procesorach typu Intel i5 jest możliwość programowania właśnie w ten sposób? Pomińmy sens czegoś takiego, chodzi mi o to jak miałoby się to odbyć. Podczas rozruchu płyta główna próbuje znaleźć na dyskach system do uruchomienia. Jak zatem miałoby wyglądać bezpośrednio uruchomienie programu?
    Pozdrawiam.

    szukaj bare metal na githubie - pierwsze co mi przyszlo do glowy to pong:
    https://github.com/spacerace/x86-pong
    tutaj wiecej przykladow:
    https://github.com/cirosantilli/x86-bare-metal-examples
  • #22 18870100
    JasiuQ
    Poziom 1  
    Typowa akademicka dyskusja o wyższości świąt wielkanocy nad Bożego Narodzenia. Czym jest OS, jak nie wielką pętlą while z mnóstwem nieużywanych funkcji w przypadku implementacji prostego algorytmu do sterownika? Dobór narzędzi (tutaj kodu) dobieramy pod kątem dostępnych zasobów. Jak stać nas na rozrzutność w postaci megabajtów pamięci oraz niepewność w czasie wykonania procesu - to OS, bo nawet koder w pythonie jest w stanie coś wyklepać. Jeśli mówimy o zadaniach realtimowych i niezawodnym kodzie - to programowanie niskopoziomowe i przerwania. Stosunek zajętości pamięci 10:1 (100:1 jak jeszcze jakis pyton czy jawa trzeba dodać). Szybkość wykonania: zwykle 10:1 (poprawny kod niskopoziomowy vs wysokopoziomowe języki). Niezawodność - no cóż, te wysokopziomowe działają, czasem. Nie jest to problemem w rejestratorze temperatury w pokoju, ale dla sterownika od poduszek w samochodzie?
  • #23 18870374
    Konto nie istnieje
    Poziom 1  

Podsumowanie tematu

Dyskusja dotyczy przejścia programistów z programowania "bare-metal" na systemy operacyjne (OS). Uczestnicy podkreślają różnice między tymi podejściami, wskazując na zalety i wady każdego z nich. Programowanie "bare-metal" oznacza bezpośrednie działanie na sprzęcie bez interwencji OS, co daje pełną kontrolę nad czasem i zasobami, ale wymaga większej wiedzy i umiejętności. Z kolei systemy operacyjne oferują wygodę, łatwiejsze debugowanie oraz dostęp do zasobów wirtualnych, co czyni je bardziej odpowiednimi dla złożonych aplikacji. Wspomniano również o przerwaniach, które są kluczowe w obu podejściach, oraz o możliwościach programowania na nowoczesnych procesorach, takich jak Intel i5. Wiele osób zauważa, że nie ma jednoznacznej odpowiedzi na pytanie, które podejście jest lepsze, ponieważ zależy to od specyfiki projektu.
Podsumowanie wygenerowane przez model językowy.
REKLAMA