#afera Kontrowersyjne

@HolQ masz jakieś 125% racji

@Banan11 nie no aż tak to nie

@FriendGatherArena nie fikaj bo będziesz następny xd

@pingWIN gejuru cię nie ominie tak czy tak :grinning:

@NiebieskiSzpadelNihilizmu nie ważne, tu chodzi o zasady xD

@pingWIN jakimi skryptami znowu, co ty masz za skrypty do czarnolistowanis

@Gustawff nawet nie segreguja co do pieca, tylko wszystko siup do lasu

@WysokiTrzmiel Głupia pisanina? Przecież są dwa artykuły der Spiegla i Deutsche Welle, gdzie sami wspominają, że ichniejsza policja nawet nie chce odnosić się do tej sprawy.
Ty najlepiej poczekaj na Tuska aż zdemontuje

@groman43 długo nie siedzę już w branży, jaki RTOS się teraz używa w embedded?

@lurker_z_internetu Nie mam zielonego pojęcia. Szczerze - nigdy nie używałem żadnego open source RTOSa. Tylko proprietary.

@groman43 @lurker_z_internetu freeRTOS jest zintegrowany ze środowiskiem STM. Dlatego jest popularny na tę platformę.
Jest często wymagany w ogłoszeniach embedded, a ponieważ w hw jest bardzo mało pracy, to chcę pójść w fw. Tym bardziej, że liznąłem fw i to od podstaw-podstaw: pisanie plików linkera, pisanie makefile od zera, grzebanie w elfach. Później zacząłem robić w STM32CubeIDE i w sumie jest to spoko środowisko.

Inne znane mi z ofert pracy RTOS to zephyr.

@macgajster imo zephyr to przyszłość i warto się go uczyć. Swoją drogą to Nordic na swojej stronie ma 2 darmowe i bardzo dobre kursy zephyra. Kupujesz płytkę za kilkadziesiąt złotych i masz wszystko co potrzebne do kursu.
Warto też dodać że Nordic zrobił wtyczki do VSC więc integracja jest bezproblemowa i wg mnie dużo lepsza niż ociężały kombajn Stm32CubeIDE, ale to już moja subiektywna opinia 😉

@groman43 "The two operating systems that were most popularly used in 2024 for embedded systems were Embedded Linux and FreeRTOS. At this time, an equal percentage of developers (44% each) had utilized both options"

@lurker_z_internetu FreeRTOS jest bardzo popularnym RTOSem i przystępnym według mnie. Do tego gotowy projekt można szybko przeportować na Safe RTOS i uzyskać tym certyfikaty bezpieczeństwa.
Poza tym że jest świetnie zintegrowany z STM32 to jeszcze ESP32 go używa.

A Zephyra to jebać maczetami, znakomita idea, a wykonanie takie, że można się popłakać. Może za 10 lat coś z niego będzie xd

@octavian jestem w tak ciasnej dupce, że muszę uczyć się tego co najczęściej pada w ogłoszeniach. A pada FreeRTOS.
Do tego dołożę C++ po przejściu z samounauczonego C, ale bez znajomości jakichś większych pojęć i mam nadzieję, że wystarczy. Wachlarz wymaganych umiejętności jest bardzo szeroki, a pracuję obecnie poza programowaniem z powodu siły wyższej. Po pracy mam mało czasu, więc nauka dwóch RTOS, jakkolwiek brzmi jak taran w drzwiach, jest zbyt zasobożerna :confused:

@macgajster w przypadku C++ i z tego co obserwuję wśród ludzi, którzy znając C uczyli się C++ mogę doradzić: nie traktuj tego języka jak C z klasami. To, że można stosować podejście jak w C nie oznacza, że się powinno. Tak naprawdę to jest inny język niż C

@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.

@macgajster
Gdybyś miał jakieś pytania to chętnie spróbowałbym pomóc.

@pierdonauta_kosmolony największym moim problemem jest znalezienie czasu :confused: 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.

@macgajster
https://wokwi.com/projects/322609470223942226

ESP-IDF FreeRTOS tasks - Wokwi ESP32, STM32, Arduino SimulatorRun IoT and embedded projects in your browser: ESP32, STM32, Arduino, Pi Pico, and more. No installation required!Wokwi

@macgajster
Chryste, próbowałem cokolwiek napisać i wyszły bzdury i tylko udało mi się wkleić link.
Być może warto zacząć od jakichś symulatorów lub emulatorów?

@macgajster a spróbuj zapytać chata gpt. Napisz mu co masz (jaki uC, jakie komponenty do niego etc) i poproś o projekt.

@ZohanTSW btw co jest nie tak z zephyrem? Pytam bo jestem ciekawy. Używałem go ok 6 msc i byłem zachwycony jak to działa. Próg wejścia wyższy niż freertos, ale jak zrozumie się device tree i konfigurację to idzie z górki.

@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