Como é que se justifica a utilização de temporizadores em sistemas embebido e em tempo-real? 1. Nestes sistemas, tarefas do sistema e do utilizador fazem escalonamento e execução de actividades após decorrer um determinado período de tempo 2. Sistemas complexos são compostos por vários módulos de software e componentes, cada um requerendo temporizadores com diferentes valores de timeout A maioria dos sistemas embebidos usam dois tipos de temporizadores na gestão de actividades sensíveis à temporização 1. Temporizadores por hardware 2. Temporizadores por software
Temporizadores por hardware 1. Derivado do integrado temporizador (PIT) que interrompe directamente o processador ao expirar um determinado tempo 2. Operações com exigências de precisão ou latência precisam do desempenho previsível deste tipo de temporizadores Temporizadores por software 1. São eventos de software que são escalonados através das facilidades de software 2. Permite escalonamento eficiente de eventos de software que não requerem alta precisão 3. Reduzem o overhead do sistema de interrupção
Relógio Tempo-Real (RTC) vs. Relógio do sistema O relógio tempo-real (RTC) é responsável pelo registo e controlo da hora, dia, mês e ano É independente do CPU e do PIT Vem acompanhado com uma DRAM alimentado por bateria
Relógio Tempo real (RTC) vs. Relógio do sistema A tarefa do relógio do sistema depende da implementação e pode ser: Registar e controlar o tempo real ou o tempo decorrido desde do arranque do sistema Normalmente é inicializado com o valor obtido directamente a partir da leitura do RTC no arranque do sistema ou então pelo utilizador É dependente do PIT Actualizado a cada interrupção do timer: incrementando em uma unidade o seu valor actual
PIT (Programmable Interval Timers) O PIT é normalmente inicializado durante o arranque do sistema 1. Tem associado vários registos de controlo um dos quais é carregado com o valor de contagem que determina a ocorrência da próxima interrupção 2. Outros registos servem para configurar o modo de operação
A capacidade de geração de eventos periódicos é uma das características mais importantes do PIT em ambientes embebidos A inicialização do PIT envolve os seguintes passos Colocar o integrado PIT num estado conhecido PIT (Programmable Interval Timers) Calcular o valor para o frequência de interrupção desejada e coloca-o no registo de controlo TINTR (Timer interrupt-rate register) TINTR = F(x), x é frequência do cristal de entrada Programar com valores adequados, os restantes registos de controlo associados à frequência de interrupção anteriormente calculada Estabelecer o modo de operação através da programação do registo de controlo adequado Instalar a ISR no sistema Activar a interrupção do Timer
Responsbilidades da ISR do Timer 1. Actualização do relógio do sistema: i. Tempo absoluto: data, hora, minutos e segundos ii. Tempo decorrido desde do arranque do sistema em ticks de relógio 2. Invocação de uma tarefa do kernel para notificar o escalonador que expirou o período de tempo (ocorrência de um tick de relógio) 3. Notificação da ocorrência do tick de relógio à gestão dos temporizadores por software 4. Confirmação da interrupção, re-inicialização do(s) registo(s) de controlo e retorno da interrupção
Modelo para a implementação da gestão dos temporizadores por software Serviços associados a gestão dos temporizadores por software: i. Permitir às aplicações criar e arrancar um temporizador ii. Permitir às aplicações destruir, parar ou cancelar um temporizador anteriormente instalado iii. Gestão interna dos temporizadores das aplicações A gestão dos temporizadores por software é normalmente composto por: 1. Componente executado no contexto da ISR (por exemplo, ISR_timeout_fn) 2. Componente executado no contexto da tarefa da aplicação
Modelo para a implementação da gestão dos temporizadores por software 1. Exemplo da aplicação com 3 temporizadores por software com timeouts de 200ms, 300ms e 500ms 2. PIT programado para ticks de relógio a cada 10ms 3. Da figura anterior, a função da componente executado no contexto da ISR consiste em permitir o escalonamento da tarefa de gestão dos temporizadores a cada 100ms 4. A aplicação manterá uma tabela com contagem decrescente em múltiplos de 100ms (actualizado a cada invocação da tarefa de gestão dos temporizadores no ponto de escalonamento) mais as funções de processamento escalonadas para execução ao expirar o respectivo timeout
Modelo para a implementação da gestão dos temporizadores por software Como é que se estima a latência associada à execução das tarefas de processamento (por exemplo, de App_timeout_fn_1)? Esta latência apresentará também atrasos a dois níveis: 1. Atraso no escalonamento da tarefa de gestão 2. Atraso na execução do processamento associado ao timeout
Modelo para a implementação da gestão dos temporizadores por software Mantendo os temporizadores numa lista não ordenada degrada o desempenho porque requer que esta lista seja percorrida para a actualização de cada entrada na ocorrência de um tick de relógio, e na remoção de um temporizador 1. O tempo de execução para a inserção de um temporizador pode ser constante 2. A remoção e actualização dos temporizadores requer tempo de execução O(N) no prior dos casos
Modelo para a implementação da gestão dos temporizadores por software Pode-se obviar o problema usando uma lista duplamente ligada em que um temporizador poderá ser inserido no fim ou no ínicio da lista Ordenando a lista por ordem crescente de timeouts: Ao inserir um novo temporizador, o valor do timeout deve ser alterado de acordo com a primeira entrada e só depois proceder-se-á à inserção do temporizador na lista 1. A inserção e remoção de um temporizador requer pesquisa e inserção e por isso, terá um custo de O( log(n) ) 2. A actualização dos temporizadores terá um tempo de execução constante
Roda de temporização (Timing Wheels) Timing wheel é um array de dimensão fixa em que cada entrada (slot) representa uma unidade de tempo relativa à precisão do gestor de temporizadores por software 1. Apresenta as vantagens das listas ordenadas na actualização dos temporizadores a cada tick de relógio 2. As operações de remoção e inserção de um temporizadores são eficientes 3. A frequência do timeout determina a precisão do gestor de temporizadores Instalado a partir de um temporizador periódico por hardware 4. Em cada entrada é também armazenada uma lista duplamente ligada com as funções callback invocadas ao expirar o timeout associado
Roda de temporização (Timing Wheels) 5. Na ocorrência de um tick de relógio, o ponteiro do relógio é incrementado e aponta para a próxima entrada Ao atingir a última entrada passa para a primeira 6. Para uma precisão de 50 ms, cada entrada representa a passagem de 50 ms, que é o menor timeout que pode ser instalado 7. O ponteiro de relógio actual (clock dial) serve de ponto de referência na determinação da entrada de instalação de um novo temporizador Por exemplo, para escalonar um timeout nos próximos 200 ms (a partir da entrada actual do ponteiro do relógio, 0/+350) será utilizada a entrada marcada com +200
Roda de temporização (Timing Wheels) Sabendo que o número de entradas é limitado, diga como escalonar eventos para além desse limite? 1. Rejeitar a instalação (inserção) de um temporizador fora da gama fixa pre-estabelecida 2. Ou acumular os eventos que estão fora da gama num buffer temporário de overflow e aguardar até que o ponteiro de relógio se posicione numa entrada a partir da qual o evento se torna escalonável i. Para a localização actual do ponteiro de relógio, entrada 1, o escalonamento de um timeout nos próximos 400 ms deve aguardar que o ponteiro seja incrementado para a localização 2. Um timeout de 500 ms deve ser instalado quando o ponteiro atingir a localização 3 ii. Proceder-se-á à instalação apenas após o processamento dos eventos nas entradas 2 e 3, respectivamente iii. A cada actualização do ponteiro de relógio, o buffer de overflow deve ser examinado para verificar a possibilidade de escalonamento de novo evento
Roda de temporização (Timing Wheels) A precisão na instalação de um novo timeout está sujeita em média a um erro de aproximadamente 50% da frequência de timeout Considere a situação em que se pretende instalar um timeout de 150 ms antes da ocorrência de um tick de relógio. Será o evento inserido na entrada +150 ms ou +200 ms? As funções callbacks podem tornar a implementação da gestão de temporizadores não determinística porque não se conhece os tempos de execução destas funções Não existe um limite máximo associado às chamada das callbacks e como tal, os intervalos x e y são não determinísticos a solução depende da aplicação
Roda de temporização (Timing Wheels) Discuta a implementação de um timing wheel para uma gama de 100 ms a 5 min. Para uma precisão de 100 ms seriam necessários 3000 entradas que consistia num consumo exagerado de recursos num ambiente com recursos limitados desempenho seria degradada nas operações de remoção e inserção e muita RAM seria consumida 10 x 100 ms = 1s 10 entradas/s 60 s = 1 min 60 x 10 entradas / min Por isso seriam necessários: 5 x 60 x 10 = 3000 entradas
Roda de temporização hierárquica Características de um timing wheel hierárquico Apresenta vários timing wheels Cada timing wheel na hierarquia apresenta uma precisão diferente Um ponteiro de relógio é associado a cada timing wheel Actualizada para a proxima localização quando o ponteiro do relógio do nível inferior dá a volta A redução em espaço permite a implementação de temporizadores de alta precisão com uma vasta gama de timeouts
Roda de temporização hierárquica Discuta a implementação de um timing wheel hieráquico para uma gama de 100 ms a 5 mn. Seriam necessários apenas 75 entradas para timeouts com resolução de 100 ms e duração até 5 minutos: 1º array (o da esquerda) 10 x 100 ms = 1 s 10 entradas/s 2º array (0 do meio) 60 s = 1 min 60 entradas / min 3º array (o da direita) 5 entradas para 5 minutos Total de 75 entradas = 5 + 60 + 10
Roda de temporização hierárquica Como procederia para instalar um timeout de 2min, 4 s e 300ms? 1. Instalava-se o callback na entrada de 2 min 2. O callback anterior ao ser invocado pela vez instalava-se a si próprio na entrada de 4 s 3. Na próxima vez que é invocado, ao expirar os 4 s, reinstala-se na entrada correspondente aos 300 ms 4. O processamento real seria efectuado pelo callback ao expirar os últimos 300 ms
APIs para operações de temporização Muitos RTOS fornecem sob a forma de APIs um conjunto de operações de temporizações divididos em três grupos: Grupo 1 Grupo 2 Grupo 3 Operações de baixo nível para o acesso ao hardware: Timer_enable(), Timer_disable(), Timer_getrate(),... Serviços para a gestão dos temporizadores por software: Timer_create(),Timer_delete(), Timer_start(), Timer_stop(),... Operações de acesso às estruturas de dados do RTC ou do relógio do sistema: Clock_getTime(), Clock_setTime(),...