-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PoC] Reactive SAUL: saul_observer based on callbacks #16277
base: master
Are you sure you want to change the base?
Conversation
After a week, I've successfully built a system based on this driver:
The main benefit brought to me by this driver is the ability to get notified on SAUL device state changes (i.e. someone pressed that switch ...). I can react on this event and turn on the LED for instance. I'm going to test flight this system in my home automation setup. I wrote an adapter to the client mentioned above. The switch es are now glued to the desk and can be used to turn on the printer and the PC. My flatmates are already making fun of me, since the project turn on the printer and a LED by pressing a button took me way tooo long :D The switches under the deskThe Raspberry Pi with its network interface attached and covered with too much dust (sry!) |
I extended the DHT sensor driver to demonstrate how an analog sensor - in this case temperature and humidity - could be made observable. It uses the Works like a charm:
|
5eee0c9
to
008352f
Compare
Cross post from #14121 I think my proof of concept is in a good state for talking about its architecture. I try to give you an overview. It should help to get into its code and design:
Frontend
Backend
To evaluate the concept, I've ported two drivers ( I'd like to hear your opinion on this design. At the current stage I need to know if I'm heading in the right direction. If I'm not the only who believes this is a good way to solve the problem we were bikeshedding about, I'm going polish the PoC and bring it into RIOT with some PRs. The first one will be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
saul_observer
is powered by its own thread.
Isn't it possible to use event_thread
for this? Each additional thread needs its own stack. You can make the event queue configurable to allow users to still run it in a dedicated thread, if the three-level priority management of event_thread
is to course grained for a specific use case.
drivers/Makefile.dep
Outdated
else | ||
FEATURES_REQUIRED += periph_gpio | ||
endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
else | |
FEATURES_REQUIRED += periph_gpio | |
endif | |
endif | |
FEATURES_REQUIRED += periph_gpio |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
Great idea! TBH I wasn't aware of the existence of For the PoC I'm going for hard-coded |
Are there any further remarks or comments on the proposed architecture? |
2bf0d5f
to
fb2e305
Compare
Please do so! |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
Contribution description
After almost a year - sorry for the long delay - I finally managed to put some time into the promised alternative implementation for #14121. This PR is a proof-of-concept to play around with the concept. With some aftermath, this can be cleaned up for a merge into master.
The main differences to #14182:
utils.c
)msg_t
which may fail to be delivered.check
function inside ofsaul_driver_t
isn't mandatory anymore. If it's not implemented (i.e.NULL
), every SAUL event will make it to the registered callbacks.This way, everyI added a flag that can be returned by theSAUL_ACT_*
is observable by default! If it's being written, observers will be notified!read
andwrite
implementation indicating that thecheck
function shall be called.Testing procedure
Flash
tests/saul_observer
onto a board withsaul_gpio
support and play around with the registered SAUL devices. You should see some change notifications.Issues/PRs references
#14121
#14182