Delay in mS

	vTaskDelay(2000 / portTICK_PERIOD_MS);


The RTOS tick period is (by default) 10ms

N.B. We've found using a value less than the RTOS tick rate, so (10 / portTICK_PERIOD_MS), results in a delay of 100mS regardless of the value used!  Even vTaskDelay(10) does it.  This seems like it must be a bug that hopefully will get fixed but one to watch out for if you get weird slowness

Delay in uS

The ROM function ets_delay_us() (defined in rom/ets_sys.h) will allow you to busy-wait a specified number of uS.

Note that this is busy-waiting – it does not allow other tasks to run, it just burns CPU cycles.

Exact delays

If you have to do something that is extremely time critical for a short period of time you can suspend interrupts and context switches. Call portDISABLE_INTERRUPTS (and portENABLE_INTERRUPTS after you're done) and the interrupts on that core should stop firing, stopping task switches as well.

Be aware that dependent on what you do, instructions may still not execute at the same speed because of e.g. bus contention, cache misses etc. If you need 100% accurate timings, it's better to wait until a timer has a certain value than executing a loop of instructions. Or, if possible, use a hardware peripherals to generate/capture the signals you need alltogether, negating the need for precise timings.



We benefit hugely from resources on the web so we decided we should try and give back some of our knowledge and resources to the community by opening up many of our company’s internal notes and libraries through mini sites like this. We hope you find the site helpful.
Please feel free to comment if you can add help to this page or point out issues and solutions you have found, but please note that we do not provide support on this site. If you need help with a problem please use one of the many online forums.


Your email address will not be published. Required fields are marked *