event queue timing resolution

[0Grit]

Description

Any particular reason equeue_mbed.cpp's timing is implemented only to a resolution of milliseconds?

Parts like RT1050 can be clocked upto 600Mhz.
Accuracy of time to actually executing the event at such resolution would obviously depend on where things are executing from (Flash/RAM/qspi/cache) and other factors, but is there a feasibility consideration I'm missing?

I don't have a need, just curious of design intent and do not see a design nor requirements doc for anything under mbed-os/events.

Issue request type

[x] Question
[ ] Enhancement
[ ] Bug

[cmonr]

Probably legacy reasons. Don't think we were use to using devices that could clock that high 😄

@geky Thoughts?

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-308

[kjbracey]

Any particular reason

Power, portability, practical need.

High resolution clocks take more power - to achieve high precision we'd have to keep them running, and make sure the CPU was only lightly asleep to wake promptly.

The event queue primary API is designed around "typical" needs, and uses the standard RTOS timing API that in principle permits deep sleep states, that potentially take 10ms to wake - wake latency adjustments in the RTOS port to compensate for this.

Very few people need timed events with precision greater than a millisecond - those that do can use the Timeout or Ticker class to schedule an event queue call with microsecond precision (just pass an event to its attach method).

If you do that, the running high-precision timer will stop the device going into deep sleep.

You would have to make sure the event queue is of a high enough priority to make it worthwhile scheduling something with that high precision - that a normal-priority task will be preempted. (Tasks with equal priority are round-robin scheduled at 5ms intervals).

[0Grit]

@kjbracey-arm thanks for the insight

What is your take if I'm taking the 'Minar' approach? I believe I would prefer to run RTOS-less for any fully asynchronous scenarios anyway.
Though I suppose that route would require event priority be implemented or alternatively prioritized queues through threading. Sleep lock/tuning might then be adjusted depending on if a high priority event has been queued or minimum event latency requirements.

Also, unrelated but had been looking for this information in the Mbed OS docs,

(Tasks with equal priority are round-robin scheduled at 5ms intervals).

but I couldn't find it anywhere.
Is this something I should go to the RTX docs for?

[kjbracey]

Currently optimal sleeping behaviour can only be achieved via the RTOS, as the logic is embedded in its idle handler. But the logic could be extracted and used otherwise.

We are also looking at a non-RTOS build profile, and that will likely restructure to pull that out and improve non-RTOS builds.

The 5 tick round robin is just RTX default - and Mbed OS specifies ticks as milliseconds. See RTX documentation for more info on its scheduling.