Real

Quando você precisa usar um sistema operacional em tempo real (RTOS) para um projeto incorporado? O que isso traz para a mesa e quais são os custos? Felizmente existem definições técnicas rigorosas, que também podem ajudar a descobrir se um RTOS é a escolha certa para um projeto.

A parte “tempo real” do nome cobre nomeadamente a premissa básica de um RTOS: a garantia de que certos tipos de operações serão concluídas dentro de um intervalo de tempo determinístico predefinido. Dentro do “tempo real” encontramos categorias distintas: tempo real duro, firme e suave, com penalidades cada vez menos severas por falta de prazo. Como exemplo de um cenário difícil em tempo real, imagine um sistema onde o controlador incorporado tem que responder aos dados recebidos do sensor dentro de um intervalo de tempo específico. Se a consequência do não cumprimento desse prazo for a quebra de componentes posteriores do sistema, figurativa ou literalmente, o prazo será difícil.

Em comparação, o tempo real suave seria o tipo de operação em que seria ótimo se o controlador respondesse dentro desse intervalo de tempo, mas se demorasse um pouco mais, tudo bem também. Alguns sistemas operacionais são capazes de trabalhar em tempo real, enquanto outros não. Isso é principalmente um fator de seu design fundamental, especialmente do agendador.

Neste artigo, daremos uma olhada em vários sistemas operacionais para ver onde eles se enquadram nessas definições e quando você deseja usá-los em um projeto.

Diferentes sistemas operacionais incorporados abordam diferentes tipos de sistemas e possuem diferentes conjuntos de recursos. O mais minimalista dos RTOSes populares é provavelmente o FreeRTOS, que fornece um agendador e com ele primitivos multithreading, incluindo threads, mutexes, semáforos e métodos de alocação de heap seguros para threads. Dependendo das necessidades do projeto, você pode escolher entre vários métodos de alocação dinâmica, bem como permitir apenas a alocação estática.

No outro extremo da escala, encontramos RTOSes como VxWorks, QNX e Linux com patches de agendador em tempo real aplicados. Geralmente são sistemas operacionais certificados ou compatíveis com POSIX, que oferecem a conveniência de desenvolver para uma plataforma altamente compatível com plataformas de desktop regulares, ao mesmo tempo que oferecem algum grau de garantia de desempenho em tempo real, cortesia de seu modelo de agendamento.

Novamente, um RTOS é apenas um RTOS se o escalonador vier com uma garantia de um certo nível de determinismo ao alternar tarefas.

Mesmo fora do domínio dos sistemas operacionais, o desempenho dos processadores em tempo real pode diferir significativamente. Isso se torna especialmente aparente quando se olha para microcontroladores e o número de ciclos necessários para que uma interrupção seja processada. Para os populares MCUs Cortex-M, por exemplo, a latência de interrupção varia de 12 ciclos (M3, M4, M7) a 23+ (M1), na melhor das hipóteses. Divida pela velocidade do processador e você terá cerca de um quarto de microssegundo.

Em comparação, quando olhamos para a gama 8051 de MCUs da Microchip, podemos ver no 'Manual de Hardware dos Microcontroladores Atmel 8051' na seção 2.16.3 ('Tempo de Resposta') que dependendo da configuração da interrupção, a latência da interrupção pode estar em qualquer lugar de 3 a 8 ciclos. Nas plataformas x86 a história é mais complicada novamente, devido à natureza um tanto complicada dos IRQs x86. Novamente, alguma fração de microssegundo.

Essa latência impõe um limite absoluto ao melhor desempenho em tempo real que um RTOS pode alcançar, embora devido à sobrecarga da execução de um agendador, um RTOS não chegue nem perto desse limite. É por isso que, para obter o melhor desempenho em tempo real da categoria, uma abordagem determinística de loop de pesquisa único com rotinas de tratamento de interrupção rápidas para eventos recebidos é de longe a mais determinística.

Se a interrupção, ou outra mudança de contexto, custar ciclos, a execução mais rápida do processador subjacente também poderá obviamente reduzir a latência, mas traz outras compensações, entre as quais a maior utilização de energia e maiores requisitos de resfriamento.

Como demonstra o FreeRTOS, o ponto principal de adicionar um sistema operacional é adicionar suporte multitarefa (e multithreading). Isso significa um módulo agendador que pode usar algum tipo de mecanismo de agendamento para dividir o tempo do processador em 'fatias' nas quais diferentes tarefas ou threads podem estar ativas. Embora o agendador multitarefa mais fácil seja o de estilo cooperativo, onde cada thread cede voluntariamente para permitir que outros threads façam o que querem, isso tem a desvantagem distinta de cada thread ter o poder de arruinar tudo para outros threads.