Benefícios do RTOS vs Bare Metal para programação MCU?

Observe: Esta pergunta menciona especificamente dois RTOS, mas é mais genérica e provavelmente pode ser respondida por qualquer pessoa que tenha escrito código C para RTOS incorporados antes e que o software foi executado diretamente nas MCUs.

Estou interessado em aprender mais sobre RTOS incorporados e escrever aplicativos para eles. Atualmente, estou analisando a Embox e o RIOT porque eles são de código aberto, modernos, ativos e parecem ter uma excelente documentação. Meu objetivo tem duas fases: a fase 1 é descobrir como compilar e atualizar esses sistemas operacionais para um MCU (provavelmente AVR ou ARM). A Fase 2 é então escrever um programa C simples (basicamente um daemon sem cabeça), que evoluiria ao longo do tempo como um "aplicativo de hobby". Em seguida, colocava em flash / implantava esse programa no mesmo MCU, implantando com êxito um appstack que consistia em Embox / RIOT e meu aplicativo residia em cima dele.

Antes de percorrer qualquer estrada que acabe levando a becos sem saída, deparei-me com este artigo que explica muito bem por que os aplicativos em tempo real, escritos em C / assembler e enviados para MCUs, realmente não precisam de RTOSs debaixo deles. .

Então agora estou realmente confuso e estou questionando parte do meu entendimento fundamental da teoria da computação. Acho que estou tentando decidir se deve ou não usar o Embox / RIOT em primeiro lugar:

• Mantenha o curso e vá com uma "pilha de aplicativos" no MCU do aplicativo OS +; ou
• Preste atenção ao aviso do artigo e vá com um MCU executando meu aplicativo "bare metal"

Obviamente, o primeiro é mais trabalhoso e, portanto, é melhor haver uma boa razão / recompensa para seguir esse caminho. Então, pergunto: quais são os reais benefícios que esses (e similares) RTOS incorporados oferecem aos desenvolvedores de aplicativos MCU / C? De quais recursos específicos meu aplicativo C pode se beneficiar (talvez não reinventando a roda?) Usando um RTOS? O que se perde com o abandono do RTOS e o desnudamento?

Estou solicitando exemplos concretos aqui, não o hype da mídia que você recebe quando acessa a entrada da Wikipedia para RTOSes ;-)

Os programas de microcontrolador consistem em várias tarefas . Digamos que você queira montar um telescópio controlado por computador. As tarefas seriam:

• Recupere um novo byte de entrada do buffer serial USB.
• Verifique se recebemos um comando completo.
• Nesse caso, execute esse comando.
• Leia os sensores para a posição atual do telescópio.
• Defina a saída adequada para controlar o próximo passo dos motores.

Esse é um conjunto de tarefas bastante típico para algo para o qual você usaria um microcontrolador e é muito fácil de gerenciar com um loop infinito, como:

while(TRUE) {
  uint8_t input = readUsbBuffer();
  parseCommand(input);
  readSensors();
  setMotors();
}

Se você continuar adicionando e adicionando recursos, poderá eventualmente encontrar problemas comuns para os quais deseja criar abstrações, como:

• Seu buffer está transbordando, portanto, você deseja garantir que a tarefa possa interromper outras tarefas antes de transbordar.
• Você quer economizar bateria dormindo quando nada é necessário.
• Você quer ter certeza de que todas as tarefas tenham uma chance justa. Se readSensorsdemorar demais, você poderá interrompê-lo e voltar mais tarde.
• Você deseja redefinir apenas uma tarefa sem afetar outras.
• Você deseja que um vazamento de memória ou outro bug em uma tarefa não execute as outras tarefas.
• Você deseja poder atribuir diferentes tarefas a diferentes prioridades.
• Você deseja poder colocar uma tarefa não confiável na caixa de areia.
• Você deseja executar tarefas em taxas diferentes. Talvez seus sensores possam ser lidos apenas 10 vezes por segundo, mas você deseja executar uma etapa do motor 100 vezes por segundo.

Um ou dois desses itens podem ser manipulados manualmente com relativa facilidade. Se você tem o suficiente desses tipos de problemas com frequência suficiente para começar a generalizá-los em bibliotecas, basicamente reinventou um RTOS. Se o gerenciamento de tarefas do seu programa for suficientemente complexo, mesmo se você não usar um RTOS pronto para uso, acabará reinventando um mal.

No entanto, na minha experiência, a linha em que você deseja um RTOS está muito próxima da linha em que você deseja um microprocessador em vez de um microcontrolador. Se você espera que seu firmware fique tão complexo, geralmente é melhor seguir a rota do microprocessador desde o início.

Eu escrevi minha própria biblioteca multi-threading cooperativa para o ARM Cortex-M0.

Mal havia algumas páginas de código, e a primeira versão não demorou mais de um dia para escrever e depurar.

A grande vantagem do roll-your-own é que você conhece o código e pode portá-lo para chips aos quais o RTOS pode não suportar. Além disso, você gasta menos tempo pensando em perguntas como "ele falhará? Eu tento usar os recursos A e B simultaneamente?" Desde que você escreveu o código, você sabe a resposta.

A segmentação é a principal coisa que você obtém de um RTOS, e acaba não sendo uma coisa tão importante para se implementar. É raro você precisar de muitos recursos de um RTOS. Mas se você definir seus requisitos e isso acontecer, use um RTOS.