michaelh/zephyr
1
0
Fork 0
Code Releases Activity

doc: misspelling and UTF-8 fixes

Browse source 
More general spelling fixes, and cleaning up stray UTF-8 characters
such as curly-quotes, em- and en-dashes.  Use replacement strings
for |reg| and |trade|.

Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
This commit is contained in:
David B. Kinder 2017-05-09 15:38:30 -07:00 • committed by Anas Nashif
commit 2f41cb8329
43 changed files with 119 additions and 115 deletions
Download patch file Download diff file Expand all files Collapse all files

10
README.rst
View file

@ -1,7 +1,7 @@
Zephyr™ Project Zephyr Project
############### ##############
The Zephyr™ Project is a scalable real-time operating system (RTOS) supporting The Zephyr Project is a scalable real-time operating system (RTOS) supporting
multiple hardware architectures, optimized for resource constrained devices, multiple hardware architectures, optimized for resource constrained devices,
and built with security in mind. and built with security in mind.
@ -29,11 +29,11 @@ Welcome to the Zephyr community!
Resources Resources
********* *********
Here’s a quick summary of resources to find your way around the Zephyr Project Here's a quick summary of resources to find your way around the Zephyr Project
support systems: support systems:
* **Zephyr Project Website**: The https://zephyrproject.org website is the * **Zephyr Project Website**: The https://zephyrproject.org website is the
central source of information about the Zephyr Project. On this site, you’ll central source of information about the Zephyr Project. On this site, you'll
find background and current information about the project as well as all the find background and current information about the project as well as all the
relevant links to project material. For a quick start, refer to the relevant links to project material. For a quick start, refer to the
`Zephyr Introduction`_ and `Getting Started Guide`_. `Zephyr Introduction`_ and `Getting Started Guide`_.

2
boards/arc/arduino_101_sss/doc/board.rst
View file

@ -6,7 +6,7 @@ Arduino/Genuino 101 (Sensor Subsystem)
The Arduino 101 contains a 32 MHz Argonaut RISC Core (ARC)* EM processor as part The Arduino 101 contains a 32 MHz Argonaut RISC Core (ARC)* EM processor as part
of the Quark SE C1000 SoC within the Curie module. of the Quark SE C1000 SoC within the Curie module.
The ARC core is referenced as the digital signal processor (DSP) sensor hub or a The ARC core is referenced as the digital signal processor (DSP) sensor hub or a
sensor subsystem depending on what document you’re looking at. sensor subsystem depending on what document you're looking at.
For more information about using the sensor subsystem with Zephyr, see For more information about using the sensor subsystem with Zephyr, see
:ref:`arduino_101`. :ref:`arduino_101`.

2
boards/arm/96b_carbon/doc/96b_carbon.rst
View file

@ -23,7 +23,7 @@ Hardware
96Boards Carbon provides the following hardware components: 96Boards Carbon provides the following hardware components:
- STM32F401RET6 in LQFP64 package - STM32F401RET6 in LQFP64 package
- ARM®32-bit Cortex®-M4 CPU with FPU - ARM |reg| 32-bit Cortex |reg|-M4 CPU with FPU
- 84 MHz max CPU frequency - 84 MHz max CPU frequency
- VDD from 1.7 V to 3.6 V - VDD from 1.7 V to 3.6 V
- 512 KB Flash - 512 KB Flash

2
boards/arm/96b_nitrogen/doc/96b_nitrogen.rst
View file

@ -27,7 +27,7 @@ Hardware
96Boards Nitrogen provides the following hardware components: 96Boards Nitrogen provides the following hardware components:
- nRF52832 microcontroller with 512kB Flash, 64kB RAM - nRF52832 microcontroller with 512kB Flash, 64kB RAM
- ARM®32-bit Cortex®-M4 CPU with FPU - ARM |reg| 32-bit Cortex |reg|-M4 CPU with FPU
- Bluetooth LE - Bluetooth LE
- NFC - NFC
- LPC11U35 on board SWD debugger - LPC11U35 on board SWD debugger

4
boards/arm/cc3200_launchxl/doc/cc3200_launchxl.rst
View file

@ -6,7 +6,7 @@ CC3200 LaunchXL
Overview Overview
******** ********
The SimpleLink CC3200 LaunchXL is a development board for the CC3200 The SimpleLink CC3200 LaunchXL is a development board for the CC3200
wireless microcontroller (MCU), the industry’s first single-chip wireless microcontroller (MCU), the industry's first single-chip
programmable MCU with built-in Wi-Fi connectivity. programmable MCU with built-in Wi-Fi connectivity.
Features: Features:
@ -29,7 +29,7 @@ Hardware
The CC3200 SoC has two MCUs: The CC3200 SoC has two MCUs:
#. Applications MCU - an ARM® Cortex®-M4 Core at 80 MHz, with 256Kb RAM, #. Applications MCU - an ARM |reg| Cortex |reg|-M4 Core at 80 MHz, with 256Kb RAM,
and access to external serial 1Mb flash with bootloader and peripheral and access to external serial 1Mb flash with bootloader and peripheral
drivers in ROM. drivers in ROM.

2
boards/arm/cc3220sf_launchxl/doc/cc3220sf_launchxl.rst
View file

@ -34,7 +34,7 @@ Hardware
The CC3220SF SoC has two MCUs: The CC3220SF SoC has two MCUs:
#. Applications MCU - an ARM® Cortex®-M4 Core at 80 MHz, with 256Kb RAM, #. Applications MCU - an ARM |reg| Cortex |reg|-M4 Core at 80 MHz, with 256Kb RAM,
and access to external serial 1Mb flash with bootloader and peripheral and access to external serial 1Mb flash with bootloader and peripheral
drivers in ROM. drivers in ROM.

2
boards/arm/curie_ble/doc/board.rst
View file

@ -3,7 +3,7 @@
Curie (BLE) Curie (BLE)
########### ###########
The Intel® Curie* module includes Bluetooth LE to enable developers to interact with The Intel |reg| Curie* module includes Bluetooth LE to enable developers to interact with
Bluetooth enabled devices such as phones and tablets. Bluetooth enabled devices such as phones and tablets.
See :ref:`arduino_101` for information how to use the BLE module with Zephyr on the Arduino See :ref:`arduino_101` for information how to use the BLE module with Zephyr on the Arduino

19
boards/arm/disco_l475_iot1/doc/disco_l475_iot1.rst
View file

@ -9,15 +9,15 @@ Overview
The B-L475E-IOT01A Discovery kit for IoT node allows users to develop The B-L475E-IOT01A Discovery kit for IoT node allows users to develop
applications with direct connection to cloud servers. applications with direct connection to cloud servers.
The Discovery kit enables a wide diversity of applications by exploiting The Discovery kit enables a wide diversity of applications by exploiting
low-power communication, multiway sensing and ARM® Cortex® -M4 core-based low-power communication, multiway sensing and ARM |reg| Cortex |reg|-M4 core-based
STM32L4 Series features. STM32L4 Series features.
This kit provides: This kit provides:
- 64-Mbit Quad-SPI (Macronix) Flash memory - 64-Mbit Quad-SPI (Macronix) Flash memory
- Bluetooth® V4.1 module (SPBTLE-RF) - Bluetooth |reg| V4.1 module (SPBTLE-RF)
- Sub-GHz (868 or 915 MHz) low-power-programmable RF module (SPSGRF-868 or SPSGRF-915) - Sub-GHz (868 or 915 MHz) low-power-programmable RF module (SPSGRF-868 or SPSGRF-915)
- Wi-Fi® module Inventek ISM43362-M3G-L44 (802.11 b/g/n compliant) - Wi-Fi |reg| module Inventek ISM43362-M3G-L44 (802.11 b/g/n compliant)
- Dynamic NFC tag based on M24SR with its printed NFC antenna - Dynamic NFC tag based on M24SR with its printed NFC antenna
- 2 digital omni-directional microphones (MP34DT01) - 2 digital omni-directional microphones (MP34DT01)
- Capacitive digital sensor for relative humidity and temperature (HTS221) - Capacitive digital sensor for relative humidity and temperature (HTS221)
@ -28,7 +28,7 @@ This kit provides:
- 2 push-buttons (user and reset) - 2 push-buttons (user and reset)
- USB OTG FS with Micro-AB connector - USB OTG FS with Micro-AB connector
- Expansion connectors: - Expansion connectors:
- Arduino™ Uno V3 - Arduino |trade| Uno V3
- PMOD - PMOD
- Flexible power-supply options: - Flexible power-supply options:
- ST LINK USB VBUS or external sources - ST LINK USB VBUS or external sources
@ -49,14 +49,15 @@ Hardware
The STM32L475RG SoC provides the following hardware IPs: The STM32L475RG SoC provides the following hardware IPs:
- Ultra-low-power with FlexPowerControl (down to 130 nA Standby mode and 100 μA/MHz run mode) - Ultra-low-power with FlexPowerControl (down to 130 nA Standby mode and 100 uA/MHz run mode)
- Core: ARM® 32-bit Cortex®-M4 CPU with FPU, frequency up to 80 MHz, 100DMIPS/1.25DMIPS/MHz (Dhrystone 2.1) - Core: ARM |reg| 32-bit Cortex |reg|-M4 CPU with FPU, frequency up to 80 MHz, 100DMIPS/1.25DMIPS/MHz (Dhrystone 2.1)
- Clock Sources: - Clock Sources:
- 4 to 48 MHz crystal oscillator - 4 to 48 MHz crystal oscillator
- 32 kHz crystal oscillator for RTC (LSE) - 32 kHz crystal oscillator for RTC (LSE)
- Internal 16 MHz factory-trimmed RC (±1%) - Internal 16 MHz factory-trimmed RC (±1%)
- Internal low-power 32 kHz RC (±5%) - Internal low-power 32 kHz RC (±5%)
- Internal multispeed 100 kHz to 48 MHz oscillator, auto-trimmed by LSE (better than ±0.25 % accuracy) - Internal multispeed 100 kHz to 48 MHz oscillator, auto-trimmed by
LSE (better than ±0.25 % accuracy)
- 3 PLLs for system clock, USB, audio, ADC - 3 PLLs for system clock, USB, audio, ADC
- RTC with HW calendar, alarms and calibration - RTC with HW calendar, alarms and calibration
- Up to 24 capacitive sensing channels: support touchkey, linear and rotary touch sensors - Up to 24 capacitive sensing channels: support touchkey, linear and rotary touch sensors
@ -75,7 +76,7 @@ The STM32L475RG SoC provides the following hardware IPs:
- Quad SPI memory interface - Quad SPI memory interface
- 4x digital filters for sigma delta modulator - 4x digital filters for sigma delta modulator
- Rich analog peripherals (independent supply) - Rich analog peripherals (independent supply)
- 3x 12-bit ADC 5 MSPS, up to 16-bit with hardware oversampling, 200 μA/MSPS - 3x 12-bit ADC 5 MSPS, up to 16-bit with hardware oversampling, 200 uA/MSPS
- 2x 12-bit DAC, low-power sample and hold - 2x 12-bit DAC, low-power sample and hold
- 2x operational amplifiers with built-in PGA - 2x operational amplifiers with built-in PGA
- 2x ultra-low-power comparators - 2x ultra-low-power comparators
@ -90,7 +91,7 @@ The STM32L475RG SoC provides the following hardware IPs:
- 14-channel DMA controller - 14-channel DMA controller
- True random number generator - True random number generator
- CRC calculation unit, 96-bit unique ID - CRC calculation unit, 96-bit unique ID
- Development support: serial wire debug (SWD), JTAG, Embedded Trace Macrocell™ - Development support: serial wire debug (SWD), JTAG, Embedded Trace Macrocell |trade|
More information about STM32L476RG can be found here: More information about STM32L476RG can be found here:

2
boards/arm/frdm_k64f/doc/frdm_k64f.rst
View file

@ -33,7 +33,7 @@ Hardware
- RGB LED - RGB LED
- FXOS8700CQ accelerometer and magnetometer - FXOS8700CQ accelerometer and magnetometer
- Two user push buttons - Two user push buttons
- Flexible power supply option – OpenSDAv2 USB, Kinetis K64 USB, and external source - Flexible power supply option - OpenSDAv2 USB, Kinetis K64 USB, and external source
- Easy access to MCU input/output through Arduino* R3 compatible I/O connectors - Easy access to MCU input/output through Arduino* R3 compatible I/O connectors
- Programmable OpenSDAv2 debug circuit supporting the CMSIS-DAP Interface - Programmable OpenSDAv2 debug circuit supporting the CMSIS-DAP Interface
software that provides: software that provides:

11
boards/arm/frdm_kw41z/doc/frdm_kw41z.rst
View file

@ -6,14 +6,15 @@ NXP FRDM-KW41Z
Overview Overview
******** ********
The FRDM-KW41Z is a development kit enabled by the Kinetis® W series The FRDM-KW41Z is a development kit enabled by the Kinetis |reg| W series
KW41Z/31Z/21Z (KW41Z) family built on ARM® Cortex®-M0+ processor with KW41Z/31Z/21Z (KW41Z) family built on ARM |reg| Cortex |reg|-M0+ processor with
integrated 2.4 GHz transceiver supporting Bluetooth® Smart/Bluetooth®Low Energy integrated 2.4 GHz transceiver supporting Bluetooth |reg| Smart/Bluetooth
(BLE) v4.2, Generic FSK, IEEE® 802.15.4 and Thread. |reg| Low Energy
(BLE) v4.2, Generic FSK, IEEE |reg| 802.15.4 and Thread.
The FRDM-KW41Z kit contains two Freedom boards that can be used as a The FRDM-KW41Z kit contains two Freedom boards that can be used as a
development board or a shield to connect to a host processor. The FRDM-KW41Z is development board or a shield to connect to a host processor. The FRDM-KW41Z is
form-factor compatible with the Arduino™ R3 pin layout for more expansion form-factor compatible with the Arduino |trade| R3 pin layout for more expansion
options. options.
The FRDM-KW41Z highly-sensitive, optimized 2.4 GHz radio features a PCB The FRDM-KW41Z highly-sensitive, optimized 2.4 GHz radio features a PCB

6
boards/arm/hexiwear_k64/doc/hexiwear_k64.rst
View file

@ -9,7 +9,7 @@ Overview
Hexiwear is powered by a Kinetis K64 microcontroller based on the ARM Cortex-M4 Hexiwear is powered by a Kinetis K64 microcontroller based on the ARM Cortex-M4
core. Another Kinetis wireless MCU, the KW40Z, provides Bluetooth Low Energy core. Another Kinetis wireless MCU, the KW40Z, provides Bluetooth Low Energy
connectivity. Hexiwear also integrates a wide variety of sensors, as well as a connectivity. Hexiwear also integrates a wide variety of sensors, as well as a
user interface consisting of a 1.1” 96px x 96px full color OLED display and six user interface consisting of a 1.1" 96px x 96px full color OLED display and six
capacitive buttons with haptic feedback. capacitive buttons with haptic feedback.
- Eye-catching Smart Watch form factor with powerful, low power Kinetis K6x MCU - Eye-catching Smart Watch form factor with powerful, low power Kinetis K6x MCU
@ -17,7 +17,7 @@ capacitive buttons with haptic feedback.
- Designed for wearable applications with the onboard rechargeable battery, - Designed for wearable applications with the onboard rechargeable battery,
OLED screen and onboard sensors such as optical heart rate, accelerometer, OLED screen and onboard sensors such as optical heart rate, accelerometer,
magnetometer and gyroscope. magnetometer and gyroscope.
- Designed for IoT end node applications with the onboard sensor’s such as - Designed for IoT end node applications with the onboard sensor's such as
temperature, pressure, humidity and ambient light. temperature, pressure, humidity and ambient light.
- Flexibility to let you add the sensors of your choice nearly 200 additional - Flexibility to let you add the sensors of your choice nearly 200 additional
sensors through click boards. sensors through click boards.
@ -39,7 +39,7 @@ Hardware
- Li-Ion/Li-Po Battery Charger NXP MC34671 - Li-Ion/Li-Po Battery Charger NXP MC34671
- Optical heart rate sensor Maxim MAX30101 - Optical heart rate sensor Maxim MAX30101
- Ambient Light sensor, Humidity and Temperature sensor - Ambient Light sensor, Humidity and Temperature sensor
- 1.1” full color OLED display - 1.1" full color OLED display
- Haptic feedback engine - Haptic feedback engine
- 190 mAh 2C Li-Po battery - 190 mAh 2C Li-Po battery
- Capacitive touch interface - Capacitive touch interface

2
boards/arm/nucleo_f401re/doc/nucleof401re.rst
View file

@ -36,7 +36,7 @@ Hardware
Nucleo F401RE provides the following hardware components: Nucleo F401RE provides the following hardware components:
- STM32F401RET6 in LQFP64 package - STM32F401RET6 in LQFP64 package
- ARM®32-bit Cortex®-M4 CPU with FPU - ARM |reg| 32-bit Cortex |reg|-M4 CPU with FPU
- 84 MHz max CPU frequency - 84 MHz max CPU frequency
- VDD from 1.7 V to 3.6 V - VDD from 1.7 V to 3.6 V
- 512 KB Flash - 512 KB Flash

2
boards/arm/nucleo_f411re/doc/nucleof411re.rst
View file

@ -36,7 +36,7 @@ Hardware
Nucleo F411RE provides the following hardware components: Nucleo F411RE provides the following hardware components:
- STM32F411RET6 in LQFP64 package - STM32F411RET6 in LQFP64 package
- ARM®32-bit Cortex®-M4 CPU with FPU - ARM |reg| 32-bit Cortex |reg|-M4 CPU with FPU
- 100 MHz max CPU frequency - 100 MHz max CPU frequency
- VDD from 1.7 V to 3.6 V - VDD from 1.7 V to 3.6 V
- 512 KB Flash - 512 KB Flash

13
boards/arm/nucleo_l476rg/doc/nucleol476rg.rst
View file

@ -35,17 +35,18 @@ Hardware
The STM32L476RG SoC provides the following hardware IPs: The STM32L476RG SoC provides the following hardware IPs:
- Ultra-low-power with FlexPowerControl (down to 130 nA Standby mode and 100 μA/MHz run mode) - Ultra-low-power with FlexPowerControl (down to 130 nA Standby mode and 100 uA/MHz run mode)
- Core: ARM® 32-bit Cortex®-M4 CPU with FPU, frequency up to 80 MHz, 100DMIPS/1.25DMIPS/MHz (Dhrystone 2.1) - Core: ARM |reg| 32-bit Cortex |reg|-M4 CPU with FPU, frequency up to 80 MHz, 100DMIPS/1.25DMIPS/MHz (Dhrystone 2.1)
- Clock Sources: - Clock Sources:
- 4 to 48 MHz crystal oscillator - 4 to 48 MHz crystal oscillator
- 32 kHz crystal oscillator for RTC (LSE) - 32 kHz crystal oscillator for RTC (LSE)
- Internal 16 MHz factory-trimmed RC (±1%) - Internal 16 MHz factory-trimmed RC (±1%)
- Internal low-power 32 kHz RC (±5%) - Internal low-power 32 kHz RC (±5%)
- Internal multispeed 100 kHz to 48 MHz oscillator, auto-trimmed by LSE (better than ±0.25 % accuracy) - Internal multispeed 100 kHz to 48 MHz oscillator, auto-trimmed by
LSE (better than ±0.25 % accuracy)
- 3 PLLs for system clock, USB, audio, ADC - 3 PLLs for system clock, USB, audio, ADC
- RTC with HW calendar, alarms and calibration - RTC with HW calendar, alarms and calibration
- LCD 8 × 40 or 4 × 44 with step-up converter - LCD 8 x 40 or 4 x 44 with step-up converter
- Up to 24 capacitive sensing channels: support touchkey, linear and rotary touch sensors - Up to 24 capacitive sensing channels: support touchkey, linear and rotary touch sensors
- 16x timers: - 16x timers:
- 2x 16-bit advanced motor-control - 2x 16-bit advanced motor-control
@ -62,7 +63,7 @@ The STM32L476RG SoC provides the following hardware IPs:
- Quad SPI memory interface - Quad SPI memory interface
- 4x digital filters for sigma delta modulator - 4x digital filters for sigma delta modulator
- Rich analog peripherals (independent supply) - Rich analog peripherals (independent supply)
- 3× 12-bit ADC 5 MSPS, up to 16-bit with hardware oversampling, 200 μA/MSPS - 3x 12-bit ADC 5 MSPS, up to 16-bit with hardware oversampling, 200 uA/MSPS
- 2x 12-bit DAC, low-power sample and hold - 2x 12-bit DAC, low-power sample and hold
- 2x operational amplifiers with built-in PGA - 2x operational amplifiers with built-in PGA
- 2x ultra-low-power comparators - 2x ultra-low-power comparators
@ -77,7 +78,7 @@ The STM32L476RG SoC provides the following hardware IPs:
- 14-channel DMA controller - 14-channel DMA controller
- True random number generator - True random number generator
- CRC calculation unit, 96-bit unique ID - CRC calculation unit, 96-bit unique ID
- Development support: serial wire debug (SWD), JTAG, Embedded Trace Macrocell™ - Development support: serial wire debug (SWD), JTAG, Embedded Trace Macrocell |trade|
More information about STM32L476RG can be found here: More information about STM32L476RG can be found here:

6
boards/nios2/altera_max10/doc/board.rst
View file

@ -13,9 +13,9 @@ the Nios II Gen 2 soft CPU.
.. figure:: img/max_10_dev_kit_top_photo.jpg .. figure:: img/max_10_dev_kit_top_photo.jpg
:width: 442px :width: 442px
:align: center :align: center
:alt: Altera’s MAX* 10 :alt: Altera's MAX* 10
Altera’s MAX* 10 (Credit: Altera) Altera's MAX* 10 (Credit: Altera)
Hardware Hardware
******** ********
@ -35,7 +35,7 @@ importance is SW2:
.. image:: img/Altera_MAX10_switches.jpg .. image:: img/Altera_MAX10_switches.jpg
:width: 442px :width: 442px
:align: center :align: center
:alt: Altera’s MAX* 10 Switches :alt: Altera's MAX* 10 Switches
Other switches are user switches, their position is application-specific. Other switches are user switches, their position is application-specific.

4
boards/x86/arduino_101/doc/board.rst
View file

@ -7,7 +7,7 @@ Overview
******** ********
The Arduino/Genuino 101 is a learning and development board which contains an The Arduino/Genuino 101 is a learning and development board which contains an
Intel® Curie™ Module. This board is designed to integrate the core's low Intel |reg| Curie |trade| Module. This board is designed to integrate the core's low
power-consumption and high performance with the Arduino's ease-of-use. The power-consumption and high performance with the Arduino's ease-of-use. The
Arduino 101 adds Bluetooth Low Energy capabilities and has an on-board 6-axis Arduino 101 adds Bluetooth Low Energy capabilities and has an on-board 6-axis
accelerometer/gyroscope, providing exciting opportunities for building creative accelerometer/gyroscope, providing exciting opportunities for building creative
@ -24,7 +24,7 @@ The Intel Quark* SE SoC in the Curie module contains a single core 32 MHz x86
(Intel Quark* processor) and the 32 MHz Argonaut RISC Core (ARC)* EM processor. (Intel Quark* processor) and the 32 MHz Argonaut RISC Core (ARC)* EM processor.
The two processors operate simultaneously and share memory. The ARC processor is The two processors operate simultaneously and share memory. The ARC processor is
also referenced as the digital signal processor (DSP) sensor hub or a sensor also referenced as the digital signal processor (DSP) sensor hub or a sensor
subsystem depending on what document you’re looking at. In theory, the DSP can subsystem depending on what document you're looking at. In theory, the DSP can
run using a minimal amount of power, gathering and processing sensor data while run using a minimal amount of power, gathering and processing sensor data while
the x86 processor waits in a low power mode, which would be ideal for always-on the x86 processor waits in a low power mode, which would be ideal for always-on
applications. applications.

10
boards/x86/quark_d2000_crb/doc/quark_d2000_crb.rst
View file

@ -6,7 +6,7 @@ Quark D2000 Development Board
Overview Overview
******** ********
The Intel® Quark ™ microcontroller D2000 package is shipped as a 40-pin QFN The Intel |reg| Quark |trade| microcontroller D2000 package is shipped as a 40-pin QFN
component. component.
.. image:: quark-d2000-developers-kit.png .. image:: quark-d2000-developers-kit.png
@ -14,7 +14,7 @@ component.
:align: center :align: center
:alt: Quark D2000 Development Board :alt: Quark D2000 Development Board
Intel™ Quark® microcontroller D2000 contains the following items: Intel |reg| Quark |trade| microcontroller D2000 contains the following items:
- On-board components: - On-board components:
@ -23,11 +23,11 @@ Intel™ Quark® microcontroller D2000 contains the following items:
- Expansion options: - Expansion options:
- “Arduino Uno” compatible SIL sockets ( 3.3V IO Only ) - "Arduino Uno" compatible SIL sockets ( 3.3V IO Only )
- Other connectors: - Other connectors:
- 1x USB 2.0 Device Port – micro Type B - 1x USB 2.0 Device Port - micro Type B
- On-board coin cell battery holder - On-board coin cell battery holder
- 5V input a screw terminal/header (external power or Li-ion) - 5V input a screw terminal/header (external power or Li-ion)
- EEMBC power input header - EEMBC power input header
@ -38,7 +38,7 @@ Hardware
General information for the board can be found at the `Intel Website`_, General information for the board can be found at the `Intel Website`_,
which includes both `schematics`_ and BRD files. which includes both `schematics`_ and BRD files.
The Intel® Quark™ Microcontroller D2000 Development Platform supports the The Intel |reg| Quark |trade| Microcontroller D2000 Development Platform supports the
familiar open standard Arduino Uno Rev 3.0 physical interface and is familiar open standard Arduino Uno Rev 3.0 physical interface and is
mechanically compatible with Uno Rev 3.0. It does not support the 6 pin ICSP mechanically compatible with Uno Rev 3.0. It does not support the 6 pin ICSP
Header. Header.

4
boards/x86/tinytile/doc/board.rst
View file

@ -20,8 +20,8 @@ See :ref:`arduino_101` for information how to use the tinyTILE board with Zephyr
Features of the tinyTILE include: Features of the tinyTILE include:
- Intel® Curie™ module dual-core (Intel® Quark* processor core and ARC* core) - Intel |reg| Curie |trade| module dual-core (Intel |reg| Quark* processor core and ARC* core)
- Bluetooth® low energy, 6-axis combo sensor and pattern matching engine - Bluetooth |reg| low energy, 6-axis combo sensor and pattern matching engine
- 14 digital input/output pins (four can be used as PWM output pins) - 14 digital input/output pins (four can be used as PWM output pins)
- Four PWM output pins - Four PWM output pins
- Six analog input pins - Six analog input pins

4
boards/xtensa/xt-sim/doc/xt-sim.rst
View file

@ -48,8 +48,8 @@ The frequency of the clock under simulation is set to 25MHz.
System requirements System requirements
******************* *******************
Pre-requisites Prerequisites
============== =============
A Linux host system is required for Xtensa development work. A Linux host system is required for Xtensa development work.
We recommend using a __``Debian 9.x (Stretch)``__ or recent __``Ubuntu``__ We recommend using a __``Debian 9.x (Stretch)``__ or recent __``Ubuntu``__
releases (with multilib support). releases (with multilib support).

2
doc/api/kernel_api.rst
View file

@ -117,7 +117,7 @@ with basic priority inheritance.
Alerts Alerts
****** ******
Alerts enable an application to perform asynchronous signalling, Alerts enable an application to perform asynchronous signaling,
somewhat akin to Unix-style signals. somewhat akin to Unix-style signals.
(See :ref:`alerts_v2`.) (See :ref:`alerts_v2`.)

3
doc/application/application.rst
View file

@ -306,7 +306,8 @@ An application's :file:`.conf` file defines its default kernel configuration.
The settings in this file override or augment the board configuration settings. The settings in this file override or augment the board configuration settings.
The board configuration settings can be viewed The board configuration settings can be viewed
in :file:`$ZEPHYR_BASE/boards/ARCHITECTURE/BOARD/BOARD_defconfig`. LENGTHlWRONGEPHY
_BASE/boards/ARCHITECTURE/BOARD/BOARD_defconfig`.
.. note:: .. note::

10
doc/contribute/security.rst
View file

@ -78,8 +78,8 @@ help prevent security violations and limit their impact:
and permitted only in specific conditions defined by the system and permitted only in specific conditions defined by the system
protection scheme, e.g., after successful authentication. protection scheme, e.g., after successful authentication.
Furthermore, default settings for services shall be chosen in a way Furthermore, default settings for services shall be chosen in a way
to provide maximum security. This corresponds to the “Secure by to provide maximum security. This corresponds to the "Secure by
Default” paradigm [MICRO12]_. Default" paradigm [MICRO12]_.
- **Separation of privilege** is the principle that two conditions or - **Separation of privilege** is the principle that two conditions or
more need to be satisfied before access is granted. In the context more need to be satisfied before access is granted. In the context
@ -220,7 +220,7 @@ scripting, missing authentication, and missing authorization. See the
Security Subcommittee Security Subcommittee
===================== =====================
There shall be a “security subcommittee”, responsible for There shall be a "security subcommittee", responsible for
enforcing this guideline, monitoring reviews, and improving these enforcing this guideline, monitoring reviews, and improving these
guidelines. guidelines.
@ -280,12 +280,12 @@ and approved by consensus.
.. _attack: http://www.theverge.com/2016/10/21/13362354/dyn-dns-ddos-attack-cause-outage-status-explained .. _attack: http://www.theverge.com/2016/10/21/13362354/dyn-dns-ddos-attack-cause-outage-status-explained
.. [MICRO12] Microsoft Corporation, Security Development Lifecycle – SDL .. [MICRO12] Microsoft Corporation, Security Development Lifecycle - SDL
Process Guidance Version 5.2, 2012. Process Guidance Version 5.2, 2012.
.. [PAUL09] M. Paul, "The Ten Best Practices for Secure Software .. [PAUL09] M. Paul, "The Ten Best Practices for Secure Software
Development," International Information Systems Security Certification Development," International Information Systems Security Certification
Consortium, Inc. [(ISC)2®], Palm Harbor, FL, USA, 2009. Consortium, Inc. [(ISC)2], Palm Harbor, FL, USA, 2009.
.. [SALT75] J. H. Saltzer and M. D. Schroeder, "The protection of .. [SALT75] J. H. Saltzer and M. D. Schroeder, "The protection of
information in computer systems," Proceedings of the IEEE, information in computer systems," Proceedings of the IEEE,

2
doc/getting_started/getting_started.rst
View file

@ -179,7 +179,7 @@ Running a Sample Application in QEMU
==================================== ====================================
To perform rapid testing of an application in the development environment you To perform rapid testing of an application in the development environment you
can use the qemu emulation board configuration available for both X86 and ARM can use the QEMU emulation board configuration available for both X86 and ARM
Cortex-M3 architectures. This can be easily accomplished by calling a special Cortex-M3 architectures. This can be easily accomplished by calling a special
target when building an application that invokes QEMU once the build process is target when building an application that invokes QEMU once the build process is
completed. completed.

6
doc/getting_started/installation_win.rst
View file

@ -70,7 +70,7 @@ up:
.. note:: .. note::
The ISSM toolset only supports development for Intel® Quark™ The ISSM toolset only supports development for Intel |reg| Quark |trade|
Microcontrollers, for example, the Arduino 101 board. (Check out the Microcontrollers, for example, the Arduino 101 board. (Check out the
"Zephyr Development Environment "Zephyr Development Environment
Setup" in this `Getting Started on Arduino 101 with ISSM`_ document.) Setup" in this `Getting Started on Arduino 101 with ISSM`_ document.)
@ -118,7 +118,7 @@ up:
#. Finally, you can try building the :ref:`hello_world` sample to check things #. Finally, you can try building the :ref:`hello_world` sample to check things
out. out.
To build for the Intel® Quark™ (x86-based) Arduino 101: To build for the Intel |reg| Quark |trade| (x86-based) Arduino 101:
.. code-block:: console .. code-block:: console
@ -198,7 +198,7 @@ Windows, you will need to build or install a toolchain:
.. note:: .. note::
The ISSM toolset only supports development for Intel® Quark™ The ISSM toolset only supports development for Intel |reg| Quark |trade|
Microcontrollers, for example, the Arduino 101 board. (Check out the Microcontrollers, for example, the Arduino 101 board. (Check out the
"Zephyr Development Environment "Zephyr Development Environment
Setup" in this `Getting Started on Arduino 101 with ISSM`_ document.) Setup" in this `Getting Started on Arduino 101 with ISSM`_ document.)

2
doc/kernel/data_passing/mailboxes.rst
View file

@ -371,7 +371,7 @@ can examine the message descriptor to determine which thread sent the message,
how much data was exchanged, how much data was exchanged,
and the application-defined info value supplied by the sending thread. and the application-defined info value supplied by the sending thread.
Any number of receiving threads may wait simultaneously on a mailboxes's Any number of receiving threads may wait simultaneously on a mailboxes'
receive queue. The threads are sorted according to their priority; receive queue. The threads are sorted according to their priority;
threads of equal priority are sorted so that the one that started waiting threads of equal priority are sorted so that the one that started waiting
first can receive a message first. first can receive a message first.

2
doc/kernel/memory/heap.rst
View file

@ -3,7 +3,7 @@
Heap Memory Pool Heap Memory Pool
################ ################
The :dfn:`heap memory pool` is a pre-defined memory pool object that allows The :dfn:`heap memory pool` is a predefined memory pool object that allows
threads to dynamically allocate memory from a common memory region threads to dynamically allocate memory from a common memory region
in a :cpp:func:`malloc()`-like manner. in a :cpp:func:`malloc()`-like manner.

2
doc/kernel/other/interrupts.rst
View file

@ -86,7 +86,7 @@ is running.
interrupted until it has explicitly unlocked its IRQ lock. interrupted until it has explicitly unlocked its IRQ lock.
Alternatively, a thread may temporarily **disable** a specified IRQ Alternatively, a thread may temporarily **disable** a specified IRQ
so its associated ISR does not execute when the IRQ is signalled. so its associated ISR does not execute when the IRQ is signaled.
The IRQ must be subsequently **enabled** to permit the ISR to execute. The IRQ must be subsequently **enabled** to permit the ISR to execute.
.. important:: .. important::

6
doc/kernel/overview/changes.rst
View file

@ -103,7 +103,7 @@ in system clock ticks. This change makes things more intuitive for most
developers. However, the kernel still implements timeouts using the developers. However, the kernel still implements timeouts using the
tick-based system clock. tick-based system clock.
The previous nanokernel timer and microkernel timer object types have beeni The previous nanokernel timer and microkernel timer object types have been
merged into a single type. merged into a single type.
Memory Allocation Memory Allocation
@ -123,7 +123,7 @@ from a heap data pool.
Synchronization Synchronization
*************** ***************
The prevous nanokernel semaphore and microkernel semaphore object types have been The previous nanokernel semaphore and microkernel semaphore object types have been
merged into a single type. The new type can now be used as a binary semaphore, merged into a single type. The new type can now be used as a binary semaphore,
as well as a counting semaphore. as well as a counting semaphore.
@ -135,7 +135,7 @@ non-blocking manner or use an additional mechanism, such as an event object,
to signal the application that one of the semaphores is available. to signal the application that one of the semaphores is available.
The previous microkernel event object type is renamed to "alert" and is now presented as The previous microkernel event object type is renamed to "alert" and is now presented as
a relative to Unix-style signalling. Due to improvements to the implementation a relative to Unix-style signaling. Due to improvements to the implementation
of semaphores, alerts are now less efficient to use for basic synchronization of semaphores, alerts are now less efficient to use for basic synchronization
than semaphores; consequently, alerts should now be reserved for scenarios than semaphores; consequently, alerts should now be reserved for scenarios
requiring the use of a callback function. requiring the use of a callback function.

2
doc/kernel/overview/overview.rst
View file

@ -14,7 +14,7 @@ features needed by your application, making it ideal for systems with limited
amounts of memory (as little as 2 KB!) or with simple multi-threading amounts of memory (as little as 2 KB!) or with simple multi-threading
requirements (such as a set of interrupt handlers and a single background task). requirements (such as a set of interrupt handlers and a single background task).
Examples of such systems include: embedded sensor hubs, environmental sensors, Examples of such systems include: embedded sensor hubs, environmental sensors,
simple LED wearables, and store inventory tags. simple LED wearable, and store inventory tags.
Applications requiring more memory (50 to 900 KB), multiple communication Applications requiring more memory (50 to 900 KB), multiple communication
devices (like WiFi and Bluetooth Low Energy), and complex multi-threading, devices (like WiFi and Bluetooth Low Energy), and complex multi-threading,

18
doc/kernel/synchronization/alerts.rst
View file

@ -4,7 +4,7 @@ Alerts
###### ######
An :dfn:`alert` is a kernel object that allows an application to perform An :dfn:`alert` is a kernel object that allows an application to perform
asynchronous signalling when a condition of interest occurs. asynchronous signaling when a condition of interest occurs.
.. contents:: .. contents::
:local: :local:
@ -19,7 +19,7 @@ its memory address.
An alert has the following key properties: An alert has the following key properties:
* An **alert handler**, which specifies the action to be taken * An **alert handler**, which specifies the action to be taken
when the alert is signalled. The action may instruct the system workqueue when the alert is signaled. The action may instruct the system workqueue
to execute a function to process the alert, mark the alert as pending to execute a function to process the alert, mark the alert as pending
so it can be processed later by a thread, or ignore the alert. so it can be processed later by a thread, or ignore the alert.
@ -78,7 +78,7 @@ significant differences. The most notable of these are:
* A Zephyr alert pends *after* it has been delivered to its alert handler, * A Zephyr alert pends *after* it has been delivered to its alert handler,
and only if an alert handler function does not consume the alert. and only if an alert handler function does not consume the alert.
* Zephyr has no pre-defined alerts or actions. All alerts are application * Zephyr has no predefined alerts or actions. All alerts are application
defined, and all have a default action that pends the alert. defined, and all have a default action that pends the alert.
Implementation Implementation
@ -116,7 +116,7 @@ The following code has the same effect as the code segment above.
Signaling an Alert Signaling an Alert
================== ==================
An alert is signalled by calling :cpp:func:`k_alert_send()`. An alert is signaled by calling :cpp:func:`k_alert_send()`.
The following code illustrates how an ISR can signal an alert The following code illustrates how an ISR can signal an alert
to indicate that a key press has occurred. to indicate that a key press has occurred.
@ -137,7 +137,7 @@ to indicate that a key press has occurred.
Handling an Alert Handling an Alert
================= =================
An alert handler function is used when a signalled alert should not be ignored An alert handler function is used when a signaled alert should not be ignored
or immediately pended. It has the following form: or immediately pended. It has the following form:
.. code-block:: c .. code-block:: c
@ -162,7 +162,7 @@ key presses detected by an ISR (as shown in the previous section).
/* do complex processing of the keystroke */ /* do complex processing of the keystroke */
... ...
/* signalled alert has been consumed */ /* signaled alert has been consumed */
return 0; return 0;
} }
@ -189,10 +189,10 @@ only when a numeric key is pressed.
if ((c >= '0') && (c <= '9')) { if ((c >= '0') && (c <= '9')) {
/* save key press information */ /* save key press information */
... ...
/* signalled alert should be pended */ /* signaled alert should be pended */
return 1; return 1;
} else { } else {
/* signalled alert has been consumed */ /* signaled alert has been consumed */
return 0; return 0;
} }
} }
@ -219,7 +219,7 @@ work to a thread to reduce the amount of time interrupts are locked.
Use an alert to allow the kernel's system workqueue to handle an alert, Use an alert to allow the kernel's system workqueue to handle an alert,
rather than defining an application thread to handle it. rather than defining an application thread to handle it.
Use an alert to allow the kernel's system workqueue to pre-process an alert, Use an alert to allow the kernel's system workqueue to preprocess an alert,
prior to letting an application thread handle it. prior to letting an application thread handle it.
Configuration Options Configuration Options

2
doc/kernel/synchronization/mutexes.rst
View file

@ -36,7 +36,7 @@ by another thread, the requesting thread may choose to wait for the mutex
to be unlocked. to be unlocked.
After locking a mutex, the thread may safely use the associated resource After locking a mutex, the thread may safely use the associated resource
for as long as needed; however, it is considered good practise to hold the lock for as long as needed; however, it is considered good practice to hold the lock
for as short a time as possible to avoid negatively impacting other threads for as short a time as possible to avoid negatively impacting other threads
that want to use the resource. When the thread no longer needs the resource that want to use the resource. When the thread no longer needs the resource
it must **unlock** the mutex to allow other threads to use the resource. it must **unlock** the mutex to allow other threads to use the resource.

4
doc/kernel/threads/lifecycle.rst
View file

@ -52,9 +52,9 @@ instructed to delay execution of the thread by specifying a timeout
value -- for example, to allow device hardware used by the thread value -- for example, to allow device hardware used by the thread
to become available. to become available.
The kernel allows a delayed start to be cancelled before the thread begins The kernel allows a delayed start to be canceled before the thread begins
executing. A cancellation request has no effect if the thread has already executing. A cancellation request has no effect if the thread has already
started. A thread whose delayed start was successfully cancelled must be started. A thread whose delayed start was successfully canceled must be
re-spawned before it can be used. re-spawned before it can be used.
Thread Termination Thread Termination

4
doc/kernel/threads/workqueues.rst
View file

@ -122,7 +122,7 @@ Attempting to cancel a delayed work item once its timeout has expired has
no effect on the work item; the work item remains pending in the workqueue's no effect on the work item; the work item remains pending in the workqueue's
queue, unless the work item has already been removed and processed by the queue, unless the work item has already been removed and processed by the
workqueue's thread. Consequently, once a work item's timeout has expired workqueue's thread. Consequently, once a work item's timeout has expired
the work item is always processed by the workqueue and cannot be cancelled. the work item is always processed by the workqueue and cannot be canceled.
System Workqueue System Workqueue
================ ================
@ -224,7 +224,7 @@ A delayed work item is defined using a variable of type
An initialized delayed work item can be submitted to the system workqueue by An initialized delayed work item can be submitted to the system workqueue by
calling :cpp:func:`k_delayed_work_submit()`, or to a specified workqueue by calling :cpp:func:`k_delayed_work_submit()`, or to a specified workqueue by
calling :cpp:func:`k_delayed_work_submit_to_queue()`. A delayed work item calling :cpp:func:`k_delayed_work_submit_to_queue()`. A delayed work item
that has been submitted but not yet consumed by its workqueue can be cancelled that has been submitted but not yet consumed by its workqueue can be canceled
by calling :cpp:func:`k_delayed_work_cancel()`. by calling :cpp:func:`k_delayed_work_cancel()`.
Suggested Uses Suggested Uses

4
doc/porting/board_porting.rst
View file

@ -23,7 +23,7 @@ Hardware Configuration Hierarchy
******************************** ********************************
Hardware definitions in Zephyr follow a well-defined hierarchy of configurations Hardware definitions in Zephyr follow a well-defined hierarchy of configurations
and layers, below are thelayers from top to bottom: and layers, below are the layers from top to bottom:
- Board - Board
- SoC - SoC
@ -105,7 +105,7 @@ SoC Series
---------- ----------
Moving closer to the SoC, the series is derived from an SoC family. A series is Moving closer to the SoC, the series is derived from an SoC family. A series is
defined by a feautre set that serves the purpose of distinguishing different defined by a feature set that serves the purpose of distinguishing different
SoCs belonging to the same family. SoCs belonging to the same family.
SoC SoC

6
doc/release-notes-1.5.rst
View file

@ -83,9 +83,9 @@ Bluetooth
Build and Infrastructure Build and Infrastructure
************************ ************************
- Added “qemugdb” target to start a local GDB on port 1234. - Added "qemugdb" target to start a local GDB on port 1234.
- Added script to filter known issues in the build output. - Added script to filter known issues in the build output.
- Sanity: Added “-R” option to build all test with assertions. - Sanity: Added "-R" option to build all test with assertions.
Libraries Libraries
********* *********
@ -101,7 +101,7 @@ Documentation
- Fixed several typos, trademarks and grammar. - Fixed several typos, trademarks and grammar.
- Moved all the boards documentation to the wiki. - Moved all the boards documentation to the wiki.
- Moved Code Contribution documentation to the wiki. - Moved Code Contribution documentation to the wiki.
- Added package “ncurses” to the list of requirements. - Added package "ncurses" to the list of requirements.
- Updated Mac OS X instructions. - Updated Mac OS X instructions.
Test and Samples Test and Samples

8
doc/subsystems/bluetooth/gap-pics.rst
View file

@ -700,9 +700,9 @@ Central Simultaneous BR/EDR and LE Transports
============== ============== ======================================= ============== ============== =======================================
Parameter Name Selected Description Parameter Name Selected Description
============== ============== ======================================= ============== ============== =======================================
TSPC_GAP_44_1 False (*) Simultaneous BR/EDR and LE Transports – BR/EDR TSPC_GAP_44_1 False (*) Simultaneous BR/EDR and LE Transports - BR/EDR
Slave to the same device (C.1) Slave to the same device (C.1)
TSPC_GAP_44_2 False (*) Simultaneous BR/EDR and LE Transports – BR/EDR TSPC_GAP_44_2 False (*) Simultaneous BR/EDR and LE Transports - BR/EDR
Master to the same device (C.1) Master to the same device (C.1)
============== ============== ======================================= ============== ============== =======================================
@ -713,9 +713,9 @@ Peripheral Simultaneous BR/EDR and LE Transports
============== ============== ======================================= ============== ============== =======================================
Parameter Name Selected Description Parameter Name Selected Description
============== ============== ======================================= ============== ============== =======================================
TSPC_GAP_45_1 False (*) Simultaneous BR/EDR and LE Transports – BR/EDR TSPC_GAP_45_1 False (*) Simultaneous BR/EDR and LE Transports - BR/EDR
Slave to the same device (C.1) Slave to the same device (C.1)
TSPC_GAP_45_2 False (*) Simultaneous BR/EDR and LE Transports – BR/EDR TSPC_GAP_45_2 False (*) Simultaneous BR/EDR and LE Transports - BR/EDR
Master to the same device (C.1) Master to the same device (C.1)
============== ============== ======================================= ============== ============== =======================================

12
doc/subsystems/bluetooth/l2cap-pics.rst
View file

@ -112,15 +112,15 @@ TSPC_L2CAP_3_6 False (*) Support of flush timeout value for unreliable
TSPC_L2CAP_3_7 False (*) Support of bi-directional quality of service TSPC_L2CAP_3_7 False (*) Support of bi-directional quality of service
(QoS) option field (QoS) option field
TSPC_L2CAP_3_8 False (*) Negotiate QoS service type TSPC_L2CAP_3_8 False (*) Negotiate QoS service type
TSPC_L2CAP_3_9 False (*) Negotiate and support service type ‘No traffic’ TSPC_L2CAP_3_9 False (*) Negotiate and support service type 'No traffic'
TSPC_L2CAP_3_10 False (*) Negotiate and support service type ‘Best effort’ TSPC_L2CAP_3_10 False (*) Negotiate and support service type 'Best effort'
TSPC_L2CAP_3_11 False (*) Negotiate and support service type ‘Guaranteed’ TSPC_L2CAP_3_11 False (*) Negotiate and support service type 'Guaranteed'
TSPC_L2CAP_3_12 True Support minimum MTU size 23 octets TSPC_L2CAP_3_12 True Support minimum MTU size 23 octets
TSPC_L2CAP_3_13 False (*) Negotiate and support service type ‘No traffic’ TSPC_L2CAP_3_13 False (*) Negotiate and support service type 'No traffic'
for Extended Flow Specification for Extended Flow Specification
TSPC_L2CAP_3_14 False (*) Negotiate and support service type ‘Best Effort' TSPC_L2CAP_3_14 False (*) Negotiate and support service type 'Best Effort'
for Extended Flow Specification for Extended Flow Specification
TSPC_L2CAP_3_15 False (*) Negotiate and support service type ‘Guaranteed’ TSPC_L2CAP_3_15 False (*) Negotiate and support service type 'Guaranteed'
for Extended Flow Specification for Extended Flow Specification
TSPC_L2CAP_3_16 True Support Multiple Simultaneous LE Data Channels TSPC_L2CAP_3_16 True Support Multiple Simultaneous LE Data Channels
=============== =========== ======================================= =============== =========== =======================================

2
doc/subsystems/bluetooth/sm-pics.rst
View file

@ -68,7 +68,7 @@ Parameter Name Selected Description
TSPC_SM_5_1 True Encryption Setup using STK (C.3) TSPC_SM_5_1 True Encryption Setup using STK (C.3)
TSPC_SM_5_2 True Encryption Setup using LTK (O) TSPC_SM_5_2 True Encryption Setup using LTK (O)
TSPC_SM_5_3 True Slave Initiated Security (C.1) TSPC_SM_5_3 True Slave Initiated Security (C.1)
TSPC_SM_5_4 True Slave Initiated Security – Master response(C.2) TSPC_SM_5_4 True Slave Initiated Security - Master response(C.2)
=============== =========== ======================================= =============== =========== =======================================

10
doc/subsystems/logging/kernel_event_logger.rst
View file

@ -20,14 +20,14 @@ application. The capacity of the kernel event logger is also configurable.
By default, it has a ring buffer that can hold up to 128 32-bit words By default, it has a ring buffer that can hold up to 128 32-bit words
of event information. of event information.
The kernel event logger is capable of recording the following pre-defined The kernel event logger is capable of recording the following predefined
event types: event types:
* Interrupts. * Interrupts.
* Context switching of threads. * Context switching of threads.
* Kernel sleep events (i.e. entering and exiting a low power state). * Kernel sleep events (i.e. entering and exiting a low power state).
The kernel event logger only records the pre-defined event types it has been The kernel event logger only records the predefined event types it has been
configured to record. Each event type can be enabled independently. configured to record. Each event type can be enabled independently.
An application can also define and record custom event types. An application can also define and record custom event types.
@ -93,7 +93,7 @@ A **sleep event** has the following format:
}; };
A **custom event** must have a type ID that does not conflict with A **custom event** must have a type ID that does not conflict with
any existing pre-defined event type ID. The format of a custom event any existing predefined event type ID. The format of a custom event
is application-defined, but must contain at least one 32-bit data word. is application-defined, but must contain at least one 32-bit data word.
A custom event may utilize a variable size, to allow different events A custom event may utilize a variable size, to allow different events
of a single type to record differing amounts of information. of a single type to record differing amounts of information.
@ -101,7 +101,7 @@ of a single type to record differing amounts of information.
Timestamps Timestamps
========== ==========
By default, the timestamp recorded with each pre-defined event is obtained from By default, the timestamp recorded with each predefined event is obtained from
the kernel's :ref:`hardware clock <clocks_v2>`. This 32-bit clock counts up the kernel's :ref:`hardware clock <clocks_v2>`. This 32-bit clock counts up
extremely rapidly, which means the timestamp value wraps around frequently. extremely rapidly, which means the timestamp value wraps around frequently.
(For example, the Lakemont APIC timer for Quark SE wraps every 134 seconds.) (For example, the Lakemont APIC timer for Quark SE wraps every 134 seconds.)
@ -176,7 +176,7 @@ Adding a Custom Event Type
========================== ==========================
A custom event type must use an integer type ID that does not duplicate A custom event type must use an integer type ID that does not duplicate
an existing type ID. The type IDs for the pre-defined events can be found an existing type ID. The type IDs for the predefined events can be found
in :file:`include/logging/kernel_event_logger.h`. If dynamic recording of in :file:`include/logging/kernel_event_logger.h`. If dynamic recording of
events is enabled, the event type ID must not exceed 32. events is enabled, the event type ID must not exceed 32.

2
doc/subsystems/networking/network-management-api.rst
View file

@ -69,7 +69,7 @@ will be found in the `include/net/net_mgmt.h` header file. But in case
of an L2 technology, let's say Ethernet, these would be found in of an L2 technology, let's say Ethernet, these would be found in
`include/net/ethernet.h` `include/net/ethernet.h`
You define your handler modelled with this signature: You define your handler modeled with this signature:
.. code-block:: c .. code-block:: c

4
doc/subsystems/networking/qemu_setup.rst
View file

@ -1,6 +1,6 @@
.. _networking_with_qemu: .. _networking_with_qemu:
Networking with Qemu Networking with QEMU
#################### ####################
This page describes how to set up a "virtual" networking between a (Linux) host This page describes how to set up a "virtual" networking between a (Linux) host
@ -41,7 +41,7 @@ For the steps below, you will need at least 4 terminal windows:
Step 1 - Create helper socket Step 1 - Create helper socket
============================= =============================
Before starting QEMU with network emulation, a unix socket for the emulation Before starting QEMU with network emulation, a Unix socket for the emulation
should be created. should be created.
In terminal #2, type: In terminal #2, type:

8
doc/subsystems/shell.rst
View file

@ -24,7 +24,7 @@ A shell interface exposing subsystem features is a shell module, multiple
modules can be available at the same time. modules can be available at the same time.
`MODULE_NAME COMMAND` `MODULE_NAME COMMAND`
One of the available modules is “KERNEL”, for the Kernel module. More One of the available modules is "KERNEL", for the Kernel module. More
information can be found in :c:macro:`SHELL_REGISTER`. information can be found in :c:macro:`SHELL_REGISTER`.
Help commands Help commands
@ -48,7 +48,7 @@ Select module commands
command, you will not need to enter module name in further commands. If command, you will not need to enter module name in further commands. If
the selected module has set a default shell prompt during its initialization, the selected module has set a default shell prompt during its initialization,
the prompt will be changed to that one. Otherwise, the prompt will be the prompt will be changed to that one. Otherwise, the prompt will be
changed to the selected module’s name to reflect the current module in use. changed to the selected module's name to reflect the current module in use.
`select` `select`
Clears selected module. Restores prompt as well. Clears selected module. Restores prompt as well.
@ -71,7 +71,7 @@ Example:
CONFIG_NET_SHELL=y CONFIG_NET_SHELL=y
In the subsystem’s code, the shell usage depends on this config parameter. In the subsystem's code, the shell usage depends on this config parameter.
This subsystem specific flag should also depend on :option:`CONFIG_CONSOLE_SHELL` flag. This subsystem specific flag should also depend on :option:`CONFIG_CONSOLE_SHELL` flag.
Configuration steps to add shell functionality to a module Configuration steps to add shell functionality to a module
@ -103,7 +103,7 @@ set a default module in code level. In this case, the function
shell_register_default_module should be called after calling SHELL_REGISTER in shell_register_default_module should be called after calling SHELL_REGISTER in
application level. If the function shell_register_prompt_handler was called as application level. If the function shell_register_prompt_handler was called as
well, the prompt will be changed to that one. Otherwise, the prompt will be well, the prompt will be changed to that one. Otherwise, the prompt will be
changed to the selected module’s name, in order to reflect the current module in changed to the selected module's name, in order to reflect the current module in
use. use.

6
samples/net/http_server/README.rst
View file

@ -129,7 +129,7 @@ wget will show:
Connecting to 192.168.1.101:80... connected. Connecting to 192.168.1.101:80... connected.
HTTP request sent, awaiting response... 200 OK HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html] Length: unspecified [text/html]
Saving to: ‘index.html’ Saving to: 'index.html'
The HTML file generated by Zephyr and downloaded by wget is: The HTML file generated by Zephyr and downloaded by wget is:
@ -174,7 +174,7 @@ wget will show:
Connecting to 192.168.1.101:80... connected. Connecting to 192.168.1.101:80... connected.
HTTP request sent, awaiting response... 200 OK HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html] Length: unspecified [text/html]
Saving to: ‘index.html’ Saving to: 'index.html'
This is the HTML file generated by Zephyr and downloaded by wget: This is the HTML file generated by Zephyr and downloaded by wget:
@ -288,7 +288,7 @@ This will be shown on the screen
Unable to locally verify the issuer's authority. Unable to locally verify the issuer's authority.
HTTP request sent, awaiting response... 200 OK HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html] Length: unspecified [text/html]
Saving to: ‘index.html’ Saving to: 'index.html'
index.html [ <=> ] index.html [ <=> ]