summaryrefslogtreecommitdiffstatshomepage
path: root/tests/basics/map.py
diff options
context:
space:
mode:
authorPaul Sokolovsky <pfalcon@users.sourceforge.net>2016-10-29 05:02:24 +0300
committerPaul Sokolovsky <pfalcon@users.sourceforge.net>2016-10-29 05:02:24 +0300
commit6ed5583f8cfa5aa0afb776654cd996abaaa5fba3 (patch)
treef2c44b256ab0d83f4a44e4357aefa3f8ac9dc8f2 /tests/basics/map.py
parente381efed4a49c206fe413758749ee30b3b46cebe (diff)
downloadmicropython-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