Toda a verdade sobre o RTOS. Artigo 6. Outros serviços RTOS

Nos artigos anteriores, discutimos a funcionalidade do kernel em termos de tarefas executadas e a interação entre eles. Neste artigo, examinamos o que mais o kernel pode fazer, o que se manifesta amplamente em várias outras chamadas de API disponíveis. Também responderemos à pergunta: o que transforma o kernel em um sistema operacional?

Artigos anteriores da série:
Artigo 5. Interação e sincronização de tarefas
Artigo 4. Tarefas, alternância de contexto e interrupções
Artigo # 3 Tarefas e planejamento
Artigo 2. RTOS: estrutura e modo em tempo real
Artigo 1. RTOS: introdução.

Gerenciamento de tarefas

Além do agendamento de tarefas e da interação entre eles, o RTOS incluirá funcionalidade (chamadas de API) para gerenciar tarefas de várias maneiras. Vamos considerar algumas possibilidades.

Criar e excluir tarefas

No RTOS "dinâmico", há chamadas de função que permitem criar tarefas (e outros objetos RTOS) quando necessário. Essas chamadas incluem uma ampla variedade de parâmetros que definem a tarefa, por exemplo, ponto de entrada, tamanho da pilha e prioridade. A chamada da API de remoção de tarefa correspondente permite liberar recursos após a conclusão da tarefa.

No RTOS "estático", os parâmetros de definição da tarefa são configurados em um tipo de arquivo de configuração durante a montagem.

Pausar e retomar uma tarefa

Como vimos, a maioria dos RTOS tem o conceito de um estado de tarefas "suspensas". Isso pode ser alcançado de várias maneiras. Uma delas é uma chamada explícita para a função da API Suspend Task. Pode ser causado por si ou por outra tarefa. A chamada "Continuar tarefa" correspondente permite que a tarefa fique na fila novamente para o planejamento.

Estado de suspensão da tarefa

Para um sistema em tempo real, o controle de tempo é um requisito importante e pode assumir várias formas. Uma visão simples é a capacidade da tarefa "adormecer", ou seja, a tarefa é suspensa por um determinado período de tempo. Quando o tempo acaba, a tarefa "acorda" e fica novamente na fila para o planejamento. Uma chamada de API geralmente estará disponível para esse fim. Obviamente, essa funcionalidade depende da disponibilidade do cronômetro.

Isenção

Ao usar o agendador Round Robin ("carrossel"), uma tarefa pode se recusar a controlar o processador para a próxima tarefa na cadeia. Para fazer isso, a função API "Liberar tarefa" estará disponível. A tarefa não é suspensa, estará disponível para planejamento quando chegar a sua vez. Ao usar o agendador de fatia de tempo, é possível que uma tarefa possa liberar parte de seu intervalo de tempo se não tiver um trabalho importante a ser feito imediatamente. A liberação de uma tarefa não tem significado lógico ao executar os planejadores Executar até a conclusão ou Prioridade.

Conclusão da tarefa

Em um artigo anterior, descobrimos que, além dos estados "Pronto" ou "Suspenso", o RTOS pode oferecer suporte a outros estados de tarefas. A tarefa pode ser "Concluída", o que significa que sua função principal acabou de sair: nenhuma chamada especial à API é necessária. Uma tarefa pode ser "Finalizada", o que significa que ela não está disponível para planejamento e deve ser redefinida para se tornar disponível novamente para inicialização, consulte "Redefinindo uma tarefa" abaixo. Isso requer uma chamada de API especial. A disponibilidade desses estados de tarefas adicionais, a terminologia usada e suas definições exatas serão diferentes, dependendo do RTOS.

Redefinição de tarefa

Muitos RTOS oferecem uma chamada para a função API "Redefinir tarefa", que permite retornar a tarefa ao seu estado original. Ela pode estar em um estado suspenso e exigir que a função "Reiniciar tarefa" seja executada para fazer fila para o planejamento.

Tarefas prioritárias etc.

Em um RTOS "dinâmico", as chamadas de API podem estar disponíveis para configurar vários parâmetros de tarefa em tempo de execução. Os exemplos incluem prioridade e duração do intervalo de tempo.

Informações do sistema

No RTOS, haverá várias chamadas de API para fornecer ao sistema informações sobre a tarefa, incluindo:
Informações sobre as tarefas . Quantas tarefas existem no sistema, sua configuração e status atual.
Informações sobre outros objetos do kernel. Quantos objetos de cada tipo estão no sistema, sua configuração e informações sobre o estado atual. Por exemplo:

• Qual é a capacidade atual da fila? Posso adicionar mais mensagens?
• quantas tarefas estão suspensas em uma caixa de correio específica?

Informações sobre a versão RTOS . Uma chamada de API pode fornecer dados semelhantes.

Alocação de memória

Em muitos aplicativos, é importante que o programa possa capturar dinamicamente alguma memória quando necessário e liberá-lo quando não for mais necessário. A mesma coisa acontece no firmware. No entanto, as abordagens convencionais são propensas a problemas improváveis ​​ou inconvenientes em aplicativos de desktop, mas podem ser desastrosas para um sistema incorporado. No entanto, existem maneiras de implementar esses serviços, mesmo em um RTOS estático.

Problemas com as funções malloc () e free ()

Em um programa C de desktop, uma função pode chamar malloc () , indicando quanta memória é necessária, e retornar um ponteiro para a área de armazenamento. Usando a memória, ela pode ser liberada chamando free () . A memória é alocada de uma área chamada heap. O problema dessa abordagem é que, com uma sequência descoordenada de chamadas para essas funções, a área de heap pode facilmente se fragmentar e, em seguida, a alocação de memória falhará, mesmo que haja memória suficiente disponível, porque áreas adjacentes não são grandes o suficiente. Alguns sistemas (como Java e Visual Basic) usam esquemas sofisticados de "coleta de lixo" para desfragmentar. O problema é que esses esquemas podem levar a atrasos imprevisíveis significativos no tempo de execução e à necessidade de usar ponteiros indiretos (que não funcionam em C).

Se malloc () e free () foram implementados de maneira reentrante (geralmente não) e usados ​​pelas tarefas RTOS, a fragmentação ocorrerá muito rapidamente e uma falha no sistema será quase inevitável. No C ++, existem operadores new e delete que geralmente executam as mesmas funções que malloc () e free (). Eles estão sujeitos às mesmas limitações e problemas.

Seções de memória

Para fornecer um sistema em tempo real com memória dinamicamente acessível, pode ser usada uma abordagem em bloco para o gerenciamento de memória. Esses blocos são comumente chamados de "partições"; partições podem ser alocadas no "conjunto de partições".

O conjunto de partições contém um certo número de blocos, cada um com o mesmo tamanho. O número e o tamanho dos blocos em uma partição são determinados quando o conjunto de partições é criado. Isso pode ser dinâmico se o próprio sistema permitir, ou estaticamente durante a montagem. Normalmente, um aplicativo pode incluir vários conjuntos de partições que oferecem blocos de tamanhos diferentes.

Se uma tarefa precisar de memória, ela chama uma API que solicita um bloco de um pool específico. Se esta chamada for bem-sucedida, a tarefa receberá um ponteiro para o bloco selecionado. Se a chamada falhar porque Se não houver partições disponíveis no pool indicado, a tarefa poderá receber uma resposta de erro. Como alternativa, a tarefa pode ser bloqueada (suspensa) até que outra tarefa libere o bloco na seção.

Normalmente, uma tarefa simplesmente passa um ponteiro para um bloco de memória em qualquer código que use o bloco. Isso leva a um problema quando o bloco não é mais necessário. Se o código possui apenas um ponteiro para um bloco, como ele pode informar o RTOS por meio de uma chamada de API, de qual pool de partições ele deseja liberar memória? A resposta é que a maioria dos RTOS suporta dados adicionais em um bloco dedicado (geralmente um deslocamento negativo do ponteiro) que fornece as informações necessárias. Portanto, para chamar a API para liberar um bloco, apenas seu endereço é necessário.

O artigo a seguir terá mais informações sobre partições de memória.

Tempo

A funcionalidade associada ao uso e controle do tempo provavelmente estará disponível no sistema operacional em tempo real. As oportunidades variam de acordo com o RTOS, mas consideraremos as disponíveis ao público. De qualquer forma, o timer em tempo real é um elemento indispensável para o funcionamento de qualquer um desses serviços.

Hora do sistema

A hora simples do sistema, ou "relógio de ponto", está quase sempre disponível. Este é apenas um contador (geralmente 32 bits), que é incrementado usando a rotina de serviço de interrupção em tempo real e pode ser configurado e lido através de chamadas de API.

Tempo limite da chamada de serviço

Normalmente, um RTOS permite bloquear chamadas de API, ou seja, a tarefa de chamada é suspensa (bloqueada) até que o serviço solicitado seja fornecido. Geralmente esse bloqueio é vago, mas alguns RTOS oferecem um tempo limite durante o qual a chamada retorna quando o tempo limite expira, se o serviço continuar indisponível. Os tempos limite de chamada da API não são suportados por todos os RTOS.

Estado de suspensão da tarefa

Normalmente, as tarefas têm a capacidade de fazer uma pausa por um período fixo de tempo. Isso foi discutido anteriormente na seção Gerenciamento de tarefas.

Temporizadores de software

Para que as tarefas do programa executem funções de contagem de tempo, a maioria dos RTOS oferece objetos de timer. Esses são cronômetros independentes atualizados pelo manipulador de interrupção do cronômetro em tempo real, que pode ser controlado por chamadas de API. Essas chamadas configuram, monitoram e monitoram a operação do timer. Como regra, eles podem ser configurados para uma única atuação ou reinicialização automática. Uma rotina de expiração também é geralmente suportada, uma função que é executada toda vez que um timer conclui um ciclo. O próximo artigo fornecerá mais informações sobre temporizadores de software e uma descrição de sua implementação.

Interrupções, drivers e E / S

A extensão em que os RTOSs estão associados a interrupções e E / S é muito diferente. Da mesma forma, alguns RTOSs têm uma estrutura muito clara para drivers de dispositivo, o que pode adicionar problemas ao escolher um produto específico.

Interrupções

As interrupções apresentam um problema para o RTOS por dois motivos.

• Sem nenhuma precaução, o manipulador de interrupção (ISR) "roubará" o tempo do processador, interrompendo assim o comportamento do RTOS em tempo real.
• Se o ISR fizer chamadas de API que afetam o agendamento de tarefas, isso deve ser monitorado e o RTOS deve poder executar seu algoritmo de agendamento.

Um exemplo dessa chamada de API é o procedimento para ativar uma tarefa com uma prioridade mais alta do que a que foi iniciada quando a interrupção ocorreu.

Alguns RTOSs controlam totalmente todas as interrupções. Uma série de chamadas de API está disponível para "registrar" programas ISR. Essa abordagem permite que o planejador identifique quando as interrupções estão ativadas e facilita o uso da maioria das chamadas de API do ISR.

Por exemplo, o Nucleus RTOS implementa o conceito de manipuladores de interrupção de “baixa prioridade” e “alta prioridade”, que fornecem gerenciamento confiável de interrupções sem sobrecarga desnecessária (ou seja, um aumento no atraso de interrupção).

Outros RTOS podem usar o modo automático de interrupção, o que oferece aos desenvolvedores mais opções para garantir que os manipuladores de interrupção funcionem corretamente. Como regra, são fornecidos prefixo ISR (prólogo) e sufixo (epílogo) adicionais para proteger as chamadas de API feitas nele.
O Nucleus SE usa uma rotina de interrupção leve, que será descrita em um artigo futuro.

Drivers

A maioria dos RTOSs determina a estrutura do driver do dispositivo. Os detalhes podem variar dependendo do RTOS, mas o driver geralmente consiste em dois componentes em interação: código incorporado (chamadas de API) e ISR. Normalmente, outras chamadas de API estarão disponíveis para gerenciar e registrar drivers.

Entrada / saída

Atualmente, a maioria dos RTOS no mercado não se preocupa com entrada / saída de nível superior, mas alguns deles definem um fluxo de entrada / saída, que basicamente estabelece uma conexão entre os drivers de dispositivo correspondentes e as funções padrão da linguagem C, como printf ().
Historicamente, o RTOS frequentemente suportava o "console", a interface do usuário para o RTOS através de um canal serial. Isso foi usado principalmente para diagnóstico e depuração. O uso de depuradores modernos que oferecem suporte a aplicativos de depuração com RTOS elimina a necessidade de tais objetos.

Diagnóstico

Normalmente, o RTOS requer desempenho máximo com espaço mínimo de memória. Portanto, a verificação de integridade não é uma alta prioridade. Com a ajuda de modernas tecnologias de depuração que levam em conta os recursos do RTOS, a maioria das verificações pode ser realizada fora do próprio RTOS.

Verificando parâmetros de chamada da API

As chamadas de API podem ter muitos parâmetros complexos. Isso pode causar erros. Muitos RTOS fornecem uma verificação dos parâmetros de tempo de execução com o retorno de um código de erro no caso de um parâmetro incorreto. Como isso requer código adicional e as próprias verificações afetam negativamente o desempenho, é melhor verificar os parâmetros durante a montagem ou configuração.

Verificação de pilha

Para a maioria dos tipos de agendador (exceto Executar até a conclusão), cada tarefa possui sua própria pilha, cujo tamanho é determinado individualmente. Em alguns RTOSs, o kernel possui uma pilha separada; em outros, a pilha de tarefas é "emprestada" durante uma chamada de API. Obviamente, a integridade da pilha é importante para a confiabilidade geral do sistema. Portanto, os RTOSs geralmente oferecem ferramentas para verificar a integridade da pilha no tempo de execução. Existem várias opções:

• Uma chamada de API que retorna a quantidade de espaço de pilha para a tarefa atual ou especificada.
• Os parâmetros delimitadores da pilha. Eles recebem um valor único (geralmente ímpar e diferente de zero), que é verificado periodicamente quanto à reescrita.

Diagnóstico de aplicativos

Apesar do fato de que essa função não é diretamente suportada no RTOS, uma tarefa de aplicativo pode ser alocada para verificar a integridade de todo o sistema. Essa tarefa pode ser responsável por redefinir o timer do watchdog. Uma tarefa pode receber dados de entrada periódicos (por exemplo, parâmetros de sinal) de cada tarefa crítica. A redefinição do timer do watchdog (que impedirá a reinicialização do sistema) será executada somente após a chegada dos dados de todas as tarefas.

Serviços que não são do kernel

O RTOS é mais do que apenas o núcleo em que estamos focados até agora. Esse sistema operacional de desktop é significativamente diferente do RTOS incorporado. Normalmente, em um sistema operacional de desktop, todos os componentes adicionais são agrupados ou podem ser instalados (todos os PCs de mesa têm uma interface gráfica do usuário e apenas alguns deles não têm acesso à rede). O PC de mesa não possui limites reais de recursos: sempre há memória livre, espaço no disco rígido e recursos da CPU não utilizados. Em um mundo de sistemas embarcados com recursos limitados, podem ser necessários componentes adicionais, como placas de vídeo, componentes de rede e sistemas de arquivos, mas eles devem ser desconectáveis ​​e escalonáveis ​​para minimizar o consumo de memória.

Recursos de rede

A maioria dos sistemas embarcados está de alguma forma relacionada a redes. Assim, espera-se que haja um interesse significativo em soluções de rede para sistemas embarcados, devido ao qual existe um grande número de produtos no mercado.

O TCP / IP é um protocolo padrão amplamente utilizado e é a escolha óbvia para muitos aplicativos. Normalmente, o TCP / IP é usado para o protocolo Ethernet (IEEE802.3), que fornece uma velocidade média de 10 Mb / s. Hoje, 100 Mb / s são bastante comuns, e na abordagem 1 Gb / s. Além disso, o TCP / IP pode ser usado para outros protocolos. Por exemplo, o PPP (Protocolo Ponto a Ponto) é uma implementação TCP / IP para transferência de dados seriais que foi adaptada para conexões de Internet de banda larga.

Até recentemente, a versão v4 do protocolo IP (IPv4) era usada. No entanto, torna-se obsoleto à medida que os endereços gratuitos acabam. A solução é o IPv6, aumentando significativamente o número de endereços possíveis e fornecendo ferramentas mais eficientes para manutenção e segurança. O IPv6 está amplamente disponível e é usado em equipamentos de vários países, bem como em sistemas militares em todo o mundo.
Uma alternativa é o UDP (User Datagram Protocol). Este protocolo é usado para desempenho máximo. O UDP não fornece a mesma confiabilidade e consistência que o TCP, mas é leve e altamente eficiente.

USB é o Universal Serial Bus, amplamente utilizado em dispositivos para conexão com computadores desktop. Ele fornece uma interface plug-and-play muito fácil de usar que oculta software bastante sofisticado.Um dispositivo incorporado que deve ser conectado a um PC deve ser implementado como uma função USB, que requer um conjunto específico de componentes de software. Se o dispositivo precisar gerenciar outros dispositivos conectados via USB (como um PC comum), ele precisará de um conjunto de softwares do tipo host.

O IEEE1394 , outro padrão para interfaces seriais usado para transferir rapidamente grandes quantidades de dados entre dispositivos (por exemplo, para transferir dados de vídeo), também é conhecido como FireWire e i.Link.

Protocolos sem fio - a conveniência e a prevalência de várias tecnologias sem fio entre os consumidores levaram a uma alta demanda por recursos sem fio em dispositivos embarcados. O Wi-Fi (conjunto de padrões IEEE802.11) fornece um conjunto completo de recursos de rede, permitindo a implementação de topologias de ponto e de infraestrutura a uma distância suficiente. O interesse na segurança de dados nessas redes está aumentando, o que significa que isso deve afetar o software. Outras tecnologias de rádio, principalmente Bluetooth e ZigBee, fornecem comunicações sem fio ponto a ponto de curto alcance.

Verificação de protocolo

Como as oportunidades de rede estão em alta demanda, há muitos fornecedores oferecendo suas soluções. Os clientes enfrentam o desafio de verificar a qualidade dos produtos disponíveis. Ao contrário do kernel RTOS, uma verificação completa da funcionalidade e desempenho da pilha de protocolos não é uma tarefa fácil. Felizmente, kits de ferramentas estão disponíveis para verificação de protocolos (embora a um preço significativo), e um comprador em potencial pode descobrir com o fornecedor qual conjunto ele usou para verificar.

Gráficos

Uma interface gráfica está se tornando mais comum entre dispositivos incorporados. Pode ser um LCD monocromático pequeno e muito simples (como em telefones antigos, MP3 players, alarmes etc.). Por outro lado, um receptor de televisão digital pode ter sua própria tela HDTV de alta resolução. Essa tela requer suporte de software totalmente integrado ao kernel RTOS.
Como a tela geralmente possui algum tipo de dispositivo de entrada, o suporte a esses dispositivos geralmente é incluído no pacote gráfico. Esse pacote pode suportar dispositivos apontadores (por exemplo, mouse), telas sensíveis ao toque, teclados e teclados completos.
Os gráficos podem ser usados ​​de várias maneiras. Ele pode simplesmente fornecer informações (por exemplo, como um placar eletrônico). Ou a exibição pode fazer parte de uma interface gráfica do usuário, juntamente com menus, janelas, ícones e elementos semelhantes. De qualquer forma, é necessário um conjunto de software bastante específico, e o pacote de gráficos fornecido com o RTOS deve fornecer a flexibilidade necessária sem aumentar significativamente a quantidade de memória usada.

Sistemas de arquivos

Quando um aplicativo incorporado precisa armazenar e processar quantidades significativas de dados, é óbvio que faz sentido organizar esses dados em algum tipo de sistema de arquivos. Os dados podem estar na RAM, na memória flash embutida, em uma unidade flash USB, em um disco rígido comum ou em um disco óptico (CD-ROM ou DVD-ROM). Novamente, essa oportunidade deve ter suporte de software totalmente integrado ao RTOS. O sistema de arquivos deve ser cuidadosamente projetado para atender aos requisitos reentrantes de um sistema multitarefa.

A conformidade é especialmente importante para sistemas de arquivos. Por exemplo, o uso do formato de disco compatível com MS-DOS permite que os desenvolvedores usem a arquitetura bem estabelecida e oferece troca de dados completa com sistemas de desktop.