Luuke

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

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 sterowaniu silnikami BLDC/PMSM to one narzucają jak należy nimi sterować i kiedy trzeba robić odpowiednie przełączenia. A jak nie to silnik stanie i odmówi posłuszeństwa

Warto zacząć od ujednolicenia nazewnictwa, jest to strasznie namieszane. Silnik BLDC ma trapezoidalny przebieg BEMF, natomiast sinusoidalny przebieg ma silnik PMSM (czasem nazywany BLAC). Optymalny sposób sterowania jest zgodny z przebiegiem BEMF, tzn. dla BLDC będzie to sterowanie 6-step, a dla PMSM sterowanie z wykorzystaniem FOC. W sterowaniu 6-step można bez problemu wykorzystać obserwację BEMF i na tej podstawie ustalać moment przełączenia. Świetnie to Dondu opisał na swojej stronie. W sterowaniu FOC wykorzystuje się obserwację przebiegów prądów fazowych na podstawie których ustala się położenie wirnika i oblicza wysterowanie wyjść sterujących na kolejny cykl. Sygnały sinusoidalne uzyskuje się poprzez odpowiednie wysterowanie wyjść PWM.

Owszem, może chodzić latami, ale trzeba się postarać i pobawić, żeby system był stabilny. Natomiast w standardowej konfiguracji wystarczy najzwyklejszy zanik zasilania, żeby padła karta SD i malina już nie wstanie Edit: Tfu, nie zanik pamięci, tylko zanik zasilania

Na aliexpress wpisz "water pump 5v". Cena to jakieś ~5-10zł.

Raspberry Pi jest zbyt niepewne, żeby użyć w terrarium, za często potrafi się coś zawiesić. Do sterowania kablem grzewczym sugerowałbym użycie termostatu RT-2, którym można regulować nastawy temperatury. U mnie bezawaryjnie działa już ponad 2 lata i jest bardzo popularny wśród terrarystów. Kiedyś też chciałem bawić się we własny system. Później kabel dostał termostat RT-2, a żarówka do wyspy ciepła cyfrowy programator czasowy. Miał być zdalny system podglądu temperatury i wilgotności w terrarium, są nawet kable rozprowadzone w ściankach. Skończyło się na tym, że po zachowaniu węża widzę czy temperatura jest odpowiednia i generalnie nic nie tykam

Cześć, Od kilku dni zajmuję się konfiguracją i testowaniem środowiska unit testowego dla projektu pisanego w języku C opartego na procku STM32F030K6. Z początku próbowałem podziałać z Ceedling/Unity jednak w trakcie prac wyszło, że jest możliwość wykorzystania wspólnego tool'a w wielu projektach, przy czym część z nich jest pisana w języku C++. W związku z tym zacząłem się bawić narzędziem Googletest. Bez problemu można przy pomocy tego framework'a testować kod w C oraz C++. Niestety problem pojawia się w momencie mockowania funkcji. Googlemock już sobie z tym nie radzi (dedykowany do C++). Z pomocą przychodzi FFF (Fake Function Framework), który jest dedykowany do języka C, bez problemu tworzy fałszywe funkcje i imituje żądane działania. Osobnym tematem jest analiza statyczna kodu. Do tego celu używamy PC-Lint, który można skonfigurować pod różne standardy, m.in. MISRA C. Pozdrawiam

Witamy na forum! Wg mnie załóż temat - worklog w którym będziesz opisywać postępy pracy i w którym inne osoby będą mogły podawać swoje sugestie następnych kroków. Zostanie też ślad dla potomnych

Owszem, podstawowe funkcjonalności się pokrywają, ale problem pojawia się, gdy zaczniemy się zagłębiać w bardziej zaawansowane elementy. LL ma lepszą optymalizację kosztem m.in. przenoszalności. Do skakania między rodzinami bardziej przydatny jest HAL. Oczywiście, że nie! Istnieje dokumentacja do procka (DS, PM i RM) oraz dokumentacja do bibliotek (HAL, LL, SPL), obie generowane niezależnie.

Po krótkim czasie można lecieć z pamięci (tak samo jak z każdą inną biblioteką), szczególnie jeśli nie zmieniamy rodziny procka. Czasem warto nawet zainwestować podwójną robotę. Pisanie na rejestrach wrednie się mści gdy pracujemy w zespole i ktoś inny musi przeczytać to co napisaliśmy. Dlatego często i tak pisze się wrappery do tego typu kodu. Problem pojawi się też gdy sami chcemy przeczytać własny kod po upływie dłuższego czasu. Zrozumienie co dany bit robi w danym rejestrze będzie wymagało ponownego zajrzenia do RM. Low Level jak najbardziej ma pełną dokumentację, która jest generowana na podstawie komentarzy w kodzie. W jednym się zgadzamy, do RM zajrzeć trzeba :)

Rejestry protokołu Modbus (tzw. Holding Registers) są nijak powiązane z rejestrami mikrokontrolera. Możesz je zaimplementować w postaci tablicy w programie na uC. Wtedy Master wpisując wartość pod jakiś rejestr będzie zapisywał do tej tablicy. W międzyczasie aplikacja na uC będzie sobie sprawdzać wartości tablicy i używać zadane tam wartości do wyznaczonych celów.

Dla mnie używanie LL to jak pisanie na rejestrach tylko bardziej czytelne i łatwiejsze w zrozumieniu. Oba wymagają takiego samego zapoznania się z RM. Dla przykładu poniższe linijki robiące dokładnie to samo: SysTick->CTRL |= SysTick_CTRL_TICKINT_Msk; LL_SYSTICK_EnableIT(); Zaglądamy co robi funkcja: /** * @brief Enable SysTick exception request * @rmtoll STK_CTRL TICKINT LL_SYSTICK_EnableIT * @retval None */ __STATIC_INLINE void LL_SYSTICK_EnableIT(void) { SET_BIT(SysTick->CTRL, SysTick_CTRL_TICKINT_Msk); } I jeszcze: #define SET_BIT(REG, BIT) ((REG) |= (BIT))

Czujnik jest podłączony do zasilania przez nóżki VCC i GND. W związku z tym dopóki cały układ jest zasilany na nóżkach sondy jest napięcie, które powoduje elektrolizę miedzi. Aby temu zapobiec możesz dodać sterowanie tego zasilania przez mały tranzystorek dodany w linii zasilania czujnika i sterowany przez dodatkowy pin Arduino. W programie będzie coś takiego: wybudzenie procka -> włączenie zasilania czujnika -> odczekanie chwili dla ustabilizowania odczytu -> pomiar -> wyłączenie zasilania czujnika -> (podlewanie) -> uśpienie procka. W sumie to nic dziwnego, że nie ruszyła Wydajność prądowa mikrokontrolerów w prockach jest bardzo niska.