Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Kategoria: Kamery IP / Alarmy / Automatyka Bram
Montersi
Kategoria: Akumulatorki / Baterie / Ładowarki

[C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++

Freddie Chopin 13 Lis 2016 12:56
  • #121 13 Lis 2016 12:56
    Piotrus_999
    Poziom 39  

    michalko12 napisał:
    Nie może być też tak, że jeśli jeden wątek ma 90% a drugi 9% to ten z tym 9% zostanie obsłużony dopiero wtedy kiedy wyczerpie się czas wątku 90%.

    W systemach RT tym się musi zająć projektant aplikacji.

  • #122 13 Lis 2016 12:56
    Freddie Chopin
    Specjalista - Mikrokontrolery

    michalko12 napisał:
    Na jedno wychodzi, zamiast 90ms, podpriorytet 90/100, tym bardziej, że nie ma możliwości zagwarantowania tych 90ms. Można zagwarantować, że ten wątek otrzyma 90% kwantów czasu procesora w stosunku do innych wątków o tym samym priorytecie. Nie może być też tak, że jeśli jeden wątek ma 90% a drugi 9% to ten z tym 9% zostanie obsłużony dopiero wtedy kiedy wyczerpie się czasz wątku 90%.

    Nie wychodzi na jedno. Algorytmy szeregowania wątków w systemach operacyjnych czasu rzeczywistego są takie a nie inne, gdyż chodzi o to, aby poddawały się jakiejś analizie, np. https://en.wikipedia.org/wiki/Rate-monotonic_scheduling , dzięki czemu można faktycznie powiedzieć, że coś jest real-time, a nie "cos podobnego, ale działa dobrze". Wynajdywanie jakiegoś algorytmu od nowa, tylko do specyficznej i dosyć hipotetycznej na razie sytuacji, nie brzmi zbyt kusząco (; Jeśli kwanty 90ms, 9ms i 1ms nie spełniają Twoich założeń przez zbyt długie oczekiwanie na obsługę w tych dwóch "krótszych", to znaczy że po prostu system jest nie do końca przemyślany i te dwa krótsze powinny być jednak wątkami o wyższym priorytecie. Albo po prostu 90/9/1 można zmienić na 9/1/1 - zawsze 10x krótsze czekanie <;

    michalko12 napisał:
    Jeśli wątek przechodzi w stan blokowania to automatycznie wypada z kolejki tasków w stanie wykonywania, a tym samym algorytm r-r nie bierze go pod uwagę i jego kwant czasu w ogóle nie ma znaczenia dla r-r. Co innego jeśli wątek sam się wywłaszcza na rzecz innych, wtedy raczej jego kwant czasowy nie powinien być resetowany.

    To nie chodzi o to czy scheduler bierze pod uwagę zablokowany wątek czy nie - to jest oczywiste. Chodzi o to, co powinno się stać z kwantem czasowym wątku po jego zablokowaniu. We FreeRTOSie nie trzeba się nad tym zastanawiać, ponieważ kwant czasowy round-robin wynosi tam zawsze "1", więc zbytnio nie ma pola manewru. Jednak w innych systemach (np. w distortos) kwant ten może być większy i wynosić np. 10 albo 100. Dla uproszczenia załóżmy, że chodzi o milisekundy. Moje rozumienie jest takie, że jeśli wątek ma np. 100ms kwant czasowy, wykonuje się przez 90ms (zostało więc 10ms) i w tym momencie zostanie zablokowany (bo czeka na semafor, kolejkę, mutexa, cokolwiek), to gdy zostanie odblokowany (bo się doczekał na ten semafor, mutexa czy kolejkę), to jego kwant czasowy zostaje zresetowany do 100ms. W distortos kwant czasowy jest resetowany tylko w 3 przypadkach:
    - przy zmianie algorytmu szeregowania dla danego wątku (round-robin <-> fifo),
    - jeśli się faktycznie wyczerpał i wątek został przełączony,
    - jeśli wątek zostaje zablokowany na jakimś obiekcie synchronizacyjnym.

    Z tego więc wynika, że kwant nie jest resetowany gdy wątek zostanie wywłaszczony - czy to przez wątek o wyższym priorytecie, czy to z własnej woli poprzez wywołanie funkcji yield(). W takim wypadku, gdy zostanie on ponownie uruchomiony, będzie po prostu kontynuował z takim kwantem czasowym jaki mu został.

  • #123 25 Lis 2016 09:56
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Wczoraj sfinalizowałem w końcu kolejną wersję o numerku 0.3.0. Zajęło to 3x dłużej niż planowałem, ale w trakcie takiego spiętrzenia spraw zawodowych, osobistych i remontowych niczego innego nie można było oczekiwać (; Najważniejsze zmiany w kolejności chronologicznej to:
    - wsparcie dla okresowych timerów programowych ,
    - miły w użyciu driver do portu szeregowego , operujący na abstrakcyjnej klasie interfejsowej dla sprzętowej części + implementacja tejże klasy interfejsowej dla wszystkich obsługiwanych układów (STM32F0, STM32F1 i STM32F4), na razie jedynie w wersji z przerwaniami,
    - równie prosty w użyciu (bo korzystający z tego wspomnianego powyżej) driver dla RS-485 ,
    - driver obsługujący magistralę SPI w trybie "master" , operujący na abstrakcyjnej klasie interfejsowej dla sprzętowej części - jak wyżej, dostępna jest implementacja dla 3 typów STM32 oparta na przerwaniach,
    - abstrakcyjna klasa bazowa "urządzenie SPI" , oraz pierwsza przydatna implementacja tej klasy w postaci drivera dla popularnych układów EEPROMów podłączanych przez SPI ,
    - poprawki wymagane przez GCC 6,
    - zmiana generatora pliku distortosConfiguration.h z takiego który używał AWK na taki bazujący tylko na shellu i coreutils (np. sed), dzięki czemu AWK nie jest już potrzebny w ogóle.

    Bardziej "rozwlekła" lista wprowadzonych zmian - http://distortos.org/distortos-change-log/#0.3.0

    http://distortos.org/news/distortos-0-3-0-released/

  • #124 03 Gru 2016 20:49
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Długo oczywiście zeszło, ale wyczarowałem drugi artykuł o stanach w jakich może się znaleźć wątek i przejściach między tymi stanami.

    http://distortos.org/documentation/task-states/

    Tym razem już nieco "wyższy" poziom (a przynajmniej tak mi się wydaje), choć starałem się ograniczyć w przykładach czy opisach do minimalnego zestawu "ficzerów", aby tekst był zrozumiały nawet dla kogoś kto pierwszy raz czyta coś o RTOSach. Może się udało, może nie (; We'll see... Teraz prace nad kolejnymi artykułami powinny nieco przyspieszyć.

  • #125 11 Sty 2017 19:14
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Wrzuciłem dwa kolejne ciekawe artykuły:
    1. ARM toolchain for Windows - zawiera kompletny i szczegółowy opis instalacji pod Windows wszelkich narzędzi wymaganych przez distortos (MSYS2, make, gcc [bleeding-edge-toolchain], OpenOCD, kconfig-frontends, Eclipse),
    2. Creating and configuring a project in Eclipse - opis tworzenia i konfiguracji nowego projektu z distortos w Eclipse, włącznie z najważniejszą chyba rzeczą, czyli konfiguracja indeksera.

    Artykuły te nie są oczywiście przeznaczone tylko dla distortos - zarówno jeden i drugi można potraktować jako opis konfiguracji toolchaina dla "zwykłych" projektów dla ARM. W pierwszym artykule pomijamy wtedy akapity o kconfig-frontends, a w drugim rzeczy typu konfiguracja samego RTOSa (czyli tworzenie/modyfikacja pliku distortosConfiguration.mk) czy włączanie pełnych komend kompilacji w konsoli (choć to również może się przydać w niektórych projektach).

    Jak zwykle wszelkie uwagi i opinie mile widziane (;

  • #126 11 Sty 2017 19:29
    tadzik85
    Poziom 38  

    ad.1 ścieżkę systemową można ustawić w Eclipse. Uważam, że tak jest lepiej jak ktoś używa wielu środowisk itp itd, wtedy kompilatory i make nie będą się gryzły. I Nadal aktualne przecież jest doinstalowanie pluginu Hardware debuging.

    I może polecenia których należy użyć rzeczy które należy skopiować daj w nowych liniach dla ułatwienia.

  • #127 11 Sty 2017 19:32
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Można ustawić w Eclipse, ale dla celów tego projektu i tak musi być ustawiona ścieżka systemowa, bo inaczej nie będzie działać konfiguracja projektu z konsoli systemowej (tam potrzebne jest MSYS2 i kconfig-frontends).

    Wtyczka do debuggowania, jak i samo debuggowanie, planowane jest jako osobna część trzecia.

  • #128 11 Sty 2017 19:34
    tadzik85
    Poziom 38  

    Freddie Chopin napisał:
    Można ustawić w Eclipse, ale dla celów tego projektu i tak musi być ustawiona ścieżka systemowa, bo inaczej nie będzie działać konfiguracja projektu z konsoli systemowej (tam potrzebne jest MSYS2 i kconfig-frontends).
    Dodać można wszystko co chcesz ;),

    Zaznacz choć, że jest taka możliwość....

  • #129 11 Sty 2017 19:45
    Freddie Chopin
    Specjalista - Mikrokontrolery

    tadzik85 napisał:
    Dodać można wszystko co chcesz ,

    Opiszę może dokładniej o co mi chodziło, gdyż poprzedni post może nie być wystarczająco jednoznaczny. Niektóre narzędzia muszą być w ścieżce systemowej widocznej na poziomie systemu operacyjnego, ponieważ polecenie "make menuconfig" (które jest bardzo ważną częścią projektu distortos) _NIE_ zadziała nigdy z poziomu Eclipse'a. Dla narzędzia uruchamianego z "cmd.exe" czy z terminala w Linuxie (bo uruchomienie go w Eclipse jest fizycznie niemożliwe) nie ma znaczenia co sobie ustawisz w opcjach projektu w Eclipse.

    tadzik85 napisał:
    Zaznacz choć, że jest taka możliwość....

    Idea jest taka że artykuły są też dla ludzi którzy nie mają z tym obycia. Dla takich osób dawanie miliona opcji jest tylko zaciemnianiem obrazu, a sam opis (bez obrazków i np. osobnego akapitu) będzie zbyt skromny aby ktoś sobie z tego skorzystał. Zakładam, że osoby zaawansowane nie muszą takiego opisu wykonywać krok po kroku z dokładnością co do kropki, bo wiedzą co chcą osiągnąć i w jaki sposób. Mogę więc dodać na górze jednego i drugiego artykułu informację, że opisany sposób nie jest jedynym ani "jedynym właściwym" i są możliwe inne rozwiązania, które również będą działać.

    Swoją drogą - sam używam wielu toolchainów i nigdy nie używam konfiguracji PATH z poziomu projektu Eclipse'a - jeśli jest problem, to uruchamiam Eclipse z linii komend z dodatkowymi folderami na początku PATH, wtedy mają one priorytet nad tym co jest już w systemowym PATH. W linuxie z konsoli "PATH=~/what/ever/bin:$PATH eclipse &", w Windows zapewne podobnie (nie wiem, nie używam obecnie).

  • #130 11 Sty 2017 19:50
    tadzik85
    Poziom 38  

    Freddie Chopin napisał:
    Spróbuj przeczytać dokładnie to co napisałem. Niektóre narzędzia muszą być w ścieżce systemowej widocznej na poziomie systemu operacyjnego, ponieważ polecenie "make menuconfig" _NIE_ zadziała nigdy z poziomu Eclipse'a. Dla narzędzia uruchamianego z "cmd.exe" czy z terminala w Linuxie (bo uruchomienie go w Eclipse jest fizycznie niemożliwe) nie ma znaczenia co sobie ustawisz w opcjach projektu w Eclipse.
    Podobno to temat o konfiguracji eclipse nie tylko pod Distortos. A to są sugestie jedynie......

    Jak nie chcesz zaciemniać artykułu. To może tricks & tips na końcu? Właśnie, może drobna wzmianka bo autosave? gdzie znaleźć?

  • #131 11 Sty 2017 19:57
    Freddie Chopin
    Specjalista - Mikrokontrolery

    tadzik85 napisał:
    Podobno to temat o konfiguracji eclipse nie tylko pod Distortos. A to są sugestie jedynie......

    Temat jest o distortos. Artykuł jest na stronie distortos i jest przeznaczony głównie dla distortos. Po prostu distortos nie jest tak specjalnie różny od dowolnego innego projektu dla ARM, żeby opis konfiguracji toolchaina czy projektu w Eclipse nie pokrywał się w jakichś 95% z opisami dla "zwykłych" projektów. Sugestię odnotowałem i oczywiście za nią dziękuję, tylko że we wszystkim musi być umiar - jak w artykule w każdym akapicie będzie coś na styl "zrób daną rzecz tak albo siak. jeśli wybrałeś pierwszą opcję to pomiń następne 3 akapity. jesli wybrałeś drugą opcje, skocz 2 akapity w tył" to po prostu nikt się w tym nie połapie i nikt nie będzie w stanie na jego podstawie zrobić czegoś co jest dla niego/niej absolutną nowością.

    tadzik85 napisał:
    Jak nie chcesz zaciemniać artykułu. To może tricks & tips na końcu? Właśnie, może drobna wzmianka bo autosave? gdzie znaleźć?

    To jest planowane jako jeszcze jedna - czwarta - część, która byłaby poświęcona przydatnym opcjom "kosmetycznym". Tutaj sprawa jest mocno niejasna, bo większość takich opcji jest całkowicie subiektywna - ja np. nie włączam autosave, bo nie chce mi się szukać (; A jak nie wiem gdzie jest jakaś opcja, to warto odnotować, że wyszukiwarka w "preferences" działa bardzo dobrze i przy jej pomocy można znaleźć każdą opcje w 5 sekund (jeśli wiemy czego szukamy <: ). Artykuł podstawowy chciałem zredukować do minimum wymaganych kroków, aby nie przedłużać.

  • #132 11 Sty 2017 20:01
    tadzik85
    Poziom 38  

    No to sporo mi wyjaśniłeś.... A, że taka wyszukiwarka jest też trzeba zauważyć, co dla kogoś kto eclipse widzi 1 raz może nie być oczywiste.

    PS. indexer, często warto odznaczyć indexowanie plików nie używanych w kompilacji a będących w projekcie.


    Poza tym informacja nie jest przykazem do stosowania. Ale lepiej znać możliwości, niż szukać godzinami czy zadawać pytania na forum.

  • #133 22 Sty 2017 01:35
    kriss68
    Poziom 20  

    Planujesz podpiąć tego RTOSa pod std::thread?

  • #134 22 Sty 2017 10:42
    Freddie Chopin
    Specjalista - Mikrokontrolery

    kriss68 napisał:
    Planujesz podpiąć tego RTOSa pod std::thread?

    Nie mam na ten temat sprecyzowanego zdania... Związane jest to z nieoptymalną (moim zdaniem) proporcją zalet do wad. Zaleta zasadniczo jest tylko jedna, choć oczywiście bardzo istotna - standardowy interfejs. Za to bez specjalnego zastanawiania się rozwiązanie to ma dwie bardzo poważne wady.

    1. Wymagałoby to utrzymywania forka GCC i newlib, aby produkować toolchain "arm-distortos-eabi-" zamiast "arm-none-eabi-", taka integracja oczywiście działałaby tylko na tym pierwszym, więc aby dało się używać systemu z tym drugim, konieczne byłyby pewnie jakieś kompilacje warunkowe w samym projekcie.

    2. Sam interfejs std::thread jest niezbyt dopasowany do wymagań mikrokontrolerów czy w ogóle embedded, a jego "standardowość" jest mocno ograniczona - warto zauważyć, że w kwestii wątków interfejs std::thread w ogóle nie zakłada istnienia czegoś takiego jak priorytet, algorytm szeregowania czy rozmiar stosu. O ile te dwie pierwsze rzeczy można po stworzeniu wątku zmienić (korzystając z _NIE_standardowych rozwiązań dostępnych poprzez obiekt zwracany przez funkcję native_handle()), o tyle tej ostatniej rzeczy się niestety nie da zmodyfikować po starcie wątku na mikrokontrolerze bez MMU. Oczywiście też nie da się zrobić tak, żeby po wywołaniu konstruktora std::thread wątek nie był od razu uruchamiany, bo tego ten interfejs też nie przewiduje...

    Szczególnie istotny jest ten drugi punkt, bo on mocno ogranicza zasadniczą zaletę tego rozwiązania. No bo w takim przypadku albo wszystkie wątki stworzone tym interfejsem muszą mieć dokładnie ten sam rozmiar stosu, albo konieczne jest dokładanie niestandardowych rozwiązań, np. funkcji modyfikującej domyślny rozmiar stosu dla std:thread (która do poprawnego działania musiałaby być używana w sekcji krytycznej wraz z konstruktorem wątku...).

    Z drugiej strony interfejs udostępniany w distortos jest bardzo zbliżony do std::thread, tyle że z drobnymi modyfikacjami tak aby bardziej pasował do mikrokontrolerów. Nie wiem więc, czy w ogóle warto coś takiego robić, ponieważ dla mikrokontrolerów byłaby to raczej "ciekawostka" niż coś używalnego do poważnych zastosowań. Interfejs pthread jest dużo bardziej dopasowany do naszych wymagań - jeśli więc ktoś lubi rozwiązania standardowe, to właśnie w tym kierunku warto się odwrócić. Ten interfejs oczywiście nie jest w C++, więc też nie załatwia wszystkich problemów...

  • #135 11 Mar 2017 17:25
    Freddie Chopin
    Specjalista - Mikrokontrolery

    No i mamy kolejną wersję, oznaczoną numerkiem 0.4.0!

    Najważniejsze - moim skromnym zdaniem - zmiany, to:
    - wsparcie dla całej rodziny STM32F7, dzięki czemu ilość obsługiwanych układów wynosi obecnie 395 sztuk,
    - dwie opcje (każda w dwóch wariantach) umożliwiające wykrywanie przepełnienia stosu wątku,
    - opcja sprawdzania kontekstu funkcji które nie mogą być używane w przerwaniach (blokujące, mutexy i cały namespace ThisThread), co załatwia chyba najpopularniejszy typ błędu w aplikacjach.

    Krótki artykuł o najnowszej wersji (wraz ze wszystkimi ciekawymi linkami) można znaleźć na stronce projektu - http://distortos.org/news/distortos-0-4-0-released/

    [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++ [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++ [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++ [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++