summaryrefslogtreecommitdiff
path: root/docs/reference
diff options
context:
space:
mode:
Diffstat (limited to 'docs/reference')
-rw-r--r--docs/reference/constrained.rst6
-rw-r--r--docs/reference/filesystem.rst12
-rw-r--r--docs/reference/glossary.rst2
-rw-r--r--docs/reference/speed_python.rst6
4 files changed, 13 insertions, 13 deletions
diff --git a/docs/reference/constrained.rst b/docs/reference/constrained.rst
index 9c68bab9a..2a5f9d7fd 100644
--- a/docs/reference/constrained.rst
+++ b/docs/reference/constrained.rst
@@ -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
diff --git a/docs/reference/filesystem.rst b/docs/reference/filesystem.rst
index 9e7e6212d..114e59735 100644
--- a/docs/reference/filesystem.rst
+++ b/docs/reference/filesystem.rst
@@ -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
diff --git a/docs/reference/glossary.rst b/docs/reference/glossary.rst
index 27a66aa76..da951189e 100644
--- a/docs/reference/glossary.rst
+++ b/docs/reference/glossary.rst
@@ -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
diff --git a/docs/reference/speed_python.rst b/docs/reference/speed_python.rst
index aa9777859..a563b2d36 100644
--- a/docs/reference/speed_python.rst
+++ b/docs/reference/speed_python.rst
@@ -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