RTOS: Software Timer no FreeRTOS

Um software timer no FreeRTOS funciona da mesma forma que o hardware timer, entretanto, há alguns detalhes que vale ressaltar. Confira neste artigo!

Sistemas embarcados contam com diversos timers físicos (hardware) para uso interno, como em PWM, ou de uso geral com extrema precisão e imunidade a interferências do código. Porém, em muitos projetos, podemos precisar de muito mais timers do que o embarcado nos disponibiliza e aí entra o software timer. Uma das únicas limitações para a quantidade de software timers no seu embarcado é a RAM disponível e, no ESP32 com ~300 KB de RAM livre, podemos criar até ~5800 timers independentes se for necessário.

Quais as vantagens e desvantagens do software timer no FreeRTOS?

Os software timers funcionam da mesma forma que os hardware timers, entretanto, há alguns detalhes que vale ressaltar:

  1. Assim como o hardware timer, o software timer não utiliza nenhum processamento da CPU enquanto ativo;
  2. Pode ser comparado a uma tarefa do RTOS;
  3. Todos os comandos do timer são enviados à tarefa “Timer Service ou Daemon task” por uma queue, o que vamos entender mais à frente.
  4. One-shot e Auto-reload.

Vantagens

  • Não precisa de suporte do hardware, sendo de total responsabilidade do FreeRTOS;
  • Limite de timers é a memória disponível;
  • Fácil implementação.

Desvantagens

  • Latência varia de acordo com a prioridade da tarefa “Timer Service” e frequência do FreeRTOS, ambos configuráveis;
  • Pode perder comandos se usado excessivamente durante um curto período de tempo, já que a comunicação com a tarefa “Timer Service” é feita por uma queue, a qual pode ficar lotada.

Timer Service ou Daemon task

Essa tarefa é iniciada automaticamente junto ao scheduler caso você habilite os software timer no FreeRTOS. Ela é responsável por receber e executar os comandos sobre timers e também executar a função de callback quando o timer expira. Essa tarefa funciona exatamente igual a qualquer outra tarefa do RTOS, então, se houver dúvidas, basta se aprofundar nos detalhes sobre tarefas do RTOS. Como foi dito anteriormente, a prioridade é configurável e altamente aconselhável deixá-la maior que todas suas outras tarefas.

Veja nas figuras 1 e 2 a comunicação com a tarefa “Timer Service” através da queue.

Software Timer no FreeRTOS - Comunicação com a Timer Service por queue.
Figura 1 – Comunicação com a Timer Service por queue.
Timer Service efetuando preempção da própria tarefa que está configurando o timer.
Figura 2 – Timer Service efetuando preempção da própria tarefa que está configurando o timer.

Ao usar excessivamente comandos de controle do timer, a queue responsável por essa comunicação pode ficar lotada e, caso você deixe o parâmetro de espera das funções em zero, o comando será perdido. Por esse motivo, é sempre aconselhado a colocar um tempo de espera para que as funções aguardem a queue esvaziar. O motivo mais comum para lotar a queue da tarefa “Timer Service” é utilizar os comandos dentro de ISRs, já que uma ISR tem prioridade mais alta e não deixará tempo para a “Timer Service” processar dados anteriores caso venha acontecer alguma oscilação ou bouncing, por exemplo.

Vamos botar a mão na massa e criar alguns timers para aprender a usá-los e também verificar a frequência para saber se é estável ou não.

Código do projeto

Testando esse simples código, já podemos visualizar no terminal que o microcontrolador está enviando as mensagens perfeitamente em 1 segundo, mas vamos analisar mais a fundo e ver se ele se mantém estável mesmo com frequências mais altas, lembrando que a frequência máxima do software timer está limitada à frequência do RTOS. Vamos observar o desempenho do timer com o analisador lógico nas figuras 3 e 4. Em ambos testes, a ISR do timer efetuou um pulso de 50 us em um GPIO.

Veja na figura 3 (clique para ampliar se necessário), o software timer efetuando o pulso de 50 us no GPIO com frequência de 10 Hz (100 ms), observe no canto direito da imagem os detalhes da análise de ~100 pulsos.

Analisador lógico para software timer de 10 Hz.
Figura 3 – Analisador lógico para software timer de 10 Hz.

De acordo com o analisador lógico, nossa frequência média foi de 9,997 Hz (100,030009002701 ms), o que é aceitável para a maioria dos propósitos e deve-se lembrar do próprio erro do analisador lógico.

Agora vamos observar na figura 4, o software timer efetuando o pulso de 50 us no GPIO com frequência de 500 Hz (2 ms), observe no canto direito da imagem os detalhes da análise de ~100 pulsos.

Analisador lógico para software timer de 500 Hz.
Figura 4 – Analisador lógico para software timer de 500 Hz.

De acordo com o analisador lógico, nossa frequência média foi de 499,8 Hz (2,000800320128 ms), o que também é aceitável para a maioria dos projetos e não devemos esquecer novamente sobre o erro do analisador lógico.

O software timer do FreeRTOS se mostra bem estável e pode ser extremamente útil na maioria dos projetos que usam timers, já que podemos trocar os timers físicos (hardware) pelo software caso a frequência não seja tão alta. Devemos lembrar que a frequência máxima indicada para uso do FreeRTOS é de 1000 Hz, deixando o software timer atrelado a esta frequência máxima também.

Saiba mais

Biblioteca de Soft Timers

Biblioteca rápida de Timer, Delay e Timeout sem desperdícios

Sistemas Operacionais de Tempo Real – Timers

Referências

https://www.freertos.org/FreeRTOS-Software-Timer-API-Functions.html
https://freertos.org/Documentation/RTOS_book.html
http://esp-idf.readthedocs.io/en/latest/api-reference/system/freertos.html

Outros artigos da série

<< RTOS: Uso de grupo de eventos para sincronização de tarefas

Engenheiro da Computação pela USC, pretende sempre se aprimorar e fazer a diferença nesta imensa área da tecnologia. Apaixonado por sistemas embarcados IoT, processamento de imagem, linux, astronomia e integração da computação nos mais diversos fins práticos e didáticos.

Notificações
Notificar
guest
4 Comentários
recentes
antigos mais votados
Inline Feedbacks
View all comments
terra
terra
17/09/2018 10:10

Como assim “não consome nenhum processamento da CPU enquanto ativo”?

José Morais
José Morais
Reply to  terra
19/09/2018 08:01

A CPU não precisa efetuar nenhum tipo de processamento para manter o “timer contando”, podemos dizer que ele “conta independentemente da CPU”.

Felipe Neves
Felipe Neves
Reply to  José Morais
25/09/2018 12:18

José, na verdade ele demanda processamento da CPU sim, visto que o soft timer depende do tick timer, invocado a cada tick do kernel, alem disso o determinismo do timer vai variar a medida que timers entram e saem da timer list variando o uso de cpu para processamento do modulo de soft timers.

José Morais
José Morais
Reply to  Felipe Neves
25/09/2018 13:17

Sim sim, fiz apenas um resuminho (1* aproximação) que se usuário precisar, deve buscar nas referências para maiores detalhes. Mas realmente deve-se lembrar que é usado e obrigado por manter isso atualizado nos comentários.

Se o usuário ainda quiser ver uma parcela do uso, pode utilizar as funções de DEBUG para ver o tempo de absoluto da tarefa como vTaskGetRunTimeStats().

WEBINAR

Imagens de Ultrassom: Princípios e Aplicações

DATA: 26/10 ÀS 19:30 H