everywhere: fix typos
Fix a lot of typos Signed-off-by: Nazar Kazakov <nazar.kazakov.work@gmail.com>
This commit is contained in:
Nazar Kazakov
Anas Nashif
parent
3b576fc688
commit
f483b1bc4c
|
|
@ -70,7 +70,7 @@
|
|||
- "arch/xtensa/**/*"
|
||||
- "include/arch/xtensa/**/*"
|
||||
"area: RISCV":
|
||||
- "arch/risv/**/*"
|
||||
- "arch/riscv/**/*"
|
||||
- "include/arch/riscv/**/*"
|
||||
"area: ARC":
|
||||
- "arch/arc/**/*"
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
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)
|
||||
if(NOT CONFIG_ARCH_POSIX)
|
||||
# `zephyr_stdint.h` is not included for the POSIX (native) arch because it
|
||||
|
|
|
|||
|
|
@ -799,7 +799,7 @@ choice CACHE_TYPE
|
|||
config HAS_ARCH_CACHE
|
||||
bool "Integrated cache controller"
|
||||
help
|
||||
"Integrade on-core cache controller"
|
||||
"Integrated on-core cache controller"
|
||||
|
||||
config HAS_EXTERNAL_CACHE
|
||||
bool "External cache controller"
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
"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
|
||||
*/
|
||||
#if defined(CONFIG_ARC_SECURE_FIRMWARE)
|
||||
|
|
|
|||
|
|
@ -245,7 +245,7 @@ SECTION_FUNC(TEXT,z_arm_userspace_enter)
|
|||
mov r0, lr
|
||||
|
||||
#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
|
||||
#else
|
||||
/* change processor mode to unprivileged */
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@
|
|||
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
|
||||
* run (cannot be NULL)
|
||||
*
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
*
|
||||
* @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 addr_val Address register value
|
||||
*
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ void arch_new_thread(struct k_thread *thread, k_thread_stack_t *stack,
|
|||
* Following the RISC-V architecture,
|
||||
* the MSTATUS register (used to globally enable/disable interrupt),
|
||||
* 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
|
||||
* and restored prior to returning from the interrupt/exception.
|
||||
* This shall allow to handle nested interrupts.
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ LOG_MODULE_DECLARE(os, CONFIG_KERNEL_LOG_LEVEL);
|
|||
*
|
||||
* 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
|
||||
* in the assembly list file or use addr2line. In the listing, the
|
||||
* 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
|
||||
* the current window pointer (psr bits 4..0) which results in %o
|
||||
* 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"
|
||||
* 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.
|
||||
*/
|
||||
struct savearea {
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@
|
|||
* we go through z_x86_trampoline_to_user.
|
||||
*
|
||||
* 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
|
||||
* switching page tables.
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
*
|
||||
* 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
|
||||
* mapping preserved.
|
||||
*
|
||||
|
|
@ -1147,7 +1147,7 @@ out:
|
|||
* @param size Size of the physical region to map
|
||||
* @param entry_flags Desired state of non-address PTE bits covered by mask,
|
||||
* 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.
|
||||
* @param options Control options. Do not set OPTION_USER here. OPTION_FLUSH
|
||||
* will trigger a TLB shootdown after all tables are updated.
|
||||
|
|
@ -1334,7 +1334,7 @@ static void identity_map_remove(uint32_t level)
|
|||
#endif
|
||||
|
||||
/* 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
|
||||
void z_x86_mmu_init(void)
|
||||
|
|
|
|||
|
|
@ -981,7 +981,7 @@ void arch_gdb_init(void)
|
|||
* converting BREAK.N into BREAK which is bigger.
|
||||
* This is needed as the GDB stub will need to change
|
||||
* 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
|
||||
* won't go forward.
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
#
|
||||
|
||||
# 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
|
||||
|
||||
# Only specify FTDI serial number if it is specified via
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
# Configure JTAG cable
|
||||
# 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
|
||||
|
||||
# Only specify FTDI serial number if it is specified via
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
# Configure JTAG cable
|
||||
# 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
|
||||
|
||||
# Only specify FTDI serial number if it is specified via
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ QEMU, and display the following console output:
|
|||
|
||||
*** Booting Zephyr OS build zephyr-v2.2.0-2486-g7dbfcf4bab57 ***
|
||||
threadA: Hello World from qemu_arc!
|
||||
threudB: Hello World from qemu_arc!
|
||||
threadB: Hello World from qemu_arc!
|
||||
threadA: Hello World from qemu_arc!
|
||||
threadB: Hello World from qemu_arc!
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ Hardware
|
|||
- Temperature/Pressure: STMicro LPS22HB
|
||||
- ALS: Intersil ISL29034
|
||||
- Proximity: STMicro VL53L0X
|
||||
- Acclerometer/Gyroscope: STMicro LSM6DSL
|
||||
- Accelerometer/Gyroscope: STMicro LSM6DSL
|
||||
- Geomagnetic: STMicro LIS2MDL
|
||||
- AMR Hall sensor: MRMS501A
|
||||
- Microphone: STMicro MP34DT05
|
||||
|
|
|
|||
|
|
@ -149,7 +149,7 @@ the remaining are not used/tested.
|
|||
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
|
||||
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
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ Hardware
|
|||
- Pressure: BMP280
|
||||
- ALS/Proximity: RPR-0521RS
|
||||
- Geomagnetic: BMM150
|
||||
- Acclerometer/Gyroscope: BMI160
|
||||
- Accelerometer/Gyroscope: BMI160
|
||||
- AMR Hall sensor: MRMS501A
|
||||
- Microphone: SPK0415HM4H-B
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ Hardware
|
|||
- On board sensors:
|
||||
|
||||
- Temperature/Pressure: STMicro LPS22HB
|
||||
- Acclerometer/Gyroscope: STMicro LSM6DS3H
|
||||
- Accelerometer/Gyroscope: STMicro LSM6DS3H
|
||||
- Magnetometer: STMicro LIS3MDL
|
||||
- Microphone: STMicro MP34DT01
|
||||
|
||||
|
|
|
|||
|
|
@ -71,11 +71,11 @@ Connections and IOs
|
|||
The `schematic`_ will tell you everything
|
||||
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`,
|
||||
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`:
|
||||
This configuration option enables the internal I2C sensors.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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
|
||||
targetted designs for now.
|
||||
targeted designs for now.
|
||||
|
||||
For more information about the ARM Cortex-M1/M3 DesignStart FPGA, see the
|
||||
following websites:
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@
|
|||
* 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
|
||||
* 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
|
||||
* configured with mode 1 to operate as I2C_SCL.
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@
|
|||
* 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
|
||||
* 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
|
||||
* configured with mode 1 to operate as I2C_SCL.
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
.. _contextualelectronics_abc:
|
||||
|
||||
Contextual Eletronics Advanced BLE Cell
|
||||
#######################################
|
||||
Contextual Electronics Advanced BLE Cell
|
||||
########################################
|
||||
|
||||
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:
|
||||
|
||||
* CLOCK
|
||||
|
|
|
|||
|
|
@ -246,10 +246,10 @@ are only possible after rework the board and using the revision 1.0.0.
|
|||
:goals: build
|
||||
: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 |
|
||||
+-------------+------------+------------+
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ For more information about the EFM32WG SoC and EFM32WG-STK3800 board:
|
|||
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 |
|
||||
|
|
|
|||
|
|
@ -215,7 +215,7 @@ CAN
|
|||
===
|
||||
|
||||
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``).
|
||||
|
||||
Programming and Debugging
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ Overview
|
|||
The MEC15xxEVB_ASSY6853 kit is a future development platform to evaluate the
|
||||
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.
|
||||
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
|
||||
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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
``boards/arm/mikroe_clicker_2/mikroe_cliker_2_defconfig``
|
||||
``boards/arm/mikroe_clicker_2/mikroe_clicker_2_defconfig``
|
||||
|
||||
Connections and IOs
|
||||
===================
|
||||
|
|
|
|||
|
|
@ -198,7 +198,7 @@ Flashing
|
|||
|
||||
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: samples/hello_world
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ Motherboard
|
|||
3. I2C interface
|
||||
4. SPI interface
|
||||
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
|
||||
8. UART interface
|
||||
9. Battery holder
|
||||
|
|
|
|||
|
|
@ -14,8 +14,8 @@ config BOARD
|
|||
# To let the nRF5 bootloader load an application, the application
|
||||
# must be linked after Nordic MBR, that is factory-programmed on the board.
|
||||
|
||||
# Nordic nRF5 booatloader exists outside of the partitions specified in the
|
||||
# DTS file, so we manually override FLASH_LOAD_OFFEST to link the application
|
||||
# Nordic nRF5 bootloader exists outside of the partitions specified in the
|
||||
# DTS file, so we manually override FLASH_LOAD_OFFSET to link the application
|
||||
# correctly, after Nordic MBR.
|
||||
|
||||
# When building MCUBoot, MCUBoot itself will select USE_DT_CODE_PARTITION
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ Nucleo G0B1RE provides the following hardware components:
|
|||
- Tamper Pins(3)
|
||||
- 12-bit ADC with 16 channels
|
||||
- 12-bit DAC with 2 channels(2)
|
||||
- Analog Comperator(3)
|
||||
- Analog Comparator(3)
|
||||
- 12-channel DMA
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
# SPDX-License-Identifier: Apache-2.0
|
||||
|
|
@ -13,7 +13,7 @@ set BOARDNAME NUCLEO-H723ZG
|
|||
|
||||
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
|
||||
reset_config srst_only srst_nogate connect_assert_srst
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
|
||||
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
|
||||
reset_config srst_only srst_nogate connect_assert_srst
|
||||
|
||||
|
|
|
|||
|
|
@ -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/
|
||||
# revert to board/st_nucleo_l1.cfg
|
||||
# source [find board/st_nucleo_l1.cfg]
|
||||
|
|
|
|||
|
|
@ -211,7 +211,7 @@ Programming and Debugging
|
|||
|
||||
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
|
||||
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
|
||||
SWD transport, but it is also possible to use JTAG with the Olimex ARM-USB-OCD-H
|
||||
|
|
|
|||
|
|
@ -185,7 +185,7 @@ Debugging
|
|||
Using Segger Ozone debugger, debugging and flashing is made easy.
|
||||
|
||||
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
|
||||
typing the following in the debugger console:
|
||||
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ static void prevent_false_prev_evt(void)
|
|||
uint32_t prev_val;
|
||||
|
||||
/* 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
|
||||
* (half of 1M tick) and clean potential event. After that time there
|
||||
* is no risk of unwanted event.
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ CONFIG_SERIAL=y
|
|||
CONFIG_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.
|
||||
# Thus we do not use flash directly.
|
||||
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ Here are official IOs figures from eLinux for Kingfisher Infotainment board:
|
|||
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
|
||||
----
|
||||
|
|
|
|||
|
|
@ -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
|
||||
`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: samples/basic/blinky
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@
|
|||
compatible = "gpio-keys";
|
||||
|
||||
/* 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
|
||||
*/
|
||||
sw0_user_button: button_1 {
|
||||
|
|
|
|||
|
|
@ -21,4 +21,4 @@ config UART_XLNX_UARTLITE
|
|||
depends on SERIAL
|
||||
default y
|
||||
|
||||
endif # BOARD_SCOBC_SPEQ
|
||||
endif # BOARD_SCOBC_MODULE1
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ USB Type-C socket and USB Type-A plug.
|
|||
.. image:: img/serpente.jpg
|
||||
:width: 640px
|
||||
:align: center
|
||||
:alt: Serpente Baords
|
||||
:alt: Serpente Boards
|
||||
|
||||
Hardware
|
||||
********
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ started quickly. Here are some highlights of the STM32F3DISCOVERY board:
|
|||
acceleration sensor and a 3D digital magnetic sensor;
|
||||
|
||||
.. 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
|
||||
:width: 350px
|
||||
|
|
@ -194,7 +194,7 @@ CAN
|
|||
===
|
||||
The STM32F3DISCOVERY does not have an onboard CAN transceiver. In
|
||||
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``).
|
||||
|
||||
Programming and Debugging
|
||||
|
|
|
|||
|
|
@ -150,7 +150,7 @@ Here is an example for the :ref:`blinky-sample` application.
|
|||
:board: stm32f411e_disco
|
||||
:goals: build flash
|
||||
|
||||
Incase you are using PCB revision B, you have to use an
|
||||
In case you are using PCB revision B, you have to use an
|
||||
adapted board definition as the default PCB rev here is D:
|
||||
|
||||
.. zephyr-app-commands::
|
||||
|
|
|
|||
|
|
@ -145,7 +145,7 @@
|
|||
INA230_AVG_MODE_1)>;
|
||||
/* Set current LSB to 1mA */
|
||||
current-lsb = <1>;
|
||||
/* Set shunt resistror value to 15 milliohms */
|
||||
/* Set shunt resistor value to 15 milliohms */
|
||||
rshunt = <15>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ transport select hla_swd
|
|||
|
||||
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
|
||||
reset_config srst_only srst_nogate connect_assert_srst
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ All of the Nordic Semiconductor examples for the nRF52840 DK
|
|||
(nrf52840dk_nrf52840) may be used without modification.
|
||||
|
||||
..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
|
||||
the ubx_bmd340eval_nrf52840.
|
||||
|
||||
|
|
|
|||
|
|
@ -129,7 +129,7 @@ static void arm_v2m_beetle_pinmux_defaults(void)
|
|||
|
||||
/* Set the ARD_PWR_EN GPIO1[15] as an output */
|
||||
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);
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -365,10 +365,10 @@ For more information refer to the `Srecord Manual`_.
|
|||
|
||||
.. 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
|
||||
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
|
||||
see a USB connection exposing a Mass Storage (MUSCA_B) and a USB Serial Port.
|
||||
|
|
|
|||
|
|
@ -339,10 +339,10 @@ For more information refer to the `Srecord Manual`_.
|
|||
|
||||
.. 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
|
||||
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
|
||||
:width: 600px
|
||||
|
|
|
|||
|
|
@ -184,12 +184,12 @@
|
|||
<text x="6.95" y="302.06" class="st4" v:langID="6153"><v:paragraph v:horizAlign="1"/><v:tabList/><1/1000x</text> </g>
|
||||
<g id="shape54-79" v:mID="54" v:groupContext="shape" transform="translate(63.0709,-2.83465)">
|
||||
<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: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"/>
|
||||
<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"
|
||||
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)">
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 26 KiB After Width: | Height: | Size: 26 KiB |
|
|
@ -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
|
||||
* where clock_type is one of RTC_CLOCK_*
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
* @file Extra definitions provided by the board to soc.h
|
||||
*
|
||||
* 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
|
||||
* but that is left for the "board" to define it
|
||||
* Device code may rely on the soc.h defining some things (like the interrupts
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Listing the IT81302 hardware features as following:
|
|||
- 60KB SDRAM in total
|
||||
- Built-in 32.768 kHz clock generator
|
||||
- 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
|
||||
- USB Type-c CC Logic
|
||||
- USB Power Delivery
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Get the Toolchain and QEMU
|
|||
|
||||
The minimum version of the `Zephyr SDK tools
|
||||
<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>`
|
||||
for more details.
|
||||
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ flash bank $_CHIPNAME.flash1 rv32m1 0x01000000 0 0 0 $_TARGETNAME # For core 1
|
|||
|
||||
proc ri5cy_boot { } {
|
||||
|
||||
# Erase all blok unsecure
|
||||
# Erase all block unsecure
|
||||
mwb 0x40023000 0x70
|
||||
mww 0x40023004 0x49000000
|
||||
mwb 0x40023000 0x80
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ The Zephyr TLSR9518ADK80D board configuration supports the following hardware fe
|
|||
+----------------+------------+------------------------------+
|
||||
| PWM | on-chip | pwm |
|
||||
+----------------+------------+------------------------------+
|
||||
| TRNG | on-chip | entopy |
|
||||
| TRNG | on-chip | entropy |
|
||||
+----------------+------------+------------------------------+
|
||||
| FLASH (MSPI) | on-chip | flash |
|
||||
+----------------+------------+------------------------------+
|
||||
|
|
|
|||
|
|
@ -131,7 +131,7 @@ Arduino Shields
|
|||
===============
|
||||
|
||||
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
|
||||
=============================================
|
||||
|
|
@ -182,7 +182,7 @@ MikroBus Shields
|
|||
================
|
||||
|
||||
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
|
||||
==============================================
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Overview
|
|||
********
|
||||
|
||||
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
|
||||
Interoperability Network) AT commands set. The current es-WIFI driver is able
|
||||
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
|
||||
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
|
||||
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
|
||||
signal, user need do a wire connecting these two terminals. On the below
|
||||
image is possible see suggested wiring connections.
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ high during driver initialization. Display blanking apis can be used
|
|||
to control it.
|
||||
|
||||
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.
|
||||
This signal must be supplied from either serial input (sw) or an external
|
||||
signal on the EXTCOMIN pin.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ DFRobot CAN BUS Shield V2.0
|
|||
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
|
||||
Uno R3 compatible hardware interface.
|
||||
|
||||
|
|
@ -122,7 +122,7 @@ Keyestudio CAN-BUS Shield (KS0411)
|
|||
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
|
||||
Uno R3 compatible hardware interface.
|
||||
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ Samples
|
|||
The :ref:`samples_eeprom` can be used to demonstrate the expansion boards
|
||||
functionality.
|
||||
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
|
||||
***********
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
Also shield expects SPI CS to be available on Arduino pin A1 instead of usual
|
||||
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
|
||||
|
||||
Shield configuration could be modified by moving resistors as
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ configuration files instead of small easily-merged configuration
|
|||
elements like kconfig defconfig files or devicetree includes. You
|
||||
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
|
||||
this case). Then find the relavent file in
|
||||
this case). Then find the relevant file in
|
||||
``misc/config_tools/data/<platform>/hybrid.xml``.
|
||||
|
||||
First, find the list of ``<vm>`` declarations. Each has an ``id=``
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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
|
||||
reference link https://github.com/Richard-W/uefi-run.
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ Next you disable the validation step:
|
|||
|
||||
**THIS COMMAND WILL FAIL**, give you an error that you are changing
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
modified one. But that's too many balls to juggle at once for me.
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ def calc_firmware_sha(file):
|
|||
"""
|
||||
Open firmware image file and calculate file size
|
||||
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:
|
||||
firmware.seek(0, 2)
|
||||
|
|
|
|||
|
|
@ -33,15 +33,15 @@ class Message:
|
|||
|
||||
def __init__(self):
|
||||
"""
|
||||
Intialize a byte array of 64 bytes for command messages
|
||||
Intialize another byte array of 4096 bytes for bulk messages
|
||||
Initialize a byte array of 64 bytes for command messages
|
||||
Initialize another byte array of 4096 bytes for bulk messages
|
||||
"""
|
||||
self.tx_data = bytearray(64)
|
||||
self.tx_bulk_data = bytearray(4096)
|
||||
|
||||
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)):
|
||||
self.tx_data[index] = 0
|
||||
|
|
@ -194,7 +194,7 @@ class Message:
|
|||
|
||||
def create_execfw_cmd(self):
|
||||
"""
|
||||
Creates a command to excute firmware
|
||||
Creates a command to execute firmware
|
||||
"""
|
||||
cmd = 'Execute'
|
||||
print('CMD >>> %s.' % cmd)
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
||||
# 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
|
||||
find_program(CMAKE_OBJCOPY arc-elf32-objcopy)
|
||||
if (NOT CMAKE_OBJCOPY)
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ set_property(TARGET bintools PROPERTY memusage_infile "")
|
|||
|
||||
|
||||
# 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)
|
||||
|
||||
# MWDT toolchain does not support all options in a single command
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
# 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)
|
||||
|
||||
# armclang toolchain does not support all options in a single command
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@
|
|||
set_property(TARGET bintools PROPERTY elfconvert_command ${CMAKE_OBJCOPY})
|
||||
|
||||
# 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_flag "")
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@
|
|||
set_property(TARGET bintools PROPERTY elfconvert_command ${CMAKE_OBJCOPY})
|
||||
|
||||
# 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_flag "")
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ endif()
|
|||
# link a dummy C file.
|
||||
#
|
||||
# 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})
|
||||
list(APPEND isystem_include_flags -isystem "\"${isystem_include_dir}\"")
|
||||
endforeach()
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ list(APPEND TOOLCHAIN_LIBS
|
|||
# link a dummy C file.
|
||||
#
|
||||
# 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})
|
||||
list(APPEND isystem_include_flags -isystem "\"${isystem_include_dir}\"")
|
||||
endforeach()
|
||||
|
|
|
|||
|
|
@ -172,7 +172,7 @@ macro(toolchain_ld_base)
|
|||
)
|
||||
endmacro()
|
||||
|
||||
# generate linker script snippts from configure files
|
||||
# generate linker script snippets from configure files
|
||||
macro(toolchain_ld_configure_files)
|
||||
configure_file(
|
||||
$ENV{ZEPHYR_BASE}/include/arch/common/app_data_alignment.ld
|
||||
|
|
|
|||
|
|
@ -333,7 +333,7 @@ function(section_to_string)
|
|||
# endif()
|
||||
|
||||
#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()
|
||||
|
||||
if(first)
|
||||
|
|
|
|||
|
|
@ -94,8 +94,8 @@ function(toolchain_ld_link_elf)
|
|||
# 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.
|
||||
--diag_suppress=6314
|
||||
# We use empty excution sections in order to define custom symbols, such as
|
||||
# __kernel_ram_x symbols, but nothing will go in those section, so silnence
|
||||
# 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 silence
|
||||
# the warning. Note, marking the section EMPTY causes armlink to reserve the
|
||||
# address which in some cases leads to overlapping section errors.
|
||||
--diag_suppress=6312
|
||||
|
|
|
|||
|
|
@ -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\
|
||||
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.\
|
||||
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. \
|
||||
To change CONF_FILE, use the CONF_FILE variable.")
|
||||
unset(CONF_FILE CACHE)
|
||||
|
|
|
|||
|
|
@ -2618,7 +2618,7 @@ function(dt_node_exists var)
|
|||
cmake_parse_arguments(DT_NODE "" "${req_single_args}" "" ${ARGN})
|
||||
|
||||
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()
|
||||
|
||||
foreach(arg ${req_single_args})
|
||||
|
|
|
|||
|
|
@ -4,8 +4,8 @@
|
|||
|
||||
# Zephyr Kernel CMake module.
|
||||
#
|
||||
# This is the main Zephyr Kernel CMake module which is resposible for creation
|
||||
# of Zephyr libraries and the Zephyr executeable.
|
||||
# This is the main Zephyr Kernel CMake module which is responsible for creation
|
||||
# of Zephyr libraries and the Zephyr executable.
|
||||
#
|
||||
# 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})
|
||||
|
||||
# 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.
|
||||
list(APPEND CMAKE_ASM_SOURCE_FILE_EXTENSIONS "S")
|
||||
enable_language(C CXX ASM)
|
||||
|
|
|
|||
|
|
@ -112,7 +112,7 @@ foreach(root ${BOARD_ROOT})
|
|||
endforeach()
|
||||
|
||||
# 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 invokes '<build-command> shields' target
|
||||
list(SORT SHIELD_LIST)
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ SOFTWARE.
|
|||
|
||||
html {
|
||||
/* 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;
|
||||
--menu-display: none;
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ html {
|
|||
--border-radius-small: 4px;
|
||||
--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-medium: 10px;
|
||||
--spacing-large: 16px;
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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.
|
||||
|
||||
Configuration options
|
||||
|
|
@ -93,7 +93,7 @@ def adjust_includes(
|
|||
|
||||
|
||||
def sync_contents(app: Sphinx) -> None:
|
||||
"""Synhronize external contents.
|
||||
"""Synchronize external contents.
|
||||
|
||||
Args:
|
||||
app: Sphinx application instance.
|
||||
|
|
|
|||
|
|
@ -395,7 +395,7 @@ def write_orphans(bindings, base_binding, vnd_lookup, out_dir):
|
|||
# Next, write the per-binding pages. These contain the
|
||||
# per-compatible targets for compatibles not in 'dup_compats'.
|
||||
# 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.
|
||||
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):
|
||||
# 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
|
||||
# exists.
|
||||
|
||||
|
|
|
|||
|
|
@ -227,7 +227,7 @@ Zephyr.)
|
|||
target_sources(app PRIVATE src/main.c)
|
||||
|
||||
``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.
|
||||
|
||||
``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
|
||||
|
||||
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:
|
||||
|
||||
.. code-block:: none
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ Main rules
|
|||
|
||||
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
|
||||
severity and the equivlent rules from other standards for reference.
|
||||
severity and the equivalent rules from other standards for reference.
|
||||
|
||||
.. 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.3
|
||||
- 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>`_
|
||||
- `Rule 10.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_10_03.c>`_
|
||||
* - Rule 10.4
|
||||
|
|
|
|||
|
|
@ -230,7 +230,7 @@ The CI infrastructure currently runs the following tests:
|
|||
IOPCTL_Type *base = config->base;
|
||||
|
||||
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
|
||||
is misidentified as a multiplication expression that would be correct
|
||||
as ``IOPCTL_Type * base``.
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ For this, `git bisect`_ is the recommended tool.
|
|||
Recommendations on the process:
|
||||
|
||||
* 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:
|
||||
https://git-scm.com/docs/git-bisect
|
||||
|
|
|
|||
|
|
@ -116,7 +116,7 @@ gate the final release. The following counts shall be used:
|
|||
|
||||
.. 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
|
||||
|
||||
|
||||
|
|
@ -174,7 +174,7 @@ security fixes.
|
|||
|
||||
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
|
||||
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.
|
||||
|
||||
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
|
||||
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.
|
||||
- Regular static analysis on the complete tree using available commercial and
|
||||
open-source tools and documentation of deviations and false positives.
|
||||
|
|
|
|||
|
|
@ -113,7 +113,7 @@ stack pointer manipulation* during thread context switching, without affecting t
|
|||
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
|
||||
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`.
|
||||
|
||||
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*
|
||||
|
||||
* 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 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
|
||||
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).
|
||||
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.
|
||||
|
|
@ -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)
|
||||
* 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.
|
||||
|
||||
|
||||
|
|
@ -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
|
||||
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
|
||||
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
|
||||
(full-SRAM partitioning is not required).
|
||||
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
|
||||
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.
|
||||
|
||||
When a bootloader image enables :kconfig:option:`CONFIG_SW_VECTOR_RELAY`
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ is being placed in the memory, and its counterpart
|
|||
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,
|
||||
but are still loaded in physical memory. However, during boot, code
|
||||
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)
|
||||
|
||||
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)
|
||||
|
||||
|
|
|
|||
|
|
@ -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 socat.exe creates tunel to board. Run in console
|
||||
- Check if socat.exe creates tunnel to board. Run in console
|
||||
|
||||
.. code-block::
|
||||
|
||||
|
|
|
|||
|
|
@ -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_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_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_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)
|
||||
|
|
|
|||
|
|
@ -452,5 +452,5 @@ tips and best practices for writing :file:`Kconfig` files.
|
|||
kconfig/preprocessor-functions.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`.
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue