[riot-notifications] [RIOT-OS/RIOT] Proposal: eSAUL - Extended Sensor Actuator Uber Layer (#14121)

chrysn notifications at github.com
Wed May 27 15:18:54 CEST 2020

> "1 sender to n receivers" pattern

That is a good point, but as I've outlined msg is probably unsuitable. That may illustrate that there is some need for a more generic "dispatch to multiple handlers" tool that's not limited to using the message bus -- or we're just seeing the single instance where that's needed, hard to tell.

> > As I understand, we already plan on having a thread that polls any sensors for which there are subscribers.
> To me, this notification makes only sense for sensors like a motion sensor, a button, etc. which does create IRQs that are translated into higher level event notifications.

Ok, I thought that this interrupt-based thing would be an afterthought only -- fine if it's the main mode of operation. That definitely makes things easier on the side of later obtaining the most recent value from the sensor -- as that's then just a read from the memory location that gets updated in the interrupt.

So a sensor that doesn't push values in interrupts would just not accept subscriptions? That would be the most lightweight thing -- provided it fits the use case for eSAUL.

> Or do we want the subscribers to be potentially run in IRQ context?

The xtimer / sock_async approach would in allow the subscriber to run something in the IRQ context, but it would very much be recommended that it'll be only "Release the given mutex", "Set the given thread flag", "Wake the given thread", "Set the given event" or "Send the given message" or a similarly small one. (In xtimer, the arbitrary-callback has [big red warnigns](https://riot-os.org/api/group__sys__xtimer.html#gadcc4acdd5b781fe1e8760503cfb635bb); in sock_async, the async API has no large warnings but the expectation seems to be that you use the event-based one which executes the "set the given event" callback).

> All the IPC mechanisms available should be more than fast enough for whatever events

The speed of the IPC mechanisms is not what's worrying me. The application's ability to use them reliably in light of fast notification streams compared to the application's update rate is what concerns me, and where approaches that have the message bus as the only way out of an event fall short.

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...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20200527/de64845a/attachment-0001.htm>

More information about the notifications mailing list