Newcomer Query: Feature list/TODO items

Hi All,

I'm studying masters program in Computer Science and have very recently found out about RIOT-OS when I was looking for GSOC 2015 projects in the area of Embedded Systems. For past few months I've been involved in development of Embedded solution for Internet of Thing domain and have gained some knowledge about the eco-system (Evaluation board, SDK, Toolchain, Vendor provided networking stack, libraries, prototyping etc) for a typical Embedded solution. (I've been mostly involved with SOCs from STMicroelectronics and Nordic Semiconductor).

Few days back I asked on RIOT-OS IRC channel about the possibility of participation of RIOT-OS for GSOC 2016, but I didn't get any response. I guess it's not planned at the moment. However, At the same time, I need to work on my Masters Thesis and I'm wondering that It might be possible that some significant work for RIOT OS __may__ get counted towards Thesis. On the GitHub wiki page, I could not find enough information on such feature list or TODOs list. (However, I must inform that, so far (In two days), I have mostly skimmed through the information on RIOT-OS GitHub page, forked the codebase, and have done some early setup; Toolchain, Configuring tool for Firmware Flashing, arranged a target board etc), hence Is there any feature list with some overview etc ? That would be very helpful to me.

Thanks, Amit

P.S. The RIOT-OS user mailing list archive link is broken.

Hi Amit and welcome to RIOT!

Few days back I asked on RIOT-OS IRC channel about the possibility of participation of RIOT-OS for GSOC 2016, but I didn't get any response. I guess it's not planned at the moment.

As you assumed correctly, it's too early for a definitive decision, but I think it is likely that RIOT will apply next year, too.

However, At the same time, I need to work on my Masters Thesis and I'm wondering that It might be possible that some significant work for RIOT OS __may__ get counted towards Thesis.

I think this is definitely possible.

On the GitHub wiki page, I could not find enough information on such feature list or TODOs list. (However, I must inform that, so far (In two days), I have mostly skimmed through the information on RIOT-OS GitHub page, forked the codebase, and have done some early setup; Toolchain, Configuring tool for Firmware Flashing, arranged a target board etc), hence Is there any feature list with some overview etc ? That would be very helpful to me.

I think if you look at RIOT - The friendly Operating System for the Internet of Things and RIOT - The friendly Operating System for the Internet of Things you will get a rather complete overview over existing features.

I guess there are several hot open topics on nearly all layers on the system and the networking side of RIOT. Do you have any particular interests in the area of IoT? Are you more interested in system design, hardware support (e.g. drivers) or more in the networking aspect (link layer, routing, application layer...)?

The RIOT-OS user mailing list archive link is broken.

Thanks for the hint. Now it should be fixed again.

Cheers, Oleg

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, 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), watched the RIOT-OS introductory video on Youtube [1] and tried some other example application. So far so good.

I think, I need to spend some more time to get a clearer picture, however I do have few doubts (probably silly ones right now) and have few areas of interest.

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)?

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

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 ?

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 ?

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.

Thanks, Amit

My bad, forgot to add the link to the video on Youtube. Adding it now.

[1] https://www.youtube.com/watch?v=Cwf3y2Xj0og

Thanks, Amit

Hi Amit,

Hi Amit and welcome to RIOT!

Few days back I asked on RIOT-OS IRC channel about the possibility of participation of RIOT-OS for GSOC 2016, but I didn't get any response. I guess it's not planned at the moment.

As you assumed correctly, it's too early for a definitive decision, but I think it is likely that RIOT will apply next year, too.

However, At the same time, I need to work on my Masters Thesis and I'm wondering that It might be possible that some significant work for RIOT OS __may__ get counted towards Thesis.

I think this is definitely possible.

On the GitHub wiki page, I could not find enough information on such feature list or TODOs list. (However, I must inform that, so far (In two days), I have mostly skimmed through the information on RIOT-OS GitHub page, forked the codebase, and have done some early setup; Toolchain, Configuring tool for Firmware Flashing, arranged a target board etc), hence Is there any feature list with some overview etc ? That would be very helpful to me.

I think if you look at RIOT - The friendly Operating System for the Internet of Things and RIOT - The friendly Operating System for the Internet of Things you will get a rather complete overview over existing features.

I guess there are several hot open topics on nearly all layers on the system and the networking side of RIOT. Do you have any particular interests in the area of IoT? Are you more interested in system design, hardware support (e.g. drivers) or more in the networking aspect (link layer, routing, application layer...)?

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, 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), watched the RIOT-OS introductory video on Youtube [1] and tried some other example application. So far so good.

I think, I need to spend some more time to get a clearer picture, however I do have few doubts (probably silly ones right now) and have few areas of interest.

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)?

It will be super easy :slight_smile: ! We have common peripheral driver APIs that must be fulfilled by the underlying hardware (hardwae abstaction). That means, higher layer software will be portable without touching lowlevel drivers.

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

Compare ble: Adding a ble link layer implementation by jhollister · Pull Request #3541 · RIOT-OS/RIOT · GitHub. As you can see, we currently have drivers for a BLE device and an initial approach for a link layer implementation. My gut feeling tells me, that the student who started working on it won't spend more time. Currently I'm looking for someone who will take this work over. Maybe found one, we'll see...

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 ?

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 ?

There are no drivers for the Spansion flash memory in RIOT. If you plan to work on it, you might also be interested in the NVRAM interface and the implementation for the mulle board.

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.

Thanks, Amit

Best, Peter

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, Oleg

[1] Release RIOT-2015.09 · RIOT-OS/RIOT · GitHub [2] http://wiki.riot-os.org/minutes-OTA-meetup-13.2.2015 [3] Initial TFTP support by DipSwitch · Pull Request #3911 · RIOT-OS/RIOT · GitHub [4] sys: elfloader implementation for RIOT by SGSSGene · Pull Request #1421 · RIOT-OS/RIOT · GitHub [5] Elf Loader for RIOT (Work In progress) by kushalsingh007 · Pull Request #3686 · RIOT-OS/RIOT · GitHub [6] http://riot-os.org/files/2015-riotlab-tutorial.pdf

Hi!

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

I see, Peter was faster than me. :wink:

It will be super easy :slight_smile: ! We have common peripheral driver APIs that must be fulfilled by the underlying hardware (hardwae abstaction). That means, higher layer software will be portable without touching lowlevel drivers.

That's awesome \m/

Compare ble: Adding a ble link layer implementation by jhollister · Pull Request #3541 · RIOT-OS/RIOT · GitHub. As you can see, we currently have drivers for a BLE device and an initial approach for a link layer implementation. My gut feeling tells me, that the student who started working on it won't spend more time. Currently I'm looking for someone who will take this work over. Maybe found one, we'll see...

Nice. Maybe I'll be able to contribute something in Future. Any documents ?

There are no drivers for the Spansion flash memory in RIOT. If you plan to work on it, you might also be interested in the NVRAM interface and the implementation for the mulle board.

RIOT/drivers/include/nvram-spi.h at master · RIOT-OS/RIOT · GitHub RIOT/drivers/nvram_spi/nvram-spi.c at master · RIOT-OS/RIOT · GitHub RIOT/drivers/include/nvram.h at master · RIOT-OS/RIOT · GitHub RIOT/boards/mulle/include/mulle-nvram.h at master · RIOT-OS/RIOT · GitHub RIOT/boards/mulle/board.c at master · RIOT-OS/RIOT · GitHub

Thank you for the links. As Oleg also suggested that, this as a good beginner level task, hence I plan to work on it to get started.

Thanks, Amit

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.

I'm planning to investigate complete firmware upgrade over the air. Currently my plan is to try out various approach to this problem, starting with the simplistic one (Using vendor provided libraries, use AT+ command, no security check etc) and slowly move towards more roboust and practical solution.

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

I plan to work on this to get started.

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, Oleg

[1] Release RIOT-2015.09 · RIOT-OS/RIOT · GitHub [2] http://wiki.riot-os.org/minutes-OTA-meetup-13.2.2015 [3] Initial TFTP support by DipSwitch · Pull Request #3911 · RIOT-OS/RIOT · GitHub [4] sys: elfloader implementation for RIOT by SGSSGene · Pull Request #1421 · RIOT-OS/RIOT · GitHub [5] Elf Loader for RIOT (Work In progress) by kushalsingh007 · Pull Request #3686 · RIOT-OS/RIOT · GitHub [6] http://riot-os.org/files/2015-riotlab-tutorial.pdf

Thank you for much needed information and those references.

Thanks, Amit

On Thu, Oct 22, 2015 at 10:27 AM, Peter Kietzmann

There are no drivers for the Spansion flash memory in RIOT. If you plan to work on it, you might also be interested in the NVRAM interface and the implementation for the mulle board.

RIOT/drivers/include/nvram-spi.h at master · RIOT-OS/RIOT · GitHub RIOT/drivers/nvram_spi/nvram-spi.c at master · RIOT-OS/RIOT · GitHub RIOT/drivers/include/nvram.h at master · RIOT-OS/RIOT · GitHub RIOT/boards/mulle/include/mulle-nvram.h at master · RIOT-OS/RIOT · GitHub RIOT/boards/mulle/board.c at master · RIOT-OS/RIOT · GitHub

Yesterday, I finished interfacing Spansion serial NOR flash memory with STM32F072C8 SOC over SPI bus on a custom board by using libraries provided by ST Microelectornics and without using any Operating system middle layer. I now plan to work on the driver for this same memory for RIOT, However I've few doubts regarding the organization of the code, testing and pull request. Please comment on items below:

1: This particular serial NOR flash memory has it's own particularities/ command sets etc, hence I'm planning to add a new driver file (say, drivers/nvram_spi/s25fl127s.c)

2: Add Spansion flash memory specific macros, data structure, function declaration under drivers/include/s25fl127s.h

3: Use existing SPI specific code for STM32F07x SOC /cpu/stm32f0/periph/spi.c

4: I will do some testing as I have the hardware, however, I'm wondering if someone else can also help me out with the testing, before I send the pull request.

5: Any other comments, suggestions for a newcomer, as this will be my first ever Pull request for any Open source project.

-Amit