app_timer2 library

[Venus_Bilandi]

I found app_timer2 library very interesting and I want to use it in our main application code but before that I am exploring it.

I wrote this code and it's not working, please help to resolve the issue.

#define LED_BLE_NUS_CONN (BSP_BOARD_LED_0)
#define LED_CDC_ACM_CONN (BSP_BOARD_LED_2)

#define LED_BLINK_INTERVAL 800

APP_TIMER_DEF(m_blink_ble);
APP_TIMER_DEF(m_blink_cdc);

void blink1_handler(void * p_context)
{
bsp_board_led_invert((uint32_t) p_context);
}

void blink2_handler(void * p_context)
{
bsp_board_led_invert((uint32_t) p_context);
}

int main(void)
{
ret_code_t ret = app_timer_init();
APP_ERROR_CHECK(ret);
ret = app_timer_create(&m_blink_ble, APP_TIMER_MODE_REPEATED, blink1_handler);
APP_ERROR_CHECK(ret);
ret = app_timer_create(&m_blink_cdc, APP_TIMER_MODE_REPEATED, blink2_handler);
APP_ERROR_CHECK(ret);
buttons_leds_init();
ret = app_timer_start(m_blink_ble,
APP_TIMER_TICKS(LED_BLINK_INTERVAL),
(void *) LED_BLE_NUS_CONN);
APP_ERROR_CHECK(ret);

ret = app_timer_start(m_blink_cdc,
APP_TIMER_TICKS(LED_BLINK_INTERVAL),
(void *) LED_CDC_ACM_CONN);
APP_ERROR_CHECK(ret);

// Enter main loop.
for (;;)
{
__NOP();
}
}

[Einar Thorsrud]

Hi,

Have you done any debugging, and if so, what what you found?

Looking at your code I see one important thing missing. The app_timer will not work if the LFCLK is not started. When using a SoftDevice this is started automatically, but if you you need to start it yourself. That can be as simple as calling "nrf_clock_task_trigger(NRF_CLOCK_TASK_LFCLKSTART);".

[Venus_Bilandi]

Thanks, it worked. is there a document which can explain how this library works and what is the flow?

[Einar Thorsrud]

Hi,

I am glad to hear it worked.

The usage is described in the Timer library documentation, but it it is not very detailed (I see now that it does not describe that the LF clock needs to be started separately). You can see a bit more about it in the old nRF5 SDK Application Timer Tutorial. The implementation itself is not documented, so you will have to refer to the code if you want to dig into that (it is normally not necessary, though).

[Venus_Bilandi]

thanks, I will look into it.

I also have developed a similar library for non blocking delay applications using TIMER2. You can create multiple soft timer instances with it. every 1ms timer handler is called and it checks for all the soft timer instance's time out and raise a flag. It does not allow you to call timeout handler, it's a polling based system. But with few modification I think I can add a timeout handler feature in it.

This is more of the reason why I found this app_timer2 library interesting because it already have all the features that can come handy like timeout handler.

My question is what is better to use for this application, TIMER or RTC?

[Einar Thorsrud]

The TIMER and RTC are similar in the sense that they both are timers (count clock pules), but they have some very significant differences in use cases like this. The primary difference is that the TIMER runs of the high frequency clock, and is up to 16 MHz (can be lowered using the prescaler). The RTC on the other hand runs of the 32.768 kHz low frequency clock. This means that if you need very high time resolution, the TIMER is what you want. However, the high frequency clock has a high current consumption, so if you need a low current consumption that is not an alternative. In that case, using the RTC is the sensible approach. All in all, a TIME with required clock etc will consume in the order of 400 -500 uA, where as a RTC with required clock etc would consume in the order of 2-3 uA.

This means that if you are making a low power device an want the soft timers to always run, then using an RTC based approach (like the app_timer) is the only sensible approach. If you don't care about power consumption, then thing may be different.