New Software Timers in FreeRTOS under MS Windows

SW Timers

Embedded applications need to schedule future events. This can be accomplished using timers and timers' services.

Timers are an integral part of any real-time system. A timer can be seen as an event scheduling according to a predefined time value in the future, exactly like setting an alarm clock.

Embedded systems that have time-sensitive activities use 2 types of timers; hard-timers and soft-timers. Hard timers are based on physical timers on the chip that directly interrupt the CPU. A hard-timer is a must in case of an application demanding high precision and predication. On the other hand soft-timers are scheduled through a software facility that enables soft-timer's maintenance, installation, and removal.

But if hard-timers are more accurate than their soft counterparts, why are they used? The answer is in their nature. The can be programmed with timeouts of course granularity. In addition, the high-precision is not always needed in most of embedded systems. Another prevailing reason is reducing system interrupt overhead. Facilities of soft-timers are built using only 1 hardware-timer.

SW Timers in FreeRTOS

Starting from FreeRTOS V7.0.0, FreeRTOS added the soft-timers feature. FreeRTOS timers have 2 modes of operations; autorelaod and 1-shot modes. Whenever a timer timeouts, a callback function is executed. This service is implemented as a FreeRTOS kernel task and a FreeRTOS queue. This task is assigned a stack size and priority defined the macros configTIMER_TASK_STACK_DEPTH and configTIMER_TASK_PRIORITY respectively. The timers APIs are implemented through the queue. Whenever a task calls a timer API it send s a command to the timer task through the timers queue. This task continually gets the next expire time, either process the expired timer or blocks until a timer expires or  it receives a command  and processes it. Like any other FreeRTOS service, this service is highly configurable. In order to use it you have to:

1. Define configUSE_TIMERS to 1
2. Define configTIMER_TASK_PRIORITY and configTIMER_STACK_DEPTH
3. Define configTIMER_QUEUE_LENGTH
4. Add FreeRTOS/Source/timers.c to your application.
5. Use the timers in your application

Demoing the SW Timers under MS Windows

Last year, I showed how to run the industrial PC port under MS Windows. Recently, FreeRTOS team made a windows simulator. Unlike the PC port that used Open Watcom and 80x86 assembly, it uses MS VC or MingW and Windows APIs. 

The following steps shows how to test the SW timers with the FreeRTOS MS Windows simulator:

1. Download MS VC++ 2010 Express edition from here.
2. After Installing the compiler, download FreeRTOS from here.
3. Open the project using MS VC and here you go.

Running uCOS-III under Microsoft Windows

uCOS-III the Real-Time Kernel

uCOS-III is Micrium's newest RTOS, designed for developers who need to save time on their current and next embedded sytem projects. In addition to the features inherent in μC/OS-II, μC/OS-III also manages an unlimited number of application tasks, and features an interrupt disable time of near zero. For more details, you can check its data sheet.

uCOS-III Win32 Simulation

Win32 port allows uCOS-III to run under Microsoft Windows. The port relies on Windows' process and thread management features; the uCOS-III Win32 port does not turn Windows into a real-time operating system! It was developed for didactic purposes to teach the basics of real-time operating systems with an insight to OS internal implementation. This approach was chosen, because it is much easier access PCs rather than to proprietary embedded systems. Powerful PC-based development tools like Microsoft Visual Studio are available free of charge as compared to costly embedded system cross-compilers and debuggers. Thus real-time system mechanisms can be studied with uCOS-III under Win32 providing a soft real-time-environment on PCs. If the basic functionality of the application is working correctly, the application can be easily ported to an embedded system later in the lab.

Figure 1 shows the relationship between the user application, uCOS-III the underlying Windows system.

Figure 1: Application / uCOS-III / Windows Vista Relationship

As a result of this hierarchy, µC/OS-III tasks are really Windows threads and their stacks are converted to Windows thread stacks. The system ticker is driven by the high resolution multi-media timer if WIN_MM_TICK is defined in os_cpu.h. Otherwise it is driven by sleep(), the system coarse timer. A more realistic real-time effect can be achieved by using the multi-media timer since it has finer granularity (1ms) than the system coarse timer.

Critical sections are implemented using the Win32 API.

Fortunately, the underlying architecture is transparent to the application programmer and all µC/OS-III application code can utilize various features using traditional documented µC/OS-III function calls.

Since µC/OS-III is an infinite loop by nature, it should be noted that the processor utilization under windows will remain close to 100% while µC/OS-III is running. This is normal operating behavior for infinite loop consol based programs under Windows.

uCOS-III Win32 Simulation with Windows
To run this test, you have to install Microsoft Visual C++ 2008 Express. You can get it here.

Once you open the project, it will look as shown in Figure 2.

Figure 2: MS Visual C++ 2008 Express Project Structure

The directories used are:

1. uC/CPU: generic and Win32 specific uC/CPU headers
2. uC/LIB: compiler independent uC/LIB library functions
   
3. BSP: header files for BSP
4. uCOS-III: version 3.01.2 of uCOS-III
5. App: example application

After building the project, once you run it you get the output shown in Figure 3.

Figure 3: uCOS-III for Windows

Adding Interrupts to uCOS-II Running on Microsoft Windows

How to Simulate Interrupts?

In the past few days, I was asked that question many times. So, I decided to make a small software example to show how uCOS-II interrupts can be simulated under Windows.

I modified the uCOS-II port to support 8 interrupts at the same level of priority. Moreover, these interrupts can occur simultaneously but their ISR execution order depends on the implementation. I followed the uCOS-II tasks's priority schema with interrupts (i.e. the smaller the interrupt number, the faster it will be executed).

The implementation core is done by creating a Win32 thread as a generic IRQ handler in os_cpu.c. In addition, 2 utilities were added in the file pc.c. They are used to register and unregister user ISRs. ISRs will be written only in C.

Testing the Interrupts Implementation

My test code is based on the 1^st example in uCOS-II book. I modified this code to have 5 tasks with the highest priority to be interrupt-driven. Each task of the 5 will wait for a semaphore before printing its number on the screen. ISRs will trigger these tasks by signaling the semaphores. The test code can be found here.

To automate this test, I wrote a utility that generates these 5 interrupts randomly every 2 milliseconds. The code for this utility can be found here. I just run my test code then run the interrupt generation utility. To distinguish the interrupt-driven tasks from others, I modified their code to print their IDs in a new color scheme. The interrupt generation utility code is found here.

Fig 1 shows the application running with interrupts. Numbers with blue background are those printed by tasks driven by interrupts.

Figure 1: Example 1 Modified to Run with Interrupts

Running Timer's of uCOS-II to Measure Cycle Average Execution Time

Software Timers

Embedded applications need to schedule future events. This can be accomplished using timers and timers' services.

Timers are an integral part of any real-time system. A timer can be seen as an event scheduling according to a predefined time value in the future, exactly like setting an alarm clock.

Embedded systems that have time-sensitive activities use 2 types of timers; hard-timers and soft-timers. Hard timers are based on physical timers on the chip that directly interrupt the CPU. A hard-timer is a must in case of an application demanding high precision and predication. On the other hand soft-timers are scheduled through a software facility that enables soft-timer's maintenance, installation, and removal.

But if hard-timers are more accurate than their soft counterparts, why are they used? The answer is in their nature. The can be programmed with timeouts of course granularity. In addition, the high-precision is not always needed in most of embedded systems. Another prevailing reason is reducing system interrupt overhead. Facilities of soft-timers are built using only 1 hardware-timer.

Software Timers in uCOS-II

Starting from uCOS-II V2.8x, uCOS-II added the soft-timers feature. uCOS-II timers have 2 modes of operations; periodic and 1-shot modes. Whenever a timer timeouts, a callback function is executed. This service is implemented as a uCOS-II task. This task is assigned a stack size and priority defined the macros OS_TASK_TMR_STK_SIZE and OS_TASK_TMR_PRIO respectively. This task is signaled from the tick ISR at a constant rate defined by the macro OS_TMR_CFG_TICKS_PER_SEC. Whenever signaled, it updates the soft timers created by the user and make calls to callback functions if they expire. The design structure used for timers implementation is wheel spoke. Like any other uCOS-II service, this service is highly configurable. In order to use it you have to:

1. Define OS_TMR_EN to a value greater than zero

2. Define OS_TASK_TMR_STK_SIZE and OS_TASK_TMR_PRIO

3. Define frequency of timers update through OS_TMR_CFG_TICKS_PER_SEC

4. Enable hooks

5. Modify OSTimeTickHook to signals the timers manager task as explained here

6. Use any of timers management APIs in your application

Measuring Execution Time

To test the execution time of a cyclic task, you should use the OSTimeGet API at its start and end to measure the execution time. You should accumulate the total execution time and the number of cycles executed in order to calculate average cycle execution time. The soft-timer will be used to calculate this average at periodic rates. A code example is can be found here.

Fig 1 shows the result of running that code.

Figure 1: Timer Measuring Execution Time

Running FreeRTOS with Microsoft Windows Vista in 1 Hour

About FreeRTOS

FreeRTOS is a real-time operating system for embedded systems, being ported to several microcontrollers. It is distributed under the GPL with an optional exception. The exception permits users' proprietary code to remain closed source while maintaining the kernel itself as open source, thereby facilitating the use of FreeRTOS in proprietary applications.

FreeRTOS is designed to be small and simple. The kernel itself consists of only three or four C files. To make the code readable, easy to port, and maintainable, it is written mostly in C, but there are a few assembler functions included where needed (mostly in architecture specific scheduler routines). The download contains prepared configurations and demonstrations for every port and compiler, allowing rapid application design.

Another related project is OpenRTOS, which has an identical code base to FreeRTOS but with different licensing. The OpenRTOS license removes all reference to the GPL and its implications. For example, one of the conditions of using FreeRTOS in a commercial product is that the user is made aware of the use of FreeRTOS and the source code must be provided upon request. OpenRTOS doesn't have this requirement.

SafeRTOS is a derivative version of FreeRTOS that has been analyzed, documented and tested to meet the stringent requirements of the IEC 61508 safety standard. Complete safety lifecycle documentation artifacts have been created and independently audited to verify IEC 61508 SIL 3 conformance.

FreeRTOS and Windows Simulation

Can the Industrial PC port run under Windows? The answer is yes. In FreeRTOS, there is an x86 port that can run in a dos emulation box. But you should take care that it is a simulation and won't give you the correct response. In addition, there is an ARM port that can be simulated within Keil.

Steps to Run the x86 Port Under Microsoft Windows

1. Download the latest FreeRTOS from here

2. Unpack it under C Drive

3. Download the OpenWatcom tools for windows from here and install it under C drive

4. Open the Open Watcom project in the FreeRTOS/Demo/PC directory - it is called rtosdemo.wpj

5. In main.c, comment the line "vStartComTestTasks( mainCOM_TEST_PRIORITY, serCOM1, ser115200 );" or you will get errors about COM1 not available

Figure 1: FreeRTOS Running Under Microsoft Windows Vista

Next

I think the next step is to make a complete free course about FreeRTOS. This tutorial will serve as a starting point to build complete labs based on windows simulation. I hope, they will be a success like the uCOS-II courses I made earlier.

Running PC Utility for uCOS-II with Microsoft Windows Vista in 1 Hour

uCOS-II the Real-Time Kernel

uCOS-II is a small, yet powerful real-time operating system developed by Jean J. Labrosse and described in his book "MicroC/OS-II - The Real-Time-Kernel", Second Edition, published by CMP Books. The operating system is highly CPU independent and has been ported to numerous microprocessor platforms. The source code as provided together with the book and via the web site may be freely used for non-commercial applications and educational purposes. Licenses for commercial use are available too.

PC Utility for uCOS-II x86 Win32 Simulation

In a previous post, I managed to simulate uCOS-II with Windows Vista. The example used was a very simple one that used to display simple messages on the console. The next step was to create a PC utility to access some of the PC capabilities. By this, I am completing the simulation environment of uCOS-II on Windows Vista and making it similar to the environment described in uCOS-II books by J. Labrosse.

This utility is encapsulated in a file called PC.C and called from the test code. This utility uses the Windows console driver. Encapsulation allows users to easily adapt the code to a different compiler or a different design. The utility contains 3 types of services: character-based display, elapsed-time measurement, and miscellaneous.

Most of the previous tests of the PC Utility were never done, until writing this document, with Windows Vista. In this document, I will show how you can run a PC Utility used with Windows XP under Windows Vista.

Building the PC Utility

My starting point was a PC utility written by Prof. Werner Zimmermann. He used the windows console driver for character based display and some APIs for time measurements.

In addition, he had 3 examples similar to those described in Labrosse's book. I used examples 1, 2, and 3 written for VC as a starting point for my test applications.

To build this tutorial on your own, you need to download Zimmermann's Windows port of uCOS-II from here.

Steps to Build the PC utility

1. Extract the Zimmermann's port

2. Following the directory structure we made in the previous post referenced above, create a directory for the PC utility files as follows C:\Micrium\Software\Blocks\PC\OpenWatcomC-C++1.8

3. Copy PC.C and PC.H from Zimmermann's port to the created directory above

4. In PC.C, remove anything related to interrupts.

5. Build 3 different projects as described in the previous post. The new projects should include the newly added PC files and source codes of examples 1, 2, and 3 from the Zimmermann's port.

6. In each file called test.c, change the PC_DispChar calls to PC_DispStr. PC_DispChar is buggy for this port.

7. In any example where hooks are needed, do the necessary changes to include them in the uCOS-II original code.

8. Compile and run your 3 examples.

Figure 1: Open Watcom C-C++ 1.8 Project Structure

Figure 2: Example 1 Running with the PC Utility

Figure 3: Example 2 Running with the PC Utility

Figure 4: Example 3 Running with the PC Utility