Dlaczego chipy zegara czasu rzeczywistego korzystają z BCD

14

Widziałem dziesiątki różnych układów zegara czasu rzeczywistego na rynku, a także kilka procesorów z wbudowanym oddzielnie zasilanym modułem zegara czasu rzeczywistego.

Prawie wszystkie z nich nie tylko przechowują czas jako rok-miesiąc-dzień-godziny-minuty-sekundy, ale nawet poszczególne pola są przechowywane w formacie BCD, a nie w formacie binarnym.

Czy jest jakiś podstawowy tego powód?

Czy są jakieś aplikacje mikroprocesorowe, które robią coś bardziej zaawansowanego niż tylko wyświetlanie zegara, w którym format BCD jest bardziej przydatny niż binarny, lub w którym rok-miesiąc-dzień-godzina-minuty-sekundy byłby bardziej użyteczny niż prosta 47-bitowa liczba zmian stanu oscylatora?

Z tego, co mogę powiedzieć, wydaje się, że twórcy RTCC dodają wiele dodatkowych obwodów, aby ich układy były mniej użyteczne; jedynym powodem, dla którego mogę wymyślić, że moduły RTCC w procesorach zachowują się w ten sposób, jest to, że dostawcy procesorów używają wcześniej istniejących implementacji BCD, a nie produkują własne.

supercat
źródło
2
Nie znam odpowiedzi, ale zastanawiam się, czy istnieje jakaś korelacja między BCD a dekoderem 7-segmentowym ?
Prof. Meow Meow
@Prof. Meow Meow: Ładne imię. Najbardziej praktyczną metodą przechowywania liczb, które będą wyświetlane sprzętowo, jest BCD. Istnieją systemy przechowujące liczby do wyświetlenia w innych formatach, ale w wielu przypadkach po prostu wykorzystały ROM do mapowania bezpośrednio od numeru do jego wizualnej reprezentacji (np. Automat do gier „Tank” używał 6-bitowych liczników wyników i 512 bajt ROM, aby przekonwertować każdą wartość punktową na kształt 8x8), ale na ogół było to wykonalne tylko wtedy, gdy maksymalna wartość liczbowa była dość mała.
supercat

Odpowiedzi:

12

Czy wszystkie RTC używają kodowania BCD?

RTC z Philips / NXP (zarówno samodzielne, jak i zintegrowane z układami ARM7 lub Cortex-M3) nie używają kodowania BCD.

Co jest nie tak z BCD RTC?

W porównaniu do licznika płaskiego jedynymi operacjami, które są trudniejsze przy podzielonym zegarze BCD, są obliczenia różnicy czasu (dodanie sekund lub obliczenie upływającego czasu). Porównania czasu, takie jak: „bieżący czas jest większy niż czas alarmu ustawiony przez użytkownika” są równie łatwe.

Co jest fajnego w RTC BCD (i ogólnie podzielonym polu)?

Podział pól jest naprawdę fajny, gdy zależy Ci na dacie kalendarzowej. Ludzkie kalendarze mają zabawne rzeczy, takie jak miesiące o różnej długości, a ponadto lata przestępne. Postaraj się to zrobić w jednym liczniku (możesz uzyskać punkt bonusowy za prawie zerowe zużycie energii). Aha i spróbuj w ten sposób wspierać dni tygodnia (całkiem przydatne we wszelkiego rodzaju urządzeniach przeznaczonych dla ludzi: od budzików po sterowniki grzejników).

Podejście BCD ma jedną dodatkową cechę: dostajesz przerwania „co sekundę” lub „co dziesięć sekund” za darmo, bez konieczności wykonywania żadnych obliczeń dotyczących dat i godzin.

Do obliczenia rekordowego roku przestępnego w NXP RTC jest trochę mało, ponieważ dba tylko o zasadę podzielności przez 4 i nie sprawdza podziału przez 100 i 400. Jeśli utrzyma licznik lat w BCD, byłoby to trywialne i najprawdopodobniej zrobione dobrze.

streszczenie

  1. Jeśli chcesz zegar monotoniczny, użyj go. Możesz kupić PIC lub AVR z „licznikiem RTC” (który jest tylko licznikiem asynchronicznym z autonomicznym oscylatorem 32kHz). Pamiętaj, że samo wyświetlenie daty będzie trudne. :)

  2. Jeśli chcesz wyświetlić godzinę i datę oraz ustawić alarmy na podstawie danych wprowadzonych przez użytkownika w czasie i dacie, użyj RTC. I pamiętaj, że gdy użytkownik zmieni bieżącą godzinę i datę, Twoje przerwania oparte na RTC mogą być niedokładne.

jpc
źródło
1
Właśnie zacząłem używać Gekko, który ma 24-bitowy RTC, to prawie to, czego chcę, poza tym, że nie może utrzymać czasu, gdy procesor jest martwy. Patrzyłem również na ST Micro ARM, który ma głupi moduł BCD RTC, który obsługuje przerwania tylko na sekundę. Gdyby układ ST nigdy nie byłby pozbawiony mocy przez ponad trzy lata, mógłbym zatrzasnąć preskalary RTC, aby działać z prędkością 32x, a następnie użyć sztuczek programowych, aby to zrekompensować, uzyskując w ten sposób rozdzielczość czasową 1/32 s na zdarzeniach budzenia, ale czasy przechowywane w RTC nie miałyby żadnego znaczącego związku z czasem kalendarzowym i ...
supercat
1
... więc konieczność konwersji z głupiego formatu RTC na przyrosty 1/32 sekundy byłaby irytująca, zwłaszcza, że ​​taka konwersja byłaby wymagana w każdym cyklu uśpienia / budzenia. Chyba jestem ciekawy, ilu ludzi używa odczytów RTCC bez konwersji na zunifikowane sekundy. Być może wystarczy, aby format YMDHMS był opłacalny, ale moim zdaniem znacznie bardziej przydatne jest rezerwowanie YMDHMS dla ludzkich operacji we / wy i używanie prostych sekund (lub jakiejkolwiek ich części) na wszystko inne.
supercat
1
@jpc: Moją skłonnością byłoby nigdy nie ustawiać czasu układu RTC, ale zamiast tego zachować „czas od zainstalowania baterii zegara” i zachować różnicę między tym a czasem naściennym. Zastosowałem to podejście w jednej generacji produktu, który używał osobnego PIC do utrzymywania czasu podtrzymania bateryjnego (czas na tym PIC był tylko do odczytu) i używałbym go na chipie z prostym licznikiem. Wydawało się jednak, że to trochę głupi pomysł, aby RTC urządzenia zapisywało bez znaczenia datę sformatowaną, chociaż jeśli użyję układu ST Micro, mógłbym to zrobić.
supercat
1
BTW, seria STM32F100 wykorzystuje 32-bitowe sekundy RTC (nie BCD), ale seria STM32F400 regresuje z powrotem do RTC zakodowanego w BCD. Westchnienie.
Mark Lakata
1
@FedericoRusso: Rozdzielenie pola miałoby jakiś sens, choć bardziej jest przeszkodą niż pomocą w większości aplikacji. Wybór BCD wydaje się wręcz dziwaczny jako wybór w pakiecie z procesorem , który nie obsługuje BCD .
supercat
3

Gdy korzystasz z zegarów, bardziej prawdopodobne jest, że będziesz zainteresowany minutami i dziesiątkami sekund (w kierunku ich wyświetlenia) niż tylko sumą sekund, minut i tak dalej. W przypadku, gdy nie jesteś zainteresowany oddzielnymi cyframi, istnieje szansa, że ​​nie przejmujesz się oddzielnymi wartościami minut lub sekund, i że równie dobrze możesz użyć długiego licznika binarnego, jak sugerowałeś.
Łatwiej jest konwertować z BCD na binarne w oprogramowaniu niż na odwrót. A ponieważ liczniki BCD nie wymagają tak dużej dodatkowej nieruchomości w porównaniu z licznikami binarnymi, warto wybrać BCD.

stevenvh
źródło
2
Jak często aplikacja nie chce nic robić z datą i godziną inną niż wyświetlanie? Wydaje mi się, że o wiele bardziej powszechne jest wykonywanie takich czynności, jak obliczanie pewnego dystansu w przyszłości lub określanie czasu, jaki upłynął od jakiegoś konkretnego zdarzenia itp. Co jest łatwiejsze do obliczenia: data i czas 45 sekund po 28 lutego 2000 r. 23:59:52 lub 5097582 + 45 (ta ostatnia wartość zakłada, że ​​epoka będzie miała miejsce 01 stycznia 2000 r.)? Jak o ustalenie, czy 5 minut przerwy między 28-lut-2000 23:59 i 01-Mar-2000 00:03 (VS 5097540.0 i 5184180.0)
Supercat
1
RTC z 48-bitowym licznikiem dla 65 536 tysięcznych sekundy i modułem porównywania alarmów, który zakrywał mniej więcej 24 bity, byłby niezwykle przydatny w systemach małej mocy, ponieważ mógłby być wykorzystywany jako podstawa do planowania systemu operacyjnego niezależnie od procesor budzi się i śpi. Jeśli coś ma się wydarzyć za 4 sekundy, system może zanotować wartość RTC, kiedy zdarzenie powinno nastąpić. Jeśli za 2 sekundy procesor nie będzie miał nic do roboty, może ustawić alarm RTC i przejść do trybu uśpienia. Kiedy zdarzenie powinno nastąpić, system się budzi.
supercat,
@ superupat - na komputerach ogólnego przeznaczenia pozwól systemowi zarządzającemu śledzić czas i rób „przydatne rzeczy” z tymi informacjami o czasie. RTC jest konsultowany tylko raz, aby zainicjować informacje o czasie systemu operacyjnego, a następnie czas jest aktualizowany przez przerwania. Ale w przypadku wielu prostych zastosowań osadzonych jest o wiele bardziej prawdopodobne, że
Toybuilder
1
@Toybuilder: To drugie podejście jest dokładnie takie, jakie zastosowałem w kilku ostatnich generacjach zamka elektronicznego. Moimi największymi irytacjami był brak możliwości wyboru wyjścia impulsowego między 32 kHz a 16 Hz (ponieważ nie ufałem podciągnięciu 1M do niezawodnego działania z wyjściem otwartym kolektorem 32 kHz, jedynym rozsądnym wyborem było 16 Hz), a także niechlujność PIC zespół obwodów czasowych.
supercat
1
@FedericoRusso: Gdyby ktoś miał prosty binarny licznik czasu, nie musiałby wracać do godzin, minut i sekund, z wyjątkiem być może wyświetlacza czytelnego dla człowieka. Po prostu dodaje się 3723 i to wszystko. Podczas pracy z wartościami daty / godziny YMD-HMS potrzebny jest osobny kod do zwiększania i zmniejszania, czas letni jest koszmarem, dla którego twórcy układów wydają się lubić dodawać zepsute wsparcie [jak polecenie, które odejmuje jeden od liczby godzin, z wyjątkiem sytuacji, gdy jest zero, w którym to przypadku nic nie robi]. DST to także binarny problem, ale nie aż tak straszny.
supercat
3

Podejrzewam kilka powodów:

Historyczne - robią to już od pewnego czasu. Jeśli chcesz, aby nowa część zastąpiła jakąś inną część, musi ona mniej więcej działać tak samo. Więc trzymaj się BCD.

Aplikacja - jeśli ktoś używa RTC z małej mikro (coś w zakresie 8 bitów, jak niskiej jakości PIC), to radzenie sobie z dużą liczbą (np. 47-bitowy licznik) jest dużym bólem szyi. O wiele łatwiej jest radzić sobie z cyframi BCD, ponieważ nie musisz pracować nad rozkładaniem.

Nie takie trudne - Robienie liczników BCD nie jest takie trudne, i myślę, że w rzeczywistości nie jest to dużo więcej bram niż robienie ich binarnie.

Można sobie wyobrazić system, w którym otrzymasz oddzielne liczniki godzin, minut itp. W postaci binarnej zamiast BCD (unikając w ten sposób problemu „zerwania 47-bitowej liczby”), ale nie jest to o wiele łatwiejsze i masz zamiar zrobić trochę i tak konwersje podczas wyświetlania rzeczy.

Michael Kohne
źródło
1
48-bitowa liczba będzie 32-bitową liczbą sekund i ułamkiem 16-bitowym. Praca z 32-bitowymi liczbami na 8-bitowej mikro nie jest taka zła. Mogę sobie wyobrazić, że na czymś takim jak 6502, który ładnie poradziłby sobie z zapakowanym BCD, format BCD może w niektórych przypadkach zaoszczędzić kilka bajtów, chociaż dodatkowa złożoność obsługi przenoszenia między sekundami-godzinami minutami zrównoważyłaby jakąkolwiek przewagę. Ale z pewnością ludzie, którzy wbudowali RTCC w układy ARM ST micro, nie spodziewali się, że ktoś użyje 6502 do przetwarzania danych - nie z siedzącym tutaj 32-bitowym ARM!
supercat
1
@ superuper - choć nie jest to trudne, wykonywanie 32-bitowej pracy na 8-bitowej mikroprocesorze jest nadal uciążliwe w <bleep>. A na czymś takim jak PIC (z BARDZO ograniczoną instrukcją, rejestracją i ramkami) jest to jeszcze bardziej bolesne. Jeśli chodzi o układ ARM - założę się, że ma on więcej wspólnego z historycznym precedensem niż czymkolwiek innym - wszyscy są przyzwyczajeni do robienia tego w ten sposób, więc nadal tak robią.
Michael Kohne,
1
Zastanawiam się, jaka część ludzi korzystających z urządzeń peryferyjnych RTCC nie konwertuje dat / godzin na liczniki sekund w stylu uniksowym?
supercat
1
supercat: Wszystkie? Jakiego wykorzystania są sygnatury czasowe w stylu uniksowym w zegarze? OTOH twoim jedynym przypadkiem użycia są alarmy RTOS, które są lepiej obsługiwane z normalnym timerem lub z prostym przerwaniem „drugiego przyrostu” z RTC.
JPC
1
@jpc: Co zrobić, jeśli chcesz ustalić, czy dana data jest w czasie letnim, lub ustalić, czy program, który rozpoczyna się w określoną datę / godzinę i trwa określoną długość, będzie nakładał się na inną? Takie rzeczy są łatwe z prostymi sekundami, ale trudniejsze z YMDHMS. Jeśli chodzi o używanie normalnego timera, obecnie używam tika 1/16 sekundy z układu RTC napędzającego TMR1 i TMR3 na PIC; daje mi to budzenie z dokładnością do 1/16 sekundy, które działa nawet wtedy, gdy główny zegar procesora jest zatrzymany, i czerpię z tego cały czas.
supercat
1

Zgadzam się z Michaelem Kohne, że jest dużo historycznego rozmachu.

Wczesne MCU również miały znacznie mniej miejsca na kod i dane (na przykład 128 bajtów RAM). Ponieważ informacje o czasie są często wykorzystywane do celów komunikacji międzyludzkiej, bardziej sensowne jest utrzymywanie danych jak najbliżej formatu używanego do wyświetlania / wprowadzania danych przez ludzi.

Niektóre nowsze MCU z większą ilością kodu i przestrzeni danych czasami implementują sprzętowe liczniki czasu rzeczywistego - urządzenia te często przechowują binarne liczby tików 32kHz.

Producent zabawek
źródło
Kodowałem dla Atari 2600 (128 bajtów RAM) i znam zalety BCD. Rzeczy takie jak wyniki są prawie zawsze obliczane w BCD; numery poziomów czasami są. Jednak nawet w 6502 spodziewałbym się, że gdybym musiał ustalić, czy dwie daty / godziny były w odległości pięciu minut od siebie i ustalić, czy obowiązuje czas letni, kod do konwersji licznika 32-bitowego na YMDHMS być tak zwartym jak kod, aby wykonywać te obliczenia bez wykonywania takich konwersji. Jak dla nowszych procesorów, widziałem niektóre z prostych liczników 32kHz, które wymagają główny procesor, że żyje ...
Supercat
... ale zauważone przeze mnie układy, które mają oddzielnie zasilany RTCC, używają BCD YMDHMS.
supercat
Nowsze procesory to robią, ponieważ jest tańsze i zużywa nieco mniej prądu (szczególnie ważne, ponieważ zastosowany proces półprzewodnikowy jest zoptymalizowany do wytwarzania procesorów, a nie RTC).
JPC
@jpc: Dlaczego korzystanie z BCD YMDHMS jest tańsze i mniej kosztowne? Sądzę, że 47-bitowy licznik tylko do odczytu z komparatorem na dolnych 32 bitach byłby prostszy niż wszystkie elementy analizujące datę w układzie RTC. O ile nie ma jakiegoś filmu mistrzowskiego z obwodu daty BCD, który z powodu tajemnej, dawno zapomnianej magii, może zostać przekształcony w projekt w celu osiągnięcia niższych prądów niż są dostępne przy użyciu nowoczesnych metod, nie jestem pewien, dlaczego BCD byłby tańszy lub używał mniej prądu?
supercat
Myślałem o odpowiedzi @Toybuilders, w której stwierdził, że nowsze procesory mają tylko liczniki, a nie pełne RPC.
JPC
1

Jeśli ktoś jest zainteresowany, po prostu patrzę na serię 32F ST i wydaje się, że podczas gdy nowsza seria 32L wykorzystuje BCD RTC, 32F używa prostego licznika 32-bitowego z konfigurowalnym preskalarem i zapewnia osobne wejście baterii dla niego (brawo! ). Wolałbym mieć dłuższy prosty licznik bez konfigurowalnego prekalarnego (więc mogłem uzyskać dokładność 1/256 s, ale zachować czas na lata bez martwienia się o zawijanie), ale gdybym ustawił skalę wstępną na 1/64 s, czasomierz mógłby działać dwa lata bez przelewania się. Nie idealny, ale nie tak źle. Trochę nieestetyczne, że jeśli ktoś włącza maszynę po zbyt długim wyłączeniu (2,1+ lat), data / godzina nieuchronnie cofną się o 2,1 roku, ale nie jest to poważny problem (licznik ma flagę przelewu, ale w wiele przypadków, które nie byłyby strasznie pomocne. Jeśli urządzenie było włączone przez dwa lata przed wyłączeniem, a zostało włączone trzy miesiące później, można oczekiwać, że zegar się przepełni; pytanie brzmiałoby, czy przepełniło się dwukrotnie, i nie znam na to żadnej flagi.

supercat
źródło
0

Wydaje się, że Maxim robi dokładnie to, co chcesz z DS1372U . Potrzebuje mniej niż 1μA, kosztuje 1,7 USD i jest dostępny (!) Na DigiKey i Mouser. Jedynym problemem jest to, że nie wydaje się oferować alarmów z dokładnością przekraczającą 1 sekundę, a najniższa częstotliwość taktowania wyjściowego wynosi $ \ ok. 4kHz.

jpc
źródło
1
Jest to trochę drogie i nie pozwala w żaden sposób odczytać przyrostów mniejszych niż sekunda. Wyjście 4096Hz byłoby fajne, choć byłoby znacznie ładniej, gdyby było niskie dla 1/65536 sekundy i wysokie dla 15/65536. Wyjścia typu otwarty kolektor powinny być jak najmniejsze.
supercat