docs/utime: Use markup adhering to the latest conventions.
This commit is contained in:
parent
1e31d4bdf6
commit
6f87b03e3c
|
@ -57,10 +57,10 @@ Functions
|
|||
|
||||
.. function:: sleep(seconds)
|
||||
|
||||
Sleep for the given number of seconds. Some boards may accept `seconds` as a
|
||||
Sleep for the given number of seconds. Some boards may accept *seconds* as a
|
||||
floating-point number to sleep for a fractional number of seconds. Note that
|
||||
other boards may not accept a floating-point argument, for compatibility with
|
||||
them use ``sleep_ms()`` and ``sleep_us()`` functions.
|
||||
them use `sleep_ms()` and `sleep_us()` functions.
|
||||
|
||||
.. function:: sleep_ms(ms)
|
||||
|
||||
|
@ -73,30 +73,32 @@ Functions
|
|||
.. function:: ticks_ms()
|
||||
|
||||
Returns an increasing millisecond counter with an arbitrary reference point, that
|
||||
wraps around after some value. This value is not explicitly exposed, but we will
|
||||
refer to it as ``TICKS_MAX`` to simplify discussion. Period of the values is
|
||||
``TICKS_PERIOD = TICKS_MAX + 1``. ``TICKS_PERIOD`` is guaranteed to be a power of
|
||||
wraps around after some value.
|
||||
|
||||
The wrap-around value is not explicitly exposed, but we will
|
||||
refer to it as *TICKS_MAX* to simplify discussion. Period of the values is
|
||||
*TICKS_PERIOD = TICKS_MAX + 1*. *TICKS_PERIOD* is guaranteed to be a power of
|
||||
two, but otherwise may differ from port to port. The same period value is used
|
||||
for all of ``ticks_ms()``, ``ticks_us()``, ``ticks_cpu()`` functions (for
|
||||
simplicity). Thus, these functions will return a value in range [``0`` ..
|
||||
``TICKS_MAX``], inclusive, total ``TICKS_PERIOD`` values. Note that only
|
||||
for all of `ticks_ms()`, `ticks_us()`, `ticks_cpu()` functions (for
|
||||
simplicity). Thus, these functions will return a value in range [*0* ..
|
||||
*TICKS_MAX*], inclusive, total *TICKS_PERIOD* values. Note that only
|
||||
non-negative values are used. For the most part, you should treat values returned
|
||||
by these functions as opaque. The only operations available for them are
|
||||
``ticks_diff()`` and ``ticks_add()`` functions described below.
|
||||
`ticks_diff()` and `ticks_add()` functions described below.
|
||||
|
||||
Note: Performing standard mathematical operations (+, -) or relational
|
||||
operators (<, <=, >, >=) directly on these value will lead to invalid
|
||||
result. Performing mathematical operations and then passing their results
|
||||
as arguments to ``ticks_diff()`` or ``ticks_add()`` will also lead to
|
||||
as arguments to `ticks_diff()` or `ticks_add()` will also lead to
|
||||
invalid results from the latter functions.
|
||||
|
||||
.. function:: ticks_us()
|
||||
|
||||
Just like ``ticks_ms()`` above, but in microseconds.
|
||||
Just like `ticks_ms()` above, but in microseconds.
|
||||
|
||||
.. function:: ticks_cpu()
|
||||
|
||||
Similar to ``ticks_ms()`` and ``ticks_us()``, but with the highest possible resolution
|
||||
Similar to `ticks_ms()` and `ticks_us()`, but with the highest possible resolution
|
||||
in the system. This is usually CPU clocks, and that's why the function is named that
|
||||
way. But it doesn't have to be a CPU clock, some other timing source available in a
|
||||
system (e.g. high-resolution timer) can be used instead. The exact timing unit
|
||||
|
@ -111,13 +113,13 @@ Functions
|
|||
.. function:: ticks_add(ticks, delta)
|
||||
|
||||
Offset ticks value by a given number, which can be either positive or negative.
|
||||
Given a ``ticks`` value, this function allows to calculate ticks value ``delta``
|
||||
Given a *ticks* value, this function allows to calculate ticks value *delta*
|
||||
ticks before or after it, following modular-arithmetic definition of tick values
|
||||
(see ``ticks_ms()`` above). ``ticks`` parameter must be a direct result of call
|
||||
to ``ticks_ms()``, ``ticks_us()``, or ``ticks_cpu()`` functions (or from previous
|
||||
call to ``ticks_add()``). However, ``delta`` can be an arbitrary integer number
|
||||
or numeric expression. ``ticks_add()`` is useful for calculating deadlines for
|
||||
events/tasks. (Note: you must use ``ticks_diff()`` function to work with
|
||||
(see `ticks_ms()` above). *ticks* parameter must be a direct result of call
|
||||
to `ticks_ms()`, `ticks_us()`, or `ticks_cpu()` functions (or from previous
|
||||
call to `ticks_add()`). However, *delta* can be an arbitrary integer number
|
||||
or numeric expression. `ticks_add()` is useful for calculating deadlines for
|
||||
events/tasks. (Note: you must use `ticks_diff()` function to work with
|
||||
deadlines.)
|
||||
|
||||
Examples::
|
||||
|
@ -136,23 +138,25 @@ Functions
|
|||
|
||||
.. function:: ticks_diff(ticks1, ticks2)
|
||||
|
||||
Measure ticks difference between values returned from ``ticks_ms()``, ``ticks_us()``,
|
||||
or ``ticks_cpu()`` functions. The argument order is the same as for subtraction
|
||||
Measure ticks difference between values returned from `ticks_ms()`, `ticks_us()`,
|
||||
or `ticks_cpu()` functions, as a signed value which may wrap around.
|
||||
|
||||
The argument order is the same as for subtraction
|
||||
operator, ``ticks_diff(ticks1, ticks2)`` has the same meaning as ``ticks1 - ticks2``.
|
||||
However, values returned by ``ticks_ms()``, etc. functions may wrap around, so
|
||||
However, values returned by `ticks_ms()`, etc. functions may wrap around, so
|
||||
directly using subtraction on them will produce incorrect result. That is why
|
||||
``ticks_diff()`` is needed, it implements modular (or more specifically, ring)
|
||||
`ticks_diff()` is needed, it implements modular (or more specifically, ring)
|
||||
arithmetics to produce correct result even for wrap-around values (as long as they not
|
||||
too distant inbetween, see below). The function returns **signed** value in the range
|
||||
[``-TICKS_PERIOD/2`` .. ``TICKS_PERIOD/2-1``] (that's a typical range definition for
|
||||
[*-TICKS_PERIOD/2* .. *TICKS_PERIOD/2-1*] (that's a typical range definition for
|
||||
two's-complement signed binary integers). If the result is negative, it means that
|
||||
``ticks1`` occurred earlier in time than ``ticks2``. Otherwise, it means that
|
||||
``ticks1`` occurred after ``ticks2``. This holds ``only`` if ``ticks1`` and ``ticks2``
|
||||
are apart from each other for no more than ``TICKS_PERIOD/2-1`` ticks. If that does
|
||||
*ticks1* occurred earlier in time than *ticks2*. Otherwise, it means that
|
||||
*ticks1* occurred after *ticks2*. This holds **only** if *ticks1* and *ticks2*
|
||||
are apart from each other for no more than *TICKS_PERIOD/2-1* ticks. If that does
|
||||
not hold, incorrect result will be returned. Specifically, if two tick values are
|
||||
apart for ``TICKS_PERIOD/2-1`` ticks, that value will be returned by the function.
|
||||
However, if ``TICKS_PERIOD/2`` of real-time ticks has passed between them, the
|
||||
function will return ``-TICKS_PERIOD/2`` instead, i.e. result value will wrap around
|
||||
apart for *TICKS_PERIOD/2-1* ticks, that value will be returned by the function.
|
||||
However, if *TICKS_PERIOD/2* of real-time ticks has passed between them, the
|
||||
function will return *-TICKS_PERIOD/2* instead, i.e. result value will wrap around
|
||||
to the negative range of possible values.
|
||||
|
||||
Informal rationale of the constraints above: Suppose you are locked in a room with no
|
||||
|
@ -164,10 +168,10 @@ Functions
|
|||
behavior: don't let your application run any single task for too long. Run tasks
|
||||
in steps, and do time-keeping inbetween.
|
||||
|
||||
``ticks_diff()`` is designed to accommodate various usage patterns, among them:
|
||||
`ticks_diff()` is designed to accommodate various usage patterns, among them:
|
||||
|
||||
Polling with timeout. In this case, the order of events is known, and you will deal
|
||||
only with positive results of ``ticks_diff()``::
|
||||
* Polling with timeout. In this case, the order of events is known, and you will deal
|
||||
only with positive results of `ticks_diff()`::
|
||||
|
||||
# Wait for GPIO pin to be asserted, but at most 500us
|
||||
start = time.ticks_us()
|
||||
|
@ -175,7 +179,7 @@ Functions
|
|||
if time.ticks_diff(time.ticks_us(), start) > 500:
|
||||
raise TimeoutError
|
||||
|
||||
Scheduling events. In this case, ``ticks_diff()`` result may be negative
|
||||
* Scheduling events. In this case, `ticks_diff()` result may be negative
|
||||
if an event is overdue::
|
||||
|
||||
# This code snippet is not optimized
|
||||
|
@ -192,8 +196,8 @@ Functions
|
|||
print("Oops, running late, tell task to run faster!")
|
||||
task.run(run_faster=true)
|
||||
|
||||
Note: Do not pass ``time()`` values to ``ticks_diff()``, you should use
|
||||
normal mathematical operations on them. But note that ``time()`` may (and will)
|
||||
Note: Do not pass `time()` values to `ticks_diff()`, you should use
|
||||
normal mathematical operations on them. But note that `time()` may (and will)
|
||||
also overflow. This is known as https://en.wikipedia.org/wiki/Year_2038_problem .
|
||||
|
||||
|
||||
|
@ -205,8 +209,8 @@ Functions
|
|||
embedded boards without a battery-backed RTC, usually since power up or reset). If you
|
||||
want to develop portable MicroPython application, you should not rely on this function
|
||||
to provide higher than second precision. If you need higher precision, use
|
||||
``ticks_ms()`` and ``ticks_us()`` functions, if you need calendar time,
|
||||
``localtime()`` without an argument is a better choice.
|
||||
`ticks_ms()` and `ticks_us()` functions, if you need calendar time,
|
||||
`localtime()` without an argument is a better choice.
|
||||
|
||||
.. admonition:: Difference to CPython
|
||||
:class: attention
|
||||
|
|
Loading…
Reference in New Issue