build real time operating system on microcontroller

Question

Now I try to write RTOS by my self. I have a question: in RTOS concept, we have "context switch" theory. From what I know, context switch is to describe that when some task is running and the other task has a higher priority, the higher priority task will run and the current task will be saved its state and continue to start after the higher task finish. To do this concept, I think the higher priority task will run in the interrupt functions since the interrupt functions have higher priority than other instruction, am I right?. If i am right, so i do not need to write code to save the current task's state, since as i know that after interrupt, the program will return to where it is interrupted. If I am wrong, how can I save the current task 's state? Is it necessary to write assembly code to do that since I see halogen generate an assembly code file to do this for FreeRTOS?

Answer 1

I think the higher priority task will run in the interrupt functions since the interrupt functions have higher priority than other instruction, am I right?

No, interrupt handlers run in their own context. The context switching and priority of interrupts is (normally) handled by the processor hardware, whilst RTOS threads (again normally) are switched by software mechanisms involving storing register states of the current task, restoring the register states of the new task the last register restored being the program-counter so that execution continues from the stored location of the new task.

It is not possible to perform a context switch entirely in high-level code in languages that do not support threading intrinsically, since the register set is architecture specific and system level-languages such as C are not architecture specific and do not provide register level access.

One of the best resources for learning in detail how an RTOS works internally is the Jean Labrosse's book MicroC/OS-II(now freely available in PDF from Micrium); start from Chapter 2 for an overview of RTOS concepts, and Chapter 3 describes the kernel implementation (context switching specifically in section 3.06) - you would have to look at the various ports available to see the precise implementation of OS_TASK_SW() for specific architectures; in the book it is presented as pseudocode.

Although a comercial RTOS in its own right (largely superseded by MicroC/OS-III), MicroC-OS/II was originally available only by purchasing this book and was intended specifically for teaching RTOS concepts and implementation. FreeRTOS (recommended by others as an exemplar) on the other hand, has the advantage of being open-source, but is not nearly so well documented at the implementation level, and is perhaps a somewhat unconventional RTOS implementation (though not necessarily at the context switching level).

MicroC/OS-II is perhaps unusual in that it does not support tasks of equal priority level (all tasks must have a different priority) and therefore does not support round-robin scheduling; it is a pure preemptive, priority-based RT scheduler - this allows for very efficient and fast context switch times. MicroC/OS-III is more conventional in that sense, but at the expense of context switch times.

Answer 2

A context switch has nothing in particular to do with task priority. It simply means you save off the entire CPU state of one task, and load the state of another task. Yes, this will be written in assembly, as you need to save the registers.

If you try to go with your current approach you will immediately fail. If a Hugh priority task is running in the interrupt handler, how will your kernel handle the next interrupt? Low interrupt latency is key to a successful RTOS (or any OS).

Answer 3

An RTOS which deserves the name RTOS needs to have a few more features than only preemptive scheduling. Other design decisions are whether to use nested interrupts or not, if it applies a deferred interrupt processing scheme, if there is priority inversion allowed or how to handle it, if there is time slicing or run to completion (or both) and many other aspects.

Your CPU has a set of registers, such as accumulator and other CPU working registers, stack pointer, maybe floating point registers and possibly more registers.

In order to implement a context switch, you need to identify the set of state of a running task which you need to save so it can resume later on.

Typically, that saving of state part is done in assembler or using intrinsic assembler functions from within C code.

By no means should RTOS tasks run in the interrupt context.

If you implement a interrupt handler, you simply have a program with an interrupt handler and not an RTOS ;)

Answer 4

Writing an RTOS is quite a task to take upon your self, and given the state of your questions, I would recommend you trying something simpler first. However, if you are determined to try making your own RTOS here are some pointers.

Part of an RTOS is the ability to make a system for preemptive scheduling (Run multiple tasks and switch between them based on coditions like time and priority). Hardcoding your applicationcode of a higher priority task into an interrupt does not do that. Rather you should have an timer-interrupt ticking at a steady rate. In the interrupt you should store the current context, keep track of your system-time (make some functions to set/get systemtime in your OS, and update the time for every interrupt), check if the new tick has caused another task's delay to expire and if so switch to the context of that task.

If the making of all this you want to be able to keep track of the memory-layout for each task, as you need to give each task a certain amount of stack. You want to implement a control-structure to keep track of the states of all your tasks:

• How many tasks do you currently have?
• What is each tasks memory-segment?
• Is the task ACTIVE, READY or BLOCKED?
• If BLOCKRED, at what time is each task scheduled to be READY again?

And you will for sure not get around using at least a little bit of assembly-code for your context switches.

I can recommend you taking a look at FreeRTOS.org, as they describe everything of the FreeRTOS-kernal. Maby start looking at: http://www.freertos.org/implementation/a00014.html