Skocz do zawartości

Luuke

Użytkownicy
  • Zawartość

    114
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    1

Wszystko napisane przez Luuke

  1. 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?
  2. 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.
  3. 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).
  4. 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
  5. 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.
  6. 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
  7. Na aliexpress wpisz "water pump 5v". Cena to jakieś ~5-10zł.
  8. 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
  9. 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
  10. 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
  11. 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.
  12. 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 :)
  13. 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.
  14. 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))
  15. 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.
  16. Zasilanie: Pamiętaj, że w pełni naładowany pakiet LiPo 3S ma napięcie większe niż nominalne 11,1V. Koniecznie też dodaj zabezpieczenie przed nadmiernym rozładowaniem. Czujnik wilgotności gleby: Musisz dodać wyłączanie zasilania czujnika albo spodziewaj się, że za miesiąc nic z niego nie zostanie. Elektroliza zje całą miedź na nóżkach sondy. Polecam też czujnik pojemnościowy. Pompa: Wystarczy Ci minipompka na 5V od Chińczyków za kilka złociszy. Przy mojej roślinie sprawdzała się świetnie Układ nie powinien się grzać. Jeśli chcesz, żeby długo pracował na jednym naładowaniu to pamiętaj, żeby go usypiać, kiedy nie musi pracować.
  17. Tedy23, ten uklad możesz wykorzystać samodzielnie bez użycia Arduino. W jego skład wchodzi ESP8266 o taktowaniu 80MHz (chyba tyle) i zintegrowanym module WiFi. Na tym można nawet webserwer postawić. Tylko brać i programować
  18. ethanak, w sumie powiedzieliśmy o tym samym NodeMCU v3 zawiera ESP8266 w module ESP-12E. Wgrywając soft NodeMCU można kodzić układ w języku Lua.
  19. Zgaduję, że bierzesz pod uwagę tylko opcję bezprzewodową. Propozycje: - dodanie modułu BT (np. HC-05) do układu i komunikacja bezpośrednio z telefonem - wykorzystanie układu z WIFI (np. NodeMCU) Osobiście spróbowałbym tego drugiego. Koszt NodeMCU z Chin to ~2-3€ i nie potrzeba programatora. Jeśli układ miałby stały dostęp do Internetu np. przez domowe WIFI to może pobierać godzinę z serwera NTP. Cyfrowe czujniki temperatury DS18B20 mogą się komunikować po 1-Wire. Impulsy to zwykłe wejście I/O. Telefon też będzie mógł się z nim skomunikować.
  20. Luuke

    C++ nauka

    Opus magnum w uproszczeniu to odświeżona Symfonia uzwględniająca zmiany w języku C++ jakie wprowadzono w standardzie C++11. Akurat mam wypożyczone z biblioteki i póki co nie miałem odczucia kiepskiej jakości kartek. Zestaw można kupić za ~100zł.
  21. Zmiana kierunku powinna być z grubsza bezbolesna. Na pierwszym roku i tak większość zajęć się pokrywa. Papierek może i ważny, ale pamiętaj, że pracodawców bardziej interesuje wiedza i umiejętności praktyczne kandydata. Poczytaj sobie też: https://www.forbot.pl/forum/topics19/wybor-studiow-vt15360.htm
  22. Dobrze prawi, polać mu! Na własnym przykładzie: Przed wyborem studiów miałem w głowie myśl "chcę budować roboty" nie mając jakielkolwiek wiedzy na ten temat. Z początku chciałem iść na AiR ale ostatecznie wybrałem MTR na Wydziale Mechanicznym na PWr. Bazowałem tylko i wyłącznie na podstawie opisów na stronie uczelni. Kierunek można zmienić, na pierwszym roku wszędzie praktycznie to samo jest. Kierunek fajny, ale pozostał jakiś niedosyt/niesmak. Generalnie było "wszystko i nic", tzn. poruszyliśmy wiele tematów z mechaniki, elektroniki i informatyki, ale wg mnie (i wielu znajomych) zbyt ogólnie. Teraz najpewniej bym wybrałem elektronikę jako kierunek. Znacznie więcej nauczyłem się będąc członkiem koła naukowego i wykonując projekty z kolegami. Na drugim stopniu studiów udało mi się też znaleźć pracę jako programista co dodatkowo pozwoliło mi nabyć wiedzę i doświadczenie. Ostatecznie skończyło się tak, że jestem programistą systemów wbudowanych, ponieważ czułem się w tym mocny. Robotami zajmuję się po godzinach jako przyjemność i hobby Błąd! Programistów jest sporo, ale jeszcze więcej jest otwartych rekrutacji na stanowiska. Generalnie ciągle brakuje DOBRYCH programistów, którzy wiedzą co robią. Nie potrzeba super tajemnej wiedzy, wystarczy znajomość składni języka, trochę logicznego myślenia, chęci kombinowania i wymyślania nowych rozwiązań. Trzeba tylko chcieć! O jery, ale chaotycznie to wszystko napisałem... No ale nie ma czasu na wywody, kod sam się nie napisze
  23. W STM32CubeMX można wybrać używaną bibliotekę dla każdego peryferium indywidualnie, więc zgaduję, że tak
  24. No właśnie dlatego moją preferowaną praktyką jest wygenerować sobie kod tylko po to, żeby podejrzeć jak są konfigurowane i uruchamiane poszczególne peryferia. Ja sobie mówię, że to jest bardziej czytelna zabawa na rejestrach
  25. Proponowałbym jednak naukę HAL lub LL. ST się przyznało, że SPL to jedna wielka wtopa (Z własnego doświadczenia) Żeby szybko wystartować projekt używa się generatorów, ale z czasem okazuje się, że nie wszystko da się w nich zrobić i wtedy następuje przejście na ręczną konfigurację, przy czym nadal część modułów się powiela. Po pewnym czasie developmentu powstaje pewna warstwa abstrakcji, która pozwala całkowicie się odciąć od sprzętu i skupić na samej aplikacji. Wtedy nie ma już potrzeby zabawy z rejestrami. We wszystkich przypadkach czystość kodu jest priorytetowa, aby nie tracić czasu na jego "dekodowanie" przy ewentualnym debugu lub rozwijaniu.
×
×
  • Utwórz nowe...