Elvis

Czy ten kod nie jest przypadkiem napisany za pomocą bibliotek Arduino? Tak tylko pytam, bo podobno to zło wcielone, absolutnie nic nie warte i używane wyłącznie przez zupełnie początkujących amatorów.

A ja się wtrącę, chociaż wcale nie po to żeby komukolwiek przyznawać lub ujmować rację. Chciałbym tylko wyjaśnić kilka spraw zanim osoby zaczynające przygodę z Raspberry Pi lub innymi komputerami jednopłytkowymi zupełnie się pogubią. Tematem tej dyskusji jest robienie tworzenie kopii zapasowej zawartości karty SD - a to można zrobić na wiele sposobów. Typowe obrazy kart mają rozszerzenie .img i zawierają dokładną kopię - sektor po sektorze całej karty. Taki obraz jest dość duży, ponieważ zawiera zarówno ważne dane, jak i ogromne ilości samych zer umieszczonych w nieużywanych obszarach pamięci. Jego zaletą jest prostota użycia - wystarczy włożyć kolejną kartę do czytnika i nagrać obraz. W ten sposób dostajemy dokładną kopię zawartości karty, niejako niezależnie od systemu (możemy tak skopiować zarówno obraz Raspbiana, Windowsa IoT, czy Androida), ale również niezależnie od platformy (tak samo przygotujemy i nagramy obraz np. dla Odroid-N2, czy STM32MP1). Wadą takiego rozwiązania jest wspomniana wielkość obrazu, która odpowiada wielkości karty. Co prawda taki obraz można bardzo skutecznie skompresować, ale "goły" plik będzie miał wielkość zbliżoną do pojemności pamięci, czyli powiedzmy 16GB, 32GB itd. Natomiast metoda zaproponowana przez kolegę @ethanak działa zupełnie inaczej - zamiast kopiować wszystko co jest na karcie i tworzyć dokładny obraz, kopiujemy tylko pliki. To znacznie bardziej przypomina postępowanie na standardowym komputerze, bo w końcu robiąc backup naszych super-fajnych projektów najczęściej kopiujemy tylko pliki, a nie cały obraz dysku, który zawiera terabajty zer, albo nieużywanych danych. Stosowanie takiej metody wymaga jednak nieco więcej wiedzy i bywa trudniejsze przy odzyskiwaniu obrazu. Warto natomiast zapamiętać, że w przypadku Raspberry Pi cały obraz systemu jest przechowywany w postaci plików - więc można zastosować obie metody. Każda ma wady i zalety, o których warto byłoby podyskutować, ale w znacznie spokojniejszej atmosferze. Są również dostępne platformy, gdzie nie wszystkie dane są zapisywane w postaci plików - i wówczas metoda zaproponowana przez kolegę @ethanak-a nie zadziała, albo raczej nie całkiem. Ale w przypadku Raspberry Pi, rsync jak najbardziej nadaje się do tworzenia kopii zapasowej karty - i za jego pomocą można skopiować tylko zmienione pliki, nie zachowując ogromnej ilości niepotrzebnych danych.

@PrimeSoul przeklikałem cały przykład w najnowszym CubeMX 5.4.0 i wszystko działa poprawnie - chociaż używam aktualnie Atollica zamiast OpenSTM32. Wcześniej te same przykłady robiłem na CubeMX 5.3.0 używając OpenSTM32 i ten przykład działał bez problemu. Sprawdź, czy na pewno wybrałeś poprawnie wszystkie opcje odnośnie DMA, w szczególności kierunek: "Memory To Peripheral" Jak przystało na programistę mogę spokojnie napisać "u mnie działa"

W tej chwili zupełnie nie pamiętam tego przykładu Ale wydawało mi się że wszystko działało poprawnie. Mogę później spróbować wykonać ten przykład na aktualnym CubeMX i dać znać czy u mnie działa

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.

Nie jesteś specjalistą od AVR? Trochę zaskakuje, ale to nieważne. W każdym razie jaka jest różnica między korzystaniem z biblioteki hal a Arduino? Tak bardzo pogardzasz użytkownikami Arduino a sam z bibliotek korzystasz - nie widzisz w tym sprzeczności, nie wstyd Ci trochę czasem?

A jak USB obsługiwać na stm32?

Do obsługi USB wystaprczy AVR, cały problem to oprogramowanie. Więc trudniejsze pytanie to - jak oprogramować USB?

Ta dyskusja już dawno nie ma sensu, albo chociaż związku z tematem watku - więc może prośba do moderatora o wydzielanie tej zaciętej dyskusji do oddzielnego tematu? W każdym razie moje podsumowanie jest takie: oryginalny kod działa tak samo z const, jak i z define. Natomiast ogólnie lepiej używać define niż const, a najlepiej constexpr. Chyba że ktoś ma inne zdanie, ja chętnie dowiem się czegoś nowego

To chyba udało ci się w końcu oszukać kompilator. W sumie to wiara w moc optymalizacji jest ułomna, a jak widać na załączonym obrazku nawet prosty program może przechytrzyć kompilator. A tak z ciekawości - gdyby zamiast const użyć constexpr to kod byłby taki sam w obu przypadkach? Może należy jednak polubić C++11 albo wrócić do stylu C.

Zapomniałeś o opcji dla linkera - bez niej nieużywane śmieci zostają w pamięci.