Luuke

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 s

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

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

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 sa

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

Jeśli akurat jakimś cudem trafisz w dobry stosunek napięcia do częstotliwości to MOŻE silnik ruszy. Istnieje algorytm sterowania U/f w którym stosunek napięcia do częstotliwości musi być stały w całym zakresie prędkości. Na papierze wygląda to fajnie, w praktyce trochę gorzej. Podczas rozpędzania należy wykonać wyjątek od reguły i podać stałe napięcie, żeby w ogóle ruszyć silnikiem. Ponadto silnik pobiera zdecydowanie więcej prądu niż podczas sterowania optymalnym algorytmem. Natomiast jeśli nie trafisz ze stosunkiem U/f to silnik będzie buczał, brał dużo prądu i może się coś spalić. W st