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

Juergen Fitschen notifications at github.com
Wed May 27 16:07:08 CEST 2020

> > > 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.

I would allow subscriptions for every sensor. But only those implementing eSAUL are going to notify at some time.

The question *what* triggers a notifications is TBD. I would let the driver's programmer decide when to trigger a notification but give some advise in terms of best practices.


I'll come up with a PoC and create some facts we can work with.
Because the decision which kind of IPC to use for notifications seems to be very controversial, I'd suggest to implement the linked-list of callbacks, first. This way, we can try this driver with messages, events, flags, ... easily.

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/9ddde8c0/attachment.htm>

More information about the notifications mailing list