• State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 22 subscribers
  • Views 2734 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Question on RTX51Tiny os_wait

Paul Blase

What would happen if you have an os_wait or os_wait2 call with an interval of X milliseconds, such as

while {TRUE) {
os_wait2(K_IVL, X);
//do some stuff
}

and the "stuff" takes more than X ticks?

Parents
  • 0 in reply to Andy Neil

    Nope.

    An RTX-51 "interval" is a handy little feature that causes your code to run at a specified frequency -- regardless of how long the code takes. The time is relative to the last time you called os_wait, not the current call.

    Let's say you set the interval for 10 msec and the code takes 2 msec to run. The first line of the body executes at 10 msec. Next pass, 20 msec. Then 30 msec. Now you add some more code so that the body takes 3 msec to run. The code still begins execution at 10, 20, and 30 msec. The interval is running while your code executes.

    The "timeout" is what you describe - wait a specified interval, then execute. The time is relative to the current call. The example above would execute at 10 msec, then 22 msec, then 34 msec. After the change, 10 msec, 23 msec, 36 msec.

    Often you want periodic code to ignore the amount of time it takes to execute to keep the execution time from slipping.

    So, the question arises, what happens when the body of the task takes longer than the interval?

    I would expect the task to run continuously. Every time it comes back around to the os_wait2, the interval timer will already have expired and the OS should just reschedule the task.

    Note that the system is still broken, because the body of the task isn't executing at the specified interval, simply as close to it as it can manage, and the execution times will slip.

Reply
  • 0 in reply to Andy Neil

    Nope.

    An RTX-51 "interval" is a handy little feature that causes your code to run at a specified frequency -- regardless of how long the code takes. The time is relative to the last time you called os_wait, not the current call.

    Let's say you set the interval for 10 msec and the code takes 2 msec to run. The first line of the body executes at 10 msec. Next pass, 20 msec. Then 30 msec. Now you add some more code so that the body takes 3 msec to run. The code still begins execution at 10, 20, and 30 msec. The interval is running while your code executes.

    The "timeout" is what you describe - wait a specified interval, then execute. The time is relative to the current call. The example above would execute at 10 msec, then 22 msec, then 34 msec. After the change, 10 msec, 23 msec, 36 msec.

    Often you want periodic code to ignore the amount of time it takes to execute to keep the execution time from slipping.

    So, the question arises, what happens when the body of the task takes longer than the interval?

    I would expect the task to run continuously. Every time it comes back around to the os_wait2, the interval timer will already have expired and the OS should just reschedule the task.

    Note that the system is still broken, because the body of the task isn't executing at the specified interval, simply as close to it as it can manage, and the execution times will slip.

Children