Hi Will,
Thanks for the feedback.
1) Unless you are the highest priority task, other tasks can run which could
cause delays, and thus you are not waking up at the desired time.
Yeah, everything is based on the assumption that priority is resolved by
design, and that the scheduling constraints are realistic and well
understood in the system.
2) Using os_time_delay() and os_callout_reset() gives you a 1 os time tick
resolution, so if your ticks are 10 msecs, you will be off by up to 9 msecs. A
1 msec ticker gets you off by up to 1 msec.
Using a task to post another task is a bit heavyweight; I would use a timer or
a callout to do this. A timer would solve your “tick resolution” issue but
would not solve the problem of a task wake up getting delayed.
A timer would be a valid solution as well, yes. I haven't looked
seriously at the timer HAL yet, but I'll have a look right now and give
it a try just to familiarize myself with it.
I saw earlier today that there wasn't PWM support and wanted to see if
that was something that could be easily added to the timer HAL since
it's a common requirement that should probably be included (motor
control, dimming control, etc.). Different issue though!
It would not be hard to add an API to os_callout.c that could be used for this.
Something like “os_callout_reset_at” or “os_callout_reset_tick” which you could
pass in a specified os tick. Not sure what the API should do if you missed the
os tick (return -1 and not post the task)? This would be simple code to use;
just add the sample rate to the last time and call the new os_calllout API.
Personally, I think this would make a lot of sense and solve what is
bound to be a common problem, and perhaps you can have a flag to define
the behaviour when you miss the delay. Either you return an error code,
OR you fire the task as soon as you can (though ideally still with a
flag of some sort to know you're late), but having the option between
the two should solve some problems.
K.
