Sistemas operacionais em tempo real para microcontroladores. Sistemas incorporados e sistema operacional para eles

Oi, HABR!
Hoje vou falar sobre uma coisa tão interessante como sistema operacional Tempo real (OSR). Não tenho certeza de que será interessante para programadores experientes, mas acho que vou gostar dos iniciantes.

O que é OSR?

Se olharmos para a Wikipedia, veremos até 4 definições.
Se você disser brevemente, o OSR é um sistema operacional que responde a eventos externos em um determinado período de tempo. A partir daqui, podemos entender o objetivo principal do OSR - os dispositivos nos quais uma resposta rápida aos eventos são necessárias (mas em nenhum caso não confunde o trabalho do OSR com interrupções).

Por que precisamos dela?

Isto é, muitas razões.
Primeiro, o OSRV suporta multitarefa, prioridades dos processos de semáforo e muito mais.
Em segundo lugar, é muito fácil e quase não requer recursos.
Em terceiro lugar, todos os itens acima podemos ficar quase em qualquer glândula (por exemplo, o Freertos está sendo executado mesmo em atmega de 8 bits).
Bem, em quarto lugar: apenas jogue e aproveite.

Visão geral de 3 OSRs bem conhecidos.

ATENÇÃO: Então vai na minha opinião pessoal.
Freertos.
Um dos OSRs mais populares hoje. Portado para uma enorme quantidade de ferro. Site oficial.
prós
1) LIVRE
2) portado para um grande número de glândula
3) funcionalidade poderosa
4) Existem várias bibliotecas: gráficos, internet e muito mais.
5) Boa documentação.
Minuses.
1) Um processo de portagem bastante complexo para um novo ferro.

Conclusão: é realmente um compartilhamento profissional com boa documentação. Será bom para iniciante, se o porto já tiver uma porta.

Keilrtx.
Até recentemente, este OSRV era comercial, mas recentemente se abriu. Funciona apenas na arquitetura do braço. Site oficial.
prós
1) LIVRE
2) facilmente portas para novo ferro (dentro da arquitetura do braço).
3) Existem várias bibliotecas: gráficos, internet e muito mais.
Minuses.
1) Trabalhar em Keil é quase irreal
2) uma pequena funcionalidade aparada
3) Apenas o braço é suportado.
4) (na experiência pessoal) perde muitos tipos de velocidade.
Conclusão: Ideal para projetos iniciantes e pequenos.
uC / OS.
Poderoso compartilhamento comercial. Local na rede Internet .
prós
1) Enorme número de funções e bibliotecas.
2) suporta muito ferro
Minuses.
1) comercial.
2) Complexo em uso.

Conclusão: Você pode chamá-lo para um novato com um grande trecho.

Outros OSRVs interessantes

RtLinux OSRVs com base no Linux ordinário.
QNX OSRV baseado no Unix.

Recursos de desenvolvimento usando OSRV

Bem, em primeiro lugar, é necessário entender o seguinte: DRA não é o Windows. Não pode ser instalado. Este sistema é simplesmente compilado com o seu programa.
Ao escrever programas com o OSR, as funções não são usadas em seu entendimento habitual. Em vez de funções, processos (ou testes) são usados. O fato de que os processos, ao contrário das funções, são ciclos infinitos e nunca terminam (se apenas alguém ou não o mate - isto é, descarrega da memória).
Se vários processos estiverem incluídos, o OSR os liga, emitindo o tempo de máquina e os recursos por sua vez. É aqui que surja o conceito da prioridade do processo, se os dois processos precisarem de um tempo de motor de uma só vez, o OSR dará a aquele que tem mais prioridade.
No OSRV, há características especiais do atraso - de modo que o tempo em vão não desaparece no momento do atraso de um processo, o segundo é realizado.
Agora vamos falar sobre tal coisa como semáforo - esta coisa que controla o acesso do aplicativo para os recursos do aplicativo. Para cada recurso, há um marcador - quando o processo precisa de um recurso - ele leva e usa esse recurso. Se não houver marcador, o processo terá que esperar até que seja retornado. Eu darei um exemplo: diferentes processos enviam informações em um UART. Se não houvesse semáforo, eles enviariam bytes por sua vez e seria uma confusão. E assim o primeiro processo levou o marcador no UART enviou uma mensagem e deu o segundo (eo infinito).

Bibliotecas adicionais do OSR.

Muitas vezes, o OSRV oferece várias bibliotecas para o trabalho, por exemplo, com gráficos, internet, etc. Eles são muito confortáveis \u200b\u200be não devem ser forçados a usá-los. No entanto, lembre-se que sem o OSR, para o qual eles estão escritos, eles não funcionarão.
Aqui estão exemplos:
Para rtx.

O que vem à mente quando você ouve o sistema operacional? Certamente as janelas, linux, macro .. ou algo assim. É verdade, e sobre a questão por que ela precisa, todos vão responder com confiança: ouvir música, jogar o jogo (na internet!), Conversando com o outro no Skype. Ao mesmo tempo, contemplando os flashes LED, tendo recebido um byte de yuart \u003d).

E se você se aprofundam, ou ouvir música, enviar dados pela Internet é todos os processos únicos e, como temos um processador, depois, ao mesmo tempo, pode executar apenas uma tarefa. Portanto, as tarefas são realizadas alternadamente em pequenas "porções", a essência do sistema operacional faz isso imperceptivelmente para o usuário: para que o som não roube e o biketics esteja cantando e tudo funcionou ao mesmo tempo. Ao mesmo tempo, se uma das tarefas "pendurar", então tudo o mais continuou a trabalhar.

Se você abandonar todos os pães extras e deixar a essência nua, primeiro do sistema operacional, é apenas um temporizador que conta intervalos iguais e em si, sem a participação do usuário, alterna entre as tarefas, realiza alguma parte e alterna novamente. Também é necessário considerar que a maioria das tarefas pode não ter tempo para completar em um quantum de tempo, então você precisa salvar o status da tarefa no momento da mudança para outra, e a próxima vez para restaurar o estado das variáveis . A gestão de tudo isso é feita pelo planejador de tarefas.

Existem dois tipos principais de sistema operacional: deslocando e cooperativa. No primeiro caso, alternar entre as tarefas será "difícil", isto é. Se o Quantum of Time for 1ms, primeiro a primeira tarefa será executada exatamente 1ms, então o segundo exato 1 ms, etc. Tais eixos são chamados em tempo real (ORVD). Cooperativa é um pouco mais simples, o próprio processo deve dizer que "eu fui executado", portanto, é impossível atribuí-los.

Rápido o avr excelente não funcionará porque número pequeno RAM. Das opções disponíveis para cooperativas, fui atraído por MRTOS, você pode ler os detalhes desse sistema no site do autor (facilmente Googles). razão principal Seu uso é a simplicidade, a presença de uma versão pronta sob CAVR, para entender princípios gerais A maior coisa.

Assim, as principais questões permaneceram, por que e quando aplicar o eixo. Teoricamente, toda a mesma coisa que você faz com o eixo, você pode atravessar sem isso, pois os recursos são os mesmos. Do fato de você adotá-lo ao projeto, Megahertz no espaço não decolará, o ferro permanecerá o mesmo, portanto os recursos são os mesmos.

Portanto, você deve se perguntar algumas perguntas:
1. Você consegue gerenciar recursos competentes?
2. Não deve inventar a mesma moto no processo de escrever o firmware?
3. Quanto você lê seu código? Você é capaz de abri-lo em meio ano e sair?
4. Você está escrevendo ou grupo?

É difícil dar a resposta para a primeira pergunta, pois tudo depende da curricularidade do desenvolvedor. Com o segundo, tudo é mais compreensível se houver muitas tarefas independentes e é planejado para executá-los após certos intervalos, é melhor olhar para o lado do sistema operacional. O terceiro também é claro, é muito mais fácil entender em uma tarefa separada do que pintar dependências no ciclo principal. Se você escrever não sozinha, então há vantagens, pois todos podem escrever sua tarefa separadamente, sem interferir no resto.

Combinando o acima, o escopo da aplicação é bastante específico, sob uma certa gama de tarefas. Não empurre-o em todos os projetos. Para a maioria dos dispositivos de rádio amadores, o eixo é supérfluo, mas tendo uma ideia dela antes, provavelmente a alinhou um par de projetos.

Agora olhe debaixo do capô. Para iniciar MRTOS ao projeto, você precisa conectar mrtos.c e moeda mrtos. A estrutura do código é ligeiramente diferente do habitual

#Incluir. #Include "mrtos.h" // aqui função do corpo onde escrevemos seu super código Task1 () vazio () (enquanto (1) // tarefas em qualquer sistema operacional são construídos com base em um ciclo infinito { // aqui o código da sua tarefa Despacho; // função de gerenciamento de planejador } ; } // Timer Interrupt Handler 0 Interromper [tim0_ovf] Void timer0_ovf_isr (VOID) (CHAR II; #asm ("cli") tcnt0 \u003d 0x9c; inc_systime (); para (II \u003d 0; II< init_tasks; ii++ ) if (tasks[ ii] .delay ) -- tasks[ ii] .delay ; #asm("sei") } void main(void ) { // Inicialização da periferia Init_mrtos (); // inicialização do sistema operacional // aqui nós criamos tasses (tarefas) 3 tarefas criadas aqui Create_task (tarefa1, 1, ativo); // crie uma tarefa (nome da tarefa, prioridade, status) Create_task (tarefa2, 1, ativo); Create_tok (tarefa3, 1, ativo); Sheduler (); // Launch Scheduler. Enquanto (1); )

#Incluir. #include "mrtos.h" // aqui o corpo da função em que escrevemos o seu Task Task1 () Super Código () (enquanto (1) // Tarefas em qualquer sistema operacional sejam criados com base em um ciclo infinito (// Código da sua tarefa de despacho; // Gerenciamento do Agendador de Transmissão de Função);) // Temporizador Interrupt Processo 0 Interromper Void Timer0_ovf_ISR (VOID) (CHAR II; #asm ("cli") tcnt0 \u003d 0x9C; Inc_systime (); para (ii \u003d 0; II.

Agora mais. O número de tarefas é indicado em MRTOS.H Defina AppTasks N. A tarefa é declarada dentro do Task1 () (), Task2 () () e semelhantes, por dentro, enquanto (1) não precisa escrever nada, não é necessário Para chamar as funções, tudo isso fará você é planejador. Como você pode ver a tarefa consiste em um ciclo infinito, deve ser normal e deve ser, mas dentro da tarefa que você precisa para controlar o planejador. Ou a função de espera ou despacho. Se isso não for feito, a tarefa será realizada infinitamente.

Como funciona? Crie LED de piscar de tarefas.

VOID TASK1 () (enquanto (1) (Portal.0 \u003d! Porb.0; espera (100););)

vOID TASK1 () (enquanto (1) (Portal.0 \u003d! Porb.0; espera (100););)

Aguarde é apenas um atraso () apenas analógico, durante o atraso, um microcontrolador não executa nada e dirija ciclos vazios. Durante a mesma espera, o controle é transmitido para outras tarefas. Aqueles. Você pode criar um monte de tarefas piscando leds diferentes, com diferentes esperar e todos eles piscarão com frequências diferentes. Se atrasos não forem necessários, no final usa despacho.

Ao usar a espera, é importante entender que todo o sistema tem um tique mínimo (quantum de tempo), então estamos esperando não esperar (50) 50 milicecunds, mas 50 sistemas de teca. A configuração do tick depende de como as interrupções do temporizador são frequentemente chamadas, ou seja, Se configuramos uma interrupção para 1ms, podemos assumir que nossa ação é executada por 1 ms. Experimentos mostraram que é possível reduzir o sistema tick a ~ 20 μs com um relógio 16 MHz.

A configuração do temporizador não é diferente no estudo anteriormente, já que o timer0 possui apenas a interrupção do transbordamento, todas as configurações são vinculadas a ele. Nas versões mais recentes do CAVR, é muito conveniente para gravar requisitos de tempo, as configurações geram automaticamente.

Create_task (tarefa1, 1, ativo);

create_task (tarefa1.1, ativo);

Com prioridades, tudo é bonito não apenas. Se houver duas tarefas com prioridade diferente e a tarefa com uma prioridade grande é constantemente realizada, nunca iremos para a tarefa com uma baixa prioridade. Portanto, você precisa organizar o trabalho para que todas as tarefas tenham acesso. Aja atenção nisso, vamos compartilhar na próxima vez. Status da tarefa, iniciado ativo, StopTask parou.

Então, para aqueles que querem simplesmente piscar o LED:

#Incluir. #include "mrtos.h" vazio task1 () (enquanto (1) (espera (1000); portb.0 \u003d! portb.0;)) // Timer 0 Rotina de Serviço de Interrupção de Overflow Interromper [tim0_ovf] void timer0_ovf_isr (VOID) (CHAR II; #asm ("cli") tcnt0 \u003d 0xb2; inc_systime (); para (II \u003d 0; II< init_tasks; ii++ ) if (tasks[ ii] .delay ) -- tasks[ ii] .delay ; #asm("sei") } void main(void ) { DDRB= (1 << DDB7) | (1 << DDB6) | (1 << DDB5) | (1 << DDB4) | (1 << DDB3) | (1 << DDB2) | (1 << DDB1) | (1 << DDB0) ; PORTB= (0 << PORTB7) | (0 << PORTB6) | (0 << PORTB5) | (0 << PORTB4) | (0 << PORTB3) | (0 << PORTB2) | (0 << PORTB1) | (0 << PORTB0) ; // temporizador / contador 0 inicialização // Relógio Fonte: Relógio do sistema // Valor do relógio: 7,813 kHz tccr0 \u003d (0<< CS02) | (1 << CS01) | (1 << CS00) ; TCNT0= 0x83 ; // temporizador (s) / contador (s) Interrupção (s) Inicialização Timsk \u003d (0<< OCIE2) | (0 << TOIE2) | (0 << TICIE1) | (0 << OCIE1A) | (0 << OCIE1B) | (0 << TOIE1) | (1 << TOIE0) ; Init_mRTOS() ; create_task(task1, 1 , Active) ; Sheduler() ; while (1 ) ; }

#Incluir. #include "mrtos.h" vazio task1 () (enquanto (1) (espera (1000); portb.0 \u003d! portb.0 \u003d! Porb.0;)) // timer 0 Overflow Interrupt Service Rotina de interrupção Void Timer0_ovf_ISR (VOID) (CHAR II) #Asm ("cli") tcnt0 \u003d 0xb2; inc_systime (); para (II \u003d 0; II

Como bônus, tentei fazer uma melodia polifônica (dois cabelos) "Dr.Mario Chill". A ideia é que cada perna do controlador esteja constantemente invertida em um tasque separado, gerando assim a frequência. Alterando o obturador Você pode alterar a altura das notas.

VOID TASK2 (VOID) (enquanto (1) (se (mudo \u003d\u003d 0) // se permissão para jogar (if_ch2 [n_n] \u003d\u003d 0) // Se você está esperando por uma pausa, não tocamos nada (Portal.4 \u003d 0; aguarde (5);) mais (Portal.4 \u003d! Portal.4; // se não fizer uma pausa, aperte o pé com a frequência desejada Aguarde (Note_ch2 [n_n]); )))))

vOID TASK2 (VOID) (enquanto (1) (se (mudo \u003d\u003d 0) // se você tiver permissão para reproduzir (if_ch2 \u003d\u003d 0) // se estiver esperando por uma pausa, não tocamos nada (Portal. 4 \u003d 0; aguarde (5);) mais (portal.4 \u003d! Portb.4; // se não pausar, então com o pé com a frequência desejada de espera (note_ch2))))))

Eu não me incomodei com a ideia, 1 Tasque gera meandro com uma frequência de notas para a festa solo, no segundo para baixo. A altura de cada notículo é retirada das matrizes. Duração, alternando e quebrando em Tasque3.

Task3 vazio3 (vazio) (espera (1) (espera (1500); // Reproduza o número mínimo de notas para (mudo \u003d 0; mudo< 500 ; mute++ ) // clique na nota para não mesclar (Portb.3 \u003d 0; portb.4 \u003d 0;); Mudo \u003d 0; // Defina a bandeira que você pode reproduzir som n_n ++; // vai para a próxima nota if (n_n \u003d\u003d n_max) // se eles jogaram tudo em um círculo (n_n \u003d 0;))))

void Task3 (VOID) (espera (1) (aguarde (1500); // Reproduzir dialdial mínima de notas para (mudo \u003d 0; mudo< 500; mute++) //обрываем ноту, чтобы не сливались { PORTB.3 = 0; PORTB.4 = 0; }; mute = 0; //выставляем флаг, что можно воспроизводить звук n_n++; //переходим на следующую ноту if(n_n == n_max) //если сыграли все то идем по кругу { n_n = 0; } } }

Para misturar dois canais usou um esquema simples.

Total Peça pequena

Para aqueles que querem firmware

Eu desenvolvi um pouco mais de 10 dispositivos eletrônicos e foi contabilizado em seu trabalho de baixo nível sem o sistema operacional. A situação mudou quando a funcionalidade do próximo dispositivo se expandiu acentuadamente. Além disso, houve necessidade de uma tarefa que é chamada através dos intervalos de tempo especificados, e a precisão da chamada afeta o resultado. Também ficou claro que não funcionaria tudo para o tempo alocado, e será criado mais tarde. Após uma breve reflexão, percebi que o projeto deve incluir o sistema operacional em tempo real (Orvd ou RTOs).

Ao contrário do PC, onde o sistema operacional é mais uma camada para trabalhar com recursos do sistema, para um microcontrolador OSR - isso é principalmente um agendador de tarefas, na verdade ele desempenha um papel importante em "tempo real". No momento, é importante para mim garantir o chamado desempenho "pseudo-paralelo" de tarefas. Ou seja, existem várias tarefas com a mesma prioridade e é importante levá-los em uma determinada ordem nos intervalos de tempo especificados.

O exemplo a seguir foi visualmente: no projeto Eurobot 2011, 18 dispositivos periféricos estavam presentes no sistema. 2 e-mails podem ser mesclados em um. Seu custo diminuiria, a confiabilidade aumentou (reduziu o número de componentes no sistema), a quantidade de espaço livre no caso aumentou. A circunstância complica o fato de que o número de tarefas cresce proporcionalmente e aqui não é mais feito sem o sistema operacional. Além disso, o OSR ajuda a evitar possíveis tempo de inatividade do processador, por exemplo, durante a conversão do ADC, você pode bloquear essa tarefa e realizar outras, distribuindo assim corretamente a operação do dispositivo. Também é importante que agora o dispositivo não caia devido a uma falha na tarefa, em vez disso, é possível preservar o desempenho parcial (embora possa levar a resultados imprevisíveis). Devido ao que garantimos o crescimento desses indicadores? Na verdade, nós apertamos todos possíveis do MC, efetivamente usando suas capacidades computacionais.

Depois de breve pesquisa, a escolha caiu no freertos. Este Ord é distribuído no código-fonte em C e portas para 27 arquiteturas. A última circunstância para mim é decisiva. Isso reduzirá os custos de mão-de-obra ao trabalhar com MK de outros fabricantes. Agora estou mais interessado no porto para o AVR.

A disponibilidade de visão geral do Freertos no projeto come cerca de 9,8 cb de programas de programas e 1,8 KB RAM. Por exemplo, para o compilador Atmega32 e Winavr é de 60% e 85%, respectivamente. Já desse modelo, crie um dispositivo com grande funcionalidade é difícil - não é suficiente memória. Mas esse problema desaparece ao usar novos modelos AVR. É completamente ofendido para o Mega2560 com o seu 256kb de programas de programas e 8 kb RAM. A tendência do futuro MK acompanha apenas o sucesso do OSR.

Corre correndo no runet, fiquei surpreso ao descobrir que não há documentação sobre o sistema operacional em russo. Então, o que está aqui! A documentação original se aplica ao custo adicional. A situação simplificou o artigo Andrei Kurtica ( [E-mail protegido]) Da revista "Componentes e Tecnologia". Por acordo com o autor, usarei o artigo na versão reciclada. Seu artigo pode servir como documentação em russo. Mas o original não está disponível na impressão, o site da revista reside, então o material terá que reciclar um pouco. Em geral, o autor fez um excelente artigo e não faz sentido passar pela teoria novamente, será totalmente publicado aqui. O artigo original será anexado no final da publicação. Eu também notei que os usuários tinham dificuldade em compilar o OSR. Isso se deve ao fato de que o makefile externo é usado, no qual os caminhos para as pastas são escritos. Portanto, vou aplicar um projeto pronto sob a forma de um modelo para o AVR Studio e o AVR Eclipse. Infelizmente, o makefile nativo não retira informações de depuração, como o grau de emprego da RAM e a memória dos programas, tinham que fogir adicionando o desafio padrão apropriado.

Então, brevemente sobre a necessidade, em seu projeto, é desejável usar OSR se necessário:

Organize tarefas Multisascy e alternativas

Forneça o lançamento da tarefa através de intervalos de tempo estritamente definidos

Transferir informações de uma tarefa para outra

Adicione novas tarefas conforme necessário

Vantagens do OSRV antes de mPARA:

  1. Multitarefa. OSRV fornece um programador pronto, o mecanismo bem durável. Cada tarefa em um caso simples pode ser programada separadamente, todo o trabalho é quebrado entre vários membros da equipe. Não há necessidade de cuidar de mudar entre tarefas, ele fará o planejador.
  2. Base temporária. É necessário medir os intervalos de tempo. OSRV deve ter essa ferramenta. Ele permitirá que você realize ações através de intervalos de tempo estritamente dedicados.
  3. Troca de dados entre as tarefas. Para este propósito, uma fila é usada no OSR.
  4. Sincronização. Se tarefas diferentes usarem o mesmo recurso, como uma porta serial, os mutexes e seções críticas podem ser usadas. Se você precisar executar tarefas em uma sequência estrita ou quando ocorrer um evento específico, poderá usar semáforos ou sinais para sincronizar tarefas.

Desvantagens da OSRV.:

1. Um aumento acentuado na necessidade do programa implementar o kernel

2. Um aumento na RAM necessária para armazenar a pilha de cada tarefa, semáforos, filas, mutexes e outros objetos núcleos de objeto.

3. Atraso ao alternar entre as tarefas de conservação do contexto.

Descriçãofreertos.:

O Freertos é um sistema operacional rígido de código aberto gratuito. De preferência, escrito em C, mas há inserções montadoras. Foi desenvolvido por engenheiros de tempo real Ltd especificamente para sistemas incorporados. Recentemente, o projeto "Safertos" - melhor, documentado, testado e passado certificação para conformidade com o padrão de segurança IEC 61508 para conformidade com a versão IEC 61508. A empresa alemã estava envolvida neste projeto e agora safertos é usada na indústria aeroespacial e na tecnologia médica. Há também um projeto OpenRTOS - uma versão comercial com garantia de um fabricante.

As principais características dos Frertos:

1. O agendador suporta 3 tipos de multitarefa:

Obsting.

Cooperativo

Híbrido

2. O tamanho do kernel é 9,8 KB em formulário compilado para AVR. (Winavr)

3. A base dos arquivos Core - 4 em C.

4. Suporta tarefas e coprogramas. Os transportadores são especialmente criados para MK com um pequeno volume de RAM.

5. Rich Trace Capacidades.

6. É possível rastrear o estouro de pilha.

7. Nenhuma restrição de software no número de tarefas executadas simultaneamente.

8. Sem restrições ao número de prioridades das tarefas.

9. Algumas tarefas podem ser atribuídas a mesma prioridade.

10. Ferramentas desenvolvidas para sincronização "tarefa-tarefa" e "interrupção de problemas":

Filas

Semáforas binárias

Semáforos de contas

Semáforos recursivos

Mutexes.

11. mutexes com herança prioritária.

12. Suporte para módulo de proteção de memória para o Cortex-M3

13. Fornecido em dívida com projetos de demonstração para várias plataformas e compiladores.

14. livre. Você pode usar em projetos sem divulgar o código-fonte de acordo com a licença GPL estendida.

15. Documentação paga, mas está disponível online aqui.

16. Tempo de comutação de contexto para AVR com quartzo a 16 MHz será de apenas 20,8 μs. É muito necessário salvar dados para a pilha de tarefas e chamar o seguinte. (Observação interessante, se você compará-lo com o PIC18XXX, o controlador do AVR é \u200b\u200bmais rápido 4 vezes !!!, provavelmente é devido à qualidade do compilador)

O multitarefa deslocando significa que a tarefa com uma prioridade baixa é sobreposta por uma tarefa pronta com uma prioridade maior. Mudar entre as tarefas ocorre através de igual tempo quanta. Portanto, antes que a tarefa de inteligência inicie a execução, a quantum de tempo atual deve terminar quando a baixa prioridade é realizada.

Assim, o tempo de reação do freertos em eventos externos no modo de deslocar a multitarefa não é mais de um tempo de tempo de agendamento, que pode ser especificado nas configurações. Por padrão, é igual a 1 ms.

Se você estiver pronto para realizar várias tarefas com a mesma prioridade, neste caso, o planejador aloca cada um deles por um quantum de tempo, após o qual o controle recebe a seguinte tarefa com a mesma prioridade e assim por diante em um círculo.

A multitarefa cooperativa é diferente do deslocamento do planejador, independentemente, não pode interromper a execução da tarefa atual, até mesmo terminada para executar a tarefa com uma grande prioridade. Cada tarefa deve transferir independentemente o gerenciamento do agendador. Assim, a tarefa de alta prioridade será esperada até que a baixa prioridade complete seu trabalho e confere ao gerenciamento do planejador. O tempo de reação do sistema a um evento externo se torna indefinido e depende de quanto tempo a tarefa atual será executada antes do controle. A multitarefa cooperativa foi usada na família Windows 4 OS.

O conceito de deslocamento e cooperativa de multitarefa é combinado em uma multitarefa híbrida, quando uma chamada de desafiante ocorre todas as quantimas de tempo, mas, em contraste com a multitarefa deslocante, o programador tem a capacidade de fazer isso forçado no corpo da tarefa. Este modo é especialmente útil quando é necessário reduzir o tempo de resposta do sistema para interromper. Suponha, atualmente a tarefa de baixa prioridade é realizada e a alta prioridade aguarda uma certa interrupção. Em seguida, ocorre, mas após o término do manipulador de interrupção, a execução retorna à atual tarefa de baixa prioridade, e a alta prioridade espera o horário atual. No entanto, se depois de executar o manipulador de interrupção, transfira o controle do Agendador, ele transmitirá o controle de uma tarefa de alta prioridade, que reduz o tempo de reação do sistema associado a um evento externo.

Por quenobate-papob?

Você pode começar a desenvolver um dispositivo de microcontrolador executando o freertos, de carregar sua versão mais recente.

A distribuição de freertos está disponível como um arquivo zip comum ou auto-extraível. A distribuição contém diretamente o código do kernel (como vários arquivos de cabeçalho e arquivos de origem) e projetos de demonstração (um projeto para cada ambiente de desenvolvimento para cada porta). Em seguida, você deve descompactar o arquivo em qualquer local adequado na estação de desenvolvimento.

Apesar do número bastante grande de arquivos no arquivo, a estrutura dos diretórios é realmente simples. Se você planeja projetar dispositivos para 2-3 arquiteturas em 1-2 ambientes de desenvolvimento, a maioria dos arquivos relacionados a projetos de demonstração e vários ambientes de desenvolvimento não serão necessários.

A estrutura detalhada do diretório é dada no patch.

Todo o código-fonte do núcleo está no diretório / source.

Contente:

1.Tasks.c. - Implementação do mecanismo de tarefas, agendador

2. fila.c. - Implementação da propriedade.

3. liste.c. - As necessidades internas do planejador, no entanto, as funções podem ser usadas em programas de aplicativos.

4. Crouteine.c. - Implementação do Spram (pode estar ausente se os transportadores não forem usados).

Os arquivos de cabeçalho que estão no diretório Fonte / incluir.

1. Tasks.h, a queue.h, tist.h, croure.h - Arquivos de cabeçalho, respectivamente, para os arquivos do código do mesmo nome.

2. freertos.h. - Realize diretrizes do pré-processador para configurar a compilação.

3. mpu_wrappers.h. - Contém substitui as funções da interface do programa (funções da API) Freertos para suportar o módulo de proteção de memória (MPU).

4. Portable.h.configurações dependentes -plappo.

5. Projdefs.h.Definições do sistema -Hext.

6. semfr.h. - Define as funções da API para trabalhar com semáforos implementados com base nas filas.

7. StackMacros.h. - Contém macros para monitorar o estouro de pilha. Cada plataforma de hardware requer uma pequena parte do código principal, que implementa a interação do Freertos com esta plataforma. Todo o código dependente da plataforma está no subdiretório / Fonte / PortableOnde estão sistematizados, mas ambientes de desenvolvimento (IAR, GCC, etc.) e plataformas de hardware (por exemplo, atmelsam7s64, msp430f449). Por exemplo, o subdiretório / Fonte / Portable / GCC / Atmega323 Contém arquivos port.c e portmakacro.h que implementam / restauram o contexto da tarefa, inicialize o temporizador para criar um banco de dados temporário, inicialize a pilha de cada tarefa e outras funções dependentes de hardware para os microcontroladores da família Mega AVR e Winavr compilador (GCC).

Separadamente, é necessário destacar o subdiretório / Fonte / Portable / Memmangque contém arquivos heap_l.c, heap_2.c, heap_3.cImplementando 3 mecanismos de alocação de memória diferentes para as necessidades dos freertos, que serão descritos em detalhes mais tarde.

O diretório / demo está pronto para projetos de demonstração de compilação e montagem. A parte total do código para todos os projetos de demonstração é destacada no subdreletório / Demonstração / vírion.

Para usar os freertos em seu projeto, você deve ativar o código-fonte do código-fonte do kernel e dos arquivos de cabeçalho associados. Não há necessidade de modificá-los ou entender sua implementação.

Por exemplo, se você planeja usar a porta para microcontroladores MSP430 e o compilador GCC, para criar um projeto - zero "será necessário pelo subdiretório / Fonte / Portable / GCC / MSP430_GCC e / Fonte / Portable / Memmang. Todos os outros subdiretórios do diretório / source / portáteis não são necessários e podem ser removidos.

Se estiver planejado modificar um projeto de demonstração existente (que, de fato, recomenda-se fazer no início do estudo dos freertos), então você também precisará do subdiretório / Demo / msp430_gcc e / Demo / comum. O restante do subdiretório em / demo não é necessário e pode ser removido.

Ao criar um aplicativo, recomenda-se usar makefile. (ou arquivo de desenvolvimento do ambiente de desenvolvimento) do projeto de demonstração correspondente como ponto de partida. É aconselhável excluir a partir dos arquivos de montagem (compilação) do diretório / demo, substituindo-os por seus próprios, e arquivos do diretório / source estão intactos. Também mencionar também sobre o arquivo de cabeçalho Frerstosconfig.h.que está localizado em cada projeto de demonstração. FreertoConFig.h contém definições (#define), permitindo a configuração do kernel do Freertos:

1. Um conjunto de funções do sistema.

2. Usando o spram.

3. Número de tarefas e construções

4. Tamanho da memória (pilha e montes).

5. A frequência do relógio MK.

6. O período de operação do planejador de tempo alocado a cada tarefa de execução, que é geralmente igual a 1 ms. Desativando algumas funções do sistema e reduza o número de prioridades (reduz o consumo de memória).

A distribuição do Freertos também é incluída ferramentas para converter informações de rastreamento recebidas do agendador, no formulário de texto (diretório / Tgssun.) e o texto da licença (diretório Licença.).

Conclusões

Com a ajuda do primeiro artigo do ciclo, o leitor ficou familiarizado com o sistema operacional para os microcontroladores de Freertos La. Mostrando características do trabalho. Descreveu o conteúdo da distribuição de freertos. Os principais passos da qual o desenvolvimento de um dispositivo que executa os freertos deve ser iniciado.

Nas seguintes publicações, será dada atenção ao mecanismo de multitarefa, nomeadamente, tarefas e transportadores. Uma amostra do planejador será amostra usando os microcontroladores Atmel AVR e o compilador Winavr (GCC).

Eu constantemente pergunto a essa pergunta durante o seu hobby, - o desenvolvimento de um sistema doméstico de controle automático (casa inteligente) baseado em um microcontrolador de 16 bits, é essa verdadeira abordagem? Um mês e meia atrás, eu já escrevi no meu blog no tópico "microcontroladores contra sistemas on-chip". Então, vou escrever sobre isso novamente.

Parcialmente isso foi solicitado pelo aparecimento de Stellaris Launchpad e Arduino devido. Ambos são baseados em microcontroladores de 32 bits e de várias maneiras, muito semelhantes. Eu estudei a especificação (folha de dados) para ambos, e embora eles sejam decentemente diferentes no preço, eles são projetados para um público-alvo. Pensei no que eu poderia me mover com o MSP430 para Stellaris, e pode até ser transferido para um sistema fundamentalmente diferente, para usar algo como Raspberry Pi, em vez de microcontroladores.

Ambos, Stellaris Launchpad e Arduino são muito poderosos, mas não pretendem executar o Linux. Eles operam em um código executável escrito diretamente para eles ou executando o sistema operacional de tempo real (RTOs), - minimalista do sistema operacional, com um tempo de resposta muito curto para eventos externos. Além disso, ambos são muito mais complicados do que o AVR de MSP430 ou 8 bits.

Por outro lado, na vida real (no exterior), a maioria dos quais conheço uso de framboesa PI ou outros sistemas integrados no Linux. O uso de microcontroladores, um caso bastante raro, entre aqueles que eu conheci. Mesmo Arduino, muito menos popular no meu entorno do que o Linux embutido. Como eu entendo, é por isso que comprar Arduino a alguém quando você pode comprar framboesa pi, que pode ser muito mais, e vale a mesma ou menos? Em Linux há uma enorme quantidade de software acabado, e pode ser programado usando linguagens scripts simples.

Para mim, pessoalmente, a razão pela qual eu não quero usar o Linux é porque eu o uso diariamente no trabalho, e voltando para casa, eu não sinto prazer da necessidade de trabalhar novamente em sistemas Linux. Não tenho problemas com o Linux, mas é muito em todos os lugares, ele me oprime. É muito mais interessante para mim trabalhar com dispositivos eletrônicos simples em microchips de 8/16 bits.

No entanto, não me afaste da realidade. Se eu quiser ficar na mesma onda com um mundo real, eu tenho que usar essas ferramentas usadas no mundo real. Caso contrário, parece um desejo de dirigir um carro com um motor a vapor, só porque o motor de combustão interna é muito engraçado, eu uso o tempo todo o tempo todo. Se o mundo em todo o mundo for para uma tecnologia mais avançada, você precisa dominá-lo, eu gosto ou não. Em particular, se eu quiser que meu blog esteja interessado em pessoas e permanecesse relevante.

Na minha casa inteligente do projeto, eu realmente encontrei esse problema. Eu já fiz um driver de rede local para o sistema de controle no MSP430, e tudo parece muito digno. Em essência, posso fazer tudo o que você precisa para um sistema de automação no MSP430. No entanto, penso em saber se estou fazendo isso? Eu estou tentando se há uma sopa de garfo quando há uma colher? Talvez Linux seja um sistema mais adequado? Deixe-me explicar.

Se você parar e olhar para a situação atual, de acordo com avanços tecnológicos em novembro de 2012. Eu me pergunto, são microcontroladores são bons e relevantes e são relevantes, comparados com os sistemas on-chip usando o Linux?

Se você listar projetos em sistemas embarcados que vêm para mim na cabeça, é: drones, robôs, automação residencial, controladores de motores, sensores, relógios de pulso, impressoras 3D, etc. Em qual desses casos, o Linux integrado é adequado mais do que microcontroladores? E porque?

Eu acho que existem três situações em que o microcontrolador é a melhor escolha: onde o instante (em tempo real) é importante para os eventos; onde é necessário para o consumo de energia extremamente baixo; E onde você precisa usar fichas o mais baixas possível.

Para começar, o uso de chips baratos, não tão importante para mim. Estou envolvido no meu hobby para mim e não vou produzir produtos competitivos. Eu não tenho que pensar sobre a transferência de produção para a planta que usa o trabalho escravo para ter um preço competitivo para os projetos menores que desejo. Eu ficaria feliz se pudesse, descompactar mais de um conselho por dia, graças às minhas habilidades!

Por exemplo, para o projeto de uma casa inteligente, posso desenvolver, interruptor controlado remotamente. Pode ligar / desligar a luz ou outra coisa. Ao mesmo tempo, posso ir para a loja elétrica da loja local e comprar o mesmo por US $ 20, produzido na China. Posso matar esse preço, tentando vender seu próprio interruptor? Eu não acho que é possível.

Se você pensar sobre isso, também se aplica a um conjunto de outras coisas necessárias para a automação residencial. Sensores de temperatura, fumaça, movimento, etc., sou capaz de fazer o mesmo, mas é improvável que você possa extrair benefícios financeiros. Quem se importa para comprar essas coisas por US $ 75, quando eles podem encontrá-los por US $ 20 em bens domésticos?

Se refletimos sobre a extração de algum tipo de benefícios do seu hobby, é melhor prestar atenção a produtos mais caros e complexos. Por exemplo, um controlador de automação residencial ou um termostato, geralmente custa mais de US $ 100, e deixe mais liberdade para a criatividade individual, você pode construir um, vender seus vizinhos e até mesmo ganhar algo nele.

Mas o desejo de alcançar um preço mais lucrativo do dispositivo final não significa que você precise usar o microcontrolador mais barato da Terra. Na verdade, é uma má ideia, porque O tempo de desenvolvimento faz o mesmo custo, assim como as partes usadas. Talvez um microcontrolador seja barato, mas requer mais tempo para escrever um código de controle. O tempo é dinheiro, e se você trabalha mais rápido, você terá tempo para conseguir mais.

Todas essas reflexões, resumem que é mais lucrativo desenvolver um sistema doméstico inteligente no Linux do que em microcontroladores, apesar de minhas preferências pessoais, não use Linux (eu gosto de uma programação de baixo nível mais do que scripts, Linux me pega entediado).

Se você retornar ao tópico do tópico, o preço dos microcontroladores, pode ser um fator importante para grandes corporações irá liberar um novo produto, mas em um nível individual, se você tentar realizar negócios no estilo do Kickstarter, esse fator é Não é mais significativo, na verdade, o tempo de desenvolvimento rápido, mais importante que o custo dos componentes.

Por outro lado, os microcontroladores podem ser a melhor escolha do que o sistema on-on-chip quando o baixo consumo de energia é necessário. Nesses sistemas existem dois pontos: baixo consumo do próprio diagrama, durante a operação e um curto período de tempo. Uma maneira típica de economizar bateria para dispositivos pequenos é auto-desligamento (desligamento). Quando você desliga o computador no Linux, ele precisa de um tempo decente para retornar ao trabalho, às vezes até alguns minutos. Este tempo não é aceitável para sistemas incorporados.

Se você fizer um microcontrolador como MSP430, ele poderá funcionar por anos de uma bateria. Stellaris Launchpad e Arduino devido, em princípio, o mesmo é capaz de tal, eles consomem mais energia do que o MSP430, mas ainda muito pouco, comparado ao Raspberry Pi. Além disso, o MSP430, pode começar instantaneamente, após o desligamento.

Assim, estou absolutamente confiante de que, em todas as situações em que as operações de baixa tensão são necessárias, faz sentido usar microcontroladores. Há um grande número de dispositivos diversos trabalhando em baterias onde tal necessidade surge.

No terceiro caso, como eu disse, o uso de um microcontrolador é mais significativo do que o Linux, em operações que exigem uma reação instantânea (resposta em tempo real). Quero dizer, tais dispositivos como impressoras 3D e máquinas CNC, eu sei do que estou falando, já que dediquei muito tempo para estudar. Por natureza, eles exigem alta precisão no trabalho, o que é ligeiramente menor do que depende completamente do tempo de resposta aos comandos.

Por exemplo, se você tiver uma serra circular que corta um pedaço de madeira ou metal no momento, você não pode parar o processo, devido ao fato de que ele controla isso, é preciso uma pausa para jogar fora dados da memória para disco ou algo outro na mesma veia. Qualquer pessoa que usasse um PC esteja familiarizada com rolamento aleatório, periodicamente decorrente durante o trabalho habitual. E agora imagine que você tenha uma grande máquina de perfuração, executando um PC, que de repente começa a verificar atualizações para Windows durante a operação e perfurar, perfure a tabela na qual vale a pena, porque O computador perdeu o controle sobre ele.

PCs e sistemas on-chip não pretendem trabalhar em tempo real, pelo menos com o Windows, mesmo com o Linux, mas por si só estão tentando se aproximar disso. Como exemplo, há um patch em tempo real para o kernel Linux, e um software CNC especial criado para este tipo. Não sou suficiente com este patch Linux, e não sei o quão flexível é, para completar eventos em tempo real. Mas acho que esta é apenas uma alternativa possível, porque Linux, quaisquer manchas caíram, nunca vencerão microcontroladores nesta área, devido aos seus sistemas de interrupção.
Em conclusão, quero dizer que passei muito tempo tentando encontrar áreas onde o uso de microcontroladores em meus projetos tem uma vantagem. E tudo parece a época da Dominação Mundial Raspberry Pi e Beaglebones. Esta é a situação atual na comunidade DIY. Na maioria dos casos, mais rápido e mais fácil de desenvolver nesses sistemas, por isso é muitas vezes a melhor escolha para a maioria dos projetos.

Somente áreas de dispositivos de baixa tensão, operações em tempo real e dispositivos de baixo custo permanecem para microcontroladores.

Não depende do fato de que os microcontroladores podem parecer mais divertidos que o PC. Isso é o que terá que vir para competir.

Tradução de inglês original post