Elvis

@mw9501 nie udostępniłeś całego kodu, więc próba pomocy to niestety zgadywanie. Zacznę więc od najprostszego pytania - włączyłeś taktowanie portu z pinem RX?

Faktycznie, nie warto się tłumaczyć. Może i nie warto nawet nic pisać.

Ja nie mam siły dalej dyskutować - tak jak napisałem wcześniej, zachęcam do poczytania dlaczego w Linuxie jest oddzielny zegar czasu rzeczywistego, a oddzielny monotoniczny.

Ja też trochę eksperymentowałem, najpierw z MSP430, później LPC2138 - w sumie to ja nawet nie miałem czasu na testowanie RTC, ale na produkcji narzekali, że wskazania zegara różnią się o kilka godzin zanim urządzenie zostanie wysłane do klienta. Z tego co pamiętam kwarce używane do taktowania mikrokontrolerów mają o wiele wyższą dokładność niż używane w typowych modułach RTC, stąd było moje zaskoczenie dlaczego miałoby być inaczej. Ale niezależnie od wszystkiego, po pewnym czasie każdy, nawet drogi moduł wskazuje coś innego niż wzorzec czasu.

To zostawmy tą dyskusję w takim stanie, że każdy ma swoje zdanie i niech sobie z nim żyje jeśli mu tak wygodnie.

Ja już wykonywałem podobne eksperymenty - co prawda bez arduino, ale za to z większą ilością egzemplarzy. I zapewniam, że po kilku tygodniach zegary RTC oparte o tanie rezonatory kwarcowe wskazują niesamowite bzdury.

Zostawmy może teoretyczne gdybania - do obliczania przedziałów czasu potrzebny jest zegar monotoniczny, jak go zbudujemy to oddzielny temat. Faktycznie korekta o kilka sekund dziennie nie będzie przez nikogo zauważona, ale już np. używanie takich zegarów w programach może mieć opłakane rezultaty (a z takim błędem dopiero co walczyłem, może jestem przewrażliwiony ). Chodziło mi tylko o to, że z dwojga złego lepszym zegarem do liczenia czasu pracy było użycie millis() niż RTC. Chociaż oczywiście tworząc zestawienia będziemy potrzebowali godzin z zegara czasu rzeczywistego. Ale aby dokładnie ustalić ile czasu coś trwało (np. praca), zegar nie może być przestawiany.

Rezonatory kwarcowe na 32kHz znane są ze słabej dokładności - można ją kompensować ustawianiem pojemności itd. Ale nie oszukujmy się, po kilku dniach, czy miesiącach czas wskazywany przez taki RTC będzie odbiegał od wzorca. W zależności czy ta różnica będzie dodatnia, czy ujemna - musimy skorygować wskazania zegara, inaczej to już nie będzie czas rzeczywisty. Dochodzi jeszcze cofanie o godzinę, albo dodawanie godziny co roku ale to inna historia. Ja rozumiem RTC jako aktualny czas, czyli czas wskazywany przez zegar z kukułką wiszący na ścianie. Natomiast to liczenie liczby sekund od chwili zero to dokładnie czas monotoniczny. Nie ma sensu żebym tutaj robił własne wykłady, @ethanak lubisz bawić się linuxem, poczytaj ile rodzajów zegarów jest w systemie, rozróżnienie między RTC, a czasem monotonicznym jest chociażby tutaj: https://stackoverflow.com/questions/3523442/difference-between-clock-realtime-and-clock-monotonic Właśnie dlatego że rozliczanie czasu pracy jest poważną sprawą, nie można użyć do tego zegara który ma przeskoki, albo się cofa bo wymaga korekty. Można użyć modułów RTC do zbudowania zegara monotonicznego - wystarczy taki moduł raz ustawić i już więcej nie przestawiać. Ale to nie będzie już moduł przechowujący czas rzeczywisty, ale jakiś bliżej nieokreślony "czas odniesienia". Natomiast chcąc znać aktualną godzinę będziemy musieli wskazania odpowiednio przeliczyć.

A możesz podać skąd pomysł że zegar RTC ma większą precyzję niż np. mikrokontroler? Bo o ile ja wiem jest dokładnie odwrotnie - tanie kwarce "zegarkowe" o częstotliwości 32kHz mają dużo niższą dokładność niż stosowane do taktowania MCU. No i chyba nie zrozumiałeś co to jest zegar monotoniczny - dokładność to oddzielna sprawa. Ale RTC z założenia można przestawiać, a czasem pojawiają się przeskoki lub cofnięcia czasu. I dlatego do odmierzania przedziałów czasu trzeba stosować coś innego - to coś może być oparte o RTC, ale sam RTC bez odpowiednich zabiegów się nie sprawdzi.

RTC nie nadaje się do zliczania czasu pracy z prostej przyczyny, nie jest monotoniczny. Pierwszy i najbardziej drastyczny przypadek to zmiana czasu - z jednej strony nikt nie chciałby za darmo pracować dłużej, z drugiej kierownictwo mogłoby nie być zachwycone płaceniem za dodatkową godzinę, której w rzeczywistości nie było. Ale nawet jeśli pominiemy zmiany czasu, problem wcale nie zniknie. Na ogół oczekujemy że RTC wskazuje aktualną godzinę. Niestety jeśli uruchomimy dowolny w miarę tani (czyli np. nie-atomowy) zegar i zostawimy na jakiś czas, okaże się że jego wskazania nie są już idealne. I wtedy pojawia się problem - jeśli skorygujemy wskazania zegara, to albo damy komuś w prezencie dodatkowe godziny, albo je zabierzemy. Z drugiej strony jeśli nie będziemy aktualizować wskazań zegara, to R w nazwie RTC niewiele będzie miało wspólnego z "Rzeczywistością". Dlatego np. w systemie Linux, ale pewnie i innych mamy jednocześnie wiele zegarów. Jeden z nich to tzw. zegar monotoniczny - odpowiada on millis() na arduino i czyli w sposób stały odmierza czas np. od uruchomienia systemu. Taki zegar bardzo dobrze nadaje się do odmierzania przedziałów czasu, bo niezależnie od zmian pór roku, czy korekty wskazań RTC jego odczyty zmieniają się jednostajnie, bez cofnięć, czy przeskoków.

@atMegaTona Może zamiast się mądrzyć i ironizować, po prostu zastanów się, czy znasz się na silnikach krokowych na tyle żeby doradzać i pomagać innym. Ja się na tyle nie znam, ale widzę kiedy porady daje ktoś, kto zna się jeszcze mniej ode mnie. Oczywiście każdy ma prawo pisać w internecie co tylko chce - ale chodzi o to żeby z tego prawa mądrze korzystać, a fora tematyczne chyba nie są od tego żeby pisać cokolwiek. Mój ogólny apel jest taki, żeby pomagać w tematach na których się znamy, a nie pisać żeby zbierać kolejne wpisy. Każdy z nas jest lepszy w pewnych dziedzinach, ale nie zna się na wszystkim. Jeśli podzielimy się tym co umiemy, wszyscy zyskamy. Natomiast pisząc na każdy pojawiający się temat wprowadzamy tylko szum i jeszcze dajemy złe rady zarówno pytającemu jak i wszystkim "cichym" czytelnikom forum.

Jak napisałem wcześniej - nie podejmuję się doradzić, który silnik i jak wybrać, ale przestrzegam przed podejmowaniem decyzji na podstawie każdego wpisu na forum w internecie. Niestety ale nie wszystkie porady są dobre. Więc chyba najlepiej samemu doczytać o sterowaniu silników krokowych.

Ostatnio jest taka moda, że najwięcej pomagają osoby które najmniej się na danym temacie znają - nie chcę się w ten trend wpisywać, więc wolałbym za dużo nie pisać, ale jak przeczytałem wcześniejsze wpisy to chciałem chociaż uprzedzić, że wybór oraz jego kryteria nie świadczą najlepiej o znajomości sterowania silnikami krokowymi. Ogólnie jest tak, że jeśli silnik krokowy jest sterowany wolno to prąd w uzwojeniach silnika ma czas narosnąć do maksymalnej wartości ograniczonej tylko rezystancją. Czyli w przypadku tego silnika JK42HS40 mamy R = 50 Ohm, przy zasilaniu 12V daje prąd I = 0,5 A, czyli maksymalny prąd tego silnika - a od prądu zależy moment. Do takiego sterowania wystarczy banalny sterownik, zwykły mostek H, a nawet tranzystor (jeśli sterowanie unipolarne). Problem pojawia się podczas przełączania, czyli wykonywania kroku. Cewki mają to do siebie że nie lubią zmian prądu. Czyli gdy podłączasz napięcie 12V do kolejnej cewki to nie popłynie od razu prąd 0,5A, tylko będzie powoli narastał - jak to w obwodzie RL. Stała czasowa o ile pamiętam t = L/R, czyli w tym silniku mamy L = 36mH, co daje t = 1,5 ms. Po upływie jednego t nadal nie będzie pełnego prądu (czyli 0,5A), ale jakieś 63%. A skoro chcesz kroki wykonywać co 0,5ms to sam sobie policz ile tego prądu popłynie przez uzwojenie. Sztuczka którą się stosuje to użycie wyższego napięcia. Jak wspomniałem np. 36V spaliłoby silnik - ale wprowadzając elektroniczne sterowanie (tzw. chopper) można tego uniknąć. Natomiast mając wyższe napięcie, również prąd szybciej narasta. I dzięki temu można uzyskać wyższą prędkość.

To obawiam się że możesz się mocno przeliczyć. Silnika 12V przy zasilaniu 11V nie ma szans na 2000 kroków na s. Ten na niższe napięcie ma, a na wyższe już nie bardzo. Problem z silnikami krokowymi polega na tym, że one nie lubią się kręcić. Całkiem dobrze im idzie stanie w miejscu, ewentualnie wykonywanie kroków od czasu do czasu. Natomiast ze wzrostem częstotliwości wykonywania kroków szybko tracą moment, a sposobem na przyspieszenie jest sterowanie prądowe ze znacznie wyższego niż nominalne napięcia. Więc jeśli kupisz ten 12V to może będzie ładnie działał przy 100 krokach na sekundę, ale później po prostu padnie.

Napięcie dla silnika krokowego jest akurat mało istotnym parametrem, a zasilanie silnika dla którego podano 12V z 11,1V jest.... odważne? Może zacznijmy od czegoś innego - jakich prędkości, albo raczej częstotliwości wykonywania kroków się spodziewasz? Edit: I jeszcze jedno odnośnie napięć - w typowym układzie sterowania silnik krokowy zasila się ze znacznie wyższego napięcia niż to podawane w dokumentacji. Więc dla 12V pewnie wskazane byłoby 36V, a dla tego "droższego" 12V już miałoby sens.

Jak się ktoś nie zna na protokołach sieciowych to może nie powinien dawać "dobrych" rad. ICMP nie służy do potwierdzania odebrania danych UDP. To że da się go tak używać jeszcze o niczym nie świadczy. Proponuję starać się dawać dobre rady, a nie złe - szczególnie początkującym użytkownikom. Ewentualnie zamilknąć i wrócić do nadrabiania braków w edukacji. Edit: żeby nie było, to co napisałem to nie złośliwość, ani zachowanie sprzeczne z PPF - to po prostu stwierdzenie faktu. ICMP należy do zupełnie innej warstwy (do doczytania) niż UDP, ma określone zastosowania (do doczytania). Tworzenie bezawaryjnego łącza z użyciem UDP jest możliwe, ale na ogół bezsensowne, bo duplikuje działanie TCP. A to że ktoś nie potrafi TCP używać to już zupełnie inny temat - i nie powód żeby wszystkim odradzać korzystania z tego protokołu (jak na ironię pisząc post używając przeglądarki oraz TCP...).

Proponowałbym przemyśleć sprawę zasilania - użycie powerbanku to niekoniecznie dobry pomysł. Większość wyłącza się jeśli nie jest obciążona, a niewielki pobór pradu samej elektroniki może być właśnie tak potraktowany.

Z tego co widzę w większości opisów dht11 przewija się zakres 0-50, więc to raczej prawda. Dla dht22 ciężko o dokumentację, ale faktycznie zakres wydaje się już lepiej dopasowany do oczekiwań Niestety w przypadku tanich układów i modułów "z dalekiego wschodu" ciężko jest o solidną dokumentację. Co więcej zdarzają się po prostu podróbki i w sumie nigdy nie wiadomo co dany model będzie miał nadrukowane, a co znajdziemy w środku.

@Wiktor2019 A czytałeś dokumentację tego czujnika, czy po prostu założyłeś że będzie działał bo powinien? Taka mała podpowiedź: Kolumna "Measurement Range" ...

@atMegaTona Nawet jak wywalisz bootloader to będzie wolno i pojawi się zaskakująco szeroka szpilka. Wbrew pozorom uruchomienie mikrokontrolera zajmuje sporo czasu, więc najlepiej sprzętowe problemy rozwiązywać sprzętowo. Jako ciekawostkę zachęcam do przetestowania / pomierzenia jaki jest czas od załączenia zasilania do wykonania pierwszej instrukcji kodu. Też kiedyś myślałem, że program działa natychmiast

A ja bym proponował wrócić do tego co napisał @marek1707 Po pierwsze kod szkicu nie jest uruchamiany jako pierwszy - najpierw musi się uruchomić bootloader. Po drugie samo uruchomienie mikrokontrolera zajmuje sporo czasu - więc nawet gdyby zrezygnować z bootloadera, a pierwszą instrukcją asemblera było ustawienie pinu to i tak na wyjściu pojawi się całkiem spory impuls. Na to może pomóc tylko sprzęt - być może tak prosty jak jeden rezystor, a może będzie potrzebny negator.

@RFM Wrzuć sobie na luz, myślisz że czas przygotowywania obrazu z cukierków ma jakiekolwiek znaczenie? Projekt przecież nie był tworzony jako profesjonalne narzędzie, które będzie wyświetlało obraz w 60 FPS. A pomysł wyświetlacza bardzo fajny, pięknie pokazuje że ludzka fantazja nie zna granic. No i jak zostanie trochę "tuszu" to można najeść się cukierków do woli

U mnie CubeIDE działa wolniej niż sam CubeMX, a jak chodzi o pracę z kodem to SW4 i Atollic też są sprawniejsze - ale nie licząc przygody z antywirusem CubeIDE da się używać, tylko wolniej. Atollic ma więcej plugin-ów niż SW4 i to jest pewien plus, szczególnie pod FreeRTOSa. CubeIDE na razie jest pod tym względem gorsze niż Atollic, ale lepsze niż SW4. Główna zaleta (o ile nie jedyna) CubeIDE to planowane wsparcie - wchodzenie w Atollica, który wydaje się kończyć życie jest trochę ryzykowne. No jeszcze zostaje OpenSTM32 / SW4, ale o nim od dawna są sygnały że ma kończyć wsprarcie - chociaż jak na ironię nowe układy, jak chociażby MP1 są właśnie przez SW4 wspierane. Co więcej przykłady do Cube są pod SW4, pod TrueStudio, a pod CubeIDE jeszcze nie ma. Więc pomijając moje problemy z antywirusem - może warto byłoby się podzielić przemyśleniami, które IDE warto wybrać dla STM32? @atMegaTona Udało Ci się uruchomić TouchGFX? Ja próbowałem, ale to jakiś koszmar - z tego co pamiętam kompilowało się tylko pod jeden model stm32, a nie działało mi na niczym. Miałem wrażenie, że po przejęciu firmy przez ST nastąpiła jakaś katastrofa i trzeba poczekać aż poskładają kod do kupy, bo chwilowo jest w rozsypce. Ale jeśli udało Ci się z GFX działać to super, może napisałbyś o tym kilka słów?

@FlyingDutch Dziękuję za pomoc. Przez to że zapytałeś o komputer, postanowiłem przetestować na innym i okazało się że wszystko pięknie działa. Przyczyną problemów okazał się antywirus... Nie wiem co robi CubeIDE, ale mój antywirus ewidentnie za tym nie przepada. Więc jakby ktoś chciał wypróbować CubeIDE i miał podobne problemy - warto spróbować wyłączyć antywirusa, u mnie to pomogło. Kompilacja cały czas działała bez problemu, jedynie CubeMX w CubeIDE ledwo chodziło. Co ciekawe CubeMX jako niezależna aplikacja działał szybko. W każdym razie problem chyba rozwiązany

Jak chodzi o komputer, to używam laptopa z i7-8750h, 16GB ram, dwa dyski - systemowy SSD i tradycyjny na dane. Też jest 6 rdzeni / 12 wątków, CubeIDE po zmianie dowolnej opcji zajmuje 100% jednego rdzenia. Na CubeMX wszystko działa całkiem sprawnie, a CubeIDE jak na załączonym filmiku.