Goals and Objectives
In this project we implement, test, and instrument a Real Time Operating System whose interface is
defined in os.h. The interface
for the RTOS is simple; nevertheless, it is capable enough to handle
many embedded real time systems. In particular, it demonstrates following main responsibilities
expected from an RTOS:
In Section Test and Debug, we describe the test cases that are needed to demonstrate that requirements specified in Section Formal Specification are satisfied by our implementation. We also describe how we tested our implementation by kernel tracing. We show two different tracing mechanisms, i.e., storing and capturing trace data in the memory and in the logic analyzer respectively. We will also describe types of data that we store in the memory and capture in the logic analyzer.
Switching contexts between different tasks based on the scheduling policies of the RTOS is one of the core responsibilities of the RTOS task scheduler. In Section Context Switch, we will describe the context of a newly created task in AVR ATmel 8 bit MCU architecture. We will, then, show how kernel performs context switching between different tasks.
In the previous paragraph, we mentioned that the scheduler is responsible for scheduling different tasks. In Section Scheduling, we will describe in detail the scheduling algorithm with the help of a number of flow charts. At this point we just briefly mention that we will implement a fixed-priority pre-emptive and cooperative scheduling.
In Section IPC, we will mention the mechanisms this RTOS provides to synchronize between different tasks. This IPC is lock and loop free, and event driven where only one task can wait for an event.
The RTOS also implicitly defines memory management in the form of some policies that we expect an application engineer to respect. In Section Memory, we will briefly mention those policies.
The interface of the RTOS we are implementing is very similar to the interfaces implemented by students of the same course in earlier years. We benefited hugely from their very solid implementation. In Section Discussion, we will describe the overall architecture of this RTOS. We will also compare capabilities of this RTOS to RTOSes implemented in earlier years. We will also briefly mention the differences between those interfaces.
An RTOS can be used in safety-critical embedded systems. Therefore, it is very crucial to ensure that an RTOS is error free. To that end, we would like to look into formal methods to generate and automatically verify RTOS code. In Section Future Work, We will briefly mention some tools that we looked into.
- task Management and scheduling, and
- inter-process communication and synchronization.
- interrupt servicing, and
- memory management.
In Section Test and Debug, we describe the test cases that are needed to demonstrate that requirements specified in Section Formal Specification are satisfied by our implementation. We also describe how we tested our implementation by kernel tracing. We show two different tracing mechanisms, i.e., storing and capturing trace data in the memory and in the logic analyzer respectively. We will also describe types of data that we store in the memory and capture in the logic analyzer.
Switching contexts between different tasks based on the scheduling policies of the RTOS is one of the core responsibilities of the RTOS task scheduler. In Section Context Switch, we will describe the context of a newly created task in AVR ATmel 8 bit MCU architecture. We will, then, show how kernel performs context switching between different tasks.
In the previous paragraph, we mentioned that the scheduler is responsible for scheduling different tasks. In Section Scheduling, we will describe in detail the scheduling algorithm with the help of a number of flow charts. At this point we just briefly mention that we will implement a fixed-priority pre-emptive and cooperative scheduling.
In Section IPC, we will mention the mechanisms this RTOS provides to synchronize between different tasks. This IPC is lock and loop free, and event driven where only one task can wait for an event.
The RTOS also implicitly defines memory management in the form of some policies that we expect an application engineer to respect. In Section Memory, we will briefly mention those policies.
The interface of the RTOS we are implementing is very similar to the interfaces implemented by students of the same course in earlier years. We benefited hugely from their very solid implementation. In Section Discussion, we will describe the overall architecture of this RTOS. We will also compare capabilities of this RTOS to RTOSes implemented in earlier years. We will also briefly mention the differences between those interfaces.
An RTOS can be used in safety-critical embedded systems. Therefore, it is very crucial to ensure that an RTOS is error free. To that end, we would like to look into formal methods to generate and automatically verify RTOS code. In Section Future Work, We will briefly mention some tools that we looked into.