Know when the softdevice / Interrupt took control

RE: Know when the softdevice / Interrupt took control

Einar Thorsrud — Wed, 12 Dec 2018 14:01:51 GMT

Hi,

What I meant is that reading the timer value and setting a variable does not take many CPU instructions. Then you have the interrupt latency which adds a bit. We are definitely talking about far less than 10 μs in this case.

RE: Know when the softdevice / Interrupt took control

yuval — Wed, 12 Dec 2018 13:51:42 GMT

Hi,

No, There is no flow control. I can't know when it transmit to me.

About the 2nd question: what do you meen by "not take many instruction"?

Is it up to 10us? 50us? 100us? I don't need very aqurate number from you but i need to know more or less how much time it will take...

RE: Know when the softdevice / Interrupt took control

Einar Thorsrud — Wed, 12 Dec 2018 13:22:16 GMT

Hi Yuval,

Why do you absolutely need to handle the UART transaction immediately? Does the master device not support flow control?

I don't have numbers for how long time your timer event would take, but it should not take many instructions per time.

RE: Know when the softdevice / Interrupt took control

yuval — Wed, 12 Dec 2018 12:39:03 GMT

Thanks,

But this not working for me since i'm the slave and not the master, so i don't know when the other transmitter sends it's data....(And i act according to the data)

Another question,

If i set a timer event for every 200 micro seconds, (f.e. Inside the event i have 1 line of code - advancing a counter)

How much time will be spent in going into the event, advancing the counter and return back to the regular program?

B.r, Yuval.

RE: Know when the softdevice / Interrupt took control

Einar Thorsrud — Wed, 12 Dec 2018 11:52:57 GMT

Hi Yuval,

Interrupts for the SoftDevice are not propagated to the application, except for in cases where the SoftDevice notifies the application about something in the form of an event by calling the registered event handler(s). Therefor the method of setting a flag in the application indicating that the SoftDevice has interrupted you will not work. However, that may not be needed as there are a few other options worth considering:

The application can use the Timeslot API to obtain a timeslot where it is guaranteed to not be interrupted by the SoftDevice. This API is intended to be used for implementing a second concurrent radio protocol, but it can be used for any situation where the application needs full control for a limited duration of time with a guarantee that there will be no SoftDevice interrupts.
The UART peripheral support DMA, so a SoftDevice interrupt will not affect an ongoing transaction. The CPU is only needed to set up the transaction. If I understood your use case correctly, this will circumvent the whole problem.

Br,

Einar