doc: fix misspelling in docs and API comments
Fix misspellings missed during regular reviews. Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
This commit is contained in:
David B. Kinder
Anas Nashif
parent
c3cf543452
commit
5d8e367efe
|
|
@ -142,4 +142,4 @@ You can debug an application in the usual way. Here is an example for the
|
|||
.. _Black Pill Board:
|
||||
https://wiki.stm32duino.com/index.php?title=Black_Pill
|
||||
.. _EmbedJournal:
|
||||
https://embedjournal.com/tag/stm32-min-dev/
|
||||
https://embedjournal.com/tag/stm32-min-dev/
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Changes submitted to a development topic branch can evolve and improve
|
|||
incrementally in a branch, before they are submitted to the mainline tree for
|
||||
final integration.
|
||||
|
||||
By dedicating an isolated branch to complex features, it’s
|
||||
By dedicating an isolated branch to complex features, it's
|
||||
possible to initiate in-depth discussions around new additions before
|
||||
integrating them into the official project.
|
||||
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ Here is the description of the various moderation levels:
|
|||
|
||||
- Bug Fixes, all priorities
|
||||
- Enhancements
|
||||
- Minor “self-contained” New Features
|
||||
- Minor "self-contained" New Features
|
||||
- High:
|
||||
|
||||
- Bug Fixes: P1 and P2
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Code Review
|
|||
|
||||
GitHub is intended to provide a framework for reviewing every commit before it
|
||||
is accepted into the code base. Changes, in the form of Pull Requests (PR) are
|
||||
uploaded to GitHub but don’t actually become a part of the project until they’ve
|
||||
uploaded to GitHub but don't actually become a part of the project until they've
|
||||
been reviewed, passed a series of checks (CI), and are approved by maintainers.
|
||||
GitHub is used to support the standard open source practice of submitting
|
||||
patches, which are then reviewed by the project members before being applied to
|
||||
|
|
@ -31,7 +31,7 @@ changes are proposed using pull request, we need to allow for a minimal review
|
|||
time to give developers and contributors the opportunity to review and comment
|
||||
on changes. There are different categories of changes and we know that some
|
||||
changes do require reviews by subject matter experts and owners of the subsystem
|
||||
being changed. Many changes fall under the “trivial” category that can be
|
||||
being changed. Many changes fall under the "trivial" category that can be
|
||||
addressed with general reviews and do not need to be queued for a maintainer or
|
||||
code-owner review. Additionally, some changes might require further discussions
|
||||
and a decision by the TSC or the Security working group. To summarize the above,
|
||||
|
|
@ -134,7 +134,7 @@ Developers and contributors should always seek review, however there are cases
|
|||
when reviewers are not available and there is a need to get a code change into
|
||||
the tree as soon as possible.
|
||||
|
||||
Reviewers shall not ‘Request Changes’ without comments or justification
|
||||
Reviewers shall not 'Request Changes' without comments or justification
|
||||
=======================================================================
|
||||
|
||||
Any change requests (-1) on a pull request have to be justified. A reviewer
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ stack.
|
|||
BLE Layers
|
||||
==========
|
||||
|
||||
There are 3 main layers that together constitute a full Bluetooth Low Enery
|
||||
There are 3 main layers that together constitute a full Bluetooth Low Energy
|
||||
protocol stack:
|
||||
|
||||
* **Host**: This layer sits right below the application, and is comprised of
|
||||
|
|
@ -75,12 +75,12 @@ following configurations are commonly used:
|
|||
configuration. This configuration allows for a wider variety of combinations of
|
||||
Hosts when using the Zephyr OS as a Controller. Since HCI ensures
|
||||
interoperability among Host and Controller implementations, including of course
|
||||
Zephyr’s very own BLE Host and Controller, users of the Zephyr Controller can
|
||||
Zephyr's very own BLE Host and Controller, users of the Zephyr Controller can
|
||||
choose to use whatever Host running on any platform they prefer. For example,
|
||||
the host can be the Linux BLE Host stack (BlueZ) running on any processor
|
||||
capable of supporting Linux. The Host processor may of course also run Zephyr
|
||||
and the Zephyr OS BLE Host. Conversely, combining an IC running the Zephyr
|
||||
Host with an external Controller that does not run Zephyr is alos supported.
|
||||
Host with an external Controller that does not run Zephyr is also supported.
|
||||
|
||||
.. _bluetooth-build-types:
|
||||
|
||||
|
|
@ -90,7 +90,7 @@ Build Types
|
|||
The Zephyr software stack as an RTOS is highly configurable, and in particular,
|
||||
the BLE subsystem can be configured in multiple ways during the build process to
|
||||
include only the features and layers that are required to reduce RAM and ROM
|
||||
footprint as well as power consumption. Here’s a short list of the different
|
||||
footprint as well as power consumption. Here's a short list of the different
|
||||
BLE-enabled builds that can be produced from the Zephyr project codebase:
|
||||
|
||||
* **Controller-only build**: When built as a BLE Controller, Zephyr includes
|
||||
|
|
@ -166,7 +166,7 @@ the BLE Controller.
|
|||
|
||||
This configuration is not limited to using a Zephyr OS Host, as the right side
|
||||
of the image shows. One can indeed take one of the many existing GNU/Linux
|
||||
distributions, most of which include Linux’s own BLE Host (BlueZ), to connect it
|
||||
distributions, most of which include Linux's own BLE Host (BlueZ), to connect it
|
||||
via UART or USB to one or more instances of the Zephyr OS Controller build.
|
||||
BlueZ as a Host supports multiple Controllers simultaneously for applications
|
||||
that require more than one BLE radio operating at the same time but sharing the
|
||||
|
|
@ -250,14 +250,14 @@ peripheral implicitly enables broadcaster role. Usually the first step
|
|||
when creating an application is to decide which roles are needed and go
|
||||
from there. Bluetooth Mesh is a slightly special case, requiring at
|
||||
least the observer and broadcaster roles, and possibly also the
|
||||
Peripheral role. This will be descibed in more detail in a later
|
||||
Peripheral role. This will be described in more detail in a later
|
||||
section.
|
||||
|
||||
Peripheral role
|
||||
===============
|
||||
|
||||
Most Zephyr-based BLE devices will most likely be peripheral-role
|
||||
devices. This means that they peform connectable advertising and expose
|
||||
devices. This means that they perform connectable advertising and expose
|
||||
one or more GATT services. After registering services using the
|
||||
:cpp:func:`bt_gatt_service_register` API the application will typically
|
||||
start connectable advertising using the :cpp:func:`bt_le_adv_start` API.
|
||||
|
|
@ -268,7 +268,7 @@ such as :zephyr_file:`samples/bluetooth/peripheral_hr`.
|
|||
Central role
|
||||
============
|
||||
|
||||
Central role may not be as common for Zephyr-based devices as periphal
|
||||
Central role may not be as common for Zephyr-based devices as peripheral
|
||||
role, but it is still a plausible one and equally well supported in
|
||||
Zephyr. Rather than accepting connections from other devices a central
|
||||
role device will scan for available peripheral device and choose one to
|
||||
|
|
@ -313,7 +313,7 @@ are not exposed to the application, but a limited amount of information
|
|||
counted, and the application is expected to use the
|
||||
:cpp:func:`bt_conn_ref` API whenever storing a connection pointer for a
|
||||
longer period of time, since this ensures that the object remains valid
|
||||
(even if the connection would get disconnected). Similarily the
|
||||
(even if the connection would get disconnected). Similarly the
|
||||
:cpp:func:`bt_conn_unref` API is to be used when releasing a reference
|
||||
to a connection.
|
||||
|
||||
|
|
@ -329,12 +329,12 @@ connection object through the return value of the
|
|||
Security
|
||||
========
|
||||
|
||||
To acheive a secure relationship between two Bluetooth devices a process
|
||||
To achieve a secure relationship between two Bluetooth devices a process
|
||||
called pairing is used. This process can either be triggered implicitly
|
||||
through the security properties of GATT services, or explicitly using
|
||||
the :cpp:func:`bt_conn_security` API on a connection object.
|
||||
|
||||
To acheive a higher security level, and protect against
|
||||
To achieve a higher security level, and protect against
|
||||
Man-In-The-Middle (MITM) attacks, it is recommended to use some
|
||||
out-of-band channel during the pairing. If the devices have a sufficient
|
||||
user interface this "channel" is the user itself. The capabilities of
|
||||
|
|
@ -377,7 +377,7 @@ configuration option: :option:`CONFIG_BT_L2CAP_DYNAMIC_CHANNEL`. This channels
|
|||
support segmentation and reassembly transparently, they also support credit
|
||||
based flow control making it suitable for data streams.
|
||||
|
||||
Channels instaces are represented by the :cpp:class:`bt_l2cap_chan` struct which
|
||||
Channels instances are represented by the :cpp:class:`bt_l2cap_chan` struct which
|
||||
contains the callbacks in the :cpp:class:`bt_l2cap_chan_ops` struct to inform
|
||||
when the channel has been connected, disconnected or when the encryption has
|
||||
changed.
|
||||
|
|
@ -467,7 +467,7 @@ Discover procedures can be initiated with the use of
|
|||
:cpp:func:`bt_gatt_discover` API which takes the
|
||||
:cpp:class:`bt_gatt_dicover_params` struct which describes the type of
|
||||
discovery. The parameters also serves as a filter when setting the ``uuid``
|
||||
field only attributes which matches will be discovered, in contranst setting it
|
||||
field only attributes which matches will be discovered, in contrast setting it
|
||||
to NULL allows all attributes to be discovered.
|
||||
|
||||
.. note::
|
||||
|
|
@ -503,8 +503,8 @@ default, mesh requires both observer and broadcaster role to be enabled.
|
|||
If the optional GATT Proxy feature is desired, then peripheral role
|
||||
should also be enabled.
|
||||
|
||||
Peristent storage
|
||||
=================
|
||||
Persistent storage
|
||||
==================
|
||||
|
||||
The Bluetooth host stack uses the settings subsystem to implement
|
||||
persistent storage to flash. This requires the presence of a flash
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ CMSIS RTOS v1
|
|||
##########################
|
||||
|
||||
Cortex-M Software Interface Standard (CMSIS) RTOS is a vendor-independent
|
||||
hardware abstraction layer for the ARM Cortex®-M processor series and defines
|
||||
hardware abstraction layer for the ARM Cortex-M processor series and defines
|
||||
generic tool interfaces. Though it was originally defined for ARM Cortex-M
|
||||
microcontrollers alone, it could be easily extended to other microcontrollers
|
||||
making it generic. For more information on CMSIS RTOS v1, please refer
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ CMSIS RTOS v2
|
|||
##########################
|
||||
|
||||
Cortex-M Software Interface Standard (CMSIS) RTOS is a vendor-independent
|
||||
hardware abstraction layer for the ARM Cortex®-M processor series and defines
|
||||
hardware abstraction layer for the ARM Cortex-M processor series and defines
|
||||
generic tool interfaces. Though it was originally defined for ARM Cortex-M
|
||||
microcontrollers alone, it could be easily extended to other microcontrollers
|
||||
making it generic. For more information on CMSIS RTOS v2, please refer to the
|
||||
|
|
|
|||
|
|
@ -31,10 +31,10 @@ a multi-repo installation. When using upstream Zephyr, it looks like this:
|
|||
|
||||
└── zephyrproject/
|
||||
├── .west/
|
||||
│ ├── config
|
||||
│ └── west/
|
||||
│ ├── config
|
||||
│ └── west/
|
||||
├── zephyr/
|
||||
│ └── west.yml
|
||||
│ └── west.yml
|
||||
├── a-project
|
||||
└── ...
|
||||
|
||||
|
|
@ -108,7 +108,7 @@ Rationale for a custom tool
|
|||
During the different stages of design and development for west, using already
|
||||
established and proven multi-repo technologies was considered multiple times.
|
||||
After careful analysis, no existing tool or mechanism was found suitable for
|
||||
Zephyr’s use case set and requirements. The following two tools were examined
|
||||
Zephyr's use case set and requirements. The following two tools were examined
|
||||
in detail:
|
||||
|
||||
* Google repo
|
||||
|
|
@ -277,7 +277,7 @@ installation:
|
|||
to the revisions present in the manifest file.
|
||||
|
||||
West's view of multirepo history looks like this example (though some parts of
|
||||
the example are specific to upstream Zephyr’s use of west):
|
||||
the example are specific to upstream Zephyr's use of west):
|
||||
|
||||
.. figure:: west-mr-model.png
|
||||
:align: center
|
||||
|
|
@ -312,7 +312,7 @@ Notice a few important details about the above picture:
|
|||
- Two zephyr commits can have the same external commits (like ``F`` and ``G``).
|
||||
- Not all commits in some projects are associated with a zephyr commit (``P3``
|
||||
"jumps" multiple commits in its history between zephyr commits ``B → C``).
|
||||
- Every zephyr commit’s manifest refers to exactly one version in each of the
|
||||
- Every zephyr commit's manifest refers to exactly one version in each of the
|
||||
other projects it cares about.
|
||||
|
||||
The ``manifest-rev`` branch
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ is implemented using plain buffers. Users of the API create sockets
|
|||
for communication and pass the buffer to the library for parsing and other
|
||||
purposes. The library itself doesn't create any sockets for users.
|
||||
|
||||
On top of CoAP, Zephyr has support for LWM2M “Lightweight Machine 2 Machine”
|
||||
On top of CoAP, Zephyr has support for LWM2M "Lightweight Machine 2 Machine"
|
||||
protocol, a simple, low-cost remote management and service enablement mechanism.
|
||||
See :ref:`lwm2m_interface` for more information.
|
||||
|
||||
|
|
|
|||
|
|
@ -788,7 +788,7 @@ These GitHub issues were closed since the previous 1.11.0 tagged release:
|
|||
* :github:`8150` - Doc: Update Zephyr security overview
|
||||
* :github:`8171` - Tests failing with a stacking error on frdm_k64f
|
||||
* :github:`8172` - Networking tests failing with an assertion on frdm_k64f
|
||||
* :github:`8180` - objcopy bug？
|
||||
* :github:`8180` - objcopy bug
|
||||
* :github:`8182` - Problem with obtaining hop_limit from a received packet
|
||||
* :github:`8189` - lwm2m: Quickly running out of resources when using observe
|
||||
* :github:`8192` - MPU Fault on some platforms after THREAD_MONITOR "fix"
|
||||
|
|
|
|||
|
|
@ -348,7 +348,7 @@ release:
|
|||
* :github:`9574` - tests/cmsis_rtos_v1 - test_mutex_lock_timeout results in Assertion failure on all targets with PR#9569
|
||||
* :github:`9561` - Question: Does it support passing the bootloader(mcuboot) parameter to the kernel(zephyr)?
|
||||
* :github:`9558` - DTC 1.4.7 breaks at least FRDM_K64F builds
|
||||
* :github:`9537` - ENC28J60 can‘t receive packets properly
|
||||
* :github:`9537` - ENC28J60 can't receive packets properly
|
||||
* :github:`9536` - console: missing kernel.h include in header
|
||||
* :github:`9535` - broken callback handling in nrfx gpio driver
|
||||
* :github:`9530` - Bluetooth/gatt: bt_gatt_notify never return -ENOMEM, undocumented return value.
|
||||
|
|
@ -582,7 +582,7 @@ release:
|
|||
* :github:`8039` - tests/shell failing on Arduino 101 / Quark SE arc
|
||||
* :github:`8026` - Verify TLS server side operation
|
||||
* :github:`8019` - ARP: should drop any packet pended when timeout
|
||||
* :github:`8013` - Open-AMP：power on can not communicate
|
||||
* :github:`8013` - Open-AMP power on can not communicate
|
||||
* :github:`7999` - HCI UART with Linux host cannot connect to nrf52 6lowpan peripheral
|
||||
* :github:`7978` - SSE and SSE_FP_MATH are set on frdm_k64f, which doesn't have it, triggering Kconfig warnings
|
||||
* :github:`7977` - ARC_INIT is set on boards that don't have it, triggering Kconfig warnings
|
||||
|
|
|
|||
|
|
@ -539,7 +539,7 @@ void device_pm_disable(struct device *dev);
|
|||
* the caller is interested in.
|
||||
* @retval 0 If successfully queued the Async request. If queued,
|
||||
* the caller need to wait on the poll event linked to device
|
||||
* pm signal mechanism to know the comepletion of resume operation.
|
||||
* pm signal mechanism to know the completion of resume operation.
|
||||
* @retval Errno Negative errno code if failure.
|
||||
*/
|
||||
int device_pm_get(struct device *dev);
|
||||
|
|
@ -570,7 +570,7 @@ int device_pm_get_sync(struct device *dev);
|
|||
* the caller is interested in.
|
||||
* @retval 0 If successfully queued the Async request. If queued,
|
||||
* the caller need to wait on the poll event linked to device pm
|
||||
* signal mechanism to know the comepletion of suspend operation.
|
||||
* signal mechanism to know the completion of suspend operation.
|
||||
* @retval Errno Negative errno code if failure.
|
||||
*/
|
||||
int device_pm_put(struct device *dev);
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ int mdm_receiver_send(struct mdm_receiver_context *ctx,
|
|||
/**
|
||||
* @brief Registers receiver context.
|
||||
*
|
||||
* @note Aquires receivers device, and prepares the context to be used.
|
||||
* @note Acquires receivers device, and prepares the context to be used.
|
||||
*
|
||||
* @param *ctx: receiver context to register.
|
||||
* @param *uart_dev_name: communication device for the receiver context.
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@
|
|||
* Spectre V1 vulnerability.
|
||||
*
|
||||
* CPUs with speculative execution may speculate past any size checks and
|
||||
* leak confidential data due to analyzsis of micro-architectural properties.
|
||||
* leak confidential data due to analysis of micro-architectural properties.
|
||||
* This will unconditionally truncate any out-of-bounds indexes to
|
||||
* zero in the speculative execution path using bit twiddling instead of
|
||||
* any branch instructions.
|
||||
|
|
|
|||
|
|
@ -261,7 +261,7 @@ int lwm2m_device_add_err(u8_t error_code);
|
|||
|
||||
|
||||
/**
|
||||
* @brief LWM2M Firemware Update object states
|
||||
* @brief LWM2M Firmware Update object states
|
||||
*
|
||||
* An LwM2M client or the LwM2M Firmware Update object use the following codes
|
||||
* to represent the LwM2M Firmware Update state (5/0/3).
|
||||
|
|
@ -272,7 +272,7 @@ int lwm2m_device_add_err(u8_t error_code);
|
|||
#define STATE_UPDATING 3
|
||||
|
||||
/**
|
||||
* @brief LWM2M Firemware Update object result codes
|
||||
* @brief LWM2M Firmware Update object result codes
|
||||
*
|
||||
* After processing a firmware update, the client sets the result via one of
|
||||
* the following codes via lwm2m_engine_set_u8("5/0/5", [result code])
|
||||
|
|
@ -311,7 +311,7 @@ lwm2m_engine_set_data_cb_t lwm2m_firmware_get_write_cb(void);
|
|||
* @brief Set data callback to handle firmware update execute events.
|
||||
*
|
||||
* LwM2M clients use this function to register a callback for receiving the
|
||||
* update resource "execute" operation on the LwM2M Firmware Update oject.
|
||||
* update resource "execute" operation on the LwM2M Firmware Update object.
|
||||
*
|
||||
* @param[in] cb A callback function to receive the execute event.
|
||||
*/
|
||||
|
|
@ -655,7 +655,7 @@ int lwm2m_engine_register_read_callback(char *path,
|
|||
*
|
||||
* This callback is triggered before setting the value of a resource. It
|
||||
* can pass a special data buffer to the engine so that the actual resource
|
||||
* value can be calulated later, etc.
|
||||
* value can be calculated later, etc.
|
||||
*
|
||||
* @param[in] path LwM2M resource path string (obj/obj-instance/resource)
|
||||
* @param[in] cb Pre-write resource callback
|
||||
|
|
|
|||
|
|
@ -94,7 +94,7 @@ following macros to specify those values:
|
|||
#define BLUEMIX_FORMAT "json"
|
||||
|
||||
On your Linux host computer, open a terminal window, locate the source code
|
||||
of this sample application (i.e. :zephyr_file:`samples/net/mqtt_publisher`) and type:
|
||||
of this sample application (i.e., :zephyr_file:`samples/net/mqtt_publisher`) and type:
|
||||
|
||||
.. zephyr-app-commands::
|
||||
:zephyr-app: samples/net/mqtt_publisher
|
||||
|
|
@ -132,7 +132,7 @@ try this sample with TLS enabled, by following these steps:
|
|||
enabled on your platform and :option:`CONFIG_TLS_CREDENTIAL_FILENAMES` is
|
||||
set to ``y``).
|
||||
- In :file:`src/config.h`, set SERVER_ADDR to the IP address to connect to,
|
||||
ie. the IP address of test.mosquitto.org ``"37.187.106.16"``
|
||||
i.e., the IP address of test.mosquitto.org ``"37.187.106.16"``
|
||||
- In :file:`src/main.c`, set TLS_SNI_HOSTNAME to ``"test.mosquitto.org"``
|
||||
to match the Common Name (CN) in the downloaded certificate.
|
||||
- Build the sample by specifying ``-DOVERLAY_CONFIG=overlay-tls.conf``
|
||||
|
|
|
|||
Loading…
Reference in a new issue