Extension of the FreeOSEK RTOS
for Asymmetric Multiprocessor Systems
Pablo O. Ridolfi
Department of Electronics Engineering, Facultad Regional Buenos Aires, Universidad Tecnológica Nacional
Av. Medrano 951 (C1179AAQ), Ciudad de Buenos Aires, Argentina
pridolfi@frba.utn.edu.ar
Abstract—This paper presents a Real-Time Operating
System (RTOS) implementation. This RTOS is based on
the OSEK-OS 2.2.3 standard, which will be extended to
support an Asymmetric Multiprocessor System (AMP). The
term asymmetric means that the microprocessors included in
the system have heterogeneous architectures (a subgroup of
identical processors may exist but not the whole amount of
them are identical) and each processor executes an instance
of the RTOS specifically designed and optimised. Also, a
description of the development process that took place to
communicate each RTOS instance, taking advantage of
hardware features in order to exchange information between
processors, is provided. Finally, a functional test application
is presented: Processors monitor each other using RTOS
resources as keep-alive events while sharing information about
GPIO activity and reporting changes and system status using
serial communication. In addition, an energy consumption
analysis is performed for this test case. The hardware platform
used in this development is the Argentine Open Industrial
Computer (Computadora Industrial Abierta Argentina,
CIAA) based on the LPC4337 dual-core AMP microcontroller,
which includes an ARM Cortex-M4 (ARMv7E-M architecture)
acting as the master microprocessor and an ARM Cortex-M0
(ARMv6-M architecture), as the slave coprocessor.
Resumen—En este trabajo se presenta la implementación
de un Sistema Operativo de Tiempo Real (RTOS, por sus
siglas en inglés) basado en el estándar OSEK-OS 2.2.3
que es extendido para soportar un sistema multiprocesador
asimétrico (Asymmetric Multiprocessor System, AMP). El
término asimétrico se refiere a que los microprocesadores
que componen el sistema son de arquitecturas heterogéneas
(pudiendo existir un subconjunto de procesadores idénticos
pero no la totalidad de los mismos) y cada uno de ellos
ejecuta una instancia del RTOS especı́ficamente diseñada
y optimizada. Se describe además el proceso de desarrollo
llevado a cabo para comunicar las instancias aprovechando
caracterı́sticas de hardware para intercambiar información
entre procesadores. Finalmente se expone una aplicación de
prueba funcional: el monitoreo mutuo entre CPUs (keep-alive)
mientras se intercambia información sobre entradas/salidas
y se reporta el estado del sistema mediante comunicación
serie. También se realizará un análisis de consumo de
energı́a para esta aplicación. La plataforma utilizada para
la evaluación de dichos casos es la Computadora Industrial
Abierta Argentina (CIAA) cuyos modelos basados en el
microcontrolador LPC4337 disponen de un multiprocesador
asimétrico compuesto por un microprocesador ARM Cortex-
M4 (arquitectura ARMv7E-M) y un coprocesador ARM
Cortex-M0 (ARMv6-M).
Index Terms—Real-Time Operating Systems, OSEK Stan-
dard, Asymmetric Multiprocessor System, ARM Architecture
I. I NTRODUCTION
The use of Real-Time Operating Systems (RTOS) has
been increasing over the last few years, mainly in the so
called deeply embedded systems [1], that is, those electronic
systems with limited memory and processing capabilities,
strongly oriented to specific applications. This has to do
with the fact that nowadays microcontroller units (microcon-
trollers or MCUs) have more and better hardware resources,
making them able to execute more complex software [2].
Today, we can choose between a vast universe of MCUs with
some megabytes of program memory, hundreds of kilobytes
of data memory, Direct Memory Access, wireless connec-
tivity, fast Analog-to-Digital Conversion and other novel
peripherals that until the last decade were only available
in high performance systems.
Since 2011, and following this technological break-
through, multiple core microcontrollers have been launched
to market [3]. The NXP LPC4300 family is one of these
cases, including an ARM Cortex-M4 microprocessor as
master core and one or two ARM Cortex-M0 microproces-
sor(s) as slave core(s), depending on the part number.
It is interesting to point out that after five years having
this type of systems available, there haven’t been open-
source implementations of a RTOS supporting asymmetric
multicore microcontrollers so far. This situation narrows the
field of applications that the embedded systems engineer
can face, unless he designs his own real-time software or
bare-metal application, having to deal with communication
and data exchange between execution threads running in
different processors.
The context described above constituted the main mo-
tivation to work in an open-source Real Time Operating
System for an Asymmetric MultiProcessor (AMP). Once
the decision to work on this implementation was made, two
issues arose:
• the hardware platform to consider, and
• the RTOS to be adapted.
Both considerations were covered by the CIAA Project
(Argentine Open Industrial Computer, Computadora Indus-
trial Abierta Argentina): a local open-source hardware and
software initiative driven by engineers and professors from
several universities and companies around the country. The
main objective of this project is to incorporate added value to
the electronics industry in Argentina, providing design and
implementation resources that are free to use for everyone.
As discussed in the following sections, this project in-
cludes the design of an industrial computer based on the
LPC4337 dual-core microcontroller and a real-time oper-
ating system based on the OSEK-VDX standard, widely
adopted in the European automotive industry. Thus, it was
decided to take this hardware and extend the OSEK imple-
mentation that is part of its firmware in order to support
both processors available on the system.
Formal Requirements
The following items describe each technical requirement
that the implementation should cover:
1) CIAA-Firmware1 should be ported to the Cortex-M0
processor (the existing implementation runs only on
the Cortex-M4 core). OSEK-OS conformance tests
should pass without errors.
2) The existing Cortex-M4 port should have new soft-
ware functionality in order to enable Cortex-M0 to
execute its firmware.
3) Both firmware instances should be compiled automat-
ically.
4) OSEK-OS API ActivateTask available in both
firmware instances should be able to activate tasks
from one core to the other and vice-versa.
5) OSEK-OS API SetEvent available in both firmware
instances should be able to activate events from one
core to the other and vice-versa.
6) Firmware running on the Cortex-M4 core should
be able to stop its execution, allowing low energy
consumption profiles, without affecting the instance
running on Cortex-M0.
II. C ASE S TUDIES
In this section, the key components for an OSEK-OS
multicore extension will be analyzed: in the first place, the
standard single-core OSEK-OS is described; then the archi-
tecture and main features of the LPC4337 microcontroller
will be exposed.
A. OSEK-OS Operating System
OSEK (Offene Systeme und deren Schnittstellen fur die
Elektronik in Kraftfahrzeugen, “Open Systems and their In-
terfaces for the Electronics in Motor Vehicles”) is a standard-
ization committee formed by European automotive industry
companies in 1994 and subsequently integrated within the
VDX standard in 2005, formally called OSEK-VDX at the
time. Its set of standards was designed to unify the software
architecture of the Engine Control Units (ECUs) present in
automobiles. All the specifications included in the OSEK-
VDX standards have been distributed since 2009 under a
free-to-use license [4]. The specifications covered by this
work (and by CIAA-Firmware) are the following:
• OSEK-OS: Application Program Interface (API) and
structure specification for a priority-based operating
system.
• OSEK Implementation Language (OIL): Specifica-
tion for the configuration language used by OSEK-OS
as part of OSEK-VDX.
1 CIAA-Firmware refers to the embedded software that runs on the
LPC4337 microcontroller.
Static Operating System: OSEK-OS is a static operating
system. Being static implies that the resources required
by the user application are not dynamically created during
program execution. Instead, these resources are defined in
a process performed before compilation, called generation.
A static operating system does not use dynamic memory
allocation functions like malloc and free [5].
This way of defining static resources is justified by the
fact that an embedded system using OSEK-OS has a specific
purpose: it is known beforehand which processes will be
running and how many resources they need, i.e. no new
processes are created at runtime. Thus, some execution
contexts may be in a suspended state, waiting to be activated,
but their resources (like their stack space) will be statically
allocated in memory anyway. If a process is redesigned
using a new resource, the whole firmware will be generated,
compiled and linked.
A major advantage of a static system is its determinism, a
feature strongly related with its real-time response. On the
other hand, a static system will never suffer from lack of
memory or heap fragmentation. In addition, all tasks have
ensured their stack space, so there is no possibility that a
thread cannot be activated because of insufficient memory.
If the hardware resources are not enough, the developer
will face errors at compilation time, never during runtime.
Moreover, the priorities of the tasks are also static: the
priority of a OSEK-OS task cannot be changed in execution
time.
OSEK-OS Tasks: User application tasks can have only
four possible states (Fig. 1). When the operating system
starts, all tasks are in the Suspended state, waiting to
be activated. Task activation can be achieved: using the
system call ActivateTask, setting an Alarm, or setting
the parameter AUTOSTART=TRUE in the OIL configuration
file. Table I describes all possible transitions between states.
Normally, a single task will be in Running state because
there is only one core in most microcontrollers. But in this
case there will be up to two tasks running because of the
number of cores actually available in the LPC4337.
OSEK-OS work scheme: The development process for an
OSEK-OS application is shown in Figure 2. There are two
types of source code files for OSEK-OS:
• Fixed source files are standard C (.c and .h) files,
part of the OSEK-OS implementation.
• Buildable files are processed during generation using
the OIL configuration files. The generator output con-
sists of C language source and header files. In this
implementation, PHP is used for generation.
At least one .oil configuration file has to be defined
within the application. This file describes:
• Operating System general attributes (i.e., startup acti-
vated tasks, error callbacks, multicore support, among
others).
• Resources, Events, Tasks, Alarms and IRQ definitions.
• Stack size, priority and events used for each task.
FreeOSEK and CIAA-Firmware: CIAA-Firmware is the
embedded software running on the CIAA CPU. It consists
of several software modules (Fig. 3):
• FreeOSEK: An open-source RTOS based on the OSEK-
OS standard [6].
 TABLE I
S TATES AND TRANSITIONS FOR OSEK-OS TASKS . OSEK-OS
Configuration
buildable
file(s)
Transition Previous Next Description code
.oil
Activate SUSPENDED READY A new task becomes .c.php .h.php
Ready because of
a system call like OSEK-OS
ActivateTask. Generator fixed code
OSEK-OS ensures that .c .h
this task will begin
User
its execution from its OSEK-OS program
entry-point (its first generated .c .h
instruction). code
Start READY RUNNING A Ready task is selected .c .h
by the scheduler based CIAA-Firmware
on their priority in order static libraries
to begin (or resume) its
execution. Compiler
Wait RUNNING WAITING A Running task will en-
ter Waiting state after
calling the system call
Linker
WaitEvent. scripts Linker
Release WAITING READY At least one of the events .ld
expected by the task is
set.
Preempt RUNNING READY The scheduler decides to
Executable
run another task. Current
task will become Ready
and eventually will re-
sume its execution at Fig. 2. Code generation and compilation scheme for OSEK-OS based
the point where it was firmware.
stopped.
Terminate RUNNING SUSPENDED The task executes a sys-
tem call which places User application
it in Suspended state. It
should be activated again
in order to restart its ex- OSEK-like RTOS POSIX-like drivers
ecution.

Vendor/3rd party drivers

Hardware

Fig. 3. CIAA-Firmware architecture

In a similar way, choosing the POSIX standard for pe-

ripheral management unifies all initialization, control and
input/output functions to five standard system calls: open,
read, write, close and ioctl. Using this interface al-
lows developers using CIAA-Firmware to port new hardware
and microcontrollers, providing an abstraction layer for the
user application.

Fig. 1. State chart for OSEK-OS tasks.

• Hardware Abstraction Layer (HAL) and peripheral
drivers based on the POSIX standard [7].
• User application: Source code of tasks and OIL con-
figuration file(s).
• Third-party or vendor drivers provided by the micro-
controller manufacturer.
There are two main reasons for choosing an OSEK-like
RTOS: determinism is obligatory in all industrial environ-
ments, thus a static operating system fulfills this require-
ment. On the other hand, since it is an open standard, users
can opt for other implementations of OSEK-OS instead of
FreeOSEK without changing application code and configu-
ration. To learn more about FreeOSEK see [8].
B. LPC4337 dual-core microcontroller
The LPC4337JBD144 dual-core microcontroller is
present in the two most used CIAA boards: CIAA-NXP and
EDU-CIAA-NXP (Fig. 4). This MCU provides a Cortex-
M4F master processor and a Cortex-M0 slave processor. Its
technical characteristics will be outlined in this section.
Cortex-M4 master processor: Cortex-M4 belongs to the
ARMv7E-M family of microprocessors, launched to market
in 2006 [9]. Its main features are:
• 32-bits RISC architecture with a three-stage pipeline.
• AMBA: Advanced Microcontroller Bus Architecture.
• NVIC: Nested and Vectored Interrupt Controller.
• Privileged (system) and User privilege levels.
• Eight-region Memory Protection Unit.
• Thumb-2 Instruction Set Architecture.
• SysTick periodic interrupt timer.

Fig. 4. CIAA boards: EDU-CIAA-NXP (front) and CIAA-NXP (back).
Cortex-M0 slave coprocessor: The Cortex-M0 is part of
the ARMv6-M family of ARM microprocessors. Compared
to the Cortex-M4, M0 has a reduced instruction set. One of
its main features is its low gate count: approximately 12000
gates2 in minimum configuration [10]. It has a AHB-Lite
Von-Neumann bus architecture, but it is still a 32-bits RISC
processor with a 3-stage pipeline.
Inter Processor Communication (IPC): In the LPC4337
microcontroller, both processors have full access to all
memory and peripherals present in the 32-bits physical
address space. After a full system reset, only the master
core (Cortex-M4) is enabled to execute code while the slave
processor is held in the reset state. The software running
in the master core is responsible for setting the memory
address where the interrupt vector for the slave begins, and
then releasing it from the reset state.
Once both processors are running their programs, they
can exchange information using shared data memory space,
polling this space for changes, or using inter-core interrupt
requests (Fig. 5): the Cortex-M0 TXEV signal is connected
to the interrupt slot #1 in the Cortex-M4 Interrupt Controller,
and the Cortex-M4 TXEV signal is connected to the inter-
rupt slot #1 in the Cortex-M0 interrupt controller. In both
cores the TXEV signal is triggered using the SendEVent
instruction (SEV).
III. I MPLEMENTATION
This section describes the steps that were followed and
the milestones that were achieved according to the planned
schedule, as described in section I. Throughout the text, links
to the source code repository will be provided.
A. CIAA-Firmware port for Cortex-M0
The Cortex-M0 port consists of:
• third-party libraries (LPCOpen),
• the FreeOSEK kernel, and
• POSIX drivers.
These software modules were originally available only for
Cortex-M4.
2 The silicon area occupied by the Cortex-M0 processor is equivalent to
12000 2-input NAND gates.
Cortex-M4 Cortex-M0APP
CREG
TXEV M4TXEVENT IRQ#1
CREG
IRQ#1 TXEV
M0APPTXEVENT
Fig. 5. Inter-core interrupts for LPC4337 [11].
LPCOpen library: From the point of view of the CIAA
project, LPCOpen is a third-party open-source driver library
for NXP ARM-based microcontrollers, containing periph-
eral drivers and the CMSIS API [12].
Makefiles and linker scripts: CIAA-Firmware uses a
Makefile-based structure to define generation and compila-
tion rules for source files, static libraries and binary flash
memory images. In order to add a new target processor
(i.e., the Cortex-M0 slave core) a new set of Makefiles and
linker scripts were written and added to CIAA-Firmware3 .
The Cortex-M0 image will require the 512kB flash memory
bank B for code and data initialization, and a 16kB AHB
SRAM block for data.
POSIX device drivers: In order to perform the testing
applications for the multicore implementation (see section
IV), the Digital Input/Output driver (Dio) was ported to
Cortex-M04 .
FreeOSEK: The Cortex-M0 port of the FreeOSEK kernel
takes the Cortex-M4 port as a basis since both processors
have a similar programming model (mainly its register file
and interrupt behavior). The main issues to deal with are
outlined as follows:
1) The interrupt vector is significantly different from
Cortex-M4 in terms of order and quantity of peripheral
IRQ entries. In addition, some system exceptions do
not exist in Cortex-M0 so the OSEK generator was
improved5 .
2) The SysTick timer is not available in the Cortex-
M0 processor so the Repetitive Interrupt Timer (RIT)
available in the LPC4337 will be used in the OSEK
instance running on the M0 core. In this case, the
vector entry corresponding to the RIT timer is fixed
and cannot be defined in the OIL configuration6 .
3) The Cortex-M0 instruction set is significantly reduced
in comparison to the one available in Cortex-M4.
While Cortex-M4 supports both Thumb and Thumb-
2 instruction sets, Cortex-M0 executes only Thumb
instructions. This issue impacts on the design of the
context saving and restore routines. They have to be
redesigned using Thumb instructions only7 .
After these issues were solved, a fully functional OSEK
kernel became available for the Cortex-M0 core, also com-
pliant with the OSEK-OS Conformance Tests, as described
in the following paragraph.
3 CIAA-Firmware commit 60378ec.
4 CIAA-Firmware commit 42f857b.
5 CIAA-Firmware RTOS repository, Os_Internal_Arch_Cfg.c.php:178.
6 CIAA-Firmware RTOS repository, Os_Internal_Arch_Cfg.c.php:211
and StartOs_Arch_SysTick.c:69.
7 Context switch routine for Cortex-M0: See PendSV.s source file.
 OSEK-OS Conformance Tests: OSEK-OS standard Con-
formance Tests [13] are managed by a Perl script8 in
CIAA-Firmware. Also, a sequence of GDB commands were
introduced in order to add support for Cortex-M09 .
Dynamic Memory Allocator: Unlike Cortex-M4, Cortex-
M0 does not support unaligned memory access. Thus, the
addresses issued by this processor shall be multiples of four
bytes. Current implementation of the CIAA-Firmware Dy-
namic Memory Allocator10 performed unaligned accesses.
The memory allocator source code was corrected in order
to perform aligned memory accesses when compiled for
Cortex-M011 .
B. Multicore module
Once both instances of the OSEK operating system were
running on each core, intercommunication resources had to
be defined. On the one hand, as described in section II-B,
inter-core interrupt requests are available in the LPC4337
microcontroller. In addition, both cores are able to access
all RAM memory in the system.
The first step in the design of the intercommunication
module (called “multicore module” in CIAA-Firmware)
consisted of the implementation of a circular buffer
ciaaLibs_CircBufType12 in an unused RAM memory
location visible by both Cortex-M4 and Cortex-M0 proces-
sors.
Then, a message structure was defined13 , containing in-
formation about the sender of the current message and the
type of command requested to the receiver by the sender.
Currently, these commands are available to both cores:
• CIAA_MULTICORE_CMD_ACTIVATETASK for re-
mote OSEK task activation.
• CIAA_MULTICORE_CMD_SETEVENT for remote
OSEK event handling.
Figure 6 shows a block diagram with the previously
described resources.
TXEV IRQ1
ciaaLibs
Master CPU CircBufType Slave CPU
Cortex-M4 @0x20008000 Cortex-M0
(RAM AHB 16kB)
IRQ1 TXEV
Fig. 6. Resources scheme used by the multicore module.
8 CIAA-Firmware OSEK Conformance Test main script: ctest.pl.
9 CIAA-Firmware commit 6bd509d.
10 Note: The OSEK RTOS used in CIAA-Firmware does not need
dynamic memory allocation because it is a static operating system. Only
the POSIX driver stack depends on this functionality.
11 CIAA-Firmware commit d75abf5.
12 CIAA-Firmware circular buffer definition: ciaaLibs_CircBuf.h.
13 CIAA-Firmware message structure: ciaaMulticore_ipcCmd_t.
C. Multicore API
The Application Program Interface (API) of the multicore
module is currently available only for the OSEK operating
system. Thus, it is not accessible from user application level.
The multicore API is implemented in the following source
files:
• ciaaMulticore.c: external or public architecture
independent functions.
• ciaaMulticore_Arch.c: internal functions for
Cortex-M4.
• ciaaMulticore_Arch.c: internal functions for
Cortex-M0 (same file name with different path).
External functions:
• ciaaMulticore_init initializes hardware and
software resources needed by the multicore module.
Actually this initialization is performed differently in
each core, as described in the following section.
• ciaaMulticore_sendMessage adds a new mes-
sage to the shared circular queue, then sends a notifi-
cation to the remote core using the interrupt request.
• ciaaMulticore_recvMessage retrieves a mes-
sage from the shared queue.
• ciaaMulticore_dispatch_OSEK_API parses
the message fields and calls the appropriate OSEK
API (ActivateTask or SetEvent).
Internal functions:
• ciaaMulticore_init_Arch (Cortex-M4 core)
initializes the shared message queue and enables the
IRQ line from Cortex-M0. Then, it releases Cortex-
M0 from reset in order to start executing the second
OSEK instance.
• ciaaMulticore_init_Arch (Cortex-M0 core)
enables the IRQ line from Cortex-M4 (the other shared
resources had been initialized in the Cortex-M4 in-
stance).
• ciaaMulticore_sendSignal_Arch is code-
equivalent in both processors. It executes a Data
Synchronization Barrier (DSB) instruction in order to
complete all pending memory accesses, then sends an
interrupt request to the other processor using the Send
Event (SEV) instruction, as described in section II-B.
• ISR(M0_IRQHandler) (for Cortex-M4 core) and
ISR(M4_IRQHandler) (for Cortex-M0 core) are
the inter-core interrupt handlers. Each one acknowl-
edges the request and retrieves a message from the
shared queue prior to calling the dispatch internal
function.
D. OSEK-OS generator improvement
FreeOSEK PHP generator was modified in order to rec-
ognize new OIL configuration parameters:
• MULTICORE = TRUE has to be defined in the global
operating system configuration parameters.
• CORE = 0 (master) or CORE = 1 (slave) has to be
defined in each Task, Alarm, Counter and ISR within
the OIL configuration file in order to be generated in
the corresponding OSEK instance14 .
14 Multicore OIL file example: blinking_multicore.oil.
E. OSEK-OS API extension
FreeOSEK API functions improved in this work are
described in this section. In every case, the new functionality
is executed only if the parameter MULTICORE = TRUE is
defined in the OIL configuration file.
• StartOS: besides OS initialization, now this function
calls ciaaMulticore_init (see section III-C)15 .
• ActivateTask now detects if the TaskID param-
eter refers to a remote task. In this case, this function
defines a ciaaMulticore_ipcMsg_t message and
sends it through the multicore module (see section
III-C)16 .
• SetEvent works in a similar way to
ActivateTask, detecting if the task ID refers
to a remote task. In such case, the event is set in the
remote OSEK instance17 .
IV. F UNCTIONAL TESTS
A. Inter-core monitoring application
• Improvements on shared memory structures for both
OSEK instances, such as definitions of tasks, alarms
and events that are currently located in both memory
images.
• Definition of message queues for each core. In this
implementation there is only one message queue shared
by both cores.
• Unification of the OSEK kernel, i.e., the master pro-
cessor will be able to select the task to be executed
by the slave. Currently, this behavior can be achieved
indirectly using the ActivateTask function.
• Although OSEK-OS is a static operating system (as
stated in section II-A), the POSIX device driver stack
used in CIAA-Firmware requires dynamically allocated
resources. This situation must be improved in order to
define POSIX resources statically, improving stability
and determinism of the user application.
TABLE II
T EST CASES AND RESULTS FOR ENERGY CONSUMPTION ANALYSIS .

The monitor OSEK-OS user level application18 is Test Description CPU Current
described in this section. It makes extensive use of the Case clock sink
multicore module of CIAA-Firmware: it consists of a set of [MHz] [mA]
A0 monitor application as described in 204 228.4
tasks defined on each core that will exchange information section IV-A.
through inter-core task activation and event setting. A1 Same as A0. 102 127.6
Behavior: The slave processor will poll the GPIO pe- A2 Same as A0. 51 69.8
ripheral. Should any GPIO state change, a remote task B0 All tasks running on master proces- 204 214.1
sor. Slave processor is hold in reset.
located in the master core will be activated in order to report B1 Same as B0. 102 118.7
this change using the UART connected to a USB interface B2 Same as B0. 51 68.7
in the board. At the same time, both processors will set C0 All tasks running on slave proces- 204 208.4
remote events periodically in order to implement a keep- sor. Master processor is in deep-sleep
mode.
alive functionality: if a processor does not receive the event C1 Same as C0. 102 114.3
from its remote counterpart and a certain timeout expires, C2 Same as C0. 51 66.5
an alarm condition will be raised on the system and the user
will be appropriately notified.
ACKNOWLEDGMENT
B. Energy consumption analysis The author would like to thank Alejandro Furfaro, Mar-
Different execution profiles were introduced in the iano Cerdeiro and Ariel Lutenberg for their support during
monitor application in order to measure the average the development of this OSEK-OS extension. Without their
current drawn by the microcontroller for each profile. Test advice, this work would not have been possible.
cases and results can be observed in Table II.
R EFERENCES
V. C ONCLUSION AND FUTURE LINES OF WORK [1] Beuche, D.; Guerrouat, A.; Papajewski, H.; Schroder-Preikschat, W.;
Spinczyk, O.; Spinczyk, O., “The PURE family of object-oriented
Considering the main technical requirements introduced operating systems for deeply embedded systems, in Object-Oriented
in section I, it can be concluded that the implementation of Real-Time Distributed Computing”, 1999. (ISORC ‘99) Proceedings.
the FreeOSEK multicore extension was successful. 2nd IEEE International Symposium on , vol., no., pp.45-53, 1999.
doi: 10.1109/ISORC.1999.776349.
In addition to the monitor application, the user can [2] UBM Tech, “Embedded Market Study”, 2014.
take advantage of another multicore implementation: the [3] NXP LPC4300 family press release, 2011.
blinking_multicore application19 . This simple exam- [4] OSEK/VDX Free License Letter.
[5] ISO/IEC 9899:1999 Specification, pp. 313, sec. 7.20.3 “Memory
ple takes advantage of all the features implemented in the Management Functions”.
multicore module. [6] OSEK/VDX 2.2.3 Operating System Specification.
In order to continue this work, a summary of future lines [7] POSIX.1-2008 Specification.
[8] Mariano Cerdeiro, “Introducción a OSEK-OS – El Sistema Operativo
of work and improvements are described: del CIAA-Firmware”, ACSE, 2015. ISBN 978-987-45523-6-5.
• Implementation of OSEK-OS mutual exclusion locks, [9] Joseph Yiu, “The Definitive Guide to ARM R Cortex -M3
R and
Cortex -M4
R Processors”, Newnes, 2013.
called Resources [14]. [10] Joseph Yiu, “The Definitive Guide to ARM R Cortex -M0
R and
Cortex -M0+
R Processors”, Newnes, 2015, pp. 89, sec. 4.1.2.
15 See StartOS.c:91. [11] LPC43xx User Manual, pp. 28, sec. 2.2.
16 See ActivateTask.c:92. [12] Joseph Yiu, “The Definitive Guide to ARM R Cortex -M3
R and
17 See SetEvent.c:93. Cortex -M4
R Processors”, 3rd Ed., Newnes, 2014, pp. 46, sec. 2.9.
18 See monitor source code repository. [13] OSEK/VDX 2.2.3 Operating System Specification, pp. 13, sec. 3.2.
19 CIAA-Firmware: blinking_multicore example. [14] OSEK/VDX 2.2.3 Operating System Specification, pp. 29, sec. 8.