Toda a verdade sobre o RTOS de Colin Walls

Toda a verdade sobre o RTOS. Artigo 1.

Sistemas operacionais em tempo real: Introdução

Esta série de artigos é dedicada a um estudo completo de todos os aspectos dos sistemas operacionais em tempo real (RTOS). Os artigos são direcionados a desenvolvedores que estão curiosos para aprender como o RTOS funciona e como usá-los. O ponto de partida será a discussão sobre sistemas em tempo real em geral, e depois falaremos sobre como o RTOS pode simplificar sua implementação e tornar o código resultante mais confiável.

Examinando o RTOS, veremos como o agendador de tarefas funciona. Graças ao multithreading, parece que a CPU realiza várias operações ao mesmo tempo. Isso não é mágico, uma compreensão dos princípios do agendador de tarefas está disponível mesmo para um engenheiro de software inexperiente. Falaremos sobre outros objetos do RTOS: sobre a interação entre tarefas e sincronização, sobre o modo em tempo real, sobre gerenciamento de memória, etc., tudo será descrito com precisão e suportado por exemplos de código.

Para o desenvolvedor, um aspecto fundamental do RTOS é a API, um conjunto de chamadas de procedimento que fornecem acesso à funcionalidade do RTOS. A série apresentará artigos sobre o funcionamento da API, quais padrões estão disponíveis e como passar de uma API para outra.

Abaixo está uma lista de tópicos que consideraremos em um futuro próximo:

• Estrutura do programa e tempo real
• Sistemas operacionais em tempo real
• Tarefas e planejamento
• Interação e sincronização de tarefas
• Outros serviços do sistema operacional
• Núcleo SE
• Planejador
• As tarefas
• Seções de memória
• Signals
• Grupos de Sinalizadores de Eventos
• Semáforos
• Caixas de correio
• Filas
• Canais
• Hora do sistema
• Temporizadores de software
• Interrupções
• Diagnóstico e verificação de erros
• Inicialização e Lançamento

A série de artigos não está vinculada a nenhum sistema operacional específico em tempo real; a maior parte do material é aplicável às opções publicamente disponíveis para a implementação do RTOS. Segundo o autor, o uso de um sistema operacional comercial pronto com o suporte existente é a maneira mais confiável e produtiva de trabalhar. Um dos artigos será dedicado a uma discussão detalhada sobre o tópico “faça x compre” e outras metodologias para escolher um RTOS.

No entanto, para explicar o design interno do RTOS, exemplos do código real do produto, Nucleus SE, são usados.

Fonte: http://www.embedded.com/design/operating-systems/4442729/Introducing--RTOS-Revealed

Toda a verdade sobre o RTOS. Artigo 2

RTOS: estrutura e modo em tempo real
Estrutura do programa e tempo real

Esta série de artigos é sobre sistemas embarcados e, em particular, sobre software em execução em sistemas embarcados. Vamos começar com a definição. O que é um sistema incorporado? Em 1986, quando escrevi o primeiro livro sobre esse assunto, esse termo não existia. Os conceitos de "sistema dedicado" ou "microssistema" foram usados, mas, é claro, não refletiam toda a essência. Alguns anos depois, a palavra “embutido” entrou em uso e todos os especialistas começaram a usá-lo ativamente.

Voltar para a definição de um sistema incorporado. Em uma tentativa de explicar aos amigos e familiares no que estou trabalhando, vim com a seguinte explicação: um sistema incorporado é qualquer dispositivo eletrônico que tenha um processador, mas que geralmente não é aceito como computador.

O sistema operacional (SO) está sempre no computador; em sistemas embarcados modernos, apenas alguns tipos de SO são usados. Apesar de o uso do kernel prevalecer em sistemas de alto desempenho (32 e 64 bits), é possível se beneficiar do uso em dispositivos de baixo consumo de energia. O foco desses artigos é em sistemas operacionais, em geral e com implementação específica.

Por que usar o sistema operacional?

Vamos ver por que os sistemas operacionais são usados ​​em princípio. Existem muitas explicações, algumas delas dependem do fator humano e das características técnicas. Eu me lembro da história. Em um de nossos escritórios, havia uma cozinha onde você podia fazer café. Na porta havia uma placa com a inscrição: "Por favor, não feche a porta". Por baixo, alguém escreveu: "Por que não?", Ao qual outra pessoa respondeu: "Porque". Uma versão muito reduzida da frase "porque estamos dizendo para você fazer exatamente isso". Pelas mesmas razões, os sistemas operacionais são usados ​​em alguns sistemas, simplesmente porque precisa ser feito.

Outra explicação é o uso de aplicativos de desktop. Onde você começa se escreve software para PC ou Mac? Você liga o computador, inicia o Windows / Linux ou macOS e inicia a programação. Ter um sistema operacional é uma condição específica e fornece vários serviços úteis. É improvável que você decida começar do zero ao programar o bare metal. Portanto, não surpreende que um engenheiro com experiência em escrever software, mas para quem o firmware seja novo, conte com a presença de um sistema operacional no sistema que ele desenvolve.

Vale a pena notar um aspecto principal do SO da área de trabalho que os usuários conhecem é a interface do usuário (UI). Pergunte a alguém o que é o Windows e eles responderão que são janelas, menus, caixas de diálogo, ícones, mas o sistema de arquivos, a comunicação entre programas e a capacidade de interagir com outros sistemas são pouco mencionados. Essa é a principal diferença entre a área de trabalho e o sistema incorporado: o último pode não ter uma interface com o usuário e, se for, é bastante simples. Esta é a primeira de muitas diferenças importantes:

• Um sistema incorporado normalmente executa um único aplicativo de software, desde a inicialização até a desativação.
• Os sistemas embarcados possuem recursos limitados. A quantidade de memória pode ser bastante grande, mas não o fato de poder ser expandida; O processador possui energia limitada.
• Muitos aplicativos incorporados funcionam em tempo real. Mais sobre isso no artigo abaixo.
• As ferramentas de desenvolvimento de firmware são especializadas e executadas no computador host (como um PC), e não no sistema de destino.
• A atualização do firmware é um processo complexo. Apesar das oportunidades que aparecem devido a dispositivos conectados, as atualizações de firmware durante a operação ainda não são a norma (em contraste com as atualizações regulares e as correções (patches) usadas para o software de desktop).

Antes de considerarmos como estruturar os aplicativos incorporados, entenderemos os conceitos usados ​​nos computadores para executar programas usando o sistema operacional.

Em primeiro lugar, há uma execução de programas no estilo DOS, quando os programas são executados alternadamente.



Cada programa é iniciado, implementado e finalizado. Usamos, digamos, o programa 1, depois o programa 2, e talvez faça uma pausa, volte para o programa 3 e depois volte para o programa 2. O segundo uso do programa 2 começa de novo: o lançamento não começa de onde paramos isso (exceto nos casos em que o aplicativo em si não oferece essa oportunidade).

Após o DOS, as coisas ficaram um pouco complicadas, pois o Windows se tornou comum. Executar programas no estilo Windows significa executar vários programas no modo multithread.



Nesse modo, parece que os programas estão sendo executados ao mesmo tempo e o Windows está controlando essa ilusão. Primeiro, o programa 1 inicia, depois, ao mesmo tempo, o programa 2 inicia, depois o programa 3. O programa 2 termina, os programas 1 e 3 ainda estão em execução. O programa 3 termina, apenas o programa 1. Mais tarde, o programa 2 continua e o programa 1 termina, apenas o programa 2. Esse é um curso realista de eventos quando o Windows é usado por um usuário comum. O sistema operacional aloca recursos para que todos os programas usem corretamente o processador. Ele também fornece comunicação fácil entre programas (por exemplo, área de transferência) e controla a interface do usuário.

Alguns dispositivos portáteis exigem mais flexibilidade do que o DOS pode oferecer, mas, com recursos limitados, são necessárias despesas gerais inferiores às do Windows. Como resultado, temos a execução de programas no estilo do iOS, a saber:



Os programas são iniciados um de cada vez, mas seu status é salvo automaticamente para que você possa continuar do mesmo local ao fechar. Por exemplo, o programa 1 é iniciado, faz uma pausa para usar o programa 2 e, por exemplo, o dispositivo é desligado por um tempo. Ao retomar, o programa 3 é carregado (o estado do programa 2 foi salvo automaticamente) e, em seguida, o usuário retorna ao programa 2, continuando a trabalhar nele. Entendo que o modelo de execução de um aplicativo iOS é muito mais complicado do que o descrito acima; no entanto, essa descrição é apenas um breve resumo da percepção inicial do usuário.

A maioria dos aplicativos internos não corresponde a nenhum dos modelos acima. Como regra, o dispositivo inicia o programa na inicialização e continua a trabalhar apenas com este software por tempo indeterminado. A estrutura desse código deve ser cuidadosamente pensada.

Modelos de firmware

Os sistemas de desktop são quase todos iguais. Do ponto de vista do programa de aplicação, todos os computadores pessoais com Windows são idênticos. Os sistemas embarcados são únicos: cada um é diferente dos outros. As diferenças podem ser técnicas: tipo de processador, tamanho da memória, número de dispositivos periféricos. Os aspectos prioritários das aplicações também podem diferir em velocidade, consumo de energia, segurança e confiabilidade. Pode haver diferenças comerciais que afetam os preços: volumes de produção e a escolha entre hardware personalizado ou padrão.

Essas diferenças são importantes para desenvolvedores incorporados. Por exemplo, a escolha de ferramentas de desenvolvimento (compiladores, depuradores, etc.) depende do tipo de processador. Muitos fatores influenciam a escolha do sistema operacional ou mesmo a decisão de aplicá-lo em princípio. A estrutura do software (modelo de software) deve ser cuidadosamente selecionada para cada aplicativo incorporado individual.

Dependendo dos requisitos do aplicativo, o software incorporado pode ter várias estruturas de diferentes níveis de complexidade, por exemplo:



A forma mais simples é uma estrutura fechada na qual a mesma sequência de ações é repetida. Se o aplicativo é simples o suficiente para poder ser implementado dessa maneira, é ideal: o código simples é confiável e compreensível. No entanto, essa estrutura é extremamente sensível à parte do código que pode levar muito tempo do processador, ou seja, alguns comandos são executados por tanto tempo que atrasam a execução de outras tarefas do aplicativo. Além disso, esse modelo não é bem dimensionado: melhorar o código pode ser um problema, porque os complementos podem afetar o desempenho do código antigo.

Se algo mais complicado for necessário, você pode tentar colocar uma parte não crítica do código no loop principal e outra sensível ao tempo no manipulador de interrupções (Interrupt Service Routines, ISR). As ações do manipulador de interrupções são basicamente bastante curtas, executando apenas tarefas críticas e marcando seções do loop principal para concluir o trabalho o mais rápido possível. Podem surgir dificuldades quando é necessário distribuir o trabalho entre o loop principal e o manipulador de interrupções (assim como entre vários desenvolvedores).

Para obter a máxima flexibilidade do aplicativo, será necessário dividi-lo em vários programas separados e relativamente independentes (vamos chamá-los de tarefas ou threads), que serão executados no modo multithread. Pequenos manipuladores de interrupção também podem ser incluídos no sistema, mas notificam principalmente tarefas ou acionam uma ação. Para conseguir isso, você precisa de um sistema operacional, ou pelo menos um kernel. O uso do multithreading não apenas fornece uma distribuição flexível de funcionalidade no software, mas também facilita a distribuição do trabalho entre os desenvolvedores.

O que é tempo real?

Escrevi anteriormente que muitos aplicativos incorporados funcionam em tempo real. Nesse contexto, é habitual falar sobre sistemas operacionais em tempo real, e não sobre um sistema operacional simples. Vamos definir a terminologia.

“Um sistema operacional em tempo real é um sistema no qual a correção dos cálculos depende não apenas da correção lógica dos cálculos, mas também do tempo em que o resultado será alcançado.

Se as restrições de tempo do sistema não forem atendidas, acredita-se que ocorreu uma falha no sistema. "

Uma característica importante desse sistema é sua previsibilidade ou, como costumam dizer, determinismo.

Um sistema operacional em tempo real não é necessariamente muito rápido; "tempo real" nem sempre significa "tempo muito rápido". Isso significa que qualquer ação necessária será concluída em tempo hábil. Ou seja, rápido o suficiente, mas ao mesmo tempo não muito rápido (ou seja, lento o suficiente).

O RTOS (quando usado corretamente) fornece controle muito preciso sobre a distribuição do tempo do processador para tarefas e, portanto, torna os aplicativos completamente determinísticos. A única coisa que pode arruinar essa imagem são interrupções. Existem RTOSs que controlam totalmente as interrupções. O trabalho deles é gerenciar o serviço de interrupção como parte do agendador de tarefas. Apesar de isso levar a um comportamento previsível, esse mecanismo é bastante complicado e contém altos custos indiretos.

A maioria dos RTOS simplesmente permite que o manipulador de interrupções "roube" o tempo de uma tarefa que estava sendo executada no momento da interrupção. Isso, por sua vez, força o programador a escrever o código do manipulador de interrupções o mais curto possível. Como resultado, temos um erro permitido em tempo real. A única dificuldade é fazer chamadas para os serviços RTOS como parte de uma tarefa do manipulador. Algumas chamadas podem ser bastante inofensivas, enquanto outras causarão uma troca de contexto ao retornar de uma interrupção. Esta situação deve ser especialmente abordada, o que é possível com a ajuda de vários RTOS.

Fonte: https://www.embedded.com/design/operating-systems/4442900/Program-structure-and-real-time

Quando trabalhamos em nosso próprio sistema operacional OSRV MAX em tempo real (artigos publicados anteriormente sobre ele) , nossa equipe encontrou o blog de Colin Walls, especialista em microeletrônica e firmware da Mentor Graphics. Os artigos pareciam interessantes, os traduziam por si mesmos, mas, para não "escrever para a mesa", eles decidiram publicar. Espero que eles também sejam úteis para você. Nesse caso, planejamos publicar todos os artigos traduzidos da série.

Sobre o autor: Colin Walls trabalha na indústria eletrônica há mais de trinta anos, dedicando a maior parte de seu tempo ao firmware. Ele agora é engenheiro de firmware na Mentor Embedded (uma divisão da Mentor Graphics). Colin Walls frequentemente fala em conferências e seminários, autor de vários artigos técnicos e dois livros sobre firmware. Vive no Reino Unido. Blog profissional de Colin: http://blogs.mentor.com/colinwalls , e-mail: colin_walls@mentor.com

O artigo 3 é publicado aqui.