This is an automated email from the ASF dual-hosted git repository.
protobits pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-nuttx.git
The following commit(s) were added to refs/heads/master by this push:
new 26f09ce Documentation: Fix a few typos.
26f09ce is described below
commit 26f09cec6dfbc6b44d3b99e765d29d53d956fa52
Author: Nathan Hartman <[email protected]>
AuthorDate: Wed Apr 28 15:14:44 2021 -0400
Documentation: Fix a few typos.
* Documentation/contributing/documentation.rst
* Documentation/guides/tasktraceuser.rst
* Documentation/guides/drivers.rst
* Documentation/quickstart/running.rst
* Documentation/quickstart/compiling.rst
* Documentation/components/drivers/character/watchdog.rst
* Documentation/components/drivers/character/foc.rst
* Documentation/components/nxgraphics/nxtk.rst
* Documentation/applications/nsh/login.rst
* Documentation/introduction/detailed_support.rst
* Documentation/introduction/resources.rst
* Documentation/reference/user/01_task_control.rst
* Documentation/reference/os/wqueue.rst
Fix some misspelled words.
Many of these were caught by codespell.
---
Documentation/applications/nsh/login.rst | 2 +-
Documentation/components/drivers/character/foc.rst | 2 +-
.../components/drivers/character/watchdog.rst | 22 +++++++++++-----------
Documentation/components/nxgraphics/nxtk.rst | 4 ++--
Documentation/contributing/documentation.rst | 6 +++---
Documentation/contributing/workflow.rst | 4 ++--
Documentation/guides/tasktraceuser.rst | 4 ++--
Documentation/introduction/detailed_support.rst | 2 +-
Documentation/introduction/resources.rst | 2 +-
.../arm/imxrt/boards/teensy-4.x/index.rst | 2 +-
Documentation/platforms/arm/imxrt/index.rst | 12 ++++++------
Documentation/platforms/arm/nrf52/index.rst | 10 +++++-----
Documentation/quickstart/compiling.rst | 6 +++---
Documentation/quickstart/running.rst | 16 ++++++++--------
Documentation/reference/os/wqueue.rst | 2 +-
Documentation/reference/user/01_task_control.rst | 2 +-
16 files changed, 49 insertions(+), 49 deletions(-)
diff --git a/Documentation/applications/nsh/login.rst
b/Documentation/applications/nsh/login.rst
index 6aabfc3..01d5386 100644
--- a/Documentation/applications/nsh/login.rst
+++ b/Documentation/applications/nsh/login.rst
@@ -57,7 +57,7 @@ credentials at login time:
This is not very flexible since there can be only one user and the
password is fixed in the FLASH image. This option is also not very
secure because a malicious user could get the password by just
- looking at the ``.text`` stings in the flash image.
+ looking at the ``.text`` strings in the flash image.
#. NSH can also be configured to defer the entire user credential
verification to platform-specific logic with this setting::
diff --git a/Documentation/components/drivers/character/foc.rst
b/Documentation/components/drivers/character/foc.rst
index 1a1612a..f4dd7104 100644
--- a/Documentation/components/drivers/character/foc.rst
+++ b/Documentation/components/drivers/character/foc.rst
@@ -17,7 +17,7 @@ The Nuttx FOC driver is split into two parts:
#. An "upper half", generic driver that provides the common FOC
interface to application level code,
-#. A "lower half", platform-specific driver that implemets
+#. A "lower half", platform-specific driver that implements
the low-level logic to implement the FOC functionality
Files supporting FOC can be found in the following locations:
diff --git a/Documentation/components/drivers/character/watchdog.rst
b/Documentation/components/drivers/character/watchdog.rst
index b4e8e53..287aa45 100644
--- a/Documentation/components/drivers/character/watchdog.rst
+++ b/Documentation/components/drivers/character/watchdog.rst
@@ -65,7 +65,7 @@ Enabling the Watchdog Support and Example in ``menuconfing``
4. Include the Debug Watchdog Feature
In order to get the watchdog timer status, you need to enable it. For
production code and for your application you may disable it.
-
+
Go into menu :menuselection:`Build Setup --> Debug Options` and press
:kbd:`Enter`. Then enable:
- [x] Enable Debug Features
@@ -79,7 +79,7 @@ The previously selected example will basically do the
following:
* Open the watchdog device
* Set the watchdog timeout
* Start the watchdog timer
-* Ping (feed the dog) during the ``pingtime`` with a delay of ``pingdelay``
and print out the wdt status in case debug was enabled.
+* Ping (feed the dog) during the ``pingtime`` with a delay of ``pingdelay``
and print out the wdt status in case debug was enabled.
* Enter into an endless loop without pinging. It will cause the watchdog timer
to reset the chip on timeout, i.e., after timer expiration.
@@ -136,7 +136,7 @@ This command gets the status of the watchdog timer. It
receives a writeable poin
.. c:macro:: WDIOC_SETTIMEOUT
-This command sets the timeout value, i.e., the value that will trigger the
reset or interrupt. The argument is a ``uint32_t`` value in miliseconds.
+This command sets the timeout value, i.e., the value that will trigger the
reset or interrupt. The argument is a ``uint32_t`` value in milliseconds.
.. c:macro:: WDIOC_CAPTURE
@@ -153,12 +153,12 @@ This command registers an user callback that will be
triggered on timeout. It re
.. c:macro:: WDIOC_KEEPALIVE
- This command resets the watchdog timer AKA '**ping**", "**kick**", "**pet**",
"**feed**" the dog".
+ This command resets the watchdog timer AKA '**ping**", "**kick**", "**pet**",
"**feed**" the dog".
Enable Built in System Monitoring to reset the watchdog
-------------------------------------------------------
-The auto-monitor provides an OS-internal mechanism to automatically start and
repeatedly reset the watchdog.
+The auto-monitor provides an OS-internal mechanism to automatically start and
repeatedly reset the watchdog.
To enable it, follow the next instructions:
@@ -181,16 +181,16 @@ To enable it, follow the next instructions:
After selecting the option you may want to configure some parameters:
* **Timeout**: It is the watchdog timer expiration time in seconds.
- * **Keep a live interval**: This is the interval in which the watchdog will
be fed. It is in seconds. It can't be bigger than the timeout. If this interval
is equal to timeout interval, than this interval will automatically change to
half timeout.
+ * **Keep a live interval**: This is the interval in which the watchdog will
be fed. It is in seconds. It can't be bigger than the timeout. If this interval
is equal to timeout interval, than this interval will automatically change to
half timeout.
* **Keep alive by**: This is a choice to determine who is going to feed the
dog. There are 4 possible choices that are described as follows.
- ``Capture callback``: This choice registers a watchdog timer callback to
reset the watchdog every time it expires, i.e., on timeout.
+ ``Capture callback``: This choice registers a watchdog timer callback to
reset the watchdog every time it expires, i.e., on timeout.
``Timer callback``: This choice also uses a timer callback to reset the
watchdog, but it will reset the watchdog every "keep a live interval".
``Worker callback``: This choice uses a Work Queue to reset the watchdog
every "keep a live interval". This choice depends on having the Low or High
Priority Work Queue enabled.
- If only the High Priority Work Queue is enabled, this one will be used,
otherwise Low Priority Work Queue is used.
-
+ If only the High Priority Work Queue is enabled, this one will be used,
otherwise Low Priority Work Queue is used.
+
So, before enabling it, go into menu :menuselection:`RTOS Features --> Work
queue support` and press :kbd:`Enter`.
- [x] Low priority (kernel) worker thread
@@ -200,5 +200,5 @@ To enable it, follow the next instructions:
Go into menu :menuselection:`Device Drivers` and enable:
- [x] Power Management Support
-
-After selecting one of these choices, the chip will keep itself alive by one
of these options.
+
+After selecting one of these choices, the chip will keep itself alive by one
of these options.
diff --git a/Documentation/components/nxgraphics/nxtk.rst
b/Documentation/components/nxgraphics/nxtk.rst
index 6ff4a02..22378b9 100644
--- a/Documentation/components/nxgraphics/nxtk.rst
+++ b/Documentation/components/nxgraphics/nxtk.rst
@@ -500,9 +500,9 @@ these sub-windows to be managed more-or-less independently:
:param rect:
The location within the toolbar window to be retrieved.
:param plane:
- TSpecifies the color plane to get from.
+ Specifies the color plane to get from.
:param dest:
- TThe location to copy the memory region.
+ The location to copy the memory region.
:param deststride:
The width, in bytes, of the dest memory.
diff --git a/Documentation/contributing/documentation.rst
b/Documentation/contributing/documentation.rst
index a430716..6f57b1d 100644
--- a/Documentation/contributing/documentation.rst
+++ b/Documentation/contributing/documentation.rst
@@ -24,7 +24,7 @@ go into ``Documentation`` directory. Then,
$ pip3 install pipenv
$ pipenv install
- $ # activate the virtual environent
+ $ # activate the virtual environment
$ pipenv shell
2. Build documentation:
@@ -82,7 +82,7 @@ sometimes Sphinx's approach is used over standard RST since
it is more powerful
Documentation Conventions
=========================
-While RST/Sphinx provide many ways to do things, it is best to follow a given
convention to mantain consistency and avoid
+While RST/Sphinx provide many ways to do things, it is best to follow a given
convention to maintain consistency and avoid
pitfalls. For this reason, documentation changes should follow the following
set of conventions.
Indentation
@@ -180,7 +180,7 @@ Tips
Spacing
-------
-If you are getting formatting errors, be sure to provide the appropiate
spacing between a directive and its content.
+If you are getting formatting errors, be sure to provide the appropriate
spacing between a directive and its content.
Generally, you should follow this format:
.. code-block:: RST
diff --git a/Documentation/contributing/workflow.rst
b/Documentation/contributing/workflow.rst
index 574c873..d6bf888 100644
--- a/Documentation/contributing/workflow.rst
+++ b/Documentation/contributing/workflow.rst
@@ -13,7 +13,7 @@ You should be aware of the following:
automatically during CI to ensure conformance.
Note that not all existing files in the repository are already adapted to
conform to the standard as this is an ongoing effort. Thus,
- if you're submitting a patch to an existing file you may have to make the
file conform to the standard, even if you are not reponsible
+ if you're submitting a patch to an existing file you may have to make the
file conform to the standard, even if you are not responsible
for those standard violations.
It is also appreciated that you separate any styling fixes in a separate
commit from the functional changes so that these are more
@@ -37,6 +37,6 @@ You should be aware of the following:
- If this is from an inactive project, it may be considered for inclusion
in NuttX, provided that licensing terms allow to do so
and it is deemed of sufficient value to be included, considering that
this code will have to be maintained in NuttX afterwards.
- Note that it is undesireable to included non Apache 2.0 Licensed code
inside the repository, even if the license itself allows it
+ Note that it is undesirable to included non Apache 2.0 Licensed code
inside the repository, even if the license itself allows it
(for example BSD License).
diff --git a/Documentation/guides/tasktraceuser.rst
b/Documentation/guides/tasktraceuser.rst
index 293c3ff..a04c160 100644
--- a/Documentation/guides/tasktraceuser.rst
+++ b/Documentation/guides/tasktraceuser.rst
@@ -109,7 +109,7 @@ After getting the trace, the following command displays the
accumulated trace da
nsh> trace dump
-This will be get the trace results like the followings:
+This will get the trace results like the following:
.. code-block::
@@ -266,7 +266,7 @@ The default value is given by the kernel configuration
``CONFIG_SCHED_INSTRUMENT
- ``-a`` : Disable recording the system call arguments.
- ``+i`` : Enable interrupt trace.
- It records the event of enter/leave interrupt handler which is occured while
the tracing.
+ It records the event of enter/leave interrupt handler which occurred while
tracing.
All IRQs are recorded by default. ``trace irq`` command can filter the IRQs
to be recorded.
- ``-i`` : Disable interrupt trace.
diff --git a/Documentation/introduction/detailed_support.rst
b/Documentation/introduction/detailed_support.rst
index 3979143..65ab059 100644
--- a/Documentation/introduction/detailed_support.rst
+++ b/Documentation/introduction/detailed_support.rst
@@ -2464,7 +2464,7 @@ Also refer to the NuttX board
file for further information about the current state of the port.
NuttX-9.0 added basic support for Microchip SAME54 Xplained Pro board.
-An ethernet driver was also added to the SAME5x familly.
+An ethernet driver was also added to the SAME5x family.
STMicro STM32 F72x/F73x
-----------------------
diff --git a/Documentation/introduction/resources.rst
b/Documentation/introduction/resources.rst
index 0ac8cf4..4ef40af 100644
--- a/Documentation/introduction/resources.rst
+++ b/Documentation/introduction/resources.rst
@@ -13,7 +13,7 @@ Here's a list of Apache NuttX resources that you might find
helpful:
* `Apache NuttX mailing list <https://nuttx.apache.org/community/>`_ – a
very active mailing list, the place to get help with your application or any
questions you have about NuttX.
* `Apache NuttX YouTube channel
<https://www.youtube.com/channel/UC0QciIlcUnjJkL5yJJBmluw/videos>`_ – Alan
Carvalho de Assis's YouTube channel on NuttX. It's a source of a lot of great
practical information.
* `Apache NuttX Coding Standard
<https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard>`_ — How
code should look when you submit new files or modify existing ones.
- * `Apache NuttX Code Contribution Guidlines
<https://cwiki.apache.org/confluence/display/NUTTX/Code+Contribution+Workflow>`_
— The full workflow to follow for submitting code with all the details.
+ * `Apache NuttX Code Contribution Guidelines
<https://cwiki.apache.org/confluence/display/NUTTX/Code+Contribution+Workflow>`_
— The full workflow to follow for submitting code with all the details.
* Git
diff --git a/Documentation/platforms/arm/imxrt/boards/teensy-4.x/index.rst
b/Documentation/platforms/arm/imxrt/boards/teensy-4.x/index.rst
index 5745d30..447f62e 100644
--- a/Documentation/platforms/arm/imxrt/boards/teensy-4.x/index.rst
+++ b/Documentation/platforms/arm/imxrt/boards/teensy-4.x/index.rst
@@ -96,7 +96,7 @@ This configuration can be easily changed to work with Teensy
4.0 by
selecting ``CONFIG_TEENSY_40=y``.
This configuration runs over LPUART1 (pins 24 and 25 on Teensy). Communication
-over USB console can be turn on, but it couses problems with FlexCAN.
+over USB console can be turn on, but it causes problems with FlexCAN.
netnsh-4.1
----------
diff --git a/Documentation/platforms/arm/imxrt/index.rst
b/Documentation/platforms/arm/imxrt/index.rst
index 6a0f9b3..f694e89 100644
--- a/Documentation/platforms/arm/imxrt/index.rst
+++ b/Documentation/platforms/arm/imxrt/index.rst
@@ -69,7 +69,7 @@ range of supply voltage (rail-to-rail operation).
ADC
---
-ADC driver with the successive approximation analog/digital convertor. The
lower-half of
+ADC driver with the successive approximation analog/digital converter. The
lower-half of
this driver is initialize by calling :c:func:`imxrt_adcinitialize`.
CAN
@@ -82,7 +82,7 @@ calling :c:func:`imxrt_cannitialize()`.
There is an booting option that automatically provides initialization of
network interface
in the early stages of booting and therefore calling
:c:func:`imxrt_cannitialize()` via
-board specific logic is not neccessary. This however works only when there is
only one
+board specific logic is not necessary. This however works only when there is
only one
interface in the chip. For running more interfaces (like CAN and Ethernet),
network late
initialization must be turn on by CONFIG_NETDEV_LATEINIT and board specific
logic must call
lower-half part of drivers.
@@ -95,7 +95,7 @@ CMOS Sensor interface which enables the chip to connect
directly to external CMO
DAC
---
-Digital/analog convertor for external signal is only supported in i.MX RT1170
MCU. It is 12 bit
+Digital/analog converter for external signal is only supported in i.MX RT1170
MCU. It is 12 bit
lower power, general purpose DAC.
eLCDIF
@@ -117,7 +117,7 @@ by calling :c:func:`imxrt_netnitialize`.
There is an booting option that automatically provides initialization of
network interface
in the early stages of booting and therefore calling
:c:func:`imxrt_cannitialize()` via
-board specific logic is not neccessary. This however works only when there is
only one
+board specific logic is not necessary. This however works only when there is
only one
interface in the chip. For running more interfaces (like CAN and Ethernet),
network late
initialization must be turn on by CONFIG_NETDEV_LATEINIT and board specific
logic must call
lower-half part of drivers.
@@ -137,7 +137,7 @@ done by :c:func:`imxrt_gpio_write` function and reading is
done by :c:func:`imxr
MCUs i.MX RT1060 and higher includes both standard speed GPIOs (1-5) and high
speed
GPIOS (6-9). Regular and high speed GPIO share the same pins (GPIO1 is with
GPIO6 etc),
-therefore IOMUXC_GPR_GPR26-29 registers are used to determine what modue is
used for the
+therefore IOMUXC_GPR_GPR26-29 registers are used to determine what module is
used for the
GPIO pins.
@@ -160,7 +160,7 @@ Synchronous audio interface provided by I2C module.
Supported in i.MX RT1015 and
SPDIF
-----
-Sony/Philips digital interface audio block. It is a stereo transciever that
allows the
+Sony/Philips digital interface audio block. It is a stereo transceiver that
allows the
processor to receive and transmit digital audio. Supported in i.MX RT1010 and
higher.
SPI
diff --git a/Documentation/platforms/arm/nrf52/index.rst
b/Documentation/platforms/arm/nrf52/index.rst
index fee6e80..582de9c 100644
--- a/Documentation/platforms/arm/nrf52/index.rst
+++ b/Documentation/platforms/arm/nrf52/index.rst
@@ -63,7 +63,7 @@ GPIO/GPIOTE
-----------
Pins can be configured/operated using ``nrf52_gpio_*`` functions. Interrupts
are
-handled via the GPIOTE peripheral in one of two ways: via a GPIOTE channel or
via
+handled via the GPIOTE peripheral in one of two ways: via a GPIOTE channel or
via
PORT events. The former allows for simultaneous rising/falling edge-sensitive
interrupts
per-pin. However, as there are a limited number of channels (and sometimes
these
are used by some drivers for specific tasks), it may not always be possible to
use
@@ -88,7 +88,7 @@ is initialized by calling :c:func:`nrf52_adcinitialize`.
I2C
---
-I2C is supported both in polling and interrupt mode (via EasyDMA).
+I2C is supported both in polling and interrupt mode (via EasyDMA).
.. note:: The I2C peripheral does not support sending two transfers without
sending
a START nor RSTART. For this reason, this is supported via an internal
buffer where
@@ -105,7 +105,7 @@ SPI is supported both in polling and interrupt-based (via
EasyDMA) mode. The lat
supports arbitrarily long transfers using Nordic's list-mode EasyDMA
(intermediate
transfers are currently still manually started).
-It is possible to use SPI without either MOSI/MISO pin defined by simply not
providing
+It is possible to use SPI without either MOSI/MISO pin defined by simply not
providing
the relevant ``BOARD_SPI*_MISO/MOSI_PIN`` definition.
This implementation support power management hooks, which will disable SPI
peripheral when
@@ -115,7 +115,7 @@ UART
----
UART is implemented using polling. UARTE EasyDMA feature is not yet supported.
-This may introduce a large number of interrupts which may be undesireable.
+This may introduce a large number of interrupts which may be undesirable.
PPI
---
@@ -166,7 +166,7 @@ you need to call :c:func:`nrf52_sdc_initialize` on boot,
which will initialize t
SDC support involves registering various high-priority zero-latency interrupts
and thus requires
enabling BASEPRI and high-priority interrupt support. On supported boards, a
sample ``sdc`` configuration
-is provided with settings already set.
+is provided with settings already set.
Note that in this case, some peripherals (mostly those related to BLE) will be
unavailable. Some PPI
channels will also be ocuppied (``NRF52_PPI_NUM_CONFIGURABLE_CHANNELS`` will
be set accordingly in this case).
diff --git a/Documentation/quickstart/compiling.rst
b/Documentation/quickstart/compiling.rst
index c2a2ae4..0aef207 100644
--- a/Documentation/quickstart/compiling.rst
+++ b/Documentation/quickstart/compiling.rst
@@ -21,7 +21,7 @@ a pre-existing configuration. To list all supported
configurations you can do:
$ ./tools/configure.sh -L | less
The output is in the format ``<board name>:<board configuration>``. You will
see that
-generally all boards support the ``nsh`` configuration which is a good sarting
point
+generally all boards support the ``nsh`` configuration which is a good
starting point
since it enables booting into the interactive command line
:doc:`/applications/nsh/index`.
@@ -43,7 +43,7 @@ configuration system with:
$ cd nuttx/
$ make menuconfig
-
+
Modifying the configuration is covered in :doc:`configuring`.
Build NuttX
@@ -66,7 +66,7 @@ To clean the build, you can do:
.. code-block:: console
$ make clean
-
+
.. tip::
To increase build speed (or of any other target such as ``clean``), you can
diff --git a/Documentation/quickstart/running.rst
b/Documentation/quickstart/running.rst
index dd07a6e..6deb17d 100644
--- a/Documentation/quickstart/running.rst
+++ b/Documentation/quickstart/running.rst
@@ -11,7 +11,7 @@ which also integrates the debugger/programmer in the board
itself exposed via US
connector.
A good choice is a Nucleo or Discovery board from ST Microelectronics,
-as there is a wide choice of suported boards for the STM32 architecture in
NuttX.
+as there is a wide choice of supported boards for the STM32 architecture in
NuttX.
Also, these boards expose an UART port over the USB connection which allows you
to interact with NuttX via the interactive console without any extra hardware.
For the purposes of this guide, we will use the Nucleo F103RB board.
@@ -25,7 +25,7 @@ of programmers and target microcontrollers.
You should note that ``openocd`` project has not made stable releases for long
time and support for newer hardware will probably be only available in the
-latest Git version, so it is actually recommended to install latest
development
+latest Git version, so it is actually recommended to install latest development
version.
.. tabs::
@@ -37,7 +37,7 @@ version.
.. tab:: Install latest version from source
.. code-block:: console
-
+
$ git clone git://git.code.sf.net/p/openocd/code openocd
$ cd openocd
$ ./bootstrap
@@ -46,7 +46,7 @@ version.
The resulting installation will be under ``openocd/install``. You can add
``openocd/install/bin`` to your ``PATH``.
-
+
Now, to flash the binary to your board, connect the USB cable and do:
.. code-block:: console
@@ -72,15 +72,15 @@ if you don't see anything):
.. code-tab:: console gtkterm (GUI)
$ gtkterm -s 115200 -p /dev/ttyUSB0
-
+
.. tip::
You may have to add yourself to the ``dialout`` group on Linux to have
permission
to access serial ports:
-
+
.. code-block:: console
-
+
$ gpasswd -a <user> dialout
-
+
Where ``<user>`` is your username. You will need to log out from your desktop
for the change to have effect.
diff --git a/Documentation/reference/os/wqueue.rst
b/Documentation/reference/os/wqueue.rst
index d22291b..d026d32 100644
--- a/Documentation/reference/os/wqueue.rst
+++ b/Documentation/reference/os/wqueue.rst
@@ -60,7 +60,7 @@ to match the highest priority client.
**Configuration Options**.
-- ``CONFIG_SCHED_HPWORK``. Enables the hight priority work queue.
+- ``CONFIG_SCHED_HPWORK``. Enables the high priority work queue.
- ``CONFIG_SCHED_HPNTHREADS``. The number of threads in the
high-priority queue's thread pool. Default: 1
- ``CONFIG_SCHED_HPWORKPRIORITY``. The execution priority of the
diff --git a/Documentation/reference/user/01_task_control.rst
b/Documentation/reference/user/01_task_control.rst
index 3b4566f..63a23be 100644
--- a/Documentation/reference/user/01_task_control.rst
+++ b/Documentation/reference/user/01_task_control.rst
@@ -199,7 +199,7 @@ Functions
- Deletion of self is supported, but only because ``task_delete()``
will re-direct processing to ``exit()``.
-.. :c:funcion:: int task_restart(pid_t pid)
+.. :c:function:: int task_restart(pid_t pid)
This function *restarts* a task. The task is first
terminated and then reinitialized with same ID, priority, original entry
