RTOS jako standard na KAŻDYM mikrokontrolerze - Dobra praktyka?

Witajcie.

Naukę programowania mikrokontrolerów rozpocząłem od założenia, że mając bibliotekę udostępnioną przez producenta do danego procesora jest to wszystko czego mi potrzeba, aby napisać czytelny i niezawodny program z pełną odpowiedzialną konfiguracją i dokumentacją, aby osoba czytająca mój kod mając jedynie bibliotekę oraz plik main.c mogła zrozumieć o co chodziło autorowi. Miało to służyć zarazem zrozumieniu samego działania mikrokontrolerów od podstaw jak i nauki estetycznego pisania samych programów.

Po czasie i kilku projektach zaczynam kombinować tworząc własne biblioteki używając różnych mikrokontrolerów i zaznajamiam się ze strukturą plików CMSIS gdyż subtelne różnice w nazewnictwie zaczynają być kłopotliwe i dostosowywanie wszystkich "uniwersalnych" bibliotek zaczyna być uciążliwe.

Słowami wstępu dochodzimy do tematu. Jak proponują Ci, którzy cenią sobie uniwersalność klarowność i estetykę. Pomijam tutaj fakt, że w większości przypadków używanie RTOS'a to przerost formy nad treścią ale używanie go w każdym przypadku poszerza wiedzę i doświadczenie. Nie chciałbym wchodzić w zagadnienia HAL, choć cały Internet jest wybrukowany tą praktyką co moje oczy boli gdyż z prostej obsługi kodów jedno-plikowych zaczyna tworzyć się wielokatalogową sieć powiązań.

Jaką praktykę proponujecie? Pozdrawiam forumowiczów!

Zaznajomić się z architektura oraz zapoznać się jak działa toolchain. Jak znasz podstawy na takim poziomie (podstawy, które są tak naprawdę o ironio rzeczą rzeczą zaawansowaną), to jestem samodzielnie stwierdzić czy użycie poszczególnych rzeczy (systemy, gotowe biblioteki, rozwiązania itp) są w danym projekcie akceptowalne i na miejscu.

Większość rzeczy to nakładki, które mają ułatwić programowanie, ale jeśli się nie zna podstaw i usilnie się ktoś stara przekonać kogoś do jakiegoś rozwiązania to już nie jest inżynierstwo tylko jakiś chory aksjomat, podchodzący pod wiarę.

Tak od razu do ludzi którzy powiedzą, że nie lubię arduino, cpp i OSów. Nie lubię to prawda, ale nie raczej z powodów bo tak, tylko z innych powodów: arduino nie lubię, bo nie widzę na rynku pracy w ogóle zapotrzebowania na to, cpp jest bardzo złożonym językiem i trzeba dużo więcej nakładów pracy aby się go nauczyć + bardzo szybko ewoluuje co powoduje jeszcze większego nakładu czasu, a mam kilka innych dziedzin do nauki, a OSy, nawet polecam, chociaż sam nie używam bo nie widzę potrzeby jeszcze.

Cytat:

FreeRTOS jako standard na KAŻDYM mikrokontrolerze - Dobra praktyka ?

Windows 10 jako standard na KAŻDYM komputerze - Dobra praktyka ?

odvbo napisał:

Pomijam tutaj fakt, że w większości przypadków używanie RTOS'a to przerost formy nad treścią ale używanie go w każdym przypadku poszerza wiedzę i doświadczenie.

To poszerzenie wiedzy i doświadczenia, wynika z rozwiązywania dodatkowych problemów i błędów które popełnisz, które "zawdzięczasz" użyciu niepotrzebnie złożonych rozwiązań. Maksymalizowanie ilości napotkanych problemów jest dobre kiedy chcesz się się uczyć, złe kiedy chcesz efektywnie zrealizować niezawodnie działające urządzenie - np. projekt komercyjny.

Kolega wrzucał FreeRTOSa do projektów w których nie był potrzebny, później narzekał na utrudnione debugowanie

_lazor_ napisał:

...arduino nie lubię, bo nie widzę na rynku pracy w ogóle zapotrzebowania na to..

Jak w TV pokazują rozbrajanie bomby, to zazwyczaj jest zrobiona na Arduino Obawiam się arduinowcy zaistnieją na rynku pracy, czy nam się to podoba czy nie, dzięki dużej podaży i niskiej cenie.

_lazor_ napisał:

Większość rzeczy to nakładki, które mają ułatwić programowanie

Pomoc jest zawsze mile widziana ^^ byle tylko jasno człowiek wiedział czy wszystko stroi.

Freddie Chopin napisał:

Windows 10 jako standard na KAŻDYM komputerze - Dobra praktyka ?

Hej, dzięki mój błąd już zmieniłem.

khoam napisał:

Zakładam, że jesteś biegły w pisaniu C lub C++ na poziomie średnim. Jeżeli nie, to jedną z gorszych praktyk jest uczenie się języka programowania na podstawie kodów bibliotek czy przykładów udostępnionych przez danego producenta.

Cześć ! z tą biegłością bym nie przesadzał, ale jestem w stanie wykorzystać już każdą z opcji dostępnych w dokumentacji samego STM więc sądzę, że trzeba pójść dalej

jarek_lnx napisał:

To poszerzenie wiedzy i doświadczenia, wynika z rozwiązywania dodatkowych problemów i błędów które popełnisz,

Witaj jarek. Właśnie stąd ten temat. Chcę zadecydować jaki obrać kierunek a zarazem o ile stopni obrócić swoje podejście.

atom1477 napisał:

Ale jedno trzeba mimo to powiedzieć: takim sposobem nie nauczysz się działania mikorokontrolerów, tylko systemu operacyjnego.
Szczególnie gdy masz takie założenie że kod ma być uniwersalny i działać na każdym mikrokontrolerze. To wymusza stosowanie wyłącznie wysokopoziomowych funkcji dostępu do peryferii.

Póki co mam tą swobodę, że sam ustalam z jakiego mikrokontrolera będę korzystał także nie martwię się natłokiem zmiennych.

khoam napisał:

Taki FreeRTOS w ogóle nie dostarcza HAL,

Witaj ponownie khoam, właśnie dlatego ten projekt czy też rozwiązanie zwróciło moją uwagę gdyż póki co omijam HAL'e szerokim łukiem.

Bardzo dziękuję za udział w dyskusji. Wiele z waszych wypowiedzi mi pomogło. Oczywiście jestem świadomy, że najlepsza nauka w tej jak i w wielu innych dziedzinach to poprzez tak zwaną metodę "prób i błędów". Ważne jest, aby już na starcie wiedzieć jakich błędów nie popełnić w co się nie zagalopować niepotrzebnie a co jest ciekawe i warte uwagi z technicznego punktu widzenia. Właśnie temu miał posłużyć mi ten temat.

Robienie projektu od zera niestety wymaga dużej wiedzy na temat projektowania oprogramowania. Znajomość języka jest ważna, ale sam język nie uczy jak zachować dobre dependencje w źródłach projektu, jak napisać dobry build system (nie zależnie od użytego narzędzia) czy zaprojektować dobry interface...

Oprócz nauki hardware możesz przeczytać trochę książek na temat projektowania oprogramowania (niestety większość nijak ma się do świata embedded, tego bardzo niskopoziomowego) czy choćby oglądnąć serię z uncle bobem:
https://www.youtube.com/watch?v=7EmboKQH8lM

jarek_lnx napisał:

_lazor_ napisał:

...arduino nie lubię, bo nie widzę na rynku pracy w ogóle zapotrzebowania na to..

Jak w TV pokazują rozbrajanie bomby, to zazwyczaj jest zrobiona na Arduino Obawiam się arduinowcy zaistnieją na rynku pracy, czy nam się to podoba czy nie, dzięki dużej podaży i niskiej cenie.

Ważne też jest ile będą płacić takim programistom. Jeśli będą płacić tak jak elektronikom w tym kraju to szału nie będzie.

mam taki domysł, że wątek się źle zaczął i kontynuuje.
Stawiam tezę, że nie chodzi o "RTOS" na każdym kontrolerze, ale również o schedulery i inne bardziej niskopoziomowe realizacje, tylko tak obejmie się "wszystkie kontrolery"

Obiema ręcyma za tym głosuję. A umacniają mnie dobre wyniki.
Na Atmedze 8 posadziłem własny scheduler, obsługa portów typu przycisk, timerów, tam są przerwania itd... a nad nim 100% czysta od AVR apliakcja. Dostaje z kernela nieblokujące zdarzenia (kilka rodzajów, mniej niż 10, nie potrzebowałem więcej) jak KeyPress, LongKeyPress, KeyUp i kilka innych o których opowieść byłaby dłuższa.

Żeby być bardziej wq..cym, to w tym przebrzydłym C++, w którym podobno nie da się programowac uK. Pola prywatne, genialne, konstrktory, choćby dla statycznych obiektów. Już w pierwszej chwili po zmianie formalnej w projekcie ten przebrzydły C++ wyeliminował 3 bajty danych, jak rozumiem analiza prywatności pozwoliła mu ustalić, ze nie używane. Kompilator C taką wiedzą nie dysponował.

Więc jakieś formy podziału "system" - "aplikacja" polecam z całego serca.

Użycie RTOS jest jednym z kilku możliwych sposobów na zorganizowanie oprogramowania mikrokontrolera. Jak każdy sposób, ma on zalety i wady. Zalety - to np. to, że kiedy człowiek nauczy się myśleć w metodologii RTOS, to może łatwo konstruować spore projekty we w miarę jednolity sposób. Wada tego podejścia - potrzeba składowania stanu wątków (często zbędnego) i narzut czasu przez mechanizmy OS, niekiedy zabijający wydajność.
Ja np. preferuję model zdarzeniowy, w którym całe oprogramowanie składa się z funkcji inicjującej wykonywanej raz i procedur obsługi zdarzeń, które są wywoływane po wystąpieniu zdarzenia, wykonują się i kończą, nie pozostawiając niejawnego kontekstu. To dokładne odwrócenie koncepcje RTOS, w której wszystkie zadania kręcą się w pętlach, a tego, żeby nie kręciły się niepotrzebnie, pilnuje RTOS.

Też bardzo dużo pracuję z systemami zdarzeniowymi i jest to super rozwiązanie od małych mikrokontrolerków po nawet x86 (patrz DPDK)

BlueDraco napisał:

To dokładne odwrócenie koncepcje RTOS, w której wszystkie zadania kręcą się w pętlach, a tego, żeby nie kręciły się niepotrzebnie, pilnuje RTOS.

No nie wiem... Może i da się napisać program w RTOS w którym wszystko kręci się bez ładu i składu w pętlach, niemniej jednak taki program który ma szansę działać poprawnie jednak opiera się na zdarzeniach, na które reagują wątki.

Co mają Panowie na myśli pisząc "systemy zdarzeniowe"? Pierwszy raz spotykam się z taką nomenklaturą. Polecicie jakąś książkę w tym zakresie?

Pozdrawiam

@Edit

_lazor_ napisał:

Do poszczególnych rozwiązań, raczej osobnej książki nie znajdziesz, ale jak poszukasz poprzez hasła to pewnie w sieci znajdziesz dużo artykułów opisujących dane rozwiązania.

Oczywiście, lecz koledzy wspominający o tym na pewno sami znają miejsca, w które warto zajrzeć. Uznałem, że warto zapytać aby nie nabrać uprzedzeń źródłem ładnie zaprezentowanym, lecz felernie opisanym. Szukam punktu zaczepienia w temacie.

khoam napisał:

ESP-IDF zawiera bibliotekę Event Loop, która umożliwia komponentom programu deklarowanie zdarzeń, do których inne komponenty mogą rejestrować programy obsługi - kod, który zostanie wykonany, gdy te zdarzenia wystąpią. Standardowo korzysta z tego stos WiFi w ESP32. Co ciekawe, biblioteka Event Loop opiera się w całości na mechanizmach RTOS

Idea piękne, ale każdą ideę można sknocić głupią implementacją. A jak nie widzę implementacji to ciężko powiedzieć czy dobrze to napisali czy przez "legacy reason" nie jest to skasztanione na maksa.

Do poszczególnych rozwiązań, raczej osobnej książki nie znajdziesz, ale jak poszukasz poprzez hasła to pewnie w sieci znajdziesz dużo artykułów opisujących dane rozwiązania.

odvbo napisał:

Polecicie jakąś książkę w tym zakresie?

http://www.state-machine.com/psicc2/
To samo w duuużym skrócie: http://www.state-machine.com/doc/Modern_Programming_Slides.pdf
To samo, trochę obszerniej: https://www.youtube.com/watch?v=o3eyz1gEqGU&list=PLPW8O6W-1chytjkg63-tM7MI0BvGxxPIP

Freddie: w RTOS każde zadanie kręci się w pętli, tylko zadanie byle jak napisane zżera na to czas procesora, a dobrze napisane jest zatrzymywane przez system w oczekiwaniu na zdarzenie. Jednak ma ono zawsze strukturę pętli i nadmiarową informację o stanie w niepotrzebnych zmiennych lokalnych na stosie zadania.
Pomysł na realizację zdarzeniową różni się tym od RTOS, że nie ma pętli i nie ma ukrytego stanu (często zbędnego), a tylko jawny - w zmiennych statycznych, najlepiej zebranych w strukturę/instancję klasy. Mi się ten pomysł podoba bardziej niż stada pętli z przełączaniem zadań i trzymaniem ich zbędnych stosów, ale to oczywiście rzecz gustu. W dodatku na Cortexach możesz zrzucić zarządzanie zdarzeniami na sprzęt (NVIC) - i wszystko robi się samo, bez narzutu oprogramowania na wołanie obsługi zdarzeń - to lubię najbardziej.

BlueDraco napisał:

Freddie: w RTOS każde zadanie kręci się w pętli

Nic nie stoi na przeszkodzie, żeby pisać wątki jako "jednostrzałowe", które po skończeniu tego co mają zrobić wychodzą ze swojej głównej funkcji (lub same się kasują, co tam obsługuje dany RTOS). Można sobie takie wątki tworzyć w zależności od potrzeby. Coś na styl wzorca typu "thread pool" czy jakoś tak.

Generalnie napiszę tak. Fajne są te dywagacje o aplikacjach czysto eventowych, ale wciąż czekam aż ktoś pokaże w pełni eventowy stos TCP/IP, system plików i jeszcze najlepiej jakąś bibliotekę od GUI. Tak więc w rzeczywistości (przynajmniej tej mojej) dowolne eventowe cuda które się wyprodukuje i tak w końcu muszą się poddać przed zewnętrznymi bibliotekami, które jednak w każdym większym projekcie w końcu się pojawią i tam jednak zwykle idzie się po linii najmniejszej komplikacji, czyli wątki i zwykła synchronizacja.

@Freddie Chopin W maluchach to może być problem, duże firmy z tym problemów nie mają, ale to pomińmy. Może rozwiązania gdzie jest cortex-A + cortex-m + DPDK? cortex-a zapewnia linucha z gui, dpdk zapewnia optymalny stos tcp/ip a cortex-m do real time elementów. Aktualnie cenowo rozwiązanie jest spore, ale od kilku lat vendorzy idą w takim kierunku i nie wygląda to tak źle.

No ale po co, skoro te wszystkie rzeczy można zrobić na JEDNYM mikrokontrolerze, np. na Cortex-M.

Freddie Chopin napisał:

Można sobie takie wątki tworzyć w zależności od potrzeby. Coś na styl wzorca typu "thread pool" czy jakoś tak.

Thread pool to troszeczkę coś innego, choć to może być jedna z jego cech w celu oszczędzania zasobów. Swoją drogą też ciekawy pomysł, żeby stworzyć zadania służące jedynie do odpalania handlera delegata, pobieranego z np. kolejki.

Freddie Chopin napisał:

Generalnie napiszę tak. Fajne są te dywagacje o aplikacjach czysto eventowych, ale wciąż czekam aż ktoś pokaże w pełni eventowy stos TCP/IP, system plików (...)

Moim zdaniem wszystko ma swoje miejsce i nie można mówić, że system eventowy będzie lepszy czy gorszy niż synchroniczne x tasków przełączane przez system. Można jedynie powiedzieć, że do danego rozwiązania bardziej pasuje rozwiązanie eventowe lub taskowe. Z reguły silenie się na napisanie całego programu eventowo/pętlowo zwiększa tylko jego komplikacje dając zerowy zysk. Prosty przykład - asynchroniczna (eventowa) obsługa http request/response. W tasku w pętli mamy całą obsługę elegancko AZ. Z eventami - lockowanie, czekanie na aż przyjdzie event z odpowiedzią itd.

Freddie Chopin napisał:

jeszcze najlepiej jakąś bibliotekę od GUI.

Realizacje GUI z reguły są na eventach, a w zasadzie na czymś pomiędzy eventami a pętlami (chyba, że mówimy o wyświetlaczu graficznym). Z resztą sprowadza się to mniej więcej do tego, co napisałem na początku - task, który czeka na handlera z kolejki.

Znów odpowiem dość wymijająco - Jeśli wymagania projektu będą pasowały do takiego rozwiązania. To jest po prostu kolejna możliwość zrealizowania projektu. Widziałem projekty w AGD (inżynieryjna patologia) w wielkiej pętli while, bo nikt nie chciał bawić się w OS, widziałem projekty analizy pracy silników robionych na sztucznej inteligencji... czy smart termostat na właśnie takim rozwiązaniu jak opisałem wyżej. Łączy je jedno - koncepcyjnie spieprzone
Jeśli zadanie można wykonać na jednym mikrokontrolerze to taki SoC z cortex-A i cortex-m to przewymiarowanie, ale gdy wiele funkcjonalności posiada już taki linuks na na cortex-A to pytanie czy development podobnych driverów na cortex-m nie będą droższe niż zakup droższego SoC?

Tutaj też dodam dość istotną rzecz - projekt tworzy się na bazie umiejętności w zespole lub jakie dana osoba posiada. Można dywagować czy lepiej używać RTOSa, eventów czy całego ekosystemu arduino, ale jak ktoś nie zna danych rozwiązań to nie wiem jakby się silił to bez doświadczenia jest jak początkujący i tak popełni błędy początkującego...może trochę mniej, ale nadal jakieś popełni.
Taki truizm w sumie, ale to np powoduje że wielu ludzi nie przesiada się z avr na cortexy... czy z c na cpp itp.

_lazor_ napisał:

Widziałem projekty w AGD (inżynieryjna patologia) w wielkiej pętli while, bo nikt nie chciał bawić się w OS

Czy ja wiem? W wielu przypadkach tak się po prostu robi i to wcale nie jest coś złego, o ile wie się, co się robi. Polecam: https://stackoverflow.com/questions/47845361/...n-un-delayed-infinite-while-loop-bad-practice, https://en.wikibooks.org/wiki/Embedded_Systems/Super_Loop_Architecture, https://www.eevblog.com/forum/beginners/rtos-vs-superloop-when-to-use/

_lazor_ napisał:

Można dywagować czy lepiej używać RTOSa, eventów czy całego ekosystemu arduino

RTOS, LINUx, BSD, mikro i nano-jądra oraz OSy powinny być wybierane w zależności od zadania, jakie ma realizować dane urządzenie lub... coś. RTOS jest systemem czasu rzeczywistego i rządzą się w nim inne reguły niż w np. systemie uniksowymv - tutaj czas jest krytyczny i niezbyt sobie można pozwolić na jakiś przerwania czy czekanie na I/O nie wiadomo ile, trzeba rozumieć priorytety i zależności między taskami i wymianią danych. RTOS ma też swoje ułomności, dlatego nie jest systemem do wszystkiego i dla wszystkich. Zatem z truizmem zgodzić się trzeba, bo... tak po prostu jest.

spy napisał:

Czy ja wiem? W wielu przypadkach tak się po prostu robi i to wcale nie jest coś złego, o ile wie się, co się robi. Polecam: https://stackoverflow.com/ques...finite-while-loop-bad-practice, https://en.wikibooks.org/wiki/Embedded Systems/Super Loop Architecture, https://www.eevblog.com/forum/beginners/rtos-vs-superloop-when-to-use/

Tam było to już skasztanione i nikt nie chciał wyłożyć kasy na refaktor. Podobny projekt robiłem na początku mojej kariery dla ABB, tam był używany system operacyjny i działało to wyjątkowo dobrze.

Pamiętaj że jest kilka poziomów real time, ja np pracuje aktualnie jako hard real time, a dokładnie w implementacji LTE L1, tam się liczy wydajność, potem wydajność no i trochę wydajności, bo kto nie chce mieć jak największego transferu?
Prywatnie robię sterowniki do zasilaczy (czyli automatykę) tam za to szybkość wykonania się programu (od inputu z ADC do outputu na timerze) ma wpływ na fazę a więc i na stabilność, tak więc nadal zależy mi na najszybszym wykonywaniu się softu.
I to jest moje tło jeśli chodzi o moje podejście do projektowania. Co powoduje że moje opinie wydają się dla wielu dziwne i oderwane od rzeczywistości. I to jest prawda, bo każdy ma swoją rzeczywistość.
Każdy musi wypracować sobie swój styl, jakich narzędzi, paradygmatów, bibliotek czy sprzętu lubi korzystać i zostać specjalistą w tym wycinku.

_lazor_ napisał:

I to jest prawda, bo każdy ma swoją rzeczywistość.

Zgadzam się. Nie ma tutaj prawdy uniwersalnej, tak samo jak RTOS nie jest uniwersalnym, standardowym systemem. Ile zadań, tyle może być podejść.