Exchange & Comparison Two Real Time Operating Systems on a Micro-Controller System

Table of Contents

Acknowledgements

Abstract

Abbreviations and Symbols

1. INTRODUCTION

2. Technical Background
2.1 General Information about OS
2.1.1 History of Operating Systems
2.2 Real Time Operating System
2.2.1 What Is Real time System?
2.2.2 Real Time Operating System
2.3 RTOS in Embedded systems
2.3.1 Embedded Systems
2.3.2 Running RTOS in Embedded Systems

3. MicroC/OS-II
3.1 Features of µC/OS-II
3.1.1 Source Code
3.1.2 Portable
3.1.3 ROMable
3.1.4 Scalable
3.1.5 Preemptive
3.1.6 Multi-tasking
3.1.7 Deterministic
3.1.8 Task stacks
3.1.9 Services
3.1.10 Interrupt Management
3.1.11 Robust and reliable
3.2 MicroC/OS-II Kernel Structure
3.2.1 Critical Sections
3.2.2 Tasks
3.2.3 Task States
3.2.4 Task Scheduling
3.2.5 Locking and Unlocking the Scheduler
3.2.6 Idle Task
3.2.7 Interrupts under µC/OS-II
3.2.8 Clock Tick
3.2.9 µC/OS-II Initialization
3.2.10 Starting µC/OS-II
3.3 Services provide from MicroC/OS-II
3.3.1 Task Management
3.3.2 Time Management
3.3.3 Resource Management
3.3.4 Message Management
3.3.5 Memory Management
3.4 Porting µC/OS-II
3.4.1 Pre-requirements for porting µC/OS-II
3.4.2 Portability of µC/OS-II

4. Nokia Car-kit Operating System
4.1 Features of NOKIA CAR-KIT OS
4.1.1 Portable
4.1.2 ROMable
4.1.3 Static Configuration
4.1.4 Event-driven Real Time Kernel
4.1.5 Multi-stacks
4.1.6 Services
4.2 NOKIA Car-kit Operating System Kernel Structure
4.2.1 Critical Sections
4.2.2 System data and data definitions
4.2.3 Objects
4.2.4 Descriptors
4.2.5 Lists
4.2.6 Task Scheduling
4.2.7 Interrupt Handling
4.2.8 Configuration
4.2.9 Starting task
4.3 Services Provided From Nokia Car-kit Operating System
4.3.1 Task Management
4.3.2 Timer Management
4.3.3 Resource Management
4.3.4 Communication management
4.3.5 Memory Management

5. Evaluation and Comparison
5.1 Evaluation and Comparison
5.1.1 Kernel
5.1.2 Scheduling
5.1.3 Task Model
5.1.4 Memory
5.1.5 Interrupt and Exception Handling
5.1.6 Application Programming Interface
5.1.7 Development Information
5.1.8 Commercial Information
5.2 A Summary Comparison Review
5.2.1 Advantages and Disadvantages of MicroC/OS-II
5.2.2 Advantages and Disadvantages of NOKIA CAR-KIT OS

6. Software Mapping Layer
6.1 Introduction
6.2 Software Analysis for Mapping Layer
6.2.1 Problem Analysis
6.2.2 Functionality and Operational Concept Analysis
6.3 Software Design and Implementation for Mapping Layer
6.3.1 Software Design for mapping layer
6.3.2 Software Implementation for Mapping layer

7. Conclusion

References

Appendices

Appendix B: ROM and RAM Usage Calculator for MicroC/OS-II

Acknowledgements

The subject of this Master of Science Thesis is “Exchange and Compare Two Real Time Operating Systems on a Micro-controller system”. It is carried out at the NOKIA Product Creation Site, Platform & Core Software (PF & Core SW) group, Bochum, Germany.

First of all, I would like to thank all my supervisors, Professor Walter Geisselhardt at the University of Duisburg-Essen, and Jörg Pietruszka, Michael Bode, Jürgen Kreierhoff at the NOKIA GmbH. Their idea, advice and encouragement have been essential to this work. Thanks to all my colleagues in the STP SW Stream Team for the great work environment and their contribution in various ways to this thesis. Especially thanks to Ingo Riedel who recommended me and gave the opportunity to write this thesis at NOKIA. I am grateful to the department for the excellent facilities and flexibility allowed. I also want to thank my parents and brothers for their support and encouragement. Finally, I would like to thank my wife Yue for her love, support and understanding during the whole time of this work.

Bochum, November 2004

Junyi Xu

Kammerstr.206 Haus I, Zimmer 101

D-47057 Duisburg

Tel. +49 203 3938599

Abstract

University Duisburg-Essen, Duisburg Germany

Institute of Information Technology

Junyi Xu

Topic:

Exchange & Comparison two Real Time Operating Systems on a Micro-controller System

Examiners: Prof. Dr.-Ing. W. Geisselhardt

Funding: NOKIA GmbH, Bochum Germany

November 2004

Embedded systems are becoming an integral part of commercial products today. Mobile phones, watches, cars and flights controllers etc. are to name a few. There are critical elements between the system hardware and the software, one of the primary is the Real Time Operating System which ensures control, compatibility and timing. The Real Time Operating System has to interface/communicate well with the hardware below it to prevent casualty, and with the software above to ensure the applications running in a proper way. Therefore, more and more attention is being paid to the porting relationship between Real Time Operating System and Application Software by engineers in embedded field.

Comparing and evaluating the performance of different Real Time Operating Systems is getting more important. Measuring is the only way to provide useful information, for example, which Real Time Operating System is best suitable for a specific hardware configuration.

The purpose of this thesis paper is to find an approach to exchange MicroC/OS-II with NOKIA Car-kit OS on a micro-controller system. Besides porting MicroC/OS-II to the micro-controller system, the interfaces to higher level application software should be generated to adapt the application software to MicroC/OS-II. Finally, evaluate the advantages and disadvantages of them.

In chapter 1, a brief introduction is provided.

In chapter 2, the concept of RTOS and the development of Real Time Kernel are introduced. The field on which RTOS is always focusing and why RTOS is especially important in Embedded Systems are explained. The essential performance and the differences among several RTOS are also discussed in this chapter.

In chapter 3, the micro Real Time Kernel MicroC/OS-II is introduced in details. The speciality of MicroC/OS-II and the services provided from MicroC/OS-II are explained. Also, the micro-controllers that MicroC/OS-II supported are introduced.

In chapter 4, NOKIA Car-kit OS (NOKIA Car-kit Operating System) is introduced. The development history and some of important service mechanism are introduced briefly.

In chapter 5, the evaluation and comparison of these two Operating Systems are made. The most important characteristics, the advantages and disadvantages for both of these two RTOS are discussed.

In chapter 6, the software-mapping layer is discussed in detail. In this part, the whole software development procedure is explained. Issues from problem analyse, software design to software implementation are explained.

Finally, in chapter 7, the results from previous chapters are discussed. Some enhancement suggestions that are carried out from the whole porting and comparison procedure are given in this chapter.

Abbreviations and Symbols

Abbildung in dieser Leseprobe nicht enthalten

1. INTRODUCTION

Every year, millions of microprocessor and micro-controller chips are sold as CPUs for general-purpose computers, such as PCs or workstations, but also for devices that are not primarily used as computers, such as printers, TV sets, Mobile phones, cameras, and even coffee machines. Such devices are commonly called embedded systems. Surprisingly, the number of chips used for embedded systems exceeds by far the number of chips used for general-purpose computers. Both general-purpose computers and embedded systems (except for the very simple ones) require an operating system. The performance of operating system running on an embedded system will bring a significant influence to the quality of the final product or even to further marketing.

The subject of this thesis is Exchange and Comparison two Real Time Operating Systems in a Micro-controller system. The HW platform of the Micro-controller system is based on 16-bits micro-controller. The SW platform is based on a RTOS and implements some of the additional functionality needed for further external communications. Most of this thesis concentrates on the part of SW, especially on these two Real Time Operating Systems, NOKIA Car-kit Operating System (NOKIA CAR-KIT OS) and MicroC/OS-II (µC/OS-II).

RTOS is a crucial part of the Micro-controller system. The variety of tasks done on Micro-controller Unit (MCU) system is diverse and is time dependent. The performance of RTOS is very important for the whole system. Most of the tasks running on the system have specified time limit.

2. Technical Background

Before discussing these two Real Time Operating Systems in detail, some general information should be explained. At first, what is Operating System? What is meant by “Real Time Operating System”? Then, what kind of system could be called “Embedded System”? At last, we will discuss some essential problems of what is important for embedded systems to run a Real Time Operating System on it.

This chapter presents some basic concepts of the RTOS and Embedded System. And the questions above will be solved.

2.1 General Information about OS

2.1.1 History of Operating Systems

An operating system (OS) is an important part of almost every computer system. Computer systems can be divided into four components; hardware, operating system, application program and user. It is a difficult task to completely summarize and define the meaning of the term operating system. However, one way to describe an OS is to see it as a resource manager that allocates hardware and software resources in order to solve problems. These resources may be CPU-time, memory, storage capacity, I/O ports etc.

An important task for an OS is hardware abstraction, that is, to provide interfaces to the user and the programmer, in order to simplify their interaction with the computer system.

Charles Babbage designed the first digital computer in the 19th century. The construction of this completely mechanical design was never completed. There were no plans of an OS for Babbage's analytical engine. After the Second World War several vacuum tube computers were built. Until mid fifties these unreliable computers did not have an OS, instead manual serial processing of jobs was used. To get a job executed computer time was reserved, like studio time for making a record, and everything from wiring the plugboards to getting the results printed needed to be done in the reserved time. This method had the major drawback of wasting very expensive computer time with setting up and also with the possible idle time after a job was completed and the results maybe being printed, but before the next job was started. With the invention of the transistor computers became more widely used, but remained extremely expensive, hence the problem of wasting expensive computer time needed to be addressed.

The first Operating System is developed in the mid-fifties to maximize machine use. This first OS is called simple batch system. Instead of directly handling the hardware, the user programs, or jobs, are batched together into a queue. This queue is automatically read by the system. A special job control language (JCL) is used to control the execution via a control program called monitor. Utilities and common functions were also included with the monitor. The monitor is the predecessor of today's kernels or OS cores. With the simple batch system there was no more idle time wasted between jobs and the setting up was automated. Interrupts from timers and input/output (I/O) devices were introduced and allowed more flexibility in the system design. Protected memory access with a memory management unit (MMU) and privileged instructions were also used. One of the responsibilities of the MMU is to manage the memory accesses of application programs, protecting the memory structures of the OS and other applications. These improvements were made possible by hardware advances. As an interesting note, the popular MS-DOS system can be used as an example of a batch system without neither privileged instructions nor memory protection. The major problem with batch systems is that they do not take into account the inherent differences in the speeds of various resources such as central processing units (CPU) and peripherals. One key element of a modern OS, multiprogramming or multitasking, overcomes this.

In the mid-sixties IBM introduced a single line of computers for all applications, the System/360. These were one of the first computers to use integrated circuits (IC), providing a major price per performance advantage over machines built from individual transistors. For this System/360, IBM designed an enormously complex OS called OS/360 that included many of the key elements of the architecture of current OSs. When a computer has enough memory to store multiple programs simultaneously multitasking becomes possible. Multitasking, also called multiprogramming, allows an alternative program to run when the program originally running is blocked, i.e. waiting for some event. The CPU utilization is increased dramatically. The drawback is the complexity needed in the OS to schedule the programs or tasks and memory management unit HW needed for fault-tolerance. This overhead of the scheduler is in most cases minimal compared to the gains. When multiple users started using a computer via terminals time-sharing of CPU time was introduced. Time-sharing is a variant of multitasking where all non-blocked programs are allocated CPU time.

The personal computer (PC) in the eighties brought an OS to everyone's desk. User-friendliness and fast response time to user input became the driving forces in OS development. The computer HW became and still is inexpensive compared to skilled human user labor costs.

2.2 Real Time Operating System

2.2.1 What Is Real time System?

There are many different definitions of a real-time system. Generally, they all state that a real-time system has to react on events in its environment within a specific time interval.

A popular definition is the following:

"In real time computing the correctness of the system depends not only on the logical result of the computation but also on the time at which the results are produced."

Exactly the same definition is given as this:

Basically the real time environment brings the concepts of time and deadlines into program execution. Deadlines are time constraints by which the task must be completed or started.

A real time system is defined as a system, which guarantees deadlines for the execution of tasks. If a task does not meet its deadline, the system is considered in error.

Real time systems can be further divided into hard real time and soft real time systems. A hard real time task is defined similarly but a soft real time system is defined to mean that the deadlines associated with task are desirable but not mandatory. This is further elaborated to mean that in a soft real time system it still makes sense to complete a task even if it has passed its deadline. In a hard real time system, missing a deadline is considered a catastrophic system failure. Often, this is the case with control systems where missing a deadline can cause equipment damage, or in worst cases injury or loss of life. In a soft real time system, failure to meet a deadline is considered undesirable, but does not carry the severity it does in a hard real time system.

2.2.2 Real Time Operating System

A real time kernel, also called a Real time Operating System, or RTOS. It is important to distinguish between a real time system and a real time operating system (RTOS). The real time system consists of all system elements - the hardware, operating system, and applications - that are needed to meet the system requirements. The RTOS is just one element of the complete real time system and must provide sufficient functionality to enable the overall real time system to meet its requirements.

An RTOS is an operating system adapted to fulfill the demands from a real-time system. What makes an OS a RTOS?

1. A RTOS (Real-Time Operating System) has to be multi-threaded and preemptible.
2. The notion of thread priority has to exist, as there is for the moment no deadline driven OS.
3. The OS has to support predictable thread synchronization mechanisms
4. A system of priority inheritance has to exist
5. OS Behaviors should be known

A RTOS allows real time applications to be easily designed and expanded; functions can be added without requiring major changes to the software. The use of an RTOS simplifies the design process by splitting the application code into separate tasks. With a preemptive RTOS, all time-critical events are handled as quickly and as efficiently as possible. An RTOS allow you to make better use of your resources by providing you with precious services such as semaphores, mailboxes, queues, time delays, timeouts, etc.

Small real time systems are often implemented certain functions without an operating system. This means, however, that designers must take care of handling all the hardware of the system, e.g. interrupts by themselves. When the systems get more complex, real time operating systems are commonly used.

An operating system implement components and services that explicitly offer deterministic responses, and therefore allow the creation of hard real time systems. An RTOS is characterized by the richness of the services it provides, the performance characteristics of those services and the degree that those performance characteristics can be controlled by the application engineer (to satisfy the requirements of the application).

The less resources those services require (such as RAM to load the OS, time to do a task switch, latency of message passing, etc.) and the more deterministic the services are, the more "real time" the system is said to be.

2.3 RTOS in Embedded systems

2.3.1 Embedded Systems

An embedded system is a specialized computer. It is often hidden from the end user, used to control devices such as automobiles, home and office appliances, hand-held units of all kinds as well as machines as sophisticated as space vehicles. Operating system and application functions are often combined in the same program. An embedded system implies a fixed set of functions programmed into a non-volatile memory (ROM, flash memory, etc.) in contrast to a general-purpose computing machine. Think of it like a self-contained system. An example would be a computer in a car that controls the ignition system.

2.3.2 Running RTOS in Embedded Systems

Embedded systems tend to serve no other function independent of the system into which they are embedded, although some include external data input/output linkages, which may pass date-sensitive data to other systems.

In an embedded product, one of the most important properties that determines the success or failure of the system is its ability to respond to external events in “real time”. Real time is not well defined in quantitative terms; it depends on the application. But, in general, a real time system is one in which the event (usually an interrupt) must be handled within a bounded amount of time. Failure to respond causes a failure in the embedded system. So, the response time is a very important prerequisite for almost all embedded systems. Because they often operate critically important applications, reliable real time reactions are vital.

This leads to a natural reason to choose a RTOS embedded in an embedded system.

3. MicroC/OS-II

This chapter describes the basic elements of the RTOS kernel “MicroC/OS-II”.

“µC/OS-II ” (pronounced "Micro C O S 2") which stands for Micro-Controller Operating System Version 2 is a commercial Real Time Operating System kernel based on µC/OS (the first released version) provides from Micriµm. µC/OS-II is a highly portable, ROMable, scalable, preemptive, real time, multitasking kernel. µC/OS-II is written in ANSI C and made by Mr. Jean J. Labrosse. The world renowned author of “MicroC/OS-II, The Real time Kernel” (ISBN 1-57820-103-9). µC/OS-II was certified in an avionics product by the Federal Aviation Administration (FAA) for use in commercial aircraft by meeting the demanding requirements of the RTCA DO-178B standard for software used in avionics equipment. Since its introduction back in 1992, MicroC/OS has been used in hundreds of products.

3.1 Features of µC/OS-II

3.1.1 Source Code

The source code of µC/OS-II can be acquired freely. Anyone who bought the book of “MicroC/OS-II, The Real time Kernel” (ISBN 1-57820-103-9) gets the full set of source code with this book. The author did a lot of efforts to provide readers with a high quality ‘product’. You may not agree with some of the style constructs that he use but you should agree that the code is both clean and very consistent. Many commercial real time kernels are provided in source form. But on my opinion, there is no such code that is as neat, consistent, well commented and organized as µC/OS-II’s. Simply giving engineers the source code is not enough. We need to know how the code works and how the different pieces fit together.

3.1.2 Portable

Most of µC/OS-II is written in highly portable ANSI C, with target microprocessor specific code written in assembly language. Assembly language is kept to a minimum to make µC/OS -II easy to port to other processors. µC/OS-II can be ported to a large number of microprocessors as long as the microprocessor provides a stack pointer and the CPU registers can be pushed onto and popped from the stack. Also, the C compiler should either provide in-line assembly or language extensions that allow you to enable and disable interrupts from C.

3.1.3 ROMable

µC/OS-II was designed for embedded applications. This means that if you have the proper tool chain (i.e. C compiler, assembler and linker/locator), you can embed µC/OS-II as part of a product.

3.1.4 Scalable

Well-designed µC/OS-II allows you use only the services that you need in your application. This means that a product can have just a few of µC/OS-II’s services while another product can have the full set of features. This allows you to reduce the amount of memory (both RAM and ROM) needed by µC/OS-II on a product. Scalability is accomplished with the use of conditional compilation. You simply specify (through #define constants) which features you need for your application/product. Almost everything was done by the author to reduce both the code and data space required by µC/OS-II.

3.1.5 Preemptive

µC/OS-II is a fully preemptive real time kernel. This means that µC/OS-II always runs the highest priority task that is ready. Most commercial kernels are preemptive and µC/OS-II is comparable in performance with many of them.

3.1.6 Multi-tasking

µC/OS-II can manage up to 64 tasks, however, the current version of the software reserves eight (8) of these tasks for system use. This leaves your application with up to 56 tasks. Each task has a unique priority assigned to it, which means that µC/OS-II cannot do round robin scheduling. There are thus 64 priority levels.

3.1.7 Deterministic

Execution time of all µC/OS-II functions and services are deterministic. This means that you can always know how much time µC/OS-II will take to execute a function or a service. Furthermore, except for one service, execution time of all µC/OS-II services do not depend on the number of tasks running in your application.

3.1.8 Task stacks

Each task requires its own stack, however, µC/OS-II allows each task to have a different stack size. This allows you to reduce the amount of RAM needed in your application. With µC/OS-II’s stack checking feature, you can determine exactly how much stack space each task actually requires.

3.1.9 Services

µC/OS-II provides a number of system services such as mailboxes, queues, semaphores, fixed-sized memory partitions, time related functions, etc.

3.1.10 Interrupt Management

Interrupts can suspend the execution of a task and, if a higher priority task is awakened as a result of the interrupt, the highest priority task will run as soon as all nested interrupts complete. Interrupts can be nested up to 255 levels deep.

3.1.11 Robust and reliable

µC/OS-II is based on µC/OS, which has been used in hundreds of commercial applications since 1992. µC/OS-II uses the same core and most of the same functions as µC/OS yet offers more features.

3.2 MicroC/OS-II Kernel Structure

3.2.1 Critical Sections

µC/OS-II like all real-time kernels need to disable interrupts in order to access critical sections of code, and re-enable interrupts when done. This allows µC/OS-II to protect critical code from being entered simultaneously from either multiple tasks or ISRs. The interrupt disable time is one of the most important specifications that a real-time kernel vendor can provide because it affects the responsiveness of your system to real-time events. µC/OS-II tries to keep the interrupt disable time to a minimum but, with µC/OS-II, interrupt disable time is largely dependent on the processor architecture, and the quality of the code generated by the compiler. Every processor generally provides instructions to disable/enable interrupts and your C compiler must have a mechanism to perform these operations directly from C.

3.2.2 Tasks

A task is typically an infinite loop function as shown in Figure 3.2.2. A task looks just like any other C function containing a return type and an argument, but it never returns. The return type must always be declared to be void.

Abbildung in dieser Leseprobe nicht enthalten

Figure 3.2.2 A task is an infinite loop

3.2.3 Task States

Figure 3.2.3 shows the state transition diagram for tasks under µC/OS-II. At any given time, a task can be in any one of five states.

Abbildung in dieser Leseprobe nicht enthalten

Figure 3.2.3, Task States

3.2.4 Task Scheduling

µC/OS-II always executes the highest priority task ready to run. The determination of which task has the highest priority and thus, which task will be next to run is determined by the scheduler. Task level scheduling is performed by OSSched(). ISR level scheduling is handled by another function (OSIntExit()). µC/OS-II's task scheduling time is constant irrespective of the number of tasks created in an application.

A context switch simply consist of saving the processor registers on the stack of the task being suspended, and restoring the registers of the higher-priority task from its stack. In µC/OS-II, the stack frame for a ready task always looks as if an interrupt has just occurred and all processor registers were saved onto it. In other words, all that µC/OS-II has to do to run a ready task is to restore all processor registers from the task’s stack and execute a return from interrupt. To switch context, you should implement OS_TASK_SW() so that you simulate an interrupt. All of the code in OSSched() is considered a critical section. Interrupts are disabled to prevent ISRs from setting the ready bit of one or more tasks during the process of finding the highest priority task ready to run. Note that OSSched() could be written entirely in assembly language to reduce scheduling time. OSSched() was written in C just for readability, portability and also to minimize assembly language.

3.2.5 Locking and Unlocking the Scheduler

The OSSchedLock() function is used to prevent task rescheduling until its counterpart, OSSchedUnlock(), is called. The task that calls OSSchedLock() keeps control of the CPU even though other higher priority tasks are ready to run. Interrupts, however, are still recognized and serviced (assuming interrupts are enabled). OSSchedLock() and OSSchedUnlock() must be used in pairs.

The variable OSLockNesting keeps track of the number of times OSSchedLock() has been called to allow for nesting. This allows nested functions which contain critical code that other tasks cannot access. µC/OS-II allows nesting up to 255 levels deep. Scheduling is re-enabled when OSLockNesting is 0. OSSchedLock() and OSSchedUnlock() must be used with caution because they affect the normal management of tasks by µC/OS-II.

You may want to disable the scheduler when a low priority task needs to post messages to multiple mailboxes, queues or semaphores and you don’t want a higher priority task to take control until all mailboxes, queues and semaphores have been posted to.

3.2.6 Idle Task

µC/OS-II always creates an Idle Task, which is executed when none of the other tasks is ready to run.

The idle task (OSTaskIdle()) is always set to the lowest priority. OSTaskIdle() does nothing but increment a 32 -bit counter called OSIdleCtr. OSIdleCtr is used by the statistics task to determine how much CPU time (in percentage) is actually being consumed by the application software. The code for the idle task is shown below Figure 3.2.6. Interrupts are disabled then enabled around the increment because on 8-bit and most 16 -bit processors, a 32-bit increment requires multiple instructions which must be protected from being accessed by higher priority tasks or an ISR. The idle task can never be deleted by application software.

Abbildung in dieser Leseprobe nicht enthalten

Listing 3.2.6, µC/OS-II’s Idle task

3.2.7 Interrupts under µC/OS-II

µC/OS-II requires that an Interrupt Service Routine (ISR) be written in assembly language. If your C compiler supports in-line assembly language, however, you can put the ISR code directly in a C source file. The pseudo code for an ISR is shown below Figure 3.2.7

Abbildung in dieser Leseprobe nicht enthalten

Listing 3.2.7, ISRs under µC/OS-II

Your code should save all CPU registers onto the current task stack L3.14(1).

µC/OS-II needs to know that you are servicing an ISR and thus, you need to either call OSIntEnter() or, increment the global variable OSIntNesting L3.14(2). OSIntNesting can be incremented directly if your processor performs an increment operation to memory using a single instruction. If your processor forces you to read OSIntNesting in a register, increment the register and then store the result back in OSIntNesting then you should call OSIntEnter(). OSIntEnter() wraps these three instructions with code to disable and then enable interrupts thus ensuring access to OSIntNesting which is considered a shared resource. Incrementing OSIntNesting directly is much faster than calling OSIntEnter() and is thus the preferred way. One word of caution, some implementation of OSIntEnter() will cause interrupts to be enabled when OSIntEnter() returns. In these cases, you will need to clear the interrupt source before calling OSIntEnter() because otherwise, your interrupt will be re-entered continuously and your application will crash!

Once the previous two steps have been accomplished, you can start servicing the interrupting device L3.14(3). This section is obviously application specific. µC/OS-II allows you to nest interrupts because it keeps track of nesting in OSIntNesting. In most cases, however, you will need to clear the interrupt source before you enable interrupts to allow for interrupt nesting.

The conclusion of the ISR is marked by calling OSIntExit() L3.14(4) which decrements the interrupt nesting counter. When the nesting counter reaches 0, all nested interrupts have completed and µC/OS -II needs to determine whether a higher priority task has been awakened by the ISR (or any other nested ISR). If a higher priority task is ready to run, µC/OS-II will return to the higher priority task rather than to the interrupted task. If the interrupted task is still the most important task to run the OSIntExit() will return to its caller L3.14(5). At that point the saved registers are restored and a return from interrupt instruction is executed L3.14(6). Note that µC/OS-II will return to the interrupted task if scheduling has been disabled (OSLockNesting > 0).

3.2.8 Clock Tick

µC/OS-II requires that you provide a periodic time source to keep track of time delays and timeouts. A tick should occur between 10 and 100 times per second, or Hertz. The faster the tick rate, the higher the overhead imposed on the system. The actual frequency of the clock tick depends on the desired tick resolution of your application. You can obtain a tick source by either dedicating a hardware timer, or generating an interrupt from an AC power line (50/60 Hz) signal.

You MUST enable ticker interrupts AFTER multitasking has started, i.e. after calling OSStart(). In other words, you should initialize and tick interrupts in the first task that executes following a call to OSStart(). A common mistake is to enable ticker interrupts between calling OSInit() and OSStart() as shown in listing 3.2.8-1.

Abbildung in dieser Leseprobe nicht enthalten

Listing 3.2.8-1, Incorrect way to start the ticker

If you don't like to make ISRs any longer than they must be, OSTimeTick() can be called at the task level as shown in listing 3.2.8-2. To do this, you would create a task which has a higher priority than all your application tasks. The tick ISR would need to signal this high priority task by using either a semaphore or a message mailbox.

Abbildung in dieser Leseprobe nicht enthalten

Listing 3.2.8-2, Code to service a tick

You would obviously need to create a mailbo x (initialized to NULL) which would signal the task that a tick interrupt occurred. The tick ISR would now look as shown in listing 3.2.8-3.

Abbildung in dieser Leseprobe nicht enthalten

Listing 3.2.8-3, Code to service a tick

3.2.9 µC/OS-II Initialization

A requirement of µC/OS-II is that you call OSInit() before you call any of its other services. OSInit() initializes all of µC/OS-II’s variables and data structures (see OS_CORE.C).

OSInit() creates the idle task (OSTaskIdle()) which is always ready-to-run. The priority of OSTaskIdle() is always set to OS_LOWEST_PRIO. If OS_TASK_STAT_EN and OS_TASK_CREATE_EXT_EN (see OS_CFG.H) are both set to 1, OSInit() also creates the statistic task, OSTaskStat() and makes it ready-to-run. The priority of OSTaskStat() is always set to OS_LOWEST_PRIO – 1.

µC/OS-II also initializes four pools of free data structures as shown in figure 3.2.9. Each of these pools are singly linked lists and allows µC/OS-II to quickly obtain and return an element from and to a pool. Note that the number of free OS_TCBs in the free pool is determined by OS_MAX_TASKS specified in OS_CFG.H. µC/OS -II automatically allocates OS_N_SYS_TASKS (see uCOS_II.H) OS_TCB entries automatically. This of course allows for sufficient task control blocks for the statistic task and the idle task.

Abbildung in dieser Leseprobe nicht enthalten

Figure 3.2.9, Free Pools

3.2.10 Starting µC/OS-II

You start multitasking by calling OSStart() . Before you start µC/OS-II, however, you MUST create at least one of your application tasks as shown in listing 3.2.10.

Abbildung in dieser Leseprobe nicht enthalten

Listing 3.2.10, Initializing and Starting µC/OS-II

3.3 Services provide from MicroC/OS-II

As a high quality RTOS, µC/OS-II provides the following services:

- Semaphores
- Mutual Exclusion Semaphores (to reduce priority inversions) (added in V2.04)
- Event Flags (added in V2.51)
- Message Mailboxes
- Message Queues
- Task Management (Create, Delete, Change Priority, Suspend/Resume etc.)
- Fixed Sized Memory Block management
- Time Management

These services are described in the following five sections:

- Task management
- Time management
- Resource management
- Mailbox management
- Memory management

3.3.1 Task Management

We saw in the previous chapter that a task of µC/OS-II is either an infinite loop function or a function that deletes itself when it is done executing. A task looks just like any other C function containing a return type and an argument but, it must never return. The return type of a task must always be declared to be void.

[...]