The open project of the electric motor control module. Software Development Technology

Firmware for the insides of modern embedded electronics to write from scratch is almost impossible. It just does not give time. Therefore, software for embedded systems is created on the basis of
ready-made software platforms - frameworks. The more developed the framework, the faster the development is. Here we will talk about the framework created by me specifically for the motor control modules and successfully used for some time already.

Framework architecture.

The framework is designed to work on the open platform of the universal motor control module DMC v2.0 .

The logical architecture of the framework can be represented as a block diagram, as shown below. In the flowchart, a complete listing of all the components of the framework is omitted, since this would damage the visibility, but for a general idea, I think, there is enough detail.


(Click to enlarge)

The framework has no versions, it is in constant development, and here I just tried to fix its current state, which is laid out on GitHub.

From the point of view of software modules, the framework contains the following key parts:

- A set of application level support modules
- Real-time operating system MQX .
- middleware: file system, command shell, communication protocol stacks , etc.
- A package of low-level support for the board (board support package or BSP), which includes functions for accessing the peripherals of the boards of the BLEZ66V1 module and the power module.
- Software package for monitoring, debugging and diagnostics - FreeMaster .
- Debugging tools including RTT , instrumental tracing ITM , loggers, VT100 terminal. - Module for generating parameter files . - Modules generated source texts based on algorithms in Matlab .

Why is MQX selected?

The real-time operating system (real-time operating system, RTOS) MQX has been known for a long time, but
it was freely available a couple of years ago. This operating system was laid out by the firm Freescale before they were bought by NXP. RTOS initially had a license only for use in Freescale microcontrollers, now the license also applies to NXP products. RTOS has experienced explosive popularity, has gone through several upgrades to version 4.2, after which Freescale decided to make its subsequent versions commercial again. So it turned out two versions, one open and frozen in development called MQX Classic (aka MQX v4.2) and closed commercial MQX 5.0.

In the framework described, the MQX Classic v4.2 branch is used. This is a stable, well-tested version. The license allows the developer to modify the source code of MQX Classic and use it in commercial products, but does not allow publishing MQX Classic as source code. But this should not be a problem, since the MQX Classic is available for free download.

The structure of RTOS in general terms is as follows:

Why do we need RTOS?

A complex application where it is required in particular to control the motor is quite complex and consists of a set of asynchronous tasks, each with its own repetition cycle and activating and stopping its events. If we all perform these tasks in one super cycle, then we inevitably run into the problem of delaying the execution of some tasks by other tasks.
Using RTOS, such as MQX, it is possible to get rid of the interdependence of individual tasks on the time axis, without rewriting them or even looking at their source codes.

For example, our logger task may try for a long time to write a message to the SD card while waiting for its response, the USB task may all go into transferring a large amount of data to the computer, but the PID task of the motor algorithm will be performed strictly at a specified interval, rotation does not miss a single event of the change of the encoder signals.

Although it must be admitted, there is another increasingly popular way to get rid of complexity on a single chip - switching to multiprocessing, but in this case RTOS will do a good service.

The main advantages of RTOS MQX.

- The system kernel comes with a wide range of middleware including file system, TCP / IP stack, USB stack, command shell, etc. All in source code.

- Ready BSP kits for different boards, eliminating the work of writing peripherals from writing your own libraries.
- Detailed documentation in pdf files with easy navigation.
- Availability of a plug-in for IDE IAR embedded workbench with very detailed information about the internal structures of RTOS, much more detailed than for other well-known RTOS - uCOS and FreeRTOS.
- Many examples of RTOS and test cases.

When they talk about RTOS, they always emphasize their ability to perform tasks on time, but quantitative assessments are often not given or are given for some separately selected third-party platforms. This is clearly not enough to implement hard real-time control using RTOS. And to control the engines need exactly the hard real time.

MQX has a wonderful test case on this score, which allows you to get a detailed table of the execution time of all services on the platform on which you run the test.

Below is a table of the service execution time on the microcontroller of our motor control module, with the maximum optimization in the code execution speed enabled in the compiler.


The table also gives an idea of ​​which services are supported by RTOS and which kernel options are available. The test project in IDE IAR is included in the published framework.

The composition of the project directories

The root directory of the framework looks like this:


APP_SRC is a directory containing all sources except those related to the MQX distribution.
FreeMaster_apps - project files for execution in the FreeMaster environment .
IAR_proj - files of the workspace and project for the IAR environment embedded workbench for ARM v7.70.2. In this environment, the final application is compiled and debugged.
MQX_SRC is a directory containing all the sources of the MQX and middleware supplied with MQX. Since the license does not allow open source publication from the MQX distribution, there are no ' .c' and ' .s' files in this directory . But those who agreed to the NXP license terms may be sent the missing files.
ParametersManager is the directory of the parameter manager program. This program creates lists of application parameters and generates ' .c' and ' .h' files with parameter declarations to be embedded in the application.
TESTS is a directory with the framework test projects. Here is the MQX_benchmark project for generating a report with MQX timings.

The files MQX_LIBRARY_O0.a and MQX_LIBRARY_O3.a are the contents of the MQX_SRC directory compiled into libraries with minimum optimization and maximum optimization, respectively.

Contents of the IAR_proj directory

The U3HB_full.eww and U3HB_MQXLib.eww files are files of the IAR environment.
As long as there are no sources in the MQX directory, only the U3HB_MQXLib.eww file will work . This workspace uses the compiled MQX libraries. In the workspace U3HB_full.eww, the full MQX sources are compiled. The OUT directory is a place where the IAR environment places the products of its work, in particular, map and hex files.

The settings directory is created automatically by the IAR environment. In particular, the debugger settings are stored in it. If something can not be configured when debugging in IAR, then sometimes it is worth erasing this directory.

FileINT_FLASH_MK66FX1M0LVQ18.icf is an IAR linker configuration file. It determines the addresses of the memory regions where the code, data, interrupt vectors, stacks, etc. are placed by the linker.

MQX_SRC Directory Content

Files in the MQX_LIBRARY.eww workspace are used to create the MQX libraries. Until the ' .c' and ' .s' files are placed in directories this project will not be compiled.
config - directory with MQX configuration files. The composition of the MQX services and drivers is specified in the user_config.h configuration file .
mfs is the MQX file system, includes FAT32 and RAM FS
mqx — the MQX core includes the following subdirectories:


rtcs - TCP / IP stack. It includes the following subdirectories:


shell - directory with shell files.
usb - directory with USB stack files The

functionality of each MQX software module is well documented by the manufacturer. As an example, I will cite two documents:

→ Instructions for using MQX .
→ MQX Reference Guide.
The rest must be sought in the distribution, which is available on the NXP website .

The framework itself is in the repository here .

Further description of working with software and examples of application - in the following articles.