Quando precisamos de um sistema operacional no design de sistemas embarcados?

Eu escrevi bastante código bare metal para processadores PIC e x86. Alguém pode me dizer como e quando devo precisar de um sistema operacional? Por outro lado, que aplicativo ou situação também pode ser tratada ou sem um sistema operacional?

Minha regra geral é que você deve considerar um sistema operacional se o produto exigir um ou mais dos seguintes itens: uma pilha TCP / IP (ou outra pilha de rede complexa), uma GUI complexa (talvez uma com objetos da GUI, como janelas e eventos) ) ou um sistema de arquivos.

Se você fez alguma codificação bare metal, provavelmente está familiarizado com a arquitetura do programa super-loop . Se os requisitos de firmware do produto são simples o suficiente para serem implementados com um super loop que pode ser mantido (e esperamos que seja um pouco extensível), provavelmente você não precisa de um sistema operacional.

À medida que os requisitos de software aumentam, o super loop fica mais complexo. Quando os requisitos de software são tantos que o super loop se torna muito complexo ou não pode atender aos requisitos em tempo real do sistema, é hora de considerar outra arquitetura.

Uma arquitetura RTOS permite dividir os requisitos de software em tarefas. Se feito corretamente, isso simplifica a implementação de cada tarefa. E com a priorização de tarefas, um RTOS pode facilitar o cumprimento de requisitos em tempo real. Um RTOS não é uma panacéia, no entanto. Um RTOS aumenta a complexidade geral do sistema e abre novos tipos de erros (como deadlocks). Como alternativa ao RTOS, você pode considerar a arquitetura da máquina de estado baseada em eventos (como QP ).

Se o seu produto possui rede, uma GUI complexa e um sistema de arquivos, você deve estar no ponto em que deve considerar os sistemas operacionais com todos os recursos, como VxWorks, Windows ou Linux. Os sistemas operacionais completos incluem drivers para os detalhes de baixo nível e permitem que você se concentre no seu aplicativo.

Realmente depende da sua definição de 'sistema incorporado'. Pode haver quem afirme que, se não for uma programação bare-metal, ela não está incorporada (o que impede sua pergunta), mas eu discordaria disso - eu argumentaria que qualquer sistema projetado para executar apenas uma função, isto é, para executar apenas um 'aplicativo' específico, poderia ser chamado de sistema incorporado.

Dito isso, deve ser bastante fácil imaginar situações que se beneficiariam dos serviços de um sistema operacional completo. Por exemplo, onde trabalho, é bastante comum encontrar pessoas construindo equipamentos de teste em cima de um conjunto de projetos de instrumentação que é executado em cima de janelas. Esses sistemas são configurados para inicializar na configuração da estação de teste e bloquear o uso geral (para impedir a corrupção da estação) e, portanto, são sistemas embarcados.

No entanto, apenas a compra de módulos de E / S prontos para o uso, conectando-os a um PC montado em rack e configurando uma configuração em uma GUI pode não ser qualificada como design de sistema incorporado para alguns. Para uma situação um pouco menos disponível, considere um controlador de processo personalizado com um FPGA, para o qual você deseja fazer um registro de dados sofisticado. Você pode incorporar um sistema de processador de núcleo leve (com um BSP existente) e executar um linux em tempo real para executar uma pilha de rede (para seu log e NTP etc) e fazer tudo o mais na lógica.

Minha regra (muito vaga) é: se você precisar de mais de um segmento de controle (digamos, pelo menos, um dispositivo que envolva um protocolo ou uma máquina de estado e mais alguma coisa a fazer), alguns dos softwares OSish tornarão sua vida mais fácil

Uma pergunta antiga, mas vou comentar de qualquer maneira.

Mesmo que você não tenha pilhas de rede ou similares, no ponto em que você precisa de um agendador de tarefas, pois possui processos suficientes em seu aplicativo incorporado, considere um RTOS. Escrever um simples agendador multitarefa cooperativo baseado em timer não é tão difícil, mas garantir que um processo travado não bloqueie o restante do aplicativo e que isso pode demorar um pouco para ser acertado. Você precisa implementar um sistema prioritário com algum tipo de provisão para interromper os processos na fila se eles não foram concluídos.

O RTOS também fornece itens como proteção de memória e similares, o que facilita muito o rastreamento de algumas gaffes comuns no código C, mas microcontroladores simples simplesmente podem não ser capazes de lidar com a complexa proteção de memória. Por exemplo, o MSP430 permite separar código e dados em alto nível, mas não há controle de acesso à memória granular.

Um sistema operacional realmente preenche a lacuna entre o hardware e o software de aplicativo (através do driver do dispositivo). Em outras palavras, ele fornece uma plataforma de nível relativamente alto para o programador, o que reduz a complexidade do código. Além disso, o sistema operacional fornece plataforma forte e flexível para a execução do aplicativo.