• State Verified Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 25 subscribers
  • Views 123 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 289143
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Best way to implement polling in the event manager

user109668

Hi there,

We are developing an nRF52832 based product based on the CAF and Event Manager that requires, among other things, regular reading of sensor data and running control loop calculations based on the readings.

What do you suggest is the best way to implement this form of polling? The event manager docs (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/libraries/others/app_event_manager.html) don't suggest any way to regularly emit events.

The nrf Desktop application uses k_work_reschedule in the battery_meas.c to achieve this. However, I thought Workqueue threads are for work that's not time critical?

We were planning on having one of the module spin up a separate thread to regularly submit events, similar to what nrf Desktop does in the motion_sensor module. Any thoughts would be appreciated!

Thanks,
Mark

Parents
  • 0

    Hello

    If your sensor allows it I would set it up to take measurements at the frequency you'd like, and let it generate an event through a gpio interrupt when new data is ready. If your sensor can't do that, then your best option is probably just to generate events through timer interrupts.

    You are correct that workqueue threads are typically used to process non-urgent work, but depending on how much else is going on in your application it could possibly work well. If your application is running several different threads and all you want is to pass sensor data to a high priority thread doing control loop calculations, then maybe Zephyr's Queue could work?

    Best regards,

    Einar

Reply
  • 0

    Hello

    If your sensor allows it I would set it up to take measurements at the frequency you'd like, and let it generate an event through a gpio interrupt when new data is ready. If your sensor can't do that, then your best option is probably just to generate events through timer interrupts.

    You are correct that workqueue threads are typically used to process non-urgent work, but depending on how much else is going on in your application it could possibly work well. If your application is running several different threads and all you want is to pass sensor data to a high priority thread doing control loop calculations, then maybe Zephyr's Queue could work?

    Best regards,

    Einar

Children
  • 0 in reply to user111520

    Hello Einar,

    This is very useful, thank you!

    We've gone with a high priority thread for now, sleeping using k_sleep for the required time since the last sleep, but it's not an ideal solution. We'll look at moving it over to using timer interrupts in the future

    Thanks,
    Mark

Related
Terms of service