patrick/zephyr
1
0
Fork 0
Code Issues Pull requests Actions 8 Packages Projects Releases Wiki Activity

everywhere: fix typos

Browse source 
Fix a lot of typos

Signed-off-by: Nazar Kazakov <nazar.kazakov.work@gmail.com>
This commit is contained in:
Nazar Kazakov 2022-03-16 21:07:43 +00:00 committed by Anas Nashif
parent 3b576fc688
commit f483b1bc4c
757 changed files with 1284 additions and 1284 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
.github/labeler.yml vendored
View file

@ -70,7 +70,7 @@
- "arch/xtensa/**/*" - "arch/xtensa/**/*"
- "include/arch/xtensa/**/*" - "include/arch/xtensa/**/*"
"area: RISCV": "area: RISCV":
- "arch/risv/**/*" - "arch/riscv/**/*"
- "include/arch/riscv/**/*" - "include/arch/riscv/**/*"
"area: ARC": "area: ARC":
- "arch/arc/**/*" - "arch/arc/**/*"

2
CMakeLists.txt
View file

@ -271,7 +271,7 @@ zephyr_compile_options(
# ToDo: Remember to get feedback from Oticon on this, as they might use the `ASM_BASE_FLAG` since this is done this way. # ToDo: Remember to get feedback from Oticon on this, as they might use the `ASM_BASE_FLAG` since this is done this way.
zephyr_compile_options($<$<COMPILE_LANGUAGE:ASM>:$<TARGET_PROPERTY:asm,required>>) zephyr_compile_options($<$<COMPILE_LANGUAGE:ASM>:$<TARGET_PROPERTY:asm,required>>)
# @Intent: Enforce standard integer type correspondance to match Zephyr usage. # @Intent: Enforce standard integer type correspondence to match Zephyr usage.
# (must be after compiler specific flags) # (must be after compiler specific flags)
if(NOT CONFIG_ARCH_POSIX) if(NOT CONFIG_ARCH_POSIX)
# `zephyr_stdint.h` is not included for the POSIX (native) arch because it # `zephyr_stdint.h` is not included for the POSIX (native) arch because it

2
arch/Kconfig
View file

@ -799,7 +799,7 @@ choice CACHE_TYPE
config HAS_ARCH_CACHE config HAS_ARCH_CACHE
bool "Integrated cache controller" bool "Integrated cache controller"
help help
"Integrade on-core cache controller" "Integrated on-core cache controller"
config HAS_EXTERNAL_CACHE config HAS_EXTERNAL_CACHE
bool "External cache controller" bool "External cache controller"

2
arch/arc/core/irq_manage.c
View file

@ -135,7 +135,7 @@ void z_irq_priority_set(unsigned int irq, unsigned int prio, uint32_t flags)
__ASSERT(prio < CONFIG_NUM_IRQ_PRIO_LEVELS, __ASSERT(prio < CONFIG_NUM_IRQ_PRIO_LEVELS,
"invalid priority %d for irq %d", prio, irq); "invalid priority %d for irq %d", prio, irq);
/* 0 -> CONFIG_NUM_IRQ_PRIO_LEVELS allocted to secure world /* 0 -> CONFIG_NUM_IRQ_PRIO_LEVELS allocated to secure world
* left prio levels allocated to normal world * left prio levels allocated to normal world
*/ */
#if defined(CONFIG_ARC_SECURE_FIRMWARE) #if defined(CONFIG_ARC_SECURE_FIRMWARE)

2
arch/arm/core/aarch32/userspace.S
View file

@ -245,7 +245,7 @@ SECTION_FUNC(TEXT,z_arm_userspace_enter)
mov r0, lr mov r0, lr
#if defined(CONFIG_ARMV7_R) #if defined(CONFIG_ARMV7_R)
/* change processor mode to unprivileged, with all interrrupts enabled. */ /* change processor mode to unprivileged, with all interrupts enabled. */
msr CPSR_c, #MODE_USR msr CPSR_c, #MODE_USR
#else #else
/* change processor mode to unprivileged */ /* change processor mode to unprivileged */

2
arch/posix/core/swap.c
View file

@ -23,7 +23,7 @@
int arch_swap(unsigned int key) int arch_swap(unsigned int key)
{ {
/* /*
* struct k_thread * _current is the currently runnig thread * struct k_thread * _current is the currently running thread
* struct k_thread * _kernel.ready_q.cache contains the next thread to * struct k_thread * _kernel.ready_q.cache contains the next thread to
* run (cannot be NULL) * run (cannot be NULL)
* *

2
arch/riscv/core/pmp/core_pmp.c
View file

@ -271,7 +271,7 @@ static void csr_write_enum(int pmp_csr_enum, ulong_t value)
* *
* Configure a memory region to be secured by one of the 16 PMP entries. * Configure a memory region to be secured by one of the 16 PMP entries.
* *
* @param index Number of the targeted PMP entrie (0 to 15 only). * @param index Number of the targeted PMP entry (0 to 15 only).
* @param cfg_val Configuration value (cf datasheet or defined flags) * @param cfg_val Configuration value (cf datasheet or defined flags)
* @param addr_val Address register value * @param addr_val Address register value
* *

2
arch/riscv/core/thread.c
View file

@ -55,7 +55,7 @@ void arch_new_thread(struct k_thread *thread, k_thread_stack_t *stack,
* Following the RISC-V architecture, * Following the RISC-V architecture,
* the MSTATUS register (used to globally enable/disable interrupt), * the MSTATUS register (used to globally enable/disable interrupt),
* as well as the MEPC register (used to by the core to save the * as well as the MEPC register (used to by the core to save the
* value of the program counter at which an interrupt/exception occcurs) * value of the program counter at which an interrupt/exception occurs)
* need to be saved on the stack, upon an interrupt/exception * need to be saved on the stack, upon an interrupt/exception
* and restored prior to returning from the interrupt/exception. * and restored prior to returning from the interrupt/exception.
* This shall allow to handle nested interrupts. * This shall allow to handle nested interrupts.

6
arch/sparc/core/fatal.c
View file

@ -53,7 +53,7 @@ LOG_MODULE_DECLARE(os, CONFIG_KERNEL_LOG_LEVEL);
* *
* HOW TO USE * HOW TO USE
* *
* When invesetigating a crashed program, the first things to look * When investigating a crashed program, the first things to look
* at is typically the tt, pc and sp (o6). You can lookup the pc * at is typically the tt, pc and sp (o6). You can lookup the pc
* in the assembly list file or use addr2line. In the listing, the * in the assembly list file or use addr2line. In the listing, the
* register values in the table above can be used. The linker map * register values in the table above can be used. The linker map
@ -68,7 +68,7 @@ LOG_MODULE_DECLARE(os, CONFIG_KERNEL_LOG_LEVEL);
* g7 is the TLS pointer if enabled. A SAVE instruction decreases * g7 is the TLS pointer if enabled. A SAVE instruction decreases
* the current window pointer (psr bits 4..0) which results in %o * the current window pointer (psr bits 4..0) which results in %o
* registers becoming %i registers and a new set of %l registers * registers becoming %i registers and a new set of %l registers
* appear. RESTORE does the oppposite. * appear. RESTORE does the opposite.
*/ */
@ -85,7 +85,7 @@ LOG_MODULE_DECLARE(os, CONFIG_KERNEL_LOG_LEVEL);
* *
* When printing the registers, we get the "local" and "in" * When printing the registers, we get the "local" and "in"
* registers from the ABI stack save area, while the "out" and * registers from the ABI stack save area, while the "out" and
* "global" registares are taken from the exception stack frame * "global" registers are taken from the exception stack frame
* generated in the fault trap entry. * generated in the fault trap entry.
*/ */
struct savearea { struct savearea {

2
arch/x86/core/userspace.c
View file

@ -23,7 +23,7 @@
* we go through z_x86_trampoline_to_user. * we go through z_x86_trampoline_to_user.
* *
* We don't need to update the privilege mode initial stack pointer either, * We don't need to update the privilege mode initial stack pointer either,
* privilege elevation always lands on the trampoline stack and the irq/sycall * privilege elevation always lands on the trampoline stack and the irq/syscall
* code has to manually transition off of it to the appropriate stack after * code has to manually transition off of it to the appropriate stack after
* switching page tables. * switching page tables.
*/ */

6
arch/x86/core/x86_mmu.c
View file

@ -977,7 +977,7 @@ static inline pentry_t pte_atomic_update(pentry_t *pte, pentry_t update_val,
* bits and return the previous PTE value. * bits and return the previous PTE value.
* *
* Common mask values: * Common mask values:
* MASK_ALL - Update all PTE bits. Exitsing state totally discarded. * MASK_ALL - Update all PTE bits. Existing state totally discarded.
* MASK_PERM - Only update permission bits. All other bits and physical * MASK_PERM - Only update permission bits. All other bits and physical
* mapping preserved. * mapping preserved.
* *
@ -1147,7 +1147,7 @@ out:
* @param size Size of the physical region to map * @param size Size of the physical region to map
* @param entry_flags Desired state of non-address PTE bits covered by mask, * @param entry_flags Desired state of non-address PTE bits covered by mask,
* ignored if OPTION_RESET * ignored if OPTION_RESET
* @param mask What bits in the PTE to actually modifiy; unset bits will * @param mask What bits in the PTE to actually modify; unset bits will
* be preserved. Ignored if OPTION_RESET. * be preserved. Ignored if OPTION_RESET.
* @param options Control options. Do not set OPTION_USER here. OPTION_FLUSH * @param options Control options. Do not set OPTION_USER here. OPTION_FLUSH
* will trigger a TLB shootdown after all tables are updated. * will trigger a TLB shootdown after all tables are updated.
@ -1334,7 +1334,7 @@ static void identity_map_remove(uint32_t level)
#endif #endif
/* Invoked to remove the identity mappings in the page tables, /* Invoked to remove the identity mappings in the page tables,
* they were only needed to tranisition the instruction pointer at early boot * they were only needed to transition the instruction pointer at early boot
*/ */
__boot_func __boot_func
void z_x86_mmu_init(void) void z_x86_mmu_init(void)

2
arch/xtensa/core/gdbstub.c
View file

@ -981,7 +981,7 @@ void arch_gdb_init(void)
* converting BREAK.N into BREAK which is bigger. * converting BREAK.N into BREAK which is bigger.
* This is needed as the GDB stub will need to change * This is needed as the GDB stub will need to change
* the program counter past this instruction to * the program counter past this instruction to
* continue working. Or else SoC would repeartedly * continue working. Or else SoC would repeatedly
* raise debug exception on this instruction and * raise debug exception on this instruction and
* won't go forward. * won't go forward.
*/ */

2
boards/arc/emsdp/support/openocd.cfg
View file

@ -7,7 +7,7 @@
# #
# Configure JTAG cable # Configure JTAG cable
# EM SDP has built-in FT2232 chip, which is similiar to Digilent HS-1. # EM SDP has built-in FT2232 chip, which is similar to Digilent HS-1.
adapter driver ftdi adapter driver ftdi
# Only specify FTDI serial number if it is specified via # Only specify FTDI serial number if it is specified via

2
boards/arc/hsdk/support/openocd-2-cores.cfg
View file

@ -4,7 +4,7 @@
# Configure JTAG cable # Configure JTAG cable
# SDP has built-in FT2232 chip, which is similar to Digilent HS-1, except that # SDP has built-in FT2232 chip, which is similar to Digilent HS-1, except that
# it uses channgel B for JTAG, instead of channel A. # it uses channel B for JTAG, instead of channel A.
adapter driver ftdi adapter driver ftdi
# Only specify FTDI serial number if it is specified via # Only specify FTDI serial number if it is specified via

2
boards/arc/hsdk/support/openocd.cfg
View file

@ -4,7 +4,7 @@
# Configure JTAG cable # Configure JTAG cable
# SDP has built-in FT2232 chip, which is similar to Digilent HS-1, except that # SDP has built-in FT2232 chip, which is similar to Digilent HS-1, except that
# it uses channgel B for JTAG, instead of channel A. # it uses channel B for JTAG, instead of channel A.
adapter driver ftdi adapter driver ftdi
# Only specify FTDI serial number if it is specified via # Only specify FTDI serial number if it is specified via

2
boards/arc/qemu_arc/doc/index.rst
View file

@ -80,7 +80,7 @@ QEMU, and display the following console output:
*** Booting Zephyr OS build zephyr-v2.2.0-2486-g7dbfcf4bab57 *** *** Booting Zephyr OS build zephyr-v2.2.0-2486-g7dbfcf4bab57 ***
threadA: Hello World from qemu_arc! threadA: Hello World from qemu_arc!
threudB: Hello World from qemu_arc! threadB: Hello World from qemu_arc!
threadA: Hello World from qemu_arc! threadA: Hello World from qemu_arc!
threadB: Hello World from qemu_arc! threadB: Hello World from qemu_arc!

2
boards/arm/96b_argonkey/doc/index.rst
View file

@ -37,7 +37,7 @@ Hardware
- Temperature/Pressure: STMicro LPS22HB - Temperature/Pressure: STMicro LPS22HB
- ALS: Intersil ISL29034 - ALS: Intersil ISL29034
- Proximity: STMicro VL53L0X - Proximity: STMicro VL53L0X
- Acclerometer/Gyroscope: STMicro LSM6DSL - Accelerometer/Gyroscope: STMicro LSM6DSL
- Geomagnetic: STMicro LIS2MDL - Geomagnetic: STMicro LIS2MDL
- AMR Hall sensor: MRMS501A - AMR Hall sensor: MRMS501A
- Microphone: STMicro MP34DT05 - Microphone: STMicro MP34DT05

2
boards/arm/96b_meerkat96/doc/index.rst
View file

@ -149,7 +149,7 @@ the remaining are not used/tested.
Programming and Debugging Programming and Debugging
************************* *************************
The 96Boards Meerakat96 board doesn't have QSPI flash for the M4 and it needs The 96Boards Meerkat96 board doesn't have QSPI flash for the M4 and it needs
to be started by the A7 core. The A7 core is responsible to load the M4 binary to be started by the A7 core. The A7 core is responsible to load the M4 binary
application into the RAM, put the M4 in reset, set the M4 Program Counter and application into the RAM, put the M4 in reset, set the M4 Program Counter and
Stack Pointer, and get the M4 out of reset. The A7 can perform these steps at Stack Pointer, and get the M4 out of reset. The A7 can perform these steps at

2
boards/arm/96b_neonkey/doc/index.rst
View file

@ -37,7 +37,7 @@ Hardware
- Pressure: BMP280 - Pressure: BMP280
- ALS/Proximity: RPR-0521RS - ALS/Proximity: RPR-0521RS
- Geomagnetic: BMM150 - Geomagnetic: BMM150
- Acclerometer/Gyroscope: BMI160 - Accelerometer/Gyroscope: BMI160
- AMR Hall sensor: MRMS501A - AMR Hall sensor: MRMS501A
- Microphone: SPK0415HM4H-B - Microphone: SPK0415HM4H-B

2
boards/arm/96b_stm32_sensor_mez/doc/index.rst
View file

@ -32,7 +32,7 @@ Hardware
- On board sensors: - On board sensors:
- Temperature/Pressure: STMicro LPS22HB - Temperature/Pressure: STMicro LPS22HB
- Acclerometer/Gyroscope: STMicro LSM6DS3H - Accelerometer/Gyroscope: STMicro LSM6DS3H
- Magnetometer: STMicro LIS3MDL - Magnetometer: STMicro LIS3MDL
- Microphone: STMicro MP34DT01 - Microphone: STMicro MP34DT01

4
boards/arm/arduino_nano_33_ble/doc/index.rst
View file

@ -71,11 +71,11 @@ Connections and IOs
The `schematic`_ will tell you everything The `schematic`_ will tell you everything
you need to know about the pins. you need to know about the pins.
A convinience header mapping the Arduino pin names to their A convenience header mapping the Arduino pin names to their
Zephyr pin numbers can be found in :code:`arduino_nano_33_ble_pins.h`, Zephyr pin numbers can be found in :code:`arduino_nano_33_ble_pins.h`,
if you link against the :code:`arduino_nano_33_ble_pins` CMake library. if you link against the :code:`arduino_nano_33_ble_pins` CMake library.
For your convience, two Kconfig options are added: For your convenience, two Kconfig options are added:
#. :code:`BOARD_ARDUINO_NANO_33_BLE_INIT_SENSORS`: #. :code:`BOARD_ARDUINO_NANO_33_BLE_INIT_SENSORS`:
This configuration option enables the internal I2C sensors. This configuration option enables the internal I2C sensors.

2
boards/arm/arty/doc/index.rst
View file

@ -33,7 +33,7 @@ DesignStart FPGA`_ Xilinx edition reference designs from ARM. Zephyr supports
both the Cortex-M1 and the Cortex-M3 reference designs. The Cortex-M1 design both the Cortex-M1 and the Cortex-M3 reference designs. The Cortex-M1 design
targets either the Spartan-7 or Artix-7 based Arty boards, whereas the Cortex-M3 targets either the Spartan-7 or Artix-7 based Arty boards, whereas the Cortex-M3
design only targets the Artix-7 based boards. Zephyr only supports the Artix-7 design only targets the Artix-7 based boards. Zephyr only supports the Artix-7
targetted designs for now. targeted designs for now.
For more information about the ARM Cortex-M1/M3 DesignStart FPGA, see the For more information about the ARM Cortex-M1/M3 DesignStart FPGA, see the
following websites: following websites:

2
boards/arm/cc3220sf_launchxl/pinmux.c
View file

@ -78,7 +78,7 @@
* driverlib pin defines. For example, I2C_CC32XX_PIN_01_I2C_SCL & 0xff = 0, * driverlib pin defines. For example, I2C_CC32XX_PIN_01_I2C_SCL & 0xff = 0,
* which equals PIN_01 in driverlib pin.h. By matching the PIN_xx defines in * which equals PIN_01 in driverlib pin.h. By matching the PIN_xx defines in
* driverlib pin.h, we can pass the pin directly to the driverlib functions. * driverlib pin.h, we can pass the pin directly to the driverlib functions.
* The upper 8 bits of the macro correspond to the pin mux confg mode * The upper 8 bits of the macro correspond to the pin mux config mode
* value for the pin to operate in the I2C mode. For example, pin 1 is * value for the pin to operate in the I2C mode. For example, pin 1 is
* configured with mode 1 to operate as I2C_SCL. * configured with mode 1 to operate as I2C_SCL.
*/ */

2
boards/arm/cc3235sf_launchxl/pinmux.c
View file

@ -53,7 +53,7 @@
* driverlib pin defines. For example, I2C_CC32XX_PIN_01_I2C_SCL & 0xff = 0, * driverlib pin defines. For example, I2C_CC32XX_PIN_01_I2C_SCL & 0xff = 0,
* which equals PIN_01 in driverlib pin.h. By matching the PIN_xx defines in * which equals PIN_01 in driverlib pin.h. By matching the PIN_xx defines in
* driverlib pin.h, we can pass the pin directly to the driverlib functions. * driverlib pin.h, we can pass the pin directly to the driverlib functions.
* The upper 8 bits of the macro correspond to the pin mux confg mode * The upper 8 bits of the macro correspond to the pin mux config mode
* value for the pin to operate in the I2C mode. For example, pin 1 is * value for the pin to operate in the I2C mode. For example, pin 1 is
* configured with mode 1 to operate as I2C_SCL. * configured with mode 1 to operate as I2C_SCL.
*/ */

6
boards/arm/contextualelectronics_abc/doc/index.rst
View file

@ -1,12 +1,12 @@
.. _contextualelectronics_abc: .. _contextualelectronics_abc:
Contextual Eletronics Advanced BLE Cell Contextual Electronics Advanced BLE Cell
####################################### ########################################
Overview Overview
******** ********
The Contextual Eletronics ABC (PCA10056) hardware provides support for the The Contextual Electronics ABC (PCA10056) hardware provides support for the
Nordic Semiconductor nRF52840 ARM Cortex-M4F CPU and the following devices: Nordic Semiconductor nRF52840 ARM Cortex-M4F CPU and the following devices:
* CLOCK * CLOCK

4
boards/arm/cy8ckit_062_ble/doc/index.rst
View file

@ -246,10 +246,10 @@ are only possible after rework the board and using the revision 1.0.0.
:goals: build :goals: build
:compact: :compact:
#. The diferences from version 0.0.0 to 1.0.0: #. The differences from version 0.0.0 to 1.0.0:
+-------------+------------+------------+ +-------------+------------+------------+
| Connecion | 0.0.0 | 1.0.0 | | Connection | 0.0.0 | 1.0.0 |
+=============+============+============+ +=============+============+============+
| CDC-COM RX | P5_0 | P9_0 | | CDC-COM RX | P5_0 | P9_0 |
+-------------+------------+------------+ +-------------+------------+------------+

2
boards/arm/efm32wg_stk3800/doc/index.rst
View file

@ -41,7 +41,7 @@ For more information about the EFM32WG SoC and EFM32WG-STK3800 board:
Supported Features Supported Features
================== ==================
The efm32wg_stk3800oard configuration supports the following hardware features: The efm32wg_stk3800 board configuration supports the following hardware features:
+-----------+------------+-------------------------------------+ +-----------+------------+-------------------------------------+
| Interface | Controller | Driver/Component | | Interface | Controller | Driver/Component |

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

@ -215,7 +215,7 @@ CAN
=== ===
The FRDM-K64F board does not come with an onboard CAN transceiver. In order to The FRDM-K64F board does not come with an onboard CAN transceiver. In order to
use the CAN bus, an external CAN bus tranceiver must be connected to ``PTB18`` use the CAN bus, an external CAN bus transceiver must be connected to ``PTB18``
(``CAN0_TX``) and ``PTB19`` (``CAN0_RX``). (``CAN0_TX``) and ``PTB19`` (``CAN0_RX``).
Programming and Debugging Programming and Debugging

2
boards/arm/mec15xxevb_assy6853/doc/index.rst
View file

@ -9,7 +9,7 @@ Overview
The MEC15xxEVB_ASSY6853 kit is a future development platform to evaluate the The MEC15xxEVB_ASSY6853 kit is a future development platform to evaluate the
Microchip MEC15XX series microcontrollers. This board needs to be mated with Microchip MEC15XX series microcontrollers. This board needs to be mated with
part number MEC1501 144WFBA SOLDER DC ASSY 6860(cpu board) in order to operate. part number MEC1501 144WFBA SOLDER DC ASSY 6860(cpu board) in order to operate.
The MEC152x has superceded the MEC1501 in production. MEC152x is identical to The MEC152x has superseded the MEC1501 in production. MEC152x is identical to
MEC150x except for an enhanced Boot-ROM SPI loader. The SPI image format has MEC150x except for an enhanced Boot-ROM SPI loader. The SPI image format has
been updated requiring a new SPI image tool. MEC1501 and MEC152x SPI image been updated requiring a new SPI image tool. MEC1501 and MEC152x SPI image
formats are not compatible with each other. Evaluation and cpu boards are formats are not compatible with each other. Evaluation and cpu boards are

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

@ -56,7 +56,7 @@ Other hardware features have not been enabled yet for this board.
The default configuration can be found in the defconfig file: The default configuration can be found in the defconfig file:
``boards/arm/mikroe_clicker_2/mikroe_cliker_2_defconfig`` ``boards/arm/mikroe_clicker_2/mikroe_clicker_2_defconfig``
Connections and IOs Connections and IOs
=================== ===================

2
boards/arm/mm_feather/doc/index.rst
View file

@ -198,7 +198,7 @@ Flashing
Here is an example for the :ref:`hello_world` application. Here is an example for the :ref:`hello_world` application.
Connect a DAPLink debuger from your PC to corresponding SWD pins of SwiftIO Feather. Connect a DAPLink debugger from your PC to corresponding SWD pins of SwiftIO Feather.
.. zephyr-app-commands:: .. zephyr-app-commands::
:zephyr-app: samples/hello_world :zephyr-app: samples/hello_world

2
boards/arm/nrf51_ble400/doc/index.rst
View file

@ -72,7 +72,7 @@ Motherboard
3. I2C interface 3. I2C interface
4. SPI interface 4. SPI interface
5. 5V/3.3V power input/output: usually used as power output, also common-grounding with other user board 5. 5V/3.3V power input/output: usually used as power output, also common-grounding with other user board
6. USB connector: USB TO UART via onboard convertor CP2102 6. USB connector: USB TO UART via onboard converter CP2102
7. Debugging interface 7. Debugging interface
8. UART interface 8. UART interface
9. Battery holder 9. Battery holder

4
boards/arm/nrf52840_mdk_usb_dongle/Kconfig.defconfig
View file

@ -14,8 +14,8 @@ config BOARD
# To let the nRF5 bootloader load an application, the application # To let the nRF5 bootloader load an application, the application
# must be linked after Nordic MBR, that is factory-programmed on the board. # must be linked after Nordic MBR, that is factory-programmed on the board.
# Nordic nRF5 booatloader exists outside of the partitions specified in the # Nordic nRF5 bootloader exists outside of the partitions specified in the
# DTS file, so we manually override FLASH_LOAD_OFFEST to link the application # DTS file, so we manually override FLASH_LOAD_OFFSET to link the application
# correctly, after Nordic MBR. # correctly, after Nordic MBR.
# When building MCUBoot, MCUBoot itself will select USE_DT_CODE_PARTITION # When building MCUBoot, MCUBoot itself will select USE_DT_CODE_PARTITION

2
boards/arm/nucleo_g0b1re/doc/index.rst
View file

@ -63,7 +63,7 @@ Nucleo G0B1RE provides the following hardware components:
- Tamper Pins(3) - Tamper Pins(3)
- 12-bit ADC with 16 channels - 12-bit ADC with 16 channels
- 12-bit DAC with 2 channels(2) - 12-bit DAC with 2 channels(2)
- Analog Comperator(3) - Analog Comparator(3)
- 12-channel DMA - 12-channel DMA

4
boards/arm/nucleo_h723zg/support/openocd.cfg
View file

@ -1,4 +1,4 @@
# STM32H745ZI Nucleo board OpenOCD ST-LLINK V3 configuration # STM32H745ZI Nucleo board OpenOCD ST-LINK V3 configuration
# #
# Copyright (c) 2020 Alexander Kozhinov <AlexanderKozhinov@yandex.com> # Copyright (c) 2020 Alexander Kozhinov <AlexanderKozhinov@yandex.com>
# SPDX-License-Identifier: Apache-2.0 # SPDX-License-Identifier: Apache-2.0
@ -13,7 +13,7 @@ set BOARDNAME NUCLEO-H723ZG
source [find target/stm32h7x.cfg] source [find target/stm32h7x.cfg]
# Use connect_assert_srst here to be able to programm # Use connect_assert_srst here to be able to program
# even when core is in sleep mode # even when core is in sleep mode
reset_config srst_only srst_nogate connect_assert_srst reset_config srst_only srst_nogate connect_assert_srst

2
boards/arm/nucleo_h745zi_q/support/openocd.cfg
View file

@ -6,7 +6,7 @@
source [find board/st_nucleo_h745zi.cfg] source [find board/st_nucleo_h745zi.cfg]
# Use connect_assert_srst here to be able to programm # Use connect_assert_srst here to be able to program
# even when core is in sleep mode # even when core is in sleep mode
reset_config srst_only srst_nogate connect_assert_srst reset_config srst_only srst_nogate connect_assert_srst

2
boards/arm/nucleo_l152re/support/openocd.cfg
View file

@ -1,4 +1,4 @@
# TODO: Once official oepnOCD fix merged and available in zephyr: # TODO: Once official openOCD fix merged and available in zephyr:
# http://openocd.zylin.com/#/c/5829/ # http://openocd.zylin.com/#/c/5829/
# revert to board/st_nucleo_l1.cfg # revert to board/st_nucleo_l1.cfg
# source [find board/st_nucleo_l1.cfg] # source [find board/st_nucleo_l1.cfg]

2
boards/arm/olimex_stm32_h103/doc/index.rst
View file

@ -211,7 +211,7 @@ Programming and Debugging
This board does not include any embedded debug tool interface, instead you This board does not include any embedded debug tool interface, instead you
will have to use an external probe connected to the available 20-pin JTAG will have to use an external probe connected to the available 20-pin JTAG
connector to progran and debug the board. Both JTAG and SWD are supported. connector to program and debug the board. Both JTAG and SWD are supported.
By default when using ``west debug`` ST-Link will be used with OpenOCD's By default when using ``west debug`` ST-Link will be used with OpenOCD's
SWD transport, but it is also possible to use JTAG with the Olimex ARM-USB-OCD-H SWD transport, but it is also possible to use JTAG with the Olimex ARM-USB-OCD-H

2
boards/arm/pinetime_devkit0/doc/index.rst
View file

@ -185,7 +185,7 @@ Debugging
Using Segger Ozone debugger, debugging and flashing is made easy. Using Segger Ozone debugger, debugging and flashing is made easy.
Simply load the .elf file containing the final firmware and Simply load the .elf file containing the final firmware and
setup the debbuger to use SWD over USB for the chip nRF52832_xxAA. setup the debugger to use SWD over USB for the chip nRF52832_xxAA.
This setup can be done using the menu Tools/J-Link Settings. or by directly This setup can be done using the menu Tools/J-Link Settings. or by directly
typing the following in the debugger console: typing the following in the debugger console:

2
boards/arm/qemu_cortex_m0/nrf_timer_timer.c
View file

@ -71,7 +71,7 @@ static void prevent_false_prev_evt(void)
uint32_t prev_val; uint32_t prev_val;
/* First take care of a risk of an event coming from CC being set to /* First take care of a risk of an event coming from CC being set to
* next tick. Reconfigure CC to future (now tick is the furtherest * next tick. Reconfigure CC to future (now tick is the furthest
* future). If CC was set to next tick we need to wait for up to 0.5us * future). If CC was set to next tick we need to wait for up to 0.5us
* (half of 1M tick) and clean potential event. After that time there * (half of 1M tick) and clean potential event. After that time there
* is no risk of unwanted event. * is no risk of unwanted event.

2
boards/arm/quick_feather/quick_feather_defconfig
View file

@ -14,7 +14,7 @@ CONFIG_SERIAL=y
CONFIG_CONSOLE=y CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y CONFIG_UART_CONSOLE=y
# EOS S3 Configuartion Manager copies software from external flash to MCU # EOS S3 Configuration Manager copies software from external flash to MCU
# memory using preconfigured DMA and execute it there. # memory using preconfigured DMA and execute it there.
# Thus we do not use flash directly. # Thus we do not use flash directly.

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

@ -93,7 +93,7 @@ Here are official IOs figures from eLinux for Kingfisher Infotainment board:
GPIO GPIO
---- ----
By running Zephyr on H3ULCB, the software readable push button 'SW3' can be used as input, and the software contollable LED 'LED5' can be used as output. By running Zephyr on H3ULCB, the software readable push button 'SW3' can be used as input, and the software controllable LED 'LED5' can be used as output.
UART UART
---- ----

2
boards/arm/ruuvi_ruuvitag/doc/index.rst
View file

@ -149,7 +149,7 @@ Build and flash applications as usual (see :ref:`build_an_application` and
The easiest way to flash Zephyr onto a RuuviTag requires an external Ruuvi DEVKIT. More information about the board can be found at the The easiest way to flash Zephyr onto a RuuviTag requires an external Ruuvi DEVKIT. More information about the board can be found at the
`ruuvitag devkit`_. `ruuvitag devkit`_.
Once your tag is conencted to the DEVKIT and conencted to your PC, build and flash the application in the usual way. Once your tag is connected to the DEVKIT and connected to your PC, build and flash the application in the usual way.
.. zephyr-app-commands:: .. zephyr-app-commands::
:zephyr-app: samples/basic/blinky :zephyr-app: samples/basic/blinky

2
boards/arm/sam_v71_xult/sam_v71_xult-common.dtsi
View file

@ -52,7 +52,7 @@
compatible = "gpio-keys"; compatible = "gpio-keys";
/* The switch is labeled SW300/301 in the schematic, and /* The switch is labeled SW300/301 in the schematic, and
* labeled SW0 on the board, and labeld ERASE User Button * labeled SW0 on the board, and labeled ERASE User Button
* on docs * on docs
*/ */
sw0_user_button: button_1 { sw0_user_button: button_1 {

2
boards/arm/scobc_module1/Kconfig.defconfig
View file

@ -21,4 +21,4 @@ config UART_XLNX_UARTLITE
depends on SERIAL depends on SERIAL
default y default y
endif # BOARD_SCOBC_SPEQ endif # BOARD_SCOBC_MODULE1

2
boards/arm/serpente/doc/index.rst
View file

@ -14,7 +14,7 @@ USB Type-C socket and USB Type-A plug.
.. image:: img/serpente.jpg .. image:: img/serpente.jpg
:width: 640px :width: 640px
:align: center :align: center
:alt: Serpente Baords :alt: Serpente Boards
Hardware Hardware
******** ********

4
boards/arm/stm32f3_disco/doc/index.rst
View file

@ -33,7 +33,7 @@ started quickly. Here are some highlights of the STM32F3DISCOVERY board:
acceleration sensor and a 3D digital magnetic sensor; acceleration sensor and a 3D digital magnetic sensor;
.. HINT:: .. HINT::
Recent PCB revisions (E and newer) are shiped with I3G4250D and LSM303AGR. Recent PCB revisions (E and newer) are shipped with I3G4250D and LSM303AGR.
.. image:: img/stm32f3_disco.jpg .. image:: img/stm32f3_disco.jpg
:width: 350px :width: 350px
@ -194,7 +194,7 @@ CAN
=== ===
The STM32F3DISCOVERY does not have an onboard CAN transceiver. In The STM32F3DISCOVERY does not have an onboard CAN transceiver. In
order to use the CAN bus on the this board, an external CAN bus order to use the CAN bus on the this board, an external CAN bus
tranceiver must be connected to ``PD0`` (``CAN1_RX``) and ``PD1`` transceiver must be connected to ``PD0`` (``CAN1_RX``) and ``PD1``
(``CAN1_TX``). (``CAN1_TX``).
Programming and Debugging Programming and Debugging

2
boards/arm/stm32g071b_disco/stm32g071b_disco.dts
View file

@ -145,7 +145,7 @@
INA230_AVG_MODE_1)>; INA230_AVG_MODE_1)>;
/* Set current LSB to 1mA */ /* Set current LSB to 1mA */
current-lsb = <1>; current-lsb = <1>;
/* Set shunt resistror value to 15 milliohms */ /* Set shunt resistor value to 15 milliohms */
rshunt = <15>; rshunt = <15>;
}; };
}; };

2
boards/arm/stm32h747i_disco/support/openocd_stm32h747i_disco_m7.cfg
View file

@ -5,7 +5,7 @@ transport select hla_swd
source [find target/stm32h7x.cfg] source [find target/stm32h7x.cfg]
# Use connect_assert_srst here to be able to programm # Use connect_assert_srst here to be able to program
# even when core is in sleep mode # even when core is in sleep mode
reset_config srst_only srst_nogate connect_assert_srst reset_config srst_only srst_nogate connect_assert_srst

2
boards/arm/ubx_bmd340eval_nrf52840/doc/index.rst
View file

@ -42,7 +42,7 @@ All of the Nordic Semiconductor examples for the nRF52840 DK
(nrf52840dk_nrf52840) may be used without modification. (nrf52840dk_nrf52840) may be used without modification.
..note:: ..note::
The BMD-340 and BMD-341 are identical except for the antennna. The BMD-340 and BMD-341 are identical except for the antenna.
Throughout this board support package, the filenames utilize Throughout this board support package, the filenames utilize
the ubx_bmd340eval_nrf52840. the ubx_bmd340eval_nrf52840.

2
boards/arm/v2m_beetle/pinmux.c
View file

@ -129,7 +129,7 @@ static void arm_v2m_beetle_pinmux_defaults(void)
/* Set the ARD_PWR_EN GPIO1[15] as an output */ /* Set the ARD_PWR_EN GPIO1[15] as an output */
CMSDK_AHB_GPIO1_DEV->outenableset |= (0x1 << 15); CMSDK_AHB_GPIO1_DEV->outenableset |= (0x1 << 15);
/* Set on 3v3 (for ARDUINO HDR compliancy) */ /* Set on 3v3 (for ARDUINO HDR compliance) */
CMSDK_AHB_GPIO1_DEV->data |= (0x1 << 15); CMSDK_AHB_GPIO1_DEV->data |= (0x1 << 15);
} }

4
boards/arm/v2m_musca_b1/doc/index.rst
View file

@ -365,10 +365,10 @@ For more information refer to the `Srecord Manual`_.
.. code-block:: bash .. code-block:: bash
srec_cat $BIN_BOOLOADER -Binary -offset $FLASH_OFFSET $BIN_SNS -Binary -offset $IMAGE_OFFSET -o $HEX_FLASHABLE -Intel srec_cat $BIN_BOOTLOADER -Binary -offset $FLASH_OFFSET $BIN_SNS -Binary -offset $IMAGE_OFFSET -o $HEX_FLASHABLE -Intel
# For a 128K bootloader IMAGE_OFFSET = $FLASH_OFFSET + 0x20000 # For a 128K bootloader IMAGE_OFFSET = $FLASH_OFFSET + 0x20000
srec_cat $BIN_BOOLOADER -Binary -offset 0xA000000 $BIN_SNS -Binary -offset 0xA020000 -o $HEX_FLASHABLE -Intel srec_cat $BIN_BOOTLOADER -Binary -offset 0xA000000 $BIN_SNS -Binary -offset 0xA020000 -o $HEX_FLASHABLE -Intel
Connect the V2M Musca B1 to your host computer using the USB port. You should Connect the V2M Musca B1 to your host computer using the USB port. You should
see a USB connection exposing a Mass Storage (MUSCA_B) and a USB Serial Port. see a USB connection exposing a Mass Storage (MUSCA_B) and a USB Serial Port.

4
boards/arm/v2m_musca_s1/doc/index.rst
View file

@ -339,10 +339,10 @@ For more information refer to the `Srecord Manual`_.
.. code-block:: bash .. code-block:: bash
srec_cat $BIN_BOOLOADER -Binary -offset $FLASH_OFFSET $BIN_APP -Binary -offset $IMAGE_OFFSET -o zephyr.hex -Intel srec_cat $BIN_BOOTLOADER -Binary -offset $FLASH_OFFSET $BIN_APP -Binary -offset $IMAGE_OFFSET -o zephyr.hex -Intel
# For a 128K bootloader IMAGE_OFFSET = $FLASH_OFFSET + 0x20000 # For a 128K bootloader IMAGE_OFFSET = $FLASH_OFFSET + 0x20000
srec_cat $BIN_BOOLOADER -Binary -offset 0xA000000 $BIN_APP -Binary -offset 0xA020000 -o zephyr.hex -Intel srec_cat $BIN_BOOTLOADER -Binary -offset 0xA000000 $BIN_APP -Binary -offset 0xA020000 -o zephyr.hex -Intel
.. image:: img/v2m_musca_s1_powered.png .. image:: img/v2m_musca_s1_powered.png
:width: 600px :width: 600px

4
boards/posix/native_posix/doc/Port_vs_QEMU_vs.svg generated
View file

@ -184,12 +184,12 @@
<text x="6.95" y="302.06" class="st4" v:langID="6153"><v:paragraph v:horizAlign="1"/><v:tabList/>&#60;1/1000x</text> </g> <text x="6.95" y="302.06" class="st4" v:langID="6153"><v:paragraph v:horizAlign="1"/><v:tabList/>&#60;1/1000x</text> </g>
<g id="shape54-79" v:mID="54" v:groupContext="shape" transform="translate(63.0709,-2.83465)"> <g id="shape54-79" v:mID="54" v:groupContext="shape" transform="translate(63.0709,-2.83465)">
<title>Sheet.54</title> <title>Sheet.54</title>
<desc>ISS: Instruction Set Simulator Dev. boad: Development board H...</desc> <desc>ISS: Instruction Set Simulator Dev. board: Development board H...</desc>
<v:textBlock v:margins="rect(4,4,4,4)" v:tabSpace="42.5197"/> <v:textBlock v:margins="rect(4,4,4,4)" v:tabSpace="42.5197"/>
<v:textRect cx="160.866" cy="280.63" width="321.74" height="51.0236"/> <v:textRect cx="160.866" cy="280.63" width="321.74" height="51.0236"/>
<rect x="0" y="255.118" width="321.732" height="51.0236" class="st3"/> <rect x="0" y="255.118" width="321.732" height="51.0236" class="st3"/>
<text x="4" y="264.13" class="st13" v:langID="6153"><v:paragraph/><v:tabList/>ISS: Instruction Set Simulator<v:newlineChar/><tspan <text x="4" y="264.13" class="st13" v:langID="6153"><v:paragraph/><v:tabList/>ISS: Instruction Set Simulator<v:newlineChar/><tspan
x="4" dy="1.2em" class="st6">Dev</tspan>. boad: Development board<v:newlineChar/><tspan x="4" dy="1.2em" x="4" dy="1.2em" class="st6">Dev</tspan>. board: Development board<v:newlineChar/><tspan x="4" dy="1.2em"
class="st6">HW emu</tspan>. : Hardware emulator, e.g. Cadence Palladium<v:newlineChar/><tspan x="4" class="st6">HW emu</tspan>. : Hardware emulator, e.g. Cadence Palladium<v:newlineChar/><tspan x="4"
dy="1.2em" class="st6">RTL sim</tspan>. : HW RTL simulations</text> </g> dy="1.2em" class="st6">RTL sim</tspan>. : HW RTL simulations</text> </g>
<g id="shape56-85" v:mID="56" v:groupContext="shape" transform="translate(206.362,-124.724)"> <g id="shape56-85" v:mID="56" v:groupContext="shape" transform="translate(206.362,-124.724)">

Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 26 KiB

After

Width:  |  Height:  |  Size: 26 KiB

2
boards/posix/native_posix/native_rtc.c
View file

@ -37,7 +37,7 @@ uint64_t native_rtc_gettime_us(int clock_type)
} }
/** /**
* Similar to POSIX clock_getitme() * Similar to POSIX clock_gettime()
* get the simulation time split in nsec and seconds * get the simulation time split in nsec and seconds
* where clock_type is one of RTC_CLOCK_* * where clock_type is one of RTC_CLOCK_*
*/ */

2
boards/posix/nrf52_bsim/board_soc.h
View file

@ -7,7 +7,7 @@
* @file Extra definitions provided by the board to soc.h * @file Extra definitions provided by the board to soc.h
* *
* Background: * Background:
* The POSIC ARCH/SOC/board layering is different than in normal archs * The POSIX ARCH/SOC/board layering is different than in normal archs
* The "SOC" does not provide almost any of the typical SOC functionality * The "SOC" does not provide almost any of the typical SOC functionality
* but that is left for the "board" to define it * but that is left for the "board" to define it
* Device code may rely on the soc.h defining some things (like the interrupts * Device code may rely on the soc.h defining some things (like the interrupts

2
boards/riscv/it8xxx2_evb/doc/index.rst
View file

@ -30,7 +30,7 @@ Listing the IT81302 hardware features as following:
- 60KB SDRAM in total - 60KB SDRAM in total
- Built-in 32.768 kHz clock generator - Built-in 32.768 kHz clock generator
- PWM, eSPI, LPC, FLASH, UART, GPIO, Timer, Watchdog, ADC, JTAG - PWM, eSPI, LPC, FLASH, UART, GPIO, Timer, Watchdog, ADC, JTAG
- 6 SMBus channels, with 3 DMA controllers, compatiable with I2C - 6 SMBus channels, with 3 DMA controllers, compatible with I2C
- SPI master/slave - SPI master/slave
- USB Type-c CC Logic - USB Type-c CC Logic
- USB Power Delivery - USB Power Delivery

2
boards/riscv/qemu_riscv64/doc/index.rst
View file

@ -20,7 +20,7 @@ Get the Toolchain and QEMU
The minimum version of the `Zephyr SDK tools The minimum version of the `Zephyr SDK tools
<https://github.com/zephyrproject-rtos/sdk-ng/releases>`_ <https://github.com/zephyrproject-rtos/sdk-ng/releases>`_
with toolchain and QEMU support for the RISV64 architecture is v0.10.2. with toolchain and QEMU support for the RISCV64 architecture is v0.10.2.
Please see the :ref:`installation instructions <install-required-tools>` Please see the :ref:`installation instructions <install-required-tools>`
for more details. for more details.

2
boards/riscv/rv32m1_vega/support/openocd_rv32m1_vega_zero_riscy.cfg
View file

@ -48,7 +48,7 @@ flash bank $_CHIPNAME.flash1 rv32m1 0x01000000 0 0 0 $_TARGETNAME # For core 1
proc ri5cy_boot { } { proc ri5cy_boot { } {
# Erase all blok unsecure # Erase all block unsecure
mwb 0x40023000 0x70 mwb 0x40023000 0x70
mww 0x40023004 0x49000000 mww 0x40023004 0x49000000
mwb 0x40023000 0x80 mwb 0x40023000 0x80

2
boards/riscv/tlsr9518adk80d/doc/index.rst
View file

@ -65,7 +65,7 @@ The Zephyr TLSR9518ADK80D board configuration supports the following hardware fe
+----------------+------------+------------------------------+ +----------------+------------+------------------------------+
| PWM | on-chip | pwm | | PWM | on-chip | pwm |
+----------------+------------+------------------------------+ +----------------+------------+------------------------------+
| TRNG | on-chip | entopy | | TRNG | on-chip | entropy |
+----------------+------------+------------------------------+ +----------------+------------+------------------------------+
| FLASH (MSPI) | on-chip | flash | | FLASH (MSPI) | on-chip | flash |
+----------------+------------+------------------------------+ +----------------+------------+------------------------------+

4
boards/shields/atmel_rf2xx/doc/index.rst
View file

@ -131,7 +131,7 @@ Arduino Shields
=============== ===============
Arduino Uno R3 header is available without advanced features. It is enabled Arduino Uno R3 header is available without advanced features. It is enabled
selecting `atmel_rf2xx_arduino`_ variante option. selecting `atmel_rf2xx_arduino`_ variant option.
Pins Assignment of the Arduino Shield Modules Pins Assignment of the Arduino Shield Modules
============================================= =============================================
@ -182,7 +182,7 @@ MikroBus Shields
================ ================
MikroBus header is available available without advanced features. It is MikroBus header is available available without advanced features. It is
enabled selecting `atmel_rf2xx_mikrobus`_ variante option. enabled selecting `atmel_rf2xx_mikrobus`_ variant option.
Pins Assignment of the MikroBus Shield Modules Pins Assignment of the MikroBus Shield Modules
============================================== ==============================================

4
boards/shields/inventek_eswifi/doc/index.rst
View file

@ -7,7 +7,7 @@ Overview
******** ********
The es-WIFI (embedded Serial-to-WiFi) modules are devices developed by Inventek The es-WIFI (embedded Serial-to-WiFi) modules are devices developed by Inventek
Systems. It integrates WIFI and optionaly Bluetooth Low Energy. The es-WIFI Systems. It integrates WIFI and optionally Bluetooth Low Energy. The es-WIFI
devices can run Cypress WICED or Inventek's IWIN (Inventek Systems Wireless devices can run Cypress WICED or Inventek's IWIN (Inventek Systems Wireless
Interoperability Network) AT commands set. The current es-WIFI driver is able Interoperability Network) AT commands set. The current es-WIFI driver is able
to use one of two serial interfaces: SPI or UART. to use one of two serial interfaces: SPI or UART.
@ -48,7 +48,7 @@ The signals from D3 up to D7 are not connected by default on the Inventek's
shield. These signals marked as optional can help on development. The current shield. These signals marked as optional can help on development. The current
driver do not handle that signals and are simple suggestions and can be left driver do not handle that signals and are simple suggestions and can be left
as is. Some arduino boards don't have NRST pin connected to a GPIO pin. The as is. Some arduino boards don't have NRST pin connected to a GPIO pin. The
recomendation is bend the NRST pin and make a wire to D6. WAKE-UP signal is recommendation is bend the NRST pin and make a wire to D6. WAKE-UP signal is
available at header J26 pin 1 and shield configuration uses D7 to control that available at header J26 pin 1 and shield configuration uses D7 to control that
signal, user need do a wire connecting these two terminals. On the below signal, user need do a wire connecting these two terminals. On the below
image is possible see suggested wiring connections. image is possible see suggested wiring connections.

2
boards/shields/ls0xx_generic/doc/index.rst
View file

@ -18,7 +18,7 @@ high during driver initialization. Display blanking apis can be used
to control it. to control it.
Sharp memory displays require toggling the VCOM signal periodically Sharp memory displays require toggling the VCOM signal periodically
to prevent a DC bias ocurring in the panel as mentioned in the `appnote`_ to prevent a DC bias occurring in the panel as mentioned in the `appnote`_
and `datasheet`_. The DC bias can damage the LCD and reduce the life. and `datasheet`_. The DC bias can damage the LCD and reduce the life.
This signal must be supplied from either serial input (sw) or an external This signal must be supplied from either serial input (sw) or an external
signal on the EXTCOMIN pin. signal on the EXTCOMIN pin.

4
boards/shields/mcp2515/doc/index.rst
View file

@ -12,7 +12,7 @@ DFRobot CAN BUS Shield V2.0
Overview Overview
-------- --------
The DFRobot CAN BUS shield supports the Microship MCP2515 stand-alone CAN The DFRobot CAN BUS shield supports the Microchip MCP2515 stand-alone CAN
controller and JTA1050 high speed CAN transceiver. The shield has an Arduino controller and JTA1050 high speed CAN transceiver. The shield has an Arduino
Uno R3 compatible hardware interface. Uno R3 compatible hardware interface.
@ -122,7 +122,7 @@ Keyestudio CAN-BUS Shield (KS0411)
Overview Overview
-------- --------
The Keyestudio CAN BUS shield supports the Microship MCP2515 stand-alone CAN The Keyestudio CAN BUS shield supports the Microchip MCP2515 stand-alone CAN
controller and MCP2551 high speed CAN transceiver. The shield has an Arduino controller and MCP2551 high speed CAN transceiver. The shield has an Arduino
Uno R3 compatible hardware interface. Uno R3 compatible hardware interface.

2
boards/shields/x_nucleo_eeprma2/doc/index.rst
View file

@ -54,7 +54,7 @@ Samples
The :ref:`samples_eeprom` can be used to demonstrate the expansion boards The :ref:`samples_eeprom` can be used to demonstrate the expansion boards
functionality. functionality.
Per default the shield sets an ``eeprom-0`` alias for the M24C02-FMC6TG EEPROM, Per default the shield sets an ``eeprom-0`` alias for the M24C02-FMC6TG EEPROM,
which can be overwritten to use the other EEPROM deivces instead. which can be overwritten to use the other EEPROM devices instead.
Programming Programming
*********** ***********

2
boards/shields/x_nucleo_idb05a1/doc/index.rst
View file

@ -38,7 +38,7 @@ This is not a problem if SPI SCK from nucleo board is available on D3,
otherwise shield configuration can be changed (see below). otherwise shield configuration can be changed (see below).
Also shield expects SPI CS to be available on Arduino pin A1 instead of usual Also shield expects SPI CS to be available on Arduino pin A1 instead of usual
Arduino UNO R3 SPI CS D10. Arduino UNO R3 SPI CS D10.
This is not a problem as CS signal is software driven gpio on Arnunio A1 This is not a problem as CS signal is software driven gpio on Arduino A1
see cs-gpios in x_nucleo_idb05a1.overlay see cs-gpios in x_nucleo_idb05a1.overlay
Shield configuration could be modified by moving resistors as Shield configuration could be modified by moving resistors as

2
boards/x86/acrn/doc/index.rst
View file

@ -66,7 +66,7 @@ configuration files instead of small easily-merged configuration
elements like kconfig defconfig files or devicetree includes. You elements like kconfig defconfig files or devicetree includes. You
have to edit a big XML file to match your Zephyr configuration. have to edit a big XML file to match your Zephyr configuration.
Choose an ACRN host config that matches your hardware ("ehl-crb-b" in Choose an ACRN host config that matches your hardware ("ehl-crb-b" in
this case). Then find the relavent file in this case). Then find the relevant file in
``misc/config_tools/data/<platform>/hybrid.xml``. ``misc/config_tools/data/<platform>/hybrid.xml``.
First, find the list of ``<vm>`` declarations. Each has an ``id=`` First, find the list of ``<vm>`` declarations. Each has an ``id=``

2
boards/x86/qemu_x86/doc/index.rst
View file

@ -115,7 +115,7 @@ Exit QEMU by pressing :kbd:`CTRL+A` :kbd:`x`.
For qemu_x86_64 platform, it also supports to use UEFI bootable method For qemu_x86_64 platform, it also supports to use UEFI bootable method
to run Zephyr applications and kernel tests, but you need to set up to run Zephyr applications and kernel tests, but you need to set up
some environemnt configurations as follows: some environment configurations as follows:
* Please install uefi-run in your system environment according to this * Please install uefi-run in your system environment according to this
reference link https://github.com/Richard-W/uefi-run. reference link https://github.com/Richard-W/uefi-run.

4
boards/xtensa/intel_adsp_cavs25/doc/index.rst
View file

@ -95,7 +95,7 @@ Next you disable the validation step:
**THIS COMMAND WILL FAIL**, give you an error that you are changing **THIS COMMAND WILL FAIL**, give you an error that you are changing
the setting for the entire running system, and suggest an alternative the setting for the entire running system, and suggest an alternative
"--paritions X" argument to use that modifies only the currently used "--partitions X" argument to use that modifies only the currently used
partition. Run that modified command, then reboot. partition. Run that modified command, then reboot.
After rebooting, you will notice that your chromebook boots with the After rebooting, you will notice that your chromebook boots with the
@ -110,7 +110,7 @@ verity configuration in place though, it just doesn't try to mount the
resulting (now-invalid!) partition. resulting (now-invalid!) partition.
Metanote: The astute will note that we're probably going to throw this Metanote: The astute will note that we're probably going to throw this
kernel out, and that we could probably have just editted the command kernel out, and that we could probably have just edited the command
line of the new kernel instead of flashing and rebooting into this line of the new kernel instead of flashing and rebooting into this
modified one. But that's too many balls to juggle at once for me. modified one. But that's too many balls to juggle at once for me.

2
boards/xtensa/intel_s1000_crb/support/download.py
View file

@ -33,7 +33,7 @@ def calc_firmware_sha(file):
""" """
Open firmware image file and calculate file size Open firmware image file and calculate file size
Pad file size to a multiple of 64 bytes Pad file size to a multiple of 64 bytes
Caculate SHA256 hash of the padded contents Calculate SHA256 hash of the padded contents
""" """
with open(file, 'rb') as firmware: with open(file, 'rb') as firmware:
firmware.seek(0, 2) firmware.seek(0, 2)

8
boards/xtensa/intel_s1000_crb/support/messenger.py
View file

@ -33,15 +33,15 @@ class Message:
def __init__(self): def __init__(self):
""" """
Intialize a byte array of 64 bytes for command messages Initialize a byte array of 64 bytes for command messages
Intialize another byte array of 4096 bytes for bulk messages Initialize another byte array of 4096 bytes for bulk messages
""" """
self.tx_data = bytearray(64) self.tx_data = bytearray(64)
self.tx_bulk_data = bytearray(4096) self.tx_bulk_data = bytearray(4096)
def init_tx_data(self): def init_tx_data(self):
""" """
Intialize transmit message buffers to zeros Initialize transmit message buffers to zeros
""" """
for index in range(len(self.tx_data)): for index in range(len(self.tx_data)):
self.tx_data[index] = 0 self.tx_data[index] = 0
@ -194,7 +194,7 @@ class Message:
def create_execfw_cmd(self): def create_execfw_cmd(self):
""" """
Creates a command to excute firmware Creates a command to execute firmware
""" """
cmd = 'Execute' cmd = 'Execute'
print('CMD >>> %s.' % cmd) print('CMD >>> %s.' % cmd)

2
cmake/bintools/arcmwdt/target.cmake
View file

@ -20,7 +20,7 @@ SET(CMAKE_C_ARCHIVE_FINISH "<CMAKE_AR> -sq <TARGET>")
find_program(CMAKE_GDB ${CROSS_COMPILE}mdb PATH ${TOOLCHAIN_HOME} NO_DEFAULT_PATH) find_program(CMAKE_GDB ${CROSS_COMPILE}mdb PATH ${TOOLCHAIN_HOME} NO_DEFAULT_PATH)
# MWDT binutils don't support required features like section renameing, so we # MWDT binutils don't support required features like section renaming, so we
# temporarily had to use GNU objcopy instead # temporarily had to use GNU objcopy instead
find_program(CMAKE_OBJCOPY arc-elf32-objcopy) find_program(CMAKE_OBJCOPY arc-elf32-objcopy)
if (NOT CMAKE_OBJCOPY) if (NOT CMAKE_OBJCOPY)

2
cmake/bintools/arcmwdt/target_bintools.cmake
View file

@ -6,7 +6,7 @@ set_property(TARGET bintools PROPERTY memusage_infile "")
# List of format the tool supports for converting, for example, # List of format the tool supports for converting, for example,
# GNU tools uses objectcopyy, which supports the following: ihex, srec, binary # GNU tools uses objectcopy, which supports the following: ihex, srec, binary
set_property(TARGET bintools PROPERTY elfconvert_formats ihex srec binary) set_property(TARGET bintools PROPERTY elfconvert_formats ihex srec binary)
# MWDT toolchain does not support all options in a single command # MWDT toolchain does not support all options in a single command

2
cmake/bintools/armclang/target_bintools.cmake
View file

@ -1,5 +1,5 @@
# List of format the tool supports for converting, for example, # List of format the tool supports for converting, for example,
# GNU tools uses objectcopyy, which supports the following: ihex, srec, binary # GNU tools uses objectcopy, which supports the following: ihex, srec, binary
set_property(TARGET bintools PROPERTY elfconvert_formats ihex binary) set_property(TARGET bintools PROPERTY elfconvert_formats ihex binary)
# armclang toolchain does not support all options in a single command # armclang toolchain does not support all options in a single command

2
cmake/bintools/gnu/target_bintools.cmake
View file

@ -25,7 +25,7 @@
set_property(TARGET bintools PROPERTY elfconvert_command ${CMAKE_OBJCOPY}) set_property(TARGET bintools PROPERTY elfconvert_command ${CMAKE_OBJCOPY})
# List of format the tool supports for converting, for example, # List of format the tool supports for converting, for example,
# GNU tools uses objectcopyy, which supports the following: ihex, srec, binary # GNU tools uses objectcopy, which supports the following: ihex, srec, binary
set_property(TARGET bintools PROPERTY elfconvert_formats ihex srec binary) set_property(TARGET bintools PROPERTY elfconvert_formats ihex srec binary)
set_property(TARGET bintools PROPERTY elfconvert_flag "") set_property(TARGET bintools PROPERTY elfconvert_flag "")

2
cmake/bintools/llvm/target_bintools.cmake
View file

@ -25,7 +25,7 @@
set_property(TARGET bintools PROPERTY elfconvert_command ${CMAKE_OBJCOPY}) set_property(TARGET bintools PROPERTY elfconvert_command ${CMAKE_OBJCOPY})
# List of format the tool supports for converting, for example, # List of format the tool supports for converting, for example,
# GNU tools uses objectcopyy, which supports the following: ihex, srec, binary # GNU tools uses objectcopy, which supports the following: ihex, srec, binary
set_property(TARGET bintools PROPERTY elfconvert_formats ihex srec binary) set_property(TARGET bintools PROPERTY elfconvert_formats ihex srec binary)
set_property(TARGET bintools PROPERTY elfconvert_flag "") set_property(TARGET bintools PROPERTY elfconvert_flag "")

2
cmake/compiler/arcmwdt/target.cmake
View file

@ -35,7 +35,7 @@ endif()
# link a dummy C file. # link a dummy C file.
# #
# CMake checks compiler flags with check_c_compiler_flag() (Which we # CMake checks compiler flags with check_c_compiler_flag() (Which we
# wrap with target_cc_option() in extentions.cmake) # wrap with target_cc_option() in extensions.cmake)
foreach(isystem_include_dir ${NOSTDINC}) foreach(isystem_include_dir ${NOSTDINC})
list(APPEND isystem_include_flags -isystem "\"${isystem_include_dir}\"") list(APPEND isystem_include_flags -isystem "\"${isystem_include_dir}\"")
endforeach() endforeach()

2
cmake/compiler/xcc/target.cmake
View file

@ -51,7 +51,7 @@ list(APPEND TOOLCHAIN_LIBS
# link a dummy C file. # link a dummy C file.
# #
# CMake checks compiler flags with check_c_compiler_flag() (Which we # CMake checks compiler flags with check_c_compiler_flag() (Which we
# wrap with target_cc_option() in extentions.cmake) # wrap with target_cc_option() in extensions.cmake)
foreach(isystem_include_dir ${NOSTDINC}) foreach(isystem_include_dir ${NOSTDINC})
list(APPEND isystem_include_flags -isystem "\"${isystem_include_dir}\"") list(APPEND isystem_include_flags -isystem "\"${isystem_include_dir}\"")
endforeach() endforeach()

2
cmake/linker/arcmwdt/target.cmake
View file

@ -172,7 +172,7 @@ macro(toolchain_ld_base)
) )
endmacro() endmacro()
# generate linker script snippts from configure files # generate linker script snippets from configure files
macro(toolchain_ld_configure_files) macro(toolchain_ld_configure_files)
configure_file( configure_file(
$ENV{ZEPHYR_BASE}/include/arch/common/app_data_alignment.ld $ENV{ZEPHYR_BASE}/include/arch/common/app_data_alignment.ld

2
cmake/linker/armlink/scatter_script.cmake
View file

@ -333,7 +333,7 @@ function(section_to_string)
# endif() # endif()
#if(SETTINGS_KEEP) #if(SETTINGS_KEEP)
# armlink has --keep=<section_id>, but is there an scatter equivalant ? # armlink has --keep=<section_id>, but is there an scatter equivalent ?
#endif() #endif()
if(first) if(first)

4
cmake/linker/armlink/target.cmake
View file

@ -94,8 +94,8 @@ function(toolchain_ld_link_elf)
# The scatter file is generated, and thus sometimes input sections are specified # The scatter file is generated, and thus sometimes input sections are specified
# even though there will be no such sections found in the libraries linked. # even though there will be no such sections found in the libraries linked.
--diag_suppress=6314 --diag_suppress=6314
# We use empty excution sections in order to define custom symbols, such as # We use empty execution sections in order to define custom symbols, such as
# __kernel_ram_x symbols, but nothing will go in those section, so silnence # __kernel_ram_x symbols, but nothing will go in those section, so silence
# the warning. Note, marking the section EMPTY causes armlink to reserve the # the warning. Note, marking the section EMPTY causes armlink to reserve the
# address which in some cases leads to overlapping section errors. # address which in some cases leads to overlapping section errors.
--diag_suppress=6312 --diag_suppress=6312

2
cmake/modules/configuration_files.cmake
View file

@ -81,7 +81,7 @@ set(APPLICATION_CONFIG_DIR ${APPLICATION_CONFIG_DIR} CACHE INTERNAL "The applica
set(CACHED_CONF_FILE ${CONF_FILE} CACHE STRING "If desired, you can build the application using\ set(CACHED_CONF_FILE ${CONF_FILE} CACHE STRING "If desired, you can build the application using\
the configuration settings specified in an alternate .conf file using this parameter. \ the configuration settings specified in an alternate .conf file using this parameter. \
These settings will override the settings in the application’s .config file or its default .conf file.\ These settings will override the settings in the application’s .config file or its default .conf file.\
Multiple files may be listed, e.g. CONF_FILE=\"prj1.confi;prj2.conf\" \ Multiple files may be listed, e.g. CONF_FILE=\"prj1.conf;prj2.conf\" \
The CACHED_CONF_FILE is internal Zephyr variable used between CMake runs. \ The CACHED_CONF_FILE is internal Zephyr variable used between CMake runs. \
To change CONF_FILE, use the CONF_FILE variable.") To change CONF_FILE, use the CONF_FILE variable.")
unset(CONF_FILE CACHE) unset(CONF_FILE CACHE)

2
cmake/modules/extensions.cmake
View file

@ -2618,7 +2618,7 @@ function(dt_node_exists var)
cmake_parse_arguments(DT_NODE "" "${req_single_args}" "" ${ARGN}) cmake_parse_arguments(DT_NODE "" "${req_single_args}" "" ${ARGN})
if(${ARGV0} IN_LIST req_single_args) if(${ARGV0} IN_LIST req_single_args)
message(FATAL_ERROR "dt_node_existsl(${ARGV0} ...) missing return parameter.") message(FATAL_ERROR "dt_node_exists(${ARGV0} ...) missing return parameter.")
endif() endif()
foreach(arg ${req_single_args}) foreach(arg ${req_single_args})

6
cmake/modules/kernel.cmake
View file

@ -4,8 +4,8 @@
# Zephyr Kernel CMake module. # Zephyr Kernel CMake module.
# #
# This is the main Zephyr Kernel CMake module which is resposible for creation # This is the main Zephyr Kernel CMake module which is responsible for creation
# of Zephyr libraries and the Zephyr executeable. # of Zephyr libraries and the Zephyr executable.
# #
# This CMake module creates 'project(Zephyr-Kernel)' # This CMake module creates 'project(Zephyr-Kernel)'
# #
@ -125,7 +125,7 @@ set(CMAKE_EXPORT_COMPILE_COMMANDS TRUE CACHE BOOL
project(Zephyr-Kernel VERSION ${PROJECT_VERSION}) project(Zephyr-Kernel VERSION ${PROJECT_VERSION})
# Add .S file extension suffix into CMAKE_ASM_SOURCE_FILE_EXTENSIONS, # Add .S file extension suffix into CMAKE_ASM_SOURCE_FILE_EXTENSIONS,
# because clang from OneApi can't recongnize them as asm files on # because clang from OneApi can't recognize them as asm files on
# windows now. # windows now.
list(APPEND CMAKE_ASM_SOURCE_FILE_EXTENSIONS "S") list(APPEND CMAKE_ASM_SOURCE_FILE_EXTENSIONS "S")
enable_language(C CXX ASM) enable_language(C CXX ASM)

2
cmake/modules/shields.cmake
View file

@ -112,7 +112,7 @@ foreach(root ${BOARD_ROOT})
endforeach() endforeach()
# Prepare shield usage command printing. # Prepare shield usage command printing.
# This command prints all ishield in the system in the following cases: # This command prints all shields in the system in the following cases:
# - User specifies an invalid SHIELD # - User specifies an invalid SHIELD
# - User invokes '<build-command> shields' target # - User invokes '<build-command> shields' target
list(SORT SHIELD_LIST) list(SORT SHIELD_LIST)

2
doc/_doxygen/doxygen-awesome-sidebar-only.css
View file

@ -29,7 +29,7 @@ SOFTWARE.
html { html {
/* side nav width. MUST be = `TREEVIEW_WIDTH`. /* side nav width. MUST be = `TREEVIEW_WIDTH`.
* Make sure it is wide enought to contain the page title (logo + title + version) * Make sure it is wide enough to contain the page title (logo + title + version)
*/ */
--side-nav-fixed-width: 340px; --side-nav-fixed-width: 340px;
--menu-display: none; --menu-display: none;

2
doc/_doxygen/doxygen-awesome.css
View file

@ -48,7 +48,7 @@ html {
--border-radius-small: 4px; --border-radius-small: 4px;
--border-radius-medium: 6px; --border-radius-medium: 6px;
/* default spacings. Most compontest reference these values for spacing, to provide uniform spacing on the page. */ /* default spacings. Most components reference these values for spacing, to provide uniform spacing on the page. */
--spacing-small: 5px; --spacing-small: 5px;
--spacing-medium: 10px; --spacing-medium: 10px;
--spacing-large: 16px; --spacing-large: 16px;

4
doc/_extensions/zephyr/external_content.py
View file

@ -14,7 +14,7 @@ build. Note that the copy is *smart*, that is, only updated files are actually
copied. Therefore, incremental builds detect changes correctly and behave as copied. Therefore, incremental builds detect changes correctly and behave as
expected. expected.
Paths for external content ingluded via e.g. figure, literalinclude, etc. Paths for external content included via e.g. figure, literalinclude, etc.
are adjusted as needed. are adjusted as needed.
Configuration options Configuration options
@ -93,7 +93,7 @@ def adjust_includes(
def sync_contents(app: Sphinx) -> None: def sync_contents(app: Sphinx) -> None:
"""Synhronize external contents. """Synchronize external contents.
Args: Args:
app: Sphinx application instance. app: Sphinx application instance.

4
doc/_scripts/gen_devicetree_rest.py
View file

@ -395,7 +395,7 @@ def write_orphans(bindings, base_binding, vnd_lookup, out_dir):
# Next, write the per-binding pages. These contain the # Next, write the per-binding pages. These contain the
# per-compatible targets for compatibles not in 'dup_compats'. # per-compatible targets for compatibles not in 'dup_compats'.
# We'll finish up by writing per-compatible "disambiguation" pages # We'll finish up by writing per-compatible "disambiguation" pages
# for copmatibles in 'dup_compats'. # for compatibles in 'dup_compats'.
# Names of properties in base.yaml. # Names of properties in base.yaml.
base_names = set(base_binding.prop2specs.keys()) base_names = set(base_binding.prop2specs.keys())
@ -677,7 +677,7 @@ def print_property_table(prop_specs, string_io, deprecated=False):
def setup_compatibles_dir(compatibles, compatibles_dir): def setup_compatibles_dir(compatibles, compatibles_dir):
# Make a set of all the Path objects we will be creating for # Make a set of all the Path objects we will be creating for
# out_dir / copmatibles / {compatible_path}.rst. Delete all the ones that # out_dir / compatibles / {compatible_path}.rst. Delete all the ones that
# shouldn't be there. Make sure the compatibles output directory # shouldn't be there. Make sure the compatibles output directory
# exists. # exists.

4
doc/application/index.rst
View file

@ -227,7 +227,7 @@ Zephyr.)
target_sources(app PRIVATE src/main.c) target_sources(app PRIVATE src/main.c)
``cmake_minimum_required()`` is required to be in your ``cmake_minimum_required()`` is required to be in your
:file:`CMakeListst.txt` by CMake. It is also invoked by the Zephyr :file:`CMakeLists.txt` by CMake. It is also invoked by the Zephyr
package. The most recent of the two versions will be enforced by CMake. package. The most recent of the two versions will be enforced by CMake.
``find_package(Zephyr)`` pulls in the Zephyr build system, which creates a ``find_package(Zephyr)`` pulls in the Zephyr build system, which creates a
@ -534,7 +534,7 @@ at CMake configure time if any experimental feature is enabled.
CONFIG_WARN_EXPERIMENTAL=y CONFIG_WARN_EXPERIMENTAL=y
For example, if option ``CONFIG_FOO`` is experimental, then enabling it and For example, if option ``CONFIG_FOO`` is experimental, then enabling it and
:kconfig:option:`CONIG_WARN_EXPERIMENTAL` will print the following warning at :kconfig:option:`CONFIG_WARN_EXPERIMENTAL` will print the following warning at
CMake configure time when you build an application: CMake configure time when you build an application:
.. code-block:: none .. code-block:: none

4
doc/contribute/coding_guidelines/index.rst
View file

@ -38,7 +38,7 @@ Main rules
The coding guideline rules are based on MISRA-C 2012 and are a subset of MISRA-C. The coding guideline rules are based on MISRA-C 2012 and are a subset of MISRA-C.
The subset is listed in the table below with a summary of the rules, its The subset is listed in the table below with a summary of the rules, its
severity and the equivlent rules from other standards for reference. severity and the equivalent rules from other standards for reference.
.. note:: .. note::
@ -368,7 +368,7 @@ severity and the equivlent rules from other standards for reference.
- `Rule 10.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_10_02.c>`_ - `Rule 10.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_10_02.c>`_
* - Rule 10.3 * - Rule 10.3
- Required - Required
- The value of an expression shall not be assigned to an object with a narrower essential type or of a dierent essential type category - The value of an expression shall not be assigned to an object with a narrower essential type or of a different essential type category
- `STR04-C <https://wiki.sei.cmu.edu/confluence/display/c/STR04-C.+Use+plain+char+for+characters+in+the+basic+character+set>`_ - `STR04-C <https://wiki.sei.cmu.edu/confluence/display/c/STR04-C.+Use+plain+char+for+characters+in+the+basic+character+set>`_
- `Rule 10.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_10_03.c>`_ - `Rule 10.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_10_03.c>`_
* - Rule 10.4 * - Rule 10.4

2
doc/development_process/dev_env_and_tools.rst
View file

@ -230,7 +230,7 @@ The CI infrastructure currently runs the following tests:
IOPCTL_Type *base = config->base; IOPCTL_Type *base = config->base;
Both lines produce a diagnostic regarding spaces around the ``*`` Both lines produce a diagnostic regarding spaces around the ``*``
operator: the first is misidentifed as a pointer type declaration operator: the first is misidentified as a pointer type declaration
that would be correct as ``PAGE_SIZE *POOL_PAGES`` while the second that would be correct as ``PAGE_SIZE *POOL_PAGES`` while the second
is misidentified as a multiplication expression that would be correct is misidentified as a multiplication expression that would be correct
as ``IOPCTL_Type * base``. as ``IOPCTL_Type * base``.

2
doc/development_process/issues.rst
View file

@ -30,7 +30,7 @@ For this, `git bisect`_ is the recommended tool.
Recommendations on the process: Recommendations on the process:
* Run ``west update`` on each bisection step. * Run ``west update`` on each bisection step.
* Once the bisection is over and a culprit identifed, verify manually the result. * Once the bisection is over and a culprit identified, verify manually the result.
.. _git bisect: .. _git bisect:
https://git-scm.com/docs/git-bisect https://git-scm.com/docs/git-bisect

6
doc/development_process/release_process.rst
View file

@ -116,7 +116,7 @@ gate the final release. The following counts shall be used:
.. note:: .. note::
The "low" bug count target of <50 will be a phased appoach starting with 150 The "low" bug count target of <50 will be a phased approach starting with 150
for release 2.4.0, 100 for release 2.5.0, and 50 for release 2.6.0 for release 2.4.0, 100 for release 2.5.0, and 50 for release 2.6.0
@ -174,7 +174,7 @@ security fixes.
An LTS includes both mature and new features. API and feature maturity is An LTS includes both mature and new features. API and feature maturity is
documented and tracked. The footprint and scope of mature and stable APIs expands documented and tracked. The footprint and scope of mature and stable APIs expands
as we move from one LTS to the next giving users access to bleading edge features as we move from one LTS to the next giving users access to bleeding edge features
and new hardware while keeping a stable foundation that evolves over time. and new hardware while keeping a stable foundation that evolves over time.
Extended Stabilisation Period Extended Stabilisation Period
@ -228,7 +228,7 @@ providing a quality oriented releases. This is achieved by providing the
following products to track progress, integrity and quality of the software following products to track progress, integrity and quality of the software
components provided by the project: components provided by the project:
- Compliance with pubished coding guidelines, style guides and naming - Compliance with published coding guidelines, style guides and naming
conventions and documentation of deviations. conventions and documentation of deviations.
- Regular static analysis on the complete tree using available commercial and - Regular static analysis on the complete tree using available commercial and
open-source tools and documentation of deviations and false positives. open-source tools and documentation of deviations and false positives.

12
doc/guides/arch/arm_cortex_m.rst
View file

@ -113,7 +113,7 @@ stack pointer manipulation* during thread context switching, without affecting t
handler mode. handler mode.
In Arm Cortex-M builds a single interrupt stack memory is shared among exceptions and interrupts. The size of the interrupt stack needs In Arm Cortex-M builds a single interrupt stack memory is shared among exceptions and interrupts. The size of the interrupt stack needs
to be selected taking into consideration nested interrupts, each pushing an additional stack frame. Deverlopers can modify the interrupt to be selected taking into consideration nested interrupts, each pushing an additional stack frame. Developers can modify the interrupt
stack size using :kconfig:option:`CONFIG_ISR_STACK_SIZE`. stack size using :kconfig:option:`CONFIG_ISR_STACK_SIZE`.
The interrupt stack is also used during early boot so the kernel can initialize the main thread's stack before switching to the main thread. The interrupt stack is also used during early boot so the kernel can initialize the main thread's stack before switching to the main thread.
@ -141,7 +141,7 @@ Typically a thread context-switch will perform the following operations
* the thread's current operation *mode* * the thread's current operation *mode*
* user or privileged execution mode * user or privileged execution mode
* presense of an active floating point context * presence of an active floating point context
* the EXC_RETURN value of the current handler context (PendSV) * the EXC_RETURN value of the current handler context (PendSV)
* the floating point callee-saved registers (S16 - S31) in the thread's container for FP * the floating point callee-saved registers (S16 - S31) in the thread's container for FP
@ -233,7 +233,7 @@ this rule is described below). As a result, processor faults occurring in regula
ISRs will be handled by the corresponding fault handler and will not escalate to ISRs will be handled by the corresponding fault handler and will not escalate to
a HardFault, *similar to processor faults occurring in thread mode*. a HardFault, *similar to processor faults occurring in thread mode*.
SVC exception is normally configured with the highest conigurable priority level SVC exception is normally configured with the highest configurable priority level
(an exception to this rule will be described below). (an exception to this rule will be described below).
SVCs are used by the Zephyr kernel to dispatch system calls, trigger runtime SVCs are used by the Zephyr kernel to dispatch system calls, trigger runtime
system errors (e.g. Kernel oops or panic), or implement IRQ offloading. system errors (e.g. Kernel oops or panic), or implement IRQ offloading.
@ -469,7 +469,7 @@ Certain thread-specific MPU regions may be re-programmed dynamically, at each th
* an unprivileged RW region for the current thread's stack area (for user threads) * an unprivileged RW region for the current thread's stack area (for user threads)
* a read-only region for the MPU stack guard * a read-only region for the MPU stack guard
* unprivileged RW regions for the partitions of the currentl thread's application memory * unprivileged RW regions for the partitions of the current thread's application memory
domain. domain.
@ -489,7 +489,7 @@ overlap. :kconfig:option:`CONFIG_MPU_GAP_FILLING` controls whether the fixed MPU
covering the entire SRAM is programmed. When it does, a full SRAM area partitioning covering the entire SRAM is programmed. When it does, a full SRAM area partitioning
is required, in order to program the static and the dynamic MPU regions. This increases is required, in order to program the static and the dynamic MPU regions. This increases
the total number of required MPU regions. When :kconfig:option:`CONFIG_MPU_GAP_FILLING` is not the total number of required MPU regions. When :kconfig:option:`CONFIG_MPU_GAP_FILLING` is not
enabled the fixed MPU region convering the entire SRAM is not programmed, thus, the static enabled the fixed MPU region covering the entire SRAM is not programmed, thus, the static
and dynamic regions are simply programmed on top of the always-existing background region and dynamic regions are simply programmed on top of the always-existing background region
(full-SRAM partitioning is not required). (full-SRAM partitioning is not required).
Note, however, that the background SRAM region allows execution from SRAM, so when Note, however, that the background SRAM region allows execution from SRAM, so when
@ -562,7 +562,7 @@ of the image vector table.
Baseline Cortex-M platforms without VTOR register might not be able to relocate their Baseline Cortex-M platforms without VTOR register might not be able to relocate their
vector table which remains at a fixed location. Therefore, a chain-loadable image will vector table which remains at a fixed location. Therefore, a chain-loadable image will
require an alternative way to route HW interrupts and system exeptions to its own vector require an alternative way to route HW interrupts and system exceptions to its own vector
table; this is achieved with software vector relaying. table; this is achieved with software vector relaying.
When a bootloader image enables :kconfig:option:`CONFIG_SW_VECTOR_RELAY` When a bootloader image enables :kconfig:option:`CONFIG_SW_VECTOR_RELAY`

4
doc/guides/arch/x86.rst
View file

@ -26,7 +26,7 @@ is being placed in the memory, and its counterpart
Separate Virtual Address Space from Physical Address Space Separate Virtual Address Space from Physical Address Space
========================================================== ==========================================================
On 32-bit x86, it is possible to have separate phyiscal and virtual On 32-bit x86, it is possible to have separate physical and virtual
address space. Code and data are linked in virtual address space, address space. Code and data are linked in virtual address space,
but are still loaded in physical memory. However, during boot, code but are still loaded in physical memory. However, during boot, code
and data must be available and also addressable in physical address and data must be available and also addressable in physical address
@ -92,7 +92,7 @@ in the board configuration file. Here is an example:
--map 0x80000000,0x400000,LWUX,0xB0000000) --map 0x80000000,0x400000,LWUX,0xB0000000)
The argument ``--map`` takes the following value: The argument ``--map`` takes the following value:
``<physical address>,<size>[,<flags:LUWX>[,<virtual adderss>]]``, where: ``<physical address>,<size>[,<flags:LUWX>[,<virtual address>]]``, where:
- ``<physical address>`` is the physical address of the mapping. (Required) - ``<physical address>`` is the physical address of the mapping. (Required)

2
doc/guides/bluetooth/autopts/autopts-win10.rst
View file

@ -321,7 +321,7 @@ then build and flash tester elf again.
- Check if board sends ready event after restart (hex 00 00 80 ff 00 00). Open serial connection to board with e.g. PuTTy with proper COM and baud rate. After board reset you should see some strings in console. - Check if board sends ready event after restart (hex 00 00 80 ff 00 00). Open serial connection to board with e.g. PuTTy with proper COM and baud rate. After board reset you should see some strings in console.
- Check if socat.exe creates tunel to board. Run in console - Check if socat.exe creates tunnel to board. Run in console
.. code-block:: .. code-block::

2
doc/guides/bluetooth/l2cap-pics.rst
View file

@ -108,7 +108,7 @@ TSPC_L2CAP_3_7 False Support of bi-directional quality of service (QoS) opti
TSPC_L2CAP_3_8 False Negotiate QoS service type (C.5) TSPC_L2CAP_3_8 False Negotiate QoS service type (C.5)
TSPC_L2CAP_3_9 False Negotiate and support service type 'No Traffic' (C.2) TSPC_L2CAP_3_9 False Negotiate and support service type 'No Traffic' (C.2)
TSPC_L2CAP_3_10 False Negotiate and support service type 'Best effort' (C.3) TSPC_L2CAP_3_10 False Negotiate and support service type 'Best effort' (C.3)
TSPC_L2CAP_3_11 False Negotiate and support service type 'Gauranteed' (C.2) TSPC_L2CAP_3_11 False Negotiate and support service type 'Guaranteed' (C.2)
TSPC_L2CAP_3_12 True Support minimum MTU size 23 octets (C.6) TSPC_L2CAP_3_12 True Support minimum MTU size 23 octets (C.6)
TSPC_L2CAP_3_13 False Negotiate and support service type ‘No traffic’ for Extended Flow Specification (C.7) TSPC_L2CAP_3_13 False Negotiate and support service type ‘No traffic’ for Extended Flow Specification (C.7)
TSPC_L2CAP_3_14 False Negotiate and support service type ‘Best Effort’ for Extended Flow Specification (C.8) TSPC_L2CAP_3_14 False Negotiate and support service type ‘Best Effort’ for Extended Flow Specification (C.8)

2
doc/guides/build/index.rst
View file

@ -452,5 +452,5 @@ tips and best practices for writing :file:`Kconfig` files.
kconfig/preprocessor-functions.rst kconfig/preprocessor-functions.rst
kconfig/extensions.rst kconfig/extensions.rst
Users interested in optimizing their configuraion for security should refer Users interested in optimizing their configuration for security should refer
to the Zephyr Security Guide's section on the :ref:`hardening`. to the Zephyr Security Guide's section on the :ref:`hardening`.

6
doc/guides/debug_tools/coredump.rst
View file

@ -257,7 +257,7 @@ to the target architecture (e.g. CPU registers)
- Description - Description
* - ID * - ID
- ``char`` - ``char``
- ``A`` to indiciate this is a architecture-specific block. - ``A`` to indicate this is a architecture-specific block.
* - Header version * - Header version
- ``uint16_t`` - ``uint16_t``
- Identify the version of this block. To be interpreted by the target - Identify the version of this block. To be interpreted by the target
@ -286,7 +286,7 @@ the memory region.
- Description - Description
* - ID * - ID
- ``char`` - ``char``
- ``M`` to indiciate this is a memory block. - ``M`` to indicate this is a memory block.
* - Header version * - Header version
- ``uint16_t`` - ``uint16_t``
- Identify the version of the header. This needs to be incremented - Identify the version of the header. This needs to be incremented
@ -313,7 +313,7 @@ the following needs to be done:
#. Add a new target code to the ``enum coredump_tgt_code`` in #. Add a new target code to the ``enum coredump_tgt_code`` in
:zephyr_file:`include/debug/coredump.h`. :zephyr_file:`include/debug/coredump.h`.
#. Implement :c:func:`arch_coredump_tgt_code_get` simply to return #. Implement :c:func:`arch_coredump_tgt_code_get` simply to return
the newly introducted target code. the newly introduced target code.
#. Implement :c:func:`arch_coredump_info_dump` to construct #. Implement :c:func:`arch_coredump_info_dump` to construct
a target architecture block and call :c:func:`coredump_buffer_output` a target architecture block and call :c:func:`coredump_buffer_output`
to output the block to core dump backend. to output the block to core dump backend.

Some files were not shown because too many files have changed in this diff Show more