Previsibilidade FreeRTOS em ATmega328P

O estudo investiga o impacto de alterações nas configurações do microcontrolador, especificamente a frequência do clock, na previsibilidade do sistema operacional de tempo real FreeRTOS. O objetivo principal é medir o atraso na execução de recursos-chave do FreeRTOS em diferentes frequências de clock. A pesquisa destaca a importância da previsibilidade em sistemas de tempo real, crucial para aplicações críticas como controle de temperatura em usinas nucleares e controladores de voo. A escolha do FreeRTOS, um sistema operacional de código aberto mantido pela Amazon, justifica-se por sua popularidade e por sua ampla utilização em microcontroladores. O trabalho reconhece a ausência de mecanismos de gerenciamento de energia eficiente em muitos RTOS, incluindo o FreeRTOS, e propõe a redução da frequência do clock como uma técnica para melhorar a eficiência energética, embora se reconheça os potenciais problemas de desempenho e previsibilidade que tal abordagem pode introduzir. A citação de Santos (2017, p. 32) reforça a preocupação com atrasos que podem comprometer a resposta esperada do sistema. O trabalho, portanto, visa quantificar e analisar esses efeitos.

A pesquisa contextualiza o conceito de Sistemas Operacionais de Tempo Real (RTOS), enfatizando a previsibilidade como característica principal. RTOS garantem a execução de tarefas dentro de prazos definidos, tornando-os adequados para sistemas críticos. O FreeRTOS é apresentado como exemplo, destacando suas funcionalidades multitarefas, mecanismos de comunicação e sincronização entre tarefas e tratamento de eventos externos. A capacidade de adaptação do FreeRTOS a diferentes dispositivos é mencionada, com destaque para sua portabilidade para o Arduino Uno. No entanto, a pesquisa aponta a falta de gerenciamento de energia integrado em muitos RTOS, incluindo o FreeRTOS, que depende da manipulação direta do hardware para atingir economia de energia. A pesquisa menciona a lentidão do desenvolvimento de baterias eficientes em relação a outros componentes de hardware (Urriza et al., 2004, p. 01), o que torna o gerenciamento de energia uma necessidade para sistemas embarcados. A pesquisa contrasta o uso de um RTOS com a programação sem um sistema operacional, onde o programador assume toda a responsabilidade de gerenciamento de processos, acesso ao hardware e memória, o que aumenta a complexidade e a propensão a erros. A pesquisa também diferencia sistemas de tempo real críticos e não críticos, conforme a classificação de Tanenbaum (2016, p. 26).

Esta seção descreve recursos essenciais do FreeRTOS relevantes para o estudo. O gerenciamento de memória é abordado, com destaque para a mudança na alocação de objetos do kernel (versões posteriores à 9.0.0) para uma abordagem dinâmica ou estática, abandonando a pré-alocação ineficiente. O processo de criação e exclusão de tarefas é explicado, mencionando as funções xTaskCreate e xTaskCreateStatic. A utilização de filas para comunicação e sincronização entre tarefas é detalhada, incluindo a inserção e remoção de elementos, e o tratamento de situações de filas vazias ou cheias. O conceito de grupos de eventos para comunicação entre múltiplas tarefas ou ISRs é explicado. A sincronização entre tarefas e ISRs é detalhada, usando semáforos (binários e contadores) para garantir que os recursos sejam acessados de forma correta, evitando inconsistências e deadlocks. A utilização de mutex como mecanismo de exclusão mútua para acesso a regiões críticas é explicada. Finalmente, a notificação de tarefas é descrita como um método mais rápido para comunicação, embora limitado em comparação com as filas. A pesquisa também destaca a importância da priorização de tarefas e o impacto da troca de contexto no desempenho do sistema.

A metodologia experimental envolveu a utilização da versão 10.2.0-3 do FreeRTOS em um Arduino Uno Rev3 com o microcontrolador ATmega328P. As frequências de clock testadas foram 16 MHz, 8 MHz, 4 MHz, 2 MHz e 1 MHz. Frequências inferiores a 1 MHz não foram testadas devido a limitações do Arduino Uno relacionadas a uma constante interna (clockCyclesPerMicrosecond). Os testes abrangeram a criação e exclusão de recursos (filas, tarefas, grupos de eventos), a comunicação entre tarefas (usando filas, grupos de eventos e notificação de tarefas), a sincronização entre tarefas e ISRs usando semáforos, e a troca de contexto. Os resultados mostraram um crescimento exponencial no tempo de execução dos recursos à medida que a frequência do clock diminuiu. No caso das filas, o tamanho e a quantidade de itens não afetaram os tempos de criação e exclusão, pois a alocação de memória foi feita em tempo de compilação. A alocação dinâmica de memória apresentou problemas e não foi usada nos testes de criação de recursos. O tamanho da pilha de uma tarefa impactou apenas o tempo de criação, não a exclusão. Nos testes de sincronização usando grupos de eventos, o tempo de comunicação entre tarefas foi 16% menor em relação ao uso de filas para mensagens de 1 byte. A comunicação entre ISRs e tarefas usando filas foi significativamente mais rápida do que a comunicação usando tarefas, possivelmente devido a diferentes funções de inserção de elementos nas filas e a ausência de interrupções e controle do escalonador para as ISRs.

A análise dos temporizadores de software revelou uma precisão limitada a múltiplos de 16ms (o tick do sistema), independentemente da frequência do clock. A pesquisa observou desvios padrões elevados em alguns cenários com alta concorrência de tarefas, indicando falhas na tarefa Daemon em obter a CPU a tempo para executar os temporizadores. Em geral, se o número de ticks do temporizador for maior ou igual ao número de tarefas com mesma prioridade que a Daemon, não foram detectadas anormalidades. A conclusão principal é que o aumento de atrasos no FreeRTOS é exponencial com a diminuição da frequência do clock, dobrando ou quase dobrando a cada divisão pela metade. A pesquisa destaca a necessidade de um trade-off entre a economia de energia e o aumento do tempo de resposta. O Zenodo disponibiliza os dados completos da pesquisa (TOMAZI, 2019). A economia de energia com a redução de frequência para 4 MHz é significativa, mesmo com um aumento de quatro vezes no tempo de resposta do sistema, enquanto a economia com 8MHz é menos expressiva.

O experimento utilizou um Arduino Uno Rev3, baseado no microcontrolador ATmega328P, como plataforma de teste. O sistema operacional de tempo real escolhido foi o FreeRTOS, versão 10.2.0-3, configurado com as definições padrão. A escolha do Arduino Uno se justifica pela sua popularidade e facilidade de uso para prototipagem, além de possuir hardware relativamente simples, o que torna a análise do impacto na frequência do clock mais evidente. A utilização da versão 10.2.0-3 do FreeRTOS garante a reprodutibilidade dos resultados. A frequência do clock do microcontrolador ATmega328P foi o foco da manipulação, sendo testadas as seguintes frequências: 16 MHz, 8 MHz, 4 MHz, 2 MHz e 1 MHz. Frequências inferiores a 1 MHz foram descartadas devido a limitações matemáticas em uma constante interna do Arduino Uno, a 'clockCyclesPerMicrosecond', que gera divisão por zero para valores menores que 1.000.000 Hz. A escolha da alocação estática de memória para os testes foi feita por conta de limitações e erros encontrados na alocação dinâmica de memória do port usado para o Arduino Uno, onde a função malloc não funcionava corretamente dentro das tarefas FreeRTOS. Os resultados obtidos podem ser acessados em (TOMAZI, 2019) na plataforma Zenodo.

A metodologia de teste envolveu a medição do tempo de execução de diversas funcionalidades-chave do FreeRTOS sob diferentes frequências de clock do microcontrolador. Foram testados os tempos de criação e exclusão de recursos como filas, tarefas, grupos de eventos, e mutex. A metodologia incluiu testes de comunicação entre tarefas usando diferentes mecanismos do FreeRTOS, como filas, grupos de eventos, e notificação de tarefas. A comunicação entre as tarefas e as interrupções (ISRs) foi testada utilizando filas e semáforos. A sincronização entre múltiplas tarefas foi avaliada utilizando grupos de eventos. A medição da troca de contexto foi realizada utilizando uma tarefa principal e uma secundária, registrando o tempo de troca entre elas. Para os testes de criação e exclusão de recursos, um loop foi utilizado para criar e excluir os recursos múltiplas vezes, obtendo o tempo médio de criação e exclusão. Para os testes de comunicação, o tempo total da operação, desde o início do envio da mensagem até o final do recebimento foi registrado, seguindo a sugestão de Sacha (1995, p. 2) que argumenta que medir o tempo total é mais relevante em termos práticos, pois inclui os tempos de entrega da mensagem pelo sistema operacional e a alternância das tarefas. Os tempos dos temporizadores de software foram testados variando-se o tempo dos temporizadores (múltiplos de 16ms) e o número de tarefas concorrentes para simular diferentes cenários de carga.

Os testes de criação e exclusão de recursos do FreeRTOS foram realizados usando funções de criação estática (com o sufixo 'Static'), devido a problemas com a alocação dinâmica de memória no port utilizado para o Arduino Uno. Os resultados mostraram um aumento exponencial no tempo de criação dos recursos com a redução da frequência do clock. Em relação à exclusão dos recursos, também houve um aumento exponencial do tempo, mas com uma taxa de crescimento menor em frequências mais baixas. Para filas, o número de itens e o tamanho dos mesmos não influenciaram nos tempos de criação e exclusão, já que a memória foi alocada em tempo de compilação. Nos testes com tarefas, o tamanho da pilha influenciou diretamente o tempo de criação (devido à função memset que preenche a pilha), mas não o tempo de exclusão. O comportamento observado indica que o tempo de criação e exclusão de recursos é fortemente impactado pela frequência do clock, com o tempo dobrando ou quase dobrando a cada redução pela metade da frequência, exceto para a transição de 16MHz para 8MHz, onde o aumento foi superior ao dobro, e uma desaceleração do crescimento em frequências mais baixas para a exclusão.

A comunicação entre tarefas foi avaliada utilizando filas, grupos de eventos e notificação de tarefas. Os resultados mostraram um aumento exponencial nos tempos de comunicação com a redução da frequência do clock, similar ao observado na criação e exclusão de recursos. As filas apresentaram um comportamento semelhante ao observado na comunicação entre tarefas usando grupos de eventos, mas com tempos de resposta ligeiramente mais lentos. A comunicação via grupos de eventos foi aproximadamente 16% mais rápida do que com filas para mensagens de 1 byte. A notificação de tarefas, embora mais rápida que as outras opções, apresentou limitações quanto à capacidade de envio de dados e a impossibilidade de notificar uma tarefa a partir de uma ISR. A comunicação usando ISRs (interrupções) via filas foi mais rápida do que usando tarefas, provavelmente devido à necessidade de desabilitar interrupções e o escalonador nas funções de inserção e remoção de elementos em filas no contexto das tarefas. Com relação aos grupos de eventos, o tempo de resposta a partir das ISRs foi aproximadamente o dobro do tempo com as tarefas, sem explicação clara para esse acréscimo. A troca de contexto também apresentou um aumento exponencial nos tempos com a redução da frequência do clock.

Os temporizadores de software foram testados com diferentes tempos (múltiplos de 16ms, devido ao tick do sistema) e números de tarefas concorrentes. A precisão dos temporizadores é limitada a 16ms (um tick), independentemente da frequência do clock. Testes com diferentes quantidades de tarefas (vTarefaX) concorrendo com a tarefa Daemon (responsável pela execução dos temporizadores) revelaram desvios padrões elevados em alguns cenários, especialmente quando o número de ticks do temporizador era menor que o número de tarefas com a mesma prioridade da Daemon. Isto indica que a tarefa Daemon não conseguia obter a CPU a tempo para executar os temporizadores, levando a atrasos e irregularidades na sua execução, principalmente para tempos de temporizadores de 16ms e com maior número de tarefas concorrentes. Em situações onde o número de ticks do temporizador é maior ou igual ao número de tarefas com a mesma prioridade, não foram observadas anormalidades. As tabelas completas dos resultados dos testes com temporizadores, encontram-se no apêndice A.

O estudo concluiu que o aumento dos atrasos no sistema operacional FreeRTOS é exponencial em relação à diminuição da frequência do clock do microcontrolador. Em geral, a cada redução pela metade da frequência, o tempo de execução dos recursos pelo menos dobra, mostrando que o sistema se comporta como esperado. Essa relação direta entre frequência e tempo de resposta é crucial para o desenvolvimento de sistemas embarcados que dependem de um tempo de resposta preciso. A pesquisa destaca que a alocação dinâmica de memória não foi possível dentro das tarefas do FreeRTOS devido a limitações do port específico para o Arduino Uno. No entanto, a medição do tempo de criação estática dos recursos e o tempo de manipulação dos recursos e da troca de contexto foram realizadas conforme o proposto. Os resultados fornecem dados quantitativos para a avaliação da troca entre desempenho e consumo de energia.

Os temporizadores de software do FreeRTOS, analisados neste estudo, apresentaram uma precisão limitada a 16ms (um tick), independentemente da frequência do clock do microcontrolador. Essa limitação intrínseca dos temporizadores deve ser considerada no projeto de sistemas que requeiram maior precisão temporal. A pesquisa identificou comportamentos irregulares em cenários de alta concorrência de tarefas, onde o número de ticks do temporizador era inferior ao número de tarefas com mesma prioridade que a tarefa Daemon. Nestes cenários, a tarefa Daemon, responsável pela execução dos temporizadores, não conseguia obter o controle da CPU a tempo. Para evitar esses problemas, a pesquisa sugere que o número de ticks do temporizador seja igual ou superior ao número de tarefas com mesma prioridade da tarefa Daemon. A análise completa destes resultados está disponível nas tabelas apresentadas no Apêndice A, servindo como referência para projetos futuros.

A pesquisa demonstra que a redução da frequência do clock do microcontrolador pode gerar uma significativa economia de energia, mas com o custo de um aumento no tempo de resposta do sistema. A análise dos resultados sugere que a redução da frequência para 4MHz oferece uma excelente relação custo-benefício: embora o tempo de resposta seja quatro vezes maior que em 16MHz, a economia de energia é aproximadamente seis vezes maior. Já para 8MHz, a economia de energia é menor do que a metade e o atraso é o dobro em comparação a 16MHz. A escolha da frequência ideal requer, portanto, uma avaliação cuidadosa, considerando as tolerâncias de tempo de resposta do sistema e a necessidade de economia de energia. Este estudo fornece informações relevantes para que desenvolvedores de sistemas embarcados possam fazer escolhas mais informadas ao projetar aplicações com o FreeRTOS, balanceando a necessidade de previsibilidade e eficiência energética.