Luuke

W porządku, przejdźmy do praktyki. Zrób przegląd dostępnych sterowników, które będą w stanie wysterować silnik o zadanych parametrach, wrzuć tutaj to co znajdziesz z przemyśleniami który wg Ciebie najlepszy, a my zweryfikujemy czy dobrze wybrałeś. Ot cała praktyka 🙂

Mogę się mylić, ale... Odkąd ST wypuściło CubeIDE tool dostarczany przez AC6, czyli System Workbench for STM32 (SW4STM32) przestał być wspierany (a przynajmniej tak mi się wydaje). W związku z tym w plikach konfiguracyjnych dla CubeIDE mogą znajdować się elementy, które stare ST4STM32 nie koniecznie będzie potrafiło obsłużyć. Generalnie może być problem z tym co chcesz zrobić.

arm_pid_f32() używa zmiennych zmiennoprzecinkowych (floating point) typu float, natomiast arm_pid_q31() i arm_pid_q15() używają zmiennych stałoprzecinkowych (fixed point) pod którymi tak faktycznie kryją się typy integer. W kwestii kiedy czego używać (moja opinia/podejście): jeśli Twój procek ma wbudowane FPU lub nie zależy Tobie na szybkim wykonywaniu obliczeń to śmiało używaj arytmetyki bazującej na typach zmiennoprzecinkowych. Jeśli natomiast zależy Tobie na czasie wykonywania operacji, nie masz FPU w procku (bo jest to na przykład ARM Cortex-M0/M0+) to przyjrzyj się arytmetyce stałoprzecinkowej i skorzystaj z niej. Z doświadczenia w pracy mogę powiedzieć, że fixed point jest równie dobry jak floating point. Odpowiadając jeszcze na drugi punkt, pod kątem jakości/dokładności nie ma to większego znaczenia, u mnie w pracy poprzez algorytm FOC sterujemy silnikami bezszczotkowymi wykorzystując oba typy przy czym zmiennoprzecinkowe na prockach z jednostką FPU (Cortex-M4/M7), a stałoprzecinkowe na prockach bez FPU (Cortex-M0/M0+/M3).

Spojrzałem do repozytorium: oled2 = new SSD1306(i2c_settings); Jeśli nie ma takiej konieczności staraj się nie używać dynamicznej alokacji pamięci, szczególnie w systemach wbudowanych. Nie bez powodu standard MISRA zabrania użycia jakiejkolwiek dynamicznej alokacji pamięci. Sterta (heap) może się nadmiernie rozrosnąć i nadpisać obszar stosu (stack), a wtedy to już czarna magia zaczyna się dziać 🙂 W związku z powyższym na początek proponuję zamienić powyższą linijkę na coś takiego: SSD1306 oled2 { i2c_settings }; edit: Nie bawiłem się FreeRTOSem, ale pamiętam, że jest wybór statyczna/dynamiczna alokacja w jego konfiguracji. Upewnij się, że jest ustawiona statyczna.

Jak najbardziej! Nie ma koniecznie potrzeby uruchamiać tych przerwań i można z samego HF to sprawdzić.

Tu nie chodzi o to jak jest HAL napisany tylko jak działają ARMy. Jeśli się zatrzymuje w HF to przyczyną może być m.in. brak obsługi BF, UF, MMF. W takim przypadku bardziej nawet może się przydać biblioteka CMSIS niż HAL. Zacznij od włączenia i napisania obsługi przerwań błędów w rdzeniu i wtedy sprawdź w którym przerwaniu ląduje procek. Na tej podstawie odfiltrujesz sporą część możliwych przyczyn HardFaulta. Do tego pobierz Programming Manual dla Twojego procka i poczytaj o rdzeniu i jego błędach. W załączniku przykładowe typy błędów w Cortex-M4.

Jeśli będziesz mieć włączoną obsługę tych przerwań to nie będziesz musiał ręcznie sprawdzać tych błędów. Przerwanie samo się wywoła i to Cię już nakieruje gdzie szukać problemu. A jeśli żadne z tych przerwań się nie wywoła pomimo, że będą włączone to będzie znaczyło, że problem leży gdzieś indziej.

Cześć, Masz uruchomione pozostałe przerwania rdzenia (UsageFault, BusFault itd)? HardFault może być spowodowany też brakiem obsługi właśnie tych przerwań. Cytat z Programming Manual PM0214 dla STM32F411CE (Cortex M4)

Kiepsko to widzę w większych projektach 😄 Dobrze zrozumiałem? Wymagane są uprawnienia admina, żeby w ogóle zapisywać pliki?!

Tak uważasz? To jak wytłumaczysz zmianę procesora (i producenta) celem wygenerowania oszczędności na poziomie 100k€ rocznie? Wystarczy, że przy rocznym zapotrzebowaniu jednego miliona sztuk mikrokontrolerów znajdzie się coś tańszego o zaledwie 10 eurocentów. I co? Pozostaniesz wtedy przy pierwszym wyborze, bo podjąłeś STRATEGICZNĄ decyzję o wyborze procka + środowiska od danego producenta? Czy może lepiej wykorzystać DARMOWE środowisko uniwersalne (również open source), podmienić tylko warstwę sprzętową i czerpać korzyści? Uważasz, że to mało? Tyle pamięci to wystarczy do implementacji algorytmu wektorowego sterowania silnikami bezszczotkowymi. Litości... Kilka linijek kodu. Serio, do tego nie potrzeba środowiska typu STM32CubeMX. Nie dopisuj mi proszę czegoś czego nie powiedziałem. Mówiłem o środowiskach, nie o językach programowania. A co do samych języków to nie ma zbyt dużego wyboru: assembler, C, C++ i kilka innych niszowych by się może znalazło, przy czym i tak nie ma to znaczenia, bo wszyscy producenci skupiają się wokół języka C. Owszem, warto znać takie narzędzia, tylko po to, żeby wiedzieć jakim szerokim łukiem je omijać. Biblioteki typu HAL od ST są zbyt pamięciożerne. Czas wykonywania kodu w tych bibliotekach jest za długi. Używając środowiska od producenta jestem związany z tym producentem, a tego nie chcę. Całe te środowiska nadają się ewentualnie, żeby podejrzeć jak dane peryferium obsłużyć i tylko tyle.

Jeśli bawisz się amatorsko / hobbistycznie to nie ma to większego znaczenia, ale jeśli zależy Ci na możliwości przenoszenia kodu między procesorami różnych producentów to używanie dostarczanych przez nich środowisk jest co najmniej niepraktyczne. A weź to jeszcze podepnij pod jakieś CI/CD, gdy masz do dyspozycji jedynie pliki projektu ze środowiska bazującego np. na Eclipsie. Ciarki przechodzą na samą myśl o tym 🙂

Umiejętność czytania not katalogowych i własnoręczne pisanie niskich warstw aplikacji (obsługa peryferiów). Zyskujesz pełną kontrolę nad tym co się dzieje z Twoim prockiem.

Powiem tak, robiąc jakieś demo lub dla siebie coś na szybko to jeszcze spoko, ale pracując nad kodem produkcyjnym radziłbym unikać tego typu generatorów kodu. Niestety okazuje się, że są w nich błędy typu ustawiasz jedno, a dostajesz coś innego. Dla przykładu zegar ADC w rodzinie F0 niby ustawiony na synchroniczny z dzielnikiem 4. Wszystko działa, ADC pięknie zbiera próbki. No ale z czasem stwierdziłem, że jednak zegar asynchroniczny i ciutkę szybszy będzie korzystniejszy pomimo dodatkowego czasu potrzebnego na synchronizację. Klik klik, buduję, wgrywam... brak zmian. Okazało się, że ADC od samego początku działało asynchronicznie, pewnie wygenerowany kod robił przełączenie w złej kolejności. Po dwóch zmarnowanych dniach niedowierzałem jak można spie... zepsuć tak prostą rzecz, nie wspominając już o wypowiedzianych bogatych w przekleństwa wiązankach 😄 Co do samego środowiska, to nie jest po prostu Atolic TrueStudio ze zintegrowanym CubeMX?

Kąt elektryczny dotyczy wirującego pola magnetycznego, a kąt mechaniczny wirnika. Silniki BLDC często mają zwielokrotnioną ilość biegunów magnetycznych - krotność k. Wirnik podąża za wirującym polem magnetycznym, ale niekoniecznie kąt obrotu musi być w stosunku 1:1. Dla przykładu jeśli krotność k = 4 to 1 obrót elektryczny pola magnetycznego spowoduje tylko 1/4 obrotu mechanicznego wirnika. Należy pamiętać, że zwiększenie krotności uzwojenia to nie to samo co zmiana ilości faz w silniku.

Oba typy silników można sterować wykorzystując 6-step lub FOC, ale nieodpowiednie dobranie sterowania spowoduje spadek jakości sterowania i wspomniane już wcześniej efekty uboczne. Różnica w sygnałach BEMF wynika ze sposobu nawinięcia uzwojeń (po lewej BLDC, po prawej PMSM).