documentation: Fix several typos
Correcting typos in various documentation files Signed-off-by: Andreas Deininger <andreas@deininger.net>
This commit is contained in:
Andreas Deininger
Carles Cufí
parent
cb46ed6a32
commit
571f8591b9
10 changed files with 18 additions and 18 deletions
|
|
@ -1,7 +1,7 @@
|
|||
.. _bluetooth_cap:
|
||||
|
||||
Commmon Audio Profile
|
||||
#####################
|
||||
Common Audio Profile
|
||||
####################
|
||||
|
||||
|
||||
API Reference
|
||||
|
|
|
|||
|
|
@ -473,7 +473,7 @@ The Configuration Client uses general message parameters set by ``mesh target ds
|
|||
|
||||
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)]``
|
||||
|
|
@ -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.
|
||||
|
||||
* ``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``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
|
|
|||
|
|
@ -435,7 +435,7 @@ track" command:
|
|||
|
||||
|
||||
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
|
||||
caused by these testing commands are independent of the media player,
|
||||
so they do not correspond the actual values of the characteristics nor
|
||||
|
|
|
|||
|
|
@ -308,7 +308,7 @@ requires the following hardware peripherals.
|
|||
.. [i] General Purpose Input Output (GPIO)
|
||||
.. [j] GPIO tasks and events (GPIOTE)
|
||||
.. [k] Temperature sensor (TEMP)
|
||||
.. [l] Universal Asynchronous Receiver Transmiter (UART)
|
||||
.. [l] Universal Asynchronous Receiver Transmitter (UART)
|
||||
.. [m] Interprocess Communication peripheral (IPC)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
* 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
|
||||
* 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:
|
||||
|
||||
* 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
|
||||
* Policy callbacks
|
||||
|
||||
|
|
|
|||
|
|
@ -184,8 +184,8 @@ As a quick reference, see these three board documentation pages:
|
|||
Enabling BOSSAC on Windows Native [Experimental]
|
||||
------------------------------------------------
|
||||
|
||||
Zephyr SDK´s bossac is only currenty support on Linux and macOS. Windows support
|
||||
can be achieved by using the bossac version from `BOSSA oficial releases`_.
|
||||
Zephyr SDK´s bossac is currently supported on Linux and macOS only. Windows support
|
||||
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
|
||||
Windows PATH. A specific bossac executable can be used by passing the
|
||||
``--bossac`` option, as follows:
|
||||
|
|
@ -403,5 +403,5 @@ To enable Zephyr RTOS awareness follow the steps described in
|
|||
.. _Lauterbach TRACE32 Zephyr OS Awareness Manual:
|
||||
https://www2.lauterbach.com/pdf/rtos_zephyr.pdf
|
||||
|
||||
.. _BOSSA oficial releases:
|
||||
.. _BOSSA official releases:
|
||||
https://github.com/shumatech/BOSSA/releases
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
can be done. Existence of "dt_*" entries indicates devicetree 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.
|
||||
|
||||
The grammar for the expression language is as follows:
|
||||
|
|
@ -1080,9 +1080,9 @@ locally. As of now, those options are available:
|
|||
CI)
|
||||
- Option to specify your own list of default platforms overriding what
|
||||
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
|
||||
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
|
||||
default platforms are not in scope.
|
||||
|
||||
|
|
@ -1139,7 +1139,7 @@ And example test level 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::
|
||||
|
||||
|
|
|
|||
|
|
@ -361,7 +361,7 @@ New features:
|
|||
Bug fixes:
|
||||
|
||||
- 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
|
||||
version where the ``manifest: version:`` key was introduced. This incorrectly
|
||||
allowed invalid schema versions, like ``0.8.2``.
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ called.
|
|||
.. image:: ec_host_cmd.png
|
||||
: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
|
||||
one backend layer.
|
||||
|
||||
|
|
|
|||
|
|
@ -161,7 +161,7 @@ See the following example:
|
|||
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
|
||||
subsets of features for specific use cases.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue