Zealota

Pozwolę się wtrącić bo odniosłem wrażenie, że spór idzie na różnych płaszczyznach, jakby jeden mówił o jabłkach a drugi o gruszkach, a Kolega Elvis to jakby zupełnie na innym "poziomie abstrakcji". - RTC się nie nadaje, bo zmiany czasu itp. przeszkadzają, bo wprowadzają "błędy"? Wszystkie z tych zaburzeń jest przewidywalne i korygowalne, na potrzeby zadania zliczania czasu - RTC można go zrobić na milis, kwarcu zegarkowym, DS3231, stabilizowanym temperaturowo generatorze i pewnie jeszcze innym. - rozmawiacie o projekcie zliczania czasu pracownika. Dokładność do minuty na dobę może nie jest wystarczająca? No to może do 10 s. Po co wprowadzać "aptekarstwo" w tej dziedzinie na poziomie s lub co gorsza milisekund. Może moje wyobrażenie co do zatrudnienia jest niedostateczne, ale stawiałbym, że wystarczy "co do minuty". Jeśli damy takie założenie to każdy z wybranych RTC się nada. Co do linuksa? Hmm można to rozwinąć? Tam jest jeden zegar RTC, taki z bateryjką na płycie głównej. Reszta "zegarów" "programowych" to chyba wynika tylko z przeliczania danych. Jeśli linuks nie ma dostępu do ntpdate to korzysta tylko z tego "co zapisane w bios" - tak przewrotnie pisząc, a mam na myśli to co podtrzymuje bateryjka. Jeśli weźmiemy arduino czy jakąś bibliotekę time.h z STM, to w każdej chwili mogę przeliczyć na czas (a właściwie stan licznika) względem 1 stycznia 1970, sam z tego korzystam używając np RTC w STM32F103, gdzie jest najprostszy z RTC w STM, właśnie taki monotoniczny, który tylko tyka, a resztę, łącznie z cofaniem czasu należy zrobić ręcznie, a zatem można go rozmyślnie kontrolować. Jak działa taki DS3231? Wg mnie tam w środku jest "monotoniczny zegar" zwany licznikiem, który ze sprawną bateryjką i bez ingerencji użytkownika tylko sobie "tyka" i pomyli się o jakie "sekundy" na rok. Jaki to może mieć wpływ na wyliczenia czasu roboczogodzin? Zatem wracając do początku "spór należy" rozstrzygnąć, bo jest INTRYGUJĄCY, dla takiego czytelnika Forbota jak ja

Może to będzie odpowiednie:

No właśnie nie chcę tu sobie na razie wyobrażać bardziej uniwersalnych, rozszerzonych przypadków, bo jeśli do nich by doszło to należałoby cały koncept zapisu przemyśleć i pewnie sposób z przecinkiem byłby bardziej na miejscu, a może jeszcze coś innego by należało użyć. Mnie chodzi tutaj cały czas o ten konkretny przykład jaki podał autor. Można się tylko domyślać, ale jednak wszystko na to wskazuje, że chodzi mu o rozdzielczość czasu na poziomie załóżmy sekund (mogą być również minuty), nie milisekund czy jeszcze mniej. Z tego powodu tak się upieram (pewnie jednak zbyt literalnie) na te części ułamkowe, które nie są ułamkowe. Zresztą samo f to nie wiadomo do czego, czemu tam *2 itd Tak czy siak wydaje mi się, że rozumiem tok Twojego rozumowania i raczej na pewno wnioski jakie powstały w wątku będą przydatne. Nie zamykam się całkowicie na formę zapisu z przecinkiem, być może kiedyś zajdzie potrzeba to "się użyje".

A tutaj: Hmm. Przecież jawne rzutowanie zmiennej typu int na float, nie zmienia tej zmiennej. Ona nadal jest typu int, a jedynie - jakby to powiedzieć - "kontener" na liczby się powiększa, żeby zaspokoić zmienną f i wynik jest zgodny z oczekiwaniem, tzn. z deklaracją zmiennej f, bez obcinania zakresu do int. Natomiast zmiana z 60 na 60.0 właśnie dokonuje tej zmiany na liczbie, co oczywiście poprawnie służy zadaniu, ale wprost liczbę całkowitą zamienia na float, niepotrzebnie zaburzając logiczną deklarację zakresów zmiennych, ale o tym już pisałem wyżej. Zatem moją intencją w powyższym zapisie było to, żeby właśnie rozszerzyć "ten kontener", a nie żeby "nadać cechy" zmiennej RPM. Oczywiście wyszła tu pewna niewiedza, bo przy okazji sprawdziłem z kompilatorem w ręce 3 zapisy dla avr-gcc bez optymalizacji. float f = RPM*2/60.0; // wariant jeden float f = (float)(RPM*2)/60; // wariant dwa float f = (float)RPM*2/60; // wariant 3 Okazuje się, że pomimo poprawnej wartości dla każdego z nich jednak niektóre dadzą więcej instrukcji , a niektóre mniej. No to zagadka. Które dają mniej, a które więcej? Bez kompilatora Przyznaję się bez bicia, że ja nie wiedziałem, ale orłem nie jestem. Podsumowując wątek moją główna intencją było to, że im bardziej wzór w kodzie przypomina ten wyliczony na kartce tym lepiej, a jawne rzutowanie jest w tym przypadku lepszym, czytelniejszym rozwiązaniem, bo zakresy liczb odpowiadają ich rzeczywistym zakresom. Jak widać to są pewne drobne niuanse, być może mało ważne w praktyce, ale raczej "rozkmina" na tym poziomie to istotna nauka programowania. Nie sądzicie?

Pisałem w kontekście matematyki ten cały "wywód" o liczbach. Żeby coś zrobić "w komputerze" najpierw należy rozwiązać problem "poza". Rozwiązaniem problemu był wzór f = (2*rpm)/60 - nie f=(2*rpm)/60.0. Zadaniem programisty/Autora było powiedzenie kompilatorowi co ma zrobić tzn: float f = (float)(2*RPM)/60; Powyższy wzór jest czytelniejszy niż dopisywanie "przecinków", przynajmniej dla mnie Gdzie to niby pisałem o zmiennej RPM? Ja pisałem o 60, a Ty o RPM. Tak sobie możemy gadać jeden o jabłkach, a drugi o gruszkach Pisałem o tym, że 60 to jest liczba całkowita i bez sensu jest zamienianie jej na float przez dopisywanie jakichś przecinków (60.0) i a problem można rozwiązać poprzez jawne rzutowanie co być może jest lepszym, czytelniejszym rozwiązaniem. W końcu to wynik f ma być float, a nie zmienne (RPM) i stałe (60) są całkowite.

Liczby całkowite to podzbiór liczb rzeczywistych. Niezależnie ile byś dopisał 0 po przecinku to i tak na koniec jest to liczba całkowita i zarazem rzeczywista. Dlatego nie można powiedzieć, że to TYLKO liczba rzeczywista. Chyba łatwo to udowodnić czy 60.0 = 60?. Oczywiście, że się równa zatem skoro 60 jest całkowita i rzeczywista to 60.0 też jest całkowita i rzeczywista. Nie ma potrzeby rozszerzania zbioru liczb jeśli mamy interesujący nas zakres. To tak jak branie typu int zamiast uint8_t do mnożenia 2 liczb z zakresu 1-5. Dlatego uważam, że zapis jest sztuczny, bo do prawidłowych obliczeń w języku C jest jawne rzutowanie. Jak widać z wątku, autor miał zamiar podzielić przez liczbę całkowitą 60 ( pewnie 60 minut stąd liczba całkowita). Dostał wynik niezgodny z oczekiwaniem zaczął kombinować, dopisał przecinek, a za miesiąc nie będzie pamiętał dlaczego. Wiem, że często ten zapis z przecinkami się stosuje, ale jak dla mnie to jakiś wytrych jasny głównie dla kompilatora, dlatego pisałem, że to jakieś sztuczne...

No to można jeszcze dorzucić: float f = (float)RPM * 2 / 60; Mamy tu klasyczną "promocję do int" dlatego przy obliczeniach należy jawnie rzutować na float. W mojej opinii zapis 60.0 jest wyjątkowo sztuczny. To jest liczba całkowita, więc powinna być zapisana najprościej czyli bez żadnych przecinków. Jawne rzutowanie jak pokazałem uczy dobrych nawyków programowani przy pisaniu w C.

W załącznikach nie ma żadnych plików źródłowych. W treści nie ma wypełnionej struktury dla timerów. W ten sposób nie da się nic wymyślić

Tutaj znajdziesz gotowca: Na wskazanym wyżej kanale znajdziesz jeszcze kilka rozwinięć tego pomysłu. Są również kody, brakuje może dokładnych opisów, ale powinieneś sobie poradzić.

X1 to prawdopodobnie rezonator. Czarny i srebrny spokojnie mogą być swoimi odpowiednikami. Nie doszukiwałbym się tutaj problemów, tzn, że Chińczyk pomylił taśmy. Prędzej kamera uległa uszkodzeniu z powodu elektrostatyki. Pewnie sprzętu ESD nie używałeś przy pracy (opaski uziemiające itp.) Powód uszkodzenia może być i tak zupełnie inny...

W końcu do IR potrzebny jest tylko 1 pin, jako wejście + odbiornik IR oraz timer, niekoniecznie specjalnie "szybki". Tak działa m.in IRMP, wystarczy 10 - 15 KHz, żeby obsłużyć większość standardów kodowania na rynku. Tak. Też lubię V-usb i często korzystam, ale na tym nie zrobisz VCOM - tylko HID i to dla USB1.1

Ta LUA dawno za mną chodzi, napisałby kto parę zdań na ten temat będzie łatwiej wystartować :s Wkradł się błąd, chodziło mi o LUFA Zrobiłem kiedyś podejście w Eclipse, udało mi się skompilować kod HID pod ATmega32U4 i działało wstępnie jako klawiatura. Mogę podrzucić gotowy projekt do Eclipse.

Zrobił się strasznie tajemniczy wątek: "wiem, ale nie powiem", "zapytaj Elvisa", itd... Nie wiadomo ile tam jest mikrokontrolerów, o co "czepia się" kolega RFN i po co pisze o przejściówce USB-UART za 5 zł. Co do mikrokontrolerów wydaje mi się, że tam są dwa: jeden jako USB-UART, drugi to Arduino do dekodowania kodów IR i być może to było kością "niezgody" , Zatem przecież da się to zrobić na jednym mikrokontrolerze - na AVR z LUA i sprzętowym USB i trybie Vcom, a najlepiej lepiej to wykonać na prostym STM32 - choćby na BluePill. Wątpliwości Elvisa mnie mocno dziwią, przecież sam pisze sterowniki USB do uK. Co do konceptu sprzętowego to sam korzystam z podobnego - płyta na Celeronie j1800, LibreELEC a do tego KODI - w sumie w takim rozwiązaniu też jest IPLA jako dodatek. Coś innego mnie intryguje, wszędzie w materiałach Autor pisze coś o Zotac ZBOX B1324, wydaje mi się, że takiego to nie ma, jest ZBOX BI324 - ot literówka "I - 1", ale chyba warto to poprawić. Sam sprzęt to golas i faktycznie nie ma tam żadnych "starych" interfejsów, zatem trzeba oprzeć się na USB - ale bez przekory to naprawdę uniwersalny "serial bus".

Żeby dowiedzieć się co zrobić to warto zajrzećna ten kanał: https://www.youtube.com/channel/UCFo2uTuDWU-klP58hE34iLg Jest tam m.in. to: Kolega cbm80amiga robi kawał dobrej roboty i to na arduino (komentarz dla malkontentów )

Wszystko zależy jaki multimetr i jaki interfejs. Polecam przeglądnąć film: Oprócz tego polecam kanał tego autora. Ma tam mnóstwo bardzo pożytecznych projektów.