OK, I think this topic is a very special one, and probably not of interest of many folks out there. Or how many want to create a Processor Expert Plugin for an RTOS? Well, I did this. And I think that topic might be very controversial too, especially for all the RTOS vendors out there :-). The thoughts expressed here about creating Processor Expert components do not only apply for an RTOS, but as well for any other ‘complex’ software or stack. So if you are interested about the ‘behind the scenes’ of creating Processor Expert components, especially in the context of an RTOS, then read on ;-).

The design approach of creating a Processor Expert component had several root reasons:

• I need to integrate an operating system into my project. And this was always a very time consuming task: get the RTOS sources, add them to the project, set up compiler include and search paths, build the thing with hopefully no errors.
• Usually RTOS are heavily depending on the underlying hardware: stack frames, interrupt frames, tick timer, interrupts for context switching. Yes, all RTOS providers  have example projects. But rarely I have *exactly* that board or microcontroller. Which then in the end I need to make a port of the thing to my hardware.
• And finally I’m teaching embedded systems programming, and this includes using an RTOS. But here I want to focus on the concepts, and not on dealing with the issues of changing compiler settings or other ‘non-productive’ things.

In my teaching role, the last point was important. I have observed that adding/using an RTOS the ‘traditional’ way required around 3-4 hours to the students up to speed. Using the Processor Expert way allowed me to cut that time needed to less than 30 minutes.

The Beginning…

When I say RTOS, then I mean here a micro-Kernel like tinyOS, treadX, MicroC/OS-II or FreeRTOS. I have used MicroC/OS-II for education for a long time, and this RTOS still plays a role model for me: concise, fast, reliable, excellent documentation both in the source code itself and as well in the book µC/OS The Real-Time Kernel by Jean J. Labrosse (ISBN 0-87930-444-8).

The MicroC/OS-II Component

So it was a natural thing back in 2008 to have the MicroC/OS-II transformed into a Processor Expert component. The component supported the Freescale HCS12, HCS08 and ColdFire architectures.

In the next picture you see the uCOS Processor Expert view as shown in CodeWarrior (both Classic and Eclipse):

There were several innovative parts with this approach:

1. The RTOS source files are generatedand stored in the project structure. Usually you have the RTOS somewhere in a folder, and then you refer to it like a library. This approach (the ‘library’ one) has the advantage of having just a single instance of the RTOS. But as soon as you need it for several architectures/products or start changing it, you are in troubles. And because the RTOS is ‘external’ to the project, it requires some setup. As the RTOS file size is not big, and as generating the files on demand is such an easy thing with Processor Expert, the benefit having the source files in the project locally was a plus for me.
   

   uCOS generated files

2. The earlier point has another positive result: with the Processor Component approach, the component can contain all the sources (generated). As such, it is really easy to pass the RTOS to the students or install it on another machine: I simply pass the Processor Expert component as a ‘package’, and everything is in a single file.
3. Easier to use: simply add the component, configure it, generate code, compile and run. The component exposes the RTOS API calls like OSInit(), OSStart(), OSQPost() etc. With Processor Expert every method usually has a prefix (you can specify) in front of every function name. The implementation is using simple macros (e.g. #define uCOS1_OSStart() OSStart()):
   

   OSStart Implementation with macro

4. Online Help: You can hover with the mouse over it, and it will show you the API description. No need to consult the manual.
   

   uCos OSMemCreate Tooltip Help

5. Configuration: The RTOS configuration file is generated. Instead of manually configure the os_config.h for MicroC/OS-II, I have a graphical editor with tool tip help to make things easy to use:
   

   uCOS Properties

That component and approach worked out very well.

Licensing

It worked very, very well in a teaching and university environment. Because source code is provided for free for educational use or for peaceful research. For commercial usage a license is required, in my view very affordable.

At the Lucerne University of Applied Sciences and Arts we have up to 40-60% students which study 2-3 days a week, and work in their normal job the rest of the time. Their wish was to learn and apply something in the lab, they easily could transfer into their own commercial product work in their companies. And here the licensing thing was a hindering point. The question I was asked was: “why can we not use something open source?”.

That would have solved as well another problem: as the uC-OS component includes the RTOS sources, I would need distribution rights from Micrium (the company owning MicroC/OS-II).

FreeRTOS

Looking out for an open source alternative, one thing stood out of the 2011 Embedded Market Study: FreeRTOS. Although it has some conceptual differences (heap, stack allocation, process priorities) compared to MicroC/OS-II, it was a very valuable alternative. And it has a very friendly Open Source license, solving the above two issue points (distribution rights and need for licensing).

FreeRTOS Processor Expert Component

But what was missing was a Processor Expert Component for it. With the experience gathered with the creation of the MicroC/OS-II component it was not that hard. An it is officially available on the web since September 2011 on the Embedded Component download page.

Similar to the MicroC/OS-II component it offers methods and events to the RTOS API:

The component offers properties to configure the RTOS. The settings are generated into the RTOS configuration file FreeRTOSConfig.h:

This component is constantly evolving and has been extended as well with Tracing capabilities (see Tracing FreeRTOS with a Hardware Probe and Tracing with FreeRTOS+Trace from Percepio) and supports following architectures:

• Freescale S08 family of processors
• Freescale S12, S12X family of processors
• Freescale ColdFire V1 and ColdFire V2
• Freescale Kinetis ARM Cortex M4 and M4F family

There is work in progress (not fully supported yet) for the Freescale DSC family of processors. Beside of the various Freescale compilers, gcc support is being added now and will be available with the next version.

Ok, that’s for the introductory part. The next posts will be around how to code and hack an RTOS Processor Expert Component. Will be fun :-).

Happy Componentizing 🙂