The machine.sleep() function can be misleading because it clashes with
time.sleep() which has quite different semantics. So change it to
machine.lightsleep() which shows that it is closer in behaviour to
machine.deepsleep().
Also, add an optional argument to these two sleep functions to specify a
maximum time to sleep for. This is a common operation and underlying
hardware usually has a special way of performing this operation.
The existing machine.sleep() function will remain for backwards
compatibility purposes, and it can simply be an alias for
machine.lightsleep() without arguments. The behaviour will be the same.
Examples are added to the beginning of the module docs, similarly to docs
for many other modules.
Improvements to grammar, style, and clarity. Some paragraphs are updated
with better suggestions. A warning added of the effect incorrect usage of
the module may have. Describe the fact that offset range used in one
defined structure is limited.
Otherwise there is really nothing that can be done, it can't be unlocked by
the user because there is no way to allocate memory to execute the unlock.
See issue #4205 and #4209.
With this commit there is now only one entry point into the whole
documentation, which describes the general MicroPython language, and then
from there there are links to information about specific platforms/ports.
This commit doesn't change content (almost, it does fix a few internal
links), it just reorganises things.
All concrete network classes are now moved to their own file (eg
network.WLAN.rst) and deconditionalised (remove ..only:: directives). This
makes the network documentation the same for all ports. After this change
there are no more "..only::" directives for different ports, and the only
difference among ports is the very front page of the docs.
The WiPy machine.Timer class is very different to the esp8266 and esp32
implementations which are better candidates for a general Timer class. By
moving the WiPy Timer docs to a completely separate file, under a new name
machine.TimerWiPy, it gives a clean slate to define and write the docs for
a better, general machine.Timer class. This is with the aim of eventually
providing documentation that does not have conditional parts to it,
conditional on the port.
While the new docs are being defined it makes sense to keep the WiPy docs,
since they describe its behaviour. Once the new Timer behaviour is defined
the WiPy code can be changed to match it, and then the TimerWiPy docs would
be removed.
The machine module should be standard across all ports so should have the
same set of classes in the docs. A special warning is added to the top of
the machine.SD class because it is not standardised and only available on
the cc3200 port.
It's fair to just provide a link to all available modules, regardless of
the port. Most of the existing ports (unix, stm32, esp8266, esp32) share
most of the same set of modules anyway, so no need to maintain separate
lists for them. And there's a big discussion at the start of this index
about modules not being available on a given port.
For port-specific modules, they can also be listed unconditionally because
they have headings that explicitly state they are only available on certain
ports.
The UART.init() method is now included unconditionally and its wording
adjusted to better describe ports other than the cc3200.
UART.irq() is also included unconditionally, but this is currently only
available on the WiPy target.
By virtue of its name, the pyb module would only be available on a pyboard
and so does not need to have conditional "only" directives throughout its
documentation.
These conditionals were added mostly in
cfcf47c064 in the initial development of the
cc3200 port, which had the pyb module before it switched to the machine
module. And wipy only conditionals were removed from the pyb module
documentation in 4542643025, so there's no
need to retain any more conditionals.
Allow including crypto consts based on compilation settings. Disabled by
default to reduce code size; if one wants extra code readability, can
enable them.
These can be optionally specified, but all ports are expected to be able to
accept them, at the very least ignore, though handling of "type" param
(SOCK_STREAM vs SOCK_DGRAM) is recommended.
This can be used to select the output buffer behaviour of the DAC. The
default values are chosen to retain backwards compatibility with existing
behaviour.
Thanks to @peterhinch for the initial idea to add this feature.
The parameter order in the example for ticks_diff was incorrect. If it's
"too early" that means that scheduled time is greater than current time and
if it's "running late" then scheduled time would be less than current time.
Put offset first in OR expressions, and use "offset" var instead of
hardcoded numbers. Hopefully, this will make it more self-describing
and show patterns better.
State that this doc describes generic, "core" MicroPython functionality,
any particular port may diverge in both directions, by both omitting
some functionality, and adding more, both cases described outside the
generic documentation.
Describe that the only portable way to deal with addresses is by using
getaddrinfo(). Describe that some ports may support tuple addresses using
"socket" module (vs "usocket" of native MicroPython).
This clarifies return values and the handling of invalid (e.g. newline)
characters.
Encoding conforms to RFC 3548, but decoding does not, as it ignores invalid
characters in base64 input. Instead, it conforms to MIME handling of base64
(RFC 2045).
Note that CPython doesn't document handling of invalid characters in
a2b_base64() docs:
https://docs.python.org/3/library/binascii.html#binascii.a2b_base64 , so
we specify it more explicitly than it, based on CPython's actual behavior
(with which MicroPython now compliant).
This makes top-level ToC of the pyboard docs consistent with other ports
(consisting of 3 chapters: QuickRef, General Info, and Tutorial).
Also, some other minor tweaks applied, like local ToC for General Info and
headings mentioning pyboard.
This pseudo-section causes artifacts with latexpdf generation (almost
empty page with list containing literal "genindex", "modeindex", "search"
items). For HTML docs, these sections can be accessed from "home" page.
We don't use alpha/beta/RC, so for us version and release should be the
same, or it leads to confusion (for example, current, 1.9.1 docs are
marked as 1.9 at places).
The idea is to allow to define a kind of "macros" for repeatitive text,
so all occurrances can be updated in one place. Unfortunately, RST doesn't
support replacements with arguments, which limits usefulness of them and
should be taken into account.
We have enough terms or references throughout the docs which may be not
immediately clear or have some important nuances. Referencing terms in
gloassary is the best way to deal with that.
The old intro talked about "differences", but there were hardly any
sections describing differences, mostly MicroPython specific features.
On the other hand, we now have real "differences" chapter, though it's
mostly concerned with stdlib differences.
So, try to avoid confusion by changing wording and linking to the other
chapters and contrasting them with what is described in "MicroPython
language".
Previously, only "selected chapters" were shown in left-pane ToC (of
Read The Docs theme). These chapters were selected out of order. The
rest of chapters were hidden beyond "Documentation Contents" pseudo-
chapter. This arguably led only to confusion, as many people probably
never tried to open that pseudo-chapter, and those who did, were
confused. Such organization is even worse for PDF output, causing
chapters go in mix-mashed order.
So, instead move to single clean ToC. This will allow readers of HTML
to have access to any doc content at their fingertips (and straight
before their eyes), and will allow to finally have clean PDF docs.
Move hardware-specific optimizations to the very end of document, and
add visible note that it gives an example for Pyboard. Remove references
to specific hardware technologies, so the doc can be more naturally
used across ports. Various markup updates to adhere to the latest
docs conventions.
This causes `symbol` syntax to be equivalent to :any:`symbol`, which is
in turn the easiest way to cross-reference an arbitrary symbol in the
docs:
http://www.sphinx-doc.org/en/stable/markup/inline.html#role-any
:any: requires at least Sphinx 1.3 (for reference, Ubuntu 16.03 ships
with 1.3.6, the latest 1.6.3).
Any many of our docs, `symbol` is misused to specify arguments to
functions, etc. Refactoring that is in progress. (CODECONVENTIONS
already specify proper syntax for both arguments and xrefs, based
on CPython conventions).
This adds description of implied AbstractNIC base class, which should be
"subclasses" and implemented by a particular network device class.
This is just an initial step in that direction, the API and description
will be elabotated further.
The list starts with the simplest functionality - GPIO, proceeds to
communication interfaces (UART, SPI, I2C), the to time(r) related
things, then everything else.
For a couple of ports, there was information which directory is set
as current after boot. This information doesn't belong to "uos" module,
and is moved to boards' references (which actually already contained
information on which directory is chosen for boot, even if without
explicit mentioning that it becomes current directory, which is now
done).
