Exécutez le logiciel «desktop» sur le microcontrôleur

Embox a participé au festival TechTrain IT. Comme la première fois, nous avons apporté les morceaux de fer et montré nos réalisations en direct. Nous en avons déjà écrit sur le Habré, mais on ne sait jamais qui :). Le téléphone VoIP , Qt et OpenCV ont été présentés, tous basés sur STM32F7-Discovery. En plus du stand, nous avons fait trois rapports. J'ai déjà décrit les idées du premier sur le projet ouvert sur un habr Dans cet article, je veux raconter les idées d'un autre de notre rapport, qui s'intitulait «Lancement d'un logiciel« de bureau »sur des microcontrôleurs» . Eh bien, saisissant cette occasion, je vais vous parler un peu de mes sentiments à propos du festival.

TechTrain

Tout d'abord, permettez-moi de vous parler un peu du festival lui-même. Celui qui n'est pas intéressé peut immédiatement revenir en arrière dans la section «Lancement du logiciel« Desktop »sur le microcontrôleur»

La première chose qui a attiré mon attention lors du festival a été beaucoup de monde. Nous sommes fatigués de nous tenir sur le stand, de parler, de mener une quête et de communiquer. D'un autre côté, c'était très amusant et intéressant, et surtout, nous avons eu beaucoup d'émotions positives, par exemple, plusieurs personnes nous ont dit que nous avions un bon blog sur le hub :). Les participants au festival venaient de divers domaines d’activité, et ne venaient même pas des TI, car le slogan du festival est «un grand festival pour les développeurs, les ingénieurs et les sympathisants». Il y avait beaucoup d'enfants, un garçon à la fin du festival a sorti une machine robot du stand et a joué avec. Ni le garçon ni le robot n'ont été blessés.

Pour rendre l'étendue du public plus compréhensible, je vais l'illustrer différemment. De nombreuses activités ont été réalisées lors du festival, dont l'une était une quête. Les participants à la quête devaient monter sur les stands, accomplir les tâches inventées et obtenir un tirage. Pour cela, quelqu'un a même obtenu un quadricoptère entier. Mais maintenant, ce n'est pas ça. Nous étions également l'un des endroits où vous pouviez obtenir un sceau. Nous avions préparé des tâches, y compris des questions. Les questions étaient simples, concernant les logiciels open source et les systèmes embarqués. Mais le contingent était si différent que certains en voulaient à la simplicité de la question, tandis que d'autres entraient dans la stupeur. Le dernier, nous avons naturellement aidé, expliqué (ou suggéré Google) des choses comme: "qui sont les créateurs du langage C", "ce qui est célèbre pour Linus Torvalds", "quelle est la différence entre un microprocesseur et un microcontrôleur" ou "qu'est-ce qu'un compilateur croisé". En conséquence, personne n'est parti sans imprimer. Soit dit en passant, c'était un peu étrange, mais étrangement, beaucoup de gens pouvaient facilement déchiffrer «GNU - GNU n'est pas Unix». Probablement préparé pour Stallman. :)

Le second découle du premier. Il y avait du divertissement pour un public très large. Par exemple, Habr a apporté un bac à sable. Certes, ce n'était pas un bac à sable local où vous pouvez obtenir une invitation pour un article, mais il était possible de se vautrer dans sa renommée. A propos des invitations dans le bac à sable, je n'ai pas pensé à demander, peut-être qu'ils ont donné comme dans un vrai bac à sable. Il y avait un club de vieux ordinateurs , on pouvait jouer dessus, ce que beaucoup faisaient. Il y avait des machines à sous du Musée des machines à sous soviétiques . Sberbank, offrait un espace détente, il était également possible d'y jouer déjà dans la play station. Il y avait des kickers oui IT traditionnels et bien d'autres divertissements. Malheureusement, nous avons dû travailler, donc je ne parle que de ce qui était visible depuis notre stand.

Le troisième et probablement le principal est que les organisateurs ont réussi à rassembler des représentants de pratiquement tous les domaines informatiques, du développement Web et des systèmes distribués aux systèmes embarqués. Des développeurs et autres techniciens, aux ressources humaines et simplement intéressés, par exemple, les joueurs (après tout, il était possible de pirater Romero lui-même) ou les amateurs de bricolage. Il y avait l'AQ de COMAQA, il y avait des chefs d' équipe de Burning Lead . Il y avait des communautés de différentes villes (Rostov, Tver, Krasnodar). En conséquence, les rapports et les stands étaient très différents dans le sujet. Par exemple, notre stand était situé entre la communauté des chefs d'équipe Burning Lead et le stand du Club des directeurs informatiques de Saint-Pétersbourg .

En conséquence, des gens d'horizons très différents se sont approchés de notre stand, il y avait des développeurs Web et des joues dotnet, il y avait JS et des avantages. Quelqu'un s'est souvenu qu'il faisait quelque chose sur l'AVR alors qu'il était encore à l'université, quelqu'un disait qu'il s'amusait avec RaPi ou Arduino. Il y avait beaucoup de poussins DotNet, beaucoup se demandaient si nous avions un .NET Micro Framework . Nous avons même pensé à ne pas le traîner vers nous. On s'attendait à ce qu'il y ait beaucoup de questions sur Rust. Bref, à mon avis, les organisateurs ont réussi à bien mettre en œuvre l'idée du festival «Découvrez ce que vivent les autres!». Après tout, comme dans n'importe quel festival, l'essentiel ici est de voir les autres et de se montrer :).

Oui, les photos ne sont pas données ici. Quelques photos , y compris avec un garçon vivant Volodya, peuvent être vues dans notre groupe. Eh bien, bien sûr, dans le groupe techtrain, un tas de photos de haute qualité, ils ont promis d'en publier plus.

Lancer le logiciel de bureau sur un microcontrôleur

Mon rapport était une sorte de résumé des résultats de plusieurs de nos travaux sur le lancement de logiciels de bureau ( Qt , OpenCV , pjsip ). Le rapport s'adresse au grand public. Pour un habr j'essaierai de réduire beaucoup de détails, et pour les choses nécessaires je donnerai le lien ou les mots-clés pour la recherche.

Pour commencer, je vais donner une sorte d’ordre du jour. En fait, il y aura 3 parties. Tout d'abord, j'expliquerai les difficultés de transfert de logiciels de bureau vers des microcontrôleurs, et en cours de route, j'expliquerai la différence entre le microcontrôleur et le microprocesseur. Je vais également répondre à une question clé, par exemple, bayan de chèvre , pourquoi exécuter un logiciel de bureau sur un microcontrôleur, et enfin, je vais vous dire comment nous avons pu réduire considérablement le coût de transfert de ce logiciel de «bureau» vers des microcontrôleurs.

Quelle est la différence entre les microcontrôleurs et les microprocesseurs

Donc, une de nos questions sur la quête a sonné et peut-être sous l'influence de cela, un article est apparu sur un programmeur typique expliquant en quoi elles diffèrent. Je suis d'accord avec tout dans l'article, mais nous essaierons de l'expliquer dans nos propres mots et de faire plusieurs autres accents.

Qu'est-ce qu'une microcontrôleur (MCU)? Si vous regardez Wikipedia , vous pouvez comprendre qu'un microcontrôleur est un système sur une puce, c'est-à-dire qu'un processeur et des périphériques sont situés sur une seule puce.

Le terme système sur puce (System-on-a-Chip, SoC) est un concept plus large qu'un microcontrôleur. Il s'agit d'un tel circuit électronique intégré dans une seule puce, qui contient un microprocesseur (CPU) et des périphériques. Dans tout téléphone mobile, il y a une puce dans laquelle, en plus de plusieurs cœurs de processeur, il y a un tas de périphériques. Même les processeurs x86 incluent désormais des ponts et même des GPU. Mais je veux me concentrer non pas sur un classement clair, mais sur les fonctionnalités. Tout le monde sait que les systèmes sur puce:

• Consommez moins
• Sont moins chers
• Moins productif

Tout le monde ne sait pas qu'ils sont encore plus fiables en réduisant le nombre de contacts et peuvent avoir une plus grande plage de température.

Le microcontrôleur a une intégration encore plus grande et comprend également de la mémoire (RAM et ROM), qui est également référée à la périphérie. En conséquence, les propriétés sont préservées, consomment encore moins, coûtent encore moins, encore moins productives, encore plus fiables.

Je veux parler de «encore moins productif» plus en détail. Le fait est que, d'une part, c'est vrai, prenez n'importe quel CPU ou SoC à usage général moderne et voyez des performances nettement supérieures dans ce qu'on appelle les DMIPS . Mais si vous pensez pourquoi une telle performance? À titre d'exemple, je vais donner les jeux Quake and Doom (dont le créateur était John Romero au festival), ils ont très bien fonctionné sur le Pentium MMX. Mais les performances des systèmes basés sur ce CPU sont déjà bloquées par des microcontrôleurs haut de gamme. Je veux dire STM32F7 ou même STM32H7 . Autrement dit, sur la base de ces MCU, il est tout à fait possible d'exécuter des applications de niveau Doom et Quake, ce qui, vous en convenez, n'est pas mauvais du tout.

Parlons d'une autre caractéristique du MCU - la mémoire interne. Elle, comme je l'ai dit, se trouve directement sur la puce et, par conséquent, est très rapide. Mais elle, bien sûr, ne suffit pas. Mais combien peu? Le microcontrôleur STM32F769 contient 2 Mo de mémoire flash (ROM) et 512 + 16 + 4 ko SRAM (RAM). De plus, par exemple, la carte STM32F769i-disco possède également une mémoire externe (SDRAM 128 Mbit et mémoire Flash Quad-SPI 512 Mbit), qui est adressée directement. Je ne parle même pas de la possibilité de connecter une carte SD ou USB. Eh bien, si vous vous souvenez de la célèbre phrase «640 kb devrait suffire à tout le monde», alors la question raisonnable se pose - pourquoi les logiciels de bureau modernes sont-ils si gourmands? Par exemple, une calculatrice dans Windows 10 en mode veille consomme jusqu'à 16 Mo de mémoire.

Passons à la prochaine fonctionnalité du MCU, la présence de la ROM. En fait, les systèmes dotés d'un CPU contiennent également une ROM; l'exécution démarre à partir de celle-ci et le BIOS démarre, mais le reste du logiciel est chargé dans la RAM et exécuté à partir de celle-ci. Dans les systèmes embarqués, il est habituel d'exécuter du code directement, qui est appelé eXecute-In-Place (XIP), Linux, en passant, prend également en charge ce mode, mais l'essentiel est de tout charger dans la mémoire principale et même de l'exécuter. La possibilité d'exécuter directement à partir de la ROM est importante pour deux raisons: la première est l'architecture Harvard, la séparation du bus de commande et du bus de données vous permet d'augmenter la vitesse d'exécution du programme; la seconde - eh bien, naturellement, moins de mémoire est gaspillée, car au moins un segment de code n'a pas besoin d'être copié ailleurs.

Une autre caractéristique clé du MCU est l'absence d'un module tel que MMU , c'est-à-dire que les microcontrôleurs ne prennent pas en charge le matériel pour la gestion de la mémoire virtuelle . Dans le MCU, même pas tous ont des MPU , et le code s'exécute dans le même espace d'adressage, il est donc difficile d'organiser un fork complet () . Mais fork () lui-même, comme nous l'avons écrit dans l'article «fork () vs. vfork () »est un appel système assez lourd, et selon sa fonctionnalité, dans de nombreux cas, il peut être remplacé par vfork () ou posix_spawn ().

En résumé, en quoi les microcontrôleurs diffèrent des microprocesseurs, nous pouvons dire ce qui suit:
En termes de matériel:

• Les microcontrôleurs ont tous les périphériques nécessaires, y compris la mémoire
• Les microcontrôleurs ont beaucoup moins de mémoire
• Les microcontrôleurs n'ont pas de MMU matérielle
• Les microcontrôleurs ont une vitesse d'horloge inférieure et peuvent avoir une architecture de processeur différente (architecture cadeau)

En termes de propriétés de consommation:

• Les microcontrôleurs consomment moins d'énergie, peuvent fonctionner sur batterie
• Les microcontrôleurs sont moins chers
• Les microcontrôleurs sont plus fiables
• Les microcontrôleurs sont moins productifs

Pourquoi exécuter un logiciel de bureau sur un microcontrôleur

Ainsi, les microcontrôleurs sont moins productifs et étaient initialement destinés (et destinés) aux tâches de contrôle. Alors pourquoi exécuter sur eux un logiciel conçu pour une autre classe de systèmes? Eh bien, même si leur puissance est déjà suffisante pour de telles tâches, mais ces tâches peuvent être résolues de manière traditionnelle pour les microcontrôleurs. Autrement dit, pour utiliser divers petits RTOS ou écrire du code à partir de zéro, ce qu'on appelle le bare-metal. Il y a une réponse évidente, au départ les tâches de gestion étaient très simples, maintenant les exigences de fonctionnalité augmentent rapidement. Même à partir d'une ampoule minable dont ils attendent le contrôle via Internet, je ne parle pas de la bouilloire, ils vont probablement bientôt sélectionner la composition du thé selon l'humeur du propriétaire et chauffer la quantité optimale d'eau à la température optimale afin d'améliorer la situation environnementale. :)

Par conséquent, il n'est pas surprenant que des tentatives soient constamment faites pour utiliser le logiciel déjà développé dans les microcontrôleurs. Par exemple, ucLinux est l'une des premières tentatives largement connues pour exécuter Linux sur de petites plates-formes, maintenant c'est le mode NOMMU principalement Linux. L'idée était d'exécuter Linux sur des plates-formes matérielles sans MMU, mais nous avons découvert que c'est l'une des principales différences entre le CPU et le MCU.

En bref, les avantages d'utiliser un logiciel prêt à l'emploi:

• Réduisez les coûts de développement
• Délai de mise sur le marché plus court
• Réduction des erreurs dans le code. Les logiciels prêts à l'emploi sont plus fiables.

Comment nous le faisons chez Embox

Ici vous comprenez, vous pouvez parler très longtemps, mais encore une fois j'essaierai d'esquisser les points principaux dans une thèse et de manière accessible.

Le premier. Embox utilise le système de construction Mybuild avec son propre langage pour décrire les modules et les systèmes, nous l'avons écrit dans l'article «Mybuild - un système de construction pour les applications modulaires» . Ce système de construction vous permet de ne rien inclure de superflu dans l'image, ou plutôt d'inclure uniquement ce qui est requis. Vous pouvez vraiment affiner les caractéristiques du système, par exemple, pour exécuter PJSIP sur STM32F7, nous avons limité le nombre de paquets Ethernet à 16 en écrivant simplement une ligne dans le fichier de configuration du système

include embox.net.skbuff(amount_skb=16) 

Mybuild analyse les dépendances et génère divers artefacts, y compris les fichiers d'en-tête, les scripts de l'éditeur de liens et les Makefiles. Tout cela permet de réduire considérablement la quantité de mémoire requise et de ne pas inclure les parties qui ne sont pas du tout utilisées.

Le deuxième. De toute évidence, Embox doit prendre en charge POSIX et il est pris en charge. De plus, nous avons implémenté notre propre bibliothèque standard, car elle doit également être reconstruite en fonction de la configuration du système.

Le troisième. Liaison statique. Afin d'éviter les problèmes avec un seul espace d'adressage, de réduire la taille de l'image et de n'inclure que les parties requises, nous utilisons un lien statique. À différentes étapes, différentes parties du système sont assemblées, mais finalement tout (le noyau, tous les sous-systèmes, bibliothèques et applications) est lié en une seule image. Il contient toutes les informations sur tous les personnages de l'image. Et bien qu'à première vue, nous ayons de nombreuses applications avec des points d'entrée int (..) standard, mais dans l'image résultante, ce seront des caractères différents qui seront disponibles sur le système à partir de la ligne de commande.

Quatrièmement. Nous avons dû implémenter un runtime pour C ++, car de nombreuses applications et bibliothèques populaires utilisent des avantages.

Cinquièmement. Nous avons ajouté la possibilité d'utiliser le système de construction

  ./configure; make; make install 

Après avoir téléchargé la source quelque part et appliqué les correctifs nécessaires.

Conclusion

Aujourd'hui, les exigences fonctionnelles pour les systèmes qui étaient auparavant réalisés sur des microcontrôleurs ont considérablement augmenté. Les systèmes de contrôle devraient être compatibles avec les systèmes universels. Les caractéristiques des microcontrôleurs ont également considérablement augmenté, ce qui vous permet d'exécuter des logiciels sur eux avec les fonctionnalités correspondantes. Historiquement, les logiciels pour microcontrôleurs à des fins d'optimisation ont été écrits pour une tâche spécifique, mais avec une augmentation des exigences fonctionnelles, il est nécessaire d'appliquer des approches du monde des systèmes universels qui peuvent augmenter considérablement la fiabilité des logiciels, à savoir la réutilisation des modules, le développement distribué. Logiciel universel, bien qu'il ne prenne pas en compte les caractéristiques des systèmes embarqués, mais dispose de fonctionnalités nettement supérieures et fonctionnant bien. Par conséquent, l'utilisation de logiciels de bureau sur des microcontrôleurs donne un gain. En effet, d'une part, vous pouvez utiliser une plate-forme matérielle moins chère, plus fiable et moins consommatrice, et d'autre part, le coût de développement de tels systèmes est considérablement réduit.