Real time control loop with softdevice S140 and nrf52840.

[Sietse]

Hello List,

I have a use case where i need to control 2 DC-motors using a PID-controller.
The system is to be controlled via BLE, using a nrf52840 with softdevice S140.
As a starting point I used the ble_app_uart example, where instead of the UART I use the scheduler to process the incoming "commands"
in main mode.
The motor is started/stopped/positioned via these commands.
The PID control loop is simple and does not take much time, but is to run at 100 Hz, so I need a timer for that.
Each motor is controlled via 2 gpio pins for on/off/direction and 1 gpio with pwm for motor speed.
There are 4 encoder pins, 2 of which are to trigger a (simple) interrupt routine.

The question is whether running a 100 Hz loop is feasable with the S140 also running.
The communication over BLE is only occasionally and the motor control is only important while there is NO communication with
BLE from the controlling device (smartphone).
In that situation I could tolerate a jitter of 1 to 2 msec
Is this a feasable number?

Thanks in advance,
Sietse

PS. Note that while controlling the motors, power consumption of the cpu is not an issue.

[run_ar]

Hi,

Details on the SD Interrupt model and processor availability.

If you run the SD and the pid needs the cpu you will have conflicts if they are both active at the same time. I.e. in case the SD is advertising, scanning or in a connection.

If you are not running the PID while the SD is active, you should not see any issues as you say. Just remember to run your motor control at highest priority.

If you want the PID to have priority over the SD this is also possible by redefining the interrupt priorities. However this could lead to timing issues in the SD and possibly make it assert.

[Sietse]

Thanks for the response.

I added a timer to the app using app_timer_create and made it run each 10ms.

I logged NRF_RTC0->COUNTER in an array for 20 seconds and printed it afterwards.

The counter values change 328 each and every time, even when I send some data over BLE. I couldn't measure any jitter with this timer, or at least less than 0.1ms. It seems to work perfectly, although I still can't believe that it works this perfectly.  So it seems entirely feasible.

[Sietse]

Upon closer examination there were a few deviations from 328 that more or less corresponding to the BLE communication, but not more than 3, so about 0.1ms. I now assume that is perfectly possible to get a control loop of up to 1000Hz under these circumstances.