Fixes: #73831
find_package(Zephyr) should be called before first project() call.
Zephyr package will test and force-set the correct toolchain, especially
the C compiler.
The project() will also set the C compiler, if not set already.
If project() is called first, then conflict arises on the C compiler
selection and thus the following message is seen:
> You have changed variables that require your cache to be deleted.
> Configure will be re-run and you may have to reset some variables.
> The following variables have changed:
> CMAKE_C_COMPILER= /usr/bin/gcc
This cache deletion results in other errors, such as a missing BOARD
setting.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fix the deprecated calls to loading ZephyrUnittest by replacing them
with `Zephyr COMPONENTS unittest`.
Signed-off-by: Yuval Peress <peress@google.com>
Adding cmake_minimum_required() as this is required by CMake.
CMP0000 is a deprecated policy which allows to omit this function call,
however doing so will result in CMake printing a warning.
Adding cmake_minimum_required() to tests missing this call will remove
the warning and also allow us to remove the policy setting.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The net_timeout structure is documented to exist because of behavior
that is no longer true, i.e. that `k_delayed_work_submit()` supports
only delays up to INT32_MAX milliseconds. Nonetheless, use of 32-bit
timestamps within the work handlers mean the restriction is still
present.
This infrastructure is currently used for two timers with long
durations:
* address for IPv6 addresses
* prefix for IPv6 prefixes
The handling of rollover was subtly different between these: address
wraps reset the start time while prefix wraps did not.
The calculation of remaining time in ipv6_nbr was incorrect when the
original requested time in seconds was a multiple of
NET_TIMEOUT_MAX_VALUE: the remainder value would be zero while the
wrap counter was positive, causing the calculation to indicate no time
remained.
The maximum value was set to allow a 100 ms latency between elapse of
the deadline and assessment of a given timer, but detection of
rollover assumed that the captured time in the work handler was
precisely the expected deadline, which is unlikely to be true. Use of
the shared system work queue also risks observed latency exceeding 100
ms. These calculations could produce delays to next event that
exceeded the maximum delay, which introduced special cases.
Refactor so all operations that use this structure are encapsulated
into API that is documented and has a full-coverage unit test. Switch
to the standard mechanism of detecting completed deadlines by
calculating the signed difference between the deadline and the current
time, which eliminates some special cases.
Uniformly rely on the scanning the set of timers to determine the next
deadline, rather than assuming that the most recent update is always
next.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
