OpenComRTOS 1.4_tutorial_3o4_presentation

Session #1.3: OpenComRTOS Internals

Bernhard Sputh
bernhard.sputh@altreonic.com

Altreonic NV
Gemeentestraat 61 Bus 1
3210 Linden
Belgium

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 the
OpenComRTOS Designer Suite
Session #1.3: OpenComRTOS Internals
Session #1.4: Hands on with the OpenComRTOS Designer Suite


1 How OpenComRTOS works Internally
Interacting Entities in Detail
Virtual Single Processor (VSP) Programming Model
Priority Inversion

2 Build Process

3 Extending OpenComRTOS
Components
Porting to a new Platform
Device Drivers

4 Summary


Outline

1 How OpenComRTOS works Internally
Interacting Entities in Detail
Virtual Single Processor (VSP) Programming Model
Priority Inversion

2 Build Process

3 Extending OpenComRTOS
Components
Device Drivers

4 Summary

OpenComRTOS Paradigms

Interacting Entities
Virtual Single Processor (VSP) Programming Model.


Interacting Entities

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


Task Internals


Hub Internals


Basic Interactions
Every Interactions is represented with a Task injecting a Packet into
the 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 the
corresponding 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 almost
independently.
Interactions take place independent of placement.
For VSP to work OpenComRTOS separates Topology and Application
from 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 placed
either on a Windows or Posix32 node.


Interactions in Multi Node Systems


Priority Inversion

Definition: “priority inversion is a problematic scenario in scheduling when
a higher priority task is indirectly preempted by a lower priority task
effectively ‘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 is
written 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 Priority
Task 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 of
the Task does not matter.


Build Process of OpenComRTOS Systems

1 Project-Generator Phase:
Calculates the Routing-Tables for each Node.
Determines the IDs of the Enties of the system.
Creates the directory Output.
Creates a directory for each Node, and stores the Node-XML ﬁle there.
Triggers the build process for each Node.
2 Code-Generator Phase:
Generates a CMake based build system for the Node.
Generates the Node-Conﬁguration Files for the Node (main one is
L1 node config.c)
3 Compile and Link Phase:
Each Node gets compiled and linked.
The resulting binary gets placed in the directory Output/bin.


Components

Are a collection of Tasks and Hubs, which provide a certain service.
Get provided in a separate library, together with a Metamodel for
OpenVE.
Provide an access library which can be used from any platform, even
if the service is platform speciﬁc.
Examples for Components are:
Stdio Host Service (SHS)
Graphical Host Service (GHS)
Open System Inspector (OSI)
Safe Virtual Machine for C (SVM


Application Diagram of a Component



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 of
src/generic into it.
Integrate the newly created folder into the build system.
Map OpenComRTOS data types to platform data types:
L1 BOOL
L1 BYTE
L1 INT16 / L1 UINT16
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 Task
that 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 we
always use big-endian.
Implement an Example that connects two Nodes, typically the new
Platform 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 speciﬁc
communication media (RS232, Ethernet, . . . ).
Consist of at least one Task, which is used the send a Packet over the
communication 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 the
platform speciﬁc way.


Summary

This Lecture covered the following:
Build process of OpenComRTOS projects;
The steps involved in porting OpenComRTOS to a new Platform.


Questions?


Thank You
for Your attention

http://www.altreonic.com

References


OpenComRTOS 1.4_tutorial_3o4_presentation

More Related Content

Viewers also liked

Similar to OpenComRTOS 1.4_tutorial_3o4_presentation

Recently uploaded

OpenComRTOS 1.4_tutorial_3o4_presentation