Ein offenes Projekt eines Elektromotor-Steuermoduls. Softwareentwicklungstechnologie

Das Schreiben von Firmware für die Innenräume moderner eingebetteter Elektronik ist praktisch nicht von Grund auf neu zu schreiben. Sie geben einfach keine Zeit dafür. Daher basiert Software für eingebettete Systeme auf
fertige Softwareplattformen - Frameworks. Je weiter das Framework entwickelt ist, desto schneller ist die Entwicklung. Hier werden wir über das Framework sprechen, das ich speziell für Motorsteuerungsmodule erstellt habe und das seit einiger Zeit erfolgreich eingesetzt wird.

Die Architektur des Frameworks.

Das Framework ist für die Arbeit auf der offenen Plattform des Universal Motor Control Module DMC v2.0 ausgelegt .

Die logische Architektur des Frameworks kann als Blockdiagramm dargestellt werden (siehe unten). Im Blockdiagramm wird eine vollständige Auflistung aller Komponenten des Frameworks weggelassen, da dies die Klarheit beeinträchtigen würde, aber für eine allgemeine Idee denke ich, dass die Details ausreichen.


(Zum Vergrößern anklicken)

Das Framework hat keine Versionen, es wird ständig weiterentwickelt, und hier habe ich nur versucht, den aktuellen Status zu korrigieren, der auf GitHub veröffentlicht ist.

Aus Sicht der Softwaremodule enthält das Framework folgende Schlüsselteile:

- Eine Reihe von Support-Modulen auf Anwendungsebene
- Echtzeitbetriebssystem MQX .
- Middleware: Dateisystem, Befehlsshell, Kommunikationsprotokollstapel usw.
- Ein Low-Level-Board-Support-Paket (BSP), das den Zugriff auf die Peripheriegeräte des BLEZ66V1-Moduls und des Leistungsmoduls umfasst.
- Softwarepaket für Überwachung, Debugging und Diagnose - FreeMaster .
- Debugging-Tools wie RTT , ITM- Tool-Tracing , Logger, VT100- Terminal.
- Modul zum Generieren von Parameterdateien.
- Module generierter Quellcodes basierend auf Algorithmen in Matlab .

Warum ist MQX ausgewählt?

Das Echtzeitbetriebssystem (RTOS) MQX ist aber seit langem bekannt
erschien vor ein paar Jahren gemeinfrei. Dieses Betriebssystem wurde von Freescal hochgeladen, bevor NXP sie kaufte. RTOS hatte ursprünglich eine Lizenz nur für die Verwendung in Freescale-Mikrocontrollern, jetzt erstreckt sich die Lizenz auch auf NXP-Produkte. RTOS überlebte die explosive Popularität und durchlief mehrere Upgrades auf Version 4.2. Danach beschloss Freescale, seine nachfolgenden Versionen wieder kommerziell zu machen. Es stellte sich also heraus, dass es zwei Versionen gab, eine offene und eingefrorene Version namens MQX Classic (auch bekannt als MQX v4.2) und eine geschlossene kommerzielle MQX 5.0.

In dem beschriebenen Framework wird der Zweig MQX Classic v4.2 verwendet. Dies ist eine stabile, gut getestete Version. Die Lizenz ermöglicht es dem Entwickler, den Quellcode von MQX Classic zu ändern und in kommerziellen Produkten zu verwenden. Die Veröffentlichung von MQX Classic in Quellform ist jedoch nicht zulässig. Dies sollte jedoch kein Problem sein, da MQX Classic zum kostenlosen Download zur Verfügung steht.

Die Struktur von RTOS im Allgemeinen sieht folgendermaßen aus:

Warum brauche ich RTOS?

Eine komplexe Anwendung, bei der insbesondere eine Motorsteuerung erforderlich ist, ist recht komplex und besteht aus vielen asynchronen Aufgaben, von denen jede ihren eigenen Wiederholungszyklus und ihre Aktivierungs- und Stoppereignisse hat. Wenn wir alle diese Aufgaben in einem Superzyklus ausführen, stoßen wir unweigerlich auf das Problem, die Ausführung einiger Aufgaben durch andere Aufgaben zu verzögern.
Mit RTOS wie MQX ist es möglich, die gegenseitige Abhängigkeit einzelner Aufgaben auf der Zeitachse zu beseitigen, ohne sie neu zu schreiben oder ihre Quellcodes zu betrachten.

Beispielsweise kann unsere Logger-Aufgabe versuchen, eine Nachricht so lange wie gewünscht auf eine SD-Karte zu schreiben, die auf ihre Antwort wartet. Die USB-Aufgabe kann alle eine große Datenmenge an einen Computer übertragen. Gleichzeitig wird die PID-Aufgabe des Motoralgorithmus streng in einem bestimmten Intervall ausgeführt und die Geschwindigkeitsmessaufgabe Bei der Drehung wird kein einziges Encoder-Signaländerungsereignis übersehen.

Ich muss zugeben, dass es einen immer beliebteren Weg gibt, die Komplexität auf einem einzelnen Chip zu beseitigen - die Umstellung auf Multiprocessing. In diesem Fall bietet RTOS jedoch einen guten Service.

Die Hauptvorteile von RTOS MQX.

- Der Kernel des Systems enthält eine breite Palette an Middleware, darunter ein Dateisystem, einen TCP / IP-Stack, einen USB-Stack, eine Befehlsshell usw. Alles im Quellcode.

- Vorgefertigte BSP-Sets für verschiedene Karten, sodass Sie keine eigenen peripheren Arbeitsbibliotheken schreiben müssen.
- Detaillierte Dokumentation in PDF-Dateien mit einfacher Navigation.
- Das Vorhandensein eines Plug-Ins für die eingebettete IDE IAR-Workbench mit sehr detaillierten Informationen zu den internen Strukturen von RTOS ist viel detaillierter als bei anderen bekannten RTOS - uCOS und FreeRTOS.
- Viele RTOS-Anwendungsbeispiele und Testfälle.

Wenn sie über RTOS sprechen, betonen sie immer ihre Fähigkeit, Aufgaben rechtzeitig zu erledigen, aber quantitative Schätzungen werden für einige separat ausgewählte Plattformen von Drittanbietern meistens nicht oder nicht angegeben. Dies reicht eindeutig nicht aus, um eine harte Echtzeitsteuerung mit RTOS zu implementieren. Und um die Motoren zu steuern, benötigen Sie genau harte Echtzeit.

MQX hat diesbezüglich einen wunderbaren Testfall, mit dem Sie eine detaillierte Tabelle der Ausführungszeit aller Dienste auf der Plattform erhalten, auf der Sie den Test gestartet haben.

Nachfolgend finden Sie eine Tabelle der Ausführungszeit von Diensten auf dem Mikrocontroller unseres Motorsteuerungsmoduls, wobei die maximale Optimierung der Codeausführungsgeschwindigkeit im Compiler enthalten ist.


Die Tabelle gibt auch eine Vorstellung davon, welche Dienste von RTOS unterstützt werden und welche Kerneloptionen verfügbar sind. Das Testprojekt in der IDE IAR ist im veröffentlichten Framework enthalten.

Zusammensetzung des Projektverzeichnisses

Das Stammverzeichnis des Frameworks sieht folgendermaßen aus:


APP_SRC - Ein Verzeichnis, das alle Quellen außer denen enthält, die zur MQX-Distribution gehören.
FreeMaster_apps - Projektdateien zur Ausführung in der FreeMaster- Umgebung.
IAR_proj - Arbeitsbereich und Projektdateien für die eingebettete IAR-Workbench für ARM v7.70.2. In dieser Umgebung wird die endgültige Anwendung kompiliert und debuggt.
MQX_SRC ist ein Verzeichnis, das alle mit MQX gelieferten Quellen für MQX und Middleware enthält. Da die Lizenz kein Open Source-Publishing aus der MQX-Distribution zulässt, befinden sich in diesem Verzeichnis keine ' .s'- und' .s'- Dateien. Aber diejenigen, die den NXP-Lizenzbedingungen zustimmen, können die fehlenden Dateien erhalten.
ParametersManager - Verzeichnis des Parametermanager-Programms. Mit diesem Programm werden Listen von Anwendungsparametern erstellt und ' .s' und ' .h' Dateien mit Parameterdeklarationen zum Einbetten in die Anwendung generiert.
TESTS - ein Verzeichnis mit Framework-Testprojekten. Hier ist das MQX_benchmark- Projekt zum Generieren eines Berichts mit MQX-Timings.

Die Dateien MQX_LIBRARY_O0.a und MQX_LIBRARY_O3.a sind die Inhalte des Verzeichnisses MQX_SRC, das mit minimaler bzw. maximaler Optimierung in Bibliotheken kompiliert wurde.

Der Inhalt des Verzeichnisses IAR_proj

Die Dateien U3HB_full.eww und U3HB_MQXLib.eww sind die IAR-Arbeitsbereichsdateien .
Solange sich keine Quellen im MQX-Verzeichnis befinden, funktioniert nur die Datei U3HB_MQXLib.eww . Dieser Arbeitsbereich verwendet kompilierte MQX-Bibliotheken. Im Arbeitsbereich U3HB_full.eww werden die vollständigen MQX-Quellen kompiliert. Das OUT- Verzeichnis dient als Ort, an dem die IAR ihre Arbeitsprodukte platziert, insbesondere Map- und Hex-Dateien.

Das Einstellungsverzeichnis wird automatisch von der IAR erstellt. Es speichert speziell die Debugger-Einstellungen. Wenn beim Debuggen in der IAR etwas nicht konfiguriert werden kann, lohnt es sich manchmal, dieses Verzeichnis zu löschen.

Die Datei INT_FLASH_MK66FX1M0LVQ18.icf ist eine IAR-Linker-Konfigurationsdatei. Es bestimmt die Adressen von Speicherbereichen, in denen der Linker Code, Daten, Interruptvektoren, Stapel usw. platziert.

Der Inhalt des Verzeichnisses MQX_SRC

Arbeitsbereichsdateien MQX_LIBRARY.eww wird zum Erstellen von MQX-Bibliotheken verwendet. Bis die Dateien ' .s ' und ' .s' in den Verzeichnissen abgelegt sind, wird dieses Projekt nicht kompiliert.
config - das Verzeichnis mit den MQX-Konfigurationsdateien. Die Zusammensetzung der MQX-Dienste und -Treiber ist in der Konfigurationsdatei user_config.h angegeben.
mfs - MQX-Dateisystem, enthält FAT32 und RAM FS
mqx - Der MQX-Kern enthält die folgenden Unterverzeichnisse:


rtcs - TCP / IP-Stapel. Es enthält die folgenden Unterverzeichnisse:


Shell - Ein Verzeichnis mit Shell-Dateien.
USB - Verzeichnis mit USB Stack Dateien

Die Funktionalität jedes MQX-Softwaremoduls ist vom Hersteller gut dokumentiert. Als Beispiel werde ich Links zu zwei Dokumenten bereitstellen:

→ Anweisungen zur Verwendung des MQX .
→ MQX-Referenzhandbuch.
Der Rest muss in der Distribution gesucht werden, die auf der NXP-Website verfügbar ist .

Das Framework selbst befindet sich hier im Repository.

Weitere Beschreibungen der Arbeit mit Software und Anwendungsbeispiele finden Sie in den folgenden Artikeln.