[riot-devel] Newcomer Query: Feature list/TODO items

Oleg Hahm oliver.hahm at inria.fr
Thu Oct 22 09:49:37 CEST 2015

Hi Amit!

> Thank you for your mail. Luckily I got access to the IOT-Lab testbed and
> during past few days, I've been busy getting acquainted with the testbed,

Good to hear that. IMO the IoT-LAB is a wonderful platform and great for
experimenting with RIOT.

> going through the tutorials (RIOT OS tutorial 3 on their website seem to
> be outdated as I couldn't find the RPL UDP example under RIOT example
> application folder),

Yes, you're right. With the latest release [1] we switched to a new network
stack (gnrc) which obsoleted also the old examples. But thanks for the hint, I
guess someone needs to update this tutorial.

> 1: Generally vendors provide BSP (startup files; combination of assembly
> and C), Libraries and in some cases binaries with some glue logic
> (e.g. Nordic Semiconductor distributes Bluetooth stack, ANT stack etc
> as a binary, which they call softdevice) for bare metal programming.
> Those Vendor specific APIs are not inter-operable. So, Is RIOT-OS an
> alternative to such cross platform development ? I mean If I develop an
> application for one hardware platform (Say NRF51822, with ARM Cortex
> M0 SOC, But with different sets of Peripherals) using RIOT-OS,
> how easy it would be to port the same application on another platform
> (say, STM32 also with same ARM MCU but with slightly different set
> of Peripherals)?

RIOT aims indeed to provide a vendor independent API for the widest possible
range of architectures in the scope of IoT devices. In the past, we
experienced that building a hardware abstraction on top of the code provided
by the vendors lead to unnecessary bloated code, ugly interfaces, and
sometimes problems with the license. Implementing our own API and interfaces
to the peripheral devices, we came out with a solution that requires some more
effort for initial porting to a new platform, but turned out to be more
flexible and even more efficient as the code the vendors provides.

In general, from an application perspective it shouldn't be necessary to
change a single line of code switching from one platform to another in RIOT.

> 2: It seems that there has been some work already done for BLE
> (Bluetooth Low Energy) support. What is it's current status ?

I'm probably not the best to answer this question. Peter, James, anyone else
with an overview here?

> My areas of interest in no particular order are
> 1: Bootloader for Firmware upgrade over the air.
> Some time back, I implemented DFU-OTA (Device Firmware Upgrade
> Over The AIR) over Bluetooth transport for a custom board having Nordic
> Semiconductor's nRF51822 SOC. Thanks to the Bootloader, distributed
> by Nordic, and excellent documentation, using the bootloader with my
> application was relatively easy. During that exercise, I understood that
> some glue logic was required in the application and the bootloader, and
> also depends on some hardware specific configuration. How easy or
> difficult it would be to have such Firmware upgrade feature, when
> using RIOT-OS ?

That's indeed a very interesting topic and several people spent already some
thoughts on this. In fact, some time ago a task forced has been established to
tackle this issue, but is dormant right now [2]. Also, DipSwitch [3] is
planning to implement some OTA based on TFTP as far as I know. And last but
not least some people started to implement dynamic loading for RIOT [4][5].

To answer your question: it depends on what exactly you're planning to do.
E.g., do you want to implement a full firmware update, i.e. replacing the
whole binary or just update a single library or the application? Where do you
want to store the upgrade during the process? And then there are several open
questions about disseminating the upgrade through a network, e.g. security,
integrity and so on.

In general, there should be ways to implement such a procedure in a more or
less hardware independent way (using peripheral interfaces for things like
NVRAM or flash), but obviously some hardware dependent code is required for
each architecture that might not yet be available.

> 2: I've a custom board which has a on-board external Flash memory
> from Spansion, connected to STM32 MCU (ARM Cortex M0 based
> SOC) over SPI bus. I also looked at the drivers directory of RIOT OS
> and so far it seems that no such drivers for Spansion flash memory
> connected over SPI bus exist. So maybe this is one of the area,
> I can work on ?

Sounds like a good beginner task to familiarize yourself with RIOT and its
driver interfaces and a good first step towards 1. 

> 3: I've interest in Networking aspects too, however, I do not have
> any practical exposure to lower layers such as 802.15.4,
> 6loWPAN and have limited experience with IPv6.

You will find a lot of experience and help in the networking aspect
(particular, concerning IPv6 and 6LoWPAN). Maybe you can take a look at the
`gnrc_networking` example and try it on the IoT-LAB. Some slides as a kind of
updated version of the tutorial you mentioned before are online available [6].

Have fun,

[1] https://github.com/RIOT-OS/RIOT/releases/tag/2015.09
[2] http://wiki.riot-os.org/minutes-OTA-meetup-13.2.2015
[3] https://github.com/RIOT-OS/RIOT/pull/3911
[4] https://github.com/RIOT-OS/RIOT/pull/1421
[5] https://github.com/RIOT-OS/RIOT/pull/3686
[6] http://riot-os.org/files/2015-riotlab-tutorial.pdf
A SQL Query walks into a bar, approaches two tables and asks 'Can I join you?'

More information about the devel mailing list