Open ComRTOS 1.4_tutorial_2o4_presentation

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

Outline of this Workshop

Session #1.1: The Theoretical foundations of OpenComRTOS.
Session #1.2: Introduction to OpenComRTOS and the
Session #1.3: OpenComRTOS Internals
Session #1.4: Hands on with the OpenComRTOS Designer Suite


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


Demonstration of OpenComRTOS in Action


Outline
1 OpenComRTOS Designer Suite
2 OpenComRTOS System Composition
Tasks
3 Designing Distributed Heterogeneous Systems using the
OpenComRTOS-Suite
How Micro Controllers handle Interrupts
Requirements
Specifying the System
Implementation
Application
Collected Measurement Results
4 Summary


The OpenComRTOS Designer Suite consists of the following parts:
OpenComRTOS
OpenVE
Open Tracer
Open System Debugger
Safe Virtual Machine for C (SVM).


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.


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.

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


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


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.


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

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
conﬁguration code and the necessary build system.


Graphical modelling of the system-topology


Graphcial modelling of the Application that runs on top of
the topology.


OpenTracer

Visualises previously recorded trace-ﬁles, 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 traceﬁles recorded by the nodes in the system.


OpenTracer displaying a Multi-Node Trace


Open System Debugger (OSD)

Allows to access the System State during runtime;
Allows to suspend and resume Tasks during runtime;
Allows modiﬁcation to the memory of Nodes in the System;


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.


OpenComRTOS System Composition

A complete OpenComRTOS system always consists of two things:
Topology
Application


Topology

Nodes
Link Ports
Links


Application Entities

Tasks
Hubs
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.


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.


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 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.


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:
The example ‘Demo NW’, provided by the OpenComRTOS Designer Suite,
illustrates graphically how non-waiting semantics work.


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.


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.

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.


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.


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.


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.


Interaction: L1 RaiseEvent

Description: This signals the occurrence of an event.
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.


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.


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.


Interaction: L1 SignalSemaphore

Description: Signals a Semaphore
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.


Interaction: L1 TestSemaphore

Description: Tests whether or not a Semaphore has been signalled.
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.


Port

Description: The Port is used for a synchronized exchange of data
between Tasks. The data exchange uses the data ﬁeld 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!


Interaction: L1 PutPacketToPort

Description: This interaction sends data to a Port from where it can
be retrieved by another Task.
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.


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.
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.


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.


Interaction: L1 EnqueueFifo

Description: This places the data part of the Tasks RequestPacket
into the FIFO.
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.


Interaction: L1 DequeueFifo

Description: This operation retrieves one data part from a FIFO.
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.


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.


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.
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.


Interaction: L1 DeallocateMemoryBlock W(L1 HubID
MemID, L1 BYTE *Memory)

Description: Returns a memory block to its pool.
Variants:
L1 DeallocateMemoryBlock W(...): Returns the previously
acquired memory block, to which Memory points, to the memory pool.


What are Host Service Components?

Host Service Components allow embedded Nodes to access the screen and
ﬁle 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!


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.


Stdio Host Service Demonstration


Graphcial Host Service

2D-Drawing operations: rectangle, circle, line, . . . ;
Canvas Control: acquire the size of the canvas, resize the canvas;


Graphical Host Service Demonstration


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.


Interrupt Handling on a Standard Micro Controller



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 ﬁgure, but a range of latencies and how
often they occurred, i.e a histogram.
Measurement results must be presented on a decent display.


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.


S1 the speciﬁcation for R1
An OpenComRTOS ARM-Cortex-M3 node: ArmNode.
Automatic Reload Counter to be used as IRQ Source.
Automatic Reload Counter ISR to be modiﬁed 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.

S2: the Speciﬁcation 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.


Interrupt Latency GUI Application


S3: the Speciﬁcation 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


Interrupt Latency Measurement System Topology


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


Interrupt Latency Measurement System Application
Diagram


Measured IRQ to ISR Latency on ARM Cortex M3
50MHz (logarithmic scale)

Measured IRQ to Task Latency on ARM Cortex M3
50MHz (logarithmic scale)

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.


Questions?


Thank You
for Your attention

http://www.altreonic.com

References


Open ComRTOS 1.4_tutorial_2o4_presentation

More Related Content

What's hot

Viewers also liked

Similar to Open ComRTOS 1.4_tutorial_2o4_presentation

Recently uploaded

Open ComRTOS 1.4_tutorial_2o4_presentation