[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:
https://github.com/RIOT-OS/RIOT/issues/14121#issuecomment-633585261
-------------- 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