opencomrtos 1.4_tutorial_3o4_presentation

Session #1.3: OpenComRTOS Internals

Bernhard [email protected]

Altreonic NVGemeentestraat 61 Bus 1

3210 LindenBelgium

January 12, 2012

Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 1 / 37

Outline of this Workshop

Session #1.1: The Theoretical foundations of OpenComRTOS

Session #1.2: Introduction to OpenComRTOS and theOpenComRTOS Designer Suite

Session #1.3: OpenComRTOS Internals

Session #1.4: Hands on with the OpenComRTOS Designer Suite


1 How OpenComRTOS works InternallyInteracting Entities in DetailVirtual Single Processor (VSP) Programming ModelPriority Inversion

2 Build Process

3 Extending OpenComRTOSComponentsPorting to a new PlatformDevice Drivers

4 Summary


Outline


2 Build Process


4 Summary

OpenComRTOS Paradigms

Interacting Entities

Virtual Single Processor (VSP) Programming Model.


Interacting Entities

Entities:I Tasks (Active Entities)I Hubs (Passive Entities)

Interactions


Task Internals


Hub Internals


Basic Interactions

Every Interactions is represented with a Task injecting a Packet intothe Task Input Port of the Kernel Task.

Every Packet contains the current Priority of the Task, that sent it.

Sending a Packet results in the Task to be suspended, until thecorresponding Acknowledgement Packet arrives.


Virtual Single Processor (VSP) Programming Model.

Entities can be distributed in any form over the system,OpenComRTOS ensures that the logical behaviour is preserved.

Separates Hardware from Software. Both can be changed almostindependently.

Interactions take place independent of placement.

For VSP to work OpenComRTOS separates Topology and Applicationfrom each other.


Topology

Nodes

Link Ports

Links


Application Entities

Tasks

Hubs

Host Service Components

All entities of an Application can be mapped onto any available Node,with the exception of Host Service components, these must be placedeither on a Windows or Posix32 node.


Interactions in Multi Node Systems


Priority Inversion

Definition: “priority inversion is a problematic scenario in scheduling whena higher priority task is indirectly preempted by a lower priority taskeffectively ‘inverting’ the relative priorities of the two tasks.”.Typically that is caused when s shared resource gets protected with a Lock/ Mutex, for instance:

a shared memory buffer that must be read out before new data iswritten in;

hardware status registers that set a peripheral in a specific state;

a peripheral that can handle only one request at a time.


Priority Inheritance as Solution

If Priority Inversion gets detected, the Priority of the lower PriorityTask get boosted to the level of the higher Priority Task.

OpenComRTOS supports that on single Node systems.

OpenComRTOS supports this also system wide, i.e. the location ofthe Task does not matter.


Outline


2 Build Process


4 Summary

Build Process of OpenComRTOS Systems

1 Project-Generator Phase:I Calculates the Routing-Tables for each Node.I Determines the IDs of the Enties of the system.I Creates the directory Output.I Creates a directory for each Node, and stores the Node-XML file there.I Triggers the build process for each Node.

2 Code-Generator Phase:I Generates a CMake based build system for the Node.I Generates the Node-Configuration Files for the Node (main one isL1 node config.c)

3 Compile and Link Phase:I Each Node gets compiled and linked.I The resulting binary gets placed in the directory Output/bin.


Outline


2 Build Process


4 Summary

Components

Are a collection of Tasks and Hubs, which provide a certain service.

Get provided in a separate library, together with a Metamodel forOpenVE.

Provide an access library which can be used from any platform, evenif the service is platform specific.

Examples for Components are:I Stdio Host Service (SHS)I Graphical Host Service (GHS)I Open System Inspector (OSI)I Safe Virtual Machine for C (SVM


Application Diagram of a Component


Porting to a new Platform

Consists of the following phases:

Phase 1: Context Switch

Phase 2: Interrupt Support

Phase 3: Multi-Node and Integration


Phase 1: Context Switch

Create a new folder in src/platforms/, and copy the contents ofsrc/generic into it.

Integrate the newly created folder into the build system.

Map OpenComRTOS data types to platform data types:I L1 BOOLI L1 BYTEI L1 INT16 / L1 UINT16I L1 INT32 / L1 UINT32

Fill in the blanks: Context Switch, Enter and Leave Critical Section,Initialisation of the Task Context, Starting a Task.

Test this with a Semaphore Loop Project.


Semaphore Loop Project


Phase 2: Interrupt Support

Implement Interrupt Handling Support: Enter ISR, Leave ISR;

Implement the Periodic Timer driver;

Extend the previously developed Semaphore Loop Project, with a Taskthat performs a waiting with timeout operation on a new Semaphore.


Extended Semaphore Loop Project


Phase 3: Multi-Node and Integration

Implement a Link Driver, typically RS232;

Implement the network endianess adjustment routines. Over a link wealways use big-endian.

Implement an Example that connects two Nodes, typically the newPlatform plus a Win32 / Posix32 Node.

Implement the remaining device drivers for the target (Link Drivers,special IO drivers).

Adjust OpenVE Metamodel and the Code Generators.


Device Drivers

Timer-Drivers

Link-Drivers

General-Drivers


Timer-Driver Properties

Provide a periodic tick (usuall every 1ms).

Handle Timeouts

Provide high precision timestamps when tracing.

Integrated into the Platform Image.

Hard instantiation during system startup.

Have no Task.


Timer-Driver API

void L1 initTimer(void)

void L1 Timer setTimeout(L1 Timeout tick, L1 UINT32 id)

void L1 Timer cancelTimeout(void)

L1 Timeout L1 Timer getExpiredTimeoutTicks(void)

L1 Timeout L1 Timer getRemainingTimeoutTicks(void)

L1 Time L1 Timer getCurrentTime(void)

L1 Status L1 Timer getTimeStamp

(L1 TimeStamp ∗ pTimeStamp)

L1 UINT32 L1 Timer getLowCounterFrequency(void)

L1 UINT32 L1 Timer getHighCounterFrequency(void)


Link-Driver Properties

Transfer Packets from one Node to another Node, using a specificcommunication media (RS232, Ethernet, . . . ).

Consist of at least one Task, which is used the send a Packet over thecommunication media.

Initialise the hardware device associated with them

Provide Client and Server type of link Initialisation.

Kernel interface to them using a dedicated protocol.

Link-Driver does the link-port routing.

Link-Driver needs to be announced to the system using a Metamodel


Link-Driver API

L1 BOOL FooDriver init(FooDriver ∗ self)

L1 BOOL FooLinkPort initServer

(FooDriver ∗ driver, FooLinkPort ∗ self)

L1 BOOL FooLinkPort initClient

(FooDriver ∗ driver, FooLinkPort ∗ self)

L1 BOOL FooDriver sendPacket

(L1 XferPacket ∗ packet, L1 UINT32 size)

void FooDriver EntryPoint(L1 TaskArguments)


General-Driver Properties

Implemented as normal user Tasks.

Full control over the Application Programmer Interface (API).

Additionally can be implemented like a Host Service Component.

Interfacing to the Interrupt Request (IRQ) has to be done in theplatform specific way.


Outline


2 Build Process


4 Summary

Summary

This Lecture covered the following:

Build process of OpenComRTOS projects;

The steps involved in porting OpenComRTOS to a new Platform.


Questions?


Thank Youfor Your attention

http://www.altreonic.com

http://www.altreonic.com

References


opencomrtos 1.4_tutorial_3o4_presentation

Technology