Hi Daniel, see inline some answers and ideas for your use case.
Kind regards, Marian On Fri, 30 Oct 2020 17:37:04 +0100 Daniel Beiter <daniel.bei...@gmx.at> wrote: > Dear RIOT OS community, > > I'm Daniel a PhD in Hydrology at GFZ Potsdam and currently working on a > data logger system for use in extensive field campaigns. As far as I > have understood, RIOT OS seems to be very suitable for the tasks I have > in mind. Since I am new to using an OS on microcontrollers (rather than > running simple single-thread applications), I would very much like to > discuss with a RIOT expert (or several) what is possible and what is an > illusion of my perception. Here are some points to give you a bit of an > idea what I mean: > > * Adding pre-compiled sensor driver packages to a running application > Let's say we have 20 stations running but with varying numbers and > types of sensors (e.g. sensors monitoring trees only in forests, > discharge sensors only at rivers, etc.). Is it possible to have a > common application running on all stations and adding/removing > pre-compiled sensor driver packages to change sensor setup? It would > allow easier on-site maintenance, where fast adding/removing sensors > would not lead to changing source code and compiling a new > application for one particular station (maintenance of course always > happens in winter, at night, with strong winds, heavy rain, in a > remote forest, hard to work on source code :) ). It would certainly be possible to use a common firmware that targets the "full-fledged" node, but flash it on nodes with fewer sensors plugged in. Our goal is that drivers perform during initialization a self check (usually read out manufacturer and device ID and compare it against the expected values) - if no such sensor is present, the initialization should return with an error code. So my proposal is to just let the firmware detect upon start up which sensors are present. Sadly, you will likely not be able to use auto initialization with that approach, as you really want to check the return value of the initialization to verify if the sensor is available and functional. (Well, you could use SAUL with auto-initialization, as only successfully initialized sensors should be registered in the SAUL registry.) Note however, that it is pretty much impossible to detect hardware configuration at runtime due to the plethora of different and incompatible communication standards and the lack of any "plug and pray" protocols. So my suggestion would only work if for each sensor the configuration is known at compile time and each sensor can either be present in this very configuration, or being unconnected. But I fear that the test coverage for this scenario is not too well, so be prepared to file a few bug reports regarding the self checks. (I expect some drivers to still initialize even without hardware present, and some other drivers to infinitely loop while trying to communicate with non-existing hardware.) > * Having a web interface running, accessible via Ethernet or BLE (for > on-site maintenance) and remote (e.g. via LTE CAT M1/NB1 for > administration) to allow configuring sensor setup (number and type) > as well as general configuration (measurement interval, time of data > upload, etc.) > A simple graphical web interface would ease the maintenance for the > technician as he would "only" need to change configurations rather > than changing source code and compiling (see point above). Since I > am working currently with OpenMediaVault, I really appreciate their > web interface concept, with the possibility to revert all currently > made changes. That would certainly be possible to implement on top of RIOT. I'm unaware of anyone running an HTTP server on RIOT, but that shouldn't be too difficult to achieve. However, maybe a CoAP server would be a better option? By reusing the core concepts of HTTP based REST APIs (same message-response model, URIs, content formats (lightweight MIME Types), ...) CoAP can be trivially reached from HTTP by using cross protocol proxies that transparently translate between HTTP and CoAP. And you might be able to use the same CoAP interfaces for both human 2 machine maintenance scenarios as well regular m2m communication. Btw: lwm2m could also be something you might want to check out as an option for device management. > * All these configurations would need to be stored locally, I imagine > as JSON on an EEPROM with some kind of file system. Is this how it > is done in general? Usually the overhead of file systems is considered to be too huge for EEPROM devices. RIOT has the EEPROM registry module that works well as a low-overhead key value storage - which could be viewed as a primitive non-hierarchical file system. That should actually be quite a good match for storing configuration data. If you want to go with an actual file system, you're likely better off with flash memory or SD cards as storage. You might want to look at CBOR as alternative to JSON. It uses pretty much the same data model as JSON, but is more efficient in terms of storage and in terms of parsing overhead. Same as CoAP and HTTP, you can just convert data between the formats (with some limitations), but generally CBOR should be better suited for constrained devices. > * All configurations should also be synced with the remote server > (e.g. running ODM2) > > I hope these points make some sense even if the answer is: No, what you > want is not possible. And if not, I am happy to learn more. As mentioned > before, I would appreciate a discussion about this use case and the > potential use of RIOT OS with experienced people who find it > interesting. In case spamming the user list is not desired you can of > course contact me via my email address daniel.bei...@gmx.at Actually, I personally would like to hear more about how people are using RIOT or intending to use RIOT. Have this context information can be quite beneficial for making design decisions in RIOT - and hearing some success stories are quite motivating for the RIOT developers. So from my point of view you are very welcome to keep this discussion here. > > Enjoy your weekend and stay safe > Daniel >
pgpQI9mtV6GDR.pgp
Description: OpenPGP digital signature
_______________________________________________ users mailing list users@riot-os.org https://lists.riot-os.org/mailman/listinfo/users
