all: Fix spelling mistakes based on codespell check.

Signed-off-by: Damien George <[email protected]>
mathiasflick · Apr 27, 2023 · b1229ef · b1229ef
1 parent e160fe7
commit b1229ef
Show file tree

Hide file tree

Showing 191 changed files with 282 additions and 282 deletions.
diff --git a/.github/ISSUE_TEMPLATE/security.md b/.github/ISSUE_TEMPLATE/security.md
@@ -1,6 +1,6 @@
 ---
 name: Security report
-about: Report a security issue or vunerability in MicroPython
+about: Report a security issue or vulnerability in MicroPython
 title: ''
 labels: security
 assignees: ''

diff --git a/CODECONVENTIONS.md b/CODECONVENTIONS.md
@@ -255,7 +255,7 @@ Documentation conventions
 =========================
 
 MicroPython generally follows CPython in documentation process and
-conventions. reStructuredText syntax is used for the documention.
+conventions. reStructuredText syntax is used for the documentation.
 
 Specific conventions/suggestions:
 

diff --git a/docs/develop/cmodules.rst b/docs/develop/cmodules.rst
@@ -53,7 +53,7 @@ A MicroPython user C module is a directory with the following files:
   ``SRC_USERMOD_C`` or ``SRC_USERMOD_LIB_C`` variables. The former will be
   processed for ``MP_QSTR_`` and ``MP_REGISTER_MODULE`` definitions, the latter
   will not (e.g. helpers and library code that isn't MicroPython-specific).
-  These paths should include your expaned copy of ``$(USERMOD_DIR)``, e.g.::
+  These paths should include your expanded copy of ``$(USERMOD_DIR)``, e.g.::
 
     SRC_USERMOD_C += $(EXAMPLE_MOD_DIR)/modexample.c
     SRC_USERMOD_LIB_C += $(EXAMPLE_MOD_DIR)/utils/algorithm.c

diff --git a/docs/esp32/tutorial/intro.rst b/docs/esp32/tutorial/intro.rst
@@ -17,7 +17,7 @@ Requirements
 The first thing you need is a board with an ESP32 chip.  The MicroPython
 software supports the ESP32 chip itself and any board should work.  The main
 characteristic of a board is how the GPIO pins are connected to the outside
-world, and whether it includes a built-in USB-serial convertor to make the
+world, and whether it includes a built-in USB-serial converter to make the
 UART available to your PC.
 
 Names of pins will be given in this tutorial using the chip names (eg GPIO2)
@@ -59,7 +59,7 @@ bootloader mode, and second you need to copy across the firmware.  The exact
 procedure for these steps is highly dependent on the particular board and you will
 need to refer to its documentation for details.
 
-Fortunately, most boards have a USB connector, a USB-serial convertor, and the DTR
+Fortunately, most boards have a USB connector, a USB-serial converter, and the DTR
 and RTS pins wired in a special way then deploying the firmware should be easy as
 all steps can be done automatically.  Boards that have such features
 include the Adafruit Feather HUZZAH32, M5Stack, Wemos LOLIN32, and TinyPICO
@@ -104,7 +104,7 @@ Serial prompt
 
 Once you have the firmware on the device you can access the REPL (Python prompt)
 over UART0 (GPIO1=TX, GPIO3=RX), which might be connected to a USB-serial
-convertor, depending on your board.  The baudrate is 115200.
+converter, depending on your board.  The baudrate is 115200.
 
 From here you can now follow the ESP8266 tutorial, because these two Espressif chips
 are very similar when it comes to using MicroPython on them.  The ESP8266 tutorial
@@ -124,7 +124,7 @@ after it, here are troubleshooting recommendations:
 
 * The flashing instructions above use flashing speed of 460800 baud, which is
   good compromise between speed and stability. However, depending on your
-  module/board, USB-UART convertor, cables, host OS, etc., the above baud
+  module/board, USB-UART converter, cables, host OS, etc., the above baud
   rate may be too high and lead to errors. Try a more common 115200 baud
   rate instead in such cases.
 

diff --git a/docs/esp8266/tutorial/intro.rst b/docs/esp8266/tutorial/intro.rst
@@ -18,7 +18,7 @@ The first thing you need is a board with an ESP8266 chip.  The MicroPython
 software supports the ESP8266 chip itself and any board should work.  The main
 characteristic of a board is how much flash it has, how the GPIO pins are
 connected to the outside world, and whether it includes a built-in USB-serial
-convertor to make the UART available to your PC.
+converter to make the UART available to your PC.
 
 The minimum requirement for flash size is 1Mbyte. There is also a special
 build for boards with 512KB, but it is highly limited comparing to the
@@ -70,7 +70,7 @@ need to put your device in boot-loader mode, and second you need to copy across
 the firmware.  The exact procedure for these steps is highly dependent on the
 particular board and you will need to refer to its documentation for details.
 
-If you have a board that has a USB connector, a USB-serial convertor, and has
+If you have a board that has a USB connector, a USB-serial converter, and has
 the DTR and RTS pins wired in a special way then deploying the firmware should
 be easy as all steps can be done automatically.  Boards that have such features
 include the Adafruit Feather HUZZAH and NodeMCU boards.
@@ -128,7 +128,7 @@ Serial prompt
 
 Once you have the firmware on the device you can access the REPL (Python prompt)
 over UART0 (GPIO1=TX, GPIO3=RX), which might be connected to a USB-serial
-convertor, depending on your board.  The baudrate is 115200.  The next part of
+converter, depending on your board.  The baudrate is 115200.  The next part of
 the tutorial will discuss the prompt in more detail.
 
 WiFi
@@ -137,7 +137,7 @@ WiFi
 After a fresh install and boot the device configures itself as a WiFi access
 point (AP) that you can connect to.  The ESSID is of the form MicroPython-xxxxxx
 where the x's are replaced with part of the MAC address of your device (so will
-be the same everytime, and most likely different for all ESP8266 chips).  The
+be the same every time, and most likely different for all ESP8266 chips).  The
 password for the WiFi is micropythoN (note the upper-case N).  Its IP address
 will be 192.168.4.1 once you connect to its network.  WiFi configuration will
 be discussed in more detail later in the tutorial.
@@ -169,7 +169,7 @@ after it, here are troubleshooting recommendations:
 
 * The flashing instructions above use flashing speed of 460800 baud, which is
   good compromise between speed and stability. However, depending on your
-  module/board, USB-UART convertor, cables, host OS, etc., the above baud
+  module/board, USB-UART converter, cables, host OS, etc., the above baud
   rate may be too high and lead to errors. Try a more common 115200 baud
   rate instead in such cases.
 

diff --git a/docs/esp8266/tutorial/repl.rst b/docs/esp8266/tutorial/repl.rst
@@ -13,7 +13,7 @@ REPL over the serial port
 
 The REPL is always available on the UART0 serial peripheral, which is connected
 to the pins GPIO1 for TX and GPIO3 for RX.  The baudrate of the REPL is 115200.
-If your board has a USB-serial convertor on it then you should be able to access
+If your board has a USB-serial converter on it then you should be able to access
 the REPL directly from your PC.  Otherwise you will need to have a way of
 communicating with the UART.
 

diff --git a/docs/library/array.rst b/docs/library/array.rst
@@ -75,7 +75,7 @@ Classes
         Returns the string representation of the array, called as ``str(a)`` or ``repr(a)```
         (where ``a`` is an ``array``).  Returns the string ``"array(<type>, [<elements>])"``,
         where ``<type>`` is the type code letter for the array and ``<elements>`` is a comma
-        seperated list of the elements of the array.
+        separated list of the elements of the array.
 
         **Note:** ``__repr__`` cannot be called directly (``a.__repr__()`` fails) and
         is not present in ``__dict__``, however ``str(a)`` and ``repr(a)`` both work.
diff --git a/docs/library/bluetooth.rst b/docs/library/bluetooth.rst
@@ -44,7 +44,7 @@ Configuration
 
     Get or set configuration values of the BLE interface.  To get a value the
     parameter name should be quoted as a string, and just one parameter is
-    queried at a time.  To set values use the keyword syntax, and one ore more
+    queried at a time.  To set values use the keyword syntax, and one or more
     parameter can be set at a time.
 
     Currently supported values are:

diff --git a/docs/library/esp32.rst b/docs/library/esp32.rst
@@ -126,7 +126,7 @@ methods to enable over-the-air (OTA) updates.
     and  an ``OSError(-261)`` is raised if called on firmware that doesn't have the
     feature enabled.
     It is OK to call ``mark_app_valid_cancel_rollback`` on every boot and it is not
-    necessary when booting firmare that was loaded using esptool.
+    necessary when booting firmware that was loaded using esptool.
 
 Constants
 ~~~~~~~~~

diff --git a/docs/library/machine.ADC.rst b/docs/library/machine.ADC.rst
@@ -4,7 +4,7 @@
 class ADC -- analog to digital conversion
 =========================================
 
-The ADC class provides an interface to analog-to-digital convertors, and
+The ADC class provides an interface to analog-to-digital converters, and
 represents a single endpoint that can sample a continuous voltage and
 convert it to a discretised value.
 

diff --git a/docs/library/machine.I2C.rst b/docs/library/machine.I2C.rst
@@ -94,7 +94,7 @@ General Methods
      - *freq* is the SCL clock rate
 
    In the case of hardware I2C the actual clock frequency may be lower than the
-   requested frequency. This is dependant on the platform hardware. The actual
+   requested frequency. This is dependent on the platform hardware. The actual
    rate may be determined by printing the I2C object.
 
 .. method:: I2C.deinit()

diff --git a/docs/library/machine.I2S.rst b/docs/library/machine.I2S.rst
@@ -103,7 +103,7 @@ Constructor
      - ``ibuf`` specifies internal buffer length (bytes)
 
    For all ports, DMA runs continuously in the background and allows user applications to perform other operations while
-   sample data is transfered between the internal buffer and the I2S peripheral unit.
+   sample data is transferred between the internal buffer and the I2S peripheral unit.
    Increasing the size of the internal buffer has the potential to increase the time that user applications can perform non-I2S operations
    before underflow (e.g. ``write`` method) or overflow (e.g. ``readinto`` method).
 

diff --git a/docs/library/machine.SPI.rst b/docs/library/machine.SPI.rst
@@ -98,7 +98,7 @@ Methods
        specify them as a tuple of ``pins`` parameter.
 
    In the case of hardware SPI the actual clock frequency may be lower than the
-   requested baudrate. This is dependant on the platform hardware. The actual
+   requested baudrate. This is dependent on the platform hardware. The actual
    rate may be determined by printing the SPI object.
 
 .. method:: SPI.deinit()

diff --git a/docs/library/machine.Timer.rst b/docs/library/machine.Timer.rst
@@ -73,7 +73,7 @@ Methods
      - ``callback`` - The callable to call upon expiration of the timer period.
        The callback must take one argument, which is passed the Timer object.
        The ``callback`` argument shall be specified. Otherwise an exception
-       will occurr upon timer expiration:
+       will occur upon timer expiration:
        ``TypeError: 'NoneType' object isn't callable``
 
 .. method:: Timer.deinit()

diff --git a/docs/library/os.rst b/docs/library/os.rst
@@ -86,7 +86,7 @@ Filesystem access
 
 .. function:: statvfs(path)
 
-   Get the status of a fileystem.
+   Get the status of a filesystem.
 
    Returns a tuple with the filesystem information in the following order:
 

diff --git a/docs/library/pyb.CAN.rst b/docs/library/pyb.CAN.rst
@@ -272,7 +272,7 @@ Methods
      - *fdf* for CAN FD controllers, if set to True, the frame will have an FD
        frame format, which supports data payloads up to 64 bytes.
      - *brs* for CAN FD controllers, if set to True, the bitrate switching mode
-       is enabled, in which the data phase is transmitted at a differet bitrate.
+       is enabled, in which the data phase is transmitted at a different bitrate.
        See :meth:`CAN.init` for the data bit timing configuration parameters.
 
      If timeout is 0 the message is placed in a buffer in one of three hardware

diff --git a/docs/library/pyb.I2C.rst b/docs/library/pyb.I2C.rst
@@ -97,7 +97,7 @@ Methods
        errors properly)
 
    The actual clock frequency may be lower than the requested frequency.
-   This is dependant on the platform hardware. The actual rate may be determined
+   This is dependent on the platform hardware. The actual rate may be determined
    by printing the I2C object.
 
 .. method:: I2C.is_ready(addr)

diff --git a/docs/library/sys.rst b/docs/library/sys.rst
@@ -46,7 +46,7 @@ Functions
 .. function:: settrace(tracefunc)
 
    Enable tracing of bytecode execution.  For details see the `CPython
-   documentaion <https://docs.python.org/3/library/sys.html#sys.settrace>`_.
+   documentation <https://docs.python.org/3/library/sys.html#sys.settrace>`_.
 
    This function requires a custom MicroPython build as it is typically not
    present in pre-built firmware (due to it affecting performance).  The relevant

diff --git a/docs/library/time.rst b/docs/library/time.rst
@@ -163,8 +163,8 @@ Functions
    However, values returned by `ticks_ms()`, etc. functions may wrap around, so
    directly using subtraction on them will produce incorrect result. That is why
    `ticks_diff()` is needed, it implements modular (or more specifically, ring)
-   arithmetics to produce correct result even for wrap-around values (as long as they not
-   too distant inbetween, see below). The function returns **signed** value in the range
+   arithmetic to produce correct result even for wrap-around values (as long as they not
+   too distant in between, see below). The function returns **signed** value in the range
    [*-TICKS_PERIOD/2* .. *TICKS_PERIOD/2-1*] (that's a typical range definition for
    two's-complement signed binary integers). If the result is negative, it means that
    *ticks1* occurred earlier in time than *ticks2*. Otherwise, it means that
@@ -183,7 +183,7 @@ Functions
    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
    behaviour: don't let your application run any single task for too long. Run tasks
-   in steps, and do time-keeping inbetween.
+   in steps, and do time-keeping in between.
 
    `ticks_diff()` is designed to accommodate various usage patterns, among them:
 

diff --git a/docs/library/zephyr.rst b/docs/library/zephyr.rst
@@ -32,7 +32,7 @@ Functions
     * *CPU utilization is only printed if runtime statistics are configured via the ``CONFIG_THREAD_RUNTIME_STATS`` kconfig*
 
    This function can only be accessed if ``CONFIG_THREAD_ANALYZER`` is configured for the port in ``zephyr/prj.conf``.
-   For more infomation, see documentation for Zephyr `thread analyzer
+   For more information, see documentation for Zephyr `thread analyzer
    <https://docs.zephyrproject.org/latest/guides/debug_tools/thread-analyzer.html#thread-analyzer>`_.
 
 .. function:: shell_exec(cmd_in)

diff --git a/docs/pyboard/tutorial/usb_mouse.rst b/docs/pyboard/tutorial/usb_mouse.rst
@@ -120,7 +120,7 @@ minus sign in front of the y-coordinate in the ``hid.send()`` line above.
 Restoring your pyboard to normal
 --------------------------------
 
-If you leave your pyboard as-is, it'll behave as a mouse everytime you plug
+If you leave your pyboard as-is, it'll behave as a mouse every time you plug
 it in.  You probably want to change it back to normal.  To do this you need
 to first enter safe mode (see above), and then edit the ``boot.py`` file.
 In the ``boot.py`` file, comment out (put a # in front of) the line with the

diff --git a/docs/reference/asm_thumb2_compare.rst b/docs/reference/asm_thumb2_compare.rst
@@ -75,7 +75,7 @@ Execute the next instruction if <condition> is true:
 
 * ite(<condition>) If then else
 
-If <condtion> is true, execute the next instruction, otherwise execute the
+If <condition> is true, execute the next instruction, otherwise execute the
 subsequent one. Thus:
 
 ::
@@ -86,5 +86,5 @@ subsequent one. Thus:
     mov(r0, 200) # runs if r0 != r1
     # execution continues here
 
-This may be extended to control the execution of upto four subsequent instructions: it[x[y[z]]]
+This may be extended to control the execution of up to four subsequent instructions: it[x[y[z]]]
 where x,y,z=t/e; e.g. itt, itee, itete, ittte, itttt, iteee, etc.
diff --git a/docs/reference/constrained.rst b/docs/reference/constrained.rst
@@ -264,7 +264,7 @@ were a string.
 
 **Runtime compiler execution**
 
-The Python funcitons `eval` and `exec` invoke the compiler at runtime, which
+The Python functions `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
 `json` library for object serialisation.
@@ -403,7 +403,7 @@ Control of garbage collection
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 A GC can be demanded at any time by issuing `gc.collect()`. It is advantageous
-to do this at intervals, firstly to pre-empt fragmentation and secondly for
+to do this at intervals, firstly to preempt fragmentation and secondly for
 performance. A GC can take several milliseconds but is quicker when there is
 little work to do (about 1ms on the Pyboard). An explicit call can minimise that
 delay while ensuring it occurs at points in the program when it is acceptable.

diff --git a/docs/rp2/general.rst b/docs/rp2/general.rst
@@ -30,7 +30,7 @@ The peripherals include:
 
 * 2 UARTs
 * 2 SPI controllers
-* 2 I2C contollers
+* 2 I2C controllers
 * 16 PWM channels
 * USB 1.1 controller
 * 8 PIO state machines
diff --git a/docs/rp2/quickref.rst b/docs/rp2/quickref.rst
@@ -96,7 +96,7 @@ Programmable IO (PIO)
 ---------------------
 
 PIO is useful to build low-level IO interfaces from scratch.  See the :mod:`rp2` module
-for detailed explaination of the assembly instructions.
+for detailed explanation of the assembly instructions.
 
 Example using PIO to blink an LED at 1Hz::
 

diff --git a/docs/zephyr/tutorial/repl.rst b/docs/zephyr/tutorial/repl.rst
@@ -10,7 +10,7 @@ REPL over the serial port
 
 The REPL is available on a UART serial peripheral specified for the board by
 the ``zephyr,console`` devicetree node. The baudrate of the REPL is 115200.
-If your board has a USB-serial convertor on it then you should be able to access
+If your board has a USB-serial converter on it then you should be able to access
 the REPL directly from your PC.
 
 To access the prompt over USB-serial you will need to use a terminal emulator

diff --git a/drivers/cyw43/cywbt.c b/drivers/cyw43/cywbt.c
@@ -67,7 +67,7 @@ STATIC int cywbt_hci_cmd_raw(size_t len, uint8_t *buf) {
         buf[i] = uart_rx_char(&mp_bluetooth_hci_uart_obj);
     }
 
-    // expect a comand complete event (event 0x0e)
+    // expect a command complete event (event 0x0e)
     if (buf[0] != 0x04 || buf[1] != 0x0e) {
         printf("unknown response: %02x %02x %02x %02x\n", buf[0], buf[1], buf[2], buf[3]);
         return -1;

diff --git a/drivers/ninaw10/nina_wifi_drv.c b/drivers/ninaw10/nina_wifi_drv.c
@@ -105,7 +105,7 @@ typedef enum {
     NINA_CMD_AP_GET_BSSID           = 0x3C,
     NINA_CMD_AP_GET_CHANNEL         = 0x3D,
 
-    // Disonnect/status commands.
+    // Disconnect/status commands.
     NINA_CMD_DISCONNECT             = 0x30,
     NINA_CMD_CONN_STATUS            = 0x20,
     NINA_CMD_CONN_REASON            = 0x1F,

diff --git a/examples/embedding/README.md b/examples/embedding/README.md
@@ -23,7 +23,7 @@ To build the example project, based on `main.c`, use:
 
     $ make
 
-That will create an exacutable called `embed` which you can run:
+That will create an executable called `embed` which you can run:
 
     $ ./embed
 

diff --git a/examples/hwapi/README.md b/examples/hwapi/README.md
@@ -5,7 +5,7 @@ which would work from a board to board, from a system to another systems.
 This is inherently a hard problem, because hardware is different from one
 board type to another, and even from examplar of board to another. For
 example, if your app requires an external LED, one user may connect it
-to one GPIO pin, while another user may find it much more convinient to
+to one GPIO pin, while another user may find it much more convenient to
 use another pin. This of course applies to relays, buzzers, sensors, etc.
 
 With complications above in mind, it's still possible to write portable

diff --git a/examples/hwapi/hwconfig_pyboard.py b/examples/hwapi/hwconfig_pyboard.py
@@ -1,6 +1,6 @@
 from machine import Pin, Signal
 
-# Red LED on pin LED_RED also kown as A13
+# Red LED on pin LED_RED also known as A13
 LED = Signal("LED_RED", Pin.OUT)
 
 # Green LED on pin LED_GREEN also known as A14

diff --git a/examples/natmod/features1/features1.c b/examples/natmod/features1/features1.c
@@ -88,7 +88,7 @@ mp_obj_t mpy_init(mp_obj_fun_bc_t *self, size_t n_args, size_t n_kw, mp_obj_t *a
     // This must be first, it sets up the globals dict and other things
     MP_DYNRUNTIME_INIT_ENTRY
 
-    // Messages can be printed as usualy
+    // Messages can be printed as usual
     mp_printf(&mp_plat_print, "initialising module self=%p\n", self);
 
     // Make the functions available in the module's namespace

diff --git a/extmod/btstack/modbluetooth_btstack.c b/extmod/btstack/modbluetooth_btstack.c
@@ -883,7 +883,7 @@ int mp_bluetooth_gatts_register_service_begin(bool append) {
 
     if (!append) {
         // This will reset the DB.
-        // Becase the DB is statically allocated, there's no problem with just re-initing it.
+        // Because the DB is statically allocated, there's no problem with just re-initing it.
         // Note this would be a memory leak if we enabled HAVE_MALLOC (there's no API to free the existing db).
         att_db_util_init();
 

diff --git a/extmod/moduplatform.h b/extmod/moduplatform.h
@@ -29,7 +29,7 @@
 #include "py/misc.h"  // For MP_STRINGIFY.
 #include "py/mpconfig.h"
 
-// Preprocessor directives indentifying the platform.
+// Preprocessor directives identifying the platform.
 // The (u)platform module itself is guarded by MICROPY_PY_UPLATFORM, see the
 // .c file, but these are made available because they're generally usable.
 // TODO: Add more architectures, compilers and libraries.
-Original file line number
+Diff line change
@@ Expand Up / @@ -23,7 +23,7 @@ To build the example project, based on `main.c`, use: @@
         $ make
-    That will create an exacutable called `embed` which you can run:
+    That will create an executable called `embed` which you can run:
         $ ./embed
@@ Expand Down @@