Mistake on this page?
Report an issue in GitHub or email us
Functions
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

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.
void wait_us ( int  us)

Generic wait functions.

These provide simple NOP type wait capabilities.

Example:

1 #include "mbed.h"
2 
3 // Blinking rate in milliseconds
4 #define BLINKING_RATE_MS 500
5 DigitalOut led(LED2);
6 InterruptIn button(SW2);
7 
8 void blink_led() {
9  led = 1;
10  wait_us(BLINKING_RATE_MS * 1000);
11  led = 0;
12 }
13 
14 int main() {
15  button.fall(&blink_led);
16  while(1) {
17  // Do nothing
18  }
19 }

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.
Important Information for this Arm website

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies. If you are not happy with the use of these cookies, please review our Cookie Policy to learn how they can be disabled. By disabling cookies, some features of the site will not work.