suspect-devices/circuitpython/extmod/utime_mphal.c, branch 6.0.x

Add license to some obvious files.

2020-07-06T18:16:25+00:00

py,extmod: Some casts and minor refactors to quiet compiler warnings.

2017-07-07T01:32:22+00:00

extmod/utime_mphal: Don't exit/enter the GIL in generic sleep functions.

2017-03-22T01:49:21+00:00

GIL behaviour should be handled by the port. And ports probably want to define sleep_us so that it doesn't release the GIL, to improve timing accuracy.

extmod/utime_mphal: ticks_diff/ticks_add: Don't hardcode 32-bit types.

2016-11-03T20:54:16+00:00

Use normal mp_int_t/mp_uint_t types, algorithms (hm, formulas) can work with any type width.

extmod/utime_mphal: ticks_diff(): Optimize to avoid if conditions.

2016-11-01T23:50:48+00:00

extmod/utime_mphal: Fix implementation of new semantics of ticks_diff().

2016-10-30T00:07:22+00:00

Now the function properly uses ring arithmetic to return signed value in range (inclusive): [-MICROPY_PY_UTIME_TICKS_PERIOD/2, MICROPY_PY_UTIME_TICKS_PERIOD/2-1]. That means that function can properly process 2 time values away from each other within MICROPY_PY_UTIME_TICKS_PERIOD/2 ticks, but away in both directions. For example, if tick value 'a' predates tick value 'b', ticks_diff(a, b) will return negative value, and positive value otherwise. But at positive value of MICROPY_PY_UTIME_TICKS_PERIOD/2-1, the result of the function will wrap around to negative -MICROPY_PY_UTIME_TICKS_PERIOD/2, in other words, if a follows b in more than MICROPY_PY_UTIME_TICKS_PERIOD/2 - 1 ticks, the function will "consider" a to actually predate b.

extmod/utime_mphal: Allow ticks functions period be configurable by a port.

2016-10-30T00:02:07+00:00

Using MICROPY_PY_UTIME_TICKS_PERIOD config var.

extmod/utime_mphal: Implement ticks_add(), add to all maintained ports.

2016-10-29T14:30:05+00:00

extmod/utime_mphal: Add MP_THREAD_GIL_EXIT/ENTER warppers for sleep functions.

2016-10-29T10:42:36+00:00

Ported from unix port.

extmod/utime_mphal: ticks_diff(): switch arg order, return signed value.

2016-10-29T02:02:24+00:00

Based on the earlier discussed RFC. Practice showed that the most natural order for arguments corresponds to mathematical subtraction: ticks_diff(x, y) <=> x - y Also, practice showed that in real life, it's hard to order events by time of occurance a priori, events tend to miss deadlines, etc. and the expected order breaks. And then there's a need to detect such cases. And ticks_diff can be used exactly for this purpose, if it returns a signed, instead of unsigned, value. E.g. if x is scheduled time for event, and y is the current time, then if ticks_diff(x, y) < 0 then event has missed a deadline (and e.g. needs to executed ASAP or skipped). Returning in this case a large unsigned number (like ticks_diff behaved previously) doesn't make sense, and such "large unsigned number" can't be reliably detected per our definition of ticks_* function (we don't expose to user level maximum value, it can be anything, relatively small or relatively large).