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>

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

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

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

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