Toda a verdade sobre o RTOS. Artigo 32. Migração do Nucleus SE: recursos e compatibilidade não realizados

O principal requisito para o desenvolvimento do Nucleus SE era um alto grau de compatibilidade com o principal produto Mentor RTOS - Nucleus RTOS. O Nucleus SE suporta uma certa parte da funcionalidade do Nucleus RTOS, discutida várias vezes em artigos anteriores, mas neste artigo tentarei coletar todas as principais diferenças em um único local. Este artigo foi elaborado como uma referência rápida para todos que mudarem de um núcleo para outro ou estão no processo de escolher um kernel para um projeto específico.



Além da funcionalidade limitada ou simplificada, em comparação com o Nucleus RTOS, o Nucleus SE também foi projetado com ênfase na maximização da utilização da memória com amplas opções de personalização. Uma parte importante dessa abordagem é a escalabilidade. Muitos recursos da funcionalidade do kernel podem ser ativados ou desativados conforme necessário. Obviamente, desabilitar a funcionalidade em uma implementação específica aumenta sua incompatibilidade com o Nucleus RTOS.

No Nucleus RTOS, um sistema pode ser criado com um número indefinido de objetos do kernel, a única limitação aqui é a quantidade de recursos disponíveis (ou seja, memória). O núcleo SE tem um limite de dezesseis objetos de cada tipo; o sistema pode ter de uma a dezesseis tarefas e de zero a dezesseis objetos de cada tipo (caixas de correio, filas etc.). Apesar de esse limite poder ser aumentado, será necessário um esforço considerável, pois o Nucleus SE faz amplo uso da capacidade de armazenar o índice de um objeto em uma mordidela (quatro bits). Além disso, com mais de dezesseis tarefas, é provável que o Agendador de prioridades se torne muito ineficiente. Um aplicativo cuja funcionalidade sofre seriamente com essas limitações não é adequado para o Nucleus SE; nesse caso, o Nucleus RTOS é uma opção muito mais adequada.

Planejador

Como todos os núcleos modernos em tempo real, o Nucleus RTOS possui um agendador muito flexível que fornece vários níveis de prioridade (com um número indeterminado de tarefas em cada nível de prioridade), além da capacidade de selecionar o agendador Round Robin e Time Slice. O Nucleus SE é muito mais simples e oferece quatro agendadores que devem ser selecionados no tempo de compilação: Executar até a conclusão, Round Robin, Time Slice e Priority. É impossível combinar agendadores diferentes (ou seja, não há agendador composto). Por exemplo, você não pode selecionar uma combinação de agendadores de Time Slice e Priority. Além disso, o planejador de prioridade permite atribuir apenas uma tarefa a cada nível de prioridade, ou seja, existem tantos níveis de prioridade quanto tarefas. A prioridade da tarefa é definida durante a compilação e não muda mais (como o intervalo de tempo, se o planejador Time Slice estiver selecionado).

Chamadas de API

Interface de programação de aplicativos (API) - a "face" visível do sistema operacional. Não é de surpreender que seja aqui que as diferenças entre o Nucleus RTOS e o Nucleus SE sejam mais óbvias.

A API Nucleus SE é diferente da API Nucleus RTOS. No entanto, a API Nucleus SE foi cuidadosamente projetada para que possa ser transferida para o fragmento da API Nucleus RTOS. Os titulares do Nucleus RTOS licenciado podem obter um "shell" (um arquivo de cabeçalho contendo #define macros) que executará a transferência quase diretamente.

Pelo fato de a API Nucleus SE poder ser chamada de "subconjunto" da API Nucleus RTOS, segue-se que algumas chamadas de API estão ausentes. Isso é verdade e é um resultado inevitável dos critérios de desenvolvimento do Nucleus SE. Algumas chamadas de API simplesmente não fazem sentido, pois estão associadas a funcionalidades inexistentes; outras foram excluídas para simplificar a implementação de alguns objetos do kernel. Tudo isso é descrito em detalhes nas seções a seguir deste artigo.

Funções comuns da API

O Nucleus RTOS possui funções de API comuns a vários tipos diferentes de objetos do kernel, ou mesmo a todos os tipos de objetos. Alguns deles também foram implementados no Nucleus SE, um bom exemplo dessa função é redefinido. Outras funções não são aplicáveis ​​à implementação de objetos do kernel no Nucleus SE.

Criar e excluir

No Nucleus RTOS, todos os objetos do kernel são dinâmicos; eles são criados e excluídos conforme necessário. Portanto, existem chamadas de API para isso. No Nucleus SE, todos os objetos são estáticos (eles são criados durante a montagem), portanto, essas chamadas de API não são necessárias.

Retornando ponteiros para objetos

O identificador principal (descritor) dos objetos do kernel no Nucleus RTOS é um ponteiro para o bloco de controle do objeto, que é atribuído quando o objeto é criado. Portanto, há também um conjunto de chamadas de API que retornam uma lista de ponteiros para objetos de cada tipo. Como o Nucleus SE usa um índice simples para identificar objetos do kernel, essas chamadas não são necessárias. Um programa pode pesquisar o kernel para descobrir quantas instâncias de objetos de um tipo específico estão configuradas (usando uma chamada como NUSE_Mailbox_Count () ); se esse valor for n , os índices de objetos desse tipo terão valores de zero a n-1 .

Transmissão de dados

Para alguns tipos de objetos do kernel do Nucleus RTOS (como caixas de correio, filas e pipes), uma sobrecarga de API é fornecida para converter os dados. Isso permite que você envie dados para todas as tarefas que esperam dados do objeto. Essa possibilidade foi excluída do Nucleus SE para simplificação, pois o acesso aos dados de tais objetos é sempre realizado no contexto de uma tarefa específica, que libera o objeto. Portanto, para implementar a conversão, seria necessário um mecanismo de sinalização adicional.

Objetos de API de recursos exclusivos

Muitos objetos do kernel possuem chamadas de API que são exclusivas para um tipo específico de objeto e diferem no Nucleus RTOS e no Nucleus SE.

As tarefas

Como o Nucleus RTOS Scheduler é significativamente mais complexo que o Nucleus SE, algumas funções da API não são necessárias:

• Alterar a posição de uma interrupção de tarefa - não suportada no Nucleus SE.
• Alterar prioridade da tarefa - No Nucleus SE, a prioridade da tarefa é atribuída durante a configuração e não pode ser alterada.
• Alterando o intervalo de tempo da tarefa - no Nucleus SE, o valor do intervalo de tempo é comum a todas as tarefas e é definido durante a configuração.
• Conclusão da tarefa - O Nucleus SE não suporta o estado da tarefa "concluída".

Memória dinâmica

Como tudo é criado estaticamente no Nucleus SE, a memória dinâmica não é suportada (e não é necessária). Portanto, as funções de API associadas também são desnecessárias.

Signals

O núcleo RTOS suporta manipuladores de sinal, programas que são executados (como manipuladores de interrupção) quando os sinais da tarefa são alterados. Esse recurso foi excluído do Nucleus SE; portanto, chamadas de API para gerenciar os sinais e criar um manipulador de sinais não são necessárias.

Interrupções

O Nucleus SE usa a abordagem de interrupção sem interrupções, simplesmente fornecendo a capacidade de fazer algumas chamadas de API a partir do manipulador de interrupções. Portanto, algumas chamadas da API do Nucleus RTOS que especificam como o kernel deve lidar com interrupções não são suportadas.

Diagnóstico

O Nucleus SE possui serviços de diagnóstico muito modestos, seguindo seu estilo de desenvolvimento "restrito", limitando-se à verificação (opcional) de parâmetros e à saída do código da versão do produto. Portanto, não há suporte para chamadas à API do Nucleus RTOS relacionadas ao log do histórico e à confirmação de erros.

Drivers

O Nucleus RTOS possui uma estrutura formal de driver bem definida e várias funções de API relacionadas ao gerenciamento de drivers. O núcleo SE não possui essa estrutura; portanto, as chamadas de API correspondentes não são necessárias.

Funcionalidade de chamada da API

Alguns aspectos da funcionalidade do Nucleus SE, implementados de forma simplificada, levam a diferenças em relação ao Nucleus RTOS. Alguns deles afetam como as chamadas de API são usadas e os serviços disponíveis.

Timeouts

Ao usar o Nucleus RTOS, geralmente há situações em que uma chamada de API pode pausar uma tarefa aguardando para acessar um recurso: a tarefa está bloqueada. Essa suspensão de uma tarefa pode estar implícita (ou seja, até que o recurso fique disponível) ou um valor de tempo limite pode ser especificado. O Núcleo SE fornece o bloqueio por chamadas da API como uma opção, no entanto, somente a suspensão implícita pode ser usada (ou seja, uma chamada pode usar apenas NUSE_SUSPEND ou NUSE_NO_SUSPEND , e não um valor de tempo limite). Esse recurso é bastante simples de adicionar ao Nucleus SE.

Procedimento de suspensão

Quando vários tipos de objetos são criados no Nucleus RTOS, uma ordem de suspensão pode ser atribuída. Essa é uma sequência na qual várias tarefas bloqueadas serão retomadas à medida que os recursos estiverem disponíveis. Duas opções estão disponíveis: FIFO, primeiro a entrar, primeiro a sair (primeiro a entrar, primeiro a sair), em que as tarefas são retomadas na mesma ordem em que são bloqueadas; ou por prioridade, na qual a tarefa com a prioridade mais alta sempre recomeça primeiro. O Nucleus SE não oferece essa opção. Implementa apenas a ordem de prioridade. De fato, é mais correto dizer a ordem pelo índice de tarefas, pois a ordem de suspensão pode ser aplicada não apenas ao usar o planejador Priority, mas também ao usar os planejadores Round Robin e Time Slice.

Funcionalidade de recurso exclusivo

Em alguns casos, foram necessárias alterações funcionais relacionadas a certos tipos de objetos.

Manipuladores de sinal
Como mencionado acima, a implementação do sinal no Nucleus SE não suporta procedimentos de processamento de sinal.

Configurações do timer do aplicativo
O temporizador tem uma duração inicial / duração inicial de operação e uma duração de reinicialização e, opcionalmente, pode executar uma função definida pelo usuário na conclusão. Essa funcionalidade é suportada no Nucleus RTOS e no Nucleus SE. No entanto, o Nucleus SE, diferentemente do Nucleus RTOS, não permite alterar os parâmetros descritos acima ao chamar a função API para redefinir. Além disso, no Nucleus SE, todo o suporte para procedimentos de conclusão do timer é opcional.

Sinalizadores de evento
O núcleo RTOS tem uma opção para "absorver" sinalizadores de eventos. Isso significa que os sinalizadores que correspondem aos critérios definidos pela tarefa são redefinidos. Essa funcionalidade não é suportada no Nucleus SE, pois a capacidade de pesquisar os critérios de várias tarefas aumenta significativamente a complexidade do sistema.

Tamanhos de dados

Dois critérios de desenvolvimento para o Nucleus SE: manter a simplicidade e minimizar o uso da memória, levaram a algumas diferenças nos tamanhos dos elementos de dados em comparação com o Nucleus RTOS. Vale ressaltar que o Nucleus RTOS geralmente usa dados não assinados , o que provavelmente é de 32 bits. enquanto o Nucleus SE usa tipos de dados simplificados como U32 , U16 , U8 e assim por diante. ( Nota do tradutor: na minha opinião, o autor é adequado para sistemas de 8 bits. Nos sistemas modernos, os registros ainda são de 32 bits; portanto, cortar a parte antiga consome memória para ciclos de código e relógio para sua execução, e os dados são iguais a 32 bits quando armazenados em memória, caso contrário, o desempenho do sistema diminuirá; portanto, essa abordagem não gera um ganho para os sistemas modernos, e uma perda devido às instruções adicionadas pelo compilador que cortam a parte antiga pode muito bem. ).

Caixas de correio

No Nucleus RTOS, uma caixa de correio armazena uma mensagem que consiste em quatro elementos de dados não assinados. No Nucleus SE, uma caixa de correio armazena um item de dados ADDR . Na minha opinião, as caixas de correio geralmente são usadas para transferir um endereço (indicando dados específicos) de uma tarefa para outra.

Filas

No Nucleus RTOS, uma fila processa mensagens de um ou mais elementos de dados não assinados . A fila também pode ser configurada para manipular mensagens de tamanho variável. No Nucleus SE, uma fila processa mensagens que consistem em um único item de dados ADDR . Na minha opinião, as filas são usadas de maneira semelhante às caixas de correio. Além disso, no Nucleus RTOS, o tamanho total da fila (ou seja, o número total de elementos não assinados que podem ser colocados na fila) é especificado como um valor não assinado. No núcleo SE, esse valor é do tipo U8 . Portanto, uma fila pode conter menos dados.

Canais de dados

No Nucleus RTOS, um canal processa mensagens de um ou mais bytes; O canal também pode ser configurado para lidar com mensagens de tamanho variável. No Nucleus SE, um canal processa mensagens que consistem em um ou mais elementos de dados do tipo U8 . O tamanho da mensagem é definido durante a configuração de cada canal. Além disso, no Nucleus RTOS, o tamanho total do canal (ou seja, o número total de bytes que podem ser colocados em um canal) é especificado como um valor não cantado . No Nucleus SE, esse valor é do tipo U8 e representa o número de mensagens (na chamada da API NUSE_Pipe_Information () ). Consequentemente, um canal pode conter menos dados.

Grupos de Sinalizadores de Eventos

No Nucleus RTOS, um grupo de sinalizadores de eventos contém 32 sinalizadores; no núcleo SE, seu número é reduzido para oito. Esse tamanho foi escolhido porque os prováveis ​​processadores Nucleus SE de destino podem processar dados de 8 bits com eficiência. Ao mesmo tempo, não será difícil alterar o número de sinalizadores nos grupos de eventos processados ​​pelo Nucleus SE.

Signals

No Nucleus RTOS, cada tarefa possui um conjunto de 32 sinalizadores de sinal. No Nucleus SE, os sinais são opcionais e cada tarefa possui um conjunto de 8 sinalizadores. Esse tamanho foi escolhido porque os prováveis ​​processadores Nucleus SE de destino podem processar com eficiência dados de 8 bits. Ao mesmo tempo, alterar o número de sinalizadores nos conjuntos de sinalizadores processados ​​pelo Nucleus SE não será difícil.

Seções de memória

No núcleo RTOS, o número e o tamanho das partições não são assinados . No Núcleo SE, o número de partições é um parâmetro do tipo U8 e o tamanho da partição é U16 . Isso leva a algumas restrições de tamanho de partição e pool.

Temporizadores

No Nucleus RTOS, os cronômetros (cronômetros de aplicativo e cronômetros de suspensão de tarefas) trabalham com valores não assinados . No núcleo SE, eles são do tipo U16 . Esse tipo foi escolhido porque os prováveis ​​processadores Nucleus SE de destino podem processar dados de 16 bits com eficiência (e oito bits claramente não são suficientes para usar um timer). Ao mesmo tempo, alterar o tamanho dos temporizadores no Nucleus SE não será difícil.

O artigo a seguir examinará como o Nucleus SE pode ser usado em um projeto de software incorporado.

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 , e-mail: colin_walls@mentor.com.