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
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?