diff options
author | Paul Sokolovsky <pfalcon@users.sourceforge.net> | 2016-10-29 05:02:24 +0300 |
---|---|---|
committer | Paul Sokolovsky <pfalcon@users.sourceforge.net> | 2016-10-29 05:02:24 +0300 |
commit | 6ed5583f8cfa5aa0afb776654cd996abaaa5fba3 (patch) | |
tree | f2c44b256ab0d83f4a44e4357aefa3f8ac9dc8f2 /tests/basics/map.py | |
parent | e381efed4a49c206fe413758749ee30b3b46cebe (diff) | |
download | micropython-6ed5583f8cfa5aa0afb776654cd996abaaa5fba3.tar.gz micropython-6ed5583f8cfa5aa0afb776654cd996abaaa5fba3.zip |
extmod/utime_mphal: ticks_diff(): switch arg order, return signed value.
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).
Diffstat (limited to 'tests/basics/map.py')
0 files changed, 0 insertions, 0 deletions