Kicking the tyres of RIOT OS

RIOT is an RTOS that bills itself as “the friendly Operating System for the Internet of Things.”

There seems to be a fair amount of board support, including STM32 blue and black pills, ESP32, and even the Arduino Nano/Uno. Unsupported are the Raspberry Pi’s and the Pi Pico. A list of supported boards is available here.

So, I cloned their repo. Then

cd RIOT/examples

I copied one of their examples to the same directory, which I called my_project. Then

cd my_project

I edited main.c so that it looked like this

//Include Libraries
#include <stdio.h>
#include "thread.h"        // Use for Create the Thread
#include "xtimer.h"        // Use for create the delay
#include "periph/gpio.h"    // Use for GPIO operations

// Arduino-Nano On-Board LED connected with "A5" which mapped with atmega328p pin "PC5"
//#define EXTERNAL_LED GPIO_PIN(2,5)
#define EXTERNAL_LED GPIO_PIN(PORT_C, 13)


char task1_stack[THREAD_STACKSIZE_MAIN];
/**
 *
 */

void *Task1(void *arg)
{
	(void) arg;
	printf("Create Task1 Thread for Blink the External LED from the %s board.\n", RIOT_BOARD);
	gpio_init (EXTERNAL_LED, GPIO_OUT);
	while(1){
		puts("Task1\r\n");
		gpio_write (EXTERNAL_LED, 1);
		xtimer_msleep(500);
		gpio_write (EXTERNAL_LED, 0);
		xtimer_msleep(100);
	}
	return NULL;
}

/**
 *
 */
int main(void)
{
	xtimer_init();
#if 1
	printf("You are running RIOT on a(n) %s board.\n", RIOT_BOARD);
	printf("This board features a(n) %s MCU.\n", RIOT_MCU);
#endif

	thread_create(task1_stack,                         /* stack array pointer */
			sizeof(task1_stack),                            /* stack size */
			THREAD_PRIORITY_MAIN - 1,            /* thread priority */
			THREAD_CREATE_WOUT_YIELD | THREAD_CREATE_STACKTEST,        /* thread configuration flag, usually By default, the thread starts immediately */
			Task1,                                                 /* thread handler function */
			NULL,                                                 /* argument of thread_handler function */
			"task1"                                                /* thread_name */
		     );

	while(1){
		puts("--> I'm Main \n");
		xtimer_msleep(1000);
		//xtimer_msleep(200);
		//delay(100);
	}
	return 0;
}

As you can see, I created a task, set up the LED, and used xtimer_msleep() to sleep the task. That’s possibly a bit naughty inside a task, but I wanted to test the sleep functionality.

I wanted to test for the blue pill. I also needed to enable the xtimer module. So in the Makefile I did:

...
BOARD = bluepill
...
USEMODULE += xtimer

Then I built the project using make.

The resulting hex filing was placed in bin/bluepill, which I flashed to the chip, and hey presto, I got some blinky lights.

I didn’t get the Uno version working because I hadn’t figured out the USEMODULE trick of enabling the xtimer. Also, creating the thread meant that the project didn’t link. I think the thread uses too much memory. Perhaps the program’s default stack size was too big, and with some trimming it could be made to work.

The repo is of a chunky size, as you might expect from an OS that supports many systems. The standard Arduino API also seems supported, at least for the Arduino boards.

The bluepill hex file created by RIOT was 14192 bytes in size. This is way smaller than a similar file created by ARM mbed. The mbed file was about 44k in size, if I recall, and that was without threading. So you’re going to have to be careful here. mbed could easily max out your MCU flash if you do stuff that is more complicated.

So the advantages I see for RIOT over mbed is smaller binary size, faster compile times, and support for non-ARM chips.

Actually, one thing that disappointed me about libopencm3 is that the API is not standard across boards. The GPIO functions are not compatible between the blue and black pill. RIOT seems to offer a consistent API across chipsets. (Alas, I seemed to have fried my black pill after only a short amount of use. I’m not sure what I did wrong).

I am new to RTOSs, but my understanding is that FreeRTOS is mainly aimed at providing an RTOS scheduler, and virtually nothing else. That may be fine if that’s all you need, but the chances are that you’ll want extra goodies like consistent GPIO and Timer APIs, and suchlike.

I don’t know how RIOT compares with Zephyr. They both seem to cover the same space. Zephyr is getting a lot of buzz right now, so I can give no sage advice as to which horse to back. There are so many RTOSs to choose from, it seems to be mostly a case of picking something, and see how it takes you. There seems to be some interest in providing support for the RP2040 in Zephyr, whereas I’m not aware of any such effort for RIOT.

About mcturra2000

Computer programmer living in Scotland.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s