Une horloge en temps réel (RTC) est-elle nécessaire pour les systèmes en temps réel? [fermé]

En supposant que nous travaillons sur un système et un matériel Linux en temps réel composés de minuteries haute résolution, le fait d'avoir un RTC affecte-t-il la rapidité du système?

Ici, il dit qu'il réduit l'utilisation du processeur et de la mémoire, mais existe-t-il un moyen de comparer la différence d'une manière ou d'une autre?

L'article que vous avez lié est juste un non-sens complet et absolu. Le «temps réel» dans «l'horloge en temps réel» (car il est utilisé pour désigner le type de périphérique difficile décrit dans l'article) et le «temps réel» dans les «systèmes en temps réel» sont des termes complètement différents. Le premier signifie stocker l'heure actuelle du calendrier (généralement une très mauvaise approximation de celle-ci, par opposition à une haute précision comme l'article lié revendiqué) et l'avancer sans alimentation externe, en utilisant une pile longue durée de type bouton / pièce. Ce dernier signifie répondre aux événements avec des limites strictes sur la latence du moment de l'événement au moment de la réponse.

Quelques autres extraits de l'article, pour établir qu'il doit être considéré comme non fiable:

Presque négligeable. De l'ordre de 1 sec en 100 ans

1 sec en 100 ans équivaut à environ 317 ppt (oui, c'est des parties par billion ). Vous ne pouvez pas obtenir ce type de stabilité d'horloge avec une technologie d'horloge existante disponible dans le commerce. Même le faire passer à 1 seconde par an nécessiterait au moins un OCXO qui nécessite un four haute puissance, toujours allumé, régulant la température. L'idée que vous pourriez l'obtenir avec un appareil alimenté par une pile bouton longue durée est risible.

systèmes en temps réel comme horloge numérique, système d'assistance, appareil photo numérique

Rien de tout cela n'est ce que l'on pourrait appeler des systèmes en temps réel.

Les systèmes en temps réel sont quelque chose qui répond à un événement / stimuli interne ou externe dans un temps spécifié et ce temps est généralement en milli ou micro secondes. Il a besoin d'une minuterie de petite précision plutôt que de RTC.

Et la réponse à votre question est Non, cela n'affectera pas la réelle actualité du système.

Si votre système est hors ligne après la réinitialisation et qu'il dispose de RTC, il pourra mettre les dates appropriées dans les journaux. Les journaux peuvent être énormes au cas où vous auriez besoin de les parcourir et si le mauvais horodatage vous rendrait fou, vos développeurs de logiciels et vos clients, et en général, l'enquête serait presque impossible.

Facile ou difficile, bas ou haut dans l'article auquel vous vous référez est une sorte d'opinion personnelle. C'est difficile et coûteux si vous ne l'avez jamais fait auparavant et que vous n'avez pas d'exigences système claires et d'énoncé de travail; et c'est facile et bon marché lorsque vous savez ce dont vous avez besoin et quel est le meilleur appareil à utiliser.

Dans la plupart des systèmes, le seul véritable avantage d'un périphérique RTC par rapport à d'autres formes de chronométrage est que les mesures de temps du RTC ne seront pas affectées lorsque le reste du système se mettra en veille ou, dans certains cas, sera complètement éteint. De nombreux périphériques RTC sont en fait conçus de manière à les rendre impraticables pour la plupart des objectifs autres que l'enregistrement de l'heure approximative de la journée. De nombreux périphériques RTC (probablement une majorité mais peut-être pas une super majorité), par exemple, sont limités au temps de rapport par incréments d'une seconde, et beaucoup d'entre eux nécessiteront au moins parfois une attente occupée pour la synchronisation lors du réglage d'une alarme ou - dans certains cas - même en essayant simplement de lire l'heure. En conséquence, la façon normale d'utiliser un RTC est de simplement copier sa valeur sur une horloge plus utile au démarrage, de la régler chaque fois que "l'heure du mur" est définie,

et quatre lectures consécutives seraient garanties pour en contenir deux qui correspondent (et sont donc correctes) à moins que plus de 1/32768 seconde ne s'écoule entre la première et la dernière. Le réglage de l'alarme peut générer des événements de réveil parasites, mais la séquence:

• désactiver l'interruption du verrou de réveil
• définir le temps de réveil jusqu'à 0x7FFFFFFF ticks (environ 9 heures) avant le présent
• réinitialiser le circuit de réveil
• lire l'horloge
• si l'heure nouvellement lue indique que l'heure de réveil a été atteinte, agissez de manière appropriée
• activer l'interruption à partir du verrou de réveil

devrait manipuler tous les cas de bord suffisamment facilement pour convenir à une utilisation de conservation du temps à usage général. Malheureusement, pour une raison quelconque, les périphériques RTC ne sont jamais conçus de cette façon, mais sont plutôt plus compliqués et moins utiles.

Cela semble être une question de terminologie entourant l'utilisation du terme «temps réel».

Horloge temps réel

Une horloge en temps réel est un dispositif de chronométrage stable / précis (dans une certaine tolérance), afin que le système hôte puisse l'utiliser pour associer des événements / actions à l'heure et à la date d'occurrence.

Vous pouvez penser à une horloge en temps réel comme analogue aux entrailles d'une montre numérique connectée à l'ordinateur. Il a une référence de temps alimentée indépendamment conçue pour être stable et raisonnablement précise. Comme une montre numérique, elle ne perdra pas la trace de l'heure actuelle simplement parce que l'ordinateur hôte a été arrêté. Des horloges en temps réel ont été installées sur les ordinateurs principalement pour plus de commodité afin que l'utilisateur n'ait pas à ressaisir l'heure et la date actuelles à chaque démarrage du système ou à effectuer des ajustements fréquents pour compenser la dérive.

L'alternative à une horloge en temps réel serait d'utiliser des logiciels et des temporisateurs internes pilotés par l'horloge système. Une telle approche est réalisable (le PC IBM d'origine fonctionnait de cette façon), mais n'est pas particulièrement stable; il perdra également la trace de la date / heure à tout moment où le système d'exploitation est arrêté, bloqué ou se bloque.

Système en temps réel

Lorsque le terme «temps réel» est appliqué à un système informatique ou à une application, il décrit un système qui répond aux événements du monde réel dans un laps de temps déterministe très court - souvent quelques millisecondes, parfois moins, avec un ordre défini. d'entrées simultanées. Les systèmes en temps réel sont utilisés pour des choses telles que le contrôle des machines - robotique, simulations et jeux. Bien qu'une application en temps réel puisse utiliser les informations de date et d'heure actuelles, une application n'est pas "en temps réel" simplement parce qu'elle utilise la date et l'heure actuelles.

Horloges en temps réel vs minuteries haute résolution

Comme indiqué ci-dessus, le but d'une horloge en temps réel est de garder une trace fiable de la date et de l'heure actuelles, généralement à la seconde près; un bon aura une dérive minimale (secondes gagnées ou perdues chaque jour). Les horloges en temps réel n'ont généralement pas de haute résolution; leurs horloges de base fonctionnent souvent assez lentement par rapport aux horloges CPU modernes; ceci afin de minimiser la consommation d'énergie (drainer sur sa source d'alimentation indépendante) afin que l'horloge continue de conserver de manière fiable l'heure si l'ordinateur hôte est éteint pendant une période prolongée.

Une minuterie haute résolution n'est pas concernée par l'heure ou la date actuelle; son but est de mesurer des intervalles de temps avec une certaine précision, peut-être des microsecondes ou même moins. Pour ce faire, il doit être basé sur une horloge haute fréquence stable - généralement l'horloge du système informatique. Les temporisateurs à haute résolution ne sont pas non plus généralement concernés par la dérive sur de longues durées, car le but habituel est la mesure du temps sur de courtes durées. Les minuteries haute résolution n'ont pas la même préoccupation de consommation d'énergie que les horloges en temps réel, car elles n'ont pas de travail à faire lorsque l'ordinateur hôte est éteint.

Je pense que la raison principale d'une horloge en temps réel est l'heure exacte jusqu'à un certain intervalle. L'horloge régulière est généralement assortie de condensateurs et peut présenter des écarts de fréquence plus importants en fonction d'une grande variété de facteurs, peut-être hors de contrôle, tels que la capacité / résistance mal réglée du circuit de synchronisation d'horloge, l'incertitude dans la synchronisation de l'horloge utilisée qui sert l'objectif duel pour la performance, ainsi qu'il y a souvent une logique programmable pour diviser les temps qui peuvent à nouveau introduire une erreur.

Habituellement, le RTC peut avoir des minuteries et des chiens de garde, etc. Couplé à lui, donnant l'hypothèse garantie ou bonne qu'à intervalles réguliers et précis qui peuvent même rester en phase avec diverses choses, des procédures ou du code donnés seront exécutés. Vous ne pouvez pas facilement obtenir cela avec une horloge régulière. Ou vous devez être très prudent dans la production afin que l'horloge soit précise. Vous pouvez voir des choses comme l'audio et ce qui peut ne pas avoir besoin d'utiliser le rtc au lieu de l'horloge système à haute vitesse.

Quant à ce que signifie RTC, je ne peux pas le dire avec certitude. Je sais que Linux est un outil répandu dans le monde embarqué, mais je ne sais pas à quel point il fonctionne pour toutes les applications en temps réel. Le multithreading peut rendre les temps d'exécution non déterministes, mais lorsque le matériel dépasse largement les exigences de performances, de nombreuses solutions fonctionnent correctement, même dans les applications en temps réel.

Ensuite, il y a des applications critiques et à faible performance. Une chose souhaitable ici est une solution déterministe et souvent moins complexe. Ici, le RTC peut être utilisé évidemment. Linux peut fournir un accès spécial aux interruptions qui lui sont couplées. Il me semble que pour un temps réel déterministe, vous avez besoin non seulement d'un rtc, mais d'interruptions ou d'un accès os à eux.

Vous aurez besoin d'une horloge en temps réel si vous comptez sur une communication sécurisée avec d'autres ordinateurs sur Internet (pas à 100%, mais si vous n'avez pas de référence d'heure locale, vous devez faire confiance à autre chose, et vous pouvez '' t faire confiance aux certificats sauf si vous connaissez la date).

Donc, non, vous n'en avez pas besoin pour tous les systèmes «en temps réel». Cependant, selon votre application, vous souhaiterez peut-être toujours un RTC comme moyen le plus économe en énergie pour obtenir une bonne correction de temps après avoir été dans un état de faible puissance.