I think there was some discussion re: HAL PWM but I cannot quite recall the end result. Maybe that this would be a driver instead of a HAL? I agree; PWM is very commonly used so having PWM support (in either driver or HAL form) should be added.
> On Dec 26, 2016, at 10:26 AM, Kevin Townsend <[email protected]> wrote: > > 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.
