Time Series Foundation Models - current state and future directions
OpenComRTOS 1.4_tutorial_3o4_presentation
1. 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
2. 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
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 2 / 37
3. 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
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 3 / 37
4. 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
Porting to a new Platform
Device Drivers
4 Summary
5. OpenComRTOS Paradigms
Interacting Entities
Virtual Single Processor (VSP) Programming Model.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 5 / 37
7. Task Internals
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 7 / 37
8. Hub Internals
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 8 / 37
9. 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.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 9 / 37
10. 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.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 10 / 37
11. 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.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 10 / 37
12. Topology
Nodes
Link Ports
Links
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 11 / 37
13. 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.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 12 / 37
14. Interactions in Multi Node Systems
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 13 / 37
15. 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.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 14 / 37
16. 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.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 15 / 37
17. 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
Porting to a new Platform
Device Drivers
4 Summary
18. 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 file there.
Triggers the build process for each Node.
2 Code-Generator Phase:
Generates a CMake based build system for the Node.
Generates the Node-Configuration 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.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 17 / 37
19. 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 file there.
Triggers the build process for each Node.
2 Code-Generator Phase:
Generates a CMake based build system for the Node.
Generates the Node-Configuration 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.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 17 / 37
20. 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 file there.
Triggers the build process for each Node.
2 Code-Generator Phase:
Generates a CMake based build system for the Node.
Generates the Node-Configuration 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.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 17 / 37
21. 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
Porting to a new Platform
Device Drivers
4 Summary
22. 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 specific.
Examples for Components are:
Stdio Host Service (SHS)
Graphical Host Service (GHS)
Open System Inspector (OSI)
Safe Virtual Machine for C (SVM
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 19 / 37
23. Application Diagram of a Component
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 20 / 37
24. Porting to a new Platform
Consists of the following phases:
Phase 1: Context Switch
Phase 2: Interrupt Support
Phase 3: Multi-Node and Integration
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 21 / 37
25. 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.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 22 / 37
26. 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.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 22 / 37
27. 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.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 22 / 37
29. 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.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 24 / 37
30. Extended Semaphore Loop Project
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 25 / 37
31. 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.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 26 / 37
32. Device Drivers
Timer-Drivers
Link-Drivers
General-Drivers
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 27 / 37
33. 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.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 28 / 37
35. Link-Driver Properties
Transfer Packets from one Node to another Node, using a specific
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
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 30 / 37
37. 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 specific way.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 32 / 37
38. 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
Porting to a new Platform
Device Drivers
4 Summary
39. Summary
This Lecture covered the following:
Build process of OpenComRTOS projects;
The steps involved in porting OpenComRTOS to a new Platform.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 34 / 37