Álvaro Albuquerque

Rafael Monteiro
Roger Matos
O que é FreeRTOS?
● É um sistema operacional de tempo real para microcontroladores e pequenos
microprocessadores;
● Inclui um kernel e uma grande quantidade de bibliotecas para os mais
variados usos;
● Comprado pela Amazon em 2017 e ela é responsável pelo seu suporte desde
então.
Para qual tipo e tamanho de sistema o FreeRTOS é
indicado?
● Seu foco está na compacidade e velocidade de execução;
● Feito com o intuito de ser pequeno o suficiente para rodar em
microcontroladores e dispositivos de baixo consumo de energia;
● Muitas vezes pode ser visto como uma biblioteca de threads e não como um
sistema operacional, devido à sua simplicidade;
● O Amazon FreeRTOS contém bibliotecas que fazem integração com os
sistemas de computação em nuvem da Amazon;
● IoT e Edge Computing.
Arquiteturas de hardware
● ARM
○ Principal provedor da tecnologia de
processadores, oferece a maior variedade de
processadores para melhores requerimentos de
custo e performance;
○ Cortex-A, Cortex-M, Cortex-R, Neoverse, Ethos.
● MIPS
○ Fundamental em diversos dispositivos de IoT.
● RISC-V
○ Combina uma abordagem técnica modularizada
com um modelo de negócios open-license.
● Intel
○ Fornece microprocessadores, placas-mãe,
circuitos integrados, memórias flash, entre outros.
Arquiteturas de Software
Arquiteturas de software
● Kernel do FreeRTOS
○ Um kernel de sistema operacional em tempo real para microcontroladores.
● CoreHTTP
○ Biblioteca de cliente HTTP para criar aplicações que utilizam API REST para se conectar a
um servidor HTTP.
● CoreMQTT
○ Biblioteca de cliente MQTT para criar publicações que criam e assinam tópicos de MQTT e se
conectam a um agente de mensagens baseado em MQTT.
● Biblioteca device shadows
○ Define funções para criar, atualizar e excluir AWS Iot Device Shadows.
● Agente OTA
○ Gerenciamento de notificação, download e verificação de atualizações de firmware para
dispositivos de FreeRTOS.
Arquitetura de software
Outros componentes da arquitetura de software:

● Biblioteca de gerenciamento de Wi-Fi;

● Biblioteca de gerenciamento de Bluetooth low energy;
● Biblioteca do Device Defender;
● Interface do Transport Layer Security (TLS).
Tarefas
● Tasks:
○ Cada task executa dentro de seu próprio contexto sem depender de outras tasks dentro do
sistema ou do scheduler;
○ Apenas uma task executada por vez (single core);
○ Alternância entre tasks feitas pelo scheduler;
○ Cada task terá uma pilha responsável por armazenar o contexto;
○ Simples e sem restrição de uso;
○ Permite preempção completa e prioridades;
○ Maior utilização de RAM por task;
Tarefas
● Co-routines:
○ Implementadas para uso em dispositivos bem pequenos, mas raramente utilizada atualmente;
○ Parecido com tasks, porém com algumas diferenças;
○ Todas co-routines compartilham a mesma pilha;
○ Compartilhando a mesma pilha, deve-se ter atenção ao seu uso;
○ Usa scheduling cooperativo com prioridade em relação a outras co-routines, mas pode ser
incluída em aplicações com tasks preemptivas;
○ Possui limitações no uso, por conta da redução no uso da RAM.
Tarefas
● Estados:
○ Tasks:
■ Running: usando o processador;
■ Ready: esperando ser executada;
■ Blocked: Esperando um evento
(delay, fila, semáforo, externo).
Normalmente, podem ter timeout
para executar mesmo quando
evento não ocorreu;
■ Suspended: Não possuem timeout
e só entram ou saem desse
estado caso seja explicitamente
comandado.
Tarefas
● Estados:
○ Co-routines:
■ Running: usando o processador;
■ Ready: esperando ser executada.
Pode acontecer caso haja outra
co-routine de igual ou maior
prioridade ou caso haja alguma
task sendo executada;
■ Blocked: Esperando por algum
evento (temporal ou externo).
Tarefas
● Prioridades:
○ Tasks:
■ Cada task é associada com uma prioridade que vai de 0 a
configMAX_PRIORITIES - 1;
■ configMAX_PRIORITIES deve ser o menor possível para minimizar a utilização
de RAM;
■ Número pequenos de prioridade denotam prioridade baixa;
■ Task idle tem prioridade 0:
● Task idle é criadas quando o scheduler inicia para ter sempre uma task a
ser executada;
● Libera espaço na memória quando tasks são deletadas.
■ Task no estado Running é sempre a de maior prioridade possível de ser
executada;
Tarefas
● Prioridades:
○ Co-routines:
■ Cada task é associada com uma prioridade que vai de 0 a
configMAX_PRIORITIES - 1;
■ configMAX_PRIORITIES deve ser o menor possível para minimizar a utilização
de RAM;
■ Número pequenos de prioridade denotam prioridade baixa;
■ As prioridades de co-routines apenas fazem diferença dentro do contexto de
co-routine, pois tasks terão sempre maior prioridade sobre co-routines.
Tarefas
● Scheduling:
○ Tasks:
■ “By default, FreeRTOS uses a fixed-priority preemptive scheduling policy, with
round-robin time-slicing of equal priority tasks”
● “fixed-priority”: Tasks terão prioridades fixas, porém podem ser
temporariamente alteradas por conta do priority inheritance;
● “preemptive”: O scheduler sempre executará a tarefa de maior prioridade
habilitada para ser executada;
● “round-robin”: Tasks que compartilham mesma prioridade alternam entre si
o estado de Running;
● “time-slicing”: Essa alternância é feita a cada interrupção por tick. Sendo o
tempo entre cada tick o denominado “time slice”
■ Tarefas com maior prioridade que dependam de evento sempre são enviadas
para estado Suspended ou Blocked até o evento ocorrer, a fim de não bloquear
tarefas de menor prioridade;
Tarefas
● Scheduling:
○ Co-routines:
■ Em sistemas que possuem co-routines e tasks, as co-routines só serão
executadas quando não houver tasks de maior prioridade que a task idle
disponíveis de serem executadas;
■ Co-routines são geralmente agendadas (scheduled) dentro de cada ciclo da
função idle utilizando a chamada vCoRoutineSchedule();
■ Isso acontece mesmo quando o sistema for composto somente de co-routines,
pois a task idle sempre será criada quando o scheduler for iniciado.
Memória
● Estático vs Dinâmico:
○ A partir da versão 9.0 do FreeRTOS, é possível criar objetos RTOS de forma estática ou
dinâmica;
○ Entre os objetos temos:
■ Tasks;
■ Software Timers;
■ Queues;
■ Event groups;
■ Semaphores;
■ Mutexes.
○ Ambos os métodos possuem prós e contras. E fica a cargo do desenvolvedor escolher qual
utilizar.
Memória
● Estático:
○ Objetos estáticos podem ser colocados em locais específicos da memória;
○ A utilização da RAM pode ser determinada em tempo de ligação (link time), e não em tempo
de execução (run time);
○ Não é necessário lidar com erros em alocação de memória;
○ Diminui a latência do sistema;
○ Para criar esse objetos RTOS, o desenvolvedor só precisa informar o local da memória onde
quer criar;
Memória
● Dinâmico:
○ Oferece mais simplicidade e aumenta potencial de diminuir a utilização de RAM;
○ Menos parâmetros são necessários para criar o objeto;
○ A alocação dinâmica ocorre automaticamente dentro das chamadas API do RTOS;
○ O desenvolvedor não precisa se preocupar em alocar a memória na mão;
○ A RAM utilizada por objetos deletados pode ser ser reutilizada;
○ As funções da API do RTOS retornam informações sobre a utilização da heap para oferecer
mais controle e prover otimização em sua utilização;
○ Existem diferente métodos de alocar memória e vai do desenvolvedor escolher qual a melhor
para a aplicação:
■ Simplicidade e determinismo, para aplicações com segurança crítica;
■ Proteção contra fragmentação;
■ Dividir a heap ao longo de diferentes regiões da RAM;
■ Ou uma alocação mais personalizada.
Memória
● Sistemas embarcados em tempo real possuem diferentes requisitos de RAM
e tempo, então um algoritmo de alocação de memória só será apropriado
para determinado subconjunto de aplicações;
● Logo, FreeRTOS separa a alocação de memória de suas funcionalidades
core em uma camada portátil para facilitar o desenvolvimentos de diferentes
implementações;
● Quando o Kernel aloca RAM, não usa função malloc() e sim uma função
pvPortMalloc(). Quando libera RAM, chama vPortFree() ao invés de free();
● FreeRTOS oferece diversas implementações de gerenciamento de heap,
possibilidade de utilizar implementação própria e de utilizar duas
implementações diferentes simultaneamente.
Memória
● Implementações inclusas de gerenciamento de heap:
○ heap_1: Mais simples. Não oferece que a memória seja liberada;
○ heap_2: Permite liberar espaço, mas não junta blocos adjacentes livres;
○ heap_3: Encapsula os métodos malloc() e free();
○ heap_4: Junta blocos adjacentes vazios para proteger de fragmentação. Adiciona opção de
colocação em endereço absoluto;
○ heap_5: Parecido com heap_4, mas com possibilidade de dividir a heap ao longo da memória
sem se limitar a espaços adjacentes.
● Observações:
○ heap_1 caiu em desuso desde que o FreeRTOS oferece suporte para alocação estática de
memória;
○ heap_4 é preferível a utilização de heap_2.
Memória
● Memory Protection Unit (MPU):
○ Oferece suporte oficial nas arquiteturas ARMv7-M e ARMv8-M;
○ Benefícios:
■ Aplicações mais robustas e seguras;
■ Permite modo privileged ou unprivileged para tarefas;
■ Restringe acesso a recursos como RAM, código executáveis, periféricos…;
■ Previne do código executar na RAM e, assim protegendo de ataques de buffer overflow
ou de códigos maliciosos dentro da RAM.
○ Custos:
■ Design da aplicação fica mais complexo;
■ As restrições de memória devem ser informadas para o RTOS;
■ A MPU restringe o funcionamento das tasks.
Protocolos
● Esse protocolos fornecem conectividade
para construção de serviços de IoT
baseado em microcontroladores;
● Essas bibliotecas utilizam uma interface
para garantir que não dependam da
camada de transporte;
Protocolos
● MQTT:
○ Message Queue Telemetry Transport;
○ Protocolo de comunicação entre máquinas
utilizando arquitetura publisher/subscriber;
○ Protocolo voltado para dispositivos pequenos e
embarcados;
○ Implementado de maneira leve e simples;
○ Por essa característica é muito utilizado no
contexto de Internet das Coisas;
Protocolos
● HTTP:
○ Hypertext Transfer Protocol;
○ Protocolo comumente utilizado no contexto
web para transferência de dados pela rede;
○ Stateless que executa sobre uma camada
TCP/IP;
○ Otimizado para utilização de baixa memória;
○ Oferece uma API completamente síncrona e
permite aplicações gerenciarem suas co
ocorrências;
○ Oferece API que serializa o cabeçalho da
requisição, manda a requisição e recebe a
resposta
Protocolos
● SNTP:
○ Simple Network Time Protocol;
○ Permite os dispositivos de sincronizar seus clocks com o
temporizador de servidores;
○ Oferece duas camadas de API:
■ A primeira oferece métodos para serializar requisições e
desserializar pacotes de resposta e algumas utilidades;
■ A segunda oferece algumas funcionalidades para gerenciar
as operações na rede como: utilização de UDP, autenticação
de servers, notificar sistema para atualizar o tempo com
informações do servidor, entre outros.
Protocolos
● Outros:
○ USB;
○ I2C;
○ SPI;
○ TCP;
○ UDP;
○ IP.
Qual a diferença entre o Zephyr e o FreeRTOS?
● O Zephyr é 100% mantido pela ● O FreeRTOS está há mais tempo no
comunidade; mercado;
● Atualizações mais frequentes; ● O FreeRTOS fornece uma licença
● Sistemas de build e configuração únicos comercial opcional;
(Cmake e Kconfig); ● Fornece integração direta com a
● Por ter um desenvolvimento voltado à infraestrutura de cloud da Amazon;
segurança e ter uma comunidade muito ● Fornece a opção de migração para o
ativa, tende a ser mais seguro. SafeRTOS.
Referências
Architecture Partners: [Link]
What is FreeRTOS?:
[Link]
Perguntas frequentes sobre o FreeRTOS:
[Link]
FreeRTOS Kernel Developer Docs: [Link]
Application Protocols: [Link]