Limits to software quadrature decoder with nrf52840 with softdevice.

RE: Limits to software quadrature decoder with nrf52840 with softdevice.

Sietse — Mon, 04 Jan 2021 11:07:10 GMT

Thanks for the help!

I wasn't able to mark you last reply as the correct answer, but this will do I guess.

RE: Limits to software quadrature decoder with nrf52840 with softdevice.

Einar Thorsrud — Mon, 04 Jan 2021 09:02:43 GMT

Hi,

[quote user="Sietse"]

I found the reason for the long delay, I think!

During debugging I did set the gcc optimalisation to -O0. Setting it to -O3 again made the time drop to a little less than 5 msec.

[/quote]

Ah, good news. That could make sense.

[quote user="Sietse"]Is it possible for force there to be NO low power mode when the motor is used, so programmatically? That would hopefully reduce the latency even further![/quote]

Yes. A typical SoftDevice application enters system ON low power mode by calling sd_app_evt_wait() in the main loop, either directly or via for instance nrf_pwr_mgmt_run(). To not enter a low power mode, simply do not call any of these functions in the main loop (so here you could check if the motor is in use, and only enter low power mode if it is not).

Happy New Year!

RE: Limits to software quadrature decoder with nrf52840 with softdevice.

Sietse — Wed, 23 Dec 2020 12:52:21 GMT

I found the reason for the long delay, I think!

During debugging I did set the gcc optimalisation to -O0. Setting it to -O3 again made the time drop to a little less than 5 msec.

When the motor/encoder is to be used, there is no need for a low power mode because the motor is already consuming a lot. Is it possible for force there to be NO low power mode when the motor is used, so programmatically? That would hopefully reduce the latency even further!

Thanks in advance and happy holidays!

RE: Limits to software quadrature decoder with nrf52840 with softdevice.

Einar Thorsrud — Tue, 22 Dec 2020 12:19:56 GMT

Hi,

I see. So you are measuring (with a logic analyzer or similar) the time from a change on a GPIO input to a change on a GPIO output? If so, 20 ms is much, I agree. If the device is in system on low power mode (after a call to sd_app_evt_wait() or _WFE()) the HFINT clock needs to be started, which adds about 4 ms. There are also some microseconds for CPU startup etc, and some CPU cycles for your logic. But it should not add up to anything close to 20 ms.

Can you share a project that reproduce this so that I can test on my side? Please note that I will be off for Christmas holiday until beginning of January though, so my next reply will probably be delayed until then.

RE: Limits to software quadrature decoder with nrf52840 with softdevice.

Sietse — Mon, 21 Dec 2020 14:56:09 GMT

Thanks for the reply.

I am not using QDEC, now only testing the software encoder using 2 gpiote interrupts.

From 'Interrupt latency due to SoC framework' I read that there is up to 4 microseconds latency to be expected. Why am I seeing 20 microseconds? I would have thought that only a gpiote interrupt has to be redirected to the app.

What am I doing wrong here. Nothing is happening: the softdevice is "idling" in the connected state and there can be 2 interrupts from the encoder signal. Nothing more.

RE: Limits to software quadrature decoder with nrf52840 with softdevice.

Einar Thorsrud — Mon, 21 Dec 2020 10:21:42 GMT

Hi,

I am not entirely sure I understand the question or context. How have you configured the QDEC? The sample period is important here, and the shortest period you can configure is 128 us. There is no way to get higher time resolution then that.

Though that may not be relevant, you can see the duration of time the SoftDevice will block the application from the SoftDevice specification under Processor usage patterns and availability.

RE: Limits to software quadrature decoder with nrf52840 with softdevice.

Sietse — Sun, 20 Dec 2020 16:38:44 GMT

Further investigation with scope and logic analyzer reveals that the encoder signals are not clean. When running faster they probably create the problems. So probably a problem in my hardware setup, sorry.

But I would very much like to understand the issues with the delays I mentioned. What is happening during the 20 microsecond? This to learn whether it is feasible or not, having very short interrupts every, say, 200 or more microseconds.

And why is it so constant? This suggests that it has nothing to do with a busy softdevice. Note that the testing is done while connected with bluetooth and no communication over bluetooth, so i would imagine the softdevice is more or less at "rest".

I tried the tests with the gpiote interrupt levels 6 and 2. Thanks again.

RE: Limits to software quadrature decoder with nrf52840 with softdevice.

Sietse — Fri, 18 Dec 2020 10:29:22 GMT

It is a but more complicated. When using a gpio in the handler and a scope I see that all interrupts are coming through!

There is a constant delay from the encoder edge and the toggling of the gpio of 20 microseconds. And it occasionally jumps to 150 microseconds.I find the constant 20 microsecond a very long and also strange that it is so very constant, but for my use case it is ok. The minimum distance between encoder interrupts is 200 micoseconds, so it could work.

I will first investigate further.