L'écriture de firmware pour les intérieurs de l'électronique embarquée moderne est pratiquement impossible à écrire à partir de zéro. Ils ne donnent tout simplement pas de temps pour cela. Par conséquent, le logiciel pour les systèmes embarqués est basé sur
plates-formes logicielles prêtes à l'emploi - cadres. Plus le cadre est développé, plus le développement est rapide. Ici, nous allons parler du cadre que j'ai créé spécifiquement pour les modules de commande de moteur et qui a été utilisé avec succès depuis un certain temps maintenant.
L'architecture du cadre.
Le cadre est conçu pour fonctionner sur la plate-forme ouverte du module de commande de moteur universel
DMC v2.0 .
L'architecture logique du cadre peut être représentée sous la forme d'un schéma fonctionnel, illustré ci-dessous. Dans l'organigramme, une liste complète de tous les composants du cadre est omise, car cela nuirait à la clarté, mais pour une idée générale, je pense, la granularité est suffisante.
(Cliquer pour agrandir)Le framework n'a pas de versions, il est en développement constant, et ici j'ai juste essayé de corriger son état actuel, qui est posté sur GitHub.
Du point de vue des modules logiciels, le framework contient les éléments clés suivants:
- Un ensemble de modules de support au niveau application
- Système d'exploitation en temps réel
MQX .
- Middleware:
système de fichiers, shell de commande, piles de protocoles de communication , etc.
- Un ensemble de support de carte de bas niveau (BSP), qui comprend l'
accès aux périphériques des cartes de module BLEZ66V1 et du module d'alimentation.
- Progiciel pour la
surveillance, le débogage et les diagnostics -
FreeMaster .
- Outils de débogage, y compris
RTT , traçage des outils
ITM , enregistreurs, terminal
VT100 .
- Module de
génération de fichiers de paramètres.
- Modules de codes sources générés basés sur des algorithmes dans
Matlab .
Pourquoi MQX est-il sélectionné?
Le système d'exploitation en temps réel (RTOS) MQX est connu depuis longtemps, mais
est apparu dans le domaine public il y a quelques années. Ce système d'exploitation a été téléchargé par Freescal avant que NXP ne les achète. RTOS avait initialement une licence uniquement pour une utilisation dans les microcontrôleurs Freescale, maintenant la licence s'étend également aux produits NXP. RTOS a survécu à une popularité explosive, a subi plusieurs mises à niveau vers la version 4.2, après quoi Freescale a décidé de rendre à nouveau ses versions ultérieures commerciales. Il s'est donc avéré deux versions, une ouverte et gelée en développement appelée MQX Classic (alias MQX v4.2) et une MQX 5.0 commerciale fermée.
Dans le cadre décrit, la branche MQX Classic v4.2 est utilisée. Il s'agit d'une version stable et bien testée. La licence permet au développeur de modifier le code source de MQX Classic et de l'utiliser dans des produits commerciaux, mais elle ne permet pas la publication de MQX Classic sous forme source. Mais cela ne devrait pas être un problème, car MQX Classic est disponible en téléchargement gratuit.
La structure de RTOS en termes généraux ressemble à ceci:
Pourquoi ai-je besoin de RTOS?
Une application complexe où, en particulier, un contrôle moteur est requis est assez complexe et se compose de nombreuses tâches asynchrones, chacune avec son propre cycle de répétition et ses événements d'activation et d'arrêt. Si nous effectuons toutes ces tâches dans un supercycle, nous rencontrons inévitablement le problème de retarder l'exécution de certaines tâches par d'autres tâches.
En utilisant RTOS, comme MQX, il est possible de se débarrasser de l'interdépendance des tâches individuelles sur l'axe du temps sans les réécrire ni même regarder leurs codes sources.
Par exemple, notre tâche d'enregistreur peut essayer d'écrire un message aussi longtemps que souhaité sur une carte SD en attente de sa réponse, la tâche USB peut toutes aller au transfert d'une grande quantité de données vers un ordinateur, mais en même temps la tâche PID de l'algorithme du moteur sera effectuée strictement à un intervalle spécifié, et la tâche de mesure de vitesse la rotation ne manquera pas un seul événement de changement de signal d'encodeur.
Bien que je dois admettre, il existe un autre moyen de plus en plus populaire de se débarrasser de la complexité sur une seule puce: passer au multitraitement, mais dans ce cas, RTOS fournira un bon service.
Les principaux avantages de RTOS MQX.
- Le noyau du système est livré avec une large gamme de middleware comprenant un système de fichiers, une pile TCP / IP, une pile USB, un shell de commande, etc. Tout dans le code source.
- Ensembles BSP prêts à l'emploi pour différentes cartes, éliminant le besoin d'écrire vos propres bibliothèques de travail périphériques.
- Documentation détaillée dans des fichiers pdf avec une navigation facile.
- La présence d'un plug-in pour l'atelier intégré IDE IAR avec des informations très détaillées sur les structures internes de RTOS, est beaucoup plus détaillée que pour d'autres RTOS bien connus - uCOS et FreeRTOS.
- Beaucoup d'exemples d'application RTOS et de cas de test.
Lorsqu'ils parlent de RTOS, ils soulignent toujours leur capacité à effectuer les tâches à temps, mais les estimations quantitatives ne sont le plus souvent pas données ou données pour certaines plateformes tierces sélectionnées séparément. Ce n'est clairement pas suffisant pour implémenter un contrôle dur en temps réel à l'aide de RTOS. Et pour contrôler les moteurs dont vous avez besoin en temps réel, il est exactement difficile.
MQX dispose d'un merveilleux cas de test à cet égard, qui vous permet d'obtenir un tableau détaillé du temps d'exécution de tous les services sur la plate-forme sur laquelle vous avez lancé le test.
Vous trouverez ci-dessous un tableau du temps d'exécution des services sur le microcontrôleur de notre module de contrôle moteur, avec l'optimisation maximale pour la vitesse d'exécution du code incluse dans le compilateur.
Temps d'exécution du service RTOS MQX Classic Le tableau donne également une idée des services pris en charge par RTOS et des options de noyau disponibles. Le projet de test dans l'IDE IAR est inclus dans le cadre publié.
Composition du répertoire du projet
Le répertoire racine du framework ressemble à ceci:
APP_SRC - un répertoire contenant toutes les sources sauf celles qui appartiennent à la distribution MQX.
FreeMaster_apps - fichiers de projet à exécuter dans l'environnement
FreeMaster .
IAR_proj - espace de travail et fichiers de projet pour le plan de travail intégré IAR pour l'environnement ARM v7.70.2. Dans cet environnement, l'application finale est compilée et déboguée.
MQX_SRC est un répertoire contenant toutes les sources de MQX et middleware fournis avec MQX. Étant donné que la licence ne permet pas la publication open source à partir de la distribution MQX, il n'y a pas
de fichiers "
.s" et "
.s" dans ce répertoire. Mais ceux qui acceptent les termes de la licence NXP peuvent recevoir les fichiers manquants.
ParametersManager - répertoire du programme du gestionnaire de paramètres. À l'aide de ce programme, des listes de paramètres d'application sont créées et
des fichiers «
.s» et «
.h» sont générés avec des déclarations de paramètres à intégrer dans l'application.
TESTS - un répertoire avec des projets de test de framework. Voici le projet
MQX_benchmark pour générer un rapport avec des timings MQX.
Les fichiers
MQX_LIBRARY_O0.a et
MQX_LIBRARY_O3.a sont le contenu du répertoire
MQX_SRC compilé dans des bibliothèques avec une optimisation minimale et une optimisation maximale, respectivement.
Le contenu du répertoire IAR_proj
Les fichiers
U3HB_full.eww et
U3HB_MQXLib.eww sont les fichiers d'
espace de travail IAR .
Tant qu'il n'y a pas de sources dans le répertoire MQX, seul le fichier
U3HB_MQXLib.eww fonctionnera . Cet espace de travail utilise des bibliothèques MQX compilées. Dans l'
espace de travail U3HB_full.eww, les sources MQX complètes sont compilées. Le répertoire
OUT sert de lieu où l'IAR place ses produits de travail, en particulier les fichiers de carte et hexadécimaux.
Le répertoire des
paramètres est automatiquement créé par l'IAR. Il stocke spécifiquement les paramètres du débogueur. Si quelque chose ne peut pas être configuré pendant le débogage dans l'IAR, il vaut parfois la peine d'effacer ce répertoire.
Le fichier
INT_FLASH_MK66FX1M0LVQ18.icf est un fichier de configuration de l'éditeur de liens IAR. Il détermine les adresses des régions de mémoire où l'éditeur de liens place le code, les données, les vecteurs d'interruption, les piles, etc.
Le contenu du répertoire MQX_SRC
Les fichiers d'espace de travail
MQX_LIBRARY.eww sont utilisés pour créer des bibliothèques MQX. Tant que les fichiers «
.s » et «
.s» ne seront pas placés dans les répertoires, ce projet ne sera pas compilé.
config - le répertoire avec les fichiers de configuration MQX. La composition des services et pilotes MQX est spécifiée dans le
fichier de configuration
user_config.h .
mfs - système de fichiers MQX, comprend FAT32 et RAM FS
mqx - le noyau MQX comprend les sous-répertoires suivants:
rtcs - pile TCP / IP. Il comprend les sous-répertoires suivants:
shell - un répertoire avec des fichiers shell.
usb - répertoire avec fichiers de pile USB
La fonctionnalité de chaque module logiciel MQX est bien documentée par le fabricant. À titre d'exemple, je fournirai des liens vers deux documents:
→
Instructions d'utilisation du MQX .
→
Guide de référence MQX.Le reste doit être recherché dans la distribution,
qui est disponible sur le site NXP .
Le cadre lui-même est dans le référentiel
ici .
Vous trouverez une description plus détaillée de l'utilisation des logiciels et des exemples d'application dans les articles suivants.