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?
while (TRUE) { os_wait2( K_IVL, X ); //do some stuff }
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.
OK, but I don't think that's clear from the manual page: http://www.keil.com/support/man/docs/tr51/tr51_os_wait2.htm At the very least, it needs a hyperlink to this page, where the concept of the "interval" is defined: http://www.keil.com/support/man/docs/tr51/tr51_events.htm One problem with these online manuals is that there is no way to search just a single manual - it's all or nothing! :-(
Search in on-line manuals: http://www.keil.com/support/search.asp Click 2. Search in On-line Manuals. Reinhard
>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. The problem is that I'm not entirely sure that this is what it's doing. I'm getting weird results, although I haven't the time to fully investigate them. It seems like when the interval expires that RTXTiny interrupts the process and restarts it at the wait call. Since I don't care about exact timing, I substituted a timeout call for an interval call and it worked properly.
"http://www.keil.com/support/search.asp Click 2. Search in On-line Manuals." Yes, but my point is that this will always search all the manuals. The is no way to search just one specific manual, or even just one specific toolset.
Sorry, I did not saw this. Actually you can search product releated manuals, but not a specific manual. Is this really a serious problem? Reinhard
What would happen if you have an os_wait or os_wait2 call with an interval of X milliseconds...and the "stuff" takes more than X ticks? The os_wait function will return immediately in this case. Each task includes a timer "delay" that decrements once for each timer tick. If you wait for 5 ticks, 5 is added to this tick (which starts at 0 for the first call to os_wait for an interval). And, the new value is 5. After 5 time ticks, the value will be 0 and the task will be run again. So, if you ask for an interval of 5 ticks and the current "delay" time is -5 or lower, the task will re-start immediately. So, if the interval is ALWAYS less than the stuff, no other tasks will run. Jon
Thanks for the ideas, Andy. I've added a link to the Events page and added a little more description there of the effects of Interval in such a case. One problem with these online manuals is that there is no way to search just a single manual - it's all or nothing! This is already on the list of new features for the web site. Jon
Ah, maybe that was the problem: parallel tasks that I thought were executing weren't. Thanks Paul >The os_wait function will return immediately in this case. ... So, if the interval is ALWAYS less than the stuff, no other tasks will run.
This might actually be something to change in RTX51Tiny. If I have several tasks going on, and round-robin task switching turned off for efficiency, then there should be a "next_task" function that I can call simply to give other tasks a chance to execute when timing isn't critical. Calling "os_wait()" with a value of 0 would be sufficient. I rolled my own little RTS, before I could afford a copy of RTX51Tiny, and did just that. Each task would execute once through the "while (1)" loop and then pass control on to the next. Paul Blase
...there should be a "next_task" function that I can call simply to give other tasks a chance to execute... This is your lucky day. :-) There is such a function. It's called os_switch_task. Here's the manual page for it: http://www.keil.com/support/man/docs/tr51/tr51_os_switch_task.htm Jon
Arrgh, I knew that I missed something. Thanks. Paul
Ah, os_switchtask isn't in the manual, it must be a new feature. That's why I didn't find it. Thanks Paul