RTOS: Software Timer no FreeRTOS

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
NEWSLETTER

Receba os melhores conteúdos sobre sistemas eletrônicos embarcados, dicas, tutoriais e promoções.

Obrigado! Sua inscrição foi um sucesso.

Ops, algo deu errado. Por favor tente novamente.

Licença Creative Commons Esta obra está licenciada com uma Licença Creative Commons Atribuição-CompartilhaIgual 4.0 Internacional.

José Morais
Estudante de Engenharia da Computação pela USC, pretende se aprimorar e fazer a diferença nesta imensa área da tecnologia. Apaixonado por IoT, sistemas embarcados, microcontroladores e integração da computação nos mais diversos fins práticos e didáticos.

4
Deixe um comentário

avatar
 
1 Comment threads
3 Thread replies
3 Followers
 
Most reacted comment
Hottest comment thread
3 Comment authors
Felipe NevesJosé Moraisterra Recent comment authors
  Notificações  
recentes antigos mais votados
Notificar
terra
Visitante
terra

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

José Morais
Visitante
José Morais

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
Visitante
Felipe Neves

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
Visitante
José Morais

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().