Re: Counter API ambiguity.


Chettimada, Vinayak Kariappa
 

Hi,

Analysing the problem here, with a 32-bit integers, only 31-bit value range can be used to set alarms that expire after a rollover of 32-bit clock counts.
This is considering that we want to detect if an alarm expired in the past or will expire in the future.

Use of s32_t seems a way of restricting the application from supplying something greater than 0x7fffffff.
Hence, we should retain the use of s32_t for duration/offset/period etc. and make other APIs consistent.

Regards,
Vinayak


On 13 Sep 2017, at 17:40, Boie, Andrew P <andrew.p.boie@...> wrote:

Ø  Shouldn't we stay consistent with the type for delay/timeout/alarm values among Zephyr modules?
 
I had noticed this recently as well, I couldn't figure out why APIs like k_timer_start() took signed values for the timeout, especially since the code has assertions in it to ensure the value is positive.
 
As far as I can tell from asking around, this is a historical artifact. I think we could change these parameter to unsigned types.
 
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

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