É necessário um relógio em tempo real (RTC) para sistemas em tempo real? [fechadas]

Supondo que estamos trabalhando em um sistema e hardware Linux em tempo real que consiste em cronômetros de alta resolução, ter um RTC afeta a atualidade real do sistema?

Aqui diz que reduz o uso da CPU e da memória, mas existe uma maneira de comparar a diferença de alguma forma?

O artigo que você vinculou é apenas um disparate completo e absoluto. O "tempo real" no "relógio em tempo real" (como é usado para se referir ao tipo de dispositivo rígido descrito no artigo) e o "tempo real" nos "sistemas em tempo real" são termos completamente diferentes. O primeiro significa armazenar o horário atual do calendário (geralmente uma aproximação muito pobre, em oposição à alta precisão, como o artigo vinculado afirmava) e avançá-lo sem energia externa, usando uma bateria de longa duração tipo botão / moeda. O último significa responder a eventos com limites rígidos de latência desde o momento do evento até o momento da resposta.

Alguns outros trechos do artigo, para estabelecer que ele deve ser considerado não confiável:

Quase insignificante. Da ordem de 1 segundo em 100 anos

1 segundo em 100 anos é de aproximadamente 317 ppt (sim, são partes por trilhão ). Você não pode obter esse tipo de estabilidade do relógio com qualquer tecnologia de relógio disponível no mercado. Até chegar a 1 segundo por ano exigiria pelo menos um OCXO, que requer um forno sempre ligado e de alta potência que regule a temperatura. A idéia de que você poderia obtê-lo com um dispositivo alimentado por bateria de moedas de longa duração é risível.

sistemas em tempo real como relógio digital, sistema de atendimento, câmera digital

Nenhuma delas é o que se chamaria de sistemas em tempo real.

Sistemas em tempo real são algo que responde a um evento / estímulo interno ou externo em um tempo especificado e esse tempo geralmente é em mil ou microssegundos. Ele precisa de um temporizador de pequena precisão, e não do RTC.

E a resposta para sua pergunta é Não, isso não afetará a atualidade do sistema.

Se o seu sistema estiver offline após a redefinição e o RTC, ele poderá inserir as datas apropriadas nos logs. Os logs podem ser enormes, caso você precise examiná-los e ter um carimbo de data / hora errado, deixando você, seus desenvolvedores e clientes de software malucos e, em geral, a investigação quase impossível.

Fácil ou difícil, baixo ou alto no artigo a que você se refere é um tipo de opinião pessoal. É difícil e caro se você nunca fez isso antes e não possui requisitos de sistema e declaração de trabalho claros; e é fácil e barato quando você sabe o que precisa e qual é o melhor dispositivo a ser usado.

Isso parece ser um problema de terminologia que envolve o uso do termo "tempo real".

Relógio de tempo real

Um relógio em tempo real é um dispositivo para cronometragem estável / precisa (com alguma tolerância), para que o sistema host possa usá-lo para associar eventos / ações à hora e data da ocorrência.

Você pode pensar em um relógio em tempo real como análogo às entranhas de um relógio digital conectado ao computador. Possui uma referência de tempo com alimentação independente, projetada para ser estável e razoavelmente precisa. Como um relógio digital, ele não perde a noção da hora atual apenas porque o computador host foi desligado. Os relógios em tempo real foram instalados nos computadores principalmente como uma conveniência, para que o usuário não precise digitar novamente a hora e a data atuais sempre que o sistema for iniciado ou faça ajustes frequentes para compensar a deriva.

A alternativa a um relógio em tempo real seria usar software e temporizadores internos acionados pelo relógio do sistema. Essa abordagem é viável (o PC IBM original funcionava dessa maneira), mas não é particularmente estável; também perderá o controle da data / hora a qualquer momento em que o sistema operacional for desligado, travado ou travar.

Sistema em tempo real

Quando o termo "tempo real" é aplicado a um sistema ou aplicativo de computador, ele descreve um sistema que responde a eventos do mundo real em um período determinístico muito curto - geralmente apenas alguns milissegundos, às vezes menos, com pedidos definidos de entradas simultâneas. Os sistemas em tempo real são usados ​​para controle de máquinas - robótica, simulações e jogos. Embora um aplicativo em tempo real possa fazer uso das informações atuais de hora e data, um aplicativo não é "em tempo real" apenas porque faz uso da hora e data atuais.

Relógios em tempo real vs temporizadores de alta resolução

Como mencionado acima, o objetivo de um relógio em tempo real é acompanhar de forma confiável a data e a hora atuais, geralmente apenas a segunda; um bom terá desvio mínimo (segundos ganhos ou perdidos a cada dia). Relógios em tempo real geralmente não têm alta resolução; seus relógios de base costumam rodar bem devagar em comparação aos relógios de CPU modernos; isso é para minimizar o consumo de energia (drenar sua fonte de energia independente) para que o relógio continue mantendo o tempo de forma confiável se o computador host for desligado por um período prolongado.

Um cronômetro de alta resolução não se preocupa com a hora ou data atual; seu objetivo é medir intervalos de tempo com alguma precisão, talvez microssegundos ou até menos. Para fazer isso, ele deve se basear em um relógio estável e de alta frequência - normalmente o relógio do sistema do computador. Timers de alta resolução também não costumam se preocupar com desvios por longas durações, porque o objetivo usual é a medição do tempo em durações curtas. Os cronômetros de alta resolução não têm a mesma preocupação de consumo de energia que os relógios em tempo real, porque não têm um trabalho a fazer enquanto o computador host está desligado.

Na maioria dos sistemas, a única vantagem real de um periférico do RTC em relação a outras formas de controle de tempo é que as medições de tempo do RTC não serão afetadas quando o restante do sistema entrar em suspensão ou - em alguns casos - for desligado completamente. De fato, muitos periféricos RTC são projetados de maneiras que os tornariam impraticáveis ​​para a maioria dos propósitos, além de registrar a hora aproximada do dia. Muitos periféricos RTC (provavelmente a maioria, mas talvez não uma supermaioria), por exemplo, estão limitados ao tempo de relatório em incrementos de um segundo, e muitos deles, pelo menos, às vezes, exigem sincronização de espera ao definir um alarme ou - em alguns casos - até mesmo tentando ler as horas. Como conseqüência, a maneira normal de usar um RTC é simplesmente copiar seu valor para um relógio mais útil na inicialização, defini-lo sempre que "hora da parede" for definida,

e qualquer quatro leituras consecutivas deverá garantir duas que correspondam (e, portanto, estão corretas), a menos que mais de 1/32768 segundos se passem entre a primeira e a última. A configuração do alarme pode gerar eventos de ativação espúrios, mas a sequência:

• desativar interrupção da trava de ativação
• defina o tempo de ativação para até 0x7FFFFFFF (cerca de 9 horas) antes do presente
• redefinir o circuito de ativação
• leia o relógio
• se o tempo de nova leitura indicar que o tempo de ativação foi atingido, aja adequadamente
• ativar a interrupção da trava de ativação

deve lidar com todos os casos de bordas com facilidade o suficiente para ser adequado para uso de manutenção de tempo de uso geral. Infelizmente, por qualquer motivo, os periféricos RTC nunca são projetados dessa maneira, mas são mais complicados e menos úteis.

Eu acho que a principal razão para um relógio em tempo real é o tempo exato em um intervalo. O relógio regular geralmente é aparado com capacitores e pode ter discrepâncias maiores na frequência com base em uma ampla variedade de fatores que talvez estejam fora de controle, como capacitância / resistência do circuito de temporização do relógio, incerteza na temporização do relógio que está sendo usada. serve ao propósito de desempenho do duelo, assim como geralmente existe uma lógica programável para dividir os tempos que novamente podem introduzir erros.

Normalmente, o RTC pode ter temporizadores e cães de guarda, etc. Acoplado a ele, dando uma garantia ou boa suposição de que, em intervalos precisos e regulares, que podem permanecer em fase com vários procedimentos ou código, serão executados. Você não pode conseguir isso facilmente com um relógio normal. Ou você precisa ter muito cuidado na produção para que o relógio seja preciso. Você pode ver coisas como áudio e o que não pode precisar usar o rtc em vez do relógio do sistema de alta velocidade.

Quanto ao que significa RTC, não posso dizer com certeza. Eu sei que o Linux é uma ferramenta predominante no mundo incorporado, no entanto, não tenho certeza de quão bem ele funciona para todos os aplicativos em tempo real. O multithreading pode tornar os tempos de execução não determinísticos, no entanto, quando o hardware excede em muito os requisitos de desempenho, muitas soluções funcionam bem, mesmo em aplicativos em tempo real.

Depois, existem aplicativos de missão crítica e de baixo desempenho. Uma coisa desejável aqui é a solução determinística e geralmente de menor complexidade. Aqui o RTC pode ser usado obviamente. O Linux pode fornecer acesso especial às interrupções associadas a ele. Parece-me, em tempo real determinístico, que você requer não apenas um rtc, mas interrompe ou o acesso a eles.

Você precisará de um relógio em tempo real se confiar na comunicação segura com outros computadores na Internet (não é necessário 100%, mas se você não tiver uma referência de horário local, precisará confiar em outra coisa e poderá ' não confie nos certificados, a menos que você saiba a data).

Portanto, não, você não precisa de um para todos os sistemas 'em tempo real'. No entanto, dependendo da sua aplicação, você ainda pode desejar um RTC como a maneira mais eficiente de obter uma boa correção de tempo depois de estar em um estado de baixa energia.