Elvis

Skoro za pomocą LED-a i multimetru widzisz, że pin jest poprawnie sterowany, to nie musisz nic w kodzie zmieniać - przecież działa poprawnie. O ile rozumiem problem jest albo z działaniem samego programu, albo sterownikiem silnika. Jeśli podłączysz diodę i uruchomisz program, to działa / miga poprawnie? Pytanie pomocnicze: z czego zasilasz silnik oraz bluepill?

Pierwsze pytanie - czy używasz płytki Nucelo-103rb, czy czegoś innego? Chodzi mi głównie o to czy używane piny są wolne. Druga sprawa - próbowałeś testować diodą led lub multimetrem? Warto zacząć od czegoś prostego, upewnić się że sterowanie pinem działa i dopiero wtedy podłączyć silnik. I ostatnie pytanie - testowałem na Nucleo103rb kod sterujący PA15, inicjalizacja taka jak u Ciebie, tylko z dwoma linijkami o których pisałem wcześniej - mógłbyś sprawdzić czy taki program działa poprawnie? Jeszcze jedno pytanie - napisałeś: "wstawiając breakpointy i przeglądając ODR można zauważyć, że stan na pinie zmienia się," - jak rozumiem to znaczy że zmienia się wartość w rejestrze ODR, co w sumie jest oczywiste - ale czy testowałeś stan pinu?

Może i faktycznie CubeMX, jakoś się zapatrzyłem na "Korzystając z kursu STM32 F1 HAL #4". W każdym razie PA15 został wybrany nieco niefortunnie. W datasheecie jest taka informacja: Jak widać domyślnie ten pin jest używany przez interfejs JTAG. Dlatego może nie działać jeśli go odpowiednio nie skonfigurujemy. Po pierwsze wybierając piny trzeba sprawdzić do czego są podłączone oraz w dokumentacji upewnić się, czy to na pewno zwykły pin, a nie jakiś "specjalny". W tym przypadku pewnie najłatwiej byłoby skorzystać z innego pinu i po sprawie. Natomiast jeśli bardzo chcemy używać PA15, a JTAG nie jest nam potrzebny, trzeba zmienić jego funkcję na GPIO: __HAL_RCC_AFIO_CLK_ENABLE(); __HAL_AFIO_REMAP_SWJ_NOJTAG(); Właśnie dlatego pytałem o kod konfigurujący pin - bo jeśli tego wywołania w nim nie ma, to PA15 ma prawo nie działać. Tzn. działa, ale jako JTDI i stan ODR nie ma najmniejszego znaczenia. Z tego co widzę CubeMX nie wyłącza JTAG-a, więc możliwe że to była przyczyna całego zamieszania.

@Bornhartt Pokaż kod, którym konfigurujesz pin PA15.

Z tego co pamiętam, reguły PPF na forum zabraniają takich osobistych przepychanek, przechwałek itd. Proponuję użyć google, skoro o [Imię i nazwisko usunięto], czyli RFM / es2 / InspektorzeGadget można wszystko wyszukać - zarówno doświadczenie zawodowe, wykształcenie, jaki i projekty, którymi się tutaj przechwala - to i o mnie można. Wystarczy tylko chcieć.No chyba że poznanie obsługi google to też rok ciężkiej pracy

Tak jak wcześniej myślałem, ten temat wcale nie służy opisaniu akceleratora, czy jak ten sterownik wyświetlacza się nie nazywa, tylko przechwalaniu się i budowaniu własnego ego. Nie zamierzam się do tego przyłączać, bo to chyba niezgodne z nową polityką forum (PPF), chociaż czasem faktycznie ciężko się powstrzymać. A odpowiadając możliwie ogólnie, żeby nie być posądzonym o personalne wycieczki - tak pracowałem z różnymi mikroprocesorami i mikrokontrolerami, w tym opartymi o rdzenie ARM. Wiem jakie narzędzia się do tego używa i jak skomplikowane jest to zadanie. Więc jeszcze raz napiszę - przesiadka z atmegi na stm32 to nie jest skomplikowane zadanie. Zaletą stm32 jest bardzo rozbudowana rodzina układów, więc jak ktoś pozna małe i proste jak chociażby stm32f2, zawsze może zająć się trudniejszymi - jak chociażby wspomniany stm32h7, albo stm32mp1. Ale jeszcze raz podkreślam - to nic trudnego, a już na pewno poznanie tych układów nie upoważnia nikogo do przechwalania się, ani ubliżania osobom używającym Arduino.

ARM nie ma peryferiów, bo to nazwa firmy. Nawet Cortex-M3 prawie peryferiów nie ma - raptem NVIC, SysTick, pewnie kilku teraz nie pamiętam. Cała reszta to dzieło firmy ST (czy tam STMicroelectronics), w zależności od wybranego układu modułów jest więcej lub mniej, ale nie demonizujmy - przez 3 lata to można się nauczyć własne moduły projektować. Moim zdaniem przesiadka z atmegi na stm32 to nic specjalnie trudnego. Wymaga trochę wysiłku, ale w żadnym wypadku to nie jest tytaniczne wyzwanie, a opanowanie peryferiów stm32 to wcale nie powód do dumy i chwały. Po prostu kolejny mikrokontroler, ani najtrudniejszy, ani najłatwiejszy do opanowania.

W sumie to offtopic, ale jedna rzecz nie daje mi spokoju: Rok to 52 tygodnie, mnożąc przez 6 dni i 10h daje to 3120 godzin, czyli w przeliczeniu na typowy etat 160 godzin miesięcznie - 20 miesięcy. Przyjmując 16 godzin i 7 dni w tygodniu to już 5824 godziny, czyli 36 miesiące, a więc 3 lata pracy na pełny etat... I tak się zastanawiam, dlaczego opanowanie prostych ARM Cortex-M zajęło aż tak dużo czasu? Dla porównania studia inżynierskie to ok. 2000-2500 godzin, a znam niejednego studenta, który pisze całkiem sprawnie programy na STM32. To kwestia talentu, zdolności, czy całe to oszacowanie potrzebnego czasu to jedna wielka bajka?

Dodatek w postaci modułu ISD nie jest zbędny, jest ważnym elementem projektu. Ten sam projekt można zrealizować na mnóstwo sposobów, jedne są lepsze, inne gorsze - ale które są jakie zależy od kryteriów oceniania. Czasem lepsze jest to co wymaga mniej elementów, ale innym razem to co jest np. bardziej bezawaryjne, albo łatwiejsze (szybsze) do implementacji. Nie można tak odgórnie zakładać, że coś jest złe bo mi się nie podoba, albo jest do niczego bo ja bym to inaczej zrobił. W sumie tak podchodząc do tematu można każdy projekt skrytykować, a chyba nie o to chodzi. Projekt kostki nie będzie produkowany seryjnie, powstał aby zrealizować pewną funkcjonalność i z tego co pisze autor - spełnia oczekiwania.

A jest niby związek tego "akceleratora" z mówiącą kostką? Użytkownik @jerzyz opracował projekt, opisał jak go zrobił - i bardzo dobrze, miło widzieć że osoby przygotowują swoje projekty, maja z tego dużo zabawy i potrafią się nią podzielić z innymi.

A tak z ciekawości zapytam - czemu właściwie służy ten temat?

@muchac35 trochę się nie zrozumieliśmy - dla mnie GPIO oznacza General-purpose input/output (https://en.wikipedia.org/wiki/General-purpose_input/output), czyli po prostu pin mikroprocesora. Skoro podłączyłeś wiatraczek do linii zasilania 3.3V to zupełnie inna sprawa i większość moich uwag (poza zakłóceniami) jest nieaktualna.

To może ja trochę źle zrozumiałem. Jeśli to linia zasilania 3.3V to powinno być ok, zrozumiałem że chodzi o zwykły pin GPIO, co pewnie też by działało, ale raczej krótko. Jedyne o co bym się obawiał to ew. zakłócenia, ale bez oscyloskopu ciężko sprawdzić co tam się dzieje. Jak będzie się malinka resetowała to pewnie coś jednak siało.

Nadal nie jestem pewien czy taki pomiar pokazuje chwilowe zmiany, ale nawet zakładając że Imax jest 63mA i nie generowane są żadne impulsy napięciowe, czy prądowe to w przypadku RPi mamy: Więc ja zostanę przy moim zdaniu, że długo takie połączenie nie podziała

Bardzo mocno odradzałbym podłączanie wentylatora bezpośrednio do GPIO jakiegokolwiek mikroprocesora. Po pierwsze 55 mA to duży prąd dla pinu, który nie jest przystosowany do dostarczania prądów - ma sterować napięciowo, a nie cokolwiek zasilać. Druga sprawa to sam sposób pomiaru. Zmierzona wartość to prąd średni w czasie pracy. Podczas uruchamiania pewnie był większy - jako test proponuję zmierzyć prąd przy zatrzymaniu wiatraczka palcem. Co więcej każdy silnik potrafi generować spore zakłócenia, które trafią bezpośrednio do skomplikowanego procesora... Moim zdaniem to przepis na uszkodzenie malinki.