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

STM32 - Dyskusja akademicka - Pisanie własnego RTOS

EBC41 11 Wrz 2015 08:22 1344 3
REKLAMA
  • #1 14987198
    EBC41
    Poziom 28  
    Posty: 1573
    Pomógł: 98
    Ocena: 124
    Cze,
    Od jakiegoś czasu rozwijam swoją konstrukcję sterownika do stacji pogodowej. Projekt robi się coraz większy i większy i w końcu dotarłem do etapu, w ktorym rozważam użycie jakiegoś RTOSa. Mam dużą bibliotekę własnego kodu obejmującą takie rzeczy jak kompleksowa obsługa komunikacji po USART czy I2C, mam pełną obsługę konsoli tekstowej. Do tego używam LwIP do zapewnienia komunikacji przez TCP/IP, oraz FatFS. Na koniec jest tam programowy radiomodem AFSK.. W chwili obecnej program jest realizowany w przerwaniach i w pętli for(;;), tak naprawdę można by go podzielić na kilka zasadniczych wątków

    1. 9600x na sekundę ma się uruchamiać algorytm DSP obsługujący radiomodem. Musi to nastąpić bez względu na to co aktualnie robi procesor, ponieważ zabużenia tego tempa będą uniemożliwiały poprawne dekodowanie danych. Z tąd teraz jest to wyzwalane w przerwaniu o najwyższym priorytecie

    2. Podczas nadawania do sieci radiowej, 1200x na sekundę ma się uruchamiać algorytm DSP wyliczający i aktualizujący wartość DAC. Zaburzenie wykonywania tej procedury kończy się błędami w transmisji, co czyni całe nadawanie jedynie marnowaniem cennych zasobów radiowych.

    Pozostałe wątki nie wymagają już tak ścisłego czasu rzeczywistego i są wywoływane z pętli for
    3. Wywoływanie LwIP_Packet_Handle(), który sprawdza czy z PHY od Ethnernetu nie napłynęły jakieś nowe dane do przetworzenia. Z racji szybkości transmisji to powinno wywoływać się bardzo często

    4. Sprawdzanie czy nie zakończyła się transmisja po I2C czy USART, oraz czy w z wiązku z tym nie trzeba wywołać obsługi np. konsoli tekstowej (bo użyszkodnik wcisnał ENTER)

    5. Sprawdzanie czy nie trzeba załadować do gadaczki pogodowej następnego pliku dźwiękowego z karty SD. To ma najniższy priorytet

    A teraz przechodząc do meritum. Zakładam, że na chwikę obecną nie potrzebuje obsługi wyjątków, ani dynamicznej alokacji pamięci. Chodzi mi o napisanie własnego shedulera, który będzie obsługiwał te 5 w/w zadań i przy okazji zabezpieczał całe urządzenie przed przywieszaniem się w jednym z nich (np timeouty na magistrali I2C). Oczywiście mógłbym użyć gotowca typu FreeRTOS, czy nasz lokalny DistortOS ale chciałbym się przy okazji czego nauczyć, ot trochę sztuka dla sztuki.

    Pytanie, jak ma w tej sytuacji wyglądać najproszy możliwy kernel? Jak rozumiem muszę głównie zadbać o przerzucanie zawartością PC i rejestrów pomiędzy procesami, bo sama organizacja pamięci jest już ustalana na etapie kompilacji (bo nie mam dynamicznej alokacji).. O czym jeszcze muszę wiedzieć?
  • REKLAMA
  • #2 14987416
    BlueDraco
    Specjalista - Mikrokontrolery
    Posty: 6479
    Pomógł: 939
    Ocena: 421
    Myślę, że najlepszym źródłem wiedzy na ten temat jest kod źródłowy FreeRTOS.
  • REKLAMA
  • #3 14991419
    Freddie Chopin
    Specjalista - Mikrokontrolery
    Posty: 13336
    Pomógł: 1712
    Ocena: 870
    BlueDraco napisał:
    Myślę, że najlepszym źródłem wiedzy na ten temat jest kod źródłowy FreeRTOS.

    Zależy co kto lubi - czytanie kodu tego projektu jest dosyć ciężkie...

    EBC41 napisał:
    Pytanie, jak ma w tej sytuacji wyglądać najproszy możliwy kernel?

    Szerokie pytanie, więc nie da się udzielić krótkiej odpowiedzi. Generalnie pomysł na przeglądanie innych projektów nie jest taki zły, byle nie skupiać się na jednym (np. tylko na FreeRTOSie), a raczej na kilku które są zbliżone do tego co chciałbyś osiągnąć.

    EBC41 napisał:
    O czym jeszcze muszę wiedzieć?

    Jeśli nigdy nie używałeś żadnego RTOSa, to osobiście raczej odradzałbym Ci próbę napisania swojego własnego (; W samej wielowątkowości czai się wiele "pułapek" na osobę przywykłą do nieskończonych pętli for i przerwań, a co dopiero w kodzie takiego schedulera...

    EBC41 napisał:
    chciałbym się przy okazji czego nauczyć, ot trochę sztuka dla sztuki

    Zdefiniowałbym czego chcesz się konkretnie nauczyć - wbrew pozorom przy takim projekcie (zakładając, że ma on być użyteczny dla kogoś jeszcze poza autorem i to użyteczny w sensie praktycznym, a nie jako eksperyment myślowy) więcej czasu schodzi na podejmowaniu decyzji (wymyślanie API, wymyślanie najbardziej błędo-odpornych rozwiązań "systemowych" [nie chodzi o system jako RTOS], punkt równowagi między szybkością, rozmiarem, czytelnością i funkcjonalnością, ...) czy tworzeniu dokumentacji i testów niż na samym tworzeniu systemu...

    Tak czy siak - najpierw powiedz jak wygląda Twoje doświadczenie z innymi RTOSami, bo jeśli nigdy żadnego nie użyłeś, to próba napisania własnego może być naprawdę ciekawym eksperymentem (;
  • #4 14991482
    piotrva
    VIP Zasłużony dla elektroda
    Posty: 6409
    Pomógł: 625
    Ocena: 735
    Tak, pisanie własnego systemu jest bardzo czasochłonne, o czym przekonałem się na własnej skórze - co prawda rodzina inna bo AVR, ale myślę, że też można conieco zobaczyć.
    https://github.com/eitos/RTOS
    Tu zaimplementowane są na prawdę jedynie najbardziej podstawowe funkcje.

    Owszem, zawsze coś takiego jest pouczające i spowoduje nabycie pewnego doświadczenia, jednak zaręczam - bez jakiej-takiej znajomości ASM dla danej rodziny i dużego samozaparcia będzie ciężko - czasem trzeba przeskakiwać instrukcje krok po kroku, żeby wszystko ogarnąć i wyłapać błędy...
REKLAMA