From 6bbc8c701aaa60b298d52399c4d1ae43bdf7e22a Mon Sep 17 00:00:00 2001 From: Windsor Schmidt Date: Tue, 22 Jul 2025 15:59:27 -0700 Subject: [PATCH] documentation: spelling and grammar fixes --- Documentation/applications/examples/can/index.rst | 2 +- Documentation/applications/examples/elf/index.rst | 2 +- Documentation/applications/examples/nxlines/index.rst | 4 ++-- Documentation/applications/examples/serloop/index.rst | 2 +- Documentation/applications/examples/sotest/index.rst | 6 +++--- Documentation/applications/examples/usbserial/index.rst | 4 ++-- Documentation/applications/sdr/index.rst | 6 +++--- Documentation/applications/system/zmodem/index.rst | 8 ++++---- Documentation/applications/tools/index.rst | 6 +++--- Documentation/applications/wireless/btsak/index.rst | 2 +- Documentation/implementation/drivers_design.rst | 4 ++-- Documentation/reference/os/iob.rst | 2 +- Documentation/reference/user/09_env_vars.rst | 2 +- Documentation/reference/user/10_filesystem.rst | 2 +- 14 files changed, 26 insertions(+), 26 deletions(-) diff --git a/Documentation/applications/examples/can/index.rst b/Documentation/applications/examples/can/index.rst index 9fa0b0f709..1e4d8bde52 100644 --- a/Documentation/applications/examples/can/index.rst +++ b/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 diff --git a/Documentation/applications/examples/elf/index.rst b/Documentation/applications/examples/elf/index.rst index 2f97b7b885..1988fd5a8b 100644 --- a/Documentation/applications/examples/elf/index.rst +++ b/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) diff --git a/Documentation/applications/examples/nxlines/index.rst b/Documentation/applications/examples/nxlines/index.rst index 3d274c5ca5..2e82bc1769 100644 --- a/Documentation/applications/examples/nxlines/index.rst +++ b/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. diff --git a/Documentation/applications/examples/serloop/index.rst b/Documentation/applications/examples/serloop/index.rst index 6d76547bce..e7e581da1a 100644 --- a/Documentation/applications/examples/serloop/index.rst +++ b/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). diff --git a/Documentation/applications/examples/sotest/index.rst b/Documentation/applications/examples/sotest/index.rst index 81f9d8e147..1049591d7a 100644 --- a/Documentation/applications/examples/sotest/index.rst +++ b/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 diff --git a/Documentation/applications/examples/usbserial/index.rst b/Documentation/applications/examples/usbserial/index.rst index c14a1ce5b8..98550f1b8f 100644 --- a/Documentation/applications/examples/usbserial/index.rst +++ b/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. diff --git a/Documentation/applications/sdr/index.rst b/Documentation/applications/sdr/index.rst index 68f860b534..33e2ae991b 100644 --- a/Documentation/applications/sdr/index.rst +++ b/Documentation/applications/sdr/index.rst @@ -1,6 +1,6 @@ -=============================== -Software Define Radio Libraries -=============================== +================================ +Software Defined Radio Libraries +================================ .. toctree:: :glob: diff --git a/Documentation/applications/system/zmodem/index.rst b/Documentation/applications/system/zmodem/index.rst index 4a2af8987f..7ea2576aa6 100644 --- a/Documentation/applications/system/zmodem/index.rst +++ b/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 diff --git a/Documentation/applications/tools/index.rst b/Documentation/applications/tools/index.rst index 1ed7e4caab..6d8dbf164b 100644 --- a/Documentation/applications/tools/index.rst +++ b/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 -content that you would like to access within the the target. +tool to simplify creation of ROMFS file system from any directory containing +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 diff --git a/Documentation/applications/wireless/btsak/index.rst b/Documentation/applications/wireless/btsak/index.rst index ea59b11126..434207d251 100644 --- a/Documentation/applications/wireless/btsak/index.rst +++ b/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 help info:: diff --git a/Documentation/implementation/drivers_design.rst b/Documentation/implementation/drivers_design.rst index 4127bee6cb..bb63c0a77d 100644 --- a/Documentation/implementation/drivers_design.rst +++ b/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. diff --git a/Documentation/reference/os/iob.rst b/Documentation/reference/os/iob.rst index 79dc546042..54c7f266db 100644 --- a/Documentation/reference/os/iob.rst +++ b/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. diff --git a/Documentation/reference/user/09_env_vars.rst b/Documentation/reference/user/09_env_vars.rst index 5b824697b1..44908b00df 100644 --- a/Documentation/reference/user/09_env_vars.rst +++ b/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 diff --git a/Documentation/reference/user/10_filesystem.rst b/Documentation/reference/user/10_filesystem.rst index 256d8b46d2..4ad5cb4303 100644 --- a/Documentation/reference/user/10_filesystem.rst +++ b/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.