You are on page 1of 6

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

Abstract—This paper presents a Real-Time Operating I. I NTRODUCTION

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

Vendor/3rd party drivers


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.

B. LPC4337 dual-core microcontroller
The LPC4337JBD144 dual-core microcontroller is
present in the two most used CIAA boards: CIAA-NXP and
• Hardware Abstraction Layer (HAL) and peripheral EDU-CIAA-NXP (Fig. 4). This MCU provides a Cortex-
drivers based on the POSIX standard [7]. M4F master processor and a Cortex-M0 slave processor. Its
• User application: Source code of tasks and OIL con- technical characteristics will be outlined in this section.
figuration file(s). Cortex-M4 master processor: Cortex-M4 belongs to the
• Third-party or vendor drivers provided by the micro- ARMv7E-M family of microprocessors, launched to market
controller manufacturer. in 2006 [9]. Its main features are:
There are two main reasons for choosing an OSEK-like • 32-bits RISC architecture with a three-stage pipeline.
RTOS: determinism is obligatory in all industrial environ- • AMBA: Advanced Microcontroller Bus Architecture.
ments, thus a static operating system fulfills this require- • NVIC: Nested and Vectored Interrupt Controller.
ment. On the other hand, since it is an open standard, users • Privileged (system) and User privilege levels.
can opt for other implementations of OSEK-OS instead of • Eight-region Memory Protection Unit.
FreeOSEK without changing application code and configu- • Thumb-2 Instruction Set Architecture.
ration. To learn more about FreeOSEK see [8]. • SysTick periodic interrupt timer.
Cortex-M4 Cortex-M0APP


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
Fig. 4. CIAA boards: EDU-CIAA-NXP (front) and CIAA-NXP (back).
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 .
Cortex-M0 slave coprocessor: The Cortex-M0 is part of
The Cortex-M0 image will require the 512kB flash memory
the ARMv6-M family of ARM microprocessors. Compared
bank B for code and data initialization, and a 16kB AHB
to the Cortex-M4, M0 has a reduced instruction set. One of
SRAM block for data.
its main features is its low gate count: approximately 12000
gates2 in minimum configuration [10]. It has a AHB-Lite POSIX device drivers: In order to perform the testing
Von-Neumann bus architecture, but it is still a 32-bits RISC applications for the multicore implementation (see section
processor with a 3-stage pipeline. IV), the Digital Input/Output driver (Dio) was ported to
Inter Processor Communication (IPC): In the LPC4337 Cortex-M04 .
microcontroller, both processors have full access to all FreeOSEK: The Cortex-M0 port of the FreeOSEK kernel
memory and peripherals present in the 32-bits physical takes the Cortex-M4 port as a basis since both processors
address space. After a full system reset, only the master have a similar programming model (mainly its register file
core (Cortex-M4) is enabled to execute code while the slave and interrupt behavior). The main issues to deal with are
processor is held in the reset state. The software running outlined as follows:
in the master core is responsible for setting the memory 1) The interrupt vector is significantly different from
address where the interrupt vector for the slave begins, and Cortex-M4 in terms of order and quantity of peripheral
then releasing it from the reset state. IRQ entries. In addition, some system exceptions do
Once both processors are running their programs, they not exist in Cortex-M0 so the OSEK generator was
can exchange information using shared data memory space, improved5 .
polling this space for changes, or using inter-core interrupt 2) The SysTick timer is not available in the Cortex-
requests (Fig. 5): the Cortex-M0 TXEV signal is connected M0 processor so the Repetitive Interrupt Timer (RIT)
to the interrupt slot #1 in the Cortex-M4 Interrupt Controller, available in the LPC4337 will be used in the OSEK
and the Cortex-M4 TXEV signal is connected to the inter- instance running on the M0 core. In this case, the
rupt slot #1 in the Cortex-M0 interrupt controller. In both vector entry corresponding to the RIT timer is fixed
cores the TXEV signal is triggered using the SendEVent and cannot be defined in the OIL configuration6 .
instruction (SEV). 3) The Cortex-M0 instruction set is significantly reduced
in comparison to the one available in Cortex-M4.
III. I MPLEMENTATION While Cortex-M4 supports both Thumb and Thumb-
This section describes the steps that were followed and 2 instruction sets, Cortex-M0 executes only Thumb
the milestones that were achieved according to the planned instructions. This issue impacts on the design of the
schedule, as described in section I. Throughout the text, links context saving and restore routines. They have to be
to the source code repository will be provided. redesigned using Thumb instructions only7 .
A. CIAA-Firmware port for Cortex-M0 After these issues were solved, a fully functional OSEK
The Cortex-M0 port consists of: kernel became available for the Cortex-M0 core, also com-
pliant with the OSEK-OS Conformance Tests, as described
• third-party libraries (LPCOpen),
in the following paragraph.
• the FreeOSEK kernel, and
• POSIX drivers. 3 CIAA-Firmware commit 60378ec.
These software modules were originally available only for 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
2 The silicon area occupied by the Cortex-M0 processor is equivalent to and StartOs_Arch_SysTick.c:69.
12000 2-input NAND gates. 7 Context switch routine for Cortex-M0: See PendSV.s source file.
OSEK-OS Conformance Tests: OSEK-OS standard Con- C. Multicore API
formance Tests [13] are managed by a Perl script8 in The Application Program Interface (API) of the multicore
CIAA-Firmware. Also, a sequence of GDB commands were module is currently available only for the OSEK operating
introduced in order to add support for Cortex-M09 . system. Thus, it is not accessible from user application level.
Dynamic Memory Allocator: Unlike Cortex-M4, Cortex- The multicore API is implemented in the following source
M0 does not support unaligned memory access. Thus, the files:
addresses issued by this processor shall be multiples of four • ciaaMulticore.c: external or public architecture
bytes. Current implementation of the CIAA-Firmware Dy- independent functions.
namic Memory Allocator10 performed unaligned accesses. • ciaaMulticore_Arch.c: internal functions for
The memory allocator source code was corrected in order Cortex-M4.
to perform aligned memory accesses when compiled for • ciaaMulticore_Arch.c: internal functions for
Cortex-M011 . Cortex-M0 (same file name with different path).
External functions:
B. Multicore module • ciaaMulticore_init initializes hardware and
software resources needed by the multicore module.
Once both instances of the OSEK operating system were
Actually this initialization is performed differently in
running on each core, intercommunication resources had to
each core, as described in the following section.
be defined. On the one hand, as described in section II-B,
• ciaaMulticore_sendMessage adds a new mes-
inter-core interrupt requests are available in the LPC4337
sage to the shared circular queue, then sends a notifi-
microcontroller. In addition, both cores are able to access
cation to the remote core using the interrupt request.
all RAM memory in the system.
• ciaaMulticore_recvMessage retrieves a mes-
The first step in the design of the intercommunication
sage from the shared queue.
module (called “multicore module” in CIAA-Firmware)
• ciaaMulticore_dispatch_OSEK_API parses
consisted of the implementation of a circular buffer
the message fields and calls the appropriate OSEK
ciaaLibs_CircBufType12 in an unused RAM memory
API (ActivateTask or SetEvent).
location visible by both Cortex-M4 and Cortex-M0 proces-
sors. Internal functions:
Then, a message structure was defined13 , containing in- • ciaaMulticore_init_Arch (Cortex-M4 core)

formation about the sender of the current message and the initializes the shared message queue and enables the
type of command requested to the receiver by the sender. IRQ line from Cortex-M0. Then, it releases Cortex-
Currently, these commands are available to both cores: M0 from reset in order to start executing the second
OSEK instance.
• CIAA_MULTICORE_CMD_ACTIVATETASK for re- • ciaaMulticore_init_Arch (Cortex-M0 core)
mote OSEK task activation. enables the IRQ line from Cortex-M4 (the other shared
• CIAA_MULTICORE_CMD_SETEVENT for remote resources had been initialized in the Cortex-M4 in-
OSEK event handling. stance).
Figure 6 shows a block diagram with the previously • ciaaMulticore_sendSignal_Arch is code-
described resources. 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
Master CPU CircBufType Slave CPU ISR(M4_IRQHandler) (for Cortex-M0 core) are
Cortex-M4 @0x20008000 Cortex-M0 the inter-core interrupt handlers. Each one acknowl-
(RAM AHB 16kB) edges the request and retrieves a message from the
shared queue prior to calling the dispatch internal
D. OSEK-OS generator improvement
Fig. 6. Resources scheme used by the multicore module. FreeOSEK PHP generator was modified in order to rec-
ognize new OIL configuration parameters:
• MULTICORE = TRUE has to be defined in the global
8 CIAA-Firmware OSEK Conformance Test main script: operating system configuration parameters.
9 CIAA-Firmware commit 6bd509d. • CORE = 0 (master) or CORE = 1 (slave) has to be
10 Note: The OSEK RTOS used in CIAA-Firmware does not need
defined in each Task, Alarm, Counter and ISR within
dynamic memory allocation because it is a static operating system. Only
the POSIX driver stack depends on this functionality. the OIL configuration file in order to be generated in
11 CIAA-Firmware commit d75abf5. the corresponding OSEK instance14 .
12 CIAA-Firmware circular buffer definition: ciaaLibs_CircBuf.h.
13 CIAA-Firmware message structure: ciaaMulticore_ipcCmd_t. 14 Multicore OIL file example: blinking_multicore.oil.
E. OSEK-OS API extension • Improvements on shared memory structures for both
FreeOSEK API functions improved in this work are OSEK instances, such as definitions of tasks, alarms
described in this section. In every case, the new functionality and events that are currently located in both memory
is executed only if the parameter MULTICORE = TRUE is images.
defined in the OIL configuration file. • Definition of message queues for each core. In this
implementation there is only one message queue shared
• StartOS: besides OS initialization, now this function
by both cores.
calls ciaaMulticore_init (see section III-C)15 .
• Unification of the OSEK kernel, i.e., the master pro-
• ActivateTask now detects if the TaskID param-
cessor will be able to select the task to be executed
eter refers to a remote task. In this case, this function
by the slave. Currently, this behavior can be achieved
defines a ciaaMulticore_ipcMsg_t message and
indirectly using the ActivateTask function.
sends it through the multicore module (see section
• Although OSEK-OS is a static operating system (as
III-C)16 .
stated in section II-A), the POSIX device driver stack
• SetEvent works in a similar way to
used in CIAA-Firmware requires dynamically allocated
ActivateTask, detecting if the task ID refers
resources. This situation must be improved in order to
to a remote task. In such case, the event is set in the
define POSIX resources statically, improving stability
remote OSEK instance17 .
and determinism of the user application.

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