ARTE: Arduino Real-Time Extension for ProgrammingMultitasking Applications∗

Pasquale BuonocuntoScuola Superiore Sant’Anna

Pisa, Italyp.buonocunto@sssup.it

Alessandro BiondiScuola Superiore Sant’Anna

Pisa, Italyalessandro.biondi@sssup.it

Marco PaganiScuola Superiore Sant’Anna

Pisa, Italym.pagani@sssup.it

Mauro MarinoniScuola Superiore Sant’Anna

Pisa, Italymauro.marinoni@sssup.it

Giorgio ButtazzoScuola Superiore Sant’Anna

Pisa, Italyg.buttazzo@sssup.it

ABSTRACTThis paper presents an extension to the Arduino frameworkthat introduces multitasking support and allows runningmultiple concurrent tasks in addition to the single execu-tion cycle provided by the standard Arduino framework.The extension has been implemented through the ERIKAEnterprise open-source real-time kernel, while maintainingthe simplicity of the programming paradigm typical of theArduino framework. Furthermore, a support for resourcesharing has also been integrated in the external Arduinolibraries to guarantee mutual exclusion in such a multi-taskenvironment.

CCS Concepts•Computer systems organization → Embedded soft-ware; Real-time operating systems;

KeywordsArduino, Real-time operating system, Multitasking

1. INTRODUCTIONIn recent years, Arduino established as the most popularplatform for rapid prototyping. It consists of a physicalprogrammable embedded board (often referred to as the mi-crocontroller) and an integrated development environment(IDE) that runs on a personal computer. Its widespreadadoption is mainly related to the simplicity of the develop-ment and programming phases, that magnifies the Arduinouser experience. In fact, Arduino provides a framework that

∗This work has been partially supported by Telecom Italia.

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copiesare not made or distributed for profit or commercial advantage and thatcopies bear this notice and the full citation on the first page. Copy-rights for components of this work owned by others than ACM mustbe honored. Abstracting with credit is permitted. To copy otherwise,or republish, to post on servers or to redistribute to lists, requires priorspecific permission and/or a fee. Request permissions from Permis-sions@acm.org.SAC 2016,April 04-08, 2016, Pisa, Italyc©2016 ACM. ISBN 978-1-4503-3739-7/16/04. . . $15.00

DOI: http://dx.doi.org/10.1145/2851613.2851672

allows the user to develop a fully-working application withoutknowing any details of the underlying hardware, in contrastwith most of embedded firmware development environments.This is achieved through a minimal programming model,clean library APIs to access the hardware resources and theuse of a simplified version of the C++ language, makingeasier to learn how to develop an Arduino application. Inaddition, there is a huge number of free third party librariesand code examples that allows a quick interaction with exter-nal devices, relieving the user from acquiring the knowledgefor their usage. Unlike most others programmable boards,Arduino does not need external hardware (i.e., a program-mer) to load the new code onto the board, since a USB cableis used for power supply, programming and communication.Finally, the Arduino board is designed with a common formfactor that allows making connections to the microcontrollerperipherals in a standard way.

In spite of its simplicity and effectiveness, Arduino does notsupport concurrency and a program is limited to a singleblock of instructions cyclically repeated. Such a limitationprevents a full exploitation of the computing platform and inseveral situations forces the user to adopt tricky coding solu-tions to manage activities with different timing requirementswithin a single execution cycle.

Paper contributions. To overcome the limitation ex-plained above, this paper presents the Arduino Real-TimeExtension (ARTE), which introduces a support for imple-menting concurrent real-time applications in the standardArduino framework with a minimal impact on the originalprogramming model. Furthermore, a preliminary API sup-port is proposed to addresses the problem of guaranteeinga mutually exclusive access to shared resources in such amultitasking environment. In addition to the classical Ar-duino programming model, consisting in a single main loopcontaining the code to be executed, ARTE allows the userto specify a number of different loops, each to be executedwith a given desired period. A set of experiments is finallypresented to evaluate the impact of the implemented solutionin terms of both memory footprint, runtime overhead andcpu load on a concrete case-study.

ARTE design goals. ARTE has been conceived accordingto the following design objectives:

1724

• Simplicity : although different works [2, 12, 4] havebeen proposed to integrate a multitasking support inArduino, we decided to pursue the “Arduino philoso-phy”, thus making all the new programming featuresprovided by ARTE ease of use. This has been achievedby designing the ARTE programming model as similaras possible to the original Arduino programming model,hence limiting the additional effort required to the userto implement concurrent applications.

• Real-Time multitasking support : Arduino is generallyused to build embedded systems that interact with theenvironment through sensors, actuators and communi-cation devices. For this reason, any delay introducedin the computational activities may affect the overallsystem performance [11]. Bounding the execution de-lays in all the concurrent activities programmed by theuser is therefore crucial for ensuring a desired systemperformance.

• Integration with standard Arduino Libraries: The hugenumber of libraries provided with Arduino is one ofthe key strength points that determined its widespreaduse. To this purpose, ARTE has been conceived toenable the use of all existing Arduino libraries inside amultiprogrammed application. This has been achievedthrough a slight modification of the libraries to ensuredata consistency under a multitasking execution.

• Efficiency : To preserve the performance of the Arduinocomputing platforms, ARTE has been designed to havea minimal impact on resource usage, in terms of bothfootprint and run-time overhead.

Paper structure. The remainder of this paper is organizedas follows. Section 2 discusses the background includingthe related work. Section 3 presents our proposed solution.Section 4 describes the internal structure of ARTE withdetails of its implementation. Section 5 reports an example ofusage of ARTE, a case-study and some experimental resultscarried out to evaluate the performance of the proposedapproach. Finally, Section 6 states our conclusions andfuture work.

2. BACKGROUND

2.1 Arduino FrameworkThe Arduino framework consists of a set of circuit boards(equipped with one or more microcontrollers) and an inte-grated development environment (IDE) used to develop theuser application and program the board. Various Arduinoboards have been released, having different computationalcapabilities and different I/O devices. For instance, the firstboard proposed, called Arduino UNO, is equipped with anATmega328P microcontroller running at 16 MHz, which of-fers 14 digital I/O pins and 6 analog inputs. Another popularboard is Arduino DUE, which outperforms Arduino UNOrelying on a 32-bit Atmel SAM3X8E ARM Cortex-M3 mi-crocontroller running at 84 MHz and offering a larger set ofI/O pins.

The Arduino framework offers a very simple programmingmodel structured in two basic functions, as reported in List-ing 1. Function setup() contains the code that must beexecuted when Arduino is powered on, while loop() con-tains the code that must be cyclically repeated forever. Thesetwo functions, together with other global data structures,are part of the main file, denoted as sketch, where Arduinoapplications are developed. As stated in the introduction,such a programming model does not allow the user to specifya multitasking application.

void setup() {<code here>

}

void loop() {<code here>

}

Listing 1: Arduino programming model

To support users in writing applications, a lot of standardlibraries are provided with the Arduino framework. Most ofthem are platform independent (making possible using thesame API independently of the specific Arduino board) andhave been designed to hide as much as possible all details re-lated to the functionality offered by the used microncontroller.Being Arduino a mono-programming environment, all thelibraries are designed not to be executed in concurrency.

2.2 Related WorkA few works have been proposed to support multitaskingin the Arduino framework [2, 1, 3], all consisting in ad-hoclibraries not relying on a real-time operating system (RTOS)to manage concurrency. This approach mainly suffers fromthe following drawbacks:

• tasks are cyclically executed in a cooperative manner,making more difficult to achieve response time guaran-tees on application tasks;

• the resulting programming model is quite more com-plicated with respect to the original one offered byArduino, requiring the user to specify initializationsand explicit preemption points.

In addition, most of such extensions are not maintained anddo not provide an explicit support for periodic activities.

Another proposed approach is FreeRTOS-Arduino [4], whichis based on the FreeRTOS kernel, ported to be used as anArduino library. Although this solution uses a RTOS toprovide fixed-priority preemptive scheduling, it requires theuser to be confident with concurrent programming and withthe FreeRTOS API, which is far more complex than thestandard Arduino programming model. Moreover, FreeR-TOS is not a static RTOS, because not all kernel code anddata structures can be tailored to the application at compiletime. For this reason, the kernel is characterized by a largerfootprint, memory, and runtime overhead due to dynamicobjects management.

Qduino [12] is another solution that extends the Arduino

1725

framework with a real-time kernel and a new API for han-dling multiple concurrent control loops and mutual exclusion.However, Qduino supports only x86 platforms and aims atmulticore CPUs, thus it is not compatible with the vastmajority of Arduino boards, whose CPUs are much simplerand lack memory protection units. Furthermore, it requiresthe average Arduino user to acquire additional knowledge onreal-time concurrent programming and the specific QduinoAPI. The Qduino API is quite similar to the one previouslyproposed by ARTE [10], but it requires the user to specifymore parameters than the task period.

Like FreeRTOS-Arduino and Qduino, ARTE relies on anRTOS to implement concurrency, but unlike the previousapproaches preserves the simplicity of the Arduino program-ming model, also providing a transparent integration of thelarge set of standard Arduino libraries. Moreover, ARTEsupports the most common Arduino platforms (i.e., ArduinoUNO and Arduino DUE).

To meet the design goals described in Section 1, the underlineRTOS should have a minimal impact in terms of footprintand runtime overhead and provide support for real-time taskmanagement. Among the existing open-source real-timekernels, ERIKA Enterprise [13] resulted to be the one thatbest fitted the requirements. Other open-source RTOSes,like FreeRTOS [5] and NuttX [6] could be used as well, buthave been discarded for their larger footprints due to thedynamic management of their kernel objects. To provide thebackground needed to understand the ARTE approach, thenext section briefly summarizes the features of the ERIKAkernel.

2.3 Erika EnterpriseERIKA Enterprise (ERIKA for short) is an open-sourcereal-time kernel [13] that allows achieving high predictabletiming behavior with a very small run-time overhead andmemory footprint (in the order of one kilobyte). ERIKAis an OSEK/VDX [16] certified RTOS that uses innovativeprogramming features to support time sensitive applicationson a wide range of microcontrollers and multi-core platforms.In addition to the OSEK/VDX standard features, ERIKAprovides other custom conformance classes, such as fixed-priority scheduling with preemption thresholds [19], deadlinescheduling, through the Earliest Deadline First (EDF) algo-rithm [14] and the Stack Resource Policy (SRP) [7], resourcereservations (FRSH) [15], and hierarchical scheduling (HR) [8,9]. ERIKA supports both periodic and aperiodic tasks underfixed and dynamic priorities and includes mutex primitivesfor guaranteeing bounded blocking on critical sections.

ERIKA also provides two types of interrupt handling mecha-nisms: a fast one (also referred to as Type 1) for short andurgent I/O operations, returning to the application withoutcalling the scheduler, and a safe one (also referred to as Type2) that calls the scheduler at the end of the service routine,meant to be used for the interaction with kernel objects (e.g.,for activating a task).

As specified by the OSEK/VDX standard, in ERIKA all theRTOS objects like tasks, alarms and semaphores are static;that is, all the RTOS configurations are predefined at compiletime and cannot be changed at run-time. The choice of usinga static approach is crucial for containing both footprint

and run-time overhead, obtaining a tailored RTOS imagethat is optimized for a specific application-dependent kernelconfiguration.

In ERIKA, the objects composing a particular applicationare specified in OIL (OSEK Implementation Language) andstored in proper configuration files. The ERIKA developmentenvironment also includes RT-Druid, which is a tool in chargeof processing the OIL configuration to generate the specificERIKA code for the requested kernel configuration.

3. THE ARTE APPROACH

3.1 System descriptionThe ARTE architecture proposed in this paper is illustratedin Figure 1. In ARTE, a user application exploits the ARTEframework to execute on the Arduino hardware platforms. Inaddition to the single loop present in the standard Arduinoapproach, the user can specify n concurrent loops. Loops canuse the standard Arduino libraries, which are also enhancedto be executed on a multitasking environment, as presentedin Section 4.3. Overall, the user application and the Arduinolibraries rely on the Arduino framework, which has also beenextended to support multiple concurrent loops by integratingit with the ERIKA Enterprise kernel (see Section 4.1). Atthe bottom of the ARTE architecture there are the Arduinohardware platforms. Today ARTE supports the most popularplatforms: Arduino UNO and Arduino DUE.

UserApplication Loop 1 Loop 2 Loop 3 Loop n. . .

E h dFramework

EnhancedArduino Libraries

Scheduler Resource SharingFP EDF SRP

Enhanced Arduino Framework

Scheduler Resource SharingFP EDF SRP

Arduino UNO Arduino DUE …Hardware

Figure 1: The ARTE architecture.

3.2 The ARTE programming modelAs explained in the introduction, the ARTE programmingmodel has been designed to result as similar as possible tothe original Arduino programming model. Each periodicloop defined by the user is specified as follows:

void loopi( int period) {<code here>

}

where i = 1, 2, 3, . . . and period represents the time interval(in milliseconds) with which the loop is executed.

1726

As in the original Arduino programming model, the setup()function is also available under ARTE with the same syntaxand semantics. Similarly, the original loop() function canalso be used under ARTE, offering the programmer thepossibility to execute background activities when no otherpending loops are running.

4. INTERNALSThis section describes the internal structure of ARTE. TheARTE build process is first presented to explain how the usercode (i.e., the sketch) is processed to obtain a multitaskingERIKA application and the binary executable file. Then thesection illustrates how ARTE provides support for mutualexclusion inside the Arduino libraries.

4.1 ARTE build processThe whole ARTE build process flow is shown in Figure 2.The original Arduino framework includes a sketch processingphase, denoted as Arduino processing, which is implementedinside the Arduino IDE. The main part of the ARTE buildprocess consists in extending the Arduino IDE with two ad-ditional processing phases (shown inside the dashed box): (i)ARTE pre-processing, which processes the sketch before theoriginal Arduino processing, and (ii) ARTE post-processing,invoked after the original Arduino processing.

Sketch

ARTE pre-processing

Arduino processing

ARTE post-processing

OIL file

.cppsource

files

RT-DRUID

ERIKAconfig files

ERIKAbinary file

ERIKA Build Process

Arduino Build Process

Arduino binary files

LINK

ELF

Figure 2: Build process

ARTE pre-processing. During this phase, the sketch isprocessed to extract the structure of the application, that is,the identification of the loops with their periods, in order toautomatically generate the ERIKA configuration supportingthe execution of the user application. For each identifiedloop, an ERIKA task configuration is generated in an OIL fileand then associated to the code inside the loop. In addition,the period of the loop is extracted and used to configurean OSEK alarm, which is the OSEK standard mechanismconceived to trigger periodic activities. The remaining part

of the ERIKA configuration consists in an OIL section thatspecifies the underlying hardware platform, which is selectedfrom a set of predefined OIL templates.

Arduino processing. This phase consists in the default Ar-duino transformation needed to produce a compiler-compatiblecode. In particular, the original sketch (in .pde or .ino for-mats) is converted to a standard .cpp file (i.e., C++ code);any additional files besides the main one are appended toit. Please refer to the official Arduino documentation foradditional details on this phase.

ARTE post-processing. This phase is responsible fortransforming the sketch into an ERIKA application andmodify the .cpp file produced in the previous step to make itcompiler-compatible. Specifically, each ARTE loop declara-tion is transformed into an OSEK compliant task declaration,in the form TASK(loopi ). Also, since Arduino sketches arewritten in C++, while Erika is written in C, the ERIKA codehas to be wrapped into an extern "C" declaration to avoiderrors when the code is linked together. At this point, thesketch is ready to be compiled, but it still requires additionsto make it fully functional. In particular, all the ERIKA ini-tialization functions are added in the setup() function (i.e.,before any user-defined code is executed), and each OSEKalarm automatically generated in the ARTE pre-processingphase is activated. In this way, task activations will becompletely transparent to the user.

Linking. As shown in Figure 2, the ARTE pre-processingphase produces as output the ERIKA configuration con-sisting in an OIL file. This file is given as input to theRT-DRUID tool, which generates the specific files of ERIKAdescribing its configuration. At this time, the ERIKA buildprocess is executed to obtain the RTOS binary. Note that,as described in Section 2.3, this binary file is an RTOS imagespecifically configured for the user application needs that areautomatically derived from the ARTE sketch. On the otherside, the user code is built by means of the standard Arduinobuild process, enhanced to have the visibility of ERIKA Cheaders, so obtaining the object files of the user application.Finally, the LINK phase puts together the ERIKA binarywith the object files that resulted from the Arduino buildprocess, generating the final ELF binary file ready to beloaded into the microcontroller.

4.2 Mutual exclusionSince the standard Arduino framework is designed to besingle-threaded, not all of its code is thread-safe, includingall the external third-party libraries. A simple way to keepthem safe in a concurrent environment is to run all thetasks in non-preemptive way. This solution however, wouldintroduce large blocking delays in the presence of loops withlong execution times. On the other hand, a fully preemptiveapproach cannot guarantee data consistency on shared globaldata structures.

The typical solution adopted in modern RTOSs is to guar-antee data consistency is to access global data structuresthrough mutual exclusion semaphores (mutexes). The useof mutex semaphores, however, requires inserting specificlock/unlock primitives inside the code. In the context ofreal-time operating systems, several resource access protocols,

1727

void WiFiDrv::config (...){

/∗ ∗∗∗ ARTE − begin critical section ∗∗∗ ∗/arteLock();

<SPI transaction>

/∗ ∗∗∗ ARTE − end critical section ∗∗∗ ∗/arteUnlock();

}

Listing 2: Modified Wifi shield library. File wifi drv.cpp

as Priority Inheritance Protocol (PIP) [17], Priority CeilingProtocol (PCP) [17], and Stack Resource Policy (SRP) [7]have been developed to bound the blocking delays caused byconcurrent resource accesses.

An alternative solution is to adopt a limited preemptive ap-proach [20], where preemption is disabled only inside specificregions of code (the critical sections). Note that fully pre-emptive and non-preemptive scheduling are two particularcases of such general approach.

A simple implementation of limited preemptive schedulingcan be achieved by defining a single non-preemptive high-priority task, as done in MansOS [18]. This solution, however,is quite limiting because of the additional constraint on theprogramming model. In fact, all the critical sections must beinserted in the non-preemptive task, disallowing safe resourcesharing among multiple tasks. This can be acceptable for asimple application scenario, like a small WSN application, butcannot be considered a general solution for a more complexembedded system application.

All the mechanisms discussed above are already implementedin ERIKA and can be used in ARTE. However, they requirethe user to insert specific RTOS primitives in the applicationcode and have a deep understanding of the problems relatedto concurrency. Unfortunately, this is in contrast with theArduino philosophy, which aims at simplicity.

To address mutual exclusion while maintaining the simplic-ity of the original Arduino framework, ARTE provides twoprimitives that allow first and third-party library developersto easily extend their library to guarantee safety in a multi-task environment. In addition, since the libraries support iscrucial for using ARTE, all the Arduino standard librarieshave been modified to be included as part of the ARTEframework.

The two primitives provided by ARTE to library developersare arteLock() and arteUnlock(), allowing the definition ofcritical sections. As an example, Listing 2 shows how afunction of the WiFi shield library has been modified toinclude a critical section, protecting the transaction betweenArduino and the WiFi shield over the SPI bus. In ARTE,mutual exclusion is implemented through a single sharedresource, denoted as (RES SCHEDULER), which is part ofthe OSEK standard. When the running task acquires a lockon that resource, the task becomes non-preemptive until sucha resource is released.

Thanks to this extension, any Arduino library developer, evenwithout any real-time system programming expertise, caneasily extends his own library code to be safe for a multitaskenvironment, without the need to declare and manage shared

static const uint8_t max_nesting_level_ = 1;static uint8_t nesting_level_ = 0;

void arteLock(void){

EE_hal_disableIRQ();

if (++nesting_level_ <= max_nesting_level_)GetResource(RES_SCHEDULER);

EE_hal_enableIRQ();}

void arteUnlock(void){

EE_hal_disableIRQ();

if (nesting_level_ > 0) {if (−−nesting_level_ < max_nesting_level_)

ReleaseResource(RES_SCHEDULER);}

EE_hal_enableIRQ();}

// For test purposeuint8_t arteEnabled(void) { return 1; }uint8_t lockNestingLevel(void) { return nesting_level_; }

Listing 3: ARTE primitives for mutual-exclusion.

resources.

Since many Arduino libraries are built using a hierarchicalstructure (i.e., relying on other lower-level libraries), it isnecessary to deal with nested critical sections. To copewith this problem, the ARTE mutual-exclusion support isdesigned in such a way that only the first arteLock() andthe last arteUnlock() actually enters and exits the criticalsection. Furthermore, to avoid side effects, arteUnlock() doesnot have any effect if called from outside a critical section.

In order to be seamlessly integrated with the Arduino fram-work, the API has been conceived to have no effect whenthe ARTE extension is disabled. In this way, the Arduinolibraries, modified with the inclusion of critical sections, arestill compatible with the standard Arduino framework whenthe ARTE extension is disabled. This choice facilitates thedistribution of ARTE enhanced libraries as main-line distri-bution, having a common code for ARTE and non ARTEusers.

4.3 Library implementationAs a default option, functions arteLock() and arteUnlock()are declared as weak aliases of the same ”empty” function,thus implementing a null behavior. If ARTE extension isenabled, the weak symbols are overridden by strong symbolsdefined in the ERIKA image, whose source code is reportedin Listing 3. In both functions, interrupt are disabled toavoid critical races on the variable nesting_level_, then thenesting level is checked and the OSEK API GetResource (orReleaseResource) is used to disable preemption.

5. EVALUATIONThis section presents some experiments carried out to evalu-

1728

ate the effectiveness of the proposed approach. An exampleof ARTE application is illustrated to compare it with a pos-sible formulation that would be necessary using the classicalArduino programming model.

Furthermore, a complete case-study project has been de-veloped with the purpose of testing the proposed extensionin a “real world” scenario, where multiple extension devicesand peripherals are attached to the Arduino board. Thisprovides an interesting test bench for this work since theArduino libraries, needed to control those additional devices,are required to work properly in a multitask environment.

5.1 ExampleThe selected example consists in a simple multi-rate ledblinking application. In this example, the application is incharge of making three different leds blinking with differentperiods, equal to 3, 7, and 11 seconds, respectively.

int led1 = 13;int led2 = 14;int led3 = 15;int count = 0;

void loop() {if (count % 3 == 0)

digitalToggle (led1) ;

if (count % 7 == 0)digitalToggle (led2) ;

if (count%11 == 0)digitalToggle (led3) ;

if (count == 3 ∗ 7 ∗ 11)count = 0;

count++;delay(1000);

}

(a) Arduino sketch

int led1 = 13;int led2 = 14;int led3 = 15;

void loop1(3000) {digitalToggle (led1) ;

}

void loop2(7000) {digitalToggle (led2) ;

}

void loop3(11000) {digitalToggle (led3) ;

}

(b) ARTE sketch

Listing 4: Example of multi-rate blinking leds sketcheswritten using classic Arduino and ARTE.

Listing 4a shows the considered example implemented withthe classical Arduino programming model. The single Ar-duino loop() contains a delay instruction that is responsibleto define the time granularity of the loop. The argumentpassed to the delay function must be equal to the greatestcommon divisor (GCD) of the blinking periods (in this case 1second). A variable count is used to keep track of the currentmultiple of the time granularity to determine which led hasto blink.

On the other side, Listing 4b shows the same program for-mulated using the ARTE programming model. Using theproposed approach is it possible to specify three differentloops, one for each led. The parameter indicated in thebrackets of the loop is the period (in milliseconds) at whichit has to be executed.

Although such a simple example can still be easily handledwith the original Arduino framework, the situation can getworse with more complex applications, requiring a muchhigher programming effort to emulate a multithread behavior.

Another great advantage of the ARTE multithread supportis that loops are preemptive, with a context switch timeresulted to be lower than 10 microseconds on the ArduinoDUE platform. This feature is really important when theapplication includes small loops running with short periodstogether with time-consuming loops with a long period. Thissituation, cannot be easily implemented using the classicalArduino programming model.

Listing 5 shows the OIL configuration generated by ARTEfor the multi-rate blinking example. As the figure shows, anOSEK-task specification is provided for each loop defined inthe ARTE sketch. In addition, an OSEK-alarm is associatedto each task. Task priorities are implicitly assigned followingthe rate-monotonic policy (i.e., the lower the period, thehigher the priority).

CPU m3 {OS EE {

CPU_DATA = CORTEX_MX {MODEL = M3;APP_SRC = "ARTE−sketch.cpp";COMPILER_TYPE = GNU;MULTI_STACK = FALSE;

};

MCU_DATA = ATMEL_SAM3 {MODEL = SAM3xxx;

};KERNEL_TYPE = BCC1;

};

COUNTER TaskCounter;

TASK loop3 {PRIORITY = 0x03;SCHEDULE = FULL;STACK = SHARED;

};

ALARM Alarmloop3 {COUNTER = TaskCounter;ACTION = ACTIVATETASK { TASK = loop3; };

};

TASK loop2 {PRIORITY = 0x02;SCHEDULE = FULL;STACK = SHARED;

};

ALARM Alarmloop2 {COUNTER = TaskCounter;ACTION = ACTIVATETASK { TASK = loop2; };

};

TASK loop1 {PRIORITY = 0x01;SCHEDULE = FULL;STACK = SHARED;

};

ALARM Alarmloop1 {COUNTER = TaskCounter;ACTION = ACTIVATETASK { TASK = loop1; };

};};

Listing 5: The OIL configuration generated for themulti-rate led blinking example.

1729

5.2 FootprintArduino boards are typically memory constrained platforms,therefore this section evaluates the impact of ARTE in termsof memory occupation.

Table 1 compares the memory footprint obtained when com-piling an empty sketch with the classic Arduino framework,with the footprint of a sketch compiled with ARTE for adifferent number of empty loops. The reference platform forthis evaluation is the Arduino DUE board. Note that, for thecase of a single loop, only 1216 bytes of additional memoryare required by ARTE, corresponding just to 0.23 percentof the total available memory. If further empty loops aredeclared, the memory footprint grows almost linearly with arate of less than 50 bytes per loop. The plot in Figure 3 showssuch a linear increase in memory footprint as a function ofthe number of loops.

1 2 3 4 5 6 7 8 9 1011,700

11,800

11,900

12,000

12,100

Number of loops

Size(bytes)

Figure 3: Footprint for an ARTE empty sketch.

Table 2 compares the footprints resulting from the two ver-sions of the three-led example shown in Listing 4. In thiscase, the additional footprint of the ARTE version is only1232 bytes.

Platform Footprint

ArduinoSize (bytes)

Uno Due

466 11,716

Arduino + ARTE

Loops Size (bytes)

Uno Due

1 802 11,7162 822 11,7643 840 11,8045 878 11,88410 974 12,084

Table 1: ARTE and Arduino footprints for an empty Sketch.

5.3 A case-studyThis section presents an evaluation of the ARTE approach ona more complex application developed on an Arduino DUEboard. The system includes an inertial measurement unit(IMU), a servomotor and the Ethernet shield, an externalhardware device that provides Ethernet connection to theArduino board.

Platform Footprint

ArduinoSize (bytes)

10,852

Arduino + ARTELoops Size (bytes)

3 12,084

Table 2: Footprint for the blinking LEDs demo.

The goal of this application is to use a rotation angle mea-sured by the inertial sensor to control the angular position ofthe servomotor, while hosting a web page that displays thevalues of the sensor and allows the user to enable or disablethe actuation of the servo. To improve the responsiveness ofthe web user interface the orientation samples are streamedto the web browser though a WebSocket connection. Fig-ure 4 shows an overview of the software and hardware layersinvolved in the demo.

Ethernet

MPU6050

Servo

I2Cdev

WireSPI

Arduino DUE

ERIKA RTOS

Ethernet shield MPU-6050 Servo

IMUTask

FIRTask

ServoTask

WEBTask

WSTask

WS updateTask

LED [i]Tasks

Arduino Framework + ARTE

Figure 4: Case-study: software and hardware layers

From a software perspective, the application is structuredinto nine periodic tasks. Each task is defined through anARTE loop. Three loops are dedicated to motion control: thefirst loop (IMU Task) periodically samples the orientationfrom the IMU; the second loop (FIR Task) performs a low-pass filtering on the collected samples trough a FIR filter; thethird loop (Servo Task) maps the filtered orientation samplesto the servo configuration space to control the servomotor.

The network functionality is realized by other three loops.The first loop (WEB Task) listens for HTTP requests and,once a request is received, it responds by sending a Webpage containing the HTML elements and the JavaScript codethat triggers the WebSocket connection. The request is thenreceived and processed by the WebSocket loop (WS Task)that responds to the browser. Such a response concludes thehandshake and allows establishing a WebSocket connectionbetween the application and the browser. Once the Web-Socket connection has been established, another task (WSupdate Task) periodically sends orientation samples troughthe connection. The samples are received by the JavaScript

1730

code running on the browser and used to update an HTML5element that dynamically shows the orientation to the user.

Finally, to provide the user with a visual feedback on theperiodic behavior of the ARTE loops, the application includesthree additional loops, each toggling a LED at a differentrate.

Table 3 reports the tasks periods and the profiled worst-caseexecution times (pWCETs). As can be seen from Table 3,the worst-case processor load is around 89 percent. However,for every initialization phase occurring after each new HTTPconnection, the processor load stabilizes around 25 percent.

Finally, the memory footprint of the whole application re-sulted to be equal to 104,032 bytes, occupying about 20percent of the available flash memory on the SAM3 micro-controller of the Arduino DUE board.

Overall, this case study shows that ARTE is able to managecomplex multitasking applications with a minimal runtimeoverhead and footprint.

Task Period [ms] pWCET [µs]

FIR 10 285IMU 10 1804Servo 10 11Web Server 500 216193WebSocket 500 116428WebSocket update 50 1003LED-1 1000 7LED-2 2000 7LED-3 3000 7

Table 3: Tasks periods and estimated worst-case executiontimes for the demo application.

6. CONCLUSIONSThis paper presented a solution for integrating real-timemultiprogramming capabilities in the Arduino frameworkin order to simplify the development of complex embeddedsystems characterized by multiple periodic tasks running atdifferent rates. The integration has been implemented byexploiting the real-time features of the ERIKA Enterprisekernel, an OSEK-compliant open source kernel for smallembedded platforms. The extended interface enables the userto easily specify multiple loops to be executed at differentrates while guaranteeing mutual exclusion among sharedresources in a transparent way, thus preserving the simplicityof the classical Arduino framework.

Thanks to the proposed extension, the user can quickly andreliably exploit the full computational power of the platformwithout adopting tricky coding solutions, typically neededfor managing activities with different timing requirementswithin a single execution cycle.

The impact of the implemented extension in terms of bothmemory footprint and runtime overhead has been evaluatedand resulted to be affordable for most practical uses.

In the future, we plan to enhance ARTE by including a trans-parent mechanism to guarantee data consistency withoutrequiring the user to specify critical sections, thus preserv-

ing the simplicity characterizing the Arduino programmingmodel.

7. REFERENCES[1] Arduino-compatible multi-threading library.

https://github.com/jlamothe/mthread.

[2] Arduino scheduler library.https://www.arduino.cc/en/Reference/Scheduler.

[3] Cooperative multithreading for microcontrollers, includingarduino. https://code.google.com/p/threadkit.

[4] Freertos port for arduino.https://github.com/greiman/FreeRTOS-Arduino.

[5] Freertos: Quality rtos and embedded software.http://www.freertos.org.

[6] Nuttx real-time operating system. http://www.nuttx.org.[7] T. P. Baker. Stack-based scheduling for realtime processes.

Real-Time Systems, 3(1):67–99, April 1991.

[8] M. Bertogna, N. Fisher, and S. Baruah. Resource-sharingservers for open environments. IEEE Transactions onIndustrial Informatics, 5(3):202–220, August 1991.

[9] A. Biondi, G. Buttazzo, and M. Bertogna. Supportingcomponent-based development in partitioned multiprocessorreal-time systems. In Proceedings of the 27th EuromicroConference on Real-Time Systems (ECRTS 2015), Lund,Sweden, July 8-10, 2015.

[10] P. Buonocunto, A. Biondi, and P. Lorefice. Real-timemultitasking in arduino. June 2014.

[11] G. Buttazzo. Hard Real-Time Computing Systems:Predictable Scheduling Algorithms and Applications, ThirdEdition. Springer, New York, 2011.

[12] Z. Cheng, Y. Li, and R. West. Qduino: A multithreadedarduino system for embedded computing. In Proceedings ofthe 36th IEEE Real-Time Systems Symposium (RTSS 2015),San Antonio, Texas, December 2015.

[13] P. Gai, G. Lipari, L. Abeni, M. di Natale, and E. Bini.Architecture for a portable open source real-time kernelenvironment. In Proceedings of the Second Real-Time LinuxWorkshop and Hand’s on Real-Time Linux Tutorial,November 2000.

[14] C. Liu and J. Layland. Scheduling algorithms formultiprogramming in a hard-real-time environment. Journalof the Association for Computing Machinery, 20(1):46–61,January 1973.

[15] L. Marzario, G. Lipari, P. Balbastre, and A. Crespo. IRIS: Anew reclaiming algorithm for server-based real-time systems.In Proc. of the IEEE Real-Time and Embedded Technologyand Applications Symposium, Toronto, Canada, May 2004.

[16] OSEK. OSEK/VDX Operating System Specification 2.2.1.OSEK Group, http://www.osek-vdx.org, 2003.

[17] L. Sha, R. Rajkumar, and J. Lehoczky. Priority inheritanceprotocols: An approach to real-time synchronization. IEEETransactions on Computers, 39(9):1175–1185, September1990.

[18] G. Strazdins, A. Elsts, and L. Selavo. Mansos: Easy to use,portable and resource efficient operating system fornetworked embedded devices. In Proc. of the 8th ACMConference on Embedded Networked Sensor Systems. ACM,2010.

[19] Y. Wang and M. Saksena. Scheduling fixed-priority taskswith preemption threshold. In Proc. of the 6th IEEE Int.Conference on Real-Time Computing Systems andApplications (RTCSA’99), Hong Kong, China, December13-15, 1999.

[20] Y. Wu and M. Bertogna. Improving task responsiveness withlimited preemptions. In Proceedings of the 14th IEEEInternational Conference on Emerging Technologies &Factory Automation, ETFA’09. IEEE Press.

1731