Open ComRTOS 1.4_tutorial_2o4_presentation

Session #1.2: Introduction to OpenComRTOS and theOpenComRTOS Designer Suite

Bernhard [email protected]

Altreonic NVGemeentestraat 61 Bus 1

3210 LindenBelgium

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 theOpenComRTOS Designer Suite

Session #1.3: OpenComRTOS Internals

Session #1.4: Hands on with the OpenComRTOS Designer Suite


1 OpenComRTOS Designer Suite

2 OpenComRTOS System CompositionTasksThe OpencomRTOS “HUB”Host Service Components

3 Designing Distributed Heterogeneous Systems using theOpenComRTOS-Suite

How Micro Controllers handle InterruptsPresenting the Measurement ResultsRequirementsSpecifying the SystemImplementationApplicationCollected Measurement Results

4 Summary


Demonstration of OpenComRTOS in Action


Outline





4 Summary

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


OpenComRTOS

Communicating Sequential Processes (CSP) inspired distributedRTOS

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 foranalysis using OpenTracer.

Distributed Priority Inheritance.


Available Ports of OpenComRTOS

Active Ports:I ARM Cortex M3I NXP CoolFluxI Posix32I Win32I XMOS XS-1 (L-Series)

Dormant Ports1

I Leon3I Melexis MLX-16I Xlinix Microblaze

1Present 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 4854L1 Port 4 8 8 4 4L1 Event 70 88 72 36 54L1 Semaphore 54 92 96 40 64L1 Resource 104 96 76 40 50L1 FIFO 232 356 332 140 222L1 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 fourcontext switches.


Context-Switch Figures 2

Clock Speed Context Size Memory Lo-cation

Loop Time

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

2measured using the Target NXP-CoolFlux SimulatorBernhard 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 thetopology.

Integrated code-generators create all the OpenComRTOSconfiguration code and the necessary build system.


Graphical modelling of the system-topology


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


OpenTracer

Visualises previously recorded trace-files, which contain the followinginformation:

I Task Scheduling;I Interactions with synchronisation primitives;I Internode communication;I User generated markers.

Time measurements, and thus verifying that critical timings are metby the system.

Link tracefiles 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 modification 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.


Outline





4 Summary

OpenComRTOS System Composition

A complete OpenComRTOS system always consists of two things:

Topology

Application


Topology

Nodes

Link Ports

Links


Application Entities

Tasks

Hubs

Host Service Components

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


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.


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 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 notready for the interaction, the interaction returns immediately with theerror 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 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 contextinformation, private to the Task.

Priority: An integer value in the range 0–255, which determines thepriority of this Task. Lower values mean higher priority.

ReqeustPacket: Using this RequestPacket the task interacts with itsenvironment. A RequestPacket is of type L1 Packet and consists of:

I Header-Part: Contains desitationPortID, priority, data size, andrequest-type information.

I Data-Part: This is used to transport data from one Task to anotherwhen using either Port or FIFO Hub-Implementations.


The OpencomRTOS “HUB”

Result of formal modelling;

Resources, Events, Semaphores, Ports, FIFOs, etc. are all variants ofa generic HUB.

A HUB consists of four functional parts:I Synchronisation point between Tasks;I Stores task’s waiting state if needed;I Predicate function: defines synchronisation conditions and lifts waiting

state of tasks;I Synchronisation function: functional behaviour after synchronisation.

All HUBs operate system-wide, but transparently: Virtual SingleProcessor programming model.

Possibility to create application specific hubs & services! =⇒ a newconcurrent programming model.

Hubs always offer two different types of interactions: Put and Get. Themeaning of these operations always depends upon the concrete Hubimplementation.


Resource

Description: A Resource is a Hub used to represent mutual exclusiveaccess to a shared resource in OpenComRTOS.

Usage: It is use to prevent that two tasks concurrently try to accessthe same resource. Thus it is used similar to Mutexes or (Spin)Locksavailable in other operating systems.


Interaction: L1 LockResource()

Description: This interaction tries to lock the resource. Thisoperation will only succeed when the resource is free.

Interaction Type: GET;

Variants:I L1 LockResource W(L1 HubID r): This interaction waits until

the resource r could be locked.I L1 LockResource WT(L1 HubID r, L1 Timeout t): This

interaction waits until the resource r could be locked or the timeout texpired.

I L1 LockResource NW(L1 HubID r): This interaction tries to lockthe resource r but returns immediately independent of whether or notit was able to do so.


Interaction: L1 UnlockResource()

Description: Unlocks a resource previously locked by the Task.

Interaction Type: PUT;

Variants:I L1 UnlockResource W(L1 HubID r): Releases the resource and

returns immediately.I L1 UnlockResource WT(L1 HubID r, L1 Timeout t):

Releases the resource and returns immediately.I L1 UnlockResource NW(L1 HubID r): Releases the resource

and returns immediately.


Event

Description: An event is used to synchronize two tasks, where TaskT0 waits for Event E raised by Task T1.

Usage: Events are for instance used inside OpenComRTOS to signalthe occurrence of an Interrupt Request from an Interrupt ServiceRoutine to another Task.


Interaction: L1 RaiseEvent

Description: This signals the occurrence of an event.


Variants:I 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 canbe signalled.

I L1 RaiseEvent WT(L1 HubID e, L1 Timeout t): If theEvent e is not signalled it will raise it and return. Otherwise, the Taskwaits, until the Event can be signalled, or its timeout expires.

I 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:I L1 TestEvent W(L1 HubID e): This interaction waits until Evente has been signaled.

I L1 TestEvent WT(L1 HubID e, L1 Timeout t): Thisinteraction waits until Event e has been signaled, or the timeout texpired.

I L1 TestEvent NW(L1 HubID e): This interaction tries to testEvent e but returns immediately independent of whether or not theEvent e was signalled.


Semaphore

Description: A Semaphore is used to synchronize two tasks, whereTask T0 waits for Semaphore S signalled by Task T1.

Usage: A Semaphore is always when one wants to decouple tasks andwants to prevent that synchronization events get lost.


Interaction: L1 SignalSemaphore

Description: Signals a Semaphore


Variants:I L1 SignalSemaphore W(L1 HubID s): Signals Semaphore s and

returns immediately.I L1 SignalSemaphore WT(L1 HubID s, L1 Timeout t):

Signals Semaphore s and returns immediately.I 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:I L1 TestSemaphore W(L1 HubID s): This interaction waits until

Semaphore s has been signaled.I L1 TestSemaphore WT(L1 HubID s, L1 Timeout t): This

interaction waits until Semaphore s has been signaled, or the timeoutt expired.

I L1 TestSemaphore NW(L1 HubID s): This interaction tries totest Semaphore s but returns immediately independent of whether ornot s was signalled.


Port

Description: The Port is used for a synchronized exchange of databetween Tasks. The data exchange uses the data field of the TasksRequestPackets.

Usage: Whenever data needs to be exchanged between two Tasks.The Host Services provided with OpenComRTOS heavily rely uponPorts 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!


Interaction: L1 PutPacketToPort

Description: This interaction sends data to a Port from where it canbe retrieved by another Task.


Variants:I L1 PutPacketToPort W(L1 HubID p): Sends the Tasks

RequestPacket to Port p and returns once the data exchange has takenplace.

I L1 PutPacketToPort WT(L1 HubID p, L1 Timeout t):Sends the Tasks RequestPacket to Port p and returns once the dataexchange has taken place, or the timeout t has expired.

I L1 PutPacketToPort NW(L1 HubID p): Sends the TasksRequestPacket to Port p and returns immediately, independent ofwhether or not the data exchange took place.


Interaction: L1 GetPacketFromPort

Description: This interaction receives data from a Port, whereanother Task has sent it. Upon successful return the TasksRequestPacket contains the data that the other task sent.


Variants:I L1 GetPacketFromPort W(L1 HubID p): Sends the Tasks

RequestPacket to Port p and returns once the data exchange has takenplace.

I L1 GetPacketFromPort WT(L1 HubID , L1 Timeout t):Sends the Tasks RequestPacket to Port p and returns once the dataexchange has taken place, or the timeout t has expired.

I L1 GetPacketFromPort NW(L1 HubID ): Sends the TasksRequestPacket to Port p and returns immediately, independent ofwhether or not the data exchange took place.


FIFO

Description: The FIFO can be seen as a Port with a build in buffer. Itbuffers a number of data elements and makes them available toanther task.

Usage: FIFOs are always used when one must synchronize Tasks thathave different data input characteristics.


Interaction: L1 EnqueueFifo

Description: This places the data part of the Tasks RequestPacketinto the FIFO.


Variants:I L1 EnqueueFifo W(L1 HubID f): Adds the data part of the

Tasks RequestPacket into FIFO f and returns once this operation wascompleted, i.e. there was enough free space in FIFO f.

I L1 EnqueueFifo WT(L1 HubID f, L1 Timeout t): Adds thedata part of the Tasks RequestPacket into FIFO f and returns oncethis operation was completed, i.e. there was enough free space in FIFOf, or if the timeout t expired.

I L1 EnqueueFifo NW(L1 HubID f): Tries to add the data part ofthe Tasks RequestPacket into FIFO f but returns immediately even ifthere is no enough free space in FIFO f.


Interaction: L1 DequeueFifo

Description: This operation retrieves one data part from a FIFO.


Variants:I 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.I L1 DequeueFifo WT(L1 HubID f, L1 Timeout t): Retrieves

one data part from the FIFO f. It only returns once it could retrievedata from FIFO f, or the timeout t expired.

I L1 DequeueFifo NW(L1 HubID f): Tries to retrieve one datapart from the FIFO f, but returns immediately even if there no datapart available in FIFO f.


Memory Pool

Description: Allows Tasks to dynamically acquire and release blocksof 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.


Interaction: L1 AllocateMemoryBlock W(L1 HubIDhubID, L1 BYTE **Memory, L1 UINT16 Size)

Description: This allocates a chunk of memory with the specified inSize, and places a pointer to the first element in the memory chunkin the pointer pointed to by Memory.


Variants:I L1 AllocateMemoryBlock W(...): Allocates a memory block of

the specified Size and returns the pointer in Memory. This call willwait until the memory block can be allocated.

I L1 AllocateMemoryBlock WT(...): Same asL1 AllocateMemoryBlock W(), but this call will wait until thememory block can be allocated, or the timeout t expired.

I L1 AllocateMemoryBlock NW(...): Same asL1 AllocateMemoryBlock W(), except that it returnsimmediately whether or not it could allocate the memory block.


Interaction: L1 DeallocateMemoryBlock W(L1 HubIDMemID, L1 BYTE *Memory)

Description: Returns a memory block to its pool.


Variants:I 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 andfile system of a so called legacy Node (win32 or Linux). Presently thefollowing Host Service Components come together with theOpenComRTOS 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 thekeyboard.

General file access, i.e. creating a file, reading from and writing to afile.

Trace Host Service, i.e. writing the content of the trace buffer into afile.


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


Outline





4 Summary

What are Interrupt Requests (IRQ)

A signal from a hardware device that it requires the attention of theCentral Processing Unit (CPU), for instance:

I the user pressed a button,I the Universal Asynchronous Receiver/Transmitter (UART) RX-buffer

is full,I the UART TX-buffer is empty,I a timer has expired, ...

IRQs interrupt the current program flow and force the CPU toexecute the corresponding Interrupt Service Routine (ISR).

Interrupts are usually disabled when modifying data structures, whichan ISR might modify as well.

IRQs occuring while interrupts are disabled get processed at a laterpoint in time.


Interrupt Handling on a Standard Micro Controller


Presenting the Measurement Results

The interrupt latencies depend on what was happening on the CPUat the time the Interrupt Request (IRQ) was generated.

Thus there is not a single figure, but a range of latencies and howoften 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 microcontroller, which is able to measure the following:

I IRQ to ISR Latency,I IRQ to Task Latency.

R2: GUI Application for statistical analysis and histogram display.

R3: Communication between the micro controller and the GUIApplication.


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:

I Store the value of the Automatic Reload Counter in a global Variable 3

once it has been started. This is the IRQ to ISR Latency.I Signal an OpenComRTOS Event using ‘ NW’ semantics.

A high priority task to represent the ISR task, which does thefollowing:

I Waits for an OpenComRTOS Event to become signalled and thenacquires the current value of the Automatic Reload Counter in a localvariable, this is then the IRQ to Task Latency.

I Stores the previously measured IRQ to ISR Latency in a local variable.I 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 performsconstant context switching.

3Global variables are to be avoided normally, but sometimes there is nochoice.


S2: the Specification for R2

An application that displays a histogram for each of the measuredlatencies, later on referred to as ‘Latency-GUI’.

The Latency-GUI performs the following statistical analysis, for eachof the latencies:

I Minimal LatencyI Maximal LatencyI 50% Latency

The Latency-GUI application is a normal MS-Windows programwritten in C++ using QT.

Measurements get send to the Application using a local TCP-IPconnection.


Interrupt Latency GUI Application


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 databetween


Interrupt Latency Measurement System Topology


Application Diagram Entities

Entities related to taking and processing the measurement:I Automatic Reload Counter ISRI ISR EventI Collector TaskI Data PortI Receiver Task

Entities of the CPU loading Semaphore Loop:I SemaTask1I SemaTask2I Sema2I Sema1


Interrupt Latency Measurement System ApplicationDiagram


Measured IRQ to ISR Latency on ARM Cortex M350MHz (logarithmic scale)

Measured IRQ to Task Latency on ARM Cortex M350MHz (logarithmic scale)

Outline





4 Summary

Summary

This Lecture covered the following:

Introduction to the OpenComRTOS Designer Suite;

OpenComRTOS system elements, including:I Tasks,I Hubs and all the synchronisation primitives they provide,I Host Services.

Design of a Distributed Heterogeneous System with OpenComRTOS.


Questions?


Thank Youfor Your attention

http://www.altreonic.com

http://www.altreonic.com

References


Technology

Open ComRTOS 1.4_tutorial_2o4_presentation