Unification of wait functions

[bogdanm]

This commit adds two implementations for the mbed wait functions (wait,
wait_ms, wait_us):

• with the RTOS present, the wait functions will use Thread::wait for
  millisecond delays and a busy wait loop for sub-millisecond delays.
• with the RTOS not present, the wait functions will always use a busy
  wait loop.

[bogdanm]

@sg- @0xc0170 @geky

Possible issues with this PR:

• wait_us will likely not have the same accuracy with RTOS and without RTOS.
• the mbed wait function takes a float that specifies seconds as argument, as opposed to Thread::wait that takes a uint32_t that specifies milliseconds. This can be potentially confusing.

[geky]

+1 This looks great to me!

Now that I think about it, won't the previous wait_us have the same accuracy issue with the rtos? Unless interrupts are disabled the busy loop could be prempted at any time.

[bogdanm]

You're right, any blocking function that relies on its blocking behaviour for timing will have a problem in a preemptive RTOS environment.
Another potential improvement would be to check if wait_us is called from an interrupt context and switch to blocking behaviour if it is (it might make sense to allow blocking wait behaviour in an interrupt context for short wait times).

[geky]

I think this may actually handle interrupt context correctly based on the implementation of core_util_are_interrupts_enabled:
https://github.com/mbedmicro/mbed/blob/5fea6e69ec1aec4c56852f2e959002dc815eb480/hal/common/mbed_critical.c#L28

[c1728p9]

you might consider having wait and wait_ms use Thread:wait exclusively, since the RTOS will get you very close to ms resoultion

[bogdanm]

That'd mean adding core_utils_are_interrupts_enabled checks to each wait function. Not sure this is needed.

[sg-]

LGTM 👍

[bogdanm]

Added a new commit that potentially improves the accuracy of wait_us, as suggested by @c1728p9