docs: Fix some spelling mistakes.

mcauser · dpgeorge · commit 31ac410a4fbf · 2021-05-04T22:58:00.000+10:00
diff --git a/docs/develop/cmodules.rst b/docs/develop/cmodules.rst
@@ -91,7 +91,7 @@ This simple module named ``cexample`` provides a single function
 ``cexample.add_ints(a, b)`` which adds the two integer args together and returns
 the result. It can be found in the MicroPython source tree
 `in the examples directory <https://github.com/micropython/micropython/tree/master/examples/usercmodule/cexample>`_
-and has a source file and a Makefile fragment with content as descibed above::
+and has a source file and a Makefile fragment with content as described above::
 
     micropython/
     └──examples/
diff --git a/docs/esp32/quickref.rst b/docs/esp32/quickref.rst
@@ -58,7 +58,7 @@ The :mod:`esp32` module::
     import esp32
 
     esp32.hall_sensor()     # read the internal hall sensor
-    esp32.raw_temperature() # read the internal temperature of the MCU, in Farenheit
+    esp32.raw_temperature() # read the internal temperature of the MCU, in Fahrenheit
     esp32.ULP()             # access to the Ultra-Low-Power Co-processor
 
 Note that the temperature sensor in the ESP32 will typically read higher than
diff --git a/docs/esp8266/quickref.rst b/docs/esp8266/quickref.rst
@@ -58,7 +58,7 @@ The :mod:`network` module::
     wlan.scan()             # scan for access points
     wlan.isconnected()      # check if the station is connected to an AP
     wlan.connect('essid', 'password') # connect to an AP
-    wlan.config('mac')      # get the interface's MAC adddress
+    wlan.config('mac')      # get the interface's MAC address
     wlan.ifconfig()         # get the interface's IP/netmask/gw/DNS addresses
 
     ap = network.WLAN(network.AP_IF) # create access-point interface
diff --git a/docs/library/esp32.rst b/docs/library/esp32.rst
@@ -162,7 +162,7 @@ used to transmit or receive many other types of digital signals::
 The input to the RMT module is an 80MHz clock (in the future it may be able to
 configure the input clock but, for now, it's fixed). ``clock_div`` *divides*
 the clock input which determines the resolution of the RMT channel. The
-numbers specificed in ``write_pulses`` are multiplied by the resolution to
+numbers specified in ``write_pulses`` are multiplied by the resolution to
 define the pulses.
 
 ``clock_div`` is an 8-bit divider (0-255) and each pulse can be defined by
diff --git a/docs/library/machine.Timer.rst b/docs/library/machine.Timer.rst
@@ -9,7 +9,7 @@ the most flexible and heterogeneous kind of hardware in MCUs and SoCs,
 differently greatly from a model to a model. MicroPython's Timer class
 defines a baseline operation of executing a callback with a given period
 (or once after some delay), and allow specific boards to define more
-non-standard behavior (which thus won't be portable to other boards).
+non-standard behaviour (which thus won't be portable to other boards).
 
 See discussion of :ref:`important constraints <machine_callbacks>` on
 Timer callbacks.
diff --git a/docs/library/machine.TimerWiPy.rst b/docs/library/machine.TimerWiPy.rst
@@ -16,7 +16,7 @@ the most flexible and heterogeneous kind of hardware in MCUs and SoCs,
 differently greatly from a model to a model. MicroPython's Timer class
 defines a baseline operation of executing a callback with a given period
 (or once after some delay), and allow specific boards to define more
-non-standard behavior (which thus won't be portable to other boards).
+non-standard behaviour (which thus won't be portable to other boards).
 
 See discussion of :ref:`important constraints <machine_callbacks>` on
 Timer callbacks.
@@ -115,7 +115,7 @@ Methods
 
 .. method:: timerchannel.irq(*, trigger, priority=1, handler=None)
 
-    The behavior of this callback is heavily dependent on the operating
+    The behaviour of this callback is heavily dependent on the operating
     mode of the timer channel:
 
         - If mode is ``TimerWiPy.PERIODIC`` the callback is executed periodically
diff --git a/docs/library/network.rst b/docs/library/network.rst
@@ -55,7 +55,7 @@ parameter should be `id`.
         Activate ("up") or deactivate ("down") the network interface, if
         a boolean argument is passed. Otherwise, query current state if
         no argument is provided. Most other methods require an active
-        interface (behavior of calling them on inactive interface is
+        interface (behaviour of calling them on inactive interface is
         undefined).
 
 .. method:: AbstractNIC.connect([service_id, key=None, *, ...])
diff --git a/docs/library/uctypes.rst b/docs/library/uctypes.rst
@@ -245,7 +245,7 @@ Module contents
 
 .. data:: VOID
 
-   ``VOID`` is an alias for ``UINT8``, and is provided to conviniently define
+   ``VOID`` is an alias for ``UINT8``, and is provided to conveniently define
    C's void pointers: ``(uctypes.PTR, uctypes.VOID)``.
 
 .. data:: PTR
diff --git a/docs/library/uio.rst b/docs/library/uio.rst
@@ -18,7 +18,7 @@ Conceptual hierarchy
    Conceptual hierarchy of stream base classes is simplified in MicroPython,
    as described in this section.
 
-(Abstract) base stream classes, which serve as a foundation for behavior
+(Abstract) base stream classes, which serve as a foundation for behaviour
 of all the concrete classes, adhere to few dichotomies (pair-wise
 classifications) in CPython. In MicroPython, they are somewhat simplified
 and made implicit to achieve higher efficiencies and save resources.
@@ -41,15 +41,15 @@ more concise and efficient programs - something which is highly desirable
 for MicroPython. So, while MicroPython doesn't support buffered streams,
 it still provides for no-short-operations streams. Whether there will
 be short operations or not depends on each particular class' needs, but
-developers are strongly advised to favor no-short-operations behavior
+developers are strongly advised to favour no-short-operations behaviour
 for the reasons stated above. For example, MicroPython sockets are
 guaranteed to avoid short read/writes. Actually, at this time, there is
 no example of a short-operations stream class in the core, and one would
 be a port-specific class, where such a need is governed by hardware
 peculiarities.
 
-The no-short-operations behavior gets tricky in case of non-blocking
-streams, blocking vs non-blocking behavior being another CPython dichotomy,
+The no-short-operations behaviour gets tricky in case of non-blocking
+streams, blocking vs non-blocking behaviour being another CPython dichotomy,
 fully supported by MicroPython. Non-blocking streams never wait for
 data either to arrive or be written - they read/write whatever possible,
 or signal lack of data (or ability to write data). Clearly, this conflicts
diff --git a/docs/library/uselect.rst b/docs/library/uselect.rst
@@ -87,11 +87,11 @@ Methods
    `callee-owned tuple`. This function provides an efficient, allocation-free
    way to poll on streams.
 
-   If *flags* is 1, one-shot behavior for events is employed: streams for
+   If *flags* is 1, one-shot behaviour for events is employed: streams for
    which events happened will have their event masks automatically reset
    (equivalent to ``poll.modify(obj, 0)``), so new events for such a stream
    won't be processed until new mask is set with `poll.modify()`. This
-   behavior is useful for asynchronous I/O schedulers.
+   behaviour is useful for asynchronous I/O schedulers.
 
    .. admonition:: Difference to CPython
       :class: attention
diff --git a/docs/library/usocket.rst b/docs/library/usocket.rst
@@ -222,7 +222,7 @@ Methods
    Unlike `send()`, this method will try to send all of data, by sending data
    chunk by chunk consecutively.
 
-   The behavior of this method on non-blocking sockets is undefined. Due to this,
+   The behaviour of this method on non-blocking sockets is undefined. Due to this,
    on MicroPython, it's recommended to use `write()` method instead, which
    has the same "no short writes" policy for blocking sockets, and will return
    number of bytes sent on non-blocking sockets.
diff --git a/docs/library/utime.rst b/docs/library/utime.rst
@@ -173,7 +173,7 @@ Functions
    long sleep), then once you finally look again, it may seem to you that only 1 hour
    has passed. To avoid this mistake, just look at the clock regularly. Your application
    should do the same. "Too long sleep" metaphor also maps directly to application
-   behavior: don't let your application run any single task for too long. Run tasks
+   behaviour: 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:
