Systemy wbudowane, RTOS, programowanie w Linuxie - jak się w to wgryźć + kilka pytań?

Szanowne Koleżanki i Koledzy,

Postanowiłem zagłębić się w programowanie w wyżej wymienionych obszarach.

Podczas studiów z racji kierunku bardziej byłem skupiony na przedmiotach związanych z automatyką, jednak postanowiłem wrócić do programowania, które raczej traktowałem raczej jako zbędny. Zdecydowałem się naprawić swój błąd i odświeżyć moją wiedzę - albo nabyć od nowa.

Postawiłem na C, C++, programowanie w Linuxie, embedded, RTOS, ze względu na potrzebę obcowania blisko sprzętu i sympatię do pingwinów. Pytanie "Od czego zacząć?" pewnie byłoby zbyt ogólne, albo by świadczyło o moim lenistwie, bo nic nie szukałem/czytałem, więc chciałbym zadać bardziej doświadczonym osobom - zwłaszcza pracującym zawodowo na co dzień z tymi technologiami - kilka konkretniejszych pytań:

1a) Czy w programowaniu systemów embedded i RTOS ciągle używa się języka C, czy raczej C++?

Zacząłem lekturę klasycznych książek Stevensa jak "Programowanie zastosowań sieciowych w systemie Unix", "Unix – programowanie usług sieciowych. API: gniazda i XTI" czy "UNIX. Programowanie usług sieciowych. Tom 2 – Komunikacja międzyprocesowa", i w nich mowa jest tylko o języku C. Z racji tego, że książki były napisane już ponad 15 lat temu, mam wątpliwości, czy to była kwestia tego, że języki obiektowe takie jak C++ nie były jeszcze na tyle popularne czy C ma w tym przypadku jakieś niezaprzeczalne zalety, że się go nadal stosuje?

Na studiach miałem zajęcia z programowania w Linuxie i RTOS właśnie w C. Wiem, że obydwaj moi wykładowcy (W. Paluszyński oraz J. Ułasiewicz) są wybitnymi specjalistami, mający doświadczenie także w projektach komercyjnych, więc trudno im zarzucić propagowanie technologii z czasów młodości.

1b) To samo, co powyżej, tylko jak to wygląda ze zwykłym Linuxem?

O ile w systemach wbudowanych mogę się domyślać ograniczeń np. sprzętowych czy braków kompilatorów języków wyższych poziomów, to w "normalnym" Linuxie takich ograniczeń przecież nie ma.

2. Na ile ważna jest dobra znajomość technik programowania mikrokontrolerów w RTOS?

Mikrokontrolery podczas studiów nie były moją szczególną miłością, opanowałem podstawy programowania, ale zdaję sobie sprawę, że to jest temat-rzeka. Docelowo chciałbym się jednak zająć RTOS, i nie wiem, na ile niezbędne będzie się dokształcenie z "czystych" mikrokontrolerów.

3. Jak zacząć zabawę z RTOS?

Na uczelni miałem zajęcia z RTOS na systemie QNX i komputerach PC104, które miały dodatkowy moduł z wejściami i wyjściami cyfrowymi i analogowymi. Docelowo chciałbym wykorzystywać RTOS w jakiś projektach związanych z robotyką, automatyką czy mechatroniką, jak quadrocopter, roboty mobilne czy inteligentne urządzenia domowe.

I tu pytanie: czy zacząć od czystych systemów RTOS, jak np. FreeRTOS czy RTLinux, czy też może zacząć od rozszerzeń typu RTAI czy Xenomai? I które konkretnie byście polecali, z którymi mieliście doświadczenie czy słyszeliście dobre opinie?

PS Jakby się znalazł ktoś dociekliwy, to założyłem identyczny temat na innym portalu, ale bez odzewu :P

Ad. 1a.: Zależy co i na co piszesz. Jeśli szukasz wiedzy w sieci to zdecydowanie popularniejsze jest C. Z drugiej strony - bywa, że w tych przykładach widać tony struktur ze wskaźnikami na funkcje i na samą siebie o znaczącej nazwie this, ew. object.

I zwróć uwagę jak często kompiluje się soft w cpp dla (relatywnie) małych mikrokontrolerów: z reguły bez rtti i bez wyjątków (w gcc to bodajże parametry: -fno-rtti oraz -fno-exceptions).

Ad. 1b.: Niech się spece od Linuxa wypowiedzą, nie wiem.

Ad. 2: Zależy. Jeżeli chcesz iść w małe mikrokontrolery, to raczej musisz poznać ich bebechy. Z drugiej strony - możesz wziąć RTka z gotową obsługą peryferiów i HALem, wtedy zadanie może Ci się uprościć (patrz np.: ChibiOS/RT). Ale w sumie co trudnego w zapisie "rejestr = wartość"?
Bardziej problematyczną kwestią może być poznanie działania tranzystora, diody itd. w zależności od realizowanego projektu. Nie wiem na ile te tematy kojarzysz jako automatyk. Chyba, że hardware zaprojektuje Ci ktoś, a Ty skupisz się na czystym kodzeniu, wtedy oczywiście sprawa jest inna.

Ad. 3: Zaczynałem na FreeRTOSie, przykladów bazylion, dokumentacja niezła, natomiast autorzy chyba z notacją węgierską przesadzili ;)
Znów pytanie - co chcesz robić dokładnie. Z mojego doświadczenia: do sterowania elementami mocy, czyli silnikami, przetwornicami itd. stosuje się raczej procesory DSP, ew. bare-metalowe mikrokontrolery, wtedy zostaje raczej FreeRTOS, wspomniany ChibiOS i inne tego typu rozwiązania. Ale już do przetwarzania obrazu z kamery w dronie nie ma problemu zastosować czegoś opartego na Linuxie.

Pozdrawiam

Dzięki wielkie za odpowiedź, już straciłem nadzieję, że ktoś mi odpowie ;)

Ad. Ad. 1a) Czyli jak rozumiem z reguły się programuje w C, ale na sposób obiektowy? Coś jak jest opisane np. tutaj http://www.cs.rit.edu/~ats/books/ooc.pdf ? Jeszcze muszę się w to zgłębić, bo takie podejście do programowania w C to dla mnie kompletna nowość ;)

Co do C++ - czyli można w nim pisać na systemy wbudowane, jak tylko kompilatory pozwalają? Czy są jakieś ograniczenia wynikające z samej konstrukcji języka (jak np. to, o czym wspomniałeś, czyli kompilacja bez RTTI czy wyjątków)?

Ad. Ad. 2,3) Z elektroniką nie będzie problemu - trochę tego na studiach miałem, i trochę się też bawiłem w domu.

Myślałem na zrobieniu sobie czegoś w rodzaju płytki ewaluacyjnej z AVR albo ARM na pokładzie, i żeby na niego właśnie załadować jakiegoś Linuxa czy RTOS, i na takim żywym organizmie się uczyć.

W mniej lub bardziej niedalekiej przyszłości bym chciał zbudować np. robota mobilnego reagującego na głos czy właśnie autonomiczny quadrocopter lokalizujący się za pomocą kamery. Robiąc to na gołych mikrokontrolerach mogłoby to być dość karkołomne :D

Polecasz tego ChibiOS/RT do takich zastosowań? Czy raczej sugerowałbyś zacząć od FreeRTOS?

To od końca: w Chibiego się wgryzam w wolnych chwilach (a niestety nie mam ich za wiele) także trudno mi go polecić czy odradzić. Za to na pewno mogę FreeRTOSa polecić, edukacyjnie jest jak najbardziej ok.

Co do quadrotora/robota/autonomicznego ekspresu do kawy itd. - nikt Ci nie broni przecież użyć jakiegoś mikrokontrolera do zarządzania np. pracą silników (bo jest to zwyczajnie wygodne) i spięcia tego z Linuxem przy pomocy np. CANa czy jakiegoś RSa. Ew. pomyśl o natonialowym LabView i ich modułach, aczkolwiek to pchanie się w koszta. Sam nie do końca wierzę, że to piszę, bo szczerze nie trawię tego obrazkowego makaronowego kodu, ale zwyczajnie w takich zastosowaniach to może się sprawdzić.

Jeśli chodzi o samo C++ - to nie jest tak, że nie możesz używać wyjątków czy RTTI, raczej chodzi o oszczędność zasobów, bo tych w małych mikrokontrolerach może zwyczajnie braknąć. Tak samo niezalecane jest (nadmierne) używanie dynamicznej alokacji pamięci, czyli z wektorem i listą trzeba ostrożnie. Z drugiej strony - są przecież implementacje alternatywne, np. uSTL.
Zresztą tu nie chodzi stricte o C++, ale o rozsądek w użytkowaniu zasobów, najlepiej zobacz sam, co na AVRze użycie floata potrafi zrobić z rozmiarem programu. ;)

No i pytanie czy kompilator w ogóle obsługuje C++ - przy MSP430 o ile pamiętam są (były?) z tym problemy.

Co do pktu nr 1 - będę się musiał w to zagłębić, bo lektura wydaje się ciekawa, ale na pierwszy rzut oka -tak, mniej więcej to ta idea.

@Endrju możesz rozwinąć wypowiedź?