Czy zegar czasu rzeczywistego (RTC) jest niezbędny w systemach czasu rzeczywistego? [Zamknięte]

Zakładając, że pracujemy nad systemem Linux w czasie rzeczywistym i sprzętem, który składa się z timerów o wysokiej rozdzielczości, czy posiadanie RTC wpływa na aktualność systemu w czasie rzeczywistym?

Tutaj napisano, że zmniejsza zużycie procesora i pamięci, ale czy istnieje sposób, aby jakoś porównać różnicę?

Artykuł, który podłączyłeś, jest kompletny i kompletny nonsens. „Czas rzeczywisty” w „zegarze czasu rzeczywistego” (ponieważ jest używany w odniesieniu do rodzaju trudnego urządzenia opisanego w artykule) i „czas rzeczywisty” w „systemach czasu rzeczywistego” są zupełnie innymi terminami. Ten pierwszy oznacza przechowywanie bieżącego czasu kalendarzowego (zwykle jego bardzo słabe przybliżenie, w przeciwieństwie do wysokiej precyzji, jak twierdził artykuł powiązany) i przyspieszanie go bez zewnętrznego zasilania, przy użyciu baterii o długiej żywotności przycisku / monety. Ten ostatni oznacza reagowanie na zdarzenia z twardymi granicami opóźnienia od momentu zdarzenia do czasu odpowiedzi.

Kilka innych fragmentów tego artykułu, aby ustalić, że należy go uznać za niewiarygodnego:

Prawie nieistotne. Z rzędu 1 sekundy na 100 lat

1 sekunda na 100 lat to w przybliżeniu 317 ppt (tak, to części na bilion ). Tego rodzaju stabilności zegara nie można uzyskać za pomocą żadnej dostępnej na rynku technologii zegara. Nawet podniesienie go do 1 sekundy rocznie wymagałoby co najmniej OCXO, który wymaga wysokiej mocy, zawsze włączonego piekarnika regulującego temperaturę. Pomysł, który można uzyskać za pomocą urządzenia zasilanego baterią o długiej żywotności, jest śmieszny.

systemy czasu rzeczywistego, takie jak zegar cyfrowy, system obecności, aparat cyfrowy

Żaden z nich nie jest tak zwany systemem czasu rzeczywistego.

Systemy czasu rzeczywistego reagują na zdarzenie / bodźce wewnętrzne lub zewnętrzne w określonym czasie i zwykle w milisekundach lub mikrosekundach. Potrzebuje timera o małej precyzji, a nie RTC.

Odpowiedź na twoje pytanie brzmi: nie, nie wpłynie to na rzeczywistą aktualność systemu.

Jeśli po zresetowaniu system jest w trybie offline i ma RTC, będzie mógł wprowadzić odpowiednie daty do dzienników. Dzienniki mogą być ogromne na wypadek, gdybyś musiał je przejrzeć, a niewłaściwy znacznik czasu doprowadzi Ciebie, twórców oprogramowania i klientów do szaleństwa, a generalnie dochodzenie będzie prawie niemożliwe.

Łatwy lub trudny, niski lub wysoki w artykule, do którego się odwołujesz, jest rodzajem osobistej opinii. Jest to trudne i kosztowne, jeśli nigdy wcześniej tego nie robiłeś i nie masz jasnych wymagań systemowych i oświadczenia o pracy; i jest to łatwe i tanie, gdy wiesz, czego potrzebujesz i jakie urządzenie jest najlepsze do użycia.

W większości systemów jedyną prawdziwą przewagą urządzeń peryferyjnych RTC w porównaniu z innymi formami pomiaru czasu jest to, że pomiary czasu RTC nie ulegną zmianie, gdy reszta systemu przejdzie w stan uśpienia lub - w niektórych przypadkach - zostanie całkowicie wyłączona. Wiele urządzeń peryferyjnych RTC jest faktycznie zaprojektowanych w taki sposób, że uczynią je niepraktycznymi do większości celów innych niż rejestrowanie przybliżonej pory dnia. Na przykład wiele urządzeń peryferyjnych RTC (prawdopodobnie większość, ale być może nie nadrzędność) ogranicza się do zgłaszania czasu w przyrostach jednosekundowych, a wiele z nich co najmniej czasami wymaga zajętego oczekiwania na synchronizację podczas ustawiania alarmu lub - w niektóre przypadki - nawet po prostu próbując odczytać czas. W związku z tym normalnym sposobem korzystania z RTC jest po prostu skopiowanie jego wartości do bardziej użytecznego zegara przy uruchamianiu, ustaw go za każdym razem, gdy zostanie ustawiony „czas ściany”

a każde cztery kolejne odczyty z pewnością będą zawierać dwa pasujące (a zatem poprawne), chyba że upłynie więcej niż 1/32768 sekundy między pierwszym a ostatnim. Ustawienie alarmu może generować fałszywe zdarzenia budzenia, ale sekwencja:

• wyłącz przerwanie od zatrzasku budzenia
• ustaw czas budzenia na maksymalnie 0x7FFFFFFF tyknięć (około 9 godzin) przed czasem
• zresetować obwód budzenia
• czytać zegar
• jeśli nowo odczytany czas wskazuje, że czas budzenia został osiągnięty, działaj odpowiednio
• włączyć przerwanie od zatrzasku budzenia

powinien obsługiwać wszystkie przypadki brzegowe wystarczająco łatwo, aby nadawały się do ogólnego zastosowania w celu zachowania czasu. Niestety, z jakiegokolwiek powodu, urządzenia peryferyjne RTC nigdy nie są zaprojektowane w ten sposób, ale są bardziej skomplikowane i mniej przydatne.

Wydaje się, że jest to kwestia terminologii związanej z użyciem terminu „w czasie rzeczywistym”.

Zegar czasu rzeczywistego

Zegar czasu rzeczywistego jest urządzeniem do stabilnego / dokładnego (w pewnym zakresie tolerancji) pomiaru czasu, dzięki czemu system hosta może go użyć do powiązania zdarzeń / działań z czasem i datą wystąpienia.

Można uznać zegar czasu rzeczywistego za analogiczny do wewnętrznych elementów zegarka cyfrowego podłączonego do komputera. Ma niezależnie zasilany czas odniesienia, zaprojektowany tak, aby był stabilny i dość dokładny. Podobnie jak zegarek cyfrowy, nie straci aktualnego czasu tylko dlatego, że komputer-host został zamknięty. Zegary czasu rzeczywistego zostały zainstalowane na komputerach głównie dla wygody, aby użytkownik nie musiał ponownie wprowadzać bieżącej godziny i daty za każdym razem, gdy system jest uruchamiany, ani dokonywać częstych korekt w celu kompensacji znoszenia.

Alternatywą dla zegara czasu rzeczywistego byłoby użycie oprogramowania i wewnętrznych zegarów sterowanych przez zegar systemowy. Takie podejście jest wykonalne (oryginalny komputer IBM działał w ten sposób), ale nie jest szczególnie stabilne; utraci także datę / godzinę w dowolnym momencie, w którym system operacyjny jest zamykany, zawiesza się lub ulega awarii.

System czasu rzeczywistego

Kiedy termin „w czasie rzeczywistym” jest stosowany do systemu komputerowego lub aplikacji, opisuje system, który reaguje na zdarzenia w świecie rzeczywistym w bardzo krótkim, deterministycznym czasie - często zaledwie kilka milisekund, czasem mniej, przy określonym porządku równoczesnych danych wejściowych. Systemy czasu rzeczywistego są używane do sterowania maszynami - robotyki, symulacji i gier. Chociaż aplikacja czasu rzeczywistego może korzystać z bieżącej informacji o czasie i dacie, aplikacja nie jest „w czasie rzeczywistym” tylko dlatego, że korzysta z bieżącej godziny i daty.

Zegary czasu rzeczywistego a zegary wysokiej rozdzielczości

Jak stwierdzono powyżej, celem zegara czasu rzeczywistego jest niezawodne śledzenie bieżącej daty i godziny, zasadniczo tylko do drugiej; dobry będzie miał minimalny dryf (zyski lub straty sekund każdego dnia). Zegary czasu rzeczywistego zazwyczaj nie mają wysokiej rozdzielczości; ich zegary bazowe często działają dość wolno w porównaniu do współczesnych zegarów procesora; ma to na celu zminimalizowanie zużycia energii (zużycie niezależnego źródła zasilania), dzięki czemu zegar będzie nadal niezawodnie utrzymywał czas, jeśli komputer hosta zostanie wyłączony na dłuższy czas.

Timer o wysokiej rozdzielczości nie dotyczy bieżącej godziny ani daty; jego celem jest pomiar odstępów czasu z pewną precyzją, być może w mikrosekundach lub nawet mniej. Aby to osiągnąć, musi być oparty na stabilnym zegarze o wysokiej częstotliwości - zwykle zegarze systemowym komputera. Timery o wysokiej rozdzielczości również zwykle nie są związane z dryfowaniem w długich okresach, ponieważ zwykle celem jest pomiar czasu w krótkich okresach. Zegary wysokiej rozdzielczości nie mają takiego samego problemu z zużyciem energii jak zegary czasu rzeczywistego, ponieważ nie mają zadania do wykonania, gdy komputer hosta jest wyłączony.

Myślę, że głównym powodem zegara czasu rzeczywistego jest dokładny czas z pewnym odstępem czasu. Zwykły zegar jest zwykle przycinany kondensatorami i może wykazywać większe rozbieżności w zakresie częstotliwości w oparciu o wiele różnych czynników, być może poza kontrolą, takich jak źle dostrojona pojemność / rezystancja obwodu taktowania zegara, niepewność taktowania używanego zegara, która służy pojedynczemu celowi związanemu z wydajnością, a także często istnieje programowalna logika dzieląca czasy, które ponownie mogą wprowadzić błąd.

Zwykle RTC może mieć liczniki czasu i psy nadzorujące itp. W połączeniu z tym dajemy zagwarantowane lub dobre założenie, że w regularnych precyzyjnych odstępach czasu, które mogą nawet pozostawać w fazie z różnymi rzeczami, podane procedury lub kod zostaną wykonane. Nie można tego łatwo uzyskać za pomocą zwykłego zegara. Lub musisz być bardzo ostrożny przy produkcji, że zegar jest dokładny. Możesz zobaczyć rzeczy takie jak audio i co może nie wymagać użycia rtc zamiast zegara systemowego o wysokiej prędkości.

Co do tego, co oznacza RTC, nie mogę powiedzieć na pewno siebie. Wiem, że Linux jest powszechnym narzędziem w świecie osadzonym, ale nie jestem pewien, jak dobrze działa we wszystkich aplikacjach czasu rzeczywistego. Wielowątkowość może sprawić, że czasy wykonywania nie będą deterministyczne, jednak gdy sprzęt znacznie przekroczy wymagania dotyczące wydajności, wiele rozwiązań będzie działać dobrze nawet w aplikacjach czasu rzeczywistego.

Są też aplikacje o krytycznym znaczeniu i niskiej wydajności. Jedną z pożądanych rzeczy jest deterministyczne i często mniej skomplikowane rozwiązanie. Tutaj RTC można oczywiście wykorzystać. Linux może zapewniać specjalny dostęp do powiązanych z nim przerwań. Wydaje mi się, że dla deterministycznego czasu rzeczywistego potrzebujesz nie tylko rtc, ale także przerywa lub dostępu do nich.

Będziesz potrzebował zegara czasu rzeczywistego, jeśli polegasz na bezpiecznej komunikacji z innymi komputerami w Internecie (nie musi to być 100%, ale jeśli nie masz lokalnego czasu odniesienia, musisz zaufać czemuś innemu i możesz „ t zaufanych certyfikatów, chyba że znasz datę).

Więc nie, nie potrzebujesz go do wszystkich systemów „w czasie rzeczywistym”. Jednak w zależności od aplikacji nadal możesz chcieć, aby RTC był najbardziej energooszczędnym sposobem uzyskania dobrego czasu po przejściu w stan niskiego poboru mocy.