doc: fix spelling errors in doc/kernel documents
Change-Id: I879142a6c2da9d8ebd00c37ee57f1bf0f699dc78 Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
This commit is contained in:
parent
979f75053c
commit
23b54005e0
8 changed files with 9 additions and 9 deletions
|
@ -418,7 +418,7 @@ where the maximum size of a message is known in advance.
|
|||
This technique can be used when the message data is actually located
|
||||
in a memory block supplied by the sending thread. The mailbox copies
|
||||
the data into the message buffer specified by the receiving thread, then
|
||||
frees the meessage block back to its memory pool. This allows
|
||||
frees the message block back to its memory pool. This allows
|
||||
a receiving thread to retrieve message data without having to know
|
||||
whether the data was sent using a message buffer or a message block.
|
||||
|
||||
|
|
|
@ -156,7 +156,7 @@ in an asynchronous manner.
|
|||
.. note::
|
||||
A message queue can be used to transfer large data items, if desired.
|
||||
However, this can increase interrupt latency as interrupts are locked
|
||||
while a data item is written or read. It is usally preferable to transfer
|
||||
while a data item is written or read. It is usually preferable to transfer
|
||||
large data items by exchanging a pointer to the data item, rather than the
|
||||
data item itself. The kernel's memory map and memory pool object types
|
||||
can be helpful for data transfers of this sort.
|
||||
|
|
|
@ -4,7 +4,7 @@ Zephyr Kernel Primer (version 2)
|
|||
################################
|
||||
|
||||
This document provides a general introduction of the Zephyr kernel's
|
||||
key capabilties and services. Additional details can be found by consulting
|
||||
key capabilities and services. Additional details can be found by consulting
|
||||
the :ref:`api` and :ref:`application` documentation, and by examining
|
||||
the code in the Zephyr source tree.
|
||||
|
||||
|
|
|
@ -4,7 +4,7 @@ Interrupts
|
|||
##########
|
||||
|
||||
An :dfn:`interrupt service routine` (ISR) is a function that executes
|
||||
asychronously in response to a hardware or software interrupt.
|
||||
asynchronously in response to a hardware or software interrupt.
|
||||
An ISR normally preempts the execution of the current thread,
|
||||
allowing the response to occur with very low overhead.
|
||||
Thread execution resumes only once all ISR work has been completed.
|
||||
|
|
|
@ -267,7 +267,7 @@ it.
|
|||
Because objects are only signaled if no other thread is waiting for them to
|
||||
become available and only one thread can poll on a specific object, polling
|
||||
is best used when objects are not subject of contention between multiple
|
||||
threads, basicallly when a single thread operates as a main "server" or
|
||||
threads, basically when a single thread operates as a main "server" or
|
||||
"dispatcher" for multiple objects and is the only one trying to acquire
|
||||
these objects.
|
||||
|
||||
|
|
|
@ -106,7 +106,7 @@ which can be accessed using efficient masking operations.
|
|||
/* Buffer with 2^8 (or 256) words */
|
||||
SYS_RING_BUF_DECLARE_POW2(my_ring_buf, 8);
|
||||
|
||||
The following code defines a ring buffer with an arbitraty-sized data buffer,
|
||||
The following code defines a ring buffer with an arbitrary-sized data buffer,
|
||||
which can be accessed using less efficient modulo operations.
|
||||
|
||||
.. code-block:: c
|
||||
|
|
|
@ -83,7 +83,7 @@ thread's priority correctly reverts to its original non-elevated priority.
|
|||
The kernel does *not* fully support priority inheritance when a thread holds
|
||||
two or more mutexes simultaneously. This situation can result in the thread's
|
||||
priority not reverting to its original non-elevated priority when all mutexes
|
||||
have been released. It is recommended that a thread lcok only a single mutex
|
||||
have been released. It is recommended that a thread lock only a single mutex
|
||||
at a time when multiple mutexes are shared between threads of different
|
||||
priorities.
|
||||
|
||||
|
@ -126,7 +126,7 @@ for the mutex to become available if it is already locked by another thread.
|
|||
k_mutex_lock(&my_mutex, K_FOREVER);
|
||||
|
||||
The following code waits up to 100 milliseconds for the mutex to become
|
||||
available, and gives a warning if the mutex does not become availablee.
|
||||
available, and gives a warning if the mutex does not become available.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
|
|
|
@ -75,7 +75,7 @@ ranges:
|
|||
* preemptive threads: 0 to (:option:`CONFIG_NUM_PREEMPT_PRIORITIES` - 1)
|
||||
|
||||
For example, configuring 5 cooperative priorities and 10 preemptive priorities
|
||||
results in the ranages -5 to -1 and 0 to 9, respectively.
|
||||
results in the ranges -5 to -1 and 0 to 9, respectively.
|
||||
|
||||
Scheduling Algorithm
|
||||
====================
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue