By Tom Thompson
Ever notice how embedded devices these days are much more sophisticated? Whether they are part of consumer electronics, mobile gadgets, or specialized equipment in the medical field, embedded systems have much greater capability than their predecessors of even a few years ago. Much of this change is due to powerful system-on-a-chip parts that have 32-bit microcontroller units (MCUs), analog-to-digital convertors (ADCs) and device interfaces, such as USB and Ethernet, all integrated onto one chip.
However, silicon alone isn’t enough to make a product smarter, better, faster, stronger than the competition: software is a key part of the solution. For complex embedded systems–for example, the automatic transmission in a vehicle–software often becomes the critical part of the design. John Voelcker, IEEE Spectrum’s automotive editor, wrote in April 2007 where for the GMC Yukon hybrid automobile and its Two-Mode Hybrid automatic transmission that some seventy percent of the total effort for designing and testing the system was spent on the control software. Clearly, software has to meet silicon in order to make a complete, smart product.
Our recurring theme here on the blog is what Freescale does to make your life easier. It’s really neat to hear about our customers’ success stories where we helped to open opportunities that may have never happened otherwise. Motomic Software is a case in point.
Motomic helps device manufacturers, mobile network operators and service providers ensure that software is rapidly available whenever new devices are introduced. Motomic provides an embedded implementation of Qt, a cross-platform set of application and UI frameworks from Nokia. The frameworks are managed and refined by Nokia’s Qt Development Frameworks division and is expected to continue publishing them under an open source license. Qt’s frameworks support GUI elements, multimedia and network functions, XML parsing, and a platform-agnostic file system.
Motomic saw an opportunity if it could assist developers who are porting code onto these processors. Qt could execute directly on embedded products that target price-sensitive markets. This would allow developers to write embedded applications using a variety of Qt frameworks.
Motomic’s plan was to offer Qt developers the opportunity to migrate existing Qt applications to Freescale embedded devices and further expand their customer base. However, in order to port Qt to Freescale’s diverse array of MCUs, where each processor family has its own instruction set architecture, the company faced huge development costs. They needed an approach that made business sense. What to do?
Enter the MQX RTOS, with a feature set and availability across many Freescale processors that met the design requirements. In effect, to enable our silicon and our customers, Freescale had already done the foundational work , and enabled Motomic software to pursue the opportunity.
To achieve Motomic’s goal, the solution was to leverage the availability of the MQX RTOS across the Freescale processor families. Because of MQX RTOS’s small resource footprint and efficiency, it was possible to layer Qt above the RTOS and have the Qt frameworks draw upon its services.
To avoid a massive rewrite of the Qt source, Motomic wrote an MQX Adaptor. The adaptor is an interface library that maps Qt services onto their MQX RTOS equivalents for events, timers, processes, and other OS services (Figure 1). For example, Qt’s threading feature was redirected to MQX RTOS task services, while the Qt network frameworks made use of the Freescale TCP/IP Suite, and Qt file calls rely on the MQX File System Suite. The wealth of device drivers that MQX provides also simplified Qt’s support for keyboards and displays. Because the MQX RTOS APIs are identical across the Freescale MCU families, Motomic’s MQX Adaptor had to be written only once. That single effort gave Motomic and its customers access to every processor family supported by MQX RTOS.
Figure 1: The Motomic MQX Adaptor enables the Qt frameworks to use MQX RTOS rather than a Linux kernel
The Qt migration was successful in part because of MQX RTOS’s robustness and low overhead, along with Motomic’s software engineering expertise. In addition, the performance of the Qt applications executing on Qt for MQX RTOS appears promising. The MQX RTOS and Qt for MQX open the door for vendors to build products using the well-known Qt application framework on devices that have stringent cost and power consumption requirements.
Let’s look at some of what lies behind that success based on the MQX RTOS design.
An Efficient RTOS by Design
MQX RTOS is a 32-bit RTOS designed specifically to function within the highly constrained resources of an embedded device while providing real-time services. MQX RTOS has a small memory footprint in terms of both RAM and non-volatile storage, yet still provides sophisticated OS services, such as preemptive multitasking with priority levels and task threading.
MQX RTOS has provided solutions for products such as medical equipment for eye surgery, drug injections, and radiation dose monitoring. It is also used some aircraft braking systems and navigation equipment. For mission critical work, MQX RTOS is certifiable for medical (CFR 820.30 Part 21, IEC 60601-1) and aerospace standards (DO-178b).
Many of Freescale’s MCUs have MQX RTOS implementations. This breadth of coverage offers intriguing possibilities when developing a family of products. An MQX application has the potential to be written once, then deployed across platforms based on ColdFire and Coldfire+, Power Architecture, and Kinetis microcontrollers. This lets you tailor products for specific markets by modifying a basic hardware design to use a different Freescale MCU, depending on whether the goal is to deliver better performance or lower power consumption. The application can then be migrated to the new platform with minor modifications to the source code. MQX RTOS can therefore yield savings in software development in terms of reduced porting and testing efforts for the product line’s embedded application software. This is precisely what Motomic Software took advantage of.
How does MQX RTOS achieve a lot of bang in such a few bytes? The RTOS uses a component-based architecture to accomplish this. MQX RTOS components are mostly small C-based modules that implement very specific OS services. For example, there are components for:
• Task scheduling that uses priority and queues for real-time responsiveness
• Event and messaging services for task control and coordination
• Semaphore, mutex, and IPC routines for multitasking and multiprocessor control, coordination, and communications
• Basic I/O services, with networking and bus service stacks available as add-on options
• Error logging for debugging
As Figure 2 shows, MQX RTOS consists of eight core components that implement a basic kernel and its services, such as hardware initialization, memory management, task generation and scheduling. Another seventeen optional components can be “plugged in” along with the core components to implement the embedded application’s desired services. Since the MQX distribution provides the complete source code, you pick only those RTOS components whose features you need, and build them into the binary image. There is no baggage due to unused function code.
Figure 2: The modular, component-based architecture of the MQX RTOS
The event, memory manager, message, semaphore, log, and timer components have lightweight variants that can further reduce MQX’s resource footprint. Finally, to achieve the low execution overhead required for real-time performance, certain key kernel components, such as the context switcher and interrupt mechanism, are written in hand-coded assembly language for each processor. You can learn more about the MQX RTOS components and the API used to invoke them by studying the Freescale MQX RTOS Reference Manual.
To give you an idea of how svelte an MQX implementation can be, on a ColdFire V2 processor an MQX configuration that consists of the kernel, memory manager, lightweight semaphores, queues, interrupt stack and two tasks weighs in at 12 KB of ROM and 2.5 KB of RAM.
If the product requires network or device-specific connectivity, you can add Freescale and third-party software stacks to the image to provide such abilities. As Figure 3 shows, Freescale offers a number of software stacks for MQX RTOS. The Freescale MQX Real-Time TCP/IP Suite provides a compliant TCP/IP stack, written in reentrant code. A Freescale MQX File System Suite implements FAT-12 FAT-16 and FAT-32 file systems, and the Freescale MQX USB Host/Device Stack implements a USB stack that supports USB 1.1 and 2.0 standards. Other services/suites that add network security, industrial network bus protocols, and a GUI are available from third-party vendors such as Embedded Access Inc., SEGGER Microcontroller, IXXAT, Inc., and others.
Figure 3: Software stacks allow MQX RTOS applications to support network operations, a file system, and various devices
You can download the MQX RTOS source code from here. It’s not a demo, it’s not limited, and it’s not going to time out. We provide the MQX RTOS as a complimentary enablement technology for our silicon. Why? Because getting software to work right on a complex platform is difficult, and we need to make it as easy as possible for you to get up and running. It’s that simple.