sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Documentation: Fix various typos

Browse Source
This commit is contained in:
Nathan Hartman 2023-11-23 16:31:11 -05:00 committed by Xiang Xiao
parent 9b77b2ba0b
commit 26e4dd5638
18 changed files with 27 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Documentation/applications/graphics/nxwm/cnxconsole.rst
View File

@ -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``

2
Documentation/components/net/wqueuedeadlocks.rst
View File

@ -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.

2
Documentation/components/nxgraphics/nx.rst
View File

@ -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

2
Documentation/guides/citests.rst
View File

@ -7,7 +7,7 @@ Running CI Test Locally
NuttX automatically runs continuous integration (CI) tests on
`simulator <https://nuttx.apache.org/docs/latest/guides/simulator.html>`__
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.

2
Documentation/guides/stm32ccm.rst
View File

@ -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

4
Documentation/guides/testingtcpip.rst
View File

@ -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

6
Documentation/implementation/critical_sections.rst
View File

@ -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:

2
Documentation/implementation/processes_vs_tasks.rst
View File

@ -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.

4
Documentation/platforms/arm/imx6/boards/sabre-6quad/README.txt
View File

@ -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

2
Documentation/platforms/arm/lpc17xx/boards/olimex-lpc1766stk/README.txt
View File

@ -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")

2
Documentation/platforms/arm/sama5/boards/sama5d3-xplained/README.txt
View File

@ -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.

2
Documentation/platforms/arm/sama5/boards/sama5d3x-ek/README.txt
View File

@ -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.

2
Documentation/platforms/arm/sama5/boards/sama5d4-ek/README.txt
View File

@ -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.

2
Documentation/platforms/arm/samv7/boards/same70-xplained/README.txt
View File

@ -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.

6
Documentation/platforms/arm/stm32h7/boards/linum-stm32h753bi/index.rst
View File

@ -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

2
Documentation/platforms/avr/at32uc3/boards/avr32dev1/README.txt
View File

@ -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

2
Documentation/platforms/mips/pic32mx/boards/mirtoo/README.txt
View File

@ -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

8
Documentation/platforms/risc-v/rv32m1/boards/rv32m1-vega/README.txt
View File

@ -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: