ARTe

What is ARTe?

ARTe (Arduino Real-Time extension) is an extension to the Arduino framework that supports multitasking and real-time preemptive scheduling. Thanks to ARTe, the user can easily specify and run multiple concurrent loops at differents rates, in addition to the single execution cycle provided by the standard Arduino framework.

ARTE design goals

ARTe has been developed to support concurrent real-time periodic activities, while maintaining the simplicity of the programming paradigm typical of the Arduino framework.

System description

The ARTE architecture is illustrated Figure 1. A user application exploits the ARTE framework to execute on the Arduino hardware platforms. Today ARTE supports the most popular platforms: Arduino UNO and Arduino DUE. In addition to the single loop present in the standard Arduino approach, the user can easily specify a number of concurrent loops to be executed at specific rates. Concurrency and real-time scheduling is provided by the ERIKA Enterprise open-source real-time kernel. Loops can use the standard Arduino libraries, which have been enhanced to guarantee mutual exclusion in the access of shared data structures. The impact of ARTe in terms of footprint and runtime overhead has beed evaluated by extensive tests and resulted to be negligible.

Figure 1: The ARTE architecture.

Getting started

Download the ARTe package and unpack it. By default, ARTe extension is disabled, so the Arduino IDE behaves exactly as the official one.
To be able to write multitasking sketches, you need to enable the ARTe extension through the menu: Tools > Arte > Enable

Now you are able to program multitasking sketches with your Arduino!
You can start experimenting with ARTe by trying some examples (link alla pagina examples).

NULLa

quattro

The ARTe programming model

As explained in the introduction, the ARTE programming model has been designed to result as similar as possible to the original Arduino programming model. Each periodic loop defined by the user is specified as follows:

void loopi(int period)
{
}

where i = 1,2,3,... and period represents the time interval (in milliseconds) with which the loop is executed. As in the original Arduino programming model, the setup() function is also available under ARTE with the same syntax and semantics. Similarly, the original loop() function can also be used under ARTE, offering the programmer the possibility to execute background activities when no other pending loops are running.

INTERNALS

This section describes the internal structure of ARTE. The ARTE build process is first presented to explain how the user code (i.e., the sketch) is processed to obtain a multitasking ERIKA application and the binary executable file. Then the section illustrates how ARTE provides support for mutual exclusion and how this is integrated inside the Arduino libraries.

ARTE build process

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

Figure 2: Build process

ARTE pre-processingDuring this phase, the sketch is processed to extract the structure of the application, that is, the identification of the loops with their periods, in order to automatically generate the ERIKA configuration supporting the execution of the user application.
For each identified loop, an ERIKA task configuration is generated in an OIL file and then associated to the code inside the loop. In addition, the period of the loop is extracted and used to configure an OSEK alarm, which is the OSEK standard mechanism conceived to trigger periodic activities. The remaining part of the ERIKA configuration consists in an OIL section that specifies the underlying hardware platform; this section is selected from a set of predefined OIL templates.

Arduino processingThis phase consists in the default Arduino transformation needed to produce a compiler-compatible code. In particular, the original sketch (in .pde or .ino formats) is converted to a standard .cpp file (i.e., C++ code); any additional files beside the main one are appended to it. Please refer to the official Arduino documentation for additional details on this phase.

ARTE post-processingThis phase is responsible for transforming the sketch into an ERIKA application and modify the .cpp file produced in the previous step to make it compiler-compatible. Specifically, each ARTE loop declaration is transformed into an OSEK compliant task declaration, in the form TASK(loopi). Also, since Arduino sketches are written in C++, while Erika is written in C, the ERIKA code has to be wrapped into an extern "C" declaration to avoid errors when the code is linked together. At this point, the sketch is ready to be compiled, but it still requires additions to make it fully functional. In particular, all the ERIKA initialization functions are added in the setup() function (i.e., before any user-defined code is executed), and each OSEK alarm automatically generated in the ARTE pre-processing phase is activated. In this way, task activations will be completely transparent to the user.

LinkingAs shown in Figure 2, the ARTE pre-processing phase produces as output the ERIKA configuration consisting in an OIL file. This file is given as input to the RT-DRUID tool, which generates the specific files of ERIKA describing its configuration. At this time, the ERIKA build process is executed to obtain the RTOS binary. Note that this binary file is an RTOS image specifically configured for the user application needs that are automatically derived from the ARTE sketch. On the other side, the user code is built by means of the standard Arduino build process, enhanced to have the visibility of ERIKA C headers, so obtaining the object files of the user application. Finally, the LINK phase puts together the ERIKA binary with the object files resulted from the Arduino build process, generating the final ELF binary file ready to be loaded into the microcontroller.

Download

Click here to download the latest version. It is based on the Arduino 1.5.6-r2 IDE. In this version only Windows is supported.

The following is the list of the currently supported boards:

Arduino DUE

Arduino Uno

Arduino Nano

Arduino Mega 2560

Examples

HelloARTe

BlinkingLeds

The selected example consists in a simple multi-rate led blinking application. In this example, the application is in charge of making three different leds blinking with different periods, equal to 3, 7, and 11 seconds, respectively.

Listing 4a shows the considered example implemented with the classical Arduino programming model. The single Arduino loop() contains a delay instruction that is responsible to define the time granularity of the loop. The argument passed to the delay function must be equal to the greatest common divisor (GCD) of the blinking periods (in this case 1 second). A variable count is used to keep track of the current multiple of the time granularity to determine which led has to blink.

On the other side, Listing 4b shows the same program formulated using the ARTE programming model. Using the proposed approach is it possible to specify three different loops, one for each led. The parameter indicated in the brackets of the loop is the period (in milliseconds) at which it has to be executed. Although such a simple example can still be easily handled with the original Arduino framework, the situation can get worse with more complex applications, requiring a much higher programming effort to emulate a multithread behavior.

WebMotionController

This example presents an evaluation of the ARTE approach on a more complex application developed on an Arduino DUE board. The system includes an inertial measurement unit (IMU), a servomotor and the Ethernet shield, an external hardware device that provides Ethernet connection to the Arduino board.

The goal of this application is to use a rotation angle measured by the inertial sensor to control the angular position of the servomotor, while hosting a web page that displays the values of the sensor and allows the user to enable or disable the actuation of the servo. To improve the responsiveness of the web user interface the orientation samples are streamed to the web browser though a WebSocket connection. Figure 4 shows an overview of the software and hardware layers involved in the demo.

Figure 4: Case-study: software and hardware layers

From a software perspective, the application is structured into nine periodic tasks. Each task is defined through an ARTE loop. Three loops are dedicated to motion control: the first loop (IMU Task) periodically samples the orientation from the IMU; the second loop (FIR Task) performs a lowpass filtering on the collected samples trough a FIR filter; the third loop (Servo Task) maps the filtered orientation samples to 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 Web page containing the HTML elements and the JavaScript code that triggers the WebSocket connection. The request is then received and processed by the WebSocket loop (WS Task) that responds to the browser. Such a response concludes the handshake and allows establishing a WebSocket connection between the application and the browser. Once the WebSocket connection has been established, another task (WS update Task) periodically sends orientation samples trough the connection. The samples are received by the JavaScript code running on the browser and used to update an HTML5 element that dynamically shows the orientation to the user.
Finally, to provide the user with a visual feedback on the periodic behavior of the ARTE loops, the application includes three additional loops, each toggling a LED at a different rate.

Table 3 reports the tasks periods and the profiled worst-case execution times (pWCETs). Note that, although the worstcase processor load is around 89 percent (as can be computed from the table), after the initialization phase for setting up all the devices and establishing the HTTP connection, the processor load stabilizes around 25 percent.
Finally, the memory footprint of the whole application resulted to be equal to 104,032 bytes, occupying about 20 percent of the available flash memory on the SAM3 microcontroller of the Arduino DUE board.
Overall, this case study shows that ARTE is able to manage complex multitasking applications with a minimal runtime overhead and footprint.

Task

Period [ms]

pWCET [µs]

FIR

10

285

IMU

10

1804

Servo

10

11

Web Server

500

216193

WebSocket

500

116428

WebSocket update

50

1003

LED-1

1000

7

LED-2

2000

7

LED-3

3000

7

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