Muitos desenvolvedores começaram suas jornadas de desenvolvimento embarcado escrevendo firmware que rodava diretamente no bare metal (hardware puro) de um microcontrolador. Era direto e eficiente, pelo menos em termos de memória. Para aplicações construídas com um único propósito, como acender um LED, isso era bom. Na verdade, escrever firmware foi uma mudança considerável em relação à construção de sistemas apenas com hardware (por exemplo, incorporando um temporizador 555). Os desenvolvedores agora podiam mudar o código e modificar comportamentos com relativa facilidade, em vez de refazer a fiação de um circuito.
Hoje, sistemas embarcados estão em toda parte, de smartwatches e unidades de controle eletrônico (ECUs) de veículos a geladeiras inteligentes e dispositivos médicos. A crescente complexidade das aplicações embarcadas modernas levou à adoção generalizada de sistemas operacionais em tempo real (RTOSes). Neste artigo, definiremos RTOSes e exploraremos alguns dos recursos do popular RTOS Zephyr.
Um RTOS em Poucas Palavras
Um RTOS (Sistema Operacional em Tempo Real) é um software especializado que gerencia recursos de hardware e permite que múltiplas tarefas sejam executadas concorrentemente de forma previsível e oportuna. Diferente de sistemas operacionais de propósito geral, como Windows ou Linux, um RTOS prioriza o comportamento determinístico, o que significa que ele garante que certas operações serão concluídas dentro de um período de tempo definido. No entanto, “período de tempo” neste sentido não significa “sondar este sensor toda quinta-feira às 3 p.m.”. Em vez disso, significa algo mais parecido com “sondar este sensor a cada 500ms.”
RTOSes são construídos para atender às necessidades específicas de sistemas que exigem comportamento de temporização determinístico e previsível. Na maioria dos sistemas embarcados em tempo real (por exemplo, dispositivos médicos, aviônicos, ECUs automotivas), as aplicações frequentemente precisam que as tarefas sejam executadas dentro de janelas de tempo precisas. Assim, os RTOSes são projetados para garantir garantias em tempo real (ou seja, tarefas que cumprem prazos de temporização rigorosos) e baixa latência (ou seja, resposta rápida a interrupções e eventos).
Embora seja possível escrever firmware que possa fazer isso sem usar um RTOS, os desenvolvedores estariam reinventando a roda e construindo um subconjunto do que um RTOS moderno oferece. A sobrecarga de um RTOS será tipicamente superada pela utilidade que ele proporciona, exceto para os projetos mais restritos em recursos, como aqueles que utilizam microcontroladores AVR ou PIC de 8 bits.
Essencialmente, um RTOS é ideal em sistemas que exigem temporização precisa (por exemplo, controle de motor, processamento de áudio) ou que lidam com múltiplas tarefas ao mesmo tempo (por exemplo, um dispositivo que usa simultaneamente conectividade Bluetooth®, uma interface de usuário e dados de sensores). Um RTOS faz sentido para desenvolvedores que desejam código modular e reutilizável que seja fácil de manter à medida que o projeto cresce, e quando o gerenciamento eficiente de energia é crítico para maximizar a vida útil da bateria.
Firmware bare-metal é o melhor para aplicações simples, como piscar um LED ou ler um sensor. Também é ideal para trabalhar com memória extremamente limitada ou para ter controle completo sobre a temporização de hardware de baixo nível.
Anatomia de um RTOS
Sistemas operacionais de tempo real (RTOSes) são projetados para lidar com tarefas com temporização previsível e comportamento determinístico, cruciais para sistemas embarcados, robótica, software automotivo e controles industriais. Embora as implementações possam variar em complexidade, a maioria dos RTOSes modernos é construída em torno de um conjunto padrão de elementos fundamentais, incluindo kernels, tarefas e threads, escalonadores, comunicação entre processos (IPC), gerenciamento de memória e timers. Cada um desempenha um papel vital ao permitir a execução concorrente, a responsividade sensível ao tempo e a confiabilidade do sistema.
Kernel
No coração de qualquer RTOS está o kernel (núcleo), um core leve e determinístico projetado para garantir que as tarefas críticas sejam executadas com atraso mínimo e previsível. O kernel gerencia as operações essenciais de baixo nível do sistema, incluindo:
- Escalonar e despachar tarefas para determinar quando e qual tarefa executar.
- Lidar com interrupções para responder imediatamente a eventos externos.
- Realizar a troca de contexto (context switching) para alternar entre tarefas de forma eficiente.
- Fornecer serviços de sincronização e comunicação para que as tarefas possam coordenar e compartilhar dados com segurança.
Tarefas/Threads
Tarefas (também conhecidas como threads) são as unidades básicas de execução em um RTOS. Cada tarefa representa um fluxo de controle independente com sua própria pilha para gerenciar dados locais, um nível de prioridade definido que determina quando ela é executada e um estado claro — como pronto (ready), em execução (running), bloqueado (blocked) ou suspenso (suspended) — que muda conforme o RTOS gerencia a execução. As tarefas podem ser preemptivas, permitindo que tarefas de prioridade mais alta interrompam as de prioridade mais baixa, ou cooperativas, onde as tarefas voluntariamente cedem o controle. Em ambos os casos, o RTOS garante que a tarefa de prioridade mais alta que estiver pronta sempre receba tempo de CPU.
Escalonador
O escalonador (scheduler) atua como o cérebro do RTOS, determinando qual tarefa será executada em um determinado momento. Os escalonadores geralmente são baseados em prioridade e podem ser preemptivos, cooperativos ou um híbrido de ambas as abordagens. Muitos RTOSes permitem a configuração de algoritmos específicos, como escalonamento rate monotonic para tarefas periódicas, escalonamento round-robin para compartilhamento de tempo ou earliest-deadline-first para cargas de trabalho orientadas por prazo. Independentemente do método, o objetivo principal do escalonador é o determinismo – garantir que a execução da tarefa ocorra dentro de limites de tempo conhecidos e garantidos, o que é vital para o desempenho em tempo real.
Comunicação Entre Processos (IPC)
Para manter múltiplas tarefas rodando de forma suave e sincronizada, um RTOS fornece mecanismos de IPC que permitem o compartilhamento seguro de dados e a coordenação. Essas ferramentas ajudam a prevenir condições de corrida (race conditions) e deadlocks (impasses), garantindo que as tarefas interajam de forma confiável. Os recursos comuns de IPC incluem semáforos para sinalização e exclusão mútua (binários ou contadores), mutexes que oferecem exclusão mútua e herança de prioridade para evitar a inversão de prioridade, filas de mensagens (message queues) que atuam como buffers FIFO (first-in–first-out) para enviar dados estruturados entre tarefas, e event flags que usam máscaras de bits leves para sincronização eficiente.
Gerenciamento de Memória
Um RTOS deve gerenciar a memória de uma forma que equilibre flexibilidade com previsibilidade. Alguns sistemas dependem de alocação de memória estática, fixa no tempo de compilação, para manter um comportamento consistente, enquanto outros também suportam alocação dinâmica que usa um heap ou memory pools (reservas de memória) quando a flexibilidade em tempo de execução é necessária. Muitos RTOSes incluem recursos de segurança, como detecção de stack overflow (estouro de pilha) para capturar erros precocemente, particionamento de memória para manter diferentes regiões separadas, alocadores thread-safe para evitar conflitos e proteção de memória com suporte de hardware, se houver uma unidade de gerenciamento de memória (MMU). Alguns sistemas de tempo real evitam totalmente a memória dinâmica para garantir que o timing permaneça previsível e a fragmentação não ocorra.
Timers
O timing preciso é crítico em aplicações de tempo real, e um RTOS geralmente fornece timers de software e integração com timers de hardware para tornar isso possível. Os timers permitem que as tarefas sejam executadas em intervalos exatos ou após durações especificadas. Eles são essenciais para atrasar tarefas, implementar timeouts para lidar com atrasos inesperados e acionar operações periódicas que devem ser executadas em um cronograma estrito para manter o desempenho em tempo real.
Visão Geral do Zephyr
Um RTOS que tem experimentado um rápido crescimento nos últimos anos é o Zephyr. Na verdade, a Arduino escolheu o Zephyr, de código aberto, rico em recursos e modular, para seus núcleos de hardware de próxima geração, após o fim do suporte ao Mbed.
O Zephyr começou em 2016 como um spin-off do microrkernel Virtuoso Nano. Foi inicialmente desenvolvido pela Wind River Systems, a mesma empresa por trás do VxWorks, um dos RTOSes comerciais mais estabelecidos. O objetivo declarado do Zephyr é fornecer um RTOS neutro em relação a fornecedores, de código aberto e com foco em segurança para Internet das Coisas (IoT) e dispositivos embarcados.
A arquitetura do Zephyr é construída em torno de um design de microrkernel preemptivo e baseado em prioridade. O kernel modular é configurável no tempo de compilação, o que mantém a pegada mínima. Isso permite que os desenvolvedores usem o Zephyr para tudo, desde pequenos MCUs de 8 bits até processadores embarcados de 64 bits.
O Zephyr usa o sistema Kconfig (do kernel Linux) e o sistema de build CMake, permitindo que os desenvolvedores configurem todo o sistema operacional para um caso de uso ou placa específica. O kernel, drivers, pilhas e middleware são divididos em componentes que os desenvolvedores podem habilitar e desabilitar, selecionando apenas os módulos necessários, como rede e gerenciamento de energia.
Até o momento, o Zephyr suporta mais de 800 placas de fabricantes como Nordic Semiconductor, NXP, STMicroelectronics, Texas Instruments, Intel®, Microchip Technology e SiFive (RISC-V).
O Zephyr inclui suporte integrado para opções de conectividade essenciais, como Bluetooth Low Energy, Ethernet, Thread, CAN e Wi-Fi®, para que os desenvolvedores embarcados possam gastar menos tempo escrevendo drivers e mais tempo construindo suas aplicações. O RTOS fornece segurança através de bibliotecas de criptografia leves e integradas, como TinyCrypt e mbedTLS. Para sistemas automotivos e industriais críticos para a segurança, as certificações do Zephyr, como ISO 26262 e IEC 61508, podem ajudar os projetistas a atender a rigorosos padrões regulatórios. O Zephyr também fornece drivers para LCDs, OLEDs, painéis de toque e telas e-ink, e funciona perfeitamente com a Light and Versatile Graphics Library (LVGL) para projetar interfaces gráficas de usuário (GUIs).
O ecossistema de desenvolvimento Zephyr também é sólido e bem-arredondado. Em seu núcleo está o West, uma ferramenta de linha de comando versátil que agrupa comandos CMake, Git e de flashing ou depuração em uma única interface. O Zephyr SDK vem com toolchains pré-construídas, QEMU para testes virtualizados e outras ferramentas de desenvolvimento que ajudam os desenvolvedores a começar rapidamente. O Zephyr se integra bem com ambientes populares como Visual Studio Code, SEGGER Embedded Studio e fluxos de trabalho tradicionais de linha de comando, dando aos desenvolvedores flexibilidade na forma como trabalham. Para depuração, os desenvolvedores têm uma variedade de opções à sua disposição, incluindo GDB, OpenOCD, J-Link e pyOCD.
Conclusão
RTOSes são ferramentas poderosas que ajudam os desenvolvedores embarcados a atender aos exigentes requisitos das aplicações modernas, onde precisão, confiabilidade e escalabilidade são inegociáveis. O Zephyr, com sua arquitetura modular, ecossistema rico e forte suporte da indústria, representa uma escolha atraente para projetos que variam desde dispositivos IoT de automação residencial até sistemas automotivos críticos para a segurança. À medida que os sistemas embarcados continuam a evoluir em complexidade, alavancar um RTOS como o Zephyr permite que os desenvolvedores se concentrem na inovação em vez de reinventar a roda. Seja construindo a próxima geração de dispositivos vestíveis ou controladores industriais, o Zephyr fornece a flexibilidade e a confiança para dar vida aos projetos.
Referências
- [1] https://zephyrproject.org/
Artigo escrito por Michael Parks e publicado no blog da Mouser Electronics: From Bare Metal to Zephyr: How RTOSes Power Embedded Systems
Traduzido pela Equipe Embarcados. Visite a página da Mouser Electronics no Embarcados








