[riot-notifications] [RIOT-OS/RIOT] doc/rdm: RFC - design goals (#10162)
Thomas C. Schmidt
notifications at github.com
Tue Jan 29 23:18:27 CET 2019
tcschmidt commented on this pull request.
> +Above the HAL, the only thing that modules should know about hardware is
+whether a required feature is there or not. If it isn't, the module should
+adapt accordingly, or not compile.
+## Real-time capabilities
+Different real-time guarantees are required for different use cases. Low
+frequency sensing needs only soft real-time support and can handle less timing
+accuracy so long as the timers support long timescales. High-frequency sensing
+and control applications need hard real-time guarantees and sub-millisecond
+RIOT should deliver soft real-time performance by default, to cover the widest
+range of use cases. Programs with hard deadlines should be achievable with more
+expertise. It should provide timers which can competently handle the timescales
+of any application.
If I'm not mistaken, the system interface does not allow to specify a deadline of a thread ... as the scheduler is not deadline-aware. So I wonder how this could be done?
+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
Well, to me this discussion is artificial and a statement "with manual optimizations and specialised modules" IMO does not serve well as guidance for developing a versatile, multi-purpose OS.
I would still propose to remove at least the last sentence - "Users should be given the choice of what they want to spend their memory on." - because this is an empty phrase given that a desired function comes at a minimal cost.
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