2024: Domino Containers - The Next Step. News from the Domino Container commu...
Open ComRTOS 1.4_tutorial_2o4_presentation
1. 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, 2012
Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 1 / 70
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.2 January 12, 2012 2 / 70
3. 1 OpenComRTOS Designer Suite
2 OpenComRTOS System Composition
Tasks
The OpencomRTOS “HUB”
Host Service Components
3 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 Results
4 Summary
Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 3 / 70
5. Outline
1 OpenComRTOS Designer Suite
2 OpenComRTOS System Composition
Tasks
The OpencomRTOS “HUB”
Host Service Components
3 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 Results
4 Summary
6. OpenComRTOS Designer Suite
The 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
7. 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
8. 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
10. 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
11. Context-Switch Figures 1
Measurement Setup:
To calculate the loop time, the time for 1000 iterations gets measured,
using the highest precision timer available. Each loop performs four
context switches.
Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 11 / 70
12. 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
13. 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
14. Graphical modelling of the system-topology
Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 14 / 70
15. Graphcial modelling of the Application that runs on top of
the topology.
Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 15 / 70
16. 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
17. OpenTracer displaying a Multi-Node Trace
Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 17 / 70
18. 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
19. 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
20. Outline
1 OpenComRTOS Designer Suite
2 OpenComRTOS System Composition
Tasks
The OpencomRTOS “HUB”
Host Service Components
3 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 Results
4 Summary
21. OpenComRTOS System Composition
A complete OpenComRTOS system always consists of two things:
Topology
Application
Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 21 / 70
22. Topology
Nodes
Link Ports
Links
Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 22 / 70
23. 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.2 January 12, 2012 23 / 70
24. Interaction Semantic W (Waiting)
The Task waits until the interaction takes place, the standard CSP
semantic. 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
25. 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 has
reached 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
26. Interaction Semantic NW (Non-Waiting)
The Task does not wait for the interaction to take place. If the Hub is not
ready for the interaction, the interaction returns immediately with the
error 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
27. Tasks
A Task represents an active entity in OpenComRTOS, i.e. it has its own
agenda. 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
28. 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. The
meaning of these operations always depends upon the concrete Hub
implementation.
Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 28 / 70
29. 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
30. 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
31. 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
32. 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
33. 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
34. 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
35. 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
36. 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
37. 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
38. 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 from
a Port will never synchronize, due to the implicit serialisation of requests
by the kernel!
Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 38 / 70
39. 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
40. 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
41. 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
42. 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
43. 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
44. 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 where
the Memory Pool is mapped to. While it can be used over the
network, this is not advisable.
Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 44 / 70
45. Interaction: L1 AllocateMemoryBlock W(L1 HubID
hubID, 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
46. Interaction: L1 DeallocateMemoryBlock W(L1 HubID
MemID, 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
47. What are Host Service Components?
Host Service Components allow embedded Nodes to access the screen and
file system of a so called legacy Node (win32 or Linux). Presently the
following Host Service Components come together with the
OpenComRTOS Suite:
StdioHostService
GraphicalHostService
All interactions with a Host Service Component use waiting semantics!
Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 47 / 70
48. Stdio Host Service
The 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
49. Stdio Host Service Demonstration
Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 49 / 70
50. 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
51. Graphical Host Service Demonstration
Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 51 / 70
52. Outline
1 OpenComRTOS Designer Suite
2 OpenComRTOS System Composition
Tasks
The OpencomRTOS “HUB”
Host Service Components
3 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 Results
4 Summary
53. 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
54. Interrupt Handling on a Standard Micro Controller
Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 54 / 70
55. 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
56. 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
57. 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 no
choice.
Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 57 / 70
58. 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
59. Interrupt Latency GUI Application
Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 59 / 70
60. 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
62. 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
63. Interrupt Latency Measurement System Application
Diagram
Bernhard Sputh (Altreonic) Session #1.2 January 12, 2012 63 / 70
64. Measured IRQ to ISR Latency on ARM Cortex M3
50MHz (logarithmic scale)
65. Measured IRQ to Task Latency on ARM Cortex M3
50MHz (logarithmic scale)
66. Outline
1 OpenComRTOS Designer Suite
2 OpenComRTOS System Composition
Tasks
The OpencomRTOS “HUB”
Host Service Components
3 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 Results
4 Summary
67. Summary
This 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