No desenvolvimento de sistemas incorporados, uma das decisões técnicas mais críticas surge logo na fase de planeamento: o firmware deve ser executado diretamente no hardware ou deve depender de um sistema operativo em tempo real (RTOS)?
A escolha entre firmware bare-metal e um sistema operativo como o FreeRTOS, o Zephyr ou outros depende de vários factores técnicos, funcionais e operacionais. Esta decisão não deve ser baseada em preferências ou hábitos do programador, mas sim numa análise objetiva dos requisitos do projeto.
Na Detus, avaliamos cuidadosamente esta decisão com cada cliente, tendo em conta aspectos como a previsibilidade, a complexidade do sistema, os requisitos de escalabilidade e o nível de robustez esperado do produto final.
O que significa trabalhar sem um sistema operativo
O firmware bare-metal é um código que é executado diretamente no microcontrolador, sem qualquer camada de abstração ou programação automática de tarefas. Cabe ao programador gerir manualmente as interrupções, o tempo, a coordenação das tarefas e o estado geral do sistema.
Este modelo é adequado para sistemas simples que são altamente previsíveis e com recursos limitados. Proporciona um controlo total sobre o hardware, uma latência mínima e, normalmente, resulta numa base de código mais pequena. No entanto, exige uma gestão rigorosa da concorrência, das prioridades e da escalabilidade, o que pode tornar o desenvolvimento e a manutenção mais complexos à medida que o sistema evolui.
O que oferece um sistema operativo em tempo real
Um sistema operativo em tempo real (RTOS) permite a execução simultânea de múltiplas tarefas através de mecanismos como semáforos, filas de espera, temporizadores e eventos sincronizados. Introduz também uma estrutura modular no firmware, o que facilita a manutenção do código e a expansão do sistema ao longo do tempo.
A utilização de um RTOS é especialmente vantajosa quando:
-
Existem várias tarefas com diferentes prioridades a decorrer em simultâneo
-
O sistema requer uma temporização precisa ou ciclos periódicos fiáveis
-
Há necessidade de registo de eventos, de diagnóstico ou de registo persistente
-
O firmware é modular, com funções separadas e independentes
-
Espera-se que o produto final evolua e receba actualizações funcionais após o lançamento
Critérios objectivos para apoiar a decisão
Critério | Firmware bare-metal | Sistema operativo em tempo real |
---|---|---|
Complexidade do sistema | Pouco ou muito previsível | Médio a elevado |
Número de tarefas simultâneas | 1 a 3 tarefas principais | 4 ou mais tarefas independentes |
Manutenção futura | Código estático | Código modular e escalável |
Tolerância a falhas | Depende da implementação manual | Ferramentas incorporadas para deteção e tratamento |
Tempo de desenvolvimento | Mais rápido em sistemas simples | Mais eficiente em sistemas complexos |
Exemplo prático
Um sensor ambiental autónomo que lê valores de trinta em trinta segundos e envia os dados para um sistema central pode ser implementado de forma simples e eficaz com firmware bare-metal. O seu comportamento previsível e a ausência de múltiplas tarefas concorrentes tornam desnecessária a utilização de um sistema operativo.
Por outro lado, um dispositivo médico com vários sensores, botões de controlo, registo de eventos e uma interface de comunicação com funções de diagnóstico beneficiaria significativamente de um sistema operativo. Neste caso, a gestão de tarefas, a separação funcional e a capacidade de resposta a eventos simultâneos fazem de um RTOS a escolha certa.
Considerações sobre o desempenho
É comum assumir-se que o firmware bare-metal tem sempre um melhor desempenho. Em sistemas muito simples com recursos extremamente limitados, isto pode ser efetivamente verdade. No entanto, um RTOS bem configurado, com uma gestão adequada das prioridades e uma utilização eficiente dos seus mecanismos de programação, pode, em muitos casos, ser mais eficiente na gestão dos ciclos de espera, na comunicação assíncrona e na resposta rápida a eventos externos.
Além disso, a utilização de um sistema operativo permite práticas de desenvolvimento mais robustas, como testes modulares, actualizações de firmware seguras e uma abordagem mais estruturada à gestão do ciclo de vida do produto.
Conclusão
Não existe uma resposta universal. A decisão entre firmware bare-metal e um sistema operativo deve basear-se na arquitetura, no tipo de produto, na sua evolução prevista e no nível de estabilidade exigido.
Na Detus, avaliamos esta decisão juntamente com a seleção do microcontrolador, as considerações relativas ao consumo de energia e a lógica de funcionamento do sistema.