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

Documentation: Fix a few typos.

Browse Source 
* 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.
This commit is contained in:
Nathan Hartman 2021-04-28 15:14:44 -04:00 committed by Matias N
parent fcd5648bca
commit 26f09cec6d
16 changed files with 49 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Documentation/applications/nsh/login.rst
View File

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

2
Documentation/components/drivers/character/foc.rst
View File

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

22
Documentation/components/drivers/character/watchdog.rst
View File

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

4
Documentation/components/nxgraphics/nxtk.rst
View File

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

6
Documentation/contributing/documentation.rst
View File

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

4
Documentation/contributing/workflow.rst
View File

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

4
Documentation/guides/tasktraceuser.rst
View File

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

2
Documentation/introduction/detailed_support.rst
View File

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

2
Documentation/introduction/resources.rst
View File

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

2
Documentation/platforms/arm/imxrt/boards/teensy-4.x/index.rst
View File

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

12
Documentation/platforms/arm/imxrt/index.rst
View File

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

10
Documentation/platforms/arm/nrf52/index.rst
View File

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

6
Documentation/quickstart/compiling.rst
View File

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

16
Documentation/quickstart/running.rst
View File

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

2
Documentation/reference/os/wqueue.rst
View File

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

2
Documentation/reference/user/01_task_control.rst
View File

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