Post autor: SP8EBC » 25 stycznia 2016, 21:14
Ja w zasadzie od razu zacząłem od STM32 także poza specyficznymi zastosowaniami, takimi jak DSP nie widziałem żadnej różnicy pomiędzy C a C++
Zacząłem jednak widzieć różnicę (od PC) jak w kodzie pojawiła mi się dynamiczna alokacja pamięci i operatory takie jak new i delete, czy bardziej klasycznie funkcję malloc, free i realloc. I tu ostrzeżenie, że niestety ale bez RTOS i dobrego zarządzania pamięcią nie ma co nawet myśleć o dynamicznych obiektach. Choćbyś rozciągnął stertę do granic absurdu, to bardzo szybko dostaniesz poważne wycieki pamięci a operator new będzie zwracał albo null albo jakieś losowe śmieciowe adresy nie mające odzwierciedlenia na fizycznych peryferiach. Oczywiście takie zabawy kończą się bardzo szybko wyrzuceniem niemaskowalnego przerwania HardFault i wtedy uratować może albo watchdog albo wrzucenie do handlera wywołania funkcji NVIC_SystemReset();
Czyli jak widzisz niestety odpadają zabawy chociażby z STL. Nie masz już kolejek, wektorów, stringów i innych przydatnych rzeczy, z przydatniejszych pozostaje oczywiście obiektowość i np. szablony klas/funkcji. Używanie C++ na mikrokontrolerach jest taką trochę orką. Z jednej strony masz do dyspozycji część funkcjonalności programowania obiektowego i odsuwasz się od sprzętu ale z drugiej strony musisz pamiętać, że ten sprzęt cały czas tam jest. To nie jest Java gdzie garbage collector i cudowne obiekty same wszystko zrobią
Tutaj trzeba pamiętać, że nie dopisanie null terminatora zakończy się jazdą po adresach aż do wywalenia HardFault a ciągi znaków porównuje się przez strcmp a nie operator ==. Problemem jest też piekiełko wzajemnych wywłaszczeń przerwań i odpowiednie ustawienie ich priorytetów..... Aha i nie ma obsługi wyjątków także throw Reserve(); niestety nie pomoże
Rejestry w STM32 są traktowane jak każde inne i nie mają tutaj nic do obiektów
Fakt, język assemblera Cortex-M3 jest przeznaczony dla assemblera Cortex-M3 a nie dla ludzi, to nie czasy 80C51 gdzie ręcznie klepało się mov, djnz, czy też mul. Rejestry pozostały jednak rejestrami i teraz są w pełni 32bitowe i jest ich 13 (tych ogólnego przeznaczenia)
Jak byś miał jakieś problemy z kodem albo sprzętem to pisz tutaj śmiało, coś poradzimy.
Ja w zasadzie od razu zacząłem od STM32 także poza specyficznymi zastosowaniami, takimi jak DSP nie widziałem żadnej różnicy pomiędzy C a C++ ;) Zacząłem jednak widzieć różnicę (od PC) jak w kodzie pojawiła mi się dynamiczna alokacja pamięci i operatory takie jak new i delete, czy bardziej klasycznie funkcję malloc, free i realloc. I tu ostrzeżenie, że niestety ale bez RTOS i dobrego zarządzania pamięcią nie ma co nawet myśleć o dynamicznych obiektach. Choćbyś rozciągnął stertę do granic absurdu, to bardzo szybko dostaniesz poważne wycieki pamięci a operator new będzie zwracał albo null albo jakieś losowe śmieciowe adresy nie mające odzwierciedlenia na fizycznych peryferiach. Oczywiście takie zabawy kończą się bardzo szybko wyrzuceniem niemaskowalnego przerwania HardFault i wtedy uratować może albo watchdog albo wrzucenie do handlera wywołania funkcji NVIC_SystemReset();
Czyli jak widzisz niestety odpadają zabawy chociażby z STL. Nie masz już kolejek, wektorów, stringów i innych przydatnych rzeczy, z przydatniejszych pozostaje oczywiście obiektowość i np. szablony klas/funkcji. Używanie C++ na mikrokontrolerach jest taką trochę orką. Z jednej strony masz do dyspozycji część funkcjonalności programowania obiektowego i odsuwasz się od sprzętu ale z drugiej strony musisz pamiętać, że ten sprzęt cały czas tam jest. To nie jest Java gdzie garbage collector i cudowne obiekty same wszystko zrobią :) Tutaj trzeba pamiętać, że nie dopisanie null terminatora zakończy się jazdą po adresach aż do wywalenia HardFault a ciągi znaków porównuje się przez strcmp a nie operator ==. Problemem jest też piekiełko wzajemnych wywłaszczeń przerwań i odpowiednie ustawienie ich priorytetów..... Aha i nie ma obsługi wyjątków także throw Reserve(); niestety nie pomoże :)
Rejestry w STM32 są traktowane jak każde inne i nie mają tutaj nic do obiektów :) Fakt, język assemblera Cortex-M3 jest przeznaczony dla assemblera Cortex-M3 a nie dla ludzi, to nie czasy 80C51 gdzie ręcznie klepało się mov, djnz, czy też mul. Rejestry pozostały jednak rejestrami i teraz są w pełni 32bitowe i jest ich 13 (tych ogólnego przeznaczenia)
Jak byś miał jakieś problemy z kodem albo sprzętem to pisz tutaj śmiało, coś poradzimy.