OpenComRTOS 1.4_tutorial_3o4_presentation

OpenComRTOS 1.4_tutorial_3

1. Session #1.3: OpenComRTOS Internals
Bernhard Sputh
[email protected]
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

6. Interacting Entities
Entities:
ITasks (Active Entities)
IHubs (Passive Entities)
Interactions
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 6 / 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 separatesTopologyandApplication
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 separatesTopologyandApplication
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
Denition: \priority inversion is a problematic scenario in scheduling when
a higher priority task is indirectly preempted by a lower priority task
eectively `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 buer that must be read out before new data is
written in;
hardware status registers that set a peripheral in a specic 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:
ICalculates the Routing-Tables for each Node.
IDetermines the IDs of the Enties of the system.
ICreates the directoryOutput.
ICreates a directory for each Node, and stores the Node-XML le there.
ITriggers the build process for each Node.
2
Code-Generator Phase:
IGenerates a CMake based build system for the Node.
IGenerates the Node-Conguration Files for the Node (main one is
L1nodeconfig.c)
3
Compile and Link Phase:
IEach Node gets compiled and linked.
IThe resulting binary gets placed in the directoryOutput/bin.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 17 / 37

19. Build Process of OpenComRTOS Systems
1
Project-Generator Phase:
ICalculates the Routing-Tables for each Node.
IDetermines the IDs of the Enties of the system.
ICreates the directoryOutput.
ICreates a directory for each Node, and stores the Node-XML le there.
ITriggers the build process for each Node.
2
Code-Generator Phase:
IGenerates a CMake based build system for the Node.
IGenerates the Node-Conguration Files for the Node (main one is
L1nodeconfig.c)
3
Compile and Link Phase:
IEach Node gets compiled and linked.
IThe resulting binary gets placed in the directoryOutput/bin.
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 17 / 37

20. Build Process of OpenComRTOS Systems
1
Project-Generator Phase:
ICalculates the Routing-Tables for each Node.
IDetermines the IDs of the Enties of the system.
ICreates the directoryOutput.
ICreates a directory for each Node, and stores the Node-XML le there.
ITriggers the build process for each Node.
2
Code-Generator Phase:
IGenerates a CMake based build system for the Node.
IGenerates the Node-Conguration Files for the Node (main one is
L1nodeconfig.c)
3
Compile and Link Phase:
IEach Node gets compiled and linked.
IThe resulting binary gets placed in the directoryOutput/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 specic.
Examples for Components are:
IStdio Host Service (SHS)
IGraphical Host Service (GHS)
IOpen System Inspector (OSI)
ISafe 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 insrc/platforms/, and copy the contents of
src/genericinto it.
Integrate the newly created folder into the build system.
Map OpenComRTOS data types to platform data types:
IL1BOOL
IL1BYTE
IL1INT16/L1UINT16
IL1INT32/L1UINT32
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 insrc/platforms/, and copy the contents of
src/genericinto it.
Integrate the newly created folder into the build system.
Map OpenComRTOS data types to platform data types:
IL1BOOL
IL1BYTE
IL1INT16/L1UINT16
IL1INT32/L1UINT32
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 insrc/platforms/, and copy the contents of
src/genericinto it.
Integrate the newly created folder into the build system.
Map OpenComRTOS data types to platform data types:
IL1BOOL
IL1BYTE
IL1INT16/L1UINT16
IL1INT32/L1UINT32
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

28. Semaphore Loop Project
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 23 / 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

34. Timer-Driver API
void L1initTimer(void)
void L1TimersetTimeout(L1Timeout tick, L1UINT32 id)
void L1TimercancelTimeout(void)
L1Timeout L1TimergetExpiredTimeoutTicks(void)
L1Timeout L1TimergetRemainingTimeoutTicks(void)
L1Time L1TimergetCurrentTime(void)
L1Status L1TimergetTimeStamp
(L1TimeStamppTimeStamp)
L1UINT32 L1TimergetLowCounterFrequency(void)
L1UINT32 L1TimergetHighCounterFrequency(void)
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 29 / 37

35. Link-Driver Properties
Transfer Packets from one Node to another Node, using a specic
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

36. Link-Driver API
L1BOOL FooDriverinit(FooDriver self)
L1BOOL FooLinkPortinitServer
(FooDriverdriver, FooLinkPort self)
L1BOOL FooLinkPortinitClient
(FooDriverdriver, FooLinkPort self)
L1BOOL FooDriversendPacket
(L1XferPacketpacket, L1UINT32 size)
void FooDriverEntryPoint(L1TaskArguments)
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 31 / 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 specic 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

40. Questions?
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 35 / 37

41. Thank You
for Your attention
http://www.altreonic.com

42. References
Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 37 / 37