| /Zephyr-latest/doc/hardware/porting/ |
| D | board_porting.rst | 3 Board Porting Guide
6 To add Zephyr support for a new :term:`board`, you at least need a *board
7 directory* with various files in it. Files in the board directory inherit
13 Transition to the current hardware model
16 Shortly after Zephyr 3.6.0 was released, a new hardware model was introduced to
21 - Support for multi-core, multi-arch AMP (Asymmetrical Multi Processing) SoCs
22 - Support for multi-SoC boards
23 - Support for reusing the SoC and board Kconfig trees outside of the Zephyr
25 - Support for advanced use cases with :ref:`sysbuild`
26 - Removal of all existing arbitrary and inconsistent uses of Kconfig and folder
[all …]
|
| /Zephyr-latest/cmake/modules/ |
| D | boards.cmake | 1 # SPDX-License-Identifier: Apache-2.0
5 # Validate board and setup boards target.
7 # This CMake module will validate the BOARD argument as well as splitting the
8 # BOARD argument into <BOARD> and <BOARD_REVISION>. When BOARD_EXTENSIONS option
9 # is enabled (default) this module will also take care of finding board
12 # If a board implementation is not found for the specified board an error will
15 # If user provided board is a board alias, the board will be adjusted to real
16 # board name.
18 # If board name is deprecated, then board will be adjusted to new board name and
19 # a deprecation warning will be printed to the user.
[all …]
|
| /Zephyr-latest/samples/basic/blinky_pwm/ |
| D | README.rst | 1 .. zephyr:code-sample:: pwm-blinky
3 :relevant-api: pwm_interface
11 :zephyr:code-sample:`blinky` for a GPIO-based sample.
15 seconds until it returns to 1 Hz, completing a single blinking cycle. This
16 faster-then-slower blinking cycle then repeats forever.
18 Some PWM hardware cannot set the PWM period to 1 second to achieve the blinking
19 frequency of 1 Hz. This sample calibrates itself to what the hardware supports
26 The board must have an LED connected to a PWM output channel. The PWM
28 <dt-guide>` alias, usually in the :ref:`BOARD.dts file
29 <devicetree-in-out-files>`.
[all …]
|
| /Zephyr-latest/tests/cmake/overlays/soc_folder_kconfig/src/ |
| D | main.c | 4 * SPDX-License-Identifier: Apache-2.0
65 zassert_false(INCLUDED_BOARD_SUFFIX, "Did not expect board suffix config to be present"); in ZTEST()
68 zassert_false(INCLUDED_BOARD, "Did not expect board config to be present"); in ZTEST()
69 zassert_true(INCLUDED_BOARD_QUALIFIERS, "Expected board qualifier config to be present"); in ZTEST()
70 zassert_mem_equal(STRING_OUTPUT, "five", strlen("five"), "Expected string to match"); in ZTEST()
72 zassert_true(INCLUDED_BOARD, "Expected board config to be present"); in ZTEST()
74 "Did not expect board qualifier config to be present"); in ZTEST()
75 zassert_mem_equal(STRING_OUTPUT, "two", strlen("two"), "Expected string to match"); in ZTEST()
78 zassert_false(INCLUDED_BOARD_OTHER, "Did not expect board other config to be present"); in ZTEST()
79 zassert_true(INCLUDED_SOC, "Expect soc config to be present"); in ZTEST()
[all …]
|
| /Zephyr-latest/boards/norik/octopus_io_board/doc/ |
| D | index.rst | 1 .. zephyr:board:: octopus_io_board
6 Octopus IO-Board is an expansion to the Octopus SoM, which is built around the nRF9160 SiP
7 offering NB-IoT and LTE-M connectivity, GPS and accelerometer. Octopus IO-Board expands
9 development and prototyping of low-power IoT applications.
11 nRF9160 SiP contains ARM Cortex-M33 application processor and the
14 * :abbr:`ADC (Analog to Digital Converter)`
18 * :abbr:`I2C (Inter-Integrated Circuit)`
25 * :abbr:`UARTE (Universal asynchronous receiver-transmitter with EasyDMA)`
29 Octopus IO-Board offers the following features:
32 * USB-C for power
[all …]
|
| /Zephyr-latest/boards/ |
| D | Kconfig | 1 # SPDX-License-Identifier: Apache-2.0
3 config BOARD config
5 # When using hw model v2, then the board is inherited from CMake.
6 default "$(BOARD)" if "$(HWM_SCHEME)" = "v2"
8 This option holds the name of the board and is used to locate the files
9 related to the board in the source tree (under boards/).
10 The Board is the first location where we search for a linker.ld file,
17 If the BOARD has a revision field set, this is the revision.
18 Otherwise, it is the empty string. For example, if BOARD is
19 "plank@foo", this option will be "foo". If BOARD is "plank",
[all …]
|
| D | index.rst | 6 If you are looking to add Zephyr support for a new board, please start with the
9 When adding support documentation for a board, remember to use the template
10 available under :zephyr_file:`doc/templates/board.tmpl`.
12 Shields are hardware add-ons that can be stacked on top of a board to add extra
14 this page <boards-shields>`.
19 * Use the form below to filter the list of supported boards. If a field is left empty, it will
22 * A board must meet **all** criteria selected across different fields. For example, if you select
27 * Can't find your exact board? Don't worry! If a similar board with the same or a closely related
28 MCU exists, you can use it as a :ref:`starting point <create-your-board-directory>` for adding
29 support for your own board.
[all …]
|
| /Zephyr-latest/tests/cmake/hwm/board_extend/src/ |
| D | main.c | 4 * SPDX-License-Identifier: Apache-2.0
51 zassert_true(EXTENDED_BOARD_A, "Expected extended board to be set");
52 zassert_true(EXTENDED_BOARD_ONE_B, "Expected extended board to be set");
53 zassert_false(EXTENDED_BOARD_TWO_C, "Did not expect extended board two to be set");
54 zassert_true(EXTENDED_BOARD_D, "Expected extended board to be set");
55 zassert_false(BASE_BOARD_CONFIG, "Did not expect base board to be set");
60 zassert_true(EXTENDED_BOARD_A, "Expected extended board to be set");
61 zassert_false(EXTENDED_BOARD_ONE_B, "Did not expect extended board one to be set");
62 zassert_true(EXTENDED_BOARD_TWO_C, "Expected extended board to be set");
63 zassert_true(EXTENDED_BOARD_D, "Expected extended board to be set");
[all …]
|
| /Zephyr-latest/samples/sensor/mcux_acmp/ |
| D | README.rst | 1 .. zephyr:code-sample:: mcux_acmp
3 :relevant-api: sensor_interface
10 This sample show how to use the NXP MCUX Analog Comparator (ACMP) driver. The
11 sample supports the :zephyr:board:`twr_ke18f`, :zephyr:board:`mimxrt1170_evk`, :zephyr:board:`frdm_…
12 , :zephyr:board:`frdm_ke17z512` and :zephyr:board:`mimxrt1180_evk`.
15 provided by the ACMP Digital-to-Analog Converter (DAC). The input voltage for
16 the positive input can be adjusted by turning the on-board potentiometer for
17 :zephyr:board:`twr_ke18f` board, for :zephyr:board:`mimxrt1170_evk` the voltage signal is
18 captured on J25-13, the :zephyr:board:`frdm_ke17z` and :zephyr:board:`frdm_ke17z512` boards are
19 captured in J2-3, the :zephyr:board:`mimxrt1180_evk` board are captured in J45-13, need
[all …]
|
| /Zephyr-latest/scripts/utils/ |
| D | board_v1_to_v2.py | 3 Utility script to assist in the migration of a board from hardware model v1
4 (HWMv1) to hardware model v2 (HWMv2).
7 This script is not a complete migration tool. It is meant to assist in the
12 - ``-b|--board``: The name of the board to migrate.
13 - ``-g|--group``: The group the board belongs to. This is used to group a set of
16 - ``-v|--vendor``: The vendor name.
17 - ``-s|--soc``: The SoC name.
19 In some cases, the new board name will differ from the old board name. For
20 example, the old board name may have the SoC name as a suffix, while in HWMv2,
21 this is no longer needed. In such cases, ``-n|--new-board`` needs to be
[all …]
|
| /Zephyr-latest/scripts/schemas/ |
| D | board-schema.yml | 1 # SPDX-License-Identifier: Apache-2.0
6 ## board metadata YAML file.
8 # The board.yml file is a simple list of key value pairs containing board
10 schema;variant-schema:
14 - type: map
24 include: variant-schema
26 schema;extend-variant-schema:
30 - type: map
39 schema;board-schema:
45 desc: Name of the board
[all …]
|
| /Zephyr-latest/tests/cmake/overlays/soc_folder_overlay/src/ |
| D | main.c | 4 * SPDX-License-Identifier: Apache-2.0
53 zassert_false(INCLUDED_APP, "Did not expect app overlay to be present"); in ZTEST()
54 zassert_false(INCLUDED_BOARD_SUFFIX, "Did not expect board suffix overlay to be present"); in ZTEST()
57 zassert_false(INCLUDED_BOARD, "Did not expect board overlay to be present"); in ZTEST()
58 zassert_true(INCLUDED_BOARD_QUALIFIERS, "Expected board qualifier overlay to be present"); in ZTEST()
60 zassert_true(INCLUDED_BOARD, "Expected board overlay to be present"); in ZTEST()
62 "Did not expect board qualifier overlay to be present"); in ZTEST()
65 zassert_true(INCLUDED_SOC, "Expect soc overlay to be present"); in ZTEST()
66 zassert_false(INCLUDED_SOC_SUFFIX, "Did not expect soc suffix overlay to be present"); in ZTEST()
72 zassert_false(INCLUDED_APP, "Did not expect app overlay to be present"); in ZTEST()
[all …]
|
| /Zephyr-latest/boards/espressif/esp32s3_eye/doc/ |
| D | index.rst | 1 .. zephyr:board:: esp32s3_eye
6 The ESP32-S3-EYE is a small-sized AI development board produced by [Espressif](https://espressif.co…
7 It is based on the [ESP32-S3](https://www.espressif.com/en/products/socs/esp32-s3) SoC.
8 It features a 2-Megapixel camera, an LCD display, and a microphone, which are used for image
9 recognition and audio processing. ESP32-S3-EYE offers plenty of storage, with an 8 MB Octal PSRAM
15 The ESP32-S3-EYE board consists of two parts: the main board (ESP32-S3-EYE-MB) that integrates the
16 ESP32-S3-WROOM-1 module, camera, SD card slot, digital microphone, USB port, and function buttons;
17 and the sub board (ESP32-S3-EYE-SUB) that contains an LCD display.
18 The main board and sub board are connected through pin headers.
21 -------------
[all …]
|
| /Zephyr-latest/boards/sifive/hifive1/doc/ |
| D | index.rst | 1 .. zephyr:board:: hifive1
6 The HiFive1 is an Arduino-compatible development board with
7 an FE310 RISC-V SoC. Two revisions of this board are supported in Zephyr:
9 and `HiFive1 Rev B <https://www.sifive.com/boards/hifive1-rev-b>`__.
13 :alt: SiFive HiFive1 board
15 SiFive HiFive1 board (image courtesy of SiFive)
19 :alt: SiFive HiFive1 Rev B board
21 SiFive HiFive1 Rev B board (image courtesy of SiFive)
29 Applications for the HiFive1 board configuration can be built as usual (see
30 :ref:`build_an_application`) using the corresponding board name:
[all …]
|
| /Zephyr-latest/boards/microchip/mpfs_icicle/doc/ |
| D | index.rst | 1 .. zephyr:board:: mpfs_icicle
6 The Microchip mpfs_icicle board is a PolarFire SoC FPGA based development board with a Microchip MP…
7 The E51 RISC-V CPU can be deployed on the mpfs_icicle board.
8 More information can be found on the `Microchip website <https://www.microchip.com/en-us/product/MP…
16 Applications for the ``mpfs_icicle`` board configuration can be built as usual
19 .. zephyr-app-commands::
20 :board: mpfs_icicle
23 To build the default SMP capable variant
25 .. zephyr-app-commands::
26 :board: mpfs_icicle/polarfire/smp
[all …]
|
| /Zephyr-latest/samples/drivers/watchdog/ |
| D | README.rst | 1 .. zephyr:code-sample:: watchdog
3 :relevant-api: watchdog_interface
5 Use the watchdog driver API to reset the board when it gets stuck in an infinite loop.
10 This sample demonstrates how to use the watchdog driver API.
12 A typical use case for a watchdog is that the board is restarted in case some piece of code
18 …a watchdog callback is used to handle a timeout event once. This functionality is used to request …
19 restarts due to a timeout event in the watchdog driver.
21 The watchdog peripheral is configured in the board's ``.dts`` file. Make sure that the watchdog is …
28 :zephyr:board:`nucleo_f091rc` as follows:
30 .. zephyr-app-commands::
[all …]
|
| /Zephyr-latest/boards/quicklogic/qomu/doc/ |
| D | index.rst | 1 .. zephyr:board:: qomu
6 The Qomu board is a platform with an on-board QuickLogic EOS S3 Sensor Processing Platform.
11 - QuickLogic EOS S3 MCU Platform
12 - 16 Mbit of on-board flash memory
13 - Touchpads (4)
14 - RGB LED
15 - Powered from USB
17 Detailed information about the board can be found in a `Qomu repository`_ and `Qomu User Guide`_.
29 Below are steps to run Qomu sample application:
33 .. zephyr-app-commands::
[all …]
|
| /Zephyr-latest/include/zephyr/platform/ |
| D | hooks.h | 4 * SPDX-License-Identifier: Apache-2.0
11 * @brief Soc and Board hooks
14 * zephyr architecture and initialization code and the SoC and board specific logic
17 * @note These are all standard soc and board interfaces that are exported from
18 * soc and board specific logic to OS internal logic. These should never be accessed
26 * This hook is implemented by the SoC and can be used to perform any
27 * SoC-specific initialization.
34 * This hook is implemented by the SoC and can be used to perform any
35 * SoC-specific initialization.
42 * This hook is implemented by the SoC and can be used to perform any
[all …]
|
| /Zephyr-latest/samples/basic/rgb_led/ |
| D | README.rst | 1 .. zephyr:code-sample:: rgb-led
3 :relevant-api: pwm_interface
12 There are three single-color component LEDs in an RGB LED. Each component LED
13 is driven by a PWM port where the pulse width is changed from zero to the period
14 indicated in Devicetree. Such period should be fast enough to be above the
16 being steady). The sample causes each LED component to step from dark to max
23 The board must have red, green, and blue LEDs connected via PWM output channels.
26 <dt-guide>` aliases, usually in the :ref:`BOARD.dts file
27 <devicetree-in-out-files>`:
29 - ``red-pwm-led``
[all …]
|
| /Zephyr-latest/doc/build/flashing/ |
| D | configuration.rst | 1 .. _flashing-soc-board-config:
7 :ref:`west flash<west-flashing>`) which allows for customising how commands are used when
9 configuring when commands are ran for groups of board targets. As an example: a multi-core SoC
10 might want to only allow the ``--erase`` argument to be used once for all of the cores in the SoC
21 * ``board.yml`` (in board folder)
27 child, this then contains a map of commands as they would be provided to the flash runner e.g.
28 ``--reset`` followed by a list which specifies the settings for each of these commands (these
30 they apply to using a ``runners`` list value, this can contain ``all`` if it applies to all
31 runners, otherwise must contain each runner that it applies to using the runner-specific name.
32 Groups of board targets can be specified using the ``groups`` key which has a list of board
[all …]
|
| /Zephyr-latest/samples/sensor/mcux_lpcmp/ |
| D | README.rst | 1 .. zephyr:code-sample:: mcux_lpcmp
2 :name: NXP MCUX Low-power Analog Comparator (LPCMP)
3 :relevant-api: sensor_interface
5 Get analog comparator data from an NXP MCUX Low-power Analog Comparator (LPCMP).
10 This sample show how to use the NXP MCUX Low-power Analog Comparator (LPCMP) driver.
12 In this application, the negative input port of the LPCMP is set to 7 which
14 voltage of the DAC is set to 0 (for the specific chip, the user needs to
15 check the reference manual to confirm where this reference voltage comes
16 from), the output voltage of the DAC is equal to (VREF/256)*(data+1), where
18 The positive input port is set to 0, the user needs to check the reference
[all …]
|
| /Zephyr-latest/scripts/west_commands/ |
| D | boards.py | 3 # SPDX-License-Identifier: Apache-2.0
25 # Keep this in sync with the string in west-commands.yml.
39 --------------
42 to the format string are accessed by name.
50 - name: board name
51 - full_name: board full name (typically, its commercial name)
52 - qualifiers: board qualifiers (will be empty for legacy boards)
53 - arch: board architecture (deprecated)
55 - dir: directory that contains the board definition
56 - vendor: board vendor
[all …]
|
| /Zephyr-latest/samples/shields/lmp90100_evb/rtd/ |
| D | README.rst | 3 LMP90100 Sensor AFE Evaluation Board: RTD Sample
9 This sample is provided as an example of how to read the temperature
11 Sensor AFE Evaluation Board shield. The sample is designed for use
12 with a 3-wire PT100 sensor.
14 Please refer to :ref:`lmp90100_evb_shield` for more information on
20 Prior to running the sample application, the LMP90100 EVB must be
21 connected to the development board according to Example #3 ("3-wire
22 RTD Application") in the `LMP90100 Sensor AFE Evaluation Board User's
28 This sample runs with the LMP90100 EVB connected to any development
29 board with a matching Arduino connector. For this example, we use a
[all …]
|
| /Zephyr-latest/samples/net/telnet/ |
| D | README.rst | 1 .. zephyr:code-sample:: telnet-console
3 :relevant-api: shell_api net_core net_if net_mgmt
13 Once up and running, you can connect to the target over the network,
19 - :ref:`networking_with_qemu`
28 These are instructions for how to use this sample application using
29 QEMU on a Linux host connected to a network with DHCP service.
31 To use QEMU for testing, follow the :ref:`networking_with_qemu` guide.
35 .. zephyr-app-commands::
36 :zephyr-app: samples/net/telnet
37 :host-os: unix
[all …]
|
| /Zephyr-latest/doc/ |
| D | glossary.rst | 16 The set of user-supplied files that the Zephyr build system uses
17 to build an application image for a specified board configuration.
18 It can contain application-specific code, kernel configuration settings,
21 to create a custom kernel that makes efficient use of the board's
23 An application can sometimes be built for more than one type of board
25 if it does not require any board-specific capabilities.
28 A binary file that is loaded and executed by the board for which
31 Zephyr kernel code needed to support it. They are compiled as a single,
32 fully-linked binary.
33 Once an application image is loaded onto a board, the image takes control
[all …]
|
