uCOS-III Source Code and Books are Now Available for Free

In a great move for all embedded lovers, Jean J. Labrosse has announced a day ago that uCOS-III source code is now available for as well as its 6 books in PDF format.

Furthermore, colleges and universities can use it for free.

You can check Jean J. Labrosse announcing it here.

The source code can be downloaded from here.

The books are available from here.

The big question is "Why after a 2 years of release its source code is made available?"

If you have an answer, please share.

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

uCOS-III VS uCOS-II (API Changes)

Introduction
This is the fifth and the last post about the comparison between uCOS-II and uCOS-III. The whole five posts can serve as a guide for migrating from uCOS-II to uCOS-III.

In this post, I will try to summarize the API changes themselves. I wont go in the details of the APIs' arguments but I will try to hint the differences on a higher level. Changes in APIs were aiming at having more consistent code.

Changes in Critical Sections
Macros defined to control a critical section are redefined and moved to CPU.H.

General Changes in APIs

• Accept APIs are removed. They are now built in Pend APIs.
• Naming APIs are removed. Names are defined during Creation APIs.
• Posting APIs are combined into a single API where all options are built in a single Post API.
• The type OS_EVENT is no longer used. Instead new types were added.
  
• Query APIS are removed because they are rarely used.
• All object handles should be created by the application prior to its creation. Number of objects are no more defined during compilation.

Changes in Event Flags APIs
Changed APIs are OSFlagCreate, OSFlagDel, OSFlagPend, OSFlagPendGetFlagsRdy, and OSFlagPost.

Changes in Message Mailboxes APIs
No direct implementation of message mailboxes APIs. You can view a mailbox as a message queue with a single message. Thus, message queues APIs are used to emulate message mailboxes APIs.

Changes in Memory Management APIs
Changed APIs are OSMemCreate, OSMemGet, and OSMemPut.

Changes in Mutual Exclusion Semaphores APIs
Changed APIs are OSMutexCreate, OSMutexDel, OSMutexPend, and OSFlagPost. OSMutexPendAbort is added in uCOS-III.

Changes in Message Queues APIs
Changed APIs are OSQCreate, OSQDel, OSQPend, OSQPost, and OSQPendAbort.

Changes in Semaphores APIs
Changed APIs are OSSemCreate, OSSemDel, OSSemPend, OSSemPost, OSSemPendAbort, and OSSemSet.

Changes in Task Management APIs
Changed APIs are OSTaskChangePrio, OSTaskCreate, OSTaskDel, OSTaskResume, OSTaskRegGet, OSTaskRegSet, OSTaskSuspend, and OSTaskStkChk.
Removed APIs, others than mentioned above in the general changes section, are OSTaskDelReq, and OSTaskCreateExt.
Added APIs are OSTaskQFlush, OSTaskQPend, OSTaskQPendAbort, OSTaskQPost, OSTaskSemPend, OSTaskSemPendAbort, OSTaskSemPost, OSTaskSemSet, and OSTaskTimeQuantaSet.

Changes in Time Management APIs
All APIs are changed.

Changes in Timer Management APIs
All APIs are changed except for OSTmrSignal is removed.

Changes in Miscellaneous APIs
Changed APIs are OSInit, OSSchedLock, OSSchedUnlock, and OSVersion.
Changed and renamed APIs are OSPendMulti, and OSStatTaskCPUUsageInit.
Added APIs are OSSchedRoundRobinCfg, and OSSchedRoundRobinYield.

Changes in Hook and Port APIs
Changed APIs are OSTaskStkInit, OSTaskCreateHook, and OSTaskDelHook.
Changed and/or renamed APIs are OSInitHook, OSIdleTaskHook, and OSStatTaskHook.
Added APIs are OSGetTS, and OSTaskReturnHook.
Deleted APIs are OSInitHookEnd, and OSTCBInitHook.

uCOS-III VS uCOS-II (Variable Name Changes)

Introduction
In the fourth post, I will hint out the changes in variables' names in uCOS-III compared to uCOS-II. The changes are made to be more consistent with the coding convention.

These changes can be noticed by comparing OS.H in uCOS-III compared to uCOS-II.H in uCOS-II.

Changes

• OSCtxSwCtr in uCOS-II is renamed to OSTaskCtxSwCtr in uCOS-III and containing the same information.
• OSCPUUsage in uCOS-II is renamed to OSStatTaskCPUUsage and containing the same information.
• OSIdleCtr and OSIdleCtrMax in uCOS-II are renamed to OSIdleTaskCtr and OSIdleTaskCtrMax respectively in uCOS-III and containing the same information.
• OSIntNesting and OSSchedNesting in uCOS-II is renamed to OSIntNestingCtr and OSSchedLockNestingCtr in uCOS-III and containing the same information.
• OSTaskCtr in uCOS-II is renamed to OSTaskQty in uCOS-III and containing the same information.
• OSTCBCur and OSTCBHighRdy in uCOS-II are renamed to OSTCBCurPtr and OSTCBHighRdyPtr respectively in uCOS-III and containing the same information.
• OSTime and OSTmrTime in uCOS-II are renamed to OSTickCtr and OSTmrTicckCtr respectively in uCOS-III and containing the same information.
  

uCOS-III VS uCOS-II (Conventions)

Introduction
This is the third post out of five posts under the same topic. In the first post, I pointed out the difference in features. In the second post, I summed up the difference between the two kernels in terms of file names and contents. In this post, I will summarize changes in the conventions. They can be summarized into 3 categories.

Introduction of CPU.H
A notable change is the use of the CPU specific data types. In uCOS-II, data types were defined in OS_CPU.H. In uCOS-III, these definitions are defined in CPU.H. Every data type is prefixed with "CPU_".

Exceptions are OS_STK and OS_CPU_SR, they are renamed to CPU_STK and CPU_SR respectively.

In addition, in uCOS-II we had the OS_STK_GROWTH changed to CPU_CFG_STK_GRWOTH in uCOS-III and stored in CPU.H.

Introduction of "CFG" as Acronym
This is another convention added to define configuration options

Introduction of OS_CFG_APP.H
Some configuration options are configurable at the application level not at the kernel level as the case of uCOS-II. The application programmer only needs to define them during his application compilation rather than being defined in uCOS-II compilation which might not be accessible by the application programmer. These options plus new ones are defined in the OS_CFG_APP.H.

This file now contains configurations for maximum number of messages, ISR stack, idle tasks, ISR handler task, statistics task, ticks, and timers.

A notable change in these configurations that the word "TICKS_PER_SEC" is now replaced by "RATE_HZ". Frankly speaking, it became less confusing!

Changes in OS_CFG.H
The remaining configurations in OS_CFG.h are either renamed, moved, or removed. Additional configurations are added to that file. These modification are summarized as follows:

• DEBUG is replaced with DBG
• Naming configurations are removed as in uCOS-III objects are named during creation.
• In uCOS-III, all kernel objects are allocated during run-time. All configurations related to maximum number of objects are removed. This is really aids saving RAM and is not necessary to over allocate objects.
• Width of event flags is determined in uCOS-III by the data type OS_FLAG defined in OS_TYPE.H instead of OS_FLAG_NBITS used in uCOS-II.
  
• No query services are available in uCOS-III. All query configurations are removed.
• Accept functionality is now emulated in pend functionality through an option. All accept configurations are removed.
  
• Different posting functionality are now combined in a single post functionality. Extra posting configurations are removed.
• All configuration to support uC/OS-View are removed. This product is obsolete.
  

uCOS-III VS uCOS-II (File Names and Contents)

Introduction
This is the second post out of five under the same topic. In the first post in the comparison, I pointed out the difference in features. In this post, I will point the difference in file names and contents in both kernels. Difference can be summed up to 13.

Changes in File Names and Contents
1- os_app_hooks.c is added to uCOS-III for convenience so the user can add application hooks. Copy this file to the application directory and edit the contents of the file.
2- os_cfg_app.h is added to uCOS-III. In old uCOS-II, all configurations were stored in os_cfg.h. In uCOS-III, application specific configurations are moved from os_cfg.h to os_cfg_app.h.
3- os_cfg_r.h used in uCOS-II as a starting point for configuring the kernel is now changed to os_cfg.h in uCOS-II. The new file is reserved for configuring non-application specific kernel features.
4- Porting files are the same but some variables and function names are changed.

• OSIntNesting to OSIntNestingCtr
• OSTCBCur to OSTCBCurPtr
• OSTCBHighRdy to OSTCBHighRdyPtr
• OSInitHookBegin to OSInitHook
• OSTaskStatHook to OSStatTaskHook
• OSTaskIdleHook to OSIdelTaskHook
  
• OSInitHookEnd and OSTCBInitHook are removed
• OSTaskStkInit in the new kernel has different arguments. Instead of taking the task's stack start address, it takes the task's stack size and its stack base address. This implies a slight change in this function code in uCOS-III.

5- os_dbg.c is a must in uCOS-III compared to its counter part, os_dbg_r.c, in uCOS-II.
6- os_int.c is added to uCOS-III to support the new feature called interrupt queuing in uCOS-III. This feature allows posting calls from ISRs to be deferred to a task level handler. The goal behind this feature is to reduce interrupt latency.
7- os_pend_multi.c is added to uCOS-III to allow tasks to pend on multiple kernel objects. The old code was written in os_core.c in uCOS-II.
8- os_prio.c is added to uCOS-III to isolate the code that determines the highest priority task ready to run. A port developer can re-implement this file in assembly equivalent if this will improve the performance.
9- A message mailbox is simply a message queue with one entry. That's why the file os_mbox.c is no longer available in uCOS-II.
10- os_msg.c is added to uCOS-III to encapsulate the management of messages in message queues.
11- os_stat.c is added to uCOS-III to extract the statistics task code from os_core.c.
12- os_type.h is added to uCOS-III. This file is used to adapt the data types sizes to the cpu architecture rather than being assumed by the port developer as in uCOS-II.
13- os.h is added to uCOS-III to act as the main header file and replace ucos_ii.h in uCOS-II.

uCOS-III VS uCOS-II (Features)

Introduction

Migrating from uCOS-II to uCOS-III was a humming question in my head and the heads of many. I started trying to answer this question with the idea that uCOS-III is totally a new kernel but with roots into uCOS-II. My survey is based on uCOS-II source code and the Win32 for uCOS-III evaluation I got recently.

Differences between uCOS-III and uCOS-II can be classified under 5 categories:

1. Features
   
2. Source file names and contents
3. Conventions
4. Variable names
5. API changes

These areas are of great importance for those who are willing to port uCOS-II applications to uCOS-III.

I will try to explain briefly each category in a separate post.

If any of my results are not accurate enough due to the lackness of uCOS-III source code, please feel free to email me at amraldo@hotmail.com to correct it in this post.

Changes in Features
uCOS-III is introduced in 2009 while uCOS-II was first introduced in 1998. For both kernels, books and source code are available. But for uCOS-III, Micrium followed a new model. The source code is made available only to licensed users.

Unlike uCOS-II, uCOS-III has no limitation on numbers of tasks (255 tasks mazimum in uCOS-II) nor on the number of tasks at each priority level. Consequently, RR scheduling was introduced in uCOS-III.

uCOS-III kept all services available except for the message mailbox. It was totally removed. Although a message mail box can be used exactly like a binary semaphore, in addition for message passing, but after all it is indeed a message queue with a single entry. Another breakthrough is that mutexes and task's suspension resumption now support nesting.

Advances in performance were considered in the design of uCOS-III compared to uCOS-II. Smaller code size, support for run-time configurability, less interrupt latency, enhanced built-in measurements, time stamping on posting APIs, optimize schedulers in assembly are dreams coming into reality.

uCOS-III is working on being a safety-critical certified software. It is compliant with
MISRA C 2004 (except for 8 rules) and the certificaion is in progress to achieve DO178B Level A, EUROCAE ED-12B, SIL3/SIL4, and IEC 61508.

Running uCOS-III with Microsoft Windows Soon?

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. While uCOS-III includes many of the same features you're already familiar with in uCOS-II, there are some important differences. For example, it also manages an unlimited number of application tasks and features an interrupt disable time of near zero. With round-robin scheduling, uCOS-III allows multiple tasks to run at the same priority level. uCOS-III puts greater control of the software in your hands, yet maintains Micrium's ease-of-use, ease-of-integration, short learning curve, unsurpassed documentation, and clean code.

uCOS-III x86 Win32 Simulation?

The tutorial is made available here.