diff --git a/Documentation/applications/graphics/nxwm/cnxconsole.rst b/Documentation/applications/graphics/nxwm/cnxconsole.rst index b3ce36f1e4..e96d2fb260 100644 --- a/Documentation/applications/graphics/nxwm/cnxconsole.rst +++ b/Documentation/applications/graphics/nxwm/cnxconsole.rst @@ -127,7 +127,7 @@ pretty good description of how mouse/touchscreen input works. The mouse/touchscreen input is a little simpler, however: The main simplication is that the additional complexities of the NxConsole and its special input device -do not apply. Mouse/touchscreen inut as always steered to widgets when the +do not apply. Mouse/touchscreen input as always steered to widgets when the callback is received in ``CCallback::newMouseEvent`` by an unconditional call to ``CWidgetControl::newMouseEvent``. There is a "fork in the road" at the corresponding point in the logic of ``CCallback::newKeyboardEvent`` diff --git a/Documentation/components/net/wqueuedeadlocks.rst b/Documentation/components/net/wqueuedeadlocks.rst index 4f274d3dea..a2c35aeb2d 100644 --- a/Documentation/components/net/wqueuedeadlocks.rst +++ b/Documentation/components/net/wqueuedeadlocks.rst @@ -100,7 +100,7 @@ of a ``send()`` or ``sendto()`` transfer, then the operation will block until IO available if ``O_NONBLOCK`` is not selected. This delay can can be a substantial amount of time. -Second, if ``O_NONBLOCK`` is selected, the send will, of course, return immediatly, +Second, if ``O_NONBLOCK`` is selected, the send will, of course, return immediately, failing with errno set ``EAGAIN`` if we cannot allocate the first IOB for the transfer. The third behavior occurs if the we run out of IOBs in the middle of the transfer. diff --git a/Documentation/components/nxgraphics/nx.rst b/Documentation/components/nxgraphics/nx.rst index 899ebc5712..b44bdaccc8 100644 --- a/Documentation/components/nxgraphics/nx.rst +++ b/Documentation/components/nxgraphics/nx.rst @@ -29,7 +29,7 @@ features: * **Device Interface** NX supports any graphics device either of two device interfaces: - #. Any device with random accesss video memory using the NuttX framebuffer + #. Any device with random access video memory using the NuttX framebuffer driver interface (see include/nuttx/video/fb.h). #. Any LCD-like device than can accept raster line runs through a parallel or serial interface (see include/nuttx/lcd/lcd.h). By default, NX is diff --git a/Documentation/guides/citests.rst b/Documentation/guides/citests.rst index e3be2241cf..cb2b0aeee4 100644 --- a/Documentation/guides/citests.rst +++ b/Documentation/guides/citests.rst @@ -7,7 +7,7 @@ Running CI Test Locally NuttX automatically runs continuous integration (CI) tests on `simulator `__ -target when new pull request is submited. To avoid the tests failing you can +target when new pull request is submitted. To avoid the tests failing you can also run them locally on your computer prior to submiting new pull request. This page describes the step by step manual to do so. diff --git a/Documentation/guides/stm32ccm.rst b/Documentation/guides/stm32ccm.rst index 16ce123f96..cc0cb25763 100644 --- a/Documentation/guides/stm32ccm.rst +++ b/Documentation/guides/stm32ccm.rst @@ -40,7 +40,7 @@ NOTE: These interfaces are, technically, not prototyped since they are really provided via C pre-processor macros. NOTE: In order to use the CCM memory allocator functions, you must first call -``ccm_initialize()`` somwhere in your early boot-up logic. +``ccm_initialize()`` somewhere in your early boot-up logic. With these interfaces you have a (nearly) standard way to manage memory from a heap that consists of the the CCM SRAM. And, since the CCM memory is no longer diff --git a/Documentation/guides/testingtcpip.rst b/Documentation/guides/testingtcpip.rst index fba25b8ec4..4e07ecc52d 100644 --- a/Documentation/guides/testingtcpip.rst +++ b/Documentation/guides/testingtcpip.rst @@ -127,8 +127,8 @@ on these requests a application specific fuzz test can be generated. # Record requests to the target at 192.168.2.135 on port 80 ~/SPIKE/src/requests$ ../webmitm -t 192.168.2.135 -p 80 -Now use your web applicaiton through localhost to record some requests. Then you -can generate your application specific fuzz test from the recorded requests. +Now use your web application through localhost to record some requests. Then you +can generate your application-specific fuzz test from the recorded requests. .. code-block:: bash diff --git a/Documentation/implementation/critical_sections.rst b/Documentation/implementation/critical_sections.rst index 80493250c4..c5fcd31ffc 100644 --- a/Documentation/implementation/critical_sections.rst +++ b/Documentation/implementation/critical_sections.rst @@ -43,7 +43,7 @@ OS Interfaces ------------- Before we talk about SMP Critical Sections let's first review the internal OS -interfaces avaiable and what they do in the single CPU case: +interfaces available and what they do in the single CPU case: * ``up_irq_save()`` (and its companion, ``up_irq_restore()``). These simple interfaces just enable and disable interrupts globally. This is the simplest @@ -272,7 +272,7 @@ This file cat be read from NSH like: nsh> cat /proc/1/critmon 0.000009610,0.000001165 -The form of the output from the ``/proc/critmon`` file is simlar:: +The form of the output from the ``/proc/critmon`` file is similar:: X,X.XXXXXXXXX,X.XXXXXXXXX @@ -295,7 +295,7 @@ file was read. ``apps/system/critmon`` ----------------------- -Also available is a application daemon at ``apps/sysem/critmon``. This daemon +Also available is a application daemon at ``apps/system/critmon``. This daemon periodically reads the ProcFS files described above and dumps the output to stdout. This daemon is enabled with: diff --git a/Documentation/implementation/processes_vs_tasks.rst b/Documentation/implementation/processes_vs_tasks.rst index 16626a5834..c30a42d9c2 100644 --- a/Documentation/implementation/processes_vs_tasks.rst +++ b/Documentation/implementation/processes_vs_tasks.rst @@ -12,7 +12,7 @@ NuttX Build Types NuttX can be built in several different ways: -* **Kernel Build** The kernal build, selected with ``CONFIG_BUILD_KERNEL``, uses +* **Kernel Build** The kernel build, selected with ``CONFIG_BUILD_KERNEL``, uses the MCU's Memory Management Unit (MMU) to implement processes very similar to Linux processes. There is no interesting discussion here; NuttX behaves very much like Linux. diff --git a/Documentation/platforms/arm/imx6/boards/sabre-6quad/README.txt b/Documentation/platforms/arm/imx6/boards/sabre-6quad/README.txt index 78416f21f7..15218052db 100644 --- a/Documentation/platforms/arm/imx6/boards/sabre-6quad/README.txt +++ b/Documentation/platforms/arm/imx6/boards/sabre-6quad/README.txt @@ -401,7 +401,7 @@ of 1MB or so. - Remove all of the non-existent partitions created by the 'dd' copy. - Make a single FAT16 partition at the end of the SD card. - You will also need to format the partion for FAT. + You will also need to format the partition for FAT. 4. You can put nuttx.bin here and then boot very simply with: @@ -423,7 +423,7 @@ If you can prepare tftp server, this approach would be easy MX6Q SABRESD U-Boot > setenv serverip 192.168.10.16 MX6Q SABRESD U-Boot > setenv image nuttx.bin MX6Q SABRESD U-Boot > tftp ${loadaddr} ${image} - PHY indentify @ 0x1 = 0x004dd074 + PHY identify @ 0x1 = 0x004dd074 FEC: Link is Up 796d Using FEC0 device TFTP from server 192.168.10.16; our IP address is 192.168.10.103 diff --git a/Documentation/platforms/arm/lpc17xx/boards/olimex-lpc1766stk/README.txt b/Documentation/platforms/arm/lpc17xx/boards/olimex-lpc1766stk/README.txt index 231745001e..f4559335df 100644 --- a/Documentation/platforms/arm/lpc17xx/boards/olimex-lpc1766stk/README.txt +++ b/Documentation/platforms/arm/lpc17xx/boards/olimex-lpc1766stk/README.txt @@ -123,7 +123,7 @@ Olimex LPC1766-STK development board The LPC1766-STK has a Nokia 6100 132x132 LCD and either a Phillips PCF8833 or an Epson S1D15G10 LCD controller. The NuttX configuration may have to be adjusted depending on which controller is used with the LCD. The - "LPC1766-STK development board Users Manual" states tha the board features + "LPC1766-STK development board Users Manual" states that the board features a "LCD NOKIA 6610 128x128 x12bit color TFT with Epson LCD controller." But, referring to a different Olimex board, "Nokia 6100 LCD Display Driver," Revision 1, James P. Lynch ("Nokia 6100 LCD Display Driver.pdf") diff --git a/Documentation/platforms/arm/sama5/boards/sama5d3-xplained/README.txt b/Documentation/platforms/arm/sama5/boards/sama5d3-xplained/README.txt index 9cecfd407e..3229ebab1d 100644 --- a/Documentation/platforms/arm/sama5/boards/sama5d3-xplained/README.txt +++ b/Documentation/platforms/arm/sama5/boards/sama5d3-xplained/README.txt @@ -1673,7 +1673,7 @@ file1: CONFIG_USBHOST_ISOC_DISABLE=y CONFIG_USBMONITOR_PRIORITY=50 : USB monitor daemon priority CONFIG_USBMONITOR_INTERVAL=1 : Dump trace data every second - NOTE: If USB debug output is also enabled, both outpus will appear on the + NOTE: If USB debug output is also enabled, both outputs will appear on the serial console. However, the debug output will be asynchronous with the trace output and, hence, difficult to interpret. diff --git a/Documentation/platforms/arm/sama5/boards/sama5d3x-ek/README.txt b/Documentation/platforms/arm/sama5/boards/sama5d3x-ek/README.txt index f8fcacd01b..fb7743aea3 100644 --- a/Documentation/platforms/arm/sama5/boards/sama5d3x-ek/README.txt +++ b/Documentation/platforms/arm/sama5/boards/sama5d3x-ek/README.txt @@ -1700,7 +1700,7 @@ USB High-Speed Host CONFIG_USBMONITOR_PRIORITY=50 : USB monitor daemon priority CONFIG_USBMONITOR_INTERVAL=1 : Dump trace data every second - NOTE: If USB debug output is also enabled, both outpus will appear on the + NOTE: If USB debug output is also enabled, both outputs will appear on the serial console. However, the debug output will be asynchronous with the trace output and, hence, difficult to interpret. diff --git a/Documentation/platforms/arm/sama5/boards/sama5d4-ek/README.txt b/Documentation/platforms/arm/sama5/boards/sama5d4-ek/README.txt index 0d6931c28b..d840889c17 100644 --- a/Documentation/platforms/arm/sama5/boards/sama5d4-ek/README.txt +++ b/Documentation/platforms/arm/sama5/boards/sama5d4-ek/README.txt @@ -2078,7 +2078,7 @@ USB High-Speed Host CONFIG_USBMONITOR_PRIORITY=50 : USB monitor daemon priority CONFIG_USBMONITOR_INTERVAL=1 : Dump trace data every second - NOTE: If USB debug output is also enabled, both outpus will appear on the + NOTE: If USB debug output is also enabled, both outputs will appear on the serial console. However, the debug output will be asynchronous with the trace output and, hence, difficult to interpret. diff --git a/Documentation/platforms/arm/samv7/boards/same70-xplained/README.txt b/Documentation/platforms/arm/samv7/boards/same70-xplained/README.txt index 483cfa20ea..b69778f1ed 100644 --- a/Documentation/platforms/arm/samv7/boards/same70-xplained/README.txt +++ b/Documentation/platforms/arm/samv7/boards/same70-xplained/README.txt @@ -1322,7 +1322,7 @@ Configuration sub-directories can - An nsh configuration (see below) with added support fo MCAN driver. + An nsh configuration (see below) with added support for MCAN driver. The purpose of the configuration is mainly to track whether changes to SAMv7 MCAN driver do not cause build errors and warnings. diff --git a/Documentation/platforms/arm/stm32h7/boards/linum-stm32h753bi/index.rst b/Documentation/platforms/arm/stm32h7/boards/linum-stm32h753bi/index.rst index bcb8fe97dd..98ddd7ddde 100644 --- a/Documentation/platforms/arm/stm32h7/boards/linum-stm32h753bi/index.rst +++ b/Documentation/platforms/arm/stm32h7/boards/linum-stm32h753bi/index.rst @@ -25,7 +25,7 @@ The board features: - Crystal for RTC 32.768KHz - 1 UART serial for debug - 1 Led RGB -- 1 Buzzer without internal oscilator +- 1 Buzzer without internal oscillator - 1 Mono audio up to 3W - 1 Ethernet 10/100 - 1 MicroSD connector supporting 1 or 4-bit bus @@ -300,7 +300,7 @@ The LINUM-STM32H753BI has a external SDRAM with 16Mbits connected to FMC periphe LCD ======= -The LINUM-STM32H753BI use the LTDC to suport one LCD with RGB connection. +The LINUM-STM32H753BI use the LTDC to support one LCD with RGB connection. =========== ===== LTDC PINS @@ -354,7 +354,7 @@ The LINUM-STM32H753BI has one I2S output. BUZZER ======= -The LINUM-STM32H753BI has a buzzer without internal oscilator +The LINUM-STM32H753BI has a buzzer without internal oscillator ======= ===== GPIO PINS diff --git a/Documentation/platforms/avr/at32uc3/boards/avr32dev1/README.txt b/Documentation/platforms/avr/at32uc3/boards/avr32dev1/README.txt index dcac01fdd6..acd931ab82 100644 --- a/Documentation/platforms/avr/at32uc3/boards/avr32dev1/README.txt +++ b/Documentation/platforms/avr/at32uc3/boards/avr32dev1/README.txt @@ -127,7 +127,7 @@ Atmel Toolchain: sources,and pre-built binaries are available from the Atmel website. CONFIG_AVR32_AVRTOOLSW=y # Use the windows version - CONFIG_AVR32_AVRTOOLSL=y # Ue the Linux version + CONFIG_AVR32_AVRTOOLSL=y # Use the Linux version NOTE: The NuttX builtroot cannot be used to build the AVR32 toolchain. This is because the Atmel patches that add support for the AVR32 are not diff --git a/Documentation/platforms/mips/pic32mx/boards/mirtoo/README.txt b/Documentation/platforms/mips/pic32mx/boards/mirtoo/README.txt index 44d8c67f78..d310a4a903 100644 --- a/Documentation/platforms/mips/pic32mx/boards/mirtoo/README.txt +++ b/Documentation/platforms/mips/pic32mx/boards/mirtoo/README.txt @@ -425,7 +425,7 @@ Toolchains Even then, there are more warnings from the linker and some undefined symbols for non-NuttX code that resides in the unused Microchip libraries. You will - have to solve at least this undefined symbol problem if you want to used thei + have to solve at least this undefined symbol problem if you want to use their XC32 toolchain. Windows Native Toolchains diff --git a/Documentation/platforms/risc-v/rv32m1/boards/rv32m1-vega/README.txt b/Documentation/platforms/risc-v/rv32m1/boards/rv32m1-vega/README.txt index 28106901c2..afa433981a 100644 --- a/Documentation/platforms/risc-v/rv32m1/boards/rv32m1-vega/README.txt +++ b/Documentation/platforms/risc-v/rv32m1/boards/rv32m1-vega/README.txt @@ -23,7 +23,7 @@ Refer to https://open-isa.org for further information about this board. Currently NuttX is ported to RV32M1 RI5CY only. RI5CY is RV32IMC RISC-V CPU with PULP extensions features: - Post-Incrementing load and stores, - - Multiply-Accumulate extenstions, + - Multiply-Accumulate extensions, - ALU extensions, - Hardware Loops. @@ -78,7 +78,7 @@ Default LPUART Configuration LPUART0 is enabled in most configurations (see */defconfig). RX and TX are configured on pins PC7 and PC8, respectively (see include/board.h). These -two above pins are connected to onboard Debug Adpater which provides a USB- +two above pins are connected to onboard Debug Adapter which provides a USB- TTL serial channel. Buttons @@ -164,9 +164,9 @@ Program To program RV32M1, openocd from OPEN ISA and an external jtag adapter are pre- requisite. There are 2 tested jtag adapters: Segger Jlink EDU mini and SiPEED USB Jtag Adapter. The Segger Jlink EDU mini can connect J55 header on RV32M1-VEGA -board directly while SiPEED USB Jtag Adpater has to co-operate with an Adapter +board directly while SiPEED USB Jtag Adapter has to co-operate with an Adapter board to setup wires connection. -Compared to Segger Jlink EDU Mini Adapter, SiPEED USB Jtag Adpater is cheaper but +Compared to Segger Jlink EDU Mini Adapter, SiPEED USB Jtag Adapter is cheaper but not inferior. With SiPEED USB Jtag Adapter, some patches must be applied to rv32m1_ri5cy.cfg: