OpenComRTOS 1.4_tutorial_3o4_presentation
Upcoming SlideShare
Loading in...5
×
 

OpenComRTOS 1.4_tutorial_3o4_presentation

on

  • 305 views

OpenComRTOS 1.4_tutorial_3

OpenComRTOS 1.4_tutorial_3

Statistics

Views

Total Views
305
Views on SlideShare
305
Embed Views
0

Actions

Likes
1
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

OpenComRTOS 1.4_tutorial_3o4_presentation OpenComRTOS 1.4_tutorial_3o4_presentation Presentation Transcript

  • Session #1.3: OpenComRTOS Internals Bernhard Sputh bernhard.sputh@altreonic.com Altreonic NV Gemeentestraat 61 Bus 1 3210 Linden Belgium January 12, 2012Bernhard 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 Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 2 / 37
  • 1 How OpenComRTOS works Internally Interacting Entities in Detail Virtual Single Processor (VSP) Programming Model Priority Inversion2 Build Process3 Extending OpenComRTOS Components Porting to a new Platform Device Drivers4 Summary Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 3 / 37
  • Outline1 How OpenComRTOS works Internally Interacting Entities in Detail Virtual Single Processor (VSP) Programming Model Priority Inversion2 Build Process3 Extending OpenComRTOS Components Porting to a new Platform Device Drivers4 Summary
  • OpenComRTOS Paradigms Interacting Entities Virtual Single Processor (VSP) Programming Model. Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 5 / 37
  • Interacting Entities Entities: Tasks (Active Entities) Hubs (Passive Entities) Interactions Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 6 / 37
  • Task Internals Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 7 / 37
  • Hub Internals Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 8 / 37
  • 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
  • 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 Applicationfrom each other. Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 10 / 37
  • 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 Applicationfrom each other. Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 10 / 37
  • Topology Nodes Link Ports Links Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 11 / 37
  • Application Entities Tasks Hubs Host Service ComponentsAll 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. Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 12 / 37
  • Interactions in Multi Node Systems Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 13 / 37
  • Priority InversionDefinition: “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 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
  • 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
  • Outline1 How OpenComRTOS works Internally Interacting Entities in Detail Virtual Single Processor (VSP) Programming Model Priority Inversion2 Build Process3 Extending OpenComRTOS Components Porting to a new Platform Device Drivers4 Summary
  • 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
  • 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
  • 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
  • Outline1 How OpenComRTOS works Internally Interacting Entities in Detail Virtual Single Processor (VSP) Programming Model Priority Inversion2 Build Process3 Extending OpenComRTOS Components Porting to a new Platform Device Drivers4 Summary
  • 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
  • Application Diagram of a Component Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 20 / 37
  • Porting to a new PlatformConsists 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
  • 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
  • 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
  • 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
  • Semaphore Loop Project Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 23 / 37
  • 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
  • Extended Semaphore Loop Project Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 25 / 37
  • 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
  • Device Drivers Timer-Drivers Link-Drivers General-Drivers Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 27 / 37
  • 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
  • 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) Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 29 / 37
  • 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
  • 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) Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 31 / 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
  • Outline1 How OpenComRTOS works Internally Interacting Entities in Detail Virtual Single Processor (VSP) Programming Model Priority Inversion2 Build Process3 Extending OpenComRTOS Components Porting to a new Platform Device Drivers4 Summary
  • SummaryThis 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
  • Questions?Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 35 / 37
  • Thank Youfor Your attentionhttp://www.altreonic.com
  • References Bernhard Sputh (Altreonic) Session #1.3 January 12, 2012 37 / 37