- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I use the 20736S and SDK 2.2.0
The fine timer is normally set in:
const BLE_PROFILE_CFG contact_exchg_cfg =
{
/*.fine_timer_interval =*/ 700, // ms
......
};
Which is loaded here:
APPLICATION_INIT()
{
bleapp_set_cfg((UINT8 *)gatt_database,
gatt_database_len,
(void *)&contact_exchg_cfg,
(void *)&contact_exchg_puart_cfg,
(void *)&contact_exchg_gpio_cfg,
contact_exchg_create);
}
And we do get to the handler every 700 ms reliably, without any problems:
// It will be called every fine timer tick
void contact_exchg_timer_fine()
{
loopd_trace0("contact_exchg_timer_fine()");
timestamp++;
.......
// Change period here!!!
// How?
}
My question is, once in the fine timer handler, just before it returns, can I change the period parameter so the next time it will happen at a different time, say 900 ms from now instead of 700 ms? How do I do that?
Thanks,
Gil
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To the best of my knowledge, the app timers cannot be changed after you compile. But there are a couple of work arounds to this problem:
1. You could have some incrementing logic within the timer that only executes code on every nth call of the timer. Then dynamically change the value of n. (setting the initial fine timer value to minimum value you ever want to change it to within your code) (the original fine timer interval would need to be a factor of every interval you wish to use in the future).
The better approach:
2. Second, you could instantiate a new timer that is provided as a patch with with the most recent SDKs. As Arvind describes in the post: Re: FineTimer Follow the instructions Arvind explains to instantiate the timer. You can use this new timer much more dynamically than the app timers, meaning that you can set it to 700ms initially, kill the timer, then re-instantiate it with new parameters and new interval (900ms).
Jacob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To the best of my knowledge, the app timers cannot be changed after you compile. But there are a couple of work arounds to this problem:
1. You could have some incrementing logic within the timer that only executes code on every nth call of the timer. Then dynamically change the value of n. (setting the initial fine timer value to minimum value you ever want to change it to within your code) (the original fine timer interval would need to be a factor of every interval you wish to use in the future).
The better approach:
2. Second, you could instantiate a new timer that is provided as a patch with with the most recent SDKs. As Arvind describes in the post: Re: FineTimer Follow the instructions Arvind explains to instantiate the timer. You can use this new timer much more dynamically than the app timers, meaning that you can set it to 700ms initially, kill the timer, then re-instantiate it with new parameters and new interval (900ms).
Jacob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks!
For 1. above:
Understood. I will try that.
For 2. above:
Do you mean in the callback/handler, call "bt_clock_based_periodic_timer_Disable()" to kill the timer, and then to re-instantiate call "bt_clock_based_periodic_timer_Enable(application_timer_expired_callback, NULL, US_TIME/625);" with different US_TIME values? And then return? So the callback would look like:
int application_timer_expired_callback(void* context)
{
// 50 ms timer callback. Now chande the interval to 100 ms, for example.
// Kill timer
bt_clock_based_periodic_timer_Disable();
// Re-instatiate with 100 ms interval
bt_clock_based_periodic_timer_Enable(application_timer_expired_callback, NULL, 100000/625)
// Context was not allocated and so does not need to be freed. So return no action.
return BLE_APP_EVENT_NO_ACTION;
}
Is that right?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yeah that's what I meant overall, but you may have to tweak the code and see what works. For instance, you may need to call disable, init, then enable within your callback.
To weed out other issues you may want to call these APIs in a separate function to prevent the enable API from trying to call the function it's currently in.
Jacob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Great. I will try that. Thanks Jake! Cheers, Gil.