refactor(radio): move per10ms() to a software timer

[raphaelcoeffic]

This helps reducing the pressure on the timer queue.

[philmoz]

How accurate / consistent will this be?

Could this adversely affect the 'g_rtcTime' variable that is updated every second in the per10ms() function.

If the interval between calls is not exactly 10ms then g_rtcTime value will not accurately reflect the time.

[raphaelcoeffic]

How accurate / consistent will this be?

No different from what we're doing right. The current implementation schedules the per10ms() functions to be called from within the timer task when the HW timer hits.

This PR just replaces the async scheduling with a fixed timer call, which reduces the pressure on the timer task's request queue. As far as I could see, this is really no different from the previous implementation, except that it the timer task's queue is not flooded in case the timer task is not scheduled as often as required.

[philmoz]

Thanks.
I asked because I worked on a commercial project where the original dev used a timer callback to increment a count to measure elapsed time. It was highly inaccurate because the timer callback interval was not guaranteed. The kicker was this was on code running on a smart watch. Needless to say I threw all this out and let the watch tell me the time.

[3djc]

It is just used to fire things "from time to time", not at all for timing related activities, so inaccurate timing is no issue there

[raphaelcoeffic]

@philmoz @gagarinlg @pfeerick @3djc we'd need to decide whether or not to include this in 2.11. If that is not the case (and it's really not necessary as of now), I'd squash it with the rest of #5840 and keep only that PR open.

[3djc]

3.0 is the way to go imho

[gagarinlg]

There are a couple of users having issues with 2.11 and switches not working or UI not working. Could this solve those issues?

[3djc]

Per10ms don't handle those, so very unlikely

[raphaelcoeffic]

Closed in favour of #5840