¿Es necesario un reloj en tiempo real (RTC) para los sistemas en tiempo real? [cerrado]

Suponiendo que estamos trabajando en un sistema y hardware Linux en tiempo real que consiste en temporizadores de alta resolución, ¿tener un RTC afecta la oportunidad real del sistema?

Aquí dice que reduce el uso de CPU y memoria, pero ¿hay alguna manera de comparar la diferencia de alguna manera?

El artículo que vinculó es simplemente completo y sin sentido. El "tiempo real" en el "reloj en tiempo real" (como se usa para referirse al tipo de dispositivo resistente descrito en el artículo) y el "tiempo real" en los "sistemas en tiempo real" son términos completamente diferentes. Lo primero significa almacenar el tiempo actual del calendario (por lo general, una aproximación muy pobre del mismo, en oposición a la alta precisión como el artículo vinculado reclamado) y avanzar sin alimentación externa, usando una batería de botón / moneda de larga duración. Esto último significa responder a eventos con límites duros en la latencia desde el momento del evento hasta el momento de la respuesta.

Algunas otras partes del artículo, para establecer que debe considerarse como no confiable:

Casi despreciable. Del orden de 1 segundo en 100 años.

1 segundo en 100 años es aproximadamente 317 ppt (sí, eso es partes por billón ). No puede obtener ese tipo de estabilidad de reloj con ninguna tecnología de reloj disponible comercialmente. Incluso llegar a 1 segundo por año requeriría al menos un OCXO que requiere un horno de alta potencia y siempre encendido que regule la temperatura. La idea de que podría obtenerla con un dispositivo alimentado por una batería de larga duración es ridícula.

sistemas en tiempo real como reloj digital, sistema de asistencia, cámara digital

Ninguno de estos es lo que uno llamaría sistemas de tiempo real.

Los sistemas de tiempo real son algo que responde a un evento / estímulo interno o externo en un tiempo específico y ese tiempo generalmente es en mili o micro segundos. Necesita temporizador de pequeña precisión en lugar de RTC.

Y la respuesta a su pregunta es No, no afectará la actualidad del sistema.

Si su sistema está fuera de línea después de reiniciar y tiene RTC, podrá poner las fechas adecuadas en los registros. Los registros podrían ser enormes en caso de que necesite revisarlos y tener una marca de tiempo incorrecta lo volverá loco a usted, a sus desarrolladores de software y a sus clientes, y en general la investigación es casi imposible.

Fácil o difícil, bajo o alto en el artículo al que se refiere es una especie de opinión personal. Es difícil y costoso si nunca lo hizo antes y no tiene requisitos claros del sistema y declaración de trabajo; y es fácil y barato cuando sabes lo que necesitas y cuál es el mejor dispositivo para usar.

Esto parece ser un problema de terminología que rodea el uso del término "tiempo real".

Reloj en tiempo real

Un reloj de tiempo real es un dispositivo para el cronometraje estable / preciso (dentro de cierta tolerancia), de modo que el sistema host puede usarlo para asociar eventos / acciones con la hora y fecha de ocurrencia.

Puede pensar en un reloj de tiempo real como análogo a las entrañas de un reloj digital conectado a la computadora. Tiene una referencia de tiempo con alimentación independiente diseñada para ser estable y razonablemente precisa. Al igual que un reloj digital, no perderá la noción de la hora actual solo porque la computadora host se apagó. Los relojes en tiempo real se han instalado en las computadoras principalmente como una conveniencia para que el usuario no tenga que volver a ingresar la hora y fecha actuales cada vez que se inicia el sistema, o hacer ajustes frecuentes para compensar la deriva.

La alternativa a un reloj en tiempo real sería utilizar software y temporizadores internos controlados por el reloj del sistema. Tal enfoque es viable (la PC original de IBM funcionó de esa manera), pero no es particularmente estable; también perderá la noción de la fecha / hora en cualquier momento en que el sistema operativo se apague, se cuelgue o falle.

Sistema en tiempo real

Cuando el término "tiempo real" se aplica a un sistema o aplicación de computadora, describe un sistema que responde a eventos del mundo real en un período de tiempo muy corto y determinista, a menudo solo unos pocos milisegundos, a veces menos, con un orden definido de entradas simultáneas. Los sistemas en tiempo real se utilizan para cosas como el control de máquinas: robótica, simulaciones y juegos. Aunque una aplicación en tiempo real puede hacer uso de la información de fecha y hora actual, una aplicación no es "en tiempo real" simplemente porque hace uso de la hora y fecha actuales.

Relojes en tiempo real vs temporizadores de alta resolución

Como se indicó anteriormente, el propósito de un reloj en tiempo real es realizar un seguimiento confiable de la fecha y hora actuales, generalmente solo en el segundo; una buena tendrá una deriva mínima (segundos ganados o perdidos cada día). Los relojes de tiempo real generalmente no tienen alta resolución; sus relojes base a menudo funcionan bastante lentamente en comparación con los relojes modernos de CPU; esto es para minimizar el consumo de energía (consumir su fuente de energía independiente) para que el reloj continúe manteniendo la hora de manera confiable si la computadora host está apagada durante un período prolongado.

Un temporizador de alta resolución no se preocupa por la hora o fecha actual; su propósito es medir intervalos de tiempo con cierta precisión, tal vez microsegundos o incluso menos. Para lograr esto, debe basarse en un reloj estable de alta frecuencia, generalmente el reloj del sistema de la computadora. Los temporizadores de alta resolución tampoco suelen preocuparse por la deriva durante largas duraciones, porque el propósito habitual es la medición del tiempo durante cortas duraciones. Los temporizadores de alta resolución no tienen el mismo problema de consumo de energía que los relojes en tiempo real porque no tienen un trabajo que hacer mientras la computadora host está apagada.

En la mayoría de los sistemas, la única ventaja real de un periférico RTC sobre otras formas de cronometraje es que las mediciones de tiempo del RTC no se verán afectadas cuando el resto del sistema se quede inactivo o, en algunos casos, se apague por completo. De hecho, muchos periféricos RTC están diseñados de manera que no sean prácticos para la mayoría de los propósitos, aparte de registrar la hora aproximada del día. Muchos periféricos RTC (probablemente una mayoría, pero quizás no una supermayoría), por ejemplo, se limitan al tiempo de notificación en incrementos de un segundo, y muchos de ellos al menos a veces requieren una espera ocupada para la sincronización al configurar una alarma o - en algunos casos, incluso simplemente tratando de leer la hora. Como consecuencia, la forma normal de usar un RTC es simplemente copiar su valor a un reloj más útil al inicio, configurarlo cada vez que se establezca el "tiempo de pared",

y se garantizaría que cuatro lecturas consecutivas contengan dos que coincidan (y por lo tanto son correctas) a menos que transcurran más de 1/32768 segundos entre el primero y el último. Configurar la alarma puede generar eventos espurios de despertar, pero la secuencia:

• desactivar la interrupción del pestillo de activación
• establecer el tiempo de activación para hasta 0x7FFFFFFF ticks (aproximadamente 9 horas) antes del presente
• restablecer el circuito de activación
• lee el reloj
• Si la hora de nueva lectura indica que se ha alcanzado la hora de despertarse, actúe adecuadamente
• habilitar la interrupción del pestillo de activación

debe manejar todos los casos de borde con la suficiente facilidad como para ser adecuado para el uso de cronometraje de uso general. Desafortunadamente, por cualquier razón, los periféricos RTC nunca están diseñados de esa manera, sino que son más complicados y menos útiles.

Creo que la razón principal de un reloj de tiempo real es la hora exacta de hasta cierto intervalo. El reloj normal generalmente se ajusta con condensadores y puede tener mayores discrepancias en la frecuencia en función de una amplia variedad de factores, tal vez fuera de control, como la capacitancia / resistencia desajustada del circuito de temporización del reloj, la incertidumbre en la temporización del reloj que se está utilizando. cumple el propósito de duelo para el rendimiento, así como a menudo hay una lógica programable para dividir los tiempos que nuevamente pueden introducir errores.

Por lo general, el RTC puede tener temporizadores y perros guardianes, etc. Acoplado a él, lo que supone una buena o garantizada suposición de que a intervalos precisos regulares que incluso pueden permanecer en fase con varias cosas, se ejecutarán procedimientos o códigos dados. No puede obtener esto fácilmente con un reloj normal. O debe tener mucho cuidado en la producción para que el reloj sea exacto. Puede ver cosas como el audio y lo que no necesita usar el rtc en lugar del reloj del sistema de alta velocidad.

En cuanto a lo que significa RTC, no puedo decirlo con certeza. Sé que Linux es una herramienta frecuente en el mundo integrado, sin embargo, no estoy seguro de qué tan bien funciona para todas las aplicaciones en tiempo real. El subprocesamiento múltiple puede hacer que los tiempos de ejecución no sean deterministas, sin embargo, cuando el hardware excede en gran medida los requisitos de rendimiento, muchas soluciones funcionarán bien incluso en aplicaciones en tiempo real.

Luego están las aplicaciones de misión crítica y de bajo rendimiento. Una cosa deseable aquí es la solución determinista y, a menudo, de menor complejidad. Aquí el RTC se puede usar obviamente. Linux puede proporcionar acceso especial a las interrupciones acopladas a él. Me parece que, en tiempo real determinista, no solo necesita un rtc, sino que interrumpe el acceso a ellos.

Necesitará un reloj de tiempo real si depende de una comunicación segura con otras computadoras en Internet (no debe tener el 100%, pero si no tiene una referencia de hora local, debe confiar en otra cosa, y puede ' No confíe en los certificados a menos que sepa la fecha).

Entonces, no, no necesita uno para todos los sistemas 'en tiempo real'. Sin embargo, dependiendo de su aplicación, es posible que aún desee un RTC como la forma más eficiente de obtener un buen tiempo después de estar en un estado de baja potencia.