O projeto
Embox já completou 9 anos, mas muitos não entendem o que é e com
o que é consumido e por que é necessário. Alguns dos que ouviram falar do projeto e sabem que esse é um sistema operacional, acreditam que a Embox é um "sistema operacional doméstico". De fato, a Embox foi concebida como uma tentativa de criar o "sistema operacional" deles com "blackjack e barcos", mas o principal é "blackjack e barcos". Ou seja, certas características ou sua combinação, que faltavam em outros projetos, foram colocadas em primeiro plano.
Obviamente, ninguém iria escrever um sistema operacional universal, mesmo com alguns chips. O slogan Embox - “Caixa de ferramentas essencial para o desenvolvimento incorporado” - implica que o projeto é voltado para sistemas embarcados. No entanto, esse conceito é muito amplo, inclui: Internet das coisas (IoT) e robôs, várias framboesas (RaPi) e sistemas de bordo, arduinki e ASU-TP, ... A lista, como você sabe, pode continuar por muito tempo, há lugares onde o Linux vive muito bem e há lugares em que o Linux é redundante e vários RTOS pequenos são usados. Neste artigo, eu gostaria de falar sobre o mundo incorporado em toda a sua diversidade e também sobre o lugar da Embox nele.
Computadores de placa única
Computadores industriais
Vamos começar com computadores de placa única. Muitos deles são feitos em design industrial. A maioria é baseada em processadores com arquiteturas ARM e x86. Muitas pessoas pensam que os processadores x86 não são usados nesse segmento e tudo se limita a
framboesas ,
beagleboards ,
bananas e assim por diante. Mas muito antes do RaPi, havia outras máquinas de placa única voltadas para o segmento industrial de PCs, o chamado fator de forma
PC / 104 . Eles tiveram desempenho inferior aos desktops convencionais, porque foram projetados para tarefas nas quais a confiabilidade prevalece sobre a funcionalidade. Pelo mesmo motivo, o Linux não era frequentemente usado como sistema operacional para essas plataformas de hardware; havia vários sistemas operacionais proprietários com propriedades em tempo real (
VxWorks ,
QNX ,
LynxOS e assim por diante ). Não escrevi “RTOS” (no qual incluí todos esses três sistemas operacionais) pelos motivos pelos quais muitas vezes o
Windows CE e seu desenvolvimento do
Windows Embedded estavam localizados nessas plataformas de hardware. E não mudo a língua para atribuir todo esse zoológico ao RTOS.
Pagadores individuais do consumidor
Malinki estabeleceu uma tendência completamente diferente. Na verdade, eles não são voltados para sistemas industriais em tempo real, mas para o segmento de consumidores, no qual a relação preço / funcionalidade é avaliada, e as framboesas (e análogos) estão significativamente à frente dos concorrentes nesse parâmetro. Afinal, quando você compra por US $ 30 a 50 condicionais, obtém uma unidade de sistema completa, com a qual é possível criar facilmente um dispositivo com funcionalidade bastante complicada usando as ferramentas do Linux. Isso é muito útil para prototipagem ou bricolage. Além disso, é claro, a framboesa pode ser usada como um PC ou um pequeno servidor. Portanto, distribuições Linux prontas são frequentemente usadas como sistema operacional, principalmente, é claro,
Raspbian - Debian para Raspberry Pi, ou uma distribuição com um nome engraçado para falantes de russo
Pidora - Fedora para RaspberryPi. Para outras plataformas semelhantes, também existem distribuições prontas fornecidas pelos fabricantes de equipamentos e pelas comunidades de SO (fabricantes). Concorde que, quando você precisa criar um protótipo, a maneira mais fácil é levar pacotes prontos, instruir, escrever funcionalidades em python. Como resultado, obtenha rapidamente um protótipo funcional.
Um exemplo é um robô que reconhece uma linha usando o OpenCV .
Linux em dispositivos embarcados
Mas o mundo incorporado é muito mais amplo que as placas de placa única ARM padrão. Além disso, eles compõem uma parte relativamente pequena de dispositivos, e sua principal contribuição é a popularização e simplificação da entrada no desenvolvimento de dispositivos dessa classe. Os dispositivos seriais são criados com base nos mesmos processadores (sistemas em um chip) ou similares, mas as placas são projetadas para a tarefa (projeto, dispositivo). Conseqüentemente, as distribuições padrão são pelo menos redundantes, porque geralmente usam algum tipo de gerenciador de pacotes, e você pode facilmente fornecer muita coisa interessante (mas desnecessária para resolver uma tarefa específica). Os dispositivos incorporados geralmente vêm com funcionalidade completa e até são chamados de firmware. Há outra classe de distribuições Linux para criar firmware. Essas distribuições permitem que você “instale” os pacotes necessários estaticamente - montando-os no sistema de arquivos raiz e não dinamicamente - usando o gerenciador de pacotes do repositório. Normalmente, essas distribuições podem ser construídas não apenas aplicativos e bibliotecas de aplicativos, mas também o kernel em uma determinada configuração. E muitas vezes também é um compilador cruzado, porque a compilação no próprio dispositivo não é pelo menos eficaz.
Projeto Yocto
Até o momento, o
projeto Yocto é a distribuição mais famosa (um projeto para criar distribuições). Por sua vez, é baseado em outro projeto
OpenEmbedded conhecido, que é um tipo de sistema de construção para distribuições Linux. Se você deseja usar o Raspberry Pi não como um sistema pequeno pronto, mas como um dispositivo personalizado com Linux, o
Yocto ou seus análogos serão uma ótima opção. Pessoalmente, não vejo grandes vantagens no uso de distribuições Linux não padrão com peças de ferro padrão, mas se você planeja desenvolver dispositivos semelhantes ou deseja aprender as próprias tecnologias, essa abordagem parece a mais promissora. Afinal, enquanto um hardware especializado está sendo desenvolvido, os programadores podem desenvolver e depurar suas partes do sistema (algoritmos, drivers, bibliotecas, ...). O que reduz bastante o tempo de desenvolvimento e, portanto, o notório TTM (time to market).
Openwrt
Outro projeto de firmware famoso baseado em Linux é o
OpenWRT . Tenho certeza de que aqueles que se divertem com a personalização de roteadores ouviram falar dele. Com base neste projeto, o firmware é feito para vários roteadores, que são um binário, incluindo o kernel e o sistema de arquivos raiz. O uso de firmware (em vez de distribuições universais) em sistemas embarcados está conectado à idéia de que a funcionalidade do sistema final é conhecida no momento de seu desenvolvimento, ou seja, mesmo que a versão do roteador seja atualizada, o firmware muda inteiramente com toda a funcionalidade (ou parte deste firmware é substituída de uma maneira especial). ) A instalação, por exemplo, de suítes de escritório, geralmente não é necessária e geralmente proibida, pois isso pode introduzir sua própria incerteza. Essa abordagem permite, entre outras coisas, economizar significativamente em hardware. Os mesmos roteadores, por exemplo, têm um processador muito menos potente e muito menos memória que as glândulas universais.
Sistemas em tempo real
Voltando ao tópico das calculadoras industriais, é necessário discutir o termo "sistema em tempo real". Muitas pessoas pensam que os sistemas em tempo real são mais rápidos. Isso é uma falácia. Provavelmente, está conectado a premissas históricas. Afinal, o próprio termo surgiu quando os carros estavam lentos. E o usuário percebeu que a reação do sistema pode ficar para trás de suas ações. O termo "tempo real" significava que o sistema precisava responder a quaisquer influências, incluindo ações do operador. Mas em computadores modernos, é improvável que o usuário (operador) note inibição. Na grande maioria dos casos, quando você clica no menu, ícone, botão, veremos imediatamente um redesenho da tela, a menos que tudo esteja em ordem (a Internet está lá, o processo não trava etc.). Mas se algo inesperado aconteceu, por exemplo, a conexão é perdida, veremos como os sistemas em tempo real diferem (devem diferir). Simplesmente reiniciaremos o smartphone comum. Mas se esse sistema controla a usina, você mesmo entende que isso nem sempre é possível. A partir disso, concluímos que o sistema em tempo real deve responder de maneira previsível e não rápida a qualquer evento ou conjunto de eventos, independentemente de seu estado e ambiente.
Linux em sistemas de tempo real
Naturalmente, houve (existem e haverá) tentativas de criar um sistema em tempo real a partir do Linux. O mais famoso é o
RTLinux , originalmente era um patch para Linux, substituindo o “
agendador completamente honesto ” original, mais precisamente, inserindo o seu próprio, que era uma das tarefas definidas pelo agendador do Linux. Esse agendador trabalhava em prioridades estáticas de tarefas; portanto, trabalhava muito mais previsivelmente. Mas não era mais o Linux, ou melhor, a funcionalidade do Linux não estava em tempo real.
ARINC-653
Outra abordagem para fornecer em tempo real, semelhante ao patch RT para Linux, é a abordagem exigida pelo padrão
ARINC653 ou a chamada abordagem
MILS . Essa abordagem implica que o sistema é projetado em camadas; a camada inferior implica um hipervisor muito leve, com base no qual tarefas de graus variados de criticidade são executadas em seções definidas estaticamente. Eu chamei o hipervisor de muito leve porque implica que ele tem a mais alta criticidade e, portanto, seu código (algoritmos) deve ser verificado o mais completamente possível (idealmente, a ausência de situações não processadas deve ser matematicamente comprovada). Portanto, o código deve ser o menor possível. Bem, e o Linux, como você provavelmente entendeu, está localizado em sua própria seção.
uCLinux
As tentativas de usar o Linux em sistemas embarcados começaram há muito tempo. Uma das primeiras foi uma tentativa de usar o Linux em sistemas em que não há suporte de hardware para memória virtual (MMU). Esse projeto foi chamado de
uCLinux e sua contribuição para o kernel Linux foi no modo
NOMMU ou MMU-less.
Linux em sistemas de tempo real
Para resumir as tentativas de usar o Linux em sistemas em tempo real, você precisa responder à pergunta de por que isso está acontecendo. Ou seja, por um lado, o Linux não é particularmente (no momento e em sua forma pura) adaptado para sistemas em tempo real e, por outro, são constantemente feitas tentativas para fazer isso. E isso acontece devido à introdução de restrições (substituindo o planejador, introduzindo um hipervisor, restrições ao uso de memória virtual e assim por diante). A resposta, na minha opinião, está na presença do Linux, uma gigantesca base de código. Esses são drivers, aplicativos e bibliotecas funcionais. Obviamente, se você deseja criar um sistema confiável, use peças prontas o máximo possível, porque o desenvolvimento de novas, seja lógica funcional ou driver, sempre contém a probabilidade de introduzir um erro. E como os sistemas modernos em tempo real têm requisitos funcionais bastante altos, a reutilização de funcionalidades prontas do Linux está se tornando cada vez mais tentadora. Em outras palavras, atualizar o Linux para um sistema em tempo real não parece tão caro comparado ao desenvolvimento da funcionalidade, embora baseado em um sistema operacional em tempo real, porque a confiabilidade de todo o sistema, e não apenas sua parte na forma do kernel do sistema operacional, deve ser confiável.
Windows em dispositivos incorporados
Quero voltar ao Windows por um tempo. No início da minha carreira, tive uma discussão com um desenvolvedor mais experiente de que o Windows não pode ser usado em sistemas confiáveis. Ao qual ele se opôs que, se você testar um sistema já completo com o software funcional necessário e proibir quaisquer alterações: atualizações, instalação de software etc., o sistema será confiável o suficiente para muitas tarefas, incluindo a que decidido. Agora não tenho dúvidas de que meu oponente estava certo, não eu. Além disso, até o antigo MS-DOS tem sido usado em sistemas industriais há muito tempo. O fato é que a multitarefa, que parece tão necessária, introduz incertezas. E se você executar um software que controla completamente todo o sistema, poderá obter um comportamento muito mais determinístico. Em outras palavras, se um número indefinido de tarefas girar no sistema, é improvável que seja possível obter certeza no trabalho de todas as funções do sistema. Portanto, a maneira mais fácil de aumentar a previsibilidade do sistema é limitar sua funcionalidade e, portanto, a rejeição da universalidade no tempo de execução. O que observamos de fato nos exemplos de uso do Linux em sistemas de tempo real mencionados acima.
Microcontroladores
O exemplo do MS-DOS como o SO básico para sistemas industriais em tempo real nos leva à idéia de que, se você usar apenas seu próprio software, poderá obter um comportamento previsível de todo o sistema. E é mesmo! É verdade que você precisa fazer uma reserva de que isso só é possível se a funcionalidade do sistema for pequena e claramente corrigida. Se toda a funcionalidade do sistema consiste em controlar o motor usando o GPIO e receber (transmitir) um conjunto limitado de comandos pela interface UART, não é necessário usar o sistema operacional, você pode criar firmware (o que é chamado de bare-metal). Essa abordagem é frequentemente usada em microcontroladores. Porém, como os microcontroladores se tornaram grandes (ARM de 32 bits com vários KB de RAM versus AVR de 8 bits ok com cem bytes de RAM), as solicitações de funcionalidade aumentaram. Agora, ao desenvolver firmware, eles usam pelo menos software de fabricantes, o que permite que você use alguns exemplos prontos para trabalhar com um microcontrolador, por exemplo,
STM32Cube .
RTOSes
Porém, como os requisitos de funcionalidade estão em constante crescimento, o firmware para microcontroladores está sendo cada vez mais fabricado com base nos chamados RTOS. Ao contrário dos grandes sistemas operacionais em tempo real, esses são projetos de código aberto relativamente pequenos, fornecendo acesso total a todo o código do sistema. Ou seja, existe uma combinação de conceitos: por um lado, o código pronto é usado e, por outro lado, o desenvolvedor tem acesso total a tudo no sistema, pode-se dizer firmware bare metal.
Existem muitos RTOS para microcontroladores. Portanto, é impossível contar sobre todos. Vou destacar apenas alguns, na minha opinião, projetos interessantes e brevemente falar sobre seus recursos.
FreeRTOS
Provavelmente um dos projetos RTOS mais populares agora é o
FreeRTOS . Alguns dizem que este não é um sistema operacional completo, mas apenas um agendador. Mas se você levar em consideração a discussão acima sobre bare-metal, o grande número de microcontroladores suportados e o fato de que muitos aplicativos são escritos e integrados, a pequena funcionalidade parece mais uma virtude do que uma desvantagem. Isso nos permitiu tornar-se um padrão de fato para microcontroladores, conforme está escrito no site do projeto.
Contiki
Contiki - RTOS desenvolvido por
Adam Dunkels , criador de pilhas TCP / IP conhecidas como lwIP e uIP. Eu diria que todo o sistema operacional é construído em torno da pilha de rede. A presença do suporte ao IPv6 e os pequenos requisitos de recursos tornam este projeto interessante para a criação de vários tipos de dispositivos sem fio.
RTEMS
RTEMS Executive em tempo real para sistemas multiprocessadores. Originalmente desenvolvido para as forças armadas, o acrônimo significa Executivo em tempo real para sistemas de mísseis e, em seguida, Executivo em tempo real para sistemas militares. Projeto de código aberto bastante antigo, mas ainda animado. Representante brilhante da abordagem libOS. Quando o software desenvolvido está vinculado a um sistema operacional já montado, que não é apenas o kernel, mas também todos os serviços disponíveis. Ele é compilado e entregue como uma biblioteca para o compilador, o que é bastante conveniente nos estágios iniciais de desenvolvimento.
eCos
Sistema operacional configurável incorporado do
eCos . Também um projeto bastante antigo, anteriormente muito popular. A idéia principal é criar um sistema operacional muito configurável, ou seja, incluir no kernel apenas o que você precisa.
Outras RTOS
A lista continua por algum tempo.
Vou mencionar outro projeto
NuttX abaixo. E para aqueles que estão interessados em uma lista mais detalhada, aconselho a assistir a
Wikipedia . Para microcontroladores, eu também
mencionaria ChibiOS / RT ,
MicroC / OS (µC / OS) ,
Nut / OS ,
RIOT . Mas é claro que tudo depende da tarefa.
Arduino
Eu acho que falar sobre incorporado seria incompleto sem mencionar o Arduino. Afinal, como o RaPi, eles são muito comuns e contribuíram muito para a popularização dos microcontroladores. Eu próprio sou bastante cético em relação ao tema do arduino, por isso vou pular as críticas aos fãs dessa tecnologia. Mas sobre o fato de ser uma tecnologia muito interessante, posso dar
um exemplo de uma máquina de pão, descrita em um hub Solução muito boa. Bem, ou o
exemplo já citado
com um robô que reconhece uma linha pelo openCV , mas o
arduino também é usado lá.
Microkernel
Nunca mencionei o conceito de microkernel, que, como muitas pessoas sabem, torna o sistema confiável e previsível. Por um lado, isso é verdade, mas por outro, como sempre, não é bem assim. Mais precisamente, é claro, é verdade, mas a crença de que esse conceito (arquitetura) transformará imediatamente seu sistema em um sistema rígido em tempo real é uma ilusão. : « , ». , . , , ? , , ? , ! , , , ( ). , , ,
L4 , . , ,
.
. . , .
Embox embedded systems
embedded-, Embox . , , , Embox. , , Embox? Embox , , - - (, Android). , Embox .
Embox. Embox-, , . , -. , , , RTEMS. , . “”, , . , TCL, . ( ), .
Linux
. , , : (UDP), , . Linux. x86 ARM. . , , . Linux, 500 . , #ifdef . , , . Embox , . Mybuild, , . , ( ) , .
Linux Linux
. Linux, - . Embox Linux. , Qt (embedded-)
SIP- . , Embox , .
POSIX- —
NuttX . - Embox, - — . Qt SIP-, , NuttX . .
, RTOS POSIX. ,
FreeRTOS RTEMS, POSIX Profile 52, « , , » . RTEMS
QtLinux
RTOS, , , , . , Linux , - ( , , .). , , , , , . . , , - , , , , . , , , . , .
Linux
Linux . , . ,
OpenCV . , , OpenCV RaPi, Arduino. : — , — , , Linux . , Embox Linux. OpenCV , .
, Linux .
— , -, . ,
.
Internet of Things
Embox, RTOS , .
stm32vl-discovery. Embox 16- MSP-430 c 512 . , , , , POSIX-, (light threads). , , , . “” IoT. . - . Embox, , , , . -, , , , . -, , .
CodeFreeze .
Conclusão
embedded . , , , -. , “” embedded. , , , - ! .
PS , Embox “embedded”, “
opensource ”. , !