Mbed OS Reference
Loading...
Searching...
No Matches
wait_api functions

Functions

void wait_us (int us)
 Generic wait functions. More...
 
void wait_ns (unsigned int ns)
 Waits a number of nanoseconds. More...
 

Detailed Description

Function Documentation

◆ wait_us()

void wait_us ( int  us)

Generic wait functions.

These provide simple NOP type wait capabilities.

Example:

#include "mbed.h"
// Blinking rate in milliseconds
#define BLINKING_RATE_MS 500
DigitalOut led(LED2);
InterruptIn button(SW2);
void blink_led() {
led = 1;
wait_us(BLINKING_RATE_MS * 1000);
led = 0;
}
int main() {
button.fall(&blink_led);
while(1) {
// Do nothing
}
}
void wait_us(int us)
Generic wait functions.

Waits a number of microseconds.

Parameters
usthe whole number of microseconds to wait
Note
This function always spins to get the exact number of microseconds. This will affect power and multithread performance. Therefore, spinning for millisecond wait is not recommended, and ThisThread::sleep_for should be used instead.
You may call this function from ISR context, but large delays may impact system stability - interrupt handlers should take less than 50us.

◆ wait_ns()

void wait_ns ( unsigned int  ns)

Waits a number of nanoseconds.

This function spins the CPU to produce a small delay. It should normally only be used for delays of 10us (10000ns) or less. As it is calculated based on the expected execution time of a software loop, it may well run slower than requested based on activity from other threads and interrupts. If greater precision is required, this can be called from inside a critical section.

Parameters
nsthe number of nanoseconds to wait
Note
wait_us() will likely give more precise time than wait_ns for large-enough delays, as it is based on a timer, but its set-up time may be excessive for the smallest microsecond counts, at which point wait_ns() is better.
Any delay larger than a millisecond (1000000ns) is liable to cause overflow in the internal loop calculation. You shouldn't normally be using this for such large delays anyway in real code, but be aware if calibrating. Make repeated calls for longer test runs.
You may call this function from ISR context.