@macgajster

Ucz się freeRTOS.

Zdecydowanie rządzi w świecie mikrokontrolerów i zwykle producenci uczestniczą w rozwoju sterowników więc baza urządzeń i konfiguracji sprzętowych możliwych do zaspokojenia FreeRTOSem jest ogromna.

Rozmaite RTOSy z reguły mają dość ograniczony żywot - niegdyś popularny ecos zdechł jeszcze około 2013 r. Na projekty z VxWorksem ciężko już trafić, w automotive trzyma się jeszcze QNX.

Zresztą najważniejsze jest zrozumienie ogólnej problematyki RTOSów i czym się to zwykle różni od systemu ogólnego przeznaczenia jakim jest Linux.

@pierdonauta_kosmolony największym moim problemem jest znalezienie czasu Mam płytkę nucleo z F411RE, ale na razie nie bardzo mam pomysł co bym mógł na tym sklecić.

Teoretycznie na czymś słabszym puściłem tempomat, ale nie wiem czy tam freeRTOS podejdzie. Na pewno byłoby fajnie i przyjemne z pożytecznym - zarządzanie dość krytycznym w tej aplikacji czasem i do tego nauka.

Może znasz jakiś dobry kurs, który by ładnie opisywał wszystko? Ten z youtube już znam, ale nie podszedł mi zbyt dobrze. Może obejrzę go drugi raz i teraz będzie lepiej.

@octavian zupełnie nie można ufać tym driverom, są pobugowane i nie wiesz czy to zadziała, czy nie i zbyt często trzeba pisać patche. Trzeba je pisać również dlatego, że driver nie spełnia akurat twoich potrzeb, więc trzeba dopisać. Jeśli zajdzie potrzeba robienia upgrade'u to jest to ekstremalnie trudne, bo ekipa stwierdziła że zmieni nazwy komponentów np przez zamianę członów miejscami (z FOO_BAR na BAR_FOO).

Trafiłem do projektu który był na ukończeniu, poprawić kilka problemów i fajrant. Jednym z problemów było że modem GSM losowo gubił połączenie z internetem i po tym nie potrafił się podnieść. Po wykluczeniu problemu ze sprzętem, z budynkiem, BTSem i wszystkim wokół zacząłem sprawdzać kod. Wszystko wyglądało dobrze, kod wykorzystywał zephyrowy driver PPP do gadania z modemem ale postawiłem że jednak błąd musi być w wykorzystaniu tego drivera. No nie, nic nie poprawiało stanu rzeczy. Debug trwał 3 miesiące, trzeba było dodawać dupa printy, ustawić 6 urządzeń żeby robiły to samo i zbierać logi z każdego z nich czekając aż się w końcu coś wywali. 3 miesiące. Udało się dojść po nitce do kłębka, co wskazywało na jakiś dziwny błąd w driverze. Google skierowało na githuba lub jakieś zephyrowe forum (nie pamiętam teraz), gdzie ktoś zgłosił ten błąd 3 lata wcześniej i sobie to czekało na fixa. To był jakiś błąd w stosie sieciowym. Wystarczyłoby ten stos zresetować w przypadku problemu i w tym wypadku to by wystarczyło.

Ale Zephyr nie zezwalał na wyzerowanie tego stosu. Chyba że przez reboot, a to nie wchodziło w grę.

Skończyło się wypruciem zephyrowych driverów, przejście na protokół AT i pisanie w zasadzie wszystkiego od zera.

I teraz rzecz, której nie jestem pewien - czy Zephyr ma taki duży footprint, czy to po prostu beztalencie ludzi, którzy to pisali wcześniej: udało się uzyskać tę samą funkcjonalność co wcześniej i jednocześnie ważyło to mniej niż połowę flasha i zużywało połowę ramu. Tylko z zephyra został sam scheduler i reszta to ręcznej pisane drivery.

To był absolutny koszmar i najgorszy etap mojej kariery.

@ZohanTSW dzięki za wyjaśnienie. Miałem tyle szczęścia, że projekt nad którym pracowałem robiłem od zera więc nie miałem takich problemów. Oczywiście kilka napotkałem po drodze, ale udało się to rozwiązać pisząc własne poprawki.

Z tego co piszesz to raczej mieliście pecha do drivera, a nie całego systemu.

Podoba mi się w zephyrze że bardzo łatwo jest portować kod na inne procki przez zmiane device tree w zależności od rewizji urządzenia.

Mimo problemów jakie napotkałes to w mojej opinii jest to przyszłość embedded. Rok temu byłem na rozmowie o pytano mnie o podstawy działania

@octavian zgodzę się, że idea jest znakomita i w ten sposób powinno się robić embedded w przyszłości, jednak przed zephyrem jeszcze długa droga. Wysoki poziom wejścia też tego nie ułatwia. Samo to device tree... No niby spoko pomysł zrobić to jak w linuksie, a raczej fajnie że jest próba odwołania się do czegoś co powinno być szerzej znane, ale to według mnie wymaga uproszczenia. Może zrobić coś jak Cube MX w STM32, które będzie generować odpowiedni device tree? Może niech menuconfig to generuje? A może AI bo jest modne teraz? Bo jak na ten moment to zephyr pomaga omijać jedne kłody, rzucając ci inną kłodę prosto na twarz. Jeśli chodzi o samą przenoszalność kodu na inne procki to aktualnie piszę coś w tym rodzaju co moim zdaniem będzie łatwiejsze od zephyra bo w założeniu ma ograniczyć się do poprawnego wskazania źródeł w cmake jakiegoś domyślnego projektu (oraz ewentualne nastawy kompilatora), a tymi źródłami może być jakiś prosty hello world - byle ten hello world zawołał odpowiednią funkcję (będącą punktem wejściowym do aplikacji "biznesowej"). A ten Cmake można napisać w oparciu o exampla. Tylko to wyjdzie za X czasu bo nie mam kiedy do tego siąść, chyba musiałbym wziąć urlop na to xD a wydaje mi się możliwe, bo robiłem już coś takiego kilka razy, tylko kwestia to rozszerzyć i poznać szerszą pulę mikrokontrolerów.

Jeszcze co do tych poprawek - no na moje oko projekty oparte o zephyra mają średnio 20 patchy xD i mam mieszane uczucia co do tego. Słyszałem też że kontrybicja do repozytorium zephyra to rak, bo np robisz pull requesta z brakującą funkcjonalnością drivera, a oni ją odrzucają, bo uznają że to jest zbędne xD