RTOS para sistemas embarcados


57

Eu já vi muitos artigos que me dizem que eu deveria usar o RTOS para gerenciamento de tempo e gerenciamento de recursos. Meu tempo não permitiu minha própria pesquisa, por isso venho pedir conselhos à chiphacker.

Eu uso microcontroladores de baixo recurso (MSP430, PIC) e estava procurando por RTOSs que eu possa usar.

Ao ponto:

  1. Custo de recurso do sistema
  2. Vantagens do sistema
  3. Desvantagens do sistema
  4. Truques de implementação
  5. Situações em que o RTOS deve / não deve ser usado.

Eu não uso sistemas como o arduino, os projetos com os quais trabalho não podem suportar o custo desse sistema.


2
Estou confuso sobre o motivo pelo qual isso recebeu um voto negativo. Se o eleitor puder me dar feedback, tentarei evitar tal ação no futuro.
21413 Kortuk

1
idem. É uma ótima pergunta ....
Jason S

Aceitei uma pergunta porque, mesmo que isso fosse aberto, eu tinha várias respostas excelentes e queria recompensar pelo menos um escritor pelo esforço.
Kortuk

Respostas:


29

Não tive muita experiência pessoal com os RTOS além do QNX (o que é ótimo no geral, mas não é barato, e tive uma péssima experiência com um fornecedor de placas específico e com a atitude de não nos importarmos com outros sistemas do que o mais comum), que é muito grande para PICs e MSP430.

Onde você se beneficiará de um RTOS é em áreas como

  • gerenciamento / programação de encadeamentos
  • comunicações inter-thread + sincronização
  • E / S em sistemas com stdin / stdout / stderr ou portas seriais ou suporte a Ethernet ou um sistema de arquivos (não um MSP430 ou PIC na maioria das vezes, exceto as portas seriais)

Para periféricos de um PIC ou MSP430: para portas seriais, eu usaria um buffer de anel + interrompe ... algo que escrevo uma vez por sistema e apenas reutilizo; outros periféricos, acho que você não encontrará muito suporte de um RTOS, pois eles são tão específicos de cada fornecedor.

Se você precisar de um tempo sólido para o microssegundo, um RTOS provavelmente não ajudará - os RTOS têm tempo limitado, mas normalmente têm tremulação de tempo em sua programação devido a atrasos na alternância de contexto ... O QNX executado em um PXA270 tinha jitter nas dezenas de microssegundos típicos, máximo de 100-200us, então eu não o usaria para coisas que precisam correr mais rápido que cerca de 100Hz ou que precisam de um tempo muito mais preciso que 500us. Para esse tipo de coisa, você provavelmente precisará implementar seu próprio tratamento de interrupção. Alguns RTOS jogarão bem com isso, e outros tornarão uma dor real: seu tempo e o tempo deles podem não ser capazes de coexistir bem.

Se o cronograma / programação não for muito complexo, é melhor usar uma máquina de estado bem projetada. Eu recomendo a leitura Prático Statecharts em C / C ++, se você ainda não o fez. Usamos essa abordagem em alguns de nossos projetos em que trabalho, e há algumas vantagens reais em relação às máquinas de estado tradicionais para gerenciar a complexidade ... que é realmente a única razão pela qual você precisa de um RTOS.


Eu trabalho em uma empresa iniciante na qual os caras de sistemas embarcados mais experientes estão apenas saindo da faculdade (ou seja, eu e o outro cara que trabalha comigo há cerca de 2 anos). Passo uma grande parte do tempo me ensinando sobre a prática do setor durante minha semana de trabalho. Enquanto eu lia, fui informado de tudo, menos do nosso sistema de menor custo, um RTOS seria uma grande melhoria.
21413 Kortuk

Parece haver um sistema RTOS de recursos muito baixos para itens como PICs e MSP430s que podem ajudar a criar um sistema determinístico a partir de um sistema muito complicado, além de facilitar muito o gerenciamento de manter os módulos separados. Fiz parte de uma equipe de dois homens que efetivamente construiu um sistema de coleta e roteamento de dados em campo. Agora que olho para o RTOS, vejo que é perfeito para o que projetamos.
21415 Kortuk

Desculpe por usar três slots de postagem, sua resposta é muito útil, estou procurando uma solução com poucos recursos, mas essas informações são valiosas, obrigado pela ajuda.
`` #

não se preocupe com a contagem de comentários (IMHO, uma coisa que falta na estrutura do StackExchange é o suporte a discussões ... o formato Q / A cobre a maioria das coisas, mas não algumas) ... parece que você tem uma boa noção do que você está procurando. Eu não olhei para o FreeRTOS que Steve mencionou, mas se ele foi portado para microcontroladores low-end, talvez faça o gerenciamento de agendamento que você precisa.
Jason S

Parece salvar o estado de cada thread na pilha (algo como 50 instruções push / pull) e pode lidar com interrupções cronometradas. Meu sistema normalmente usava uma interrupção de porta para alternar threads, mas a tarefa parece factível. Desejo que este tipo de site seja tratado em um formato melhor.
Kortuk 04/12/2009

26

Você já experimentou o FreeRTOS ? É gratuito (sujeito a T&C) e foi portado para o MSP430 e vários tipos de PIC.

É pequeno em comparação com outros, mas isso também facilita o aprendizado, principalmente se você nunca usou um RTOS.

Está disponível uma licença comercial (não gratuita) e uma versão IEC 61508 / SIL 3.


Muito obrigado, analisarei a questão dentro de uma semana, deixarei a pergunta em aberto para outras respostas, mas você é uma grande ajuda!
Kortuk

12

Acabei de descobrir sobre o NuttX RTOS, que pode até funcionar em um sistema 8052 (8 bits). Não tem muitas portas, mas parece interessante. O POSIX pode ser uma vantagem, porque pode tornar seu código um pouco mais portátil se você mudar para um processador mais robusto e quiser executar o linux ou QNX em tempo real.

Eu não tenho nenhuma experiência com RTOS comerciais, mas eu uso caseiras há anos! Eles são ótimos para ajudá-lo a dividir seu desenvolvimento de código entre muitos programadores, porque eles podem essencialmente obter uma "tarefa" ou "thread" para trabalhar da parte deles. Você ainda precisa coordenar e alguém deve supervisionar todo o projeto para garantir que cada tarefa cumpra seu prazo.

Também recomendo que você pesquise Análise Monotônica de Taxa ou RMA ao usar um RTOS. Isso ajudará a garantir que suas tarefas críticas cumpram os prazos.

Também examinaria a estrutura de programação orientada a eventos QP-nano do Miro Samek que pode funcionar com ou sem um RTOS e ainda oferecer capacidade em tempo real. Com isso, você está dividindo seu design em máquinas de estados hierárquicas, em vez de tarefas tradicionais. Jason S mencionou o livro de Miro em seu post. Uma excelente leitura!


9

Uma coisa que achei útil em várias máquinas é um simples comutador de pilhas. Na verdade, eu não escrevi um para o PIC, mas espero que a abordagem funcione bem no PIC18 se ambos / todos os segmentos usarem um total de 31 ou menos níveis de pilha. No 8051, a rotina principal é:

_taskswitch:
  xch a, SP
  xch a, _altSP
  xch a, SP
  ret

No PIC, esqueço o nome do ponteiro da pilha, mas a rotina seria algo como:

_taskswitch:
  movlb _altSP >> 8
  movf _altSP, w, b
  movff _STKPTR, altSP 
  movwf _STKPTR, c
  Retorna

No início do seu programa, chame uma rotina task2 () que carregue altSP com o endereço da pilha alternativa (16 provavelmente funcionaria bem para um PIC18Fxx) e execute o loop task2; essa rotina nunca deve retornar, senão as coisas sofrerão uma morte dolorosa. Em vez disso, deve chamar _taskswitch sempre que desejar gerar controle para a tarefa principal; a tarefa principal deve chamar _taskswitch sempre que desejar render à tarefa secundária. Muitas vezes, você terá rotinas fofinhas como:

void delay_t1 (valor curto não assinado)
{
  Faz
    comutador de tarefas ();
  while ((sem sinal abreviado) (milissegundo_clock - val)> 0xFF00);  
}

Observe que o alternador de tarefas não tem meios de executar qualquer 'espera pela condição'; tudo o que suporta é um spinwait. Por outro lado, a alternância de tarefas é tão rápida que uma tentativa de alternar tarefas () enquanto a outra tarefa aguarda a expiração do cronômetro mudará para a outra tarefa, verificará o cronômetro e voltará mais rapidamente do que um alternador de tarefas determinaria que ele não precisa alternar entre tarefas.

Observe que a multitarefa cooperativa tem algumas limitações, mas evita a necessidade de muitos códigos relacionados a mutex e bloqueio nos casos em que invariantes temporariamente perturbados podem ser restabelecidos rapidamente.

(Editar): Algumas advertências sobre variáveis ​​automáticas e outras:

  1. se uma rotina que usa alternância de tarefas for chamada de ambos os threads, geralmente será necessário compilar duas cópias da rotina (possivelmente #incluindo o mesmo arquivo de origem duas vezes, com instruções #define diferentes). Qualquer arquivo de origem contém código para apenas um segmento ou outro código que será compilado duas vezes - uma vez para cada segmento - para que eu possa usar macros como "#define delay (x) delay_t1 (x)" ou #define delay (x) delay_tx (x) "dependendo do segmento que estou usando.
  2. Acredito que os compiladores PIC que não podem "ver" uma função sendo chamada assumirão que essa função pode eliminar todos e quaisquer registros de CPU, evitando assim a necessidade de salvar quaisquer registros na rotina de troca de tarefas [um bom benefício em comparação com multitarefa preemptiva]. Qualquer pessoa que considere um alternador de tarefas semelhante para qualquer outra CPU precisa estar ciente das convenções de registro em uso. Pressionar os registros antes de uma tarefa alternar e pop-los depois é uma maneira fácil de cuidar das coisas, assumindo que existe um espaço de pilha adequado.

A multitarefa cooperativa não permite escapar completamente de questões de bloqueio, mas realmente simplifica bastante as coisas. Em um RTOS preventivo com um coletor de lixo compactador, por exemplo, é necessário permitir que os objetos sejam fixados. Ao usar um comutador cooperativo, isso não é necessário, desde que o código pressuponha que os objetos do GC possam se mover a qualquer momento em que o taskwitch () for chamado. Um coletor de compactação que não precisa se preocupar com objetos fixados pode ser muito mais simples do que um que faz.


1
Resposta incrível. Eu acho que seria interessante obter alguns links sobre recursos para abordar meu próprio RTOS. Meu foco aqui foi realmente obter um RTOS de alta qualidade de um fornecedor que fez o trabalho de garantir tempo real difícil, mas esse pode ser um projeto hobby divertido para mim.
Kortuk

1
Cool, nunca pensei em tarefas como apenas alternando o SP ...
NickHalden

1
@JGord: Eu fiz pequenos comutadores de tarefas no 8x51 e em um DSP da TI. O 8051, mostrado acima, foi projetado para exatamente duas tarefas. O DSP one é usado com quatro e é um pouco mais complicado. Eu só tinha uma ideia maluca: no entanto, era possível lidar com quatro tarefas simplesmente usando três comutadores de tarefas. Sempre que uma das duas primeiras tarefas deseja alternar entre tarefas, deve chamar TaskSwitch1 e TaskSwitch2. Quando uma das duas tarefas secundárias deseja alternar entre tarefas, deve chamar Taskswitch1 e Taskswitch3. Suponha que o código inicie na pilha0 e cada alternador de tarefas seja definido com seu número de pilha correspondente.
Supercat

@JGord: Hmm ... isso não funciona; parece produzir um round-robin de 3 vias e ignora o terceiro comutador. Bem, experimente e acho que você provavelmente encontrará uma boa fórmula.
Supercat

7

Eu usei Salvo no MSP430. Isso ficou muito claro nos recursos do processador e, desde que você obedeça às regras de implementação, seja muito fácil de usar e confiável. Este é um sistema operacional cooperativo e requer que as alternâncias de tarefas sejam executadas no nível da chamada de função externa das funções de tarefa. Essa restrição permite que o sistema operacional trabalhe em dispositivos de memória muito pequenos sem usar grandes quantidades de espaço na pilha, mantendo os contextos das tarefas.

No AVR32, estou usando o FreeRTOS. Mais uma vez, muito confiável até agora, mas tive algumas discrepâncias de configuração / versão entre a versão que o FreeRTOS publica e a versão fornecida com a estrutura Atmel. No entanto, isso tem a vantagem de ser gratuito!


5

A edição de dezembro da Everyday Practical Electronics possui a parte 3 de uma série de sistemas operacionais em tempo real para PICs (na coluna PIC n 'Mix) e apresenta detalhes da configuração do FreeRTOS com MPLAB e um PICKit 2. Os dois artigos anteriores (que eu não vi) parecem ter discutido os méritos de vários RTOS e se estabelecido no FreeRTOS. Depois que o artigo atual configura o ambiente de desenvolvimento, eles começam a projetar um relógio digital binário. Parece que há pelo menos mais uma parte sobre este tópico.

Não sei ao certo como a EPE está disponível nos EUA, mas parece que existe uma loja nos EUA vinculada ao site e pode haver cópias eletrônicas disponíveis.


4

O compilador CCS para o PIC vem com um RTOS simples. Eu não tentei, mas se você tiver esse compilador, seria fácil experimentar.


1
Na verdade, eu tentei isso como o meu primeiro. Não é um RTOS em nenhum significado real da palavra. Não é preventivo de forma alguma. Ele requer o uso regular de comandos de rendimento, para que o RTOS possa decidir quem será o próximo, você deverá colocá-los intencionalmente constantemente, caso outro programa precise assumir.
precisa saber é o seguinte

2
Eu acho que ainda é chamado de RTOS. Parece que ele tem um agendador cooperativo em vez de um agendador totalmente preventivo.
Jay Atkinson

Sim, ainda é tecnicamente um RTOS, mas eu tinha e ainda tenho muito pouco valor para isso. Eu sei que é uma coisa pessoal, mas para mim precisa ser preventivo para ser valioso. Eu ainda +1, pois foi uma boa resposta e de valor.
Kortuk

3

Obrigado! Parece que a maioria das pessoas não recebeu a pergunta, mas ainda é interessante.
Kortuk

Postei na pergunta sobre SO convidando o usuário a procurar ajuda na E&R!
Kortuk

Eu acho que nós "pegamos" a pergunta no SO, estava perguntando algo diferente, mas relacionado a essa pergunta. Quanto ao seu comentário lá sobre certificação; isso depende de muitas coisas. Observando as respostas aqui, gosto da resposta do DoxaLogos referente ao QP-nano; minha experiência me leva a preferir código orientado a eventos sobre threads e alternância implícita de contexto de threads.
JANM

2

Você não falou muito sobre sua inscrição. A utilização de um RTOS depende muito do que você precisa fazer no PIC. A menos que você esteja fazendo várias coisas assíncronas, que exigem prazos estritos ou que tenham vários threads em execução, um RTOS pode ser um exagero.

Existem várias maneiras de organizar o tempo em um microcontrolador, dependendo do que é mais importante:

  1. Taxa de quadros constante: para um PIC executando um servocontrolador que deve funcionar a 1000Hz, por exemplo. Se o algoritmo PID demorar menos de 1ms para ser executado, você poderá usar o restante do milissegundo para realizar outras tarefas, como verificar o barramento CAN, ler os sensores etc.

  2. Todas as interrupções: tudo o que acontece no PIC é acionado por uma interrupção. As interrupções podem ser priorizadas de acordo com a importância do evento.

  3. Coloque-o em um loop e faça tudo o mais rápido possível. Você pode achar que isso fornece limites de tempo adequados.


Eu entendo outros métodos, mas estou querendo expandir para um RTOS. Estarei executando várias tarefas e tendo um sistema rígido em tempo real, mas estou disposto a iniciar sem os requisitos de tempo real difícil. Obrigado por reservar um tempo para responder, mas estou querendo aprender um RTOS para poder usá-lo em uma situação de alta demanda.
precisa saber é o seguinte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.