On Fri, 23 Sep 2016, Andy Ross wrote:
Bag, Amit K wrote:
In Zephyr there will be a chance to run out of timers at times andI'm a little curious about this API design too. AFAICT, it's always
we will not get the timer handle to use for our modules.
Means whenever we required a timer for our module we can call a
timer API defined in zephyr
(i.e. *task_timer_alloc(),task_timer_start(),task_timer_stop, etc*)
legal to statically allocate a k_timer struct of your own and
initialize and use it at runtime. If you need to know you won't run
out of timers, you can be guaranteed not to lose this one.
The allocate/free API looks like it's just a convenience wrapper to
allow sharing of timer objects between usages if you know they aren't
all going to be needed simultaneously.
The problem though, is that to get this facility Zephyr allocates 10
(by default) k_timer objects in a pool and shares only those.
Obviously Zephyr has no heap, so it can't share the memory as anything
but timers. And these aren't tiny objects. My quick manual count
says that they're 64 bytes a piece, so that's half a kb of RAM that
we're allocating in every default-configured app just to save a
handful of bytes in apps that want to use the "sharing" convenience
API. That seems like a bad trade to me.
Would anyone object to a patch that set CONFIG_NUM_DYNAMIC_TIMERS to
zero by default and disabled the API unless it was 1 or greater? Or
maybe deprecating it for future removal?
I was also thinking on setting this to 0 and save some space.