docs: Replace ufoo with foo in all docs.
Anywhere a module is mentioned, use its "non-u" name for consistency. The "import module" vs "import umodule" is something of a FAQ, and this commit intends to help clear that up. As a first approximation MicroPython is Python, and so imports should work the same as Python and use the same name, to a first approximation. The u-version of a module is a detail that can be learned later on, when the user wants to understand more and have finer control over importing. Existing Python code should just work, as much as it is possible to do that within the constraints of embedded systems, and the MicroPython documentation should match the idiomatic way to write Python code. With universal weak links for modules (via MICROPY_MODULE_WEAK_LINKS) users can consistently use "import foo" across all ports (with the exception of the minimal ports). And the ability to override/extend via "foo.py" continues to work well. Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
This commit is contained in:
parent
218606351c
commit
c737cde947
docs
develop
esp32
esp8266
library
array.rstbinascii.rstbluetooth.rstbtree.rstcollections.rstcryptolib.rsterrno.rstesp32.rsthashlib.rstheapq.rstindex.rstio.rstjson.rstmachine.SDCard.rstnetwork.WLAN.rstnetwork.rstos.rstpyb.Flash.rstpyb.rstre.rstrp2.Flash.rstselect.rstsocket.rstssl.rststruct.rstsys.rsttime.rstuctypes.rstzlib.rst
pyboard
reference
rp2
wipy
zephyr/tutorial
|
@ -34,7 +34,7 @@ An example is the ``gc`` module discussed in :ref:`memorymanagement`.
|
|||
>>> gc.enable()
|
||||
>>>
|
||||
|
||||
MicroPython has several other builtin standard/core modules like ``io``, ``uarray`` etc.
|
||||
MicroPython has several other builtin standard/core modules like ``io``, ``array`` etc.
|
||||
Adding a new core module involves several modifications.
|
||||
|
||||
First, create the ``C`` file in the ``py/`` directory. In this example we are adding a
|
||||
|
|
|
@ -245,8 +245,8 @@ That should give a MicroPython REPL. You can then run commands like:
|
|||
.. code-block:: bash
|
||||
|
||||
MicroPython v1.13 on 2021-01-01; example-board with unknown-cpu
|
||||
>>> import usys
|
||||
>>> usys.implementation
|
||||
>>> import sys
|
||||
>>> sys.implementation
|
||||
('micropython', (1, 13, 0))
|
||||
>>>
|
||||
|
||||
|
|
|
@ -98,7 +98,7 @@ A useful function for connecting to your local WiFi network is::
|
|||
pass
|
||||
print('network config:', wlan.ifconfig())
|
||||
|
||||
Once the network is established the :mod:`socket <usocket>` module can be used
|
||||
Once the network is established the :mod:`socket <socket>` module can be used
|
||||
to create and use TCP/UDP sockets as usual, and the ``urequests`` module for
|
||||
convenient HTTP requests.
|
||||
|
||||
|
@ -113,7 +113,7 @@ to reconnect forever).
|
|||
Delay and timing
|
||||
----------------
|
||||
|
||||
Use the :mod:`time <utime>` module::
|
||||
Use the :mod:`time <time>` module::
|
||||
|
||||
import time
|
||||
|
||||
|
@ -459,15 +459,15 @@ SD card
|
|||
|
||||
See :ref:`machine.SDCard <machine.SDCard>`. ::
|
||||
|
||||
import machine, uos
|
||||
import machine, os
|
||||
|
||||
# Slot 2 uses pins sck=18, cs=5, miso=19, mosi=23
|
||||
sd = machine.SDCard(slot=2)
|
||||
uos.mount(sd, "/sd") # mount
|
||||
os.mount(sd, "/sd") # mount
|
||||
|
||||
uos.listdir('/sd') # list directory contents
|
||||
os.listdir('/sd') # list directory contents
|
||||
|
||||
uos.umount('/sd') # eject
|
||||
os.umount('/sd') # eject
|
||||
|
||||
RMT
|
||||
---
|
||||
|
|
|
@ -117,7 +117,7 @@ Real-time clock
|
|||
|
||||
RTC in ESP8266 has very bad accuracy, drift may be seconds per minute. As
|
||||
a workaround, to measure short enough intervals you can use
|
||||
``utime.time()``, etc. functions, and for wall clock time, synchronize from
|
||||
``time.time()``, etc. functions, and for wall clock time, synchronize from
|
||||
the net using included ``ntptime.py`` module.
|
||||
|
||||
Due to limitations of the ESP8266 chip the internal real-time clock (RTC)
|
||||
|
@ -203,7 +203,7 @@ limitation with usage of TLS on the low-memory devices:
|
|||
communication with other devices.
|
||||
|
||||
There are also some not implemented features specifically in MicroPython's
|
||||
``ussl`` module based on axTLS:
|
||||
``ssl`` module based on axTLS:
|
||||
|
||||
6. Certificates are not validated (this makes connections susceptible
|
||||
to man-in-the-middle attacks).
|
||||
|
|
|
@ -78,13 +78,13 @@ A useful function for connecting to your local WiFi network is::
|
|||
pass
|
||||
print('network config:', wlan.ifconfig())
|
||||
|
||||
Once the network is established the :mod:`socket <usocket>` module can be used
|
||||
Once the network is established the :mod:`socket <socket>` module can be used
|
||||
to create and use TCP/UDP sockets as usual.
|
||||
|
||||
Delay and timing
|
||||
----------------
|
||||
|
||||
Use the :mod:`time <utime>` module::
|
||||
Use the :mod:`time <time>` module::
|
||||
|
||||
import time
|
||||
|
||||
|
@ -171,15 +171,15 @@ attaches the REPL).
|
|||
|
||||
To detach the REPL from UART0, use::
|
||||
|
||||
import uos
|
||||
uos.dupterm(None, 1)
|
||||
import os
|
||||
os.dupterm(None, 1)
|
||||
|
||||
The REPL is attached by default. If you have detached it, to reattach
|
||||
it use::
|
||||
|
||||
import uos, machine
|
||||
import os, machine
|
||||
uart = machine.UART(0, 115200)
|
||||
uos.dupterm(uart, 1)
|
||||
os.dupterm(uart, 1)
|
||||
|
||||
PWM (pulse width modulation)
|
||||
----------------------------
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
:mod:`uarray` -- arrays of numeric data
|
||||
=======================================
|
||||
:mod:`array` -- arrays of numeric data
|
||||
======================================
|
||||
|
||||
.. module:: uarray
|
||||
.. module:: array
|
||||
:synopsis: efficient arrays of numeric data
|
||||
|
||||
|see_cpython_module| :mod:`python:array`.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
:mod:`ubinascii` -- binary/ASCII conversions
|
||||
============================================
|
||||
:mod:`binascii` -- binary/ASCII conversions
|
||||
===========================================
|
||||
|
||||
.. module:: ubinascii
|
||||
.. module:: binascii
|
||||
:synopsis: binary/ASCII conversions
|
||||
|
||||
|see_cpython_module| :mod:`python:binascii`.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
:mod:`ubluetooth` --- low-level Bluetooth
|
||||
=========================================
|
||||
:mod:`bluetooth` --- low-level Bluetooth
|
||||
========================================
|
||||
|
||||
.. module:: ubluetooth
|
||||
.. module:: bluetooth
|
||||
:synopsis: Low-level Bluetooth radio functionality
|
||||
|
||||
This module provides an interface to a Bluetooth controller on a board.
|
||||
|
@ -110,7 +110,7 @@ Event Handling
|
|||
|
||||
**Note:** As an optimisation to prevent unnecessary allocations, the ``addr``,
|
||||
``adv_data``, ``char_data``, ``notify_data``, and ``uuid`` entries in the
|
||||
tuples are read-only memoryview instances pointing to ubluetooth's internal
|
||||
tuples are read-only memoryview instances pointing to :mod:`bluetooth`'s internal
|
||||
ringbuffer, and are only valid during the invocation of the IRQ handler
|
||||
function. If your program needs to save one of these values to access after
|
||||
the IRQ handler has returned (e.g. by saving it in a class instance or global
|
||||
|
@ -293,7 +293,7 @@ For the ``_IRQ_PASSKEY_ACTION`` event, the available actions are::
|
|||
_PASSKEY_ACTION_NUMERIC_COMPARISON = const(4)
|
||||
|
||||
In order to save space in the firmware, these constants are not included on the
|
||||
:mod:`ubluetooth` module. Add the ones that you need from the list above to your
|
||||
:mod:`bluetooth` module. Add the ones that you need from the list above to your
|
||||
program.
|
||||
|
||||
|
||||
|
|
|
@ -22,7 +22,7 @@ Example::
|
|||
|
||||
# First, we need to open a stream which holds a database
|
||||
# This is usually a file, but can be in-memory database
|
||||
# using uio.BytesIO, a raw flash partition, etc.
|
||||
# using io.BytesIO, a raw flash partition, etc.
|
||||
# Oftentimes, you want to create a database file if it doesn't
|
||||
# exist and open if it exists. Idiom below takes care of this.
|
||||
# DO NOT open database with "a+b" access mode.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
:mod:`ucollections` -- collection and container types
|
||||
=====================================================
|
||||
:mod:`collections` -- collection and container types
|
||||
====================================================
|
||||
|
||||
.. module:: ucollections
|
||||
.. module:: collections
|
||||
:synopsis: collection and container types
|
||||
|
||||
|see_cpython_module| :mod:`python:collections`.
|
||||
|
@ -49,7 +49,7 @@ Classes
|
|||
a string with space-separated field named (but this is less efficient).
|
||||
Example of use::
|
||||
|
||||
from ucollections import namedtuple
|
||||
from collections import namedtuple
|
||||
|
||||
MyTuple = namedtuple("MyTuple", ("id", "name"))
|
||||
t1 = MyTuple(1, "foo")
|
||||
|
@ -63,7 +63,7 @@ Classes
|
|||
added. When ordered dict is iterated over, keys/items are returned in
|
||||
the order they were added::
|
||||
|
||||
from ucollections import OrderedDict
|
||||
from collections import OrderedDict
|
||||
|
||||
# To make benefit of ordered keys, OrderedDict should be initialized
|
||||
# from sequence of (key, value) pairs.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
:mod:`ucryptolib` -- cryptographic ciphers
|
||||
==========================================
|
||||
:mod:`cryptolib` -- cryptographic ciphers
|
||||
=========================================
|
||||
|
||||
.. module:: ucryptolib
|
||||
.. module:: cryptolib
|
||||
:synopsis: cryptographic ciphers
|
||||
|
||||
Classes
|
||||
|
@ -21,9 +21,9 @@ Classes
|
|||
* *key* is an encryption/decryption key (bytes-like).
|
||||
* *mode* is:
|
||||
|
||||
* ``1`` (or ``ucryptolib.MODE_ECB`` if it exists) for Electronic Code Book (ECB).
|
||||
* ``2`` (or ``ucryptolib.MODE_CBC`` if it exists) for Cipher Block Chaining (CBC).
|
||||
* ``6`` (or ``ucryptolib.MODE_CTR`` if it exists) for Counter mode (CTR).
|
||||
* ``1`` (or ``cryptolib.MODE_ECB`` if it exists) for Electronic Code Book (ECB).
|
||||
* ``2`` (or ``cryptolib.MODE_CBC`` if it exists) for Cipher Block Chaining (CBC).
|
||||
* ``6`` (or ``cryptolib.MODE_CTR`` if it exists) for Counter mode (CTR).
|
||||
|
||||
* *IV* is an initialization vector for CBC mode.
|
||||
* For Counter mode, *IV* is the initial value for the counter.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
:mod:`uerrno` -- system error codes
|
||||
===================================
|
||||
:mod:`errno` -- system error codes
|
||||
==================================
|
||||
|
||||
.. module:: uerrno
|
||||
.. module:: errno
|
||||
:synopsis: system error codes
|
||||
|
||||
|see_cpython_module| :mod:`python:errno`.
|
||||
|
@ -20,9 +20,9 @@ Constants
|
|||
where ``exc`` is an instance of `OSError`. Usage example::
|
||||
|
||||
try:
|
||||
uos.mkdir("my_dir")
|
||||
os.mkdir("my_dir")
|
||||
except OSError as exc:
|
||||
if exc.errno == uerrno.EEXIST:
|
||||
if exc.errno == errno.EEXIST:
|
||||
print("Directory already exists")
|
||||
|
||||
.. data:: errorcode
|
||||
|
@ -30,5 +30,5 @@ Constants
|
|||
Dictionary mapping numeric error codes to strings with symbolic error
|
||||
code (see above)::
|
||||
|
||||
>>> print(uerrno.errorcode[uerrno.EEXIST])
|
||||
>>> print(errno.errorcode[errno.EEXIST])
|
||||
EEXIST
|
||||
|
|
|
@ -91,7 +91,7 @@ methods to enable over-the-air (OTA) updates.
|
|||
|
||||
These methods implement the simple and :ref:`extended
|
||||
<block-device-interface>` block protocol defined by
|
||||
:class:`uos.AbstractBlockDev`.
|
||||
:class:`os.AbstractBlockDev`.
|
||||
|
||||
.. method:: Partition.set_boot()
|
||||
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
:mod:`uhashlib` -- hashing algorithms
|
||||
=====================================
|
||||
:mod:`hashlib` -- hashing algorithms
|
||||
====================================
|
||||
|
||||
.. module:: uhashlib
|
||||
.. module:: hashlib
|
||||
:synopsis: hashing algorithms
|
||||
|
||||
|see_cpython_module| :mod:`python:hashlib`.
|
||||
|
@ -27,15 +27,15 @@ be implemented:
|
|||
Constructors
|
||||
------------
|
||||
|
||||
.. class:: uhashlib.sha256([data])
|
||||
.. class:: hashlib.sha256([data])
|
||||
|
||||
Create an SHA256 hasher object and optionally feed ``data`` into it.
|
||||
|
||||
.. class:: uhashlib.sha1([data])
|
||||
.. class:: hashlib.sha1([data])
|
||||
|
||||
Create an SHA1 hasher object and optionally feed ``data`` into it.
|
||||
|
||||
.. class:: uhashlib.md5([data])
|
||||
.. class:: hashlib.md5([data])
|
||||
|
||||
Create an MD5 hasher object and optionally feed ``data`` into it.
|
||||
|
||||
|
@ -53,5 +53,5 @@ Methods
|
|||
|
||||
.. method:: hash.hexdigest()
|
||||
|
||||
This method is NOT implemented. Use ``ubinascii.hexlify(hash.digest())``
|
||||
This method is NOT implemented. Use ``binascii.hexlify(hash.digest())``
|
||||
to achieve a similar effect.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
:mod:`uheapq` -- heap queue algorithm
|
||||
=====================================
|
||||
:mod:`heapq` -- heap queue algorithm
|
||||
====================================
|
||||
|
||||
.. module:: uheapq
|
||||
.. module:: heapq
|
||||
:synopsis: heap queue algorithm
|
||||
|
||||
|see_cpython_module| :mod:`python:heapq`.
|
||||
|
|
|
@ -56,7 +56,7 @@ The following standard Python libraries have been "micro-ified" to fit in with
|
|||
the philosophy of MicroPython. They provide the core functionality of that
|
||||
module and are intended to be a drop-in replacement for the standard Python
|
||||
library. Some modules below use a standard Python name, but prefixed with "u",
|
||||
e.g. ``ujson`` instead of ``json``. This is to signify that such a module is
|
||||
e.g. ``json`` instead of ``json``. This is to signify that such a module is
|
||||
micro-library, i.e. implements only a subset of CPython module functionality.
|
||||
By naming them differently, a user has a choice to write a Python-level module
|
||||
to extend functionality for better compatibility with CPython (indeed, this is
|
||||
|
@ -68,7 +68,7 @@ are available both by their u-name, and also by their non-u-name. The
|
|||
non-u-name can be overridden by a file of that name in your library path (``sys.path``).
|
||||
For example, ``import json`` will first search for a file ``json.py`` (or package
|
||||
directory ``json``) and load that module if it is found. If nothing is found,
|
||||
it will fallback to loading the built-in ``ujson`` module.
|
||||
it will fallback to loading the built-in ``json`` module.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
:mod:`uio` -- input/output streams
|
||||
==================================
|
||||
:mod:`io` -- input/output streams
|
||||
=================================
|
||||
|
||||
.. module:: uio
|
||||
.. module:: io
|
||||
:synopsis: input/output streams
|
||||
|
||||
|see_cpython_module| :mod:`python:io`.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
:mod:`ujson` -- JSON encoding and decoding
|
||||
==========================================
|
||||
:mod:`json` -- JSON encoding and decoding
|
||||
=========================================
|
||||
|
||||
.. module:: ujson
|
||||
.. module:: json
|
||||
:synopsis: JSON encoding and decoding
|
||||
|
||||
|see_cpython_module| :mod:`python:json`.
|
||||
|
|
|
@ -27,10 +27,10 @@ vary from platform to platform.
|
|||
|
||||
This class provides access to SD or MMC storage cards using either
|
||||
a dedicated SD/MMC interface hardware or through an SPI channel.
|
||||
The class implements the block protocol defined by :class:`uos.AbstractBlockDev`.
|
||||
The class implements the block protocol defined by :class:`os.AbstractBlockDev`.
|
||||
This allows the mounting of an SD card to be as simple as::
|
||||
|
||||
uos.mount(machine.SDCard(), "/sd")
|
||||
os.mount(machine.SDCard(), "/sd")
|
||||
|
||||
The constructor takes the following parameters:
|
||||
|
||||
|
|
|
@ -55,7 +55,7 @@ Methods
|
|||
(ssid, bssid, channel, RSSI, authmode, hidden)
|
||||
|
||||
*bssid* is hardware address of an access point, in binary form, returned as
|
||||
bytes object. You can use `ubinascii.hexlify()` to convert it to ASCII form.
|
||||
bytes object. You can use `binascii.hexlify()` to convert it to ASCII form.
|
||||
|
||||
There are five values for authmode:
|
||||
|
||||
|
|
|
@ -9,7 +9,7 @@ This module provides network drivers and routing configuration. To use this
|
|||
module, a MicroPython variant/build with network capabilities must be installed.
|
||||
Network drivers for specific hardware are available within this module and are
|
||||
used to configure hardware network interface(s). Network services provided
|
||||
by configured interfaces are then available for use via the :mod:`usocket`
|
||||
by configured interfaces are then available for use via the :mod:`socket`
|
||||
module.
|
||||
|
||||
For example::
|
||||
|
@ -17,17 +17,17 @@ For example::
|
|||
# connect/ show IP config a specific network interface
|
||||
# see below for examples of specific drivers
|
||||
import network
|
||||
import utime
|
||||
import time
|
||||
nic = network.Driver(...)
|
||||
if not nic.isconnected():
|
||||
nic.connect()
|
||||
print("Waiting for connection...")
|
||||
while not nic.isconnected():
|
||||
utime.sleep(1)
|
||||
time.sleep(1)
|
||||
print(nic.ifconfig())
|
||||
|
||||
# now use usocket as usual
|
||||
import usocket as socket
|
||||
# now use socket as usual
|
||||
import socket as socket
|
||||
addr = socket.getaddrinfo('micropython.org', 80)[0][-1]
|
||||
s = socket.socket()
|
||||
s.connect(addr)
|
||||
|
|
|
@ -1,12 +1,12 @@
|
|||
:mod:`uos` -- basic "operating system" services
|
||||
===============================================
|
||||
:mod:`os` -- basic "operating system" services
|
||||
==============================================
|
||||
|
||||
.. module:: uos
|
||||
.. module:: os
|
||||
:synopsis: basic "operating system" services
|
||||
|
||||
|see_cpython_module| :mod:`python:os`.
|
||||
|
||||
The ``uos`` module contains functions for filesystem access and mounting,
|
||||
The ``os`` module contains functions for filesystem access and mounting,
|
||||
terminal redirection and duplication, and the ``uname`` and ``urandom``
|
||||
functions.
|
||||
|
||||
|
@ -116,7 +116,7 @@ Terminal redirection and duplication
|
|||
|
||||
Duplicate or switch the MicroPython terminal (the REPL) on the given `stream`-like
|
||||
object. The *stream_object* argument must be a native stream object, or derive
|
||||
from ``uio.IOBase`` and implement the ``readinto()`` and
|
||||
from ``io.IOBase`` and implement the ``readinto()`` and
|
||||
``write()`` methods. The stream should be in non-blocking mode and
|
||||
``readinto()`` should return ``None`` if there is no data available for reading.
|
||||
|
||||
|
@ -207,7 +207,7 @@ represented by VFS classes.
|
|||
otherwise the timestamps will remain untouched. Littlefs v2 filesystems without
|
||||
timestamps will work without reformatting and timestamps will be added
|
||||
transparently to existing files once they are opened for writing. When *mtime*
|
||||
is enabled `uos.stat` on files without timestamps will return 0 for the timestamp.
|
||||
is enabled `os.stat` on files without timestamps will return 0 for the timestamp.
|
||||
|
||||
See :ref:`filesystem` for more information.
|
||||
|
||||
|
@ -234,7 +234,7 @@ but an actual block device class must implement the methods described below.
|
|||
|
||||
A concrete implementation of this class will usually allow access to the
|
||||
memory-like functionality of a piece of hardware (like flash memory). A block
|
||||
device can be formatted to any supported filesystem and mounted using ``uos``
|
||||
device can be formatted to any supported filesystem and mounted using ``os``
|
||||
methods.
|
||||
|
||||
See :ref:`filesystem` for example implementations of block devices using the
|
||||
|
|
|
@ -43,7 +43,7 @@ Methods
|
|||
|
||||
These methods implement the simple and :ref:`extended
|
||||
<block-device-interface>` block protocol defined by
|
||||
:class:`uos.AbstractBlockDev`.
|
||||
:class:`os.AbstractBlockDev`.
|
||||
|
||||
Hardware Note
|
||||
-------------
|
||||
|
|
|
@ -213,11 +213,11 @@ Miscellaneous functions
|
|||
.. function:: mount(device, mountpoint, *, readonly=False, mkfs=False)
|
||||
|
||||
.. note:: This function is deprecated. Mounting and unmounting devices should
|
||||
be performed by :meth:`uos.mount` and :meth:`uos.umount` instead.
|
||||
be performed by :meth:`os.mount` and :meth:`os.umount` instead.
|
||||
|
||||
Mount a block device and make it available as part of the filesystem.
|
||||
``device`` must be an object that provides the block protocol. (The
|
||||
following is also deprecated. See :class:`uos.AbstractBlockDev` for the
|
||||
following is also deprecated. See :class:`os.AbstractBlockDev` for the
|
||||
correct way to create a block device.)
|
||||
|
||||
- ``readblocks(self, blocknum, buf)``
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
:mod:`ure` -- simple regular expressions
|
||||
========================================
|
||||
:mod:`re` -- simple regular expressions
|
||||
=======================================
|
||||
|
||||
.. module:: ure
|
||||
.. module:: re
|
||||
:synopsis: regular expressions
|
||||
|
||||
|see_cpython_module| :mod:`python:re`.
|
||||
|
@ -95,11 +95,11 @@ Supported operators and special sequences are:
|
|||
|
||||
Example::
|
||||
|
||||
import ure
|
||||
import re
|
||||
|
||||
# As ure doesn't support escapes itself, use of r"" strings is not
|
||||
# As re doesn't support escapes itself, use of r"" strings is not
|
||||
# recommended.
|
||||
regex = ure.compile("[\r\n]")
|
||||
regex = re.compile("[\r\n]")
|
||||
|
||||
regex.split("line1\rline2\nline3\r\n")
|
||||
|
||||
|
@ -152,7 +152,7 @@ Regex objects
|
|||
-------------
|
||||
|
||||
Compiled regular expression. Instances of this class are created using
|
||||
`ure.compile()`.
|
||||
`re.compile()`.
|
||||
|
||||
.. method:: regex.match(string)
|
||||
regex.search(string)
|
||||
|
|
|
@ -32,5 +32,5 @@ Methods
|
|||
|
||||
These methods implement the simple and extended
|
||||
:ref:`block protocol <block-device-interface>` defined by
|
||||
:class:`uos.AbstractBlockDev`.
|
||||
:class:`os.AbstractBlockDev`.
|
||||
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
:mod:`uselect` -- wait for events on a set of streams
|
||||
========================================================================
|
||||
:mod:`select` -- wait for events on a set of streams
|
||||
====================================================
|
||||
|
||||
.. module:: uselect
|
||||
.. module:: select
|
||||
:synopsis: wait for events on a set of streams
|
||||
|
||||
|see_cpython_module| :mod:`python:select`.
|
||||
|
@ -35,15 +35,15 @@ Methods
|
|||
|
||||
Register `stream` *obj* for polling. *eventmask* is logical OR of:
|
||||
|
||||
* ``uselect.POLLIN`` - data available for reading
|
||||
* ``uselect.POLLOUT`` - more data can be written
|
||||
* ``select.POLLIN`` - data available for reading
|
||||
* ``select.POLLOUT`` - more data can be written
|
||||
|
||||
Note that flags like ``uselect.POLLHUP`` and ``uselect.POLLERR`` are
|
||||
Note that flags like ``select.POLLHUP`` and ``select.POLLERR`` are
|
||||
*not* valid as input eventmask (these are unsolicited events which
|
||||
will be returned from `poll()` regardless of whether they are asked
|
||||
for). This semantics is per POSIX.
|
||||
|
||||
*eventmask* defaults to ``uselect.POLLIN | uselect.POLLOUT``.
|
||||
*eventmask* defaults to ``select.POLLIN | select.POLLOUT``.
|
||||
|
||||
It is OK to call this function multiple times for the same *obj*.
|
||||
Successive calls will update *obj*'s eventmask to the value of
|
||||
|
@ -67,8 +67,8 @@ Methods
|
|||
Returns list of (``obj``, ``event``, ...) tuples. There may be other elements in
|
||||
tuple, depending on a platform and version, so don't assume that its size is 2.
|
||||
The ``event`` element specifies which events happened with a stream and
|
||||
is a combination of ``uselect.POLL*`` constants described above. Note that
|
||||
flags ``uselect.POLLHUP`` and ``uselect.POLLERR`` can be returned at any time
|
||||
is a combination of ``select.POLL*`` constants described above. Note that
|
||||
flags ``select.POLLHUP`` and ``select.POLLERR`` can be returned at any time
|
||||
(even if were not asked for), and must be acted on accordingly (the
|
||||
corresponding stream unregistered from poll and likely closed), because
|
||||
otherwise all further invocations of `poll()` may return immediately with
|
||||
|
|
|
@ -1,8 +1,8 @@
|
|||
*******************************
|
||||
:mod:`usocket` -- socket module
|
||||
*******************************
|
||||
******************************
|
||||
:mod:`socket` -- socket module
|
||||
******************************
|
||||
|
||||
.. module:: usocket
|
||||
.. module:: socket
|
||||
:synopsis: socket module
|
||||
|
||||
|see_cpython_module| :mod:`python:socket`.
|
||||
|
@ -21,13 +21,13 @@ This module provides access to the BSD socket interface.
|
|||
Socket address format(s)
|
||||
------------------------
|
||||
|
||||
The native socket address format of the ``usocket`` module is an opaque data type
|
||||
The native socket address format of the ``socket`` module is an opaque data type
|
||||
returned by `getaddrinfo` function, which must be used to resolve textual address
|
||||
(including numeric addresses)::
|
||||
|
||||
sockaddr = usocket.getaddrinfo('www.micropython.org', 80)[0][-1]
|
||||
sockaddr = socket.getaddrinfo('www.micropython.org', 80)[0][-1]
|
||||
# You must use getaddrinfo() even for numeric addresses
|
||||
sockaddr = usocket.getaddrinfo('127.0.0.1', 80)[0][-1]
|
||||
sockaddr = socket.getaddrinfo('127.0.0.1', 80)[0][-1]
|
||||
# Now you can use that address
|
||||
sock.connect(addr)
|
||||
|
||||
|
@ -35,7 +35,7 @@ Using `getaddrinfo` is the most efficient (both in terms of memory and processin
|
|||
power) and portable way to work with addresses.
|
||||
|
||||
However, ``socket`` module (note the difference with native MicroPython
|
||||
``usocket`` module described here) provides CPython-compatible way to specify
|
||||
``socket`` module described here) provides CPython-compatible way to specify
|
||||
addresses using tuples, as described below. Note that depending on a
|
||||
:term:`MicroPython port`, ``socket`` module can be builtin or need to be
|
||||
installed from `micropython-lib` (as in the case of :term:`MicroPython Unix port`),
|
||||
|
@ -54,13 +54,13 @@ Tuple address format for ``socket`` module:
|
|||
dot-notation numeric IPv4 address, e.g. ``"8.8.8.8"``, and *port* is and
|
||||
integer port number in the range 1-65535. Note the domain names are not
|
||||
accepted as *ipv4_address*, they should be resolved first using
|
||||
`usocket.getaddrinfo()`.
|
||||
`socket.getaddrinfo()`.
|
||||
* IPv6: *(ipv6_address, port, flowinfo, scopeid)*, where *ipv6_address*
|
||||
is a string with colon-notation numeric IPv6 address, e.g. ``"2001:db8::1"``,
|
||||
and *port* is an integer port number in the range 1-65535. *flowinfo*
|
||||
must be 0. *scopeid* is the interface scope identifier for link-local
|
||||
addresses. Note the domain names are not accepted as *ipv6_address*,
|
||||
they should be resolved first using `usocket.getaddrinfo()`. Availability
|
||||
they should be resolved first using `socket.getaddrinfo()`. Availability
|
||||
of IPv6 support depends on a :term:`MicroPython port`.
|
||||
|
||||
Functions
|
||||
|
@ -94,17 +94,17 @@ Functions
|
|||
|
||||
The following example shows how to connect to a given url::
|
||||
|
||||
s = usocket.socket()
|
||||
s = socket.socket()
|
||||
# This assumes that if "type" is not specified, an address for
|
||||
# SOCK_STREAM will be returned, which may be not true
|
||||
s.connect(usocket.getaddrinfo('www.micropython.org', 80)[0][-1])
|
||||
s.connect(socket.getaddrinfo('www.micropython.org', 80)[0][-1])
|
||||
|
||||
Recommended use of filtering params::
|
||||
|
||||
s = usocket.socket()
|
||||
s = socket.socket()
|
||||
# Guaranteed to return an address which can be connect'ed to for
|
||||
# stream operation.
|
||||
s.connect(usocket.getaddrinfo('www.micropython.org', 80, 0, SOCK_STREAM)[0][-1])
|
||||
s.connect(socket.getaddrinfo('www.micropython.org', 80, 0, SOCK_STREAM)[0][-1])
|
||||
|
||||
.. admonition:: Difference to CPython
|
||||
:class: attention
|
||||
|
@ -113,7 +113,7 @@ Functions
|
|||
of error in this function. MicroPython doesn't have ``socket.gaierror``
|
||||
and raises OSError directly. Note that error numbers of `getaddrinfo()`
|
||||
form a separate namespace and may not match error numbers from
|
||||
the :mod:`uerrno` module. To distinguish `getaddrinfo()` errors, they are
|
||||
the :mod:`errno` module. To distinguish `getaddrinfo()` errors, they are
|
||||
represented by negative numbers, whereas standard system errors are
|
||||
positive numbers (error numbers are accessible using ``e.args[0]`` property
|
||||
from an exception object). The use of negative values is a provisional
|
||||
|
@ -124,7 +124,7 @@ Functions
|
|||
Convert a binary network address *bin_addr* of the given address family *af*
|
||||
to a textual representation::
|
||||
|
||||
>>> usocket.inet_ntop(usocket.AF_INET, b"\x7f\0\0\1")
|
||||
>>> socket.inet_ntop(socket.AF_INET, b"\x7f\0\0\1")
|
||||
'127.0.0.1'
|
||||
|
||||
.. function:: inet_pton(af, txt_addr)
|
||||
|
@ -132,7 +132,7 @@ Functions
|
|||
Convert a textual network address *txt_addr* of the given address family *af*
|
||||
to a binary representation::
|
||||
|
||||
>>> usocket.inet_pton(usocket.AF_INET, "1.2.3.4")
|
||||
>>> socket.inet_pton(socket.AF_INET, "1.2.3.4")
|
||||
b'\x01\x02\x03\x04'
|
||||
|
||||
Constants
|
||||
|
@ -152,17 +152,17 @@ Constants
|
|||
IPPROTO_TCP
|
||||
|
||||
IP protocol numbers. Availability depends on a particular :term:`MicroPython port`.
|
||||
Note that you don't need to specify these in a call to `usocket.socket()`,
|
||||
Note that you don't need to specify these in a call to `socket.socket()`,
|
||||
because `SOCK_STREAM` socket type automatically selects `IPPROTO_TCP`, and
|
||||
`SOCK_DGRAM` - `IPPROTO_UDP`. Thus, the only real use of these constants
|
||||
is as an argument to `setsockopt()`.
|
||||
|
||||
.. data:: usocket.SOL_*
|
||||
.. data:: socket.SOL_*
|
||||
|
||||
Socket option levels (an argument to `setsockopt()`). The exact
|
||||
inventory depends on a :term:`MicroPython port`.
|
||||
|
||||
.. data:: usocket.SO_*
|
||||
.. data:: socket.SO_*
|
||||
|
||||
Socket options (an argument to `setsockopt()`). The exact
|
||||
inventory depends on a :term:`MicroPython port`.
|
||||
|
@ -260,7 +260,7 @@ Methods
|
|||
is put in blocking mode.
|
||||
|
||||
Not every :term:`MicroPython port` supports this method. A more portable and
|
||||
generic solution is to use `uselect.poll` object. This allows to wait on
|
||||
generic solution is to use `select.poll` object. This allows to wait on
|
||||
multiple objects at the same time (and not just on sockets, but on generic
|
||||
`stream` objects which support polling). Example::
|
||||
|
||||
|
@ -269,8 +269,8 @@ Methods
|
|||
s.read(10) # may timeout
|
||||
|
||||
# Use:
|
||||
poller = uselect.poll()
|
||||
poller.register(s, uselect.POLLIN)
|
||||
poller = select.poll()
|
||||
poller.register(s, select.POLLIN)
|
||||
res = poller.poll(1000) # time in milliseconds
|
||||
if not res:
|
||||
# s is still not ready for input, i.e. operation timed out
|
||||
|
@ -342,7 +342,7 @@ Methods
|
|||
|
||||
Return value: number of bytes written.
|
||||
|
||||
.. exception:: usocket.error
|
||||
.. exception:: socket.error
|
||||
|
||||
MicroPython does NOT have this exception.
|
||||
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
:mod:`ussl` -- SSL/TLS module
|
||||
=============================
|
||||
:mod:`ssl` -- SSL/TLS module
|
||||
============================
|
||||
|
||||
.. module:: ussl
|
||||
.. module:: ssl
|
||||
:synopsis: TLS/SSL wrapper for socket objects
|
||||
|
||||
|see_cpython_module| :mod:`python:ssl`.
|
||||
|
@ -13,14 +13,14 @@ facilities for network sockets, both client-side and server-side.
|
|||
Functions
|
||||
---------
|
||||
|
||||
.. function:: ussl.wrap_socket(sock, server_side=False, keyfile=None, certfile=None, cert_reqs=CERT_NONE, ca_certs=None, do_handshake=True)
|
||||
.. function:: ssl.wrap_socket(sock, server_side=False, keyfile=None, certfile=None, cert_reqs=CERT_NONE, ca_certs=None, do_handshake=True)
|
||||
|
||||
Takes a `stream` *sock* (usually usocket.socket instance of ``SOCK_STREAM`` type),
|
||||
Takes a `stream` *sock* (usually socket.socket instance of ``SOCK_STREAM`` type),
|
||||
and returns an instance of ssl.SSLSocket, which wraps the underlying stream in
|
||||
an SSL context. Returned object has the usual `stream` interface methods like
|
||||
``read()``, ``write()``, etc.
|
||||
A server-side SSL socket should be created from a normal socket returned from
|
||||
:meth:`~usocket.socket.accept()` on a non-SSL listening server socket.
|
||||
:meth:`~socket.socket.accept()` on a non-SSL listening server socket.
|
||||
|
||||
- *do_handshake* determines whether the handshake is done as part of the ``wrap_socket``
|
||||
or whether it is deferred to be done as part of the initial reads or writes
|
||||
|
@ -36,7 +36,7 @@ Functions
|
|||
|
||||
.. warning::
|
||||
|
||||
Some implementations of ``ussl`` module do NOT validate server certificates,
|
||||
Some implementations of ``ssl`` module do NOT validate server certificates,
|
||||
which makes an SSL connection established prone to man-in-the-middle attacks.
|
||||
|
||||
CPython's ``wrap_socket`` returns an ``SSLSocket`` object which has methods typical
|
||||
|
@ -54,8 +54,8 @@ Exceptions
|
|||
Constants
|
||||
---------
|
||||
|
||||
.. data:: ussl.CERT_NONE
|
||||
ussl.CERT_OPTIONAL
|
||||
ussl.CERT_REQUIRED
|
||||
.. data:: ssl.CERT_NONE
|
||||
ssl.CERT_OPTIONAL
|
||||
ssl.CERT_REQUIRED
|
||||
|
||||
Supported values for *cert_reqs* parameter.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
:mod:`ustruct` -- pack and unpack primitive data types
|
||||
======================================================
|
||||
:mod:`struct` -- pack and unpack primitive data types
|
||||
=====================================================
|
||||
|
||||
.. module:: ustruct
|
||||
.. module:: struct
|
||||
:synopsis: pack and unpack primitive data types
|
||||
|
||||
|see_cpython_module| :mod:`python:struct`.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
:mod:`usys` -- system specific functions
|
||||
========================================
|
||||
:mod:`sys` -- system specific functions
|
||||
=======================================
|
||||
|
||||
.. module:: usys
|
||||
.. module:: sys
|
||||
:synopsis: system specific functions
|
||||
|
||||
|see_cpython_module| :mod:`python:sys`.
|
||||
|
@ -28,10 +28,10 @@ Functions
|
|||
This function is a MicroPython extension intended to provide similar
|
||||
functionality to the :mod:`atexit` module in CPython.
|
||||
|
||||
.. function:: print_exception(exc, file=usys.stdout, /)
|
||||
.. function:: print_exception(exc, file=sys.stdout, /)
|
||||
|
||||
Print exception with a traceback to a file-like object *file* (or
|
||||
`usys.stdout` by default).
|
||||
`sys.stdout` by default).
|
||||
|
||||
.. admonition:: Difference to CPython
|
||||
:class: attention
|
||||
|
@ -84,7 +84,7 @@ Constants
|
|||
value directly, but instead count number of bits in it::
|
||||
|
||||
bits = 0
|
||||
v = usys.maxsize
|
||||
v = sys.maxsize
|
||||
while v:
|
||||
bits += 1
|
||||
v >>= 1
|
||||
|
@ -113,7 +113,7 @@ Constants
|
|||
is an identifier of a board, e.g. ``"pyboard"`` for the original MicroPython
|
||||
reference board. It thus can be used to distinguish one board from another.
|
||||
If you need to check whether your program runs on MicroPython (vs other
|
||||
Python implementation), use `usys.implementation` instead.
|
||||
Python implementation), use `sys.implementation` instead.
|
||||
|
||||
.. data:: stderr
|
||||
|
||||
|
|
|
@ -1,12 +1,12 @@
|
|||
:mod:`utime` -- time related functions
|
||||
======================================
|
||||
:mod:`time` -- time related functions
|
||||
=====================================
|
||||
|
||||
.. module:: utime
|
||||
.. module:: time
|
||||
:synopsis: time related functions
|
||||
|
||||
|see_cpython_module| :mod:`python:time`.
|
||||
|
||||
The ``utime`` module provides functions for getting the current time and date,
|
||||
The ``time`` module provides functions for getting the current time and date,
|
||||
measuring time intervals, and for delays.
|
||||
|
||||
**Time Epoch**: Unix port uses standard for POSIX systems epoch of
|
||||
|
@ -119,7 +119,7 @@ Functions
|
|||
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
|
||||
(resolution) of this function is not specified on ``utime`` module level, but
|
||||
(resolution) of this function is not specified on ``time`` module level, but
|
||||
documentation for a specific port may provide more specific information. This
|
||||
function is intended for very fine benchmarking or very tight real-time loops.
|
||||
Avoid using it in portable code.
|
||||
|
|
|
@ -19,7 +19,7 @@ sub-fields.
|
|||
|
||||
.. seealso::
|
||||
|
||||
Module :mod:`ustruct`
|
||||
Module :mod:`struct`
|
||||
Standard Python way to access binary data structures (doesn't scale
|
||||
well to large and complex structures).
|
||||
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
:mod:`uzlib` -- zlib decompression
|
||||
==================================
|
||||
:mod:`zlib` -- zlib decompression
|
||||
=================================
|
||||
|
||||
.. module:: uzlib
|
||||
.. module:: zlib
|
||||
:synopsis: zlib decompression
|
||||
|
||||
|see_cpython_module| :mod:`python:zlib`.
|
||||
|
|
|
@ -45,7 +45,7 @@ See :mod:`pyb`. ::
|
|||
Delay and timing
|
||||
----------------
|
||||
|
||||
Use the :mod:`time <utime>` module::
|
||||
Use the :mod:`time <time>` module::
|
||||
|
||||
import time
|
||||
|
||||
|
|
|
@ -122,7 +122,7 @@ execution from Flash, RAM may be saved as follows. The data should be located in
|
|||
Python modules and frozen as bytecode. The data must be defined as `bytes`
|
||||
objects. The compiler 'knows' that `bytes` objects are immutable and ensures
|
||||
that the objects remain in flash memory rather than being copied to RAM. The
|
||||
`ustruct` module can assist in converting between `bytes` types and other
|
||||
`struct` module can assist in converting between `bytes` types and other
|
||||
Python built-in types.
|
||||
|
||||
When considering the implications of frozen bytecode, note that in Python
|
||||
|
@ -261,7 +261,7 @@ were a string.
|
|||
The Python funcitons `eval` and `exec` invoke the compiler at runtime, which
|
||||
requires significant amounts of RAM. Note that the ``pickle`` library from
|
||||
`micropython-lib` employs `exec`. It may be more RAM efficient to use the
|
||||
`ujson` library for object serialisation.
|
||||
`json` library for object serialisation.
|
||||
|
||||
**Storing strings in flash**
|
||||
|
||||
|
@ -444,7 +444,7 @@ RAM usage and speed.
|
|||
|
||||
Where variables are required whose size is neither a byte nor a machine word
|
||||
there are standard libraries which can assist in storing these efficiently and
|
||||
in performing conversions. See the `array`, `ustruct` and `uctypes`
|
||||
in performing conversions. See the `array`, `struct` and `uctypes`
|
||||
modules.
|
||||
|
||||
Footnote: gc.collect() return value
|
||||
|
|
|
@ -40,7 +40,7 @@ Block devices
|
|||
-------------
|
||||
|
||||
A block device is an instance of a class that implements the
|
||||
:class:`uos.AbstractBlockDev` protocol.
|
||||
:class:`os.AbstractBlockDev` protocol.
|
||||
|
||||
Built-in block devices
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
@ -116,8 +116,8 @@ It can be used as follows::
|
|||
|
||||
An example of a block device that supports both the simple and extended
|
||||
interface (i.e. both signatures and behaviours of the
|
||||
:meth:`uos.AbstractBlockDev.readblocks` and
|
||||
:meth:`uos.AbstractBlockDev.writeblocks` methods) is::
|
||||
:meth:`os.AbstractBlockDev.readblocks` and
|
||||
:meth:`os.AbstractBlockDev.writeblocks` methods) is::
|
||||
|
||||
class RAMBlockDev:
|
||||
def __init__(self, block_size, num_blocks):
|
||||
|
@ -148,7 +148,7 @@ interface (i.e. both signatures and behaviours of the
|
|||
return 0
|
||||
|
||||
As it supports the extended interface, it can be used with :class:`littlefs
|
||||
<uos.VfsLfs2>`::
|
||||
<os.VfsLfs2>`::
|
||||
|
||||
import os
|
||||
|
||||
|
@ -166,8 +166,8 @@ normally would be used from Python code, for example::
|
|||
Filesystems
|
||||
-----------
|
||||
|
||||
MicroPython ports can provide implementations of :class:`FAT <uos.VfsFat>`,
|
||||
:class:`littlefs v1 <uos.VfsLfs1>` and :class:`littlefs v2 <uos.VfsLfs2>`.
|
||||
MicroPython ports can provide implementations of :class:`FAT <os.VfsFat>`,
|
||||
:class:`littlefs v1 <os.VfsLfs1>` and :class:`littlefs v2 <os.VfsLfs2>`.
|
||||
|
||||
The following table shows which filesystems are included in the firmware by
|
||||
default for given port/board combinations, however they can be optionally
|
||||
|
|
|
@ -184,7 +184,7 @@ Glossary
|
|||
``close()``, etc. A stream is an important concept in MicroPython;
|
||||
many I/O objects implement the stream interface, and thus can be used
|
||||
consistently and interchangeably in different contexts. For more
|
||||
information on streams in MicroPython, see the `uio` module.
|
||||
information on streams in MicroPython, see the `io` module.
|
||||
|
||||
UART
|
||||
Acronym for "Universal Asynchronous Receiver/Transmitter". This is a
|
||||
|
|
|
@ -123,7 +123,7 @@ This is a process known as profiling and is covered in textbooks and
|
|||
(for standard Python) supported by various software tools. For the type of
|
||||
smaller embedded application likely to be running on MicroPython platforms
|
||||
the slowest function or method can usually be established by judicious use
|
||||
of the timing ``ticks`` group of functions documented in `utime`.
|
||||
of the timing ``ticks`` group of functions documented in `time`.
|
||||
Code execution time can be measured in ms, us, or CPU cycles.
|
||||
|
||||
The following enables any function or method to be timed by adding an
|
||||
|
@ -134,9 +134,9 @@ The following enables any function or method to be timed by adding an
|
|||
def timed_function(f, *args, **kwargs):
|
||||
myname = str(f).split(' ')[1]
|
||||
def new_func(*args, **kwargs):
|
||||
t = utime.ticks_us()
|
||||
t = time.ticks_us()
|
||||
result = f(*args, **kwargs)
|
||||
delta = utime.ticks_diff(utime.ticks_us(), t)
|
||||
delta = time.ticks_diff(time.ticks_us(), t)
|
||||
print('Function {} Time = {:6.3f}ms'.format(myname, delta/1000))
|
||||
return result
|
||||
return new_func
|
||||
|
|
|
@ -45,7 +45,7 @@ The :mod:`rp2` module::
|
|||
Delay and timing
|
||||
----------------
|
||||
|
||||
Use the :mod:`time <utime>` module::
|
||||
Use the :mod:`time <time>` module::
|
||||
|
||||
import time
|
||||
|
||||
|
|
|
@ -296,8 +296,8 @@ and put it in '/flash/cert/'. Then do::
|
|||
ss = ssl.wrap_socket(s, cert_reqs=ssl.CERT_REQUIRED, ca_certs='/flash/cert/ca.pem')
|
||||
ss.connect(socket.getaddrinfo('cloud.blynk.cc', 8441)[0][-1])
|
||||
|
||||
Incompatibilities in uhashlib module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Incompatibilities in hashlib module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Due to hardware implementation details of the WiPy, data must be buffered before being
|
||||
digested, which would make it impossible to calculate the hash of big blocks of data that
|
||||
|
@ -310,7 +310,7 @@ initial one) is a multiple of 4 bytes.** The last chunk may be of any length.
|
|||
|
||||
Example::
|
||||
|
||||
hash = uhashlib.sha1('abcd1234', 1001) # length of the initial piece is multiple of 4 bytes
|
||||
hash = hashlib.sha1('abcd1234', 1001) # length of the initial piece is multiple of 4 bytes
|
||||
hash.update('1234') # also multiple of 4 bytes
|
||||
...
|
||||
hash.update('12345') # last chunk may be of any length
|
||||
|
@ -366,7 +366,7 @@ Adhoc VFS-like support
|
|||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
WiPy doesn't implement full MicroPython VFS support, instead following
|
||||
functions are defined in ``uos`` module:
|
||||
functions are defined in ``os`` module:
|
||||
|
||||
.. function:: mount(block_device, mount_point, \*, readonly=False)
|
||||
|
||||
|
|
|
@ -6,14 +6,14 @@ Filesystems and Storage
|
|||
Storage modules support virtual filesystem with FAT and littlefs formats, backed by either
|
||||
Zephyr DiskAccess or FlashArea (flash map) APIs depending on which the board supports.
|
||||
|
||||
See `uos Filesystem Mounting <https://docs.micropython.org/en/latest/library/uos.html?highlight=os#filesystem-mounting>`_.
|
||||
See `os Filesystem Mounting <https://docs.micropython.org/en/latest/library/os.html?highlight=os#filesystem-mounting>`_.
|
||||
|
||||
Disk Access
|
||||
-----------
|
||||
|
||||
The :ref:`zephyr.DiskAccess <zephyr.DiskAccess>` class can be used to access storage devices, such as SD cards.
|
||||
This class uses `Zephyr Disk Access API <https://docs.zephyrproject.org/latest/reference/storage/disk/access.html>`_ and
|
||||
implements the `uos.AbstractBlockDev` protocol.
|
||||
implements the `os.AbstractBlockDev` protocol.
|
||||
|
||||
For use with SD card controllers, SD cards must be present at boot & not removed; they will
|
||||
be auto detected and initialized by filesystem at boot. Use the disk driver interface and a
|
||||
|
@ -39,7 +39,7 @@ customize filesystem configurations. To store persistent data on the device, usi
|
|||
API is recommended (see below).
|
||||
|
||||
This class uses `Zephyr Flash map API <https://docs.zephyrproject.org/latest/reference/storage/flash_map/flash_map.html#>`_ and
|
||||
implements the `uos.AbstractBlockDev` protocol.
|
||||
implements the `os.AbstractBlockDev` protocol.
|
||||
|
||||
Example usage with the internal flash on the reel_board or the rv32m1_vega_ri5cy board::
|
||||
|
||||
|
|
Loading…
Reference in New Issue