DRO STM32F103C8T6 (Blue Pill)

tuxcnc pisze:CKS32F103C8T6.

niby się bulwersujesz a tu skrobiesz że CKS następny klon udający STM. Choć zaczyna być to wszystko irytująca kupujesz stm a dostajesz, coś takiego a wszyscy piszą że wszystko taki same.

tristar0 pisze: ↑

12 paź 2022, 18:12

niby się bulwersujesz a tu skrobiesz że CKS następny klon udający STM.

Mam do Ciebie ogromną prośbę, czytaj uważnie moje posty zanim je skomentujesz.
Tam naprawdę jest napisane jasno i wyraźnie co robię i dlaczego.
A robiłem próby uruchomienia kodu z pierwszego posta w tym temacie na obecnie dostępnych i tanich płytkach.
Teraz piszę program od nowa, w środowisku STM32CubeIDE, żeby podobnych jajec uniknąć w przyszłości.

tuxcnc pisze:Teraz piszę program od nowa, w środowisku STM32CubeIDE, żeby podobnych jajec uniknąć w przyszłości

Obawiam się że tych jajec w przyszłości nie unikniesz bo za jakiś czas znów w Blue Pill włożą coś innego bo będzie jeszcze taniej i jeszcze bardziej będzie udawać stm.

Napisałem od podstaw w środowisku STM32CubeIDE program na STM32F401ccu6, czyli tę płytkę, która przynajmniej chwilowo jest bezkonkurencyjnym zwycięzcą w kategorii "STM32 możliwości/cena" (na Aliexpress ~15 PLN plus wysyłka).
Wstyd się przyznać, ale pieprzyłem się z tym cały dzień, a przecież to wyjątkowo prosty program.
STM32CubeIDE nigdy nie używałem, choć próbowałem kilka razy. Największym problemem jest niedostępność dokumentacji. To znaczy, że dokumentacja na pewno jest, ale znaleźć ją w Internecie nie sposób. O co by się Google nie pytać, to się dostaje sto linków do kretyńskich publikacji jakichś debili, którym coś się fuksem udało i mają imperatyw pochwalić się tym w necie...
Niemożliwością jest przekopać się przez te góry śmieci żeby odnaleźć wartościowe treści...
Najpierw myślałem że szlag mnie trafi, bo mi przy edycji pinów kasowało fragmenty mojego kodu. Rozwiązanie okazało się wyjątkowo proste - kod użytkownika należy wpisywać pomiędzy komentarzami "USER CODE BEGIN ..." a "USER CODE END ...", wtedy rekonfiguracja zostawia te fragmenty kodu tak, jak je zastała. Aż trudno w to uwierzyć, ale tak podstawowej informacji nie znalazłem nigdzie i sam się musiałem tego domyślić...
Drugie pół dnia zmarnowałem na przejście z arduinowego Serial.print() na standardowe printf(). O ile sposób przekierowania standardowego wyjścia na port szeregowy znalazłem od razu, to efekt był daleki od oczekiwań...
Otóż taki prosty kod doprowadzał mnie do szału: Dla lepszej czytelności usunąłem wszystkie komentarze, ale jak wcześniej pisałem, są one bardzo istotne.
Funkcja printf() działa poprawnie z podanymi argumentami, ale oczywiście pewny tego być nie mogłem.
Funkcja HAL_Delay() też działa poprawnie, czego też pewny być nie mogłem.
Tak więc szukałem przyczyny w składni, typach argumentów, a nawet w systemie przerwań...
Otóż wynik działania tej pętli można przewidywać w taki sposób, że co około 50 ms jest wysyłany jeden pakiet danych na port szeregowy, natomiast w rzeczywistości wypluwa ona wiele pakietów na raz, jak z karabinu maszynowego, po czym jest kilkusekundowa cisza...
W końcu okazało się, że przyczyną jest używanie przez funkcję printf() bufora... Najzwyczajniej printf() pisze do bufora, a nie bezpośrednio na wyjście, zawartość bufora jest natomiast wysyłana na wyjście w całości i do tego w momentach które trudno przewidzieć. Na szczęście można funkcję printf() zmusić do tego, żeby nie korzystała z bufora i wysyłała dane od razu na wyjście...
Powyższe jest doskonałym dowodem na to, że korzystanie z ArduinoIDE jest w dłuższej perspektywie głupotą.
Aczkolwiek pisanie prostych programów w tym środowisku jest dziecinnie proste, o tyle napisanie bardziej zaawansowanego kodu jest drogą przez mękę, najpierw zaczynają się schody, potem schody są coraz wyższe, a na koniec trafiamy na ścianę, na przykład w postaci bibliotek rozbabranych do połowy i porzuconych w takim stanie, czego doskonały przykład mamy tutaj.
Kodu napisanego w ArduinoIDE na STM32F103 nie da się w żaden sposób przenieść na STM32F401 tylko i wyłącznie z tego powodu, że autor ukrywający się pod ksywą CARLOS biblioteki dla F103 przerobił, a biblioteki dla F401 rozbabrał i porzucił, bo trafił na zbyt wiele problemów. Tutaj akurat ktoś sprawę totalnie spartaczył, tego kto to już nie wiem, ale albo biblioteki są z różnych wersji kompilatora, albo autor bibliotek miał kompatybilność w głębokim poważaniu. Dość powiedzieć, że argumenty pewnych funkcji w F103 są zadeklarowane jako zmienne, a w F401 jako stałe... Po prostu kod napisany pod F103 nie ma prawa zadziałać w F401 i faktycznie nie działa...
No a potem ktoś, kto korzystał z ArduinoIDE bo łatwo i szybko, musi zapomnieć o wszystkim czego się nauczył i zacząć wszystko od zera w jakimś poważniejszym środowisku, albo poprzestać na projektach na poziomie Blink...

Wracając do programu DRO napisanego na STM32CubeIDE, to wygląda na to, że wszystko działa jak powinno i kod będzie przenośny na dowolny STM32, pod warunkiem że posiada on potrzebne zasoby.
Niestety nie mam w tej chwili ani czasu, ani głowy żeby wszystko sprawdzić i dopieścić kod, więc na razie go nie opublikuję.