ARM Cortex M-3 a biblioteka STL

[FlyingDutch]

Witam wszystkich,

chciałem się zapytać, czy programując mikro-kontrolery STM32 (np. STM32F103xx) korzystacie z biblioteki STL (i czy warto)?

Takie pytanie bo brakuje mi np. generycznego typu vector z wszystkimi dla niego metodami - głównie chodzi mi o sort (potrzebuje obliczyć medianę dla bufora DMA z 1024 pomiarami z ACD).

Na razie zrobiłem sortowanie za pomocą "bubble sort" i to mi wystarcza, ale zastanawiam się tak ogólnie, czy jest sens korzystania z STL dla programów dla sprzętu embedded z ARM Cortex M-3?

Z chęcią poznałbym wasze zdanie (boję się narzutów pamięciowych związanych z korzystaniem z STL).

Pozdrtawiam

 

[Zealota]

Osobiście nie programuję z bibliotekami SPL z kilku podstawowych powodów:

- biblioteki te nie są już wspierane przez producenta układów,

- narzut jest bardzo duży na zasoby, 

- istnieje bardzo dobry dokument opisujący programowanie na rejestrach tzw.: "poradnik Szczywronka", który jest dużym ułatwieniem w pisaniu oprogramowania "bezpośrednio na rejestrach" łącznie ze zrozumieniem działania mikrokontrolerów STM32. Zatem korzystanie z bardziej rozbudowanych, słabo udokumentowanych i zawierających błędy bibliotek mija się po prostu z celem.

Więcej krytyki można znaleźć np w tym artykule:

Standard Peripheral Library krytycznym okiem

 

Uważam również, że jednak warto się z nimi zapoznać, z następujących powodów:

- bardzo dużo materiałów i książek jest na nich opartych,

- niektóre składniki tych bibliotek wydają się dość uporządkowane, w końcu celem ich było odłączenie warstwy abstrakcyjnej od sprzętowej i wg mnie autorom się to udało,

- brakuje scentralizowanej dokumentacji do tych bibliotek, są przykłady książki itp, ale to wszystko jest takie rozproszone, mi bardzo mocno utrudnia zgłębianie wiedzy.

Bardzo często jak czegoś nie umiem sam napisać, to potrzebna jest translacja przykładów z STL do "rejestrów". Chodzi oczywiście o zrozumienie działania, a nie o przekopiowanie.

Pisałeś o sortowaniu i medianie...

Sortowania chyba nie znajdziesz w żadnej ze standardowych bibliotek od ST, ale może trzeba głębiej poszukać. Dodatkowo jeśli programista potrafi sensownie oddzielić warstwę abstrakcyjną od sprzętowej to funkcje wyższego poziomu, jak sortowanie, bez problemu zaimplementuje z innych środowisk - to główna zaleta pisania w językach takich jak "C". Oczywiście najbardziej rozwijające jest pisanie takich bibliotek samemu, ale czasami po prostu szkoda na to czasu :)

Za to pojęcia typu mediana, średnia itp wg mnie mają odzwierciedlenie w bibliotece CMSIS.

CMSIS to świetne narzędzie bardzo dobrze udokumentowane, zorientowane na sprzętową obsługę, a zatem czerpiące garściami z najlepszych cech architektury STM32, a szczególnie z takich linii jak STM32F4 czy też F3. Sam bez wcześniejszego przygotowania potrafiłem korzystać z tych bibliotek. Jeśli ktoś myśli o STM32 i DSP (a ciężko o tym nie myśleć : ) to jest to "must have".

Więcej można znaleźć tutaj:

http://www2.keil.com/mdk5/cmsis/

Ogólnie jeśli miałbym poradzić coś początkującemu to na pewno nie "sztywne pchanie" się w SPL. Należy zacząć od poradnika, o którym pisałem wyżej, można poznać HAL'a, liznąć SPL, na pewno warto korzystać z CubeMX. Jako środowisko to Atollic True Studio.

[Elvis]

Pytanie było o STL, a nie SPL - drobna ale istotna różnica :) Moim zdaniem lepiej uważać z C++ oraz bibliotekami w przypadku "małych" mikrokontrolerów. Główny problem to mała ilość pamięci RAM. O ile pamiętam std::vector domyślnie używa dynamicznej alokacji pamięci - ja nie mogę z takich "wodotrysków" korzystać, ale nawet gdyby nie było to zabronione w firmie, radziłbym uważać. Fragmentacja pamięci nie jest problemem w przyadku komputerów stacjonarnych, mikroprocesory z MMU też zobie poradzą - natomiast w małym mikrokontrolerze może być problem.

Z drugiej strony Arduino jest przykładem, że niewielki podzbiór możliwości C++ można spokojnie stosować nawet na małych AVR. Ale jeśli jedyną motywacją dla użycia STL jest algorytm sortowania to może lepiej użyć qsort() ze standardowej biblioteki C?

[Zealota]

4 minuty temu, Elvis napisał:

Pytanie było o STL, a nie SPL - drobna ale istotna różnica 🙂

 

Ooops, pozostaje przeprosić za ignorancję 🙂

A z innej beczki, napisałem mocno nie na temat, co radzicie? Usunąć ten wpis czy jak? 🙂

Edytowano Sierpień 9, 2018 przez Zealota

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[FlyingDutch]

11 minut temu, Elvis napisał:

Moim zdaniem lepiej uważać z C++ oraz bibliotekami w przypadku "małych" mikrokontrolerów. Główny problem to mała ilość pamięci RAM. O ile pamiętam std::vector domyślnie używa dynamicznej alokacji pamięci - ja nie mogę z takich "wodotrysków" korzystać, ale nawet gdyby nie było to zabronione w firmie, radziłbym uważać. Fragmentacja pamięci nie jest problemem w przyadku komputerów stacjonarnych, mikroprocesory z MMU też zobie poradzą - natomiast w małym mikrokontrolerze może być problem.

Cześć,

też maiłem obawy, że narzuty są za duże. Po prostu napiszę sobie tych kilka funkcji, które mi są potrzebne - nie stanowi to dużego problemu (raczej przyzwyczajenia z "wiekszych sprzętów"). Dziękuję wam obu za odpowiedź.

Pozdrawiam

31 minut temu, Zealota napisał:

A z innej beczki, napisałem mocno nie na temat, co radzicie? Usunąć ten wpis czy jak? 🙂

Cześć,

nie przejmuj się: rzeczywiście STL można było łatwo pomylić z SPL (Standard Peripheral Library) w kontekście programowania STM32. Link, który podałeś jest całkiem ciekawy - więc niech już zostanie.

Pozdrawiam

[GAndaLF]

Od około pół roku w pracy rozwijam projekt medyczny na STM32 w C++11. I muszę powiedzieć, że na początku miałem obawy takie same jak wy: narzuty, alokacja dynamiczna itp. Muszę jednak przyznać, że dobrze używany modern C++ w embedded jest niesamowicie wręcz przydatny. Język C++ opiera się na koncepcji zero cost abstractions - możemy używać klas, templatów i innych konstrukcji, które daje nam C++ aby zwiększyć czytelność kodu i zminimalizować ilość głupich błędów, a jednocześnie po kompilacji otrzymujemy ten sam kod w assemblerze. Musimy tylko włączyć optymalizację O2. Pisałem o tym na swoim blogu, przy okazji w linkowanym artykule możesz znaleźć trochę bibliotek do C++ na embedded:

https://ucgosu.pl/2018/05/przydatne-biblioteki-c-stm32/

Przykładowy sposób na poprawienie procedur manipulacji rejestrami sprzętowymi można znaleźć np. w tym artykule:

https://mklimenko.github.io/english/2018/06/19/write-only-variables/

To tylko wprowadzenie do tematu, jest cały ruch propagatorów C++ w embedded, którzy tworzą między innymi swoje własne biblioteki do rejestrów. Warto odwiedzić takie strony jak:

https://embeddedartistry.com/

https://blog.feabhas.com/

http://kvasir.io/

https://modm.io/

Natomiast co do użycia biblioteki STL i vector - STL jest pisany z myślą o użyciu dynamicznej alokacji i exceptionów. Dlatego tylko mały jej podzbiór dobrze współgra z embedded. Istnieje za to biblioteka ETL, która stara się zapewnić potrzebne funkcjonalności w sposób bezpieczny dla systemów embedded - https://www.etlcpp.com/

Przy okazji zachęcam do śledzenia mojego fanpage na fejsie, gdzie od niedawna staram się wrzucać materiały z neta dotyczące C++ w embedded: https://www.facebook.com/ucgosupl/

I zachęcam też do korzystania z Twittera - tam dużo osób wrzuca materiały o embedded C++ polecam na początek użytkowników:
https://twitter.com/mbeddedartistry
https://twitter.com/odinthenerd

 

No i oczywiście zachęcam do własnych eksperymentów z C++ w embedded. Moim zdaniem to jest przyszłość branży.