Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

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

ghost666 04 Sie 2020 16:37 3387 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/

    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
    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.
    ghost666 napisał 9961 postów o ocenie 8219, pomógł 157 razy. Mieszka w mieście Warszawa. Jest z nami od 2003 roku.
  • MetalworkMetalwork
  • #2
    m7m
    Poziom 11  
    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
    bobycob
    Poziom 18  
    Dziś przez "bare-metal" rozumie się często uruchomienie oprogramowania na maszynie fizycznej, a nie na wirtualnej.
  • #4
    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
    bobycob
    Poziom 18  
    przykładem takiego programu może być:
    GRUB, memtest86+
    Bardziej bezpośrednio - piszesz bios ;)
    -------------- auto korekta ----------
  • MetalworkMetalwork
  • #6
    fifi_22
    Poziom 7  
    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
    khoam
    Poziom 39  
    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
    elektronik999
    Poziom 26  
    szymon122 napisał:
    procesorach typu Intel i5


    A mnie bardziej ciekawi ten firmware który w nich jest
  • #9
    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
    __Kai__
    Poziom 10  
    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
    elektryku5
    Poziom 38  
    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
    khoam
    Poziom 39  
    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
    OldSkull
    Poziom 27  
    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
    khoam
    Poziom 39  
    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
    atom1477
    Poziom 43  
    ghost666 napisał:
    Rozpocznijmy odpowiedź na to pytanie od spojrzenia wstecz na epokę programowania "bare-metal".

    Rozpocznijmy od obalenia tezy postawnej w pytaniu, jakoby programiści przechodzili na OSy. A tak nie jest. No jacyś przechodzą. Ale i są tacy co nie przechodzą.

    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.

    Wcale nie.
    W moich projektach 90% funkcjonalności jest poza mainem.
    Wszystkie automaty stanu chodzą na przerwaniach.
    I wiele innych kodów (nie moich) ma podobnie.
    Nie można więc tak uogólniać.

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

    Kolejna bzdura.
    Jest dokładnie odwrotnie.
    To na bare-metal można łatwo mieć pełną kontrolę nad czasem.
    Oczywiście można ją mieć i na OS, ale już nie łatwo.
    Standardowo na OS mamy wątki systemowe, uruchamiane np. co 1ms.
    Żeby coś tam pozmieniać trzeba już wchodzić we wnętrze OSa.
    Generalnie więcej z tym zabawy niż zrobienie tego bez OSa.
    OS ma zalety jak używa się Ethernetu, Wifi, HDMI, myszek komputerowych/klawiatur, zapisu do plików, itp. Czyli przy dzisiejszej elektronice w sumie w większości przypadków.
    Nie mniej jednak jak układ ma zapewniać jedynie realizację algorytmów Real-Time, ale bez żadnych interfejsów, to OS nie ma tam sensu.
    Dajmy na to właśnie wspomniany sterownik elementów robota. Taki sterownik silnika krokowego czy jakiegoś BLDC, ze sprzężeniem zwrotnym z enkodera.
  • #16
    alek25
    Poziom 24  
    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
    khoam
    Poziom 39  
    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 :)
  • #19
    atom1477
    Poziom 43  
    "Program OS" tak, ale program "na OS" to już nie jest bare-metal.

    Żeby program był efektywny nie wystarczy że zawiera w sobie bare-metal.
    Żeby był efektywny trzeba dobrze napisać każdy jego fragment (a przynajmniej fragmenty krytyczne czasowo). Czyli trzeba żeby mieć wpływ na tą część bare-metal.
    Jeżeli weźmiemy OSa ale nie będziemy w niego ingerować, to nie możemy poprawić tej części bare-metal.
    Tak samo przy czystym programie bare-metal, ale takim gdzie wzięliśmy ten program skądś (np. jako gotowiec z neta) i nie zmieniamy go lecz dopisujemy tylko własną część. Tu to samo. Brak zmian w pewnej części programu to brak możliwości poprawienia błędów i nieoptymalności w tej części. Cóż z tego że będzie to bare-metal, jak akurat będzie on źle napisany a nie będziemy w to ingerowali?

    Bare-metal z tego punktu widzenia nie różni się od OS.
    I w OSie można zmieniać wszystko.
    Problemem jest tylko to że OS jest duży.
    Do tego część OS-ów jest zamknięta (brak kodów i możliwości przekompilowania jądra).
    Jest też doktryna żeby nie przerabiać OS-a, a tylko pisać na niego aplikacje. Czyli mimo braku przeciwwskazań technicznych do przerabiania OS-a, jest przeciwwskazanie "polityczne".
    I stąd niemożliwość uzyskania takiej samej niezawodności i Real-Time-owości na OS-ie.
    Bo najpierw jest w ogóle sprzeciw wobec optymalizowania OS-a, a gdy już przezwyciężymy sprzeciw, to się pojawiają problemy techniczne (ogrom kodu do optymalizowania).
  • #20
    kaczodp
    Poziom 12  
    Jak nie potrafi się dobrze napisa programu bare-metal to i OS nie pomoże, może.
  • #21
    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
    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
    atom1477
    Poziom 43  
    JasiuQ napisał:
    Typowa akademicka dyskusja o wyższości świąt wielkanocy nad Bożego Narodzenia.

    Wcale nie, bo są to inne rodzaje programów. Niemożliwe do porównania wprost.

    JasiuQ napisał:
    Czym jest OS, jak nie wielką pętlą while z mnóstwem nieużywanych funkcji w przypadku implementacji prostego algorytmu do sterownika?

    Całe te wywody których już nie zacytowałem są bezużyteczne, bo nie o OSie jest dyskusja.
    Dyskusja jest o programach na OSa, a nie o programie OS.
    Zatem nie jest ważne czym OS jest. Ważne czym są programy na niego pisane.
    To jest różnica pomiędzy programistami na OSa a programistami bare-metal.
    I ta różnica polega na tym że pisząc bare-metal, mamy dostęp do wszystkiego, ale i wszystko musimy zrobić samemu (choć można korzystać z gotowych bibliotek).
    A piszcząc na OSa, mamy dostęp tylko do tego co nam udostępni ten OS. Przy czym on udostępnia też pewne wirtualne zasoby. Więc generalnie jest udostępnione sporo zasobów, ale w większości wirtualnych,za to brakuje pewnych niskopoziomowych zasobów.

    To o czym mówisz to co innego. OS sam w sobie oczywiście jest programem bare-metal. Ale on taki jest sam dla siebie. Czy tam dla programisty który napisał tego OSa (napisał tego OSa, a nie pisze na tego OSa).

    Natomiast różnica w szybkości wykonywana wynika z obu rzeczy.
    I z samego OSa (może wymagać sporo zasobów sam dla siebie).
    Oraz z faktu że kod się na OSa pisze inaczej (raczej się korzysta z udostępnianych przez OSa zasobów, niż wkłada swój kod w niskopoziomowy kod OSa).