Hi,
What is the largest possible value of "MAX_VAL" for application timer given below:
"#define APP_TIMER_PRESCALER 0"
"#define M_DELAY APP_TIMER_TICKS(MAX_VAL, APP_TIMER_PRESCALER)"
Is it 32 bit value?
Hi,
What is the largest possible value of "MAX_VAL" for application timer given below:
"#define APP_TIMER_PRESCALER 0"
"#define M_DELAY APP_TIMER_TICKS(MAX_VAL, APP_TIMER_PRESCALER)"
Is it 32 bit value?
The RTC timer is only 24 bits and app_timer does all its timing modulo 2^24. So the largest value for your M_DELAY is (2^24)-1. However due to the way the modulo counting is done the max value is a bit smaller then this. The value I use is:
#define RTC_TICKS_BITS 24 // size of RTC[01] counter in bits
#define TIMER_MAX_TIMEOUT \
((1 << RTC_TICKS_BITS) - APP_TIMER_MIN_TIMEOUT_TICKS * 10) // fudge
How much time this represents is a function of the prescaler chosen. APP_TIMER_TICKS converts from miliseconds to ticks.
The max value in miliseconds is something like:
(2**24) * (APP_TIMER_PRESCALER+1) * 1000 / 32768 - fudge
This works out to <512 seconds for prescaler of 0.
Personally I think app_timer could really use a thorough rewrite. It wouldn't take much for it to support timeout intervals longer then the roll-over period of the timer and in the process the code could be greatly simplified. Only one timer is available for the user and I need it to provide both a monotonic real time counter (which requires a small prescaler), and timeouts/time scheduled events (which requires a larger prescaler for longer intervals) .
The RTC timer is only 24 bits and app_timer does all its timing modulo 2^24. So the largest value for your M_DELAY is (2^24)-1. However due to the way the modulo counting is done the max value is a bit smaller then this. The value I use is:
#define RTC_TICKS_BITS 24 // size of RTC[01] counter in bits
#define TIMER_MAX_TIMEOUT \
((1 << RTC_TICKS_BITS) - APP_TIMER_MIN_TIMEOUT_TICKS * 10) // fudge
How much time this represents is a function of the prescaler chosen. APP_TIMER_TICKS converts from miliseconds to ticks.
The max value in miliseconds is something like:
(2**24) * (APP_TIMER_PRESCALER+1) * 1000 / 32768 - fudge
This works out to <512 seconds for prescaler of 0.
Personally I think app_timer could really use a thorough rewrite. It wouldn't take much for it to support timeout intervals longer then the roll-over period of the timer and in the process the code could be greatly simplified. Only one timer is available for the user and I need it to provide both a monotonic real time counter (which requires a small prescaler), and timeouts/time scheduled events (which requires a larger prescaler for longer intervals) .
Many thanks for explanation. So the easiest way to get timeout > 512 seconds is to increase APP_TIMER_PRESCALER, but on the other hand if e.g. APP_TIMER_PRESCALER=4095 I can only write "MAX_VAL" taht is multiple value of 125 ms counter period? As you mentioned the problem appears when I have a few timers that need to generate different delays (e.g 1ms and a few hours). Is there any good solution for this problem? (or should I use small prescaler and start timer many times in timeout_handler in a conditional loop to get the bigger delay).
Short of rewriting app_timer, I'm not sure what the best option is. I ended up using a prescaler of 0 because I needed to use RTC1 for a 'not-quite high enough precision' monotonic counter and I gave up on doing long timers directly with app_timer.
At one point I started to rewrite app_timer with something that better matched my needs but decided I didn't want to put the time (sic) to properly test it.
Hi Clem,
What is this fudge factor you are talking about?
At the time it was unclear to me if the app_timer code would accept a timeout up near the limit of 2**24 ticks, so it seemed like a good idea to add a little bit of headroom.
But then I found that I was having timers misfire when the timeout was > 2**(24-1) ticks. See: devzone.nordicsemi.com/.../
Now I never use a timer > 2**23 ticks.
But that bug mentioned in the link was fixed in SDK11_alpha wasn't it?