[riot-notifications] [RIOT-OS/RIOT] doc/rdm: RFC - design goals (#10162)

Matthias Wählisch notifications at github.com
Thu Jan 31 00:20:19 CET 2019


waehlisch requested changes on this pull request.

Further comments will follow.

> +## 2.8. Education
+
+The broad technical scope of RIOT makes it useful as a basis for education.
+This requires:
+
+  - The presence of didactic materials related to RIOT
+  - Clear and easy to find documentation
+  - A general availability of supported hardware and tools
+
+# 3. Design philosophies
+
+RIOT satisfies the requirements of all the use cases given above, and does so
+in its own unique way, a way that reflects the collective personality of the
+RIOT community. RIOT is the Friendly IoT Operating System: it is friendly to
+users, allowing them to easily build and deploy IoT solutions that are stable
+and trouble-free.

You should also explain why RIOT is friendly to developers.

> +  - Include and support any relevant hardware
+
+## 2.8. Education
+
+The broad technical scope of RIOT makes it useful as a basis for education.
+This requires:
+
+  - The presence of didactic materials related to RIOT
+  - Clear and easy to find documentation
+  - A general availability of supported hardware and tools
+
+# 3. Design philosophies
+
+RIOT satisfies the requirements of all the use cases given above, and does so
+in its own unique way, a way that reflects the collective personality of the
+RIOT community. RIOT is the Friendly IoT Operating System: it is friendly to

s/and does so in its own unique way, a way that reflects the collective personality of the RIOT community./ based on rough consensus within the RIOT community to reflect the collective personalities of the RIOT contributors and users./

> +  - Control various specific actuators such as motors, solenoids, or valves
+  - Collect and send data with a low latency, or at least a well synchronized
+    timestamp
+  - Potentially have a very low unit cost, particularly when the networks are
+    implemented in mass market products such as automobiles
+  - Potentially run control algorithms themselves.
+
+## 2.5. Edge systems for building management and automation
+
+Various sensing and environmental control tasks can be done by edge nodes in
+buildings. The nodes need to be able to:
+
+  - Sense temperature, light, humidity, pressure, current, etc
+  - Control temperature, light, ventilation, etc
+  - Connect to the building management system, via wired or wireless connectors
+  - Deliver data with controllable timing and accuracy.

Punctuation is inconsistent in the list of items. You probably should finish each item with a ".".

> +#### Energy efficiency
+
+RIOT nodes sometimes need to last for several years without external power, so
+they need to manage energy carefully. RIOT's tickless scheduler lets devices
+sleep while they aren't collecting data.
+
+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 [1]. If small price differences are important or the
+energy budget is particularly tight, the available memory might be near the

Gap in argumentation: Why does a tight energy budget directly correlate with tight memory?

> +available ROM by over half, depending on the architecture.
+
+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
+real use cases involving even smaller devices, starting at ~2 KiB of RAM and
+~10 KiB of ROM, via manual configuration, and via modules which prioritize
+memory efficiency in their design without of course departing from any
+specifications that are used to describe the module.
+
+#### Constrained networking
+
+RIOT should deliver best-in-class communication performance and robustness.
+
+Network stacks should remain up-to-date as relevant standards emerge; they
+should be adequately extensible to support this. Users should be able to
+configure them according to technological options, and choose between

s/to technological options/to their needs/

> +available RAM and ~100 KiB of ROM. It should be just as possible to address
+real use cases involving even smaller devices, starting at ~2 KiB of RAM and
+~10 KiB of ROM, via manual configuration, and via modules which prioritize
+memory efficiency in their design without of course departing from any
+specifications that are used to describe the module.
+
+#### Constrained networking
+
+RIOT should deliver best-in-class communication performance and robustness.
+
+Network stacks should remain up-to-date as relevant standards emerge; they
+should be adequately extensible to support this. Users should be able to
+configure them according to technological options, and choose between
+high-quality implementations which address performance tradeoffs differently.
+They should be able to get the best performance and most relevant functionality
+out of whatever resources they have available.

I'm not sure if I can follow the argumentation. Most aspects are not specific to the networking subsystem in RIOT but might be applied to other parts in RIOT as well.

Regarding networking, I think we want to express that RIOT considers constrained environments but that RIOT values interoperability (for the sake of inter-connectivity = IoT) more than saving one bit. Do we agree on this?



> +Above the HAL, the only thing that modules should know about hardware is
+whether its build dependencies are provided or not. If they aren'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. Sensing and control
+applications which do not require hard real-time guarantees are also supported.
+
+RIOT should deliver soft real-time guarantees which address the use cases given
+in section 2. It should provide timers which can competently handle the
+timescales of any application.
+
+## Interoperability

Why is interoperability limited to networking? What about I2C, USB etc.?

> +
+## Modularity
+
+Logical separation of the different modules of RIOT enables a highly distributed
+community to separate development work while reducing the risk of knock-on
+effects across the system. It also allows third parties to develop modules,
+expanding development efforts from just the RIOT community and repo. There is a
+balance to be struck, however: too fine-grained can come at a cost of
+unnecessary complexity, higher resources, and difficulty of understanding.
+
+## Independence of the underlying hardware
+
+Development should be able to be done once and run on any platform using RIOT.
+To achieve this with reduced development effort in porting, the hardware is
+abstracted and the APIs are uniform at as low a level as possible.
+

I'm not sure if I like the order of the subsections. For example, the current text in "Versatility" reads like high-order insights that should be moved to the beginning of this section.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/10162#pullrequestreview-198348277
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190130/7df12fd7/attachment-0001.html>


More information about the notifications mailing list