Open ComRTOS 1.4_tutorial_2o4_presentation
Upcoming SlideShare
Loading in...5
×
 

Open ComRTOS 1.4_tutorial_2o4_presentation

on

  • 450 views

OpenComRTOS 1.4_tutorial_2

OpenComRTOS 1.4_tutorial_2

Statistics

Views

Total Views
450
Views on SlideShare
449
Embed Views
1

Actions

Likes
1
Downloads
3
Comments
0

1 Embed 1

http://www.slashdocs.com 1

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

    Open ComRTOS 1.4_tutorial_2o4_presentation Open ComRTOS 1.4_tutorial_2o4_presentation Presentation Transcript

    • Session #1.2: Introduction to OpenComRTOS and the OpenComRTOS Designer Suite Bernhard Sputh bernhard.sputh@altreonic.com Altreonic NV Gemeentestraat 61 Bus 1 3210 Linden Belgium January 12, 2012Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 1 / 70
    • 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.2 January 12, 2012 2 / 70
    • 1 OpenComRTOS Designer Suite2 OpenComRTOS System Composition Tasks The OpencomRTOS “HUB” Host Service Components3 Designing Distributed Heterogeneous Systems using the OpenComRTOS-Suite How Micro Controllers handle Interrupts Presenting the Measurement Results Requirements Specifying the System Implementation Application Collected Measurement Results4 Summary Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 3 / 70
    • Demonstration of OpenComRTOS in Action Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 4 / 70
    • Outline1 OpenComRTOS Designer Suite2 OpenComRTOS System Composition Tasks The OpencomRTOS “HUB” Host Service Components3 Designing Distributed Heterogeneous Systems using the OpenComRTOS-Suite How Micro Controllers handle Interrupts Presenting the Measurement Results Requirements Specifying the System Implementation Application Collected Measurement Results4 Summary
    • OpenComRTOS Designer SuiteThe OpenComRTOS Designer Suite consists of the following parts: OpenComRTOS OpenVE Open Tracer Open System Debugger Safe Virtual Machine for C (SVM). Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 6 / 70
    • OpenComRTOS Communicating Sequential Processes (CSP) inspired distributed RTOS Supports Heterogeneous Systems Formally Developed. Small Codesize Highly portable; Static compilation avoids problems do to exhaustion of Memory. Built in tracing-mode allows to record what happened in a system for analysis using OpenTracer. Distributed Priority Inheritance. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 7 / 70
    • Available Ports of OpenComRTOS Active Ports: ARM Cortex M3 NXP CoolFlux Posix32 Win32 XMOS XS-1 (L-Series) Dormant Ports1 Leon3 Melexis MLX-16 Xlinix Microblaze 1 Present but not actively maintained at the moment. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 8 / 70
    • Code-Size Figures Service MLX16 MicroBlaze Leon3 ARM XMOS L1 Hub shared 400 4756 4904 2192 4854 L1 Port 4 8 8 4 4 L1 Event 70 88 72 36 54 L1 Semaphore 54 92 96 40 64 L1 Resource 104 96 76 40 50 L1 FIFO 232 356 332 140 222 L1 PacketPool NA 296 268 120 166 Total L1 Services 1048 5692 5756 2572 5414 Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 9 / 70
    • Code-Size on NXP-CoolFlux Example #Tasks PMEM XMEM YMEM XYMEM SemaphoreLoop W 4 1785 768 1 1 PortLoop W 4 1759 784 1 1 Semaphore WT 3 2001 613 1 1 CodeSize All 3 2066 721 1 1 CodeSize All pTimer 3 2301 721 1 1 Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 10 / 70
    • Context-Switch Figures 1Measurement Setup:To calculate the loop time, the time for 1000 iterations gets measured,using the highest precision timer available. Each loop performs fourcontext switches. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 11 / 70
    • Context-Switch Figures 2 Clock Speed Context Size Memory Lo- Loop Time cation ARM Cortex M3 50MHz 16×32 bit internal 52.5µs NXP CoolFlux2 NA 70×24 bit internal 3826 cycles XMOS 100MHz 14×32 bit internal 26.8µs Leon3 40MHz 32×32 bit external 136.1µs MLX-16 6MHz 4×16 bit internal 100.8µs Xlinix Microblaze 100MHz 4×32 bit internal 33.6µs 2 measured using the Target NXP-CoolFlux Simulator Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 12 / 70
    • OpenVE Graphical modelling of the system-topology (hardware setup). Graphical modelling of the Application that runs on top of the topology. Integrated code-generators create all the OpenComRTOS configuration code and the necessary build system. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 13 / 70
    • Graphical modelling of the system-topology Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 14 / 70
    • Graphcial modelling of the Application that runs on top ofthe topology. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 15 / 70
    • OpenTracer Visualises previously recorded trace-files, which contain the following information: Task Scheduling; Interactions with synchronisation primitives; Internode communication; User generated markers. Time measurements, and thus verifying that critical timings are met by the system. Link tracefiles recorded by the nodes in the system. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 16 / 70
    • OpenTracer displaying a Multi-Node Trace Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 17 / 70
    • Open System Debugger (OSD) Allows to access the System State during runtime; Allows to suspend and resume Tasks during runtime; Allows modification to the memory of Nodes in the System; Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 18 / 70
    • Safe Virtual Machine for C (SVM) Interprets ARM-Thumb-1 byte code. Executes on OpenComRTOS Task. Allows to dynamically load code into the System. Minimal code-size: just 3kB when compiled for an ARM-Cortex-M3. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 19 / 70
    • Outline1 OpenComRTOS Designer Suite2 OpenComRTOS System Composition Tasks The OpencomRTOS “HUB” Host Service Components3 Designing Distributed Heterogeneous Systems using the OpenComRTOS-Suite How Micro Controllers handle Interrupts Presenting the Measurement Results Requirements Specifying the System Implementation Application Collected Measurement Results4 Summary
    • OpenComRTOS System CompositionA complete OpenComRTOS system always consists of two things: Topology Application Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 21 / 70
    • Topology Nodes Link Ports Links Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 22 / 70
    • Application Entities Tasks Hubs Host Service ComponentsAll entities of an Application can be mapped onto any available node, withthe exception of Host Service components, these must be placed either ona Windows or Posix32 node. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 23 / 70
    • Interaction Semantic W (Waiting)The Task waits until the interaction takes place, the standard CSPsemantic. Possible Return Values: RC OK: The operation was successful. RC FAIL: The operation was unsuccessful.The example ‘Demo W’, provided by the OpenComRTOS Designer Suite,illustrates graphically how waiting semantics work. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 24 / 70
    • Interaction Semantic WT (Waiting with Timeout)The Task waits until the interaction takes place, or the timeout expired,whichever happens earlier. The timeout starts once the request hasreached the Hub. Possible Return Values: RC OK: The operation was successful. RC FAIL: The operation was unsuccessful. RC TO: The operation was unsuccessful due to timing out.The example ‘Demo WT’, provided by the OpenComRTOS Designer Suite,illustrates graphically how waiting with timeout semantics work. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 25 / 70
    • Interaction Semantic NW (Non-Waiting)The Task does not wait for the interaction to take place. If the Hub is notready for the interaction, the interaction returns immediately with theerror code RC FAIL. Possible Return Values: RC OK: The operation was successful. RC FAIL: The operation was unsuccessful.The example ‘Demo NW’, provided by the OpenComRTOS Designer Suite,illustrates graphically how non-waiting semantics work. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 26 / 70
    • TasksA Task represents an active entity in OpenComRTOS, i.e. it has its ownagenda. A Task consists of: TaskEntryPoint: A function that represents what the Task does. StackSpace: A piece of memory used by the task to store context information, private to the Task. Priority: An integer value in the range 0–255, which determines the priority of this Task. Lower values mean higher priority. ReqeustPacket: Using this RequestPacket the task interacts with its environment. A RequestPacket is of type L1 Packet and consists of: Header-Part: Contains desitationPortID, priority, data size, and request-type information. Data-Part: This is used to transport data from one Task to another when using either Port or FIFO Hub-Implementations. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 27 / 70
    • The OpencomRTOS “HUB” Result of formal modelling; Resources, Events, Semaphores, Ports, FIFOs, etc. are all variants of a generic HUB. A HUB consists of four functional parts: Synchronisation point between Tasks; Stores task’s waiting state if needed; Predicate function: defines synchronisation conditions and lifts waiting state of tasks; Synchronisation function: functional behaviour after synchronisation. All HUBs operate system-wide, but transparently: Virtual Single Processor programming model. Possibility to create application specific hubs & services! =⇒ a new concurrent programming model.Hubs always offer two different types of interactions: Put and Get. Themeaning of these operations always depends upon the concrete Hubimplementation. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 28 / 70
    • Resource Description: A Resource is a Hub used to represent mutual exclusive access to a shared resource in OpenComRTOS. Usage: It is use to prevent that two tasks concurrently try to access the same resource. Thus it is used similar to Mutexes or (Spin)Locks available in other operating systems. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 29 / 70
    • Interaction: L1 LockResource() Description: This interaction tries to lock the resource. This operation will only succeed when the resource is free. Interaction Type: GET; Variants: L1 LockResource W(L1 HubID r): This interaction waits until the resource r could be locked. L1 LockResource WT(L1 HubID r, L1 Timeout t): This interaction waits until the resource r could be locked or the timeout t expired. L1 LockResource NW(L1 HubID r): This interaction tries to lock the resource r but returns immediately independent of whether or not it was able to do so. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 30 / 70
    • Interaction: L1 UnlockResource() Description: Unlocks a resource previously locked by the Task. Interaction Type: PUT; Variants: L1 UnlockResource W(L1 HubID r): Releases the resource and returns immediately. L1 UnlockResource WT(L1 HubID r, L1 Timeout t): Releases the resource and returns immediately. L1 UnlockResource NW(L1 HubID r): Releases the resource and returns immediately. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 31 / 70
    • Event Description: An event is used to synchronize two tasks, where Task T0 waits for Event E raised by Task T1 . Usage: Events are for instance used inside OpenComRTOS to signal the occurrence of an Interrupt Request from an Interrupt Service Routine to another Task. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 32 / 70
    • Interaction: L1 RaiseEvent Description: This signals the occurrence of an event. Interaction Type: PUT; Variants: L1 RaiseEvent W(L1 HubID e): If the Event e is not signalled it will raise it and return. Otherwise, the Task waits, until the Event can be signalled. L1 RaiseEvent WT(L1 HubID e, L1 Timeout t): If the Event e is not signalled it will raise it and return. Otherwise, the Task waits, until the Event can be signalled, or its timeout expires. L1 RaiseEvent NW(L1 HubID e): Returns immediately, independent whether or not event e could be raised. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 33 / 70
    • Interaction: L1 TestEvent Description: Tests whether or not an event has been signalled. Interaction Type: Get Variants: L1 TestEvent W(L1 HubID e): This interaction waits until Event e has been signaled. L1 TestEvent WT(L1 HubID e, L1 Timeout t): This interaction waits until Event e has been signaled, or the timeout t expired. L1 TestEvent NW(L1 HubID e): This interaction tries to test Event e but returns immediately independent of whether or not the Event e was signalled. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 34 / 70
    • Semaphore Description: A Semaphore is used to synchronize two tasks, where Task T0 waits for Semaphore S signalled by Task T1 . Usage: A Semaphore is always when one wants to decouple tasks and wants to prevent that synchronization events get lost. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 35 / 70
    • Interaction: L1 SignalSemaphore Description: Signals a Semaphore Interaction Type: PUT; Variants: L1 SignalSemaphore W(L1 HubID s): Signals Semaphore s and returns immediately. L1 SignalSemaphore WT(L1 HubID s, L1 Timeout t): Signals Semaphore s and returns immediately. L1 SignalSemaphore NW(L1 HubID s): Signals Semaphore s and returns immediately. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 36 / 70
    • Interaction: L1 TestSemaphore Description: Tests whether or not a Semaphore has been signalled. Interaction Type: GET; Variants: L1 TestSemaphore W(L1 HubID s): This interaction waits until Semaphore s has been signaled. L1 TestSemaphore WT(L1 HubID s, L1 Timeout t): This interaction waits until Semaphore s has been signaled, or the timeout t expired. L1 TestSemaphore NW(L1 HubID s): This interaction tries to test Semaphore s but returns immediately independent of whether or not s was signalled. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 37 / 70
    • Port Description: The Port is used for a synchronized exchange of data between Tasks. The data exchange uses the data field of the Tasks RequestPackets. Usage: Whenever data needs to be exchanged between two Tasks. The Host Services provided with OpenComRTOS heavily rely upon Ports for data exchange.Warning: Using NW interactions for both sending and receiving data froma Port will never synchronize, due to the implicit serialisation of requestsby the kernel! Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 38 / 70
    • Interaction: L1 PutPacketToPort Description: This interaction sends data to a Port from where it can be retrieved by another Task. Interaction Type: PUT; Variants: L1 PutPacketToPort W(L1 HubID p): Sends the Tasks RequestPacket to Port p and returns once the data exchange has taken place. L1 PutPacketToPort WT(L1 HubID p, L1 Timeout t): Sends the Tasks RequestPacket to Port p and returns once the data exchange has taken place, or the timeout t has expired. L1 PutPacketToPort NW(L1 HubID p): Sends the Tasks RequestPacket to Port p and returns immediately, independent of whether or not the data exchange took place. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 39 / 70
    • Interaction: L1 GetPacketFromPort Description: This interaction receives data from a Port, where another Task has sent it. Upon successful return the Tasks RequestPacket contains the data that the other task sent. Interaction Type: GET; Variants: L1 GetPacketFromPort W(L1 HubID p): Sends the Tasks RequestPacket to Port p and returns once the data exchange has taken place. L1 GetPacketFromPort WT(L1 HubID , L1 Timeout t): Sends the Tasks RequestPacket to Port p and returns once the data exchange has taken place, or the timeout t has expired. L1 GetPacketFromPort NW(L1 HubID ): Sends the Tasks RequestPacket to Port p and returns immediately, independent of whether or not the data exchange took place. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 40 / 70
    • FIFO Description: The FIFO can be seen as a Port with a build in buffer. It buffers a number of data elements and makes them available to anther task. Usage: FIFOs are always used when one must synchronize Tasks that have different data input characteristics. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 41 / 70
    • Interaction: L1 EnqueueFifo Description: This places the data part of the Tasks RequestPacket into the FIFO. Interaction Type: PUT; Variants: L1 EnqueueFifo W(L1 HubID f): Adds the data part of the Tasks RequestPacket into FIFO f and returns once this operation was completed, i.e. there was enough free space in FIFO f. L1 EnqueueFifo WT(L1 HubID f, L1 Timeout t): Adds the data part of the Tasks RequestPacket into FIFO f and returns once this operation was completed, i.e. there was enough free space in FIFO f, or if the timeout t expired. L1 EnqueueFifo NW(L1 HubID f): Tries to add the data part of the Tasks RequestPacket into FIFO f but returns immediately even if there is no enough free space in FIFO f. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 42 / 70
    • Interaction: L1 DequeueFifo Description: This operation retrieves one data part from a FIFO. Interaction Type: GET; Variants: L1 DequeueFifo W(L1 HubID f): Retrieves one data part from the FIFO f. It only returns once it could retrieve data from FIFO f. L1 DequeueFifo WT(L1 HubID f, L1 Timeout t): Retrieves one data part from the FIFO f. It only returns once it could retrieve data from FIFO f, or the timeout t expired. L1 DequeueFifo NW(L1 HubID f): Tries to retrieve one data part from the FIFO f, but returns immediately even if there no data part available in FIFO f. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 43 / 70
    • Memory Pool Description: Allows Tasks to dynamically acquire and release blocks of memory. Usage: To dynamically acquire and release blocks of memory.Warning: The pointer that gets returned is local to the Node wherethe Memory Pool is mapped to. While it can be used over thenetwork, this is not advisable. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 44 / 70
    • Interaction: L1 AllocateMemoryBlock W(L1 HubIDhubID, L1 BYTE **Memory, L1 UINT16 Size) Description: This allocates a chunk of memory with the specified in Size, and places a pointer to the first element in the memory chunk in the pointer pointed to by Memory. Interaction Type: GET; Variants: L1 AllocateMemoryBlock W(...): Allocates a memory block of the specified Size and returns the pointer in Memory. This call will wait until the memory block can be allocated. L1 AllocateMemoryBlock WT(...): Same as L1 AllocateMemoryBlock W(), but this call will wait until the memory block can be allocated, or the timeout t expired. L1 AllocateMemoryBlock NW(...): Same as L1 AllocateMemoryBlock W(), except that it returns immediately whether or not it could allocate the memory block. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 45 / 70
    • Interaction: L1 DeallocateMemoryBlock W(L1 HubIDMemID, L1 BYTE *Memory) Description: Returns a memory block to its pool. Interaction Type: PUT; Variants: L1 DeallocateMemoryBlock W(...): Returns the previously acquired memory block, to which Memory points, to the memory pool. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 46 / 70
    • What are Host Service Components?Host Service Components allow embedded Nodes to access the screen andfile system of a so called legacy Node (win32 or Linux). Presently thefollowing Host Service Components come together with theOpenComRTOS Suite: StdioHostService GraphicalHostServiceAll interactions with a Host Service Component use waiting semantics! Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 47 / 70
    • Stdio Host ServiceThe Stdio Host Service (SHS) provides currently these functionalities: General console access, i.e. printing a string, reading input from the keyboard. General file access, i.e. creating a file, reading from and writing to a file. Trace Host Service, i.e. writing the content of the trace buffer into a file. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 48 / 70
    • Stdio Host Service Demonstration Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 49 / 70
    • Graphcial Host Service 2D-Drawing operations: rectangle, circle, line, . . . ; Canvas Control: acquire the size of the canvas, resize the canvas; Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 50 / 70
    • Graphical Host Service Demonstration Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 51 / 70
    • Outline1 OpenComRTOS Designer Suite2 OpenComRTOS System Composition Tasks The OpencomRTOS “HUB” Host Service Components3 Designing Distributed Heterogeneous Systems using the OpenComRTOS-Suite How Micro Controllers handle Interrupts Presenting the Measurement Results Requirements Specifying the System Implementation Application Collected Measurement Results4 Summary
    • What are Interrupt Requests (IRQ) A signal from a hardware device that it requires the attention of the Central Processing Unit (CPU), for instance: the user pressed a button, the Universal Asynchronous Receiver/Transmitter (UART) RX-buffer is full, the UART TX-buffer is empty, a timer has expired, ... IRQs interrupt the current program flow and force the CPU to execute the corresponding Interrupt Service Routine (ISR). Interrupts are usually disabled when modifying data structures, which an ISR might modify as well. IRQs occuring while interrupts are disabled get processed at a later point in time. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 53 / 70
    • Interrupt Handling on a Standard Micro Controller Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 54 / 70
    • Presenting the Measurement Results The interrupt latencies depend on what was happening on the CPU at the time the Interrupt Request (IRQ) was generated. Thus there is not a single figure, but a range of latencies and how often they occurred, i.e a histogram. Measurement results must be presented on a decent display. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 55 / 70
    • Requirements R1: Measurement application running on an ARM-Cortex-M3 micro controller, which is able to measure the following: IRQ to ISR Latency, IRQ to Task Latency. R2: GUI Application for statistical analysis and histogram display. R3: Communication between the micro controller and the GUI Application. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 56 / 70
    • S1 the specification for R1 An OpenComRTOS ARM-Cortex-M3 node: ArmNode. Automatic Reload Counter to be used as IRQ Source. Automatic Reload Counter ISR to be modified to do the following: 3 Store the value of the Automatic Reload Counter in a global Variable once it has been started. This is the IRQ to ISR Latency. Signal an OpenComRTOS Event using ‘ NW’ semantics. A high priority task to represent the ISR task, which does the following: Waits for an OpenComRTOS Event to become signalled and then acquires the current value of the Automatic Reload Counter in a local variable, this is then the IRQ to Task Latency. Stores the previously measured IRQ to ISR Latency in a local variable. Send the collected latencies to an OpenComRTOS Port using ‘ W’ semantics (Communicating Sequential Processes (CSP)-Channel). The CPU executes a Semaphore Loop to ensure that it performs constant context switching. 3 Global variables are to be avoided normally, but sometimes there is nochoice. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 57 / 70
    • S2: the Specification for R2 An application that displays a histogram for each of the measured latencies, later on referred to as ‘Latency-GUI’. The Latency-GUI performs the following statistical analysis, for each of the latencies: Minimal Latency Maximal Latency 50% Latency The Latency-GUI application is a normal MS-Windows program written in C++ using QT. Measurements get send to the Application using a local TCP-IP connection. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 58 / 70
    • Interrupt Latency GUI Application Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 59 / 70
    • S3: the Specification for R3 An OpenComRTOS Win32 Node: Win32Node. This node connects with the ArmNode using a TCP-IP link. The Win32Node contains a port which is used to exchange data between Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 60 / 70
    • Interrupt Latency Measurement System Topology Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 61 / 70
    • Application Diagram Entities Entities related to taking and processing the measurement: Automatic Reload Counter ISR ISR Event Collector Task Data Port Receiver Task Entities of the CPU loading Semaphore Loop: SemaTask1 SemaTask2 Sema2 Sema1 Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 62 / 70
    • Interrupt Latency Measurement System ApplicationDiagram Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 63 / 70
    • Measured IRQ to ISR Latency on ARM Cortex M350MHz (logarithmic scale)
    • Measured IRQ to Task Latency on ARM Cortex M350MHz (logarithmic scale)
    • Outline1 OpenComRTOS Designer Suite2 OpenComRTOS System Composition Tasks The OpencomRTOS “HUB” Host Service Components3 Designing Distributed Heterogeneous Systems using the OpenComRTOS-Suite How Micro Controllers handle Interrupts Presenting the Measurement Results Requirements Specifying the System Implementation Application Collected Measurement Results4 Summary
    • SummaryThis Lecture covered the following: Introduction to the OpenComRTOS Designer Suite; OpenComRTOS system elements, including: Tasks, Hubs and all the synchronisation primitives they provide, Host Services. Design of a Distributed Heterogeneous System with OpenComRTOS. Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 67 / 70
    • Questions?Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 68 / 70
    • Thank Youfor Your attentionhttp://www.altreonic.com
    • References Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 70 / 70