Yes I tried to compile the rpl_udp example for the samr21-xpro but it did
not have enough RAM. Even with RPL in non-storing mode and a very small
routing table it would not fit.
Well, in non-storing you basically don't need any routing table (except for
the root node), but still it sounds weird to me that it doesn't fit. I guess
some optimization could be doable but...
Ultimately we would be looking to run UDP/RPL/COAP on top of the
For the evaluation just UDP would be fine to give me an idea if a M0+ would
be fast enough.
Is the size of RAM/flash for RIOT likely to increase? Currently building the
rpl_udp example results in 109K text+data, 37K bss. We were thinking of
going for a M0+ with 128KB flash and 64KB RAM but this does not leave much
room for expansion.
Hopefully and most likely the contrary will be the case. As the current network
stack could definitely need quite some memory optimizations and wastes a lot
of memory by many memcpy operations, we decided to completely redesign it, in
order come up with a much slimmer solution. (Apart of having identified other
drawbacks of the old solution.)
This new stack should definitely fit on the 32 kB RAM of the SAMr21 including
UDP/RPL/CoAP, but I cannot give any concrete numbers by now. Hauke, Martine,
can you give some rough numbers for the current state of the implementation?
Another advantage of the redesigned network stack will be its configurability.
The current version, for example, always expects the default minimum MTU for
IPv6 of 1280 bytes and thus reserves this once in the outgoing and once for
the incoming buffer.
For more information on the new network stack, see our paper on
http://arxiv.org/abs/1502.01968 and the minutes from the meeting in February:
There is also most of the functionality already out there on Github as Pull
Am I correct in thinking that the IPv6/6lowpan/UDP/TCP/RPL stacks are fairly
complete but there is quite a bit missing at the 802.15.4 mac layer such as
beacons and security? I assume this will increase the code size of RIOT?
Yes, this assumption is mostly correct. The biggest limitations for the upper
layer stack are:
- In the current version, 6LoWPAN and IPv6 are mostly entangled and therefore
IPv6 cannot be used standalone.
- Without support for multiple radios on one board, similar to Contiki, the
border router will work only over stdio over a serial port (and haven't
been tested for quite a while).
- Only the basic TCP feature set is implemented. Due to memory constraints,
the window size is fixed to one.
However, as I said before, we can expect rather a _de_creasing code size for
the new version of the network stack, eliminating these shortcomings.