[riot-notifications] [RIOT-OS/RIOT] Proposal: eSAUL - Extended Sensor Actuator Uber Layer (#14121)
notifications at github.com
Tue May 26 22:18:03 CEST 2020
> As I understand, we already plan on having a thread that polls any sensors for which there are subscribers.
Is there really a use case for this? If I want periodic sensor readings, wouldn't the exiting timer API already fit the bill quite nicely? Every subscriber in this scheme likely has different requirements for the reading frequency anyway.
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.
> it works well if large messages are to be sent to multiple receivers
Sending a message involves copying the pointer/value union (4 bytes), the type of the message (2 bytes), and the sender's pid (2 bytes). The actual content the pointer in the message is pointing to is not transferred. The context switch between threads is also quite light weight. And as I expect events being posted from IRQ context anyway, the context switch is hard to avoid any. (Or do we want the subscribers to be potentially run in IRQ context?)
Being honest: All the IPC mechanisms available should be more than fast enough for whatever events the average sensor can generate. The only case I can imagine a sensor is indeed causing many events at a high frequency is an button without proper de-bouncing. And if we would ship an eSAUL button implementation without de-bouncing, the first thing any user would do is opening an issue complaining that the de-bouncing of the button is broken.
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