[riot-notifications] [RIOT-OS/RIOT] Proposal: eSAUL - Extended Sensor Actuator Uber Layer (#14121)
notifications at github.com
Tue May 26 11:31:53 CEST 2020
> > > Also, the filtering feature of the message bus would be nice to exploit. However, there are way more sensor and actuator types than 32. Maybe just filter by class (so subscription needs to be done separately for sensors and actuators)? Some convenience function could be provided that filter the received messages by `saul_driver_t::type` on the calling side.
> > Or map the `saul_reg_t` pointer address to a number in the interval 0..31? Collisions may occur, but this would lead to a pre-selection und reduces noise. (Some kind of bloom filter?!)
> We can know at compile time which sensor types are available (sensor drivers would have to select a pseudomodule then for which types they enable).
> Then it would be no problem to have a separate bus for each sensor type.
Hmmm, the separation per sensor type assumes that in most use cases only one sensor type is present. I think this assumption falls apart if GPIOs, ADCs, ... are modeled as sensors. I still prefer the bloom filter idea. We have to deal with collisions anyway.
Another problem appears if a thread wants to unsubscribe from update events. It must keep track of, whether the event type is used by another sensor.
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