Re: Timer utility function to use single timer


Bag, Amit K <amit.k.bag@...>
 

Hi Ross,

As you mentioned it's always legal to statically allocate a k_timer struct of your own and initialize and use it at runtime. But suppose we allocated 10 timer structure and now if we make another call to initialize 1 more timer structure it will fail. How to handle that issue. If more than 10 timers are required in a module then statically we cannot allocate more than 10 timer in a given time. Is there any implementation or patch available to have only 1 timer structure initialized in the beginning and simulate all the other timer request coming from above and satisfy them by maintaining only 1 timer internally without actually requesting more timer to the zephyr OS. This will reduce the timer request to zephyr OS and will not have the risk of running out of the timers.


Thanks & Regards,
Amit Bag

-----Original Message-----
From: Ross, Andrew J
Sent: Friday, September 23, 2016 10:11 PM
To: Bag, Amit K <amit.k.bag(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Timer utility function to use single timer

Bag, Amit K wrote:
In Zephyr there will be a chance to run out of timers at times and 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*)
I'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?

Andy

Join devel@lists.zephyrproject.org to automatically receive all group messages.