Witam!
Od paru dni próbuje znaleźć jakieś rozsądne rozwiązanie zapisu czasu(godziny ) Jako jedna liczbę dwubajtowa.
Godziny i minuty to żaden problem, bo wystarczy godziny * 60 +minuty, ale ja mam jeszcze sekundy. I poległem na tym. Mozna policzyć która to sekunda dnia ale to juz wyjdzie po za dwa bajty. Może ktoś przerabiał juz temat i podpowie cos.

nie ma sposobu, (nie znam).
wypada zwiększyć liczbę na więcej bitową lub łączyć bajty. Same sekundy(60) to 6 bitów, minuty to kolejne 6, godziny zmieścisz w kolejnych 5, to już 17-bit. a gdzie jeszcze dni...

Do liczenia minut i godzin zapewne wykorzystujesz jakiś timer, który i tak drobi ten czas, więc wykorzystaj ten fakt i "ukradnij" z niego sekundy Przeliczenie tego to prosta matematyka.

_________________
http://www.sylwekkuna.com

Powinieneś zainteresować się pojęciem "timestamp".
Kłopot polega na tym, że potrzeba do tego 4 bajtów (32bit) i wtedy kodujesz nie tylko minuty czy godziny, ale również datę od 1 styczna 1970. Nie pamiętam czy w toolchainie do AVR są odpowiednie funkcje, ale do takich STM32 jest dostarczana biblioteka <time.h>, gdzie można znaleźć struktury i funkcje do konwersji z i do formatu timestamp.
Jeśli zdefiniujemy i zainicjujemy sobie sobie jakąś liczbę 32 bit:

to będzie ona oznaczać datę i godzinę 1 stycznia 1970, 00:00:00. Każde zwiększenie jej wartości o 1, to przypływ czasu o 1 s. Zatem 1 stycznia 2019 roku, o godzinie 00:00:00 odpowiada timeStamp = 1546300800.
Można korzystać tez z konwertera online:
https://www.unixtimestamp.com/index.php

Ja korzystam z tego np do wszelkiej maści zegarków.
Nie wiem jak jesteś zaawansowany, ale może pomoże Ci taki przykład kodu:

Na apce w telefonie ustawiam sobie czasy włączenia i wyłączenia i wysyłam to do atmegi ta musi to zapisac do eeprom i później już proste porównuje ten czas ustawiony z aktualnym i ustawiam flagę 1 lub 0
Bardzo ładnie to działa gdy sie przeliczy to na sekundy ale to sa 4 bajty. A wszystkiego razem mam na razie 130 zmiennych do zapisu. Jak nie znajdę lepszego sposobu to dam większy procek żeby wystarczyło eeproma.
O kurcze zealota do rana tego nie rozkoduje . To dla mnie magiczny jezyk
Ale napotkałem sie na "timestamp" jak szukałem w necie rozwiązań ,ale w sumie w miam przypadku to to samo co przeliczenie na sekundy.
Co do BCD to nie pomyślałem o tym zaraz pomyśle nad tym

Ależ Kolega się myli Też mi się wydaje zwykle, że to jakieś magiczne sprawy, ale jak człowiek, szczególnie ten zdesperowany, przysiądzie i poświęci czas to załapie, szkoda, że zwykle tego czasu nie ma

jak by nie było, to masz 86400 kombinacji dziennie do zapisu w najbardziej oszczędnym sposobie zapisu.
sek*min*godz. to przekracza pamięć 2 bajtów.
!! a może wystarczą dziesiątki sekund, a jednostki że tak napiszę _ ' z marszu zerować zawsze'.
wtedy ilość zajętości bitów wystarczy uint16_t lub 2x uint8_t. (dwa bajty), ?
taka myśl.

No z BDC wyjdą 3 byte jeśli dobrze to ogarniam. Niestety musza byc "cale " sekundy policzylem sobie jak zajme 4 byte na jeden "czas" to wychodzi trochę ponad 500 byte w eeprom plus coś jeszcze to w mega 324 powinienem sie zmieścić ona chyba ma 1Kb.
No cóż zostawię przeliczanie na sekundy i będę zapisywał jako LONG. To chyba najbardziej pewny sposób do porównywania później.

Zakładając, że wystarczy dobowy zakres zmiennych (86400 sekund), na zapisanie jednej zmiennej potrzebnych jest 17 bitów.
Gdyby te dane nieco ścisnąć, na zapisanie 130 zmiennych potrzebnych by było:
( 130 * 17 ) / 8 = 276,25 bajtów (czyli należy przyjąć 277)

Oczywiście procedury odczytu/zapisu takich skompresowanych danych byłyby nieco bardziej skomplikowane i ich wykonanie trwałoby na pewno nieco dłużej, niż w przypadku zwykłych zmiennych czterobajtowych.

Nie wiem, czy można i w jaki sposób napisać to w Bascomie, ale w C lub ASM jest to na pewno możliwe.

Nie wiem jednak, czy gra jest warta świeczki (czyli wysiłek wart zysku), bo różnica w cenie mikrokontrolera o odpowiedniej pojemności EEPROM nie będzie raczej porażająco duża (chyba, że chodzi o produkcję wielkoseryjną).

Witam
Do zapisu 12h wystarczy 43200 (A8C0). Od godziny 12 dodawaj jakąś wartość np. 0x1000. Jeśli liczba większa od A8C0 + Twoja stała, odejmujesz stałą i masz czas
Pozdrawiam

A sprawdzę sobie. Wypadało,by tez żeby ta liczba obliczona byla caly czas większa,bo wtedy można zastosować przy porównaniu >= i przy starcie systemu od razu procek wie jak ustawić przekaźnik. W przeciwnym wypadku można zapisać po prostu trzy zmienne byte z H,M,S i po prostu porównywać. D

Może coś z tego wyjdzie. To nie jest produkcja seryjna ,a parę sztuk ,bardziej o to chodzi,ze niby takie proste,a ciężko na to wpaść .
Dzięki za podpowiedzi . Szukałem sporo w necie i nie było ani jednego tematu na ten temat ,az dziw ze nikt tego nie potrzebował, albo nie miał z tym problemu

Niestety to sie nie sprawdzi ,bo jak zacznie liczyć po południu od nowa od 1 to dodanie stałej nic nie da ,bo wcześniej czy później i tak sie spotka z wcześniejszym zapisem chyba ze stała byłaby większa niz 43200. Jedak można zapisać sobie jakaś zmienna dodatkowa i w niej ustawiać jeden bit żeby zaznaczyć rano czy popołudniu. Przy takim podejściu można zaoszczędzić,bo zliczamy tylko do 12:00 prawie polowe eeproma i w miarę prosty zapis, odczyt.

Witam


Nie pracuj z tym formatem, jego używaj tylko do zapisu w pamięci eeprom. Napisz funkcję która przy zapisie danych robi odpowiednią konwersje godziny do tak "spakowanego" zapisu i tak samo do odczytu.
Pozdrawiam

Niestety prawa arytmetyki binarnej są nieubłagane. W celu uzyskania 84600 unikalnych kombinacji bitów trzeba użyć minimum 17 bitów i żadne sztuczki tu nie pomogą. Jako że mikrokontroler i jego pamięci wewnętrzne operują ośmiobitowymi bajtami, trzeba użyć minimum 3 bajty, czyli 24 bity, tracąc po 7 bitów (prawie 30%) na jedną zmienną. Jednym ze sposobów na zaoszczędzenie miejsca w pamięci jest wykorzystanie niewykorzystanych bitów jednej zmiennej do zapamiętania fragmentu kolejnej zmiennej. Oczywiście jest to wykonalne, ale nieco komplikuje kod związany z zapisem i odczytem (jego napisanie i przetestowanie wymaga więcej czasu, a dodatkowo zwiększa ryzyko wystąpienia błędów) oraz wydłuża czas dostępu do takich zmiennych (przed zapisem jak i po odczycie danych z pamięci bity trzeba odpowiednio wypozycjonować). Nie wiem, czy przy obecnych cenach mikrokontrolerów warto się z tym bawić (zamiast użyć uc z odpowiednią pojemnością pamięci). Trzeba by było to sobie dokładnie przekalkulować biorąc pod uwagę wszystkie plusy i minusy, uwzględniając oczywiście rozmiar serii, bo nawet mały zysk jednostkowy przy dużej ilości może okazać się opłacalny.


To też jest jakieś wyjście, zakładając że w tej dodatkowej zmiennej będziesz miał spakowane bity AM/PM z kilku zmiennych, jednak podobnie jak napisałem wyżej, skomplikuje to nieco kod zapisu/odczytu, bo będziesz musiał odczytać/zapisać najpierw 12-godzinną zmienną, po czym znaleźć i odczytać/zapisać odpowiedni bit z odpowiedniego bajtu zawierającego bity określające AM/PM. Czyli również oszczędność pojemności kosztem komplikacji kodu i czasu dostępu do zmiennych, choć może dla Ciebie to rozwiązanie będzie czytelniejsze.


... nadal jednak korzystasz tylko z 17 bitów (5 bitów godziny, 6 bitów minuty i 6 bitów sekundy) zużywając 24 bity w pamięci, chociaż przy okazji upraszcza to zapis i odczyt. Chyba najprostsze byłoby użycie 32-bitowego typu podstawowego (w 8bit AVR jest to typ long), jednak tu marnotrawstwo pamięci wyniesie ok. 47%.

Podsumowując moim zdaniem najbardziej optymalnie będzie jednak zapisywać to za pomocą trzech bajtów: godziny minuty i sekundy, a w razie potrzeby zmienić mikrokontroler na taki z większą pojemnością EEPROM (maksymalna dostępna w 8bit AVR to chyba 4096 bajtów, czyli 1024 zmiennych long).

"To też jest jakieś wyjście, zakładając że w tej dodatkowej zmiennej będziesz miał spakowane bity AM/PM z kilku zmiennych, jednak podobnie jak napisałem wyżej, skomplikuje to nieco kod zapisu/odczytu, bo będziesz musiał odczytać/zapisać najpierw 12-godzinną zmienną, po czym znaleźć i odczytać/zapisać odpowiedni bit z odpowiedniego bajtu zawierającego bity określające AM/PM. "
Tak myślałem o wykorzystaniu wszystkich bitow w bajcie wtedy nie marnuje sie miejsca. W bascom zapis i odczyt konkretnego bitu jest bardzo prosty, zresztą jak wszystko inne
Policzyłem sobie wszystko ,flag_bit poupychałem sobie w Byte i wystarczy mi miejsca na zapis Long , zrobiłem to w najprostszy sposób czyli mnożne to sobie żeby uzyskać czas w sekundach. Zmieszczę sie w 1KB eeprom.

jeżeli zrezygnujesz z nieparzystych sekund, to zmieścisz się w 2x8bit.
fakt że dokładność spadnie przy zapisie 0/-1sek. :/ srednio -0,5s.