Zephyr work queue and interrupt

RE: Zephyr work queue and interrupt

embeddedER — Thu, 07 Jul 2022 16:42:13 GMT

Thanks Einar. We are using normal sleep/idle mode. So, as you suggest, should not affect the power consumption.

I shall check and get back to you if I've more questions here.

TIA!

RE: Zephyr work queue and interrupt

Einarh — Tue, 05 Jul 2022 09:24:26 GMT

Hello!

I assume that by deep sleep you are referring to System OFF mode?

In that case no threads are running while in System OFF mode and on wakeup the system is reset, so waiting for a semaphore in deep sleep wouldn't make much sense.

If you are referring to normal sleep/idle mode, then waiting for a semaphore would not consume more power than just idling, and would be the recommended way to wait for an interrupt in a power constrained system.

Best regards,

Einar

RE: Zephyr work queue and interrupt

embeddedER — Fri, 01 Jul 2022 20:08:15 GMT

Hi Sigurd,

Thanks. semaphore is what I was thinking to use for synchronization, however, it will still need my thread to be created at the start and then it will always be running in wait state. Since, most of the time we are in deep sleep, I was thinking to start the thread only when needed and then stop it completely (rather then waiting) when not needed.

Does thread waiting for semaphore in deep sleep consume more power?

TIA!

RE: Zephyr work queue and interrupt

Sigurd — Fri, 01 Jul 2022 09:14:33 GMT

[quote user="harshal034"]We are particularly looking for a way to get around starting a thread before the interrupt arrives. And we want our worker thread to initiate as soon as first interrupt arrives.[/quote]

Maybe you can use a semaphore. At the start of the processing function:

k_sem_take(&waiting_for_irq, K_FOREVER);

in the irq:

k_sem_give(&waiting_for_iq);

RE: Zephyr work queue and interrupt

embeddedER — Mon, 27 Jun 2022 18:50:51 GMT

Hi Sigurd,

Thanks for the reply.

For our case, we need to know the pulse duration between every PWM pulse and make some necessary decisions. Our PWM duration is in milli seconds range (10-100).

We already have a code developed and tested that can calculate every PWM pulse duration and calculate the moving average and diff of pules. Currently, how we do this is, we start a thread first that does processing of this Pulse difference data and then we enable the interrupt. This works fine. PPI example, more or less does same thing.

However, since we have a battery operated device, we are in deep sleep mode by default and we want our system to wake-up when first interrupt arrives and at the same time we want to start that processing thread. However, as I mentioned above we can't start the thread from the interrupt context and if I submit a system Queue from the interrupt context, it kicks of the thread after several seconds.

We are particularly looking for a way to get around starting a thread before the interrupt arrives. And we want our worker thread to initiate as soon as first interrupt arrives.

TIA!

RE: Zephyr work queue and interrupt

Sigurd — Mon, 27 Jun 2022 07:49:38 GMT

Hi,

Not sure what's the signal frequency and the accuracy needed for your application here, but using PPI+TIMER+GPIOTE is likely the better option here. Here is some code that you can use as a template. https://github.com/sigurdnev/ncs-playground/blob/master/samples/pulse_detector/src/main.c (orginally based on the code in this post PPI Configuration to Count Pulses )