[riot-notifications] [RIOT-OS/RIOT] doc/rdm: RFC - design goals (#10162)
notifications at github.com
Wed Jan 30 16:47:11 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
+1 for removing ""Users should be given the choice of what they want to spend their memory on."
Other than that, I don't understand the aversion to supporting low-end embedded devices.
To me RIOT is the first choice for creating *any* application involving MCUs. I do choose it even on the smallest supported platforms (e.g., Arduino Uno, with 2kB of RAM), e.g., for simple Arduino-style control tasks. For reference, hello-world on that board uses ~1250B RAM, so there's room to spare for quite some control logic.
While on a board that small I can certainly not enjoy RIOT's awesome networking options, many of RIOT's perks make it a valid first choice (even compared to the Arduino libraries):
- nice and compact periph APIs
- portability (upgrade path) to other (larger) MCUs using the same application code
- large collection of supported sensors (with similar, familiar APIs)
I don't see why using RIOT on those systems is only possible "with manual optimizations and specialized modules".
It all depends on the application, but RIOT is a good fit for ~2kB RAM systems for use in control tasks (which means basically anything that the supported Atmega 328p is capable of). Why state otherwise in the design goals?
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