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] 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
! 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.