Hi Simon! > 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 > IPv6/6lowpan/802.15.4 stack. > > 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: https://github.com/RIOT-OS/RIOT/wiki/minutes-network-task-force-feb-2015 There is also most of the functionality already out there on Github as Pull Requests. > 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. Cheers, Oleg -- printk ("Barf\n"); linux-2.6.6/arch/v850/kernel/module.c
pgppxxts9bQVP.pgp
Description: PGP signature
_______________________________________________ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
