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

RTOS - wszystko, co chciałbyś wiedzieć i nie boisz się zapytać

Freddie Chopin 05 Cze 2019 15:44 5418 171
  • #151
    Użytkownik usunął konto
    Poziom 1  
  • PCBway
  • #152
    khoam
    Poziom 32  
    Marek_Skalski napisał:
    Dla mnie RTOS jest super do czasu, gdy trzeba zacząć kontaktować się z układami peryferyjnymi. Nie ma tutaj chyba żadnych reguł pozwalających opracować kod, który można łatwo przygotować, utrzymać i przenieść. Po części jest to wina peryferiów, po części liczby możliwych wariantów implementacji driverów.

    Problem "przenoszalności" kodu pomiędzy różnymi rodzinami procesorów na poziomie C/C++ w embedded jest generalnie słabo wykonalny i nie dotyczy tylko RTOS. Pewnie z tego powodu powstały takie wynalazki, jak Java, MicroPython etc.
  • #153
    Freddie Chopin
    Specjalista - Mikrokontrolery
    Odnosząc się do powyższego - taki właśnie problem występuje w tym uwielbianym przez wszystkich FreeRTOSie (ja naprawdę wciąż nie kumam co jest tak dobrego w tym projekcie, że jest on tak popularny, no ale może to ja jestem dziwny), ponieważ tam nie ma żadnych driverów. Niemniej jednak przecież w innych RTOSach (zaryzykuję teorię, że w większości, choć nie zamierzam tego uzasadniać <: ) są takie w pełni abstrakcyjne drivery, których w kodzie aplikacji można używać dokładnie tak samo, niezależnie od tego na czym ta aplikacja zostanie uruchomiona. Wynika z tego, że jedną i tą samą aplikację (jeśli jest odpowiednio napisana) można skompilować na kilka różnych platform i będzie ona działała tak samo, bez żadnych zmian w kodzie. Poprzednio już wymieniłem, ale przykładami są: mbed, ChibiOS/RT, NuttX oraz mój własny projekt distortos (aspirujący do roli frameworka, podobnie zresztą jak i pozostałe z tej listy). Zwykle nie jest też tak, że te abstrakcyjne drivery to taki sam badziew jak HAL/SPL od ST - jest z tym różnie, ale ogólnie ktoś to testuje. W mbed oczywiście "pod spodem" są drivery producentów (a więc dla STM32 będzie to HAL), ale abstrakcja nie powinna być z tego względu naruszona.

    Pewna część nieporozumień z tego wątku wynika z tego, że jak ktoś zna FreeRTOSa to już zakłada, że zna wszystkie RTOSy ("A są w ogóle jakieś inne?") no i każde durne ograniczenie tego dziwnego projektu ekstrapoluje na każdy inny projekt...
  • PCBway
  • #154
    khoam
    Poziom 32  
    Freddie Chopin napisał:
    jest tak dobrego w tym projekcie, że jest on tak popularny,

    Może dlatego, że jest bardzo łatwo "przenoszalny", właśnie ze względu na brak tego abstrakcyjnego HAL.

    Freddie Chopin napisał:
    Pewna część nieporozumień z tego wątku wynika z tego, że jak ktoś zna FreeRTOSa to już zakłada, że zna wszystkie RTOSy

    Może inaczej: nie każdy programuje na ARM i nie jest to wstyd ;)
  • #155
    Freddie Chopin
    Specjalista - Mikrokontrolery
    khoam napisał:
    Może inaczej: nie każdy programuje na ARM i nie jest to wstyd

    Przecież na dowolną inną platformę jest RTOSów na przysłowiowe "pęczki". mbed jest tylko na ARMy (wiadomo), ale ChibiOS czy NuttX już definitywnie nie. Tutaj taka lista dająca pewien pogląd na sprawę ilości takich projektów:

    https://en.wikipedia.org/wiki/Comparison_of_real-time_operating_systems

    A tutaj druga:

    https://www.osrtos.com/

    Na tej drugiej stronce np. "AVR" występuje 25x, PIC - 5x, MSP430 - 15x itd. Ale w kółko tylko FreeRTOS, FreeRTOS i FreeRTOS... (;

    Dodano po 1 [godziny] 11 [minuty]:

    khoam napisał:
    Może dlatego, że jest bardzo łatwo "przenoszalny", właśnie ze względu na brak tego abstrakcyjnego HAL.

    Czyli w przypadku FreeRTOSa to zaleta, ale w przypadku innych RTOSów brak driverów to wada (;

    Zresztą - portowanie samego schedulera nie wymaga od razu portowania wszystkich driverów. Nie trzeba ich portować wcale - ot po prostu będą niedostępne dla danej platformy i już.
  • #156
    khoam
    Poziom 32  
    Freddie Chopin napisał:
    Czyli w przypadku FreeRTOSa to zaleta, ale w przypadku innych RTOSów brak driverów to wada (;

    khoam napisał:
    Może dlatego, że jest bardzo łatwo "przenoszalny", właśnie ze względu na brak tego abstrakcyjnego HAL.

    Nie pisałem nic o innych RTOS.

    Dodano po 47 [minuty]:

    Freddie Chopin napisał:
    Zresztą - portowanie samego schedulera nie wymaga od razu portowania wszystkich driverów.

    Tak jest np. w przypadku NuttX dla ESP32 - brak wsparcia dla obsługi sieci WiFi.
  • #157
    Marico
    Poziom 20  
    Marek_Skalski napisał:

    Podtrzymuję moje stanowisko, że to sztuka dla sztuki, aby wziąć MCU i używać tylko jego CPU+RAM, pomijając układy peryferyjne, a to wszystko tylko dla wykazania, że można. Tylko gdzie tu jest obsługa peryferiów przez OS wspomniana w pierwszym cytacie? Zabrakło.


    Proszę nie wyciągać pochopnych wniosków.To oczywiście nie ma być tylko CPU+RAM ale normalny OS z obsługą sprzętu a nie paradygmat FreeRTOS "masz pan tu scheduler a drivery napisz sobie sam".
    To, że nie wykorzystuję (części) sprzętu z erraty nie oznacza, że nie wykorzystuję go w ogóle. Nie pisałem o szczegółach, których zabrakło bo to nie temat wątku, to nie ma być RTOS więc mało kogo to interesuje. I nie demonizujmy tak tej erratty, sugerując, że ów mcu do niczego się nie nadaje.
    OS wg złożeń ma mieć drivery do sprzętu, za ich pomocą userland (aplikacja funkcjonalna) ma mieć dostęp poprzez prostą warstwę abstrakcji (open/read/write /dev/uart, /dev/spi, /dev/i2c). Nic prostszego pod słońcem.
    Przykład (banalny ale oddaje clue); potrzebny jest logger temperatury zapisujący na trwałym nośniku z dostępem przez sieć. "Normalnie" by to zrobić to trzeba wziąć driver do nośnika, driver do FSa, stos tcp, skonsolidować to razem. Po czym okazuje się, ze sam kod aplikacji funkcjonalnej to kilka linijek (odczyt -> zapis -> czekaj i od nowa) a rozmiarowo 99% projektu zajmuje kod "systemowy" doklejony do projektu, konieczny ale zajął kupę czasu by to razem połączyć i skonfigurować - więc po co nim sobie głowę zawracać? OS rozwiązuje ten problem. Mając działający OS piszę tylko prosty kod czytający /dev/temp i piszący do wybranego pliku. Kilka linijek. Skompilowaną binarkę uruchamiam na gotowym (działającym) OSie.
    Oprócz banalnego uruchamiania jest ochrona zasobów, jeden proces zawierający błędy nie popsuje całości, jedynie sam sobie swój sandbox. Który z gotowych RTOSów wspiera separację tasków we własnej (nie musi być wirtualnej) przestrzeni adresowej?
  • #158
    Freddie Chopin
    Specjalista - Mikrokontrolery
    Marico napisał:
    Który z gotowych RTOSów wspiera separację tasków we własnej (nie musi być wirtualnej) przestrzeni adresowej?

    Choćby FreeRTOS po włączeniu MPU.
  • #159
    _lazor_
    Moderator Projektowanie
    W sumie czytam tak i się zastanawiam w czym ludzie mają problem jeśli chodzi o drivery? Przecież nikt nie ukrywa dokumentacji do peryferiów SoC (wyłączając takie przypadki jak raspberry pi), więc jaki problem sobie zrealizować libkę z obsługą tych peryferiów?
    Czy ludzie chcą programować mikrokontrolery tak jak jakiegoś pythona? import uart; send_uart()? I powiedzieć że są programistami?
  • #160
    alagner
    Poziom 26  
    _lazor_, czemu nie? Równie dobrze możesz napisać, że co to za programiści co piszą w C, skoro mają ASMa. Kwestia świadomości co siedzi pod spodem, ale unikanie "not invented here" nie jest imho niczym złym. Pytanie czy to jest "invented anywhere" ;) Póki co z dostępnością jest raczej problem.
  • #161
    _lazor_
    Moderator Projektowanie
    Może problem jest nie z tym że używa się gotowych rozwiązań (sterowników), ale gdzie się oczekuje by one były. Jak biorę dla przykładu jakieś nucleo to nie oczekuje by mi ktoś dostarczył sterowników (chociaż example to w sumie już dużo), ale zasiadam do czegoś co jest platformą (beaglebone, arduino, raspberry pi itp) to w sumie w drugą stronę - dziwiłbym się że nie ma tam sterowników.

    A jeszcze gorzej by RTOS dostarczał takie rzeczy, gdy na rynku tysiące układów...
  • #162
    Marico
    Poziom 20  
    _lazor_ napisał:
    W sumie czytam tak i się zastanawiam w czym ludzie mają problem jeśli chodzi o drivery?


    Odpowiem cytatem z Theodore'a Levitta: "Ludzie nie potrzebują ćwierć calowego wiertła, ludzie potrzebują ćwierć calowej dziury".
  • #163
    trol.six
    Poziom 31  
    Freddie Chopin napisał:
    trol.six napisał:
    Jak wygląda obsługa sprzętu w RTOS?

    Pytanie nieprecyzyjne (;

    W takim razie z cyklu nie zadane pytania, prosze o przykład jakiegoś bardziej precyzyjnego pytania wraz z odpowiedzią w tym zakresie. Chętnie się dowiem czegoś.
    .
  • #164
    Freddie Chopin
    Specjalista - Mikrokontrolery
    trol.six napisał:
    W takim razie z cyklu nie zadane pytania, prosze o przykład jakiegoś bardziej precyzyjnego pytania wraz z odpowiedzią w tym zakresie. Chętnie się dowiem czegoś.

    Wiem że Twój nick zobowiązuje i trolowanie to Twoja domena, ale wystarczyło przeczytać trochę więcej niż to co zacytowałeś. Pomogę:

    Freddie Chopin napisał:
    Można na nie patrzeć jak na "jak wygląda dostępność driverów do obsługi sprzętu w istniejących RTOSach". W takim wypadku odpowiedzią jest, że "wygląda różnie" - w niektórych projektach jest tylko sam scheduler i nic więcej (wiadomo że główny przykład to FreeRTOS, w którym nie ma nawet pół drivera do czegokolwiek i wszystko musisz "rzeźbić" sam). W innych (np. mbed, ChibiOS/RT, NuttX, również mój projekt distortos, ...) są drivery które maja różne poziomy abstrakcji, nawet takie jak masz w linuxie, że port szeregowy obsługujesz jako pliki i musisz się bawić z takimi durnościami jak termios.h żeby cokolwiek przestawić.

    Można również na pytanie patrzeć jak na "w jaki sposób robi się obsługę sprzętu w RTOSie". Tutaj chyba już coś o tym wspominałem - generalnie nie ma jakiejś uniwersalnej zasady którą można zastosować w każdym możliwym przypadku, bo przecież każdy driver jest trochę inny. Zasadniczo dobry driver dla RTOSa nie różni się specjalnie od dobrego drivera dla nie-RTOSa - zwykle ma w sobie jakąś kolejkę lub bufor. Zasadnicza różnica jest taka, że w RTOSie powinieneś skorzystać z jakiejś formy synchronizacji (np. semafor lub kolejka), natomiast bez RTOSa polegasz zwykle na pollingu jakiejś flagi lub też driver musi być zdarzeniowy. Dodatkowo jeśli drivery w RTOSie mają mieć jakąś abstrakcję, to zwykle podzielone są na tzw. górną i dolną połowę. Górna połowa jest wtedy uniwersalna i zapewnia rzeczy które są niezależne od sprzętu (np. w driverze portu szeregowego zajmuje się ona buforowaniem i synchronizacją z wątkiem), natomiast dolna połówka to część która jest zależna od konkretnego sprzętu, np. będzie zupełnie inna dla UARTa w STM32F1 a inna dla UARTa w LPC17xx. Dolna połówka zwykle jest ograniczona do absolutnego minimum, więc często jest robiona "zdarzeniowo", tak aby jak najwięcje kodu było w górnej (wspólnej) połówce. Temat jest bardzo szeroki i raczej ciężko na niego odpowiedzieć "w ogólności", najlepiej byłoby debatować na jakimś konkretnym przykładzie, np. UARTa.
  • #165
    trol.six
    Poziom 31  
    Ależ ja to przeczytałem :) O co ty mnie posądzasz? Jest OK. Jednak sam na koniec piszesz:
    Freddie Chopin napisał:
    Temat jest bardzo szeroki i raczej ciężko na niego odpowiedzieć "w ogólności"


    A ponieważ temat RTOS'a znam raczej orientacyjnie, więc myślałem że może jakieś szczególne ale nie ogólne kwestie dotyczące obsługi sprzętu możesz tutaj przytoczyć.
    :)
  • #166
    Freddie Chopin
    Specjalista - Mikrokontrolery
    trol.six napisał:
    A ponieważ temat RTOS'a znam raczej orientacyjnie, więc myślałem że może jakieś szczególne ale nie ogólne kwestie dotyczące obsługi sprzętu możesz tutaj przytoczyć.

    Mogę przytoczyć i szczególne i ogólne, ale musiałbym właśnie wiedzieć "w którym kierunku" mniej-więcej pytasz, bo też nie chodzi o to, żebym wyprodukował tekstu na 7 ekranów, gdyż może się okazać że opisany tam aspekt akurat nie jest tym który Cię interesuje.
  • #167
    Typek2
    Poziom 12  
    Cieszy mnie że jest taki temat na forum ponieważ mam kolejne pytanie.

    1. Wiemy że podczas pisania programów na architekturę ARM programista decycyduje za pomocą skryptu linkera gdzie w pamięci leżą sekcje programu generowane przez kompilator.
    Najczęściej wygląda to w ten sposób:
    RTOS - wszystko, co chciałbyś wiedzieć i nie boisz się zapytać
    Źródło: Link

    2. Jeśli w programie użyjemy dynamicznej alokacji pamięci za pomocą malloc() to w obszarze wolnej pamięci 'free RAM' powstanie
    sterta która rośnie w górę przeciwnie do stosu. Czy to prawda?

    3. Wiemy również jak wygląda obszar pamięci używany przez system FreeRTOS:
    RTOS - wszystko, co chciałbyś wiedzieć i nie boisz się zapytać
    Źródło: Link

    4. Z powyższego wynika że wszystkie tak zwane stosy poszczególnych tasków, bloki TCB, oraz listy, kolejki itd są umieszczone na stercie systemu FreeRTOS. Wiemy że ten obszar jest zarządzany przez system i ma określony maksymalny rozmiar.

    5. Gdzie ten obszar jest umieszczony względem mapy pamięci bez uzycia systemu?

    6. Czy zmienne zdefiniowane wewnątrz tasków trafiają na stosy tasków a zmienne zdefiniowane poza taskami trafiają do sekcji .data i .bss?

    7. Ponieważ klasyczne przerwania są niezależne od systemu to rozumiem że adresy powrotu z funkcji obsługującej przerwania są przechowywane na oryginalym stosie poza stertą systemu. Czy tak?
  • #168
    Freddie Chopin
    Specjalista - Mikrokontrolery
    Typek2 napisał:
    1. Wiemy podczas pisania programów na architekturę ARM programista decycyduje za pomocą skryptu linkera gdzie w pamięci leżą sekcje programu generowane przez kompilator.
    Najczęściej wygląda to w ten sposób:

    Nie do końca tak to wygląda dla ARM, choćby dlatego, że zwykle między flash a RAM jest spora "dziura", a więc między .rodata a .data na obrazku powinna być spora dziura "niczego". Dodatkowo na obrazku pominięta została sterta.

    Typek2 napisał:
    2. Jeśli w programie użyjemy dynamicznej alokacji pamięci za pomocą malloc() to w obszarze wolnej pamięci 'free RAM' powstanie
    sterta która rośnie w górę przeciwnie do stosu. Czy to prawda?

    Prawdą jest to, że sterta rośnie zwykle "do góry", ale czy akurat powstanie ona w obszarze oznaczonym jako "free RAM" i to czy akurat wyżej jest stos to już kwestia tego, jak to zostanie zorganizowane w skrypcie linkera. Równie dobrze może być to zrobione inaczej i np. w swoim RTOSie starałem się to zrobić bardziej odpornie - stos przerwań jest na samym początku RAM (przepełnienie wychodzi więc "poza RAM"), potem są sekcje stałe .data i .bss, potem sterta, a dopiero potem jest stos dla wątku głównego o ustalonym rozmiarze (RTOSa ma kontrole przepełnienia - oczywiście nie jest ona idealna, ale większość przepełnień wykryje). Z tego względu przy takim ułożeniu nie ma możliwości kolizji stosu przerwań ze stertą. Ale nic nie stoi na przeszkodzie, żeby sobie to ułożyć inaczej - np. tak jak to opisałeś. Różne sposoby zorganizowania tego mają różne cechy - zależnie od potrzeb mogą być one wadami lub zaletami.

    Typek2 napisał:
    4. Z powyższego wynika że wszystkie tak zwane stosy poszczególnych tasków, bloki TCB, oraz listy, kolejki itd są umieszczone na stercie systemu FreeRTOS. Wiemy że ten obszar jest zarządzany przez system i ma określony maksymalny rozmiar.

    W starym FreeRTOSie może i tak czasem było. W nowym FreeRTOSie i w RTOSach umożliwiających alokację "statyczną" (czyli praktycznie każdy, poza tym "najlepszym"...) równie dobrze mogą one być w .data lub .bss. Dodatkowo sterta jest zarządzana przez system i ma maksymalny rozmiar tylko przy niektórych implementacjach alokatora dynamicznego z FreeRTOSa - ta która używa malloc() z pewnością nie jest zarządzana przez RTOSa a to czy ma maksymalny rozmiar zalezy od biblioteki standardowej (np. od newliba i Twojej własnej implementacji funkcji sbrk()).

    Typek2 napisał:
    5. Gdzie ten obszar jest umieszczony względem mapy pamięci bez uzycia systemu?

    W tym samym miejscu, bo sterta - taka "normalna", czyli używana przez malloc() - będzie w dokładnie tym samym miejscu (względem innych sekcji, a nie pod tym samym adresem). To zależy od skryptu linkera i budowy aplikacji, a nie RTOSa. FreeRTOS jest tak prosty, że on praktycznie niczego nie robi sam, wszystko trzeba sobie zorganizować samemu - włącznie z takimi podstawami jak skrypt linkera, wektory czy startup. Gdyby nie robili tego producenci układów, to obstawiam, że większość osób nie byłaby sobie w stanie z tym poradzić, a już na pewno nie za pierwszym podejściem do RTOSa.

    Typek2 napisał:
    6. Czy zmienne zdefiniowane wewnątrz tasków trafiają na stosy tasków a zmienne zdefiniowane poza taskami trafiają do sekcji .data i .bss?

    Nie ma czegoś takiego jak "zmienne zdefiniowane wewnatrz tasków lub poza nimi". Zmienna może być albo "automatyczna" - wtedy trafia na stos, albo "statyczna" - wtedy trafia do .data/.bss. Jeśli mówimy o zmiennej automatycznej, czyli takiej na stosie, to trafi ona na taki stos jaki aktualnie będzie aktywny przy wykonaniu danej funkcji. Może będzie to stos danego wątku, ale może będzie to stos przerwań, może jedno i drugie, jeśli dana funkcja jest wywoływana zarówno przez wątki jak i przerwania.

    Jeśli pytasz o to, gdzie trafią zmienne lokalne (automatyczne) zadeklarowane w głównej funkcji danego wątku, to trafią one oczywiście na stos danego wątku (lub wątków). Jeśli jednak zmienne te będą ze słówkiem "static", to wtedy jest tylko jedna, wspólna instancja tej zmiennej, umieszczona w .bss/.data.

    Typek2 napisał:
    7. Ponieważ klasyczne przerwania są niezależne od systemu to rozumiem że adresy powrotu z funkcji obsługującej przerwania są przechowywane na oryginalym stosie poza stertą systemu. Czy tak?

    Dla ARM - jeśli włączysz odpowiedni tryb (dwa osobne stosy) - tak będzie, adresy powrotu i kopia aktualnego stanu trafiają na stos zwany jako "main stack", wskazywany przez rejestr "MSP", czyli stos dedykowany tylko dla przerwań i nie używany przez wątki. Większość RTOSów z tego korzysta, gdyż głupotą (oraz startą RAMu) byłoby zrobić to inaczej. Są jednak wyjątki, np. nuttx (nie we wszystkich przypadkach konfiguracji), w którym logika musi ustąpić temu, że "Greg ma zawsze rację i jest najmądrzejszy".
  • #169
    Typek2
    Poziom 12  
    Freddie dziękuję za odpowiedź.
    Freddie Chopin napisał:
    W starym FreeRTOSie może i tak czasem było. W nowym FreeRTOSie i w RTOSach umożliwiających alokację "statyczną" (czyli praktycznie każdy, poza tym "najlepszym"...) równie dobrze mogą one być w .data lub .bss.

    Pamiętam że jakiś czas temu FreeRTOS nie obsługiwał statycznej alokacji i wtedy używałem alokacji dynamicznej nawet nie będąc tego do końca świadomym oraz nie rozumiejąc konsekwencji z tym związanych.
    Później kiedy autorzy systemu ogłosili od dziś nareszcie nastała światłość -alokacja statyczna, przyjrzałem się tym nowym funkcjom i do mnie dotarło, po pierwsze jak mało wiem a po drugie że stąpam po cienkiej linie.
    Wiem że na zdanie "Statyczna alokacja wymaga sporo zachodu" jest odpowiedź "To zależy jakie są założenia, pewne założenia wymagają zachodu". Pytanie - w jakich branżach/rozwiązaniach używa się alokacji statycznej a w jakich można sobie pozwolić na alokacje dynamiczną. Oczywiście tylko na przykładzie tak popularnego systemu jak FreeRTOS, pomijam wyszukane, autorskie systemy w śmigłowcach bojowych itd. Czy w sterowniku do pieca C.O. to nie ma większego znaczenia a w przemysłowym sterowniku sprężarki ciśnienia w zbiorniku metanu już należy zastosować alokacje statyczną?
  • #170
    Freddie Chopin
    Specjalista - Mikrokontrolery
    Typek2 napisał:
    Pytanie - w jakich branżach/rozwiązaniach używa się alokacji statycznej a w jakich można sobie pozwolić na alokacje dynamiczną.

    Myślę że to zależy od wielu czynników. Po pierwsze od tego czy taka alokacja dynamiczna ma w danym przypadku jakieś zalety. Jeśli projekt jest prosty, to np. bawienie się alokację dynamiczną nic nie da, za to przy bardziej zakręconych zadaniach może ona wiele uprościć. Drugi czynnik który przychodzi mi do głowy to ile jest dostępnego RAMu - na układzie który ma dosyć "ciasny" RAM (np. 10 kB) raczej nie ma co szaleć, ale na STM32F7, który ma 512 kB to czemu by nie? Trzecia kwestia - w pewnych zastosowaniach "safety critical" takie bajery jak dynamiczna alokacja są zabronione, lub mocno ograniczone.
  • #171
    _lazor_
    Moderator Projektowanie
    Ja mogę rzucić z doświadczenia, że nie za wiele jest miejsc gdzie używa się dynamicznej pamięci, zwłaszcza w produktach gdzie trzyma się standardu MISRA (nie istotne czy ktoś zgadza się z MISRA czy też nie). A w projektach gdzie MISRA nie była wymagana, to cóż też unikano. Zasada jest prosta, wszystko jest proste i "bezpieczne" dopóki nie ma się buga powodującego segmentation fault raz na 1-2 tygodnie.
  • #172
    en2
    Poziom 5  
    Alokacja "dynamiczna" z punktu widzenia użytkownika może zostać osiągnięta np. poprzez przeciążenie operatora new i wymuszenie zastosowania systemowego wywołania odpowiedzialnego za alokację. W moim systemie wykorzystuje algorytm TLSF, który jest deterministycznym algorytmem alokacji z puli i służy właśnie do tego typu zastosowań. W procesorach aplikacyjnych realizujących zazwyczaj bardzo złożone funkcjonalności posiadanie własnych alokatorów jest znacznym ułatwieniem dla użytkownika systemu.

    @up standardy bezpieczeństwa dopuszczają alokację z puli. AUTOSAR, który jest nowszym odpowiednikiem MISRA mówi odpowiednio:

    Memory management functions shall ensure the following: (a) deterministic behavior resulting with the existence of worst case execution time, (b) avoiding memory fragmentation, (c) avoid running out of memory, (d) avoiding mismatched allocations or deallocations, (e) no dependence on non-deterministic calls to kernel.

    Odpowiedź na pytanie czy można używać alokacji "dynamicznej" jest zatem złożona. Wszystko zależy :D

    BTW, ktoś poruszył bardzo ciekawe zagadnienie.