Lines Matching full:that
23 and :c:func:`k_cycle_get_64` APIs. The intent is that this counter
24 represents the fastest cycle counter that the operating system is able
25 to present to the user (for example, a CPU cycle counter) and that the
26 read operation is very fast. The expectation is that very sensitive
31 platforms is a runtime constant that evaluates to
40 hardware platforms (ones that support setting arbitrary interrupt
80 Apps with precise timing requirements (that are willing to do their
102 an opaque struct type that must be initialized using one of a family
112 time" will already have advanced. This is to ensure that timers scheduled from
123 :c:macro:`K_CYC()` specify timeout values that will expire after specified
128 complicated rollover semantics, so it is expected that
134 indicates a timeout that will expire after the system uptime reaches
149 event, along with a :c:struct:`_timeout` tracking struct that is
153 Note that all variant units passed via a :c:struct:`k_timeout_t` are converted
159 Note that the list structure means that the CPU work involved in
173 number of ticks that have elapsed since the last announce call (or
176 interrupt latency interactions) that they occur near tick boundaries
177 (i.e. not "halfway through" a tick), and most importantly that they
184 It is legal to announce new ticks before that moment (though they
185 must be correct) but delay after that will cause events to be
186 missed. Note that the timeout value passed here is in a delta from
187 current time, but that does not absolve the driver of the
198 Note that a natural implementation of this API results in a "tickless"
221 access appropriately, and ensure that all critical sections are small
231 per-CPU tracking, and expects that if two timer interrupts fire near
232 simultaneously, that only one will provide the current tick count to
248 minimizes the chance that an errant ISR or interrupt lock will delay
250 current design expects that any such optimization is the
257 to the scheduler that allow implementation of time slicing of threads.
259 a global expiration but instead a per-CPU value that needs to be
263 Zephyr multiplexes the existing timer driver. This means that the
268 Subsystems that keep millisecond APIs
282 One complexity is :c:macro:`K_FOREVER`. Subsystems that might have
293 Ideally, code that takes a "timeout" parameter specifying a time to
298 Some conversions are simple. Code that needs to test for
304 that may require multiple blocking operations on underlying kernel
326 This code requires that the timeout value be inspected, which is no
329 that converts an arbitrary timeout to and from a timepoint value based on
353 Note that :c:func:`sys_timepoint_calc` accepts special values :c:macro:`K_FOREVER`
360 But some care is still required for subsystems that use those. Note that
362 and obviously that time is the time of the call to
363 :c:func:`sys_timepoint_calc`. But the user expects that the time is