Please clarify consequences of using delay() and delayMicroseconds()

[bmcdonnell]

I see in several of your examples (e.g. Basic_RTOS_Example), you have comments and code such as quoted below. Can you please clarify the consequences of utilizing delay() and delayMicroseconds() functions?

//**************************************************************************
// Can use these function for RTOS delays
// Takes into account processor speed
// Use these instead of delay(...) in rtos tasks
//**************************************************************************
void myDelayUs(int us)
{
  vTaskDelay( us / portTICK_PERIOD_US );  
}

void myDelayMs(int ms)
{
  vTaskDelay( (ms * 1000) / portTICK_PERIOD_US );  
}

void myDelayMsUntil(TickType_t *previousWakeTime, int ms)
{
  vTaskDelayUntil( previousWakeTime, (ms * 1000) / portTICK_PERIOD_US );  
}

I'm currently using a SAMD51-based board for controlling multiple items simultaneously. The underlying libraries sometimes use the delay() and delayMicroseconds() functions. I thought that using an RTOS such as this would be an easy way to multitask, without worrying about when my underlying libraries use various delays, and even allowing me to use the obviously "blocking" functions as needed. But your examples suggest I'd have to dig into every library I'm using, and their dependencies; find every place they use delay/delayMicroseconds; fork those libraries; and modify them so I can injecting different delay functions. Which in turn has me questioning whether to bother with an RTOS at all.

[BriscoeTech]

Hello bmcdonnell,

This is a really good question. It depends on what your goals are for your project. There are a couple of design decisions you will want to weigh to decide what the best option is for you.

The arduino delay() and delayMicroseconds() functions do not integrate well into a rtos because of the way they are implemented. Their implementation can be different from from processor to processor and there is no standard on how they are supposed to be implemented. Usually the way they are coded are time wasting NOP for loops, that will hog the cpu for so many cycles and will allow your code to continue running after the for loops are completed. This conflicts with how a rtos likes to do things, which is free up the processor to schedule other things until you need to come back to the task when the delays time expires. In the case of the Samd51, the arduino blocking delays are while loop based on the system tick timer, which is hardware interrupt friendly, but still not rtos friendly.

In an ideal world when you have a rtos, you will always want to use the rtos friendly delays so you have full control over the systems timing and tasks will schedule and play nicely with one another. If you call a blocking delay function, you will hang the rtos for that period of time, no other tasks are scheduled, and suddenly your predictive timing and scheduling might get thrown out the window. The rtos delays, mutexes, semaphores all work together with the scheduler to figure out who should run next, get processor time, and allows for the processor to be efficiently shared as needed among all the threads in your system.

I will say there are times when having blocking delays are ok, and that is only if they are really small when compared to the periods of all the threads in the system, or to the timing requirements you are trying to meet. Here is one example I personally had in a project. The Adafruit Neopixel library used to use delayMicroseconds() to bitbang the data sent to the leds (dont know if it still does) and these are blocking commands. For my project, I figured to set a very short string of 3 leds it would take only afew milliseconds, like <10ms to shift the data out in order to set the string. When comparing this to the timings of my threads which had periods of 1000ms, I figured that 10ms window of hogging the cpu was ok. I also was ok with potentially adding 10ms of error for when the next thread got scheduled, I was using myDelayMs and not myDelayMsUntil. Another reason I was ok with it was I was calling the leds set function from the lowest priority task, and guaranteed that all the other higher priority threads had run and finished in my system before blocking everything for the 10ms.

If your blocking delays start getting to large, you will notice the system hang or studder. This is one reason I put the printing of the "." in the idle loop example code. If you see the nice steady printing of the dots, you know that everything is completing and there is enough free time for the idle loop to run and print the dots. If you see it studdering, something in the system may be holding or hogging the cpu longer than you may want. Again, this varies from project to project. I had one project where I wanted to push a button and erase an entire sd card. This would hang the entire system for about 30 seconds. I was ok with it in that case, because I did not have any requirement for the system to need to do anything else until the sd card was erased, and was happy with how it turned out.

My advice might be to think about what the worst case delays your librarys might have, and how often, and decide if you think that is acceptable or could cause problems. Think about if one thread calls a blocking delay, will that delays length ruin the timing you need for another thread. If you decide they are negligible and try coding it up, keep an eye on the idle loop dots and see if you notice any shuddering as a clue to things might not be going smoothly. I use alot of print statements to announce when things start and end in my code, and you can track down functions that might be causing you problems.

For me I treat most well designed sensor libraries (i2c/spi/neopixles) as negligible, and assume it gets in and out as fast as it can, and any small delays or while loops it may have hidden in it as the cost of doing business. I make sure my lofty application specific threads use the rtos friendly delays to control sensor sample rates, or set long term goals and periods of the project. The only time I concisely use blocking delay functions is during the arduino setup function before the rtos start function has been called, rtos delays cannot be used if the rtos has not been started yet.

Hope this gives you some good rules of thumb, and rationale for how to go about setting up a project. Good luck!

[bmcdonnell]

Thank you kindly for the speedy and informative reply.

I'll have to think and look into this further for my current application.

Maybe you can tweak some of your response here and add it to your documentation? I think it might be useful to others.

[bmcdonnell]

I wound up getting away without an RTOS for my current application.