I am interested in the stability/maturity of OpenWSN package on NRF 52840 DK board: According to code it seems to be there (and it compiles) but OpenWSN doc does not mention NRF board as supported?
Hi Peter,
OpenWSN can be used on top of radios that provide an implementation of the IEEE 802.15.4 Radio HAL, which is the case for NRF52840. Therefore, you should be able to run OpenWSN with any NRF52840 board.
These test applications should work out of the box:
BOARD=<your_nrf52_board> make -C tests/pkg_openwsn all flash term
BOARD=<your_nrf52_board> make -C tests/pkg_openwsn_sock_udp all flash term
Cheers.
Hi @Peter_Blomqvist, the documentation being outdated is my fault, I should have kept that in sync better. I opened a PR to do so https://github.com/RIOT-OS/RIOT/pull/17131.
Regarding the status of OpenWSN, the current issues and limitations are mostly still up to date with what is in the documentation
I re-tested just now, and everything seems OK with nrf52840dk.
Thanks @jia200x and @fjmolinas for support and contribution! Code indeed looked sane and no obvious disclaimers.
A follow-up question: I am looking into getting OpenWSN into NuttX OS which runs on NRF52840. OpenWSN on RIOT runs in user space and use RIOT 802.15.4 device as radio interface to Openstack. Now, NuttX does not seem to expose a low level radio device but a rather complete MAC device. On NRF boards the radio peripheral is however not registered in any driver, so i guess my options would be to make a radio driver using the NuttX defined radio interface - which seems a bit like going backwords, or i could (maybe) as a proof of concept probably access the radio peripheral from user space. Latter would of course not be a long-term solution but i am thinking it may have benefits i terms of more precise timings.
Any advice would be appreciated!
Best Peter
Note that RIOT does not have a concept of user and kernel space. RIOT targets devices without MMU (memory management unit), so it is technically impossible to give separate tasks their own virtual address space. As a result, RIOT does not implement processes, but only threads (that share the same address space, which is the physical address space).
We are well aware that MPUs (memory protection units) are becoming more and more available. Those don’t add the ability to create processes (as still the physical address space is used directly), but allow to limit the access to memory regions based on the thread that is currently executing. In fact, RIOT already uses MPUs to detect stack overflows. Beyond that, MPUs would allow to implement “user space threads” and “kernel threads”, where the “user space threads” cannot access memory of other threads or memory mapped I/O - which would be a sensible user space and kernel space separation. There are plans to add this to RIOT, but to my knowledge nobody is currently working on this.
Thanks maribu.
Yes i should have put “user space” in quotes 
In my case protection of peripherals will be critical rather than protection of kernel memory space:
NuttX has a “flat” build option that would make MPU use rather similar to RIOT i think.
Best Peter
NuttX does not seem to expose a low-level radio device but a rather complete MAC device.
OpenWSN requires direct radio access, so you might have issues if only a complete MAC device is exposed. Are you thinking of ways to use RIOT as your nrf52 bsp to interface with OpenWSN and then with Nuttx?
On NRF boards the radio peripheral is however not registered in any driver
Not sure what you mean by this. But in any case, NRF radio drivers are not very complicated and OpenWSN also has a driver for nrf52 AFAIK, although I think its not working atm.
If you don’t mind me asking, why do you want to port it to Nuttx, is it just to support the stack there? or is that just a step towards a further goal?
Exactly. Like RIOT, NuttX also runs e.g. on AVR boards, which just don’t have an MPU.
I don’t think that RIOT will drop support for “legacy” MCUs without an MPU either, so that use of the MPU will remain optional.
I think the RIOT integration of OpenWSN is a very nice reference on NRF boards. NuttX on NRF52840 does have an “experimental” HAL to the NRF on-board Radio, but it is not integrated into the MAC layer or any other part of NuttX.
The first step would indeed be able to run a 6TiSCH stack on NuttX. . Then there’s proper radio/MAC interface to Openstack, the “user space socket” in NuttX could make Openstack integration rather seemless, and longer term there’s things like multiple IF’s and forwarding to consider.
Best Peter
I can flash the NRF22840 DK board (tests/pkg_openwsn) and get a terminal. But i don’t seem to be able to get openserial running and connect to openvisualizer: I uncommented
USEMODULE += openwsn_serial in
tests/pkg_openwsn/Makefile
but i only see one serial device on my host and that seems to be the application itself and not openwsn serial which i understand used HDLC. Openvisualizer gives me this output, (my board is connected to ttyACM0)
[MoteProbe:WARNING] Probing motes: [’/dev/ttyACM0’] at baudrates [‘115200’] 12:32:33 [MoteProbe:SUCCESS] Discovered serial-port(s):
You will need to also include stdio_null, if you have multiple UARTs (or uart and a USB device) you can hove both RIOT stdio and openvisualizer output, otherwise you must choose between one of them (stdio_null means you don’t want RIOT stdio)
OK,
Un-commenting stdio_null in the makefile seems to kill the RIOT output, and in minicom i can verify someting coming out of the board, however openvisualizer still does not seem to be able to detect the serial to openvsn.
Best Peter
I stand corrected - openvisualizer suddenly detected my board!
I notice that the board_info.h defines TSCH slot to 20ms instead of 10ms: Is this a fundamental limit for OpenWSN on boards in lower end or is it an effect of scheduling OpenWSN in RIOT?
This is the current default from OpenWSN, I don’t remember why but at some point 10ms was not enough and they increased the default to 20ms. I don’t think it will work correctly with a 10ms slot, but I don’t really think I ever tried either.
Longer slots allows for more nodes to get a slot, while also reducing power draw as nodes can sleep longer. Downside is latency is higher.
Thank you for validating that this still works.
Contiki use 10ms slots, also on NRF boards, but scheduling and routing (no openvisualizer) is different. AFAIK, TSCH specifies one frame per slot and and @ 250kbps one frame takes ~4ms to transmit, so 20ms seems a bit of overhead - i will have a go and see how it works.
I got a bit more progress: Adding a second NRF board it tries to do a CoAP Join: Open Visualizer in the ROOT Node: 13:04:56 [JRC:VERBOSE] New node: ae46:832e:dd17:4938. Creating new OSCORE context… 13:04:56 [JRC:VERBOSE] received JRC join request
Both nodes are visible as neighbors from each other.
However it seems like the RPL child is loosing sync (output of ifconfig=:
IEEE802154E sync: 0 (sync was one for a period)
6TiSCH joined: 0
The join does not seem to complete - probably due to loss of sync?
openwsn queue list Creator: cjoin [29], Owner: coap [28] Creator: sock-udp [26], Owner: 6top2154e [10] Creator: sock-udp [26], Owner: 6top2154e [10]
Any hints on how to configure?
I suspect the serial link is causing problems. Connecting root node to open visualizer works very flaky.
The issue with openvisualizer and the serial connection are correctly described in the package documentation, this part does not really depend on RIOT, but you can work around it by lowering the baud rate. You could also try this openvisualizer version, a while back I tried some hacks to work around this without lowering the baud rate. I might not have realized it and been using this version with my earlier test… I was also only testing between two nodes both using openserial, I would have to re-test with your setup. Also I actually realize that I used the nrf52840-mdk, normally it would be exactly the same as the nrf52840dK but sadly as the uart is important here issues might arise from the debugger. So could you try these 3 different things:
- connect to the uart gpios and not through the debugger
- lower the baudrtate
- use the patched openvisualizer version