[riot-notifications] [RIOT-OS/RIOT] doc/rdm: RFC - design goals (#10162)
notifications at github.com
Fri Feb 1 13:40:29 CET 2019
kaspar030 commented on this pull request.
+Modules outside the core should leverage the benefits and address the
+programming challenges of such a scheduler. They shouldn't demand that users do
+the same. They should, however, allow users to manage power through different
+modes and functions.
+#### Small memory footprint
+Most of RIOT's targeted use cases are well addressed by devices in class 1 of
+the taxonomy presented in . If small price differences are important or the
+energy budget is particularly tight, the available memory might be near the
+bottom of this class. Over-the-air updating currently reduces the available ROM
+by over half.
+RIOT should provide out-of-the-box support for devices with ~10 KiB of
+available RAM and ~100 KiB of ROM. It should be just as possible to address
I think we're looking at this from the wrong angle. We're trying to make "there are valid uses cases on 2kB AVR" fit with "our main focus is IoT on class 1 upwards" thinking. I'm not sure we can converge on a "primary use case" as in "class 1 IoT", which I personally just consider as one of the many uses of RIOT. So how about we explain that RIOT's memory usage *depends* and give examples of actual applications:
How about something like this:
Apart from being optimized for low memory usage, RIOT tries very hard to be as modular as possible so unused features don't use up precious RAM or flash. Almost all features are provided as optional modules that have to be enabled explicitly at compile time.
A minimal RIOT configuration starts at around <2KiB flash and <1.5KiB RAM (including stack space for one thread and ISRs).
Starting from there, the memory usage depends on the enabled features:
- non-networked control loop / sensing applications can fit on very small MCUs (eg., an Atmega328P with 2KiB RAM)
- 6lowPAN networking currently starts at ~10KiB RAM
- a file system adds X kB
- security, OTA Z KiB (might want to link the coming OTA paper for numbers)
- use of C library (it's huge) vs use of more optimized libs (printf vs. fmt)
- a 6lowpan/RPL enabled CoAP server with secure OTA enabled needs xx KiB RAM, yy KiB flash
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications