Skocz do zawartości

Elvis

Użytkownicy
  • Zawartość

    2594
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    189

Posty napisane przez Elvis


  1. 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.


  2. 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ć.
     

    • Lubię! 1

  3. 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.


  4. 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.

    • Lubię! 1
    • Nie zgadzam się! 1

  5. 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.


  6. 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.


  7. 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.

    • Lubię! 1

  8. 1 godzinę temu, RFM napisał:

    potwierdzaj ramki przez ICMP

    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...).

    • Lubię! 1

  9. 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.

    • Lubię! 2

  10. @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 🙂

    • Lubię! 1

  11. 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.

    • Lubię! 1

  12. @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 😉

    • Lubię! 2

  13. 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?


  14. @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 🙂

    • Lubię! 1

  15. 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.

    • Lubię! 1

  16. Kilka miesięcy temu pojawił się temat z pytaniem o wrażenia związane z CubeIDE. Ponieważ trochę czasu minęło i pojawiło się kilka nowych wersji, postanowiłem temat odkopać.

    Powód jest w sumie prosty: OpenSTM32 ma już swoje latka, a ST ciągle zapowiada że z niego zrezygnuje.

    Z drugiej strony na stronie Atollic TrueStudio widzimy: "For new designs we recommend using STM32CubeIDE instead of Atollic TrueSTUDIO. There will be no new releases of TrueSTUDIO."

    atollic.thumb.png.78b526d5d9e864d9423506717ba84bab.png

    Wygląda więc na to że CubeIDE ma być głównym środowiskiem dla mikrokontrolerów STM32.

    Ja mam jednak z CubeIDE poważny problem - to działa tak wolno, że właściwie nie działa. O ile przy małym układzie i z niewieloma peryferiami można się do powolnego działania przyzwyczaić, ale zachciało mi się wybrać nieco większy układ, a dokładniej STM32L476ZGT6 (płytka https://www.st.com/en/evaluation-tools/stm32l476g-eval.html)

    CubeIDE z tym układem działa potwornie wolno, a po włączeniu FMC praktycznie przestaje. Mierzyłem czas stoperem i po każdej zmianie parametru jest równo minuta zawieszenia środowiska. Jeden z rdzeni procesora jest wtedy obciążony w 100% i nie można nic zrobić.

    Stąd moje pytanie: jakie są Wasze doświadczenia z CubeIDE? Używał już ktoś tego środowiska? Nie mieliście problemów z wydajnością?

    Edit: Po aktualizacji Javy jest trochę lepiej.. Teraz jest trochę ponad 30s zamiast minuty.

    I jeszcze dla porównania CubeMX 5.4.0 uruchomione jako niezależna aplikacja:

     

     

    • Lubię! 1

  17. @Pieterlpl Poczytaj trochę o pomiarze ciśnienia, a przy okazji wysokości. (np. https://stacje-pogody.pl/artykul_cisnienie_atmosferyczne_bezwzgledne_i_wzgledne_zredukowane_do_poziomu_morza_o_co_chodzi_z_tymi_cisnieniami,83.html ). Szybko odkryjesz, że to co wskazuje BME280 to niezupełnie to co chyba myślisz... W każdym razie prognoza pogody podaje tzw. ciśnienie względne (zredukowane do poziomu morza), a czujnik mierzy bezwzględne. Jeśli wiesz na jakiej wysokości jesteś możesz sobie to przeliczyć. Z drugiej strony wtedy zwracana wysokość (meters) nie ma sensu, bo w końcu przeliczając wiedziałeś już na jakiej wysokości jesteś.

    • Lubię! 1
    • Pomogłeś! 1
×
×
  • Utwórz nowe...