michaelh/zephyr
1
0
Fork 0
Code Releases Activity

documentation: Fix several typos

Browse source 
Correcting typos in various documentation files

Signed-off-by: Andreas Deininger <andreas@deininger.net>
This commit is contained in:
Andreas Deininger 2023-08-03 21:11:31 +02:00 • committed by Carles Cufí
commit 571f8591b9
10 changed files with 18 additions and 18 deletions
Download patch file Download diff file Expand all files Collapse all files

4
doc/connectivity/bluetooth/api/cap.rst
View file

@ -1,7 +1,7 @@
.. _bluetooth_cap: .. _bluetooth_cap:
Commmon Audio Profile Common Audio Profile
##################### ####################
API Reference API Reference

4
doc/connectivity/bluetooth/api/mesh/shell.rst
View file

@ -473,7 +473,7 @@ The Configuration Client uses general message parameters set by ``mesh target ds
Get or set the default TTL value. Get or set the default TTL value.
* ``TTL``: If present, sets the new default TTL value. Leagal TTL values are 0x00 and 0x02-0x7f. If omitted, the current default TTL value is printed. * ``TTL``: If present, sets the new default TTL value. Legal TTL values are 0x00 and 0x02-0x7f. If omitted, the current default TTL value is printed.
``mesh models cfg friend [Val(off, on)]`` ``mesh models cfg friend [Val(off, on)]``
@ -1229,7 +1229,7 @@ To use these commands, a Firmware Distribution Server must be instantiated by th
Get a list of info about firmware receivers. Get a list of info about firmware receivers.
* ``First``: Index of the first receiver to get from the receiver list. * ``First``: Index of the first receiver to get from the receiver list.
* ``Count``: The number of recievers for which to get info. * ``Count``: The number of receivers for which to get info.
``mesh models dfd capabilities-get`` ``mesh models dfd capabilities-get``
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

2
doc/connectivity/bluetooth/api/shell/mcp.rst
View file

@ -435,7 +435,7 @@ track" command:
Some server commands are available. These commands force Some server commands are available. These commands force
notifications of the various characterstics, for testing that the notifications of the various characteristics, for testing that the
client receives notifications. The values sent in the notifications client receives notifications. The values sent in the notifications
caused by these testing commands are independent of the media player, caused by these testing commands are independent of the media player,
so they do not correspond the actual values of the characteristics nor so they do not correspond the actual values of the characteristics nor

2
doc/connectivity/bluetooth/bluetooth-ctlr-arch.rst
View file

@ -308,7 +308,7 @@ requires the following hardware peripherals.
.. [i] General Purpose Input Output (GPIO) .. [i] General Purpose Input Output (GPIO)
.. [j] GPIO tasks and events (GPIOTE) .. [j] GPIO tasks and events (GPIOTE)
.. [k] Temperature sensor (TEMP) .. [k] Temperature sensor (TEMP)
.. [l] Universal Asynchronous Receiver Transmiter (UART) .. [l] Universal Asynchronous Receiver Transmitter (UART)
.. [m] Interprocess Communication peripheral (IPC) .. [m] Interprocess Communication peripheral (IPC)

4
doc/connectivity/usb/pd/ucds.rst
View file

@ -27,7 +27,7 @@ The configuration of a USB-C Device is done in the stack layer and devicetree.
The following devicetree, structures and callbacks need to be defined: The following devicetree, structures and callbacks need to be defined:
* Devicetree usb-c-connector node referencing a TCPC * Devicetree usb-c-connector node referencing a TCPC
* Devicetree vbus node referencing a VBUS measurment device * Devicetree vbus node referencing a VBUS measurement device
* User defined structure that encapsulates application specific data * User defined structure that encapsulates application specific data
* Policy callbacks * Policy callbacks
@ -117,7 +117,7 @@ The configuration of a USB-C Device is done in the stack layer and devicetree.
Define the following devicetree, structures and callbacks: Define the following devicetree, structures and callbacks:
* Devicetree ``usb-c-connector`` node referencing a TCPC * Devicetree ``usb-c-connector`` node referencing a TCPC
* Devicetree ``vbus`` node referencing a VBUS measurment device * Devicetree ``vbus`` node referencing a VBUS measurement device
* User defined structure that encapsulates application specific data * User defined structure that encapsulates application specific data
* Policy callbacks * Policy callbacks

6
doc/develop/flash_debug/host-tools.rst
View file

@ -184,8 +184,8 @@ As a quick reference, see these three board documentation pages:
Enabling BOSSAC on Windows Native [Experimental] Enabling BOSSAC on Windows Native [Experimental]
------------------------------------------------ ------------------------------------------------
Zephyr SDK´s bossac is only currenty support on Linux and macOS. Windows support Zephyr SDK´s bossac is currently supported on Linux and macOS only. Windows support
can be achieved by using the bossac version from `BOSSA oficial releases`_. can be achieved by using the bossac version from `BOSSA official releases`_.
After installing using default options, the :file:`bossac.exe` must be added to After installing using default options, the :file:`bossac.exe` must be added to
Windows PATH. A specific bossac executable can be used by passing the Windows PATH. A specific bossac executable can be used by passing the
``--bossac`` option, as follows: ``--bossac`` option, as follows:
@ -403,5 +403,5 @@ To enable Zephyr RTOS awareness follow the steps described in
.. _Lauterbach TRACE32 Zephyr OS Awareness Manual: .. _Lauterbach TRACE32 Zephyr OS Awareness Manual:
https://www2.lauterbach.com/pdf/rtos_zephyr.pdf https://www2.lauterbach.com/pdf/rtos_zephyr.pdf
.. _BOSSA oficial releases: .. _BOSSA official releases:
https://github.com/shumatech/BOSSA/releases https://github.com/shumatech/BOSSA/releases

8
doc/develop/test/twister.rst
View file

@ -561,7 +561,7 @@ filter: <expression>
Twister will first evaluate the expression to find if a "limited" cmake call, i.e. using package_helper cmake script, Twister will first evaluate the expression to find if a "limited" cmake call, i.e. using package_helper cmake script,
can be done. Existence of "dt_*" entries indicates devicetree is needed. can be done. Existence of "dt_*" entries indicates devicetree is needed.
Existence of "CONFIG*" entries indicates kconfig is needed. Existence of "CONFIG*" entries indicates kconfig is needed.
If there are no other types of entries in the expression a filtration can be done wihout creating a complete build system. If there are no other types of entries in the expression a filtration can be done without creating a complete build system.
If there are entries of other types a full cmake is required. If there are entries of other types a full cmake is required.
The grammar for the expression language is as follows: The grammar for the expression language is as follows:
@ -1080,9 +1080,9 @@ locally. As of now, those options are available:
CI) CI)
- Option to specify your own list of default platforms overriding what - Option to specify your own list of default platforms overriding what
upstream defines. upstream defines.
- Ability to override `build_onl_all` options used in some testscases. - Ability to override `build_onl_all` options used in some testcases.
This will treat tests or sample as any other just build for default This will treat tests or sample as any other just build for default
platforms you specify in the configuation file or on the command line. platforms you specify in the configuration file or on the command line.
- Ignore some logic in twister to expand platform coverage in cases where - Ignore some logic in twister to expand platform coverage in cases where
default platforms are not in scope. default platforms are not in scope.
@ -1139,7 +1139,7 @@ And example test level configuration::
Combined configuration Combined configuration
====================== ======================
To mix the Platform and level confgiuration, you can take an example as below: To mix the Platform and level configuration, you can take an example as below:
And example platforms plus level configuration:: And example platforms plus level configuration::

2
doc/develop/west/release-notes.rst
View file

@ -361,7 +361,7 @@ New features:
Bug fixes: Bug fixes:
- West now checks that the manifest schema version is one of the explicitly - West now checks that the manifest schema version is one of the explicitly
allowed vlaues documented in :ref:`west-manifest-schema-version`. The old allowed values documented in :ref:`west-manifest-schema-version`. The old
behavior was just to check that the schema version was newer than the west behavior was just to check that the schema version was newer than the west
version where the ``manifest: version:`` key was introduced. This incorrectly version where the ``manifest: version:`` key was introduced. This incorrectly
allowed invalid schema versions, like ``0.8.2``. allowed invalid schema versions, like ``0.8.2``.

2
doc/services/device_mgmt/ec_host_cmd.rst
View file

@ -29,7 +29,7 @@ called.
.. image:: ec_host_cmd.png .. image:: ec_host_cmd.png
:align: center :align: center
SHI (Serial Host Interface) is different to this because it is used olny for communication with a SHI (Serial Host Interface) is different to this because it is used only for communication with a
host. SHI does not have API itself, thus the backend and peripheral driver layers are combined into host. SHI does not have API itself, thus the backend and peripheral driver layers are combined into
one backend layer. one backend layer.

2
doc/services/ipc/ipc_service/ipc_service.rst
View file

@ -161,7 +161,7 @@ See the following example:
Backends Backends
******** ********
The requirements needed for implementating backends give flexibility to the IPC The requirements needed for implementing backends give flexibility to the IPC
service. These allow for the addition of dedicated backends having only a service. These allow for the addition of dedicated backends having only a
subsets of features for specific use cases. subsets of features for specific use cases.