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

chrysn notifications at github.com
Mon May 25 15:57:16 CEST 2020

I agree that this should be IPC-based to better manage stack sizes.

In the light of the gcoap wrapping, the IPC messages could be level-based. (And without any processing in the interrupt handler or an overflowable queue, I think it always is). In that case, it might make more sense to not use messages, but to register a (PID, flag) combination to a SAUL sensor, and define the receiver's reaction as "clear the flag, and read the value".

Would it make sense to have a `saul_notify_poll` function that processes all SAUL registrations and sends the messages / sets the flags? Having them in a task may then just be a convenient default.

Would such a call be necessary in all cases? I figure that most drivers (all as currently implemented) would just store their last values and set the flags, but some drivers might expose additional members on their driver structs for `registration added` and `registration removed` and just set up interrupt handlers to set the flags in those cases, to the point where they don't need a thread / periodic calling any more. (As I understand the current proposal, this would be an afterthought and out of scope, but I'd like to have that confirmed.)

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/20200525/327c3d21/attachment.htm>

More information about the notifications mailing list