Freescale offers complementary MQX RTOS suite for its ColdFire microcontroller with full source code. Although the software is deliveried in source code, it is highly recommended not touching source code in the component level. Freescale suggests designer using a user configuration file to configure the operation system in compile time. Of course, experienced users still can leverage the source code to add more features by themselves. However, you have to track the MQX release from Freescale.

Embedded systems are tailor-made for specific requirements. In most cases, custom designs use compile time configurations with macro definitions to enable or disable some features. I have terrible experience of working on custom projects with encrypted source code. In order to offer diversity in same code base, the system architect introduces hundreds of macro definitions in the software. It should work if the source code is fully available for developers. However, some people (management) decided to protect the so-called software IP and avoid changing software by customers. As a result, the source code is encrypted before being delivered to the customers. During building a project in customers’ PC, the source is decrypted and compiled into a library according to a user configuration file. In order to achieve that purpose, the source code is split into plenty of small files. They even convince the tool vendors to offer a special version for this. The whole build process is extremely slow due to decryption and building many small files. A small change in a head file comes about 45 minute build on a 2G Pentium IV. By contrast, the original straightforward project only requires 5 minutes to build from scratch. Our development group could handle 50 projects in one year. After using this stupid encryption method, we could only finish 3 projects in one year, with many over time work and bugs.

Freescale offers MQX suites in full source, which is a Gospel for the developers. Thank you, Freescale. However, Freescale still recommends not touching MQX source. Instead, it is highly recommended to use a user_config.h to configure the whole MQX libraries. I do believe the experienced users can touch the code, add own library components. However, if you modify the MQX libraries, you have to struggle the bugs by yourselves without official support from Freescale, and you have to synchronize your branches with the official updates from Freescale. 

Configuration File

To build all MQX libraries at once, the special mass-build project may be used. The project is located together with the user_config.h file in directory:

<install_dir>/config/<board>/build_libs.mcp

In my MQX installation folder, it is 

C:\Program Files\Freescale\Freescale MQX 3.1\config\m52259demo. 

There are two files in this folder, one is build_libs.mcp project file, and the other is user_config.h. Open the project file in the CodeWarrior, you can see 7 sub-projects: PSP, BSP, MFS, RTCS, USB_HDK, USB_DDK and Shell. You can not see the user_config.h file until you open any sub-project, which includes it in the M52259DEMO User Config folder.

To be frank, I was quite disappointed when I saw configurable options in the file. There are few options you can manipulate. Although this head file includes two other head files from common folder, most of the configurations are usually used for MQX kernel debug and application level configurations like toggle ICMP, which can not meet diversity requirements from all kinds of embedded systems. However we can not blame Freescale, diversity is always a headache, which can not be fully solved in resource restricted embedded systems. Because if we place too much configuration in the include file, the project will be more and more difficult to maintain. The source code is cut into fractions and hard to read. I got some guidance that we should use different folders to replace the macro definition to meet diversity needs, I still wonder if the alternative approach is better than classic macro definition. Maybe it is another nightmare.

Build MQX Libraries

Since the project is dedicated for mass-building MQX libraries, you can easily build all the libraries by pressing the make menu. It takes several minutes to build them all. Then you can copy the libraries and head files to your own project source folder. Actually, they have been copied to the lib folder automatically. You can toggle the options in the user_config.h and build them again. Then you get the new libraries. The other user projects will refer these libraries by including the updated head file and linking the updated libraries in the central lib folder. So if you are developing several projects with contradictory features in the libraries, you have to isolate them into different folders. As a result, since you at least move one of them to another folder, you have to build the moved library again from scratch because of the path issue.

Reading Documents

It is always a good practice to read the documents before changing code. The original MQX from ARC and MQX from Freescale have remarkable differences. Some features are still in the documents, such as BOOTP, PPPoE and IPSec, but they are not available in the Freescale version. It is not clear whether these removed features are available in the future releases and why they are removed. These documents are helpful for the developers who are going to add features by themselves. All of the documents are places under doc folder, including the release note, manuals for individual components.

Studying Library Sources

As supplementary of reading the enclosed documents (Release Notes and Manuals) for MQX, we can research MQX by reading its source code. I am not always working on Metrowerks CodeWarrior. It takes me some day to get familiar with CW. Searching in the whole project is the most important feature for an IDE. In order to search a word in MQX libraries, you must open the sub-projects (or library) before searching. Otherwise you get nothing at all. 

For example, I would like to add two basic features for web HVAC project, DHCP client and HTTP basic authenticate which can get IP assignment from DHCP server of router and prevent unauthorized abuse for HVAC controller. I try to search the code in web HVAC project, but I get nothing. However I can see the code during debug, which includes library source in debug session. So I open the RTCS sub project in the mass build project, then searching "authenticate" in RTCS library source, I found "httpd_processreq" in httpd.c has already implemented the basic authentication. And "DHCP client" is also implemented in RTCS already. So the next step we have to return to the web HVAC project to find out why these features have not been enabled in this project. 

We should study the source for each library before we change any code. Some components have explicitly claimed that some features are not available in current release. You have to wait for next release or port other designs into MQX platform. 

I am going to survey if I can append the missing components for MQX from other designs, such as USB host CDC class driver, which is quite useful to interface WiFi, Bluetooth and mobile phone. Hopefully we can make MQX a complete RTOS suite for ColdFire.

Read the Italian version: Come configurare MQX di ColdFire

CONTACT REQUEST
If you want to know more about this Freescale product, please submit your request to Arrow Italy using this form.

NOTE: this form is valid ONLY for Companies or Customers based in Italy and working in the Italian area.