Le projet
Embox a déjà 9 ans, mais beaucoup ne comprennent pas de quoi il s'agit et avec
quoi il est mangé et pourquoi il est nécessaire. Certains de ceux qui ont entendu parler du projet et savent qu'il s'agit d'un système d'exploitation, pensent qu'Embox est un «système d'exploitation domestique». En effet, Embox a été conçu comme une tentative de faire «leur» OS avec «blackjack et bateaux», mais l'essentiel est «blackjack et bateaux». C'est-à-dire que certaines caractéristiques ou leur combinaison, qui faisaient défaut dans d'autres projets, ont été mises en avant.
Bien sûr, personne n'allait écrire un système d'exploitation universel, même avec des puces. Le slogan Embox - «Boîte à outils essentielle pour le développement embarqué» - implique que le projet vise les systèmes embarqués. Cependant, ce concept est très large, il comprend: l'Internet des objets (IoT) et les robots, diverses framboises (RaPi) et systèmes embarqués, arduinki et ASU-TP, ... La liste, comme vous le savez, peut durer très longtemps, il y a des endroits où Linux vit bien, et il y a des endroits où Linux est redondant et divers petits RTOS sont utilisés. Dans cet article, je voudrais parler du monde embarqué dans toute sa diversité, et aussi de la place d'Embox en lui.
Ordinateurs à carte unique
Ordinateurs industriels
Commençons par les ordinateurs à carte unique. Beaucoup d'entre eux sont fabriqués en design industriel. La plupart sont construits sur des processeurs avec des architectures ARM et x86. Beaucoup de gens pensent que les processeurs x86 ne sont pas utilisés dans ce segment, et tout est limité aux
framboises , aux
beagleboards , aux
bananes , etc. Mais bien avant RaPi, il y avait d'autres machines à carte unique destinées au segment des PC industriels, ce qu'on appelle le facteur de forme
PC / 104 . Ils étaient inférieurs en termes de performances aux ordinateurs de bureau conventionnels, car ils étaient destinés à des tâches dans lesquelles la fiabilité l'emporte sur la fonctionnalité. Pour la même raison, Linux n'était pas souvent utilisé comme système d'exploitation pour ces plates-formes matérielles; il existait divers systèmes d'exploitation propriétaires avec des propriétés en temps réel (
VxWorks ,
QNX ,
LynxOS, etc. ). Je n'ai pas écrit «RTOS» (auquel j'inclus tous les trois de ces systèmes d'exploitation) pour la raison que, souvent,
Windows CE et son développement de
Windows Embedded étaient situés sur ces plates-formes matérielles. Et je ne tourne pas la langue pour attribuer tout ce zoo au RTOS.
Payeur unique consommateur
Malinki a établi une tendance complètement différente. En effet, ils ne visent pas les systèmes industriels en temps réel, mais le segment de la consommation, dans lequel le rapport prix / fonctionnalité est valorisé, et les framboises (et analogues) sont nettement en avance sur leurs concurrents dans ce paramètre. Après tout, lorsque vous achetez pour un prix conditionnel de 30 à 50 $, vous obtenez une unité centrale à part entière, avec laquelle vous pouvez facilement créer un appareil avec des fonctionnalités plutôt compliquées en utilisant des outils Linux. Ceci est très utile pour le prototypage ou le bricolage. De plus, bien sûr, la framboise peut être utilisée comme un PC ou un petit serveur. Par conséquent, les distributions Linux prêtes à l'emploi sont souvent utilisées comme système d'exploitation, tout d'abord, bien sûr,
Raspbian - Debian pour Raspberry Pi, ou une distribution avec un nom amusant pour les russophones
Pidora - Fedora pour RaspberryPi. Pour d'autres plates-formes similaires, il existe également des distributions prêtes à l'emploi fournies par les fabricants d'équipements et les communautés de systèmes d'exploitation (fabricants). D'accord, lorsque vous devez créer un prototype, le moyen le plus simple est de prendre des packages d'instructions prêts à l'emploi, d'écrire des fonctionnalités en python. En conséquence, obtenez rapidement un prototype fonctionnel.
Un exemple est un robot qui reconnaît une ligne à l'aide d'OpenCV .
Linux dans les appareils embarqués
Mais le monde intégré est beaucoup plus large que les cartes à carte unique ARM standard. De plus, ils constituent une part relativement petite des appareils, et leur principale contribution est la vulgarisation et la simplification de l'entrée dans le développement des appareils de cette classe. Les périphériques série sont créés sur la base des mêmes processeurs (systèmes sur puce) ou similaires, mais les cartes sont conçues pour la tâche (projet, périphérique). Par conséquent, les distributions standard sont au moins redondantes, car elles utilisent souvent une sorte de gestionnaire de packages, et vous pouvez facilement fournir beaucoup d'intéressants (mais inutiles pour résoudre une tâche spécifique). Les appareils intégrés sont généralement livrés avec des fonctionnalités complètes, et il est même appelé firmware. Il existe une autre classe de distributions Linux pour la création de firmware. De telles distributions vous permettent «d'installer» les packages nécessaires de manière statique - en les assemblant dans le système de fichiers racine, et non de manière dynamique - à l'aide du gestionnaire de packages du référentiel. En règle générale, ces distributions peuvent être construites non seulement pour les applications et bibliothèques d'application, mais également pour le noyau dans une configuration donnée. Et souvent aussi un compilateur croisé, car la compilation sur le périphérique lui-même n'est au moins pas efficace.
Projet Yocto
À ce jour, le
projet Yocto est la distribution la plus connue (un projet de création de distributions). À son tour, il est basé sur un autre projet
OpenEmbedded bien connu, qui est une sorte de système de construction pour les distributions Linux. Si vous souhaitez utiliser le Raspberry Pi non pas comme un petit système prêt à l'emploi, mais comme un appareil personnalisé avec Linux, alors
Yocto ou ses analogues seront une excellente option. Personnellement, je ne vois pas de grands avantages à utiliser des distributions Linux non standard avec des morceaux de fer standard, mais si vous prévoyez de développer des appareils similaires ou si vous souhaitez apprendre les technologies elles-mêmes, cette approche semble la plus prometteuse. Après tout, alors qu'un matériel spécialisé est en cours de développement, les programmeurs peuvent développer et déboguer leurs parties du système (algorithmes, pilotes, bibliothèques, ...). Ce qui réduit considérablement le temps de développement, et donc le fameux TTM (time to market).
Openwrt
Un autre célèbre projet de micrologiciel basé sur Linux est
OpenWRT . Je suis sûr que ceux qui s'amusent avec la personnalisation des routeurs ont entendu parler de lui. Sur la base de ce projet, le micrologiciel est conçu pour divers routeurs, qui sont un binaire, comprenant à la fois le noyau et le système de fichiers racine. L'utilisation du firmware (plutôt que des distributions universelles) dans les systèmes embarqués est liée à l'idée que la fonctionnalité du système final est connue au moment de son développement, c'est-à-dire que même si la version du routeur est mise à jour, le firmware change entièrement avec toutes les fonctionnalités (ou une partie de ce firmware est remplacée de manière spéciale ) Installer, par exemple, des suites bureautiques, n'est généralement pas nécessaire, et souvent généralement interdit, car cela peut introduire sa propre incertitude. Cette approche permet, entre autres, d'économiser considérablement sur le matériel. Les mêmes routeurs, par exemple, ont un processeur beaucoup moins puissant et beaucoup moins de mémoire que les glandes universelles.
Systèmes en temps réel
Revenant au sujet des calculatrices industrielles, il est nécessaire de discuter du terme «système en temps réel». Beaucoup de gens pensent que les systèmes en temps réel sont plus rapides. Ceci est une erreur. Probablement, il est lié à des locaux historiques. Après tout, le terme lui-même est né lorsque les voitures étaient lentes. Et l'utilisateur a remarqué que la réaction du système pouvait être à la traîne de ses actions. Le terme «temps réel» signifiait que le système devait être sensible à toutes les influences, y compris les actions de l'opérateur. Mais sur les ordinateurs modernes, il est peu probable que l'utilisateur (opérateur) remarque une inhibition. Dans la grande majorité des cas, lorsque vous cliquez sur le menu, l'icône, le bouton, nous verrons immédiatement une refonte de l'écran, à moins bien sûr que tout soit en ordre (Internet est là, le processus ne se bloque pas, etc.). Mais si quelque chose d'inattendu se produit, par exemple, la connexion est perdue, nous verrons comment les systèmes en temps réel diffèrent (devraient différer). Nous redémarrerons simplement le smartphone normal. Mais si ce système contrôle la centrale électrique, alors vous comprenez vous-même, ce n'est pas toujours possible. Nous en concluons que le système en temps réel devrait répondre de manière prévisible et non rapide à tout événement ou ensemble d'événements, quels que soient son état et son environnement.
Linux dans les systèmes en temps réel
Naturellement, il y a eu (et il y aura) des tentatives pour créer un système en temps réel à partir de Linux. Le plus célèbre est
RTLinux , à l'origine c'était un correctif pour Linux, remplaçant le "
planificateur complètement honnête " original, plus précisément, en insérant le sien, l'une des tâches définies par le planificateur Linux. Ce planificateur a fonctionné sur les priorités de tâches statiques; en conséquence, il a fonctionné de manière beaucoup plus prévisible. Mais ce n'était plus Linux, ou plutôt, la fonctionnalité Linux n'était pas en temps réel.
ARINC-653
Une autre approche pour fournir en temps réel, quelque peu similaire au patch RT pour Linux, est l'approche requise par la norme
ARINC653 ou l'approche dite
MILS . Cette approche implique que le système est conçu en couches, la couche inférieure implique un hyperviseur très léger, basé sur les tâches de degrés de criticité variables qui sont effectuées dans des sections définies statiquement. J'ai appelé l'hyperviseur très léger car cela implique qu'il a la plus haute criticité et donc son code (algorithmes) doit être vérifié aussi complètement que possible (idéalement, l'absence de situations non traitées doit être prouvée mathématiquement). Par conséquent, le code doit être aussi petit que possible. Eh bien, et Linux, comme vous l'avez probablement compris, se trouve dans sa propre section.
uCLinux
Les tentatives d'utilisation de Linux dans des systèmes embarqués ont commencé il y a longtemps. L'une des premières a été une tentative d'utilisation de Linux dans des systèmes où il n'y a pas de support matériel pour la mémoire virtuelle (MMU). Ce projet s'appelait
uCLinux et sa contribution au noyau Linux était le mode sans
NOMMU ou MMU.
Linux dans les systèmes en temps réel
Pour résumer les tentatives d'utilisation de Linux dans les systèmes en temps réel, vous devez répondre à la question de savoir pourquoi cela se produit. Autrement dit, d'une part, Linux n'est pas particulièrement (pour le moment et dans sa forme pure) adapté aux systèmes en temps réel, et d'autre part, il y a des tentatives constantes de le faire. Et cela se produit en raison de l'introduction de restrictions (remplacement du planificateur, introduction d'un hyperviseur, restrictions sur l'utilisation de la mémoire virtuelle, etc.). La réponse, à mon avis, réside dans la présence de Linux une gigantesque base de code. Ce sont des pilotes, ce sont des applications et des bibliothèques fonctionnelles. Évidemment, si vous voulez créer un système fiable, vous devez utiliser autant que possible des pièces prêtes à l'emploi, car le développement de nouvelles pièces, que ce soit la logique fonctionnelle ou un pilote, contient toujours la probabilité d'introduire une erreur. Et comme les systèmes modernes en temps réel ont des exigences fonctionnelles assez élevées, la réutilisation de fonctionnalités prêtes à l'emploi sous Linux devient de plus en plus tentante. En d'autres termes, la mise à niveau de Linux vers un système en temps réel ne semble pas si coûteuse par rapport au développement de fonctionnalités, bien que basée sur un système d'exploitation en temps réel, car la fiabilité de l'ensemble du système, et pas seulement sa partie sous la forme du noyau du système d'exploitation, doit être fiable.
Windows dans les appareils intégrés
Je veux revenir à Windows pendant un certain temps. À l'aube de ma carrière, j'ai eu une discussion avec un développeur plus expérimenté que Windows ne peut pas être utilisé dans des systèmes fiables. À quoi il s'est opposé, si vous testez un système déjà terminé avec le logiciel fonctionnel nécessaire et interdisez tout changement: mises à jour, installation de logiciel, etc., le système sera suffisamment fiable pour de nombreuses tâches, dont celle que décidé. Maintenant, je n'ai aucun doute que mon adversaire avait raison, pas moi. De plus, même l'ancien MS-DOS est utilisé dans les systèmes industriels depuis très longtemps. Le fait est que le multitâche, qui semble si nécessaire, introduit de l'incertitude. Et si vous exécutez un logiciel qui contrôle complètement l'ensemble du système, vous pouvez obtenir un comportement beaucoup plus déterministe. En d'autres termes, si un nombre indéfini de tâches tournent dans le système, il est peu probable qu'il soit possible d'obtenir une certitude dans le travail de toutes les fonctions du système. Par conséquent, le moyen le plus simple d'augmenter la prévisibilité du système est de limiter sa fonctionnalité, et donc le rejet de l'universalité lors de l'exécution. Ce que nous observons en fait dans les exemples d'utilisation de Linux dans les systèmes temps réel mentionnés ci-dessus.
Microcontrôleurs
L'exemple de MS-DOS comme système d'exploitation de base pour les systèmes temps réel industriels nous amène à l'idée que si vous utilisez uniquement votre propre logiciel, vous pouvez obtenir un comportement prévisible de l'ensemble du système. Et ça l'est vraiment! Certes, vous devez faire une réservation que cela n'est possible que si la fonctionnalité du système est petite et clairement fixée. Si toutes les fonctionnalités du système consistent à contrôler le moteur à l'aide du GPIO et à recevoir (transmettre) un ensemble limité de commandes via l'interface UART, alors il n'est pas nécessaire d'utiliser le système d'exploitation, vous pouvez créer un firmware (ce qu'on appelle le bare-metal). Cette approche est souvent utilisée dans les microcontrôleurs. Mais depuis que les microcontrôleurs sont devenus volumineux (ARM 32 bits avec plusieurs Ko de RAM contre AVR-ok 8 bits avec cent octets de RAM), les demandes de fonctionnalités ont augmenté. Désormais, lors du développement de micrologiciels, ils utilisent au moins des logiciels de fabricants, ce qui vous permet d'utiliser des exemples prêts à l'emploi pour travailler avec un microcontrôleur, par exemple,
STM32Cube .
RTOS
Mais comme les exigences de fonctionnalité sont en constante augmentation, le micrologiciel des microcontrôleurs est de plus en plus fabriqué sur la base du soi-disant RTOS. Contrairement aux grands systèmes d'exploitation en temps réel, il s'agit de projets open source relativement petits offrant un accès complet à tout le code du système. Autrement dit, il existe une combinaison de concepts: d'une part, du code prêt à l'emploi est utilisé, et d'autre part, le développeur a un accès complet à tout dans le système, vous pouvez dire un micrologiciel nu.
Il y a beaucoup de RTOS pour les microcontrôleurs. Par conséquent, il est impossible de parler de tous. Je ne citerai que quelques-uns, à mon avis, des projets intéressants et parlerai brièvement de leurs caractéristiques.
FreeRTOS
L'un des projets RTOS les plus populaires est probablement maintenant
FreeRTOS . Certains disent que ce n'est pas un système d'exploitation complet, mais seulement un planificateur. Mais compte tenu des discussions ci-dessus sur le bare-metal, le grand nombre de microcontrôleurs pris en charge et le fait que de nombreux logiciels d'application sont écrits et intégrés, la petite fonctionnalité ressemble plus à une vertu qu'à un inconvénient. Cela nous a permis de devenir une norme de facto pour les microcontrôleurs, comme cela est écrit sur le site Web du projet.
Contiki
Contiki - RTOS développé par
Adam Dunkels , créateur de piles TCP / IP bien connues comme lwIP et uIP. Je dirais que l'ensemble du système d'exploitation est construit autour de la pile réseau. La présence de la prise en charge IPv6 et les faibles besoins en ressources rendent ce projet intéressant pour la création de différents types d'appareils sans fil.
RTEMS
RTEMS Real-Time Executive pour systèmes multiprocesseurs. Développé à l'origine pour les militaires, l'acronyme signifie Real-Time Executive pour les systèmes de missiles, puis Real-Time Executive pour les systèmes militaires. Projet open source assez ancien mais toujours vivant. Représentant brillant de l'approche libOS. Lorsque le logiciel développé est lié à un OS déjà assemblé, qui n'est pas seulement le noyau, mais aussi tous les services disponibles. Il est compilé et fourni sous forme de bibliothèque au compilateur, ce qui est assez pratique dans les premiers stades de développement.
eCos
Système d'exploitation configurable intégré
eCos . Également un projet assez ancien, auparavant très populaire. L'idée principale est de créer un système d'exploitation très configurable, c'est-à-dire d'inclure dans le noyau uniquement ce dont vous avez besoin.
Autres RTOS
La liste continue depuis un certain temps.
Je mentionnerai un autre projet
NuttX ci-dessous. Et pour ceux qui sont intéressés par une liste plus détaillée, je vous conseille de regarder
Wikipedia . Pour les microcontrôleurs, je
mentionnerais également
ChibiOS / RT ,
MicroC / OS (µC / OS) ,
Nut / OS ,
RIOT . Mais bien sûr, tout dépend de la tâche.
Arduino
Je pense que parler d'embarqué serait incomplet sans mentionner Arduino. Après tout, comme RaPi, ils sont très courants et ont grandement contribué à la popularisation des microcontrôleurs. Je suis moi-même plutôt sceptique sur le thème de l'arduino, donc je vais ignorer les critiques des fans de cette technologie. Mais sur le fait qu'il s'agit d'une technologie très intéressante, je peux donner
un exemple de machine à pain, décrite sur un hub Très belle solution. Eh bien, ou l'
exemple déjà cité
avec un robot qui reconnaît une ligne par openCV , mais
arduino y est également utilisé.
Microkernel
Je n'ai jamais mentionné le concept d'un micro-noyau qui, comme beaucoup le savent, rend le système fiable et prévisible. D'un côté, c'est vrai, mais de l'autre, comme toujours, pas tout à fait. Plus précisément, bien sûr, c'est vrai, mais croire que ce concept (architecture) transformera immédiatement votre système en un système dur en temps réel est une illusion. C’est plutôt un slogan marketing: «nous sommes un système en temps réel car nous sommes construits sur le principe d’un micronoyau». Mais le principe d'un micro-noyau permet simplement de simplifier le développement logiciel, puisque la plupart des pièces sont réalisées dans l'espace utilisateur. Mais que faire si vous avez un serveur cassé, ce qui est nécessaire pour travailler? Vous le redémarrez, mais cela prend du temps, et si vous ne l’avez pas? De plus, l'architecture micro-noyau classique a ses inconvénients! Par exemple, c'est lent, car il y a beaucoup d'appels système (transferts de messages entre serveurs et logiciels d'application). Sinon, tout le monde serait passé à une architecture micro-noyau pure depuis longtemps, et qui, par exemple, a vu des
projets sur L4 , mais ils le sont. Eh bien, et bien sûr, beaucoup se souviennent de l'
argument de Linus Torvalds avec Andrew Tanenbaum .
Autrement dit, le concept de micronoyau n'est pas une solution miracle. Mais comme une très bonne idée, elle est appliquée à un degré ou à un autre dans la plupart des systèmes d'exploitation modernes. Et la création d'un système fiable à la fin dépend toujours du développeur final et des capacités que le système d'exploitation fournit pour sa construction.
La place d'Embox dans les systèmes embarqués
J'ai déjà beaucoup parlé de divers aspects du monde embarqué, mais je n'y suis jamais allé à la place d'Embox. Eh bien, je peux dire que dans les exemples décrits ci-dessus, il peut ne pas être nécessaire d'utiliser Embox. De plus, nous demandons généralement aux utilisateurs pourquoi ils ont besoin d'Embox? Si l'utilisation d'Embox ne donne aucun avantage, nous vous recommandons d'essayer quelque chose dans la liste ci-dessus ou autre chose (par exemple, Android). Mais il existe un certain nombre de cas dans lesquels l'utilisation d'Embox donne un gain tangible.
Système de développement d'équipement
Je vais commencer par la première utilisation d'Embox. Il n'était même pas un Embox à l'époque, mais était une sorte de code C et assembleur, qui vous permettait de démarrer très rapidement et d'exécuter du code utilitaire. À ce moment, c'était un projet pour aider les ingénieurs à déboguer les équipements développés dans les FPGA. , , , 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 .
Conclusion
embedded . , , , -. , “” embedded. , , , - ! .
PS , Embox “embedded”, “
opensource ”. , !