MicroC/OS-II Real-Time Operating System On NIOS

Overview of the MicroC/OS-II RTOS

MicroC/OS-II is a popular real-time kernel produced by Micrium Inc. MicroC/OS-II is a portable, ROMable, scalable, pre-emptive, real-time, multitasking kernel. First released in 1992, MicroC/OS-II is used in hundreds of commercial applications. It is implemented on more than 40 different processor architectures in addition to the Nios II processor. 

MicroC/OS-II provides the following services: 

• Tasks (threads)
• Event flags 
• Message passing 
• Memory management 
• Semaphores 
• Time management 

The MicroC/OS-II kernel operates on top of the hardware abstraction layer (HAL) board support package (BSP) for the Nios II processor. Because of this architecture, MicroC/OS-II development for the Nios II processor has the following advantages:

• Programs are portable to other Nios II hardware systems.
• Programs are resistant to changes in the underlying hardware.
• Programs can access all HAL services, calling the UNIX-like HAL application program interface (API).
• ISRs are easy to implement.

The Nios II Implementation of MicroC/OS-II

Altera has ported MicroC/OS-II to the Nios II processor. Altera distributes MicroC/OS-II in the Nios II EDS, and supports the Nios II implementation of the MicroC/OS-II kernel. Ready-made, working examples of MicroC/OS-II programs are installed with the Nios II EDS. In addition, Altera development boards are preprogrammed with a web server reference design based on MicroC/OS-II and the NicheStack® TCP/IP Stack - Nios II Edition. 

The Altera implementation of MicroC/OS-II is designed to be easy to use. Using the Nios II project settings, you can control the configuration for all the RTOS’s modules. 

You need not modify source files directly to enable or disable kernel features. Nonetheless, Altera provides the Nios II processor-specific source code in case you wish to examine it. The MicroC/OS-II source code is located in the following directories:

• Processor-specific code: <Nios II EDS install path>/components/altera_nios2/UCOSII
• Processor-independent code: <Nios II EDS install path>/components/micrium_uc_osii

The MicroC/OS-II software package behaves like the drivers for hardware components: When MicroC/OS-II is included in a Nios II project, the header and source files from components/micrium_uc_osii are included in the project path, causing the MicroC/OS-II kernel to compile and link as part of the project.

MicroC/OS-II Architecture

The Altera implementation of MicroC/OS-II for the Nios II processor extends the single-threaded HAL environment to include the MicroC/OS-II scheduler and the associated MicroC/OS-II API. The complete HAL API is available to all MicroC/OS-II projects.

Figure 1. Architecture of MicroC/OS-II Programs

MicroC/OS-II Thread-Aware Debugging

When you debug a MicroC/OS-II application, the debugger can display the current state of all threads in the application, including backtraces and register values. You cannot use the debugger to change the current thread, so it is not possible to use the debugger to change threads or to single-step a different thread.

MicroC/OS-II Device Drivers

Each peripheral (that is, each hardware component) can provide include files and source files in the inc and src subdirectories of the component’s HAL directory.

In addition to the HAL directory, a component can optionally provide a UCOSII directory that contains code specific to the MicroC/OS-II environment. Similar to the HAL directory, the UCOSII directory contains inc and src subdirectories. 

When you create a MicroC/OS-II project, these directories are added to the search paths for source and include files.

The Nios II Software Build Tools (SBT) copies the files to your BSP’s obj subdirectory.

You can use the UCOSII directory to provide code that is used only in a multi-threaded environment. Other than these additional search directories, the mechanism for providing MicroC/OS-II device drivers is identical to the process for any other device driver.

The HAL system initialization process calls the MicroC/OS-II function OSInit() before alt_sys_init(), which instantiates and initializes each device in the system. Therefore, the complete MicroC/OS-II API is available to device drivers, although the system is still running in single-threaded mode until the program calls OSStart() from within main().

Thread-Safe HAL Drivers

To enable a driver to be ported between the HAL and MicroC/OS-II environments, Altera defines a set of operating system-independent macros that provide access to operating system facilities. These macros implement functionality that is only relevant to a multi-threaded environment. When compiled for a MicroC/OS-II project, the macros expand to MicroC/OS-II API calls. When compiled for a single-threaded HAL project, the macros expand to benign empty implementations. These macros are used in Altera-provided device driver code, and you can use them if you need to write a device driver with similar portability.

The path listed for the header file is relative to the <Nios II EDS install path>/components/micrium_uc_osii/UCOSII/inc directory.

The newlib ANSI C Standard Library

Programs based on MicroC/OS-II can also call the ANSI C standard library functions. Some consideration is necessary in a multi-threaded environment to ensure that the C standard library functions are thread-safe. The newlib C library stores all global variables in a single structure referenced through the pointer _impure_ptr. However, 
the Altera MicroC/OS-II implementation creates a new instance of the structure for each task. During a context switch, the value of _impure_ptr is updated to point to the current task’s version of this structure. In this way, the contents of the structure pointed to by _impure_ptr are treated as thread local. For example, through this mechanism each task has its own version of errno. 

This thread-local data is allocated at the top of the task’s stack. You must make allowance for thread-local data storage when allocating memory for stacks. In general, the _reent structure consumes approximately 900 bytes of data for the normal C library, or 90 bytes for the reduced-footprint C library. 

Interrupt Service Routines for MicroC/OS-II

Implementing ISRs for MicroC/OS-II normally involves some housekeeping details, as described in MicroC/OS-II: The Real-Time Kernel. However, because the Nios II implementation of MicroC/OS-II is based on the HAL, several of these details are taken care of for you. The HAL performs the following housekeeping tasks for your interrupt service routine (ISR):

• Saves and restores processor registers
• Calls OSIntEnter() and OSIntExit()

The HAL also allows you to write your ISR in C, rather than assembly language.

Implementing MicroC/OS-II Projects for the Nios II Processor

To create a program based on MicroC/OS-II, start by setting the BSP properties so that it is a MicroC/OS-II project. You can control the configuration of the MicroC/OS-II kernel using BSP settings with the Nios II SBT for Eclipse™, or on the Nios II command line.

You do not need to edit header files (such as OS_CFG.h) or source code to configure the MicroC/OS-II features. The project settings are reflected in the BSP’s system.h file; OS_CFG.h simply includes system.h.