documentation: spelling and grammar fixes

Documentation/applications/examples/can/index.rst

@@ -3,7 +3,7 @@
 =======================
 
 If the CAN device is configured in loopback mode, then this example can be used
-to test the CAN device in loop back mode. It simple sinces a sequence of CAN
+to test the CAN device in loop back mode. It simply sends a sequence of CAN
 messages and verifies that those messages are returned exactly as sent.
 
 This test depends on these specific CAN/NSH configurations settings (your

Documentation/applications/examples/elf/index.rst

@@ -3,7 +3,7 @@
 ==================
 
 This example builds a small ELF loader test case. This includes several test
-programs under ``examples/elf`` tests. These tests are build using the relocatable
+programs under ``examples/elf`` tests. These tests are built using the relocatable
 ELF format and installed in a configurable file system. At run time, the file system
 is mounted and each program is executed. Requires ``CONFIG_ELF``.
 Two distinct types of file systems are supported: internal (included in the NuttX binary)

Documentation/applications/examples/nxlines/index.rst

@@ -2,7 +2,7 @@
 ``nxlines`` NX Line Drawing
 ===========================
 
-A very simple graphics example that just exercised the NX line drawing logic.
+A very simple graphics example that just exercises the NX line drawing logic.
 
 The following configuration options can be selected:
 
@@ -28,7 +28,7 @@ The following configuration options can be selected:
 - ``CONFIG_EXAMPLES_NXLINES_BORDERCOLOR`` – The color of the lines drawn in the
   background window. Default depends on ``CONFIG_EXAMPLES_NXLINES_BPP`` (there
   really is no meaningful default).
-- ``CONFIG_EXAMPLES_NXLINES_BPP`` – Pixels per pixel to use. Valid options include
+- ``CONFIG_EXAMPLES_NXLINES_BPP`` – Bits per pixel to use. Valid options include
   ``2``, ``4``, ``8``, ``16``, ``24``, and ``32``. Default is ``16``.
 - ``CONFIG_NSH_BUILTIN_APPS`` – Build the NX lines examples as an NSH built-in
   function.

Documentation/applications/examples/serloop/index.rst

@@ -6,4 +6,4 @@ This is a mindlessly simple loopback test on the console. Useful for testing new
 serial drivers. Configuration options include:
 
 - ``CONFIG_EXAMPLES_SERLOOP_BUFIO`` – Use C buffered I/O (``getchar``/``putchar``) vs.
-   raw console I/O (read/read).
+   raw console I/O (read/write).

Documentation/applications/examples/sotest/index.rst

@@ -34,7 +34,7 @@ system. At run time, the shared library is installed and exercised. Requires
 
    If you use GCC to link, you make also need to include ``-nostdlib``.
 
-3. This example also requires ``genromfs``. ``genromfs`` can be build as part of the
+3. This example also requires ``genromfs``. ``genromfs`` can be built as part of the
    nuttx toolchain. Or can built from the ``genromfs`` sources that can be found
    in the NuttX tools repository (``genromfs-0.5.2.tar.gz``). In any event, the
    ``PATH`` variable must include the path to the ``genromfs`` executable.
@@ -49,9 +49,9 @@ system. At run time, the shared library is installed and exercised. Requires
    Windows-native binary format.
 
    If you really want to do this, you can create a NuttX x86 buildroot toolchain
-   and use that be build the ELF executables for the ROMFS file system.
+   and use that to build the ELF executables for the ROMFS file system.
 
-6. Linker scripts. You might also want to use a linker scripts to combine
+6. Linker scripts. You might also want to use a linker script to combine
    sections better. An example linker script is at
    ``nuttx/libc/elf/gnu-elf.ld``. That example might have to be tuned for your
    particular linker output to position additional sections correctly. The GNU

Documentation/applications/examples/usbserial/index.rst

@@ -6,7 +6,7 @@ Target configuration
 --------------------
 
 This is another implementation of "Hello, World" but this one uses a USB serial
-driver. Configuration options can be used to simply the test. These options
+driver. Configuration options can be used to simplify the test. These options
 include:
 
 -  ``CONFIG_EXAMPLES_USBSERIAL_INONLY`` – Only verify IN (device-to-host) data
@@ -66,5 +66,5 @@ This will generate a small program called ``host``. Usage:
      (for the PL2303 emulation) or ``/dev/ttyACM0`` (for the CDC/ACM serial
      device).
 
-The host and target will exchange are variety of very small and very large
+The host and target will exchange a variety of very small and very large
 serial messages.

Documentation/applications/sdr/index.rst

@@ -1,6 +1,6 @@
-===============================
+================================
-Software Define Radio Libraries
+Software Defined Radio Libraries
-===============================
+================================
 
 .. toctree::
    :glob:

Documentation/applications/system/zmodem/index.rst

@@ -53,7 +53,7 @@ software flow control in the host. But that would only work in one direction: If
 would prevent the host from overrunning the the target Rx buffering. So you
 should be able to do host-to-target software flow control. But there would still
 be no target-to-host flow control. That might not be an issue because the host
-is usually so much faster than that target.
+is usually so much faster than the target.
 
 RX Buffer Size
 ~~~~~~~~~~~~~~
@@ -64,7 +64,7 @@ that the Linux sz ignores this setting and always sends file data at the maximum
 size (``1024``) no matter what size of buffer you report. That is unfortunate
 because that, combined with the possibilities of data overrun mean that you must
 use quite large buffering for ZModem file receipt to be reliable (none of these
-issues effect sending of files).
+issues affect sending of files).
 
 Buffer Recommendations
 ~~~~~~~~~~~~~~~~~~~~~~
@@ -135,7 +135,7 @@ Then on the target (using ``/dev/ttyS1`` as an example)::
 
 Where filename is the full path to the file to send (i.e., it begins with the
 ``/`` character). ``/dev/ttyS1`` or whatever device you select **must** support
-Hardware flow control in order to throttle therates of data transfer to fit
+Hardware flow control in order to throttle the rate of data transfer to fit
 within the allocated buffers.
 
 Receiving Files on the Target from the Linux Host PC
@@ -181,7 +181,7 @@ You can add the ``sz -v`` option multiple times, each increases the level of deb
 output. If you want to capture the Linux ``sz`` output, then re-direct ``stderr`` to
 a log file by adding ``2>sz.log`` to the end of the ``sz`` command.
 
-If you don't have the sz command on your Linux box, the package to install
+If you don't have the sz command on your Linux box, the package to install is
 ``rzsz`` (or possibly ``lrzsz``).
 
 Building the ZModem Tools to Run Under Linux

Documentation/applications/tools/index.rst

@@ -38,8 +38,8 @@ image in this case. Here is what can be done:
 ``apps/tools`` and one in ``nuttx/tools``.
 
 **A**: The version of ``mkromfsimg.sh`` in ``nuttx/tools`` is a generic
-tool to simplify creation of ROMFS file system from any directory contain
+tool to simplify creation of ROMFS file system from any directory containing
-content that you would like to access within the the target.
+content that you would like to access within the target.
 
 The version in ``apps/tools``, on the other hand, has a very special purpose.
 It is part of the support that can be used in the KERNEL build mode.
@@ -54,7 +54,7 @@ See :doc:`/implementation/processes_vs_tasks`.
 One consequence of that is that functions like ``task_create()`` and friends
 cannot be used in the KERNEL build mode. Instead, all processes must be loaded
 into a virtual address space from an ELF or NxFLAT file residing in the file
-system. ROMFS is one of many file system, but one that is particularly usable
+system. ROMFS is one of many file systems, but one that is particularly usable
 for this purpose in deeply embedded systems.
 
 KERNEL Build Differences

Documentation/applications/wireless/btsak/index.rst

@@ -8,7 +8,7 @@ Commands
 help::
 
   Command:      help
-  Description:  Should overall command help
+  Description:  Show overall command help
   Usage:        bt <ifname> help
 
 info::

Documentation/implementation/drivers_design.rst

@@ -102,7 +102,7 @@ For the upper half driver:
 
 And for the lower half driver:
 
-* The lower-half side of the interface to the the upper0half driver, and
+* The lower-half side of the interface to the the upper-half driver, and
 
 * The low-level interface to the hardware that is managed by the lower half
   device driver.
@@ -113,7 +113,7 @@ One to Many: Encapsulation and Polymorphism
 These modular upper- and lower-half drivers have certain properties that you
 would associate with an object oriented design: Encapsulation, data abstraction,
 and polymorphism certainly.
-Because of this encapsulation, the upper-half driver is complete unaware of any
+Because of this encapsulation, the upper-half driver is completely unaware of any
 implementation details within the lower-half driver.
 Everything needed for the upper- and lower-half drivers to integrate is provided
 by the defined interface between between those two things.

Documentation/reference/os/iob.rst

@@ -21,7 +21,7 @@ networking subsystem. This objectives of this feature are:
      logic will cause the task to block and wait until a an I/O
      buffer to be freed.
   #. Each I/O buffer should be small, but can be chained together to
-     support buffering of larger thinks such as full size network
+     support buffering of larger things such as full size network
      packets.
   #. Support *throttling* logic to prevent lower priority tasks from
      hogging all available I/O buffering.

Documentation/reference/user/09_env_vars.rst

@@ -12,7 +12,7 @@ variables in the multi-processing OS:
    an inherited, exact copy of the environment of the parent. However,
    after child task has been created, subsequent operations by the child
    task on its environment does not alter the environment of the parent.
-   No do operations by the parent effect the child's environment. The
+   Nor do operations by the parent effect the child's environment. The
    environments start identical but are independent and may diverge.
 -  **Thread environments**. When a pthread is created using
    `pthread_create <#pthreadcreate>`__, the child thread also inherits

Documentation/reference/user/10_filesystem.rst

@@ -446,7 +446,7 @@ Pipes and FIFOs
 -------------------------------------
 
 NuttX operates in a flat open address space and is focused on MCUs that
-do support Memory Management Units (MMUs). Therefore, NuttX generally
+do not support Memory Management Units (MMUs). Therefore, NuttX generally
 does not require ``mmap()`` functionality and the MCUs generally cannot
 support true memory-mapped files.