Handle SYS_CLOCK_TICKS_PER_SEC != 100 in tests

[pizi-nordic]

This PR updates tests to properly handle the SYS_CLOCK_TICKS_PER_SEC != 100 by taking under account effect of tick granularity in tested API. Also, as the measurement become more precise, the timing requirements were tightened.

Details are available in code and description of the commits.

Fixes: #15983
Introduces workaround for #16195

[zephyrbot]

All checks are passing now.

Review history of this comment for details about previous failed status.
Note that some checks might have not completed yet.

[andyross]

This looks good to me. There's a nitpick in there about signedness choice in time values, but it's correctly implemented and local to a test, so not worth a -1.

[andyross]

FWIW: you could consider k_sleep(0) instead, which is guaranteed to synchronize to the "next" tick boundary and doesn't try to sleep for a full millisecond first. Not particularly relevant here, but in situations where you want to do a bunch of tick synchronization in a tight loop on systems where the tick rate is more than 1khz it might save some time running the test.

[pizi-nordic]

Good hint. Thank you. Fixed.

[pizi-nordic]

I changed the code, ran the test and it failed.
The k_sleep(0) does not perform synchronization to tick due to:

/* wait of 0 ms is treated as a 'yield' */
if (duration == 0) {
    k_yield();
    return 0;
}

I kept k_sleep(1) in the code in order to perform synchronization.

[andyross]

This looks dangerous. Time values should almost always be signed, or else the rollover condition will produce incorrect results for time values that are "near" each other (i.e. "just a few cycles ago" can look like a delta of 2^32). Alternatively: making time unsigned means that you can never use a ">"or "<" operator on the resulting value (to mean "later" or "before"), and that's dangerous..

Stated a third way: unsigned times don't have clean definitons for "later" or "before" and you need to know a-priori which time is the one that comes later. That's indeed the way it works here in your new code (i.e. it's computing a delta and assuming that current k_cycle_get_32() is after the argument), and a quick audit of my own seems to show that there aren't any other legacy uses of that elapsed_since value. So this is all local to the test and correct. Still: I strongly recommend never using an unsigned value for a time.

Changing it to a 32 bit word seems fine, I'm just quibbling about the sign.

[pizi-nordic]

My goal here is to have full range of u32 as we do not have k_cycle_get_64.