The Freescale MQX RTOS is transitioning to use the Kinetis Software Development Kit (KSDK), and there is a Beta release of MQX for KSDK available now. See Beta version of MQX RTOS for Kinetis SDK - Now Available. Processor Expert (PEx) is a code generation and configuration tool that is already integrated with KSDK. This post shows how PEx can be used with MQX for KSDK. This method is good for simple MQX projects just needing the kernel. PEx simplifies the project by adding the KSDK and MQX kernel files directly to the project.
These steps are written using MQX for KSDK v1.0.0 Beta. The Kinetis Design Studio (KDS) v1.1.1 toolchain is used, with example project attached. KDS has PEx integrated in the IDE and is used for this example, although the stand-alone tool Processor Expert Driver Suite v10.4 can be used with other toolchains. For help getting started with PEx, check out the videos at Processor Expert Tools in CodeWarrior 10.3 - Training Videos.
MQX for KSDK does not yet have any PEx projects installed with the release, but PEx can be used to create a project from scratch. First, ensure to follow the KDS release notes to have the KSDK plugins installed. Also, refer to the MQX documentation to ensure the latest MQX plugins are installed in KDS as well.
Now create a new project using the menu File->New. The New Project Wizard will walkthrough the project creation. Be sure to specify a Kinetis device that is supported by the KSDK, refer to KSDK release notes to see the available list of devices. For the "Rapid Application Development" screen, be sure to check both Kinetis SDK and Processor Expert.
Finish creating the project. After the project is created, use the Component Library to add the components MQX_KSDK and MQX_KSDK_Task. The project needs at least one MQX_KSDK_Task component, and more can be added for multiple tasks in the application.
After adding the MQX components, the Components View will show them included in the project. The MQX_KSDK properties can be customized if needed using the Component Inspector View. Each Task should be customized using the properties for the MQX_KSDK_Task components.
MQX uses stdin/stdout typically through a UART for IO functions like printf(). This can also be easily customized for the board being used. In this example, the project is written for the FRDM-K64F board, and uses the UART connected to the OpenSDA USB COM port. That board uses UART0 on pins PTB16 and PTB17. To configure in PEx, select the fsl_uart component, which is included as a sub-component under the MQX_KSDK component. Then, in the Component Inspector, change the Properties to use the needed UART peripheral and specify the pins. The other UART properties can also be customized if needed.
Other PEx components can be added as well to configure the peripheral drivers. Once the PEx configuration is complete, generate the code by clicking the Generate Code button in the Components View. This will generate the KSDK and MQX kernel code and add it directly to the project.
With the current releases, PEx will generate a warning in KDS when the code is generated. The GNU ISO C99 standard should be used when building MQX.
To change this compiler setting, right-click the project and select Properties. Then use this screenshot to find the Language Standard in the Compiler Optimization settings, and change to GNU ISO C99. Click OK to save the change.
Now the MQX application can be written. The MQX_KSDK_Task components will create function stubs for the tasks. The task routine prototypes are located in the project header file Sources/mqx_tasks.h and stubs of task functions are in source file Sources/mqx_tasks.c. Add the application code to these tasks. Then use the toolchain to build the project, and download to the target hardware.
The attached project is an example following these steps for KDS. It has a single MQX task that prints "Hello World!" out the UART using printf(). It's written for the FRDM-K64F board, and setup to use the Segger JLink OpenSDA V2 debugger app.
Original Attachment has been moved to: MQX_KSDK_PEx.zip
Thanks, William, that hadn't ever occurred to me because of my debug configuration settings:
I figured that if I selected OpenOCD, the mbed firmware would work fine. Is this not the case? Note that in this particular case, I followed the tutorial so I specified a debug config, as opposed to opening his project attachment. Speaking of which, I'll try that next in the VM.
Thanks!
