Zephyr

Zephyr RTOS   ::   Device Tree   ::   Kconfig   ::   cmake

Overview

This NN page a holding point for notes and links to external references regarding Zephyr RTOS, and Zephyr RTOS Project. Some key features of Zephyr RTOS include its designers' incorporation of Device Tree Source and Kconfig frameworks in this real time operating system.

As of 2023 April this page under reorganization, pulling multiple local pages into this page and removing older and defunct content - TMH

For device tree and Kconfig see also:

• https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html
  
• https://github.com/ulfalizer/Kconfiglib Kconfig library parser and helper scripts project headed by Ulf Magnusson
  

TODO:

• [ ] Find the meaning of the wrapping function this Zephyr header provides `$workspace/zephyr/include/zephyr/dt-bindings/dt-util.h`.
• [ ] Review the definition and implications of `__ASSERT` symbol defined in `$workspace/zephyr/include/zephyr/sys/__assert.h`.

^ Zephyr Releases

Zephyr RTOS project itself, one of some one hundred twenty projects on Zephyr's Github page, has stable releases which become available once or twice a year. The Zephyr RTOS repository itself is generally at a cutting edge of development. It is `git tagged` or identified as a release candidate, until that point where the work has been finished to review all open issues and developments and create and tag a new stable release.

Zephyr RTOS release notes for various releases are found at https://docs.zephyrproject.org/latest/releases/.

Nordic Semi forks a recent, but not necessarily most recent stable release of Zephyr RTOS Project as part of its NCS Software Development Kit.

A local NN wiki page with some early Zephyr release notes is Zephyr RTOS releases. There may not be much to save from this article, but contributor Ted to review it.

As of summer 2024 Zephyr 3.7.0 LTS has been released:

• https://docs.zephyrproject.org/latest/releases/release-notes-3.7.html

Board porting to move projects from older Zephyr releases to 3.7.0 LTS has a page, and also new `sysbuild` integration:

• https://docs.zephyrproject.org/latest/hardware/porting/board_porting.html#board-porting-guide
• https://docs.zephyrproject.org/latest/build/sysbuild/index.html#sysbuild

^ Zephyr Tutorials

Bootlin blog - intro to setting up and building Zephyr:

• https://bootlin.com/blog/getting-started-with-zephyr/

Bootlin author and engineer Miguel Gasquez Zephyr articles:

• https://bootlin.com/blog/author/miguel-gazquez/

Troubleshooting IoT Cellular Connections with Nordic nRF9160 . . .

• https://blog.golioth.io/category/zephyr/page/2/

Mr. Green's Workshop tutorials on Zephyr and RPi Pico. This article talks about three ways of classifying Zephyr based projects based on their top directory location relative to the instance of Zephyr SDK against which they build.

• https://www.mrgreensworkshop.com/posts/2022-06-10-raspberry-pi-pico-zephyr-os-part-2

^ Zephyr Toolchain Installation

Complete notes for Zephyr toolchain installation and config are provided at Zephyr Project's "Getting Started Guide".

Note: prior to Zephyr 4.1.0 it was necessary to install certain Zephyr tools and toolchain requirements an older way using `west install -r zephyr/scripts/requirements.txt`. precise comment issuecomment-2682627057.

A final or near final step to setting up for Zephyr RTOS based projects, using Zephyr's `west` utility, involves performing a "west initialization" of the new workspace. The two ways --manifest-url and -l (local) are detailed here:

• https://docs.zephyrproject.org/latest/develop/west/built-in.html#west-init

Installation Installation Notes

Installation notes for Linux Mint 20.3, attempted 2025 Q3:

- Step (1) -

$ sudo apt install git cmake ninja-build gperf ccache dfu-util device-tree-compiler wget python-pip python-setuptools python3-wheel tk xz-utils file mak
$ #                          ^^^^^^^^^^^                       ^^^^^^^^^^^^^^^^^^^^                                   ^^^^^^^^^^^^^    ^^^^^^^^

Next step to set up Python virtual environment fails:

 $ python -m venv ~/projects/zephyr-project/.venv
 /usr/bin/python: No module named venv

Python version locally installed is:

 $ /usr/bin/python --version
 Python 2.7.18

Woa, this 2.x version of Python is not something Zephyr RTOS project has required thus far. Has always used python3. The Bootlin instructions may not be well fit for Debian based hosts (already found four package names related to toolchain to be off from what Debian / LinuxMint package mirrors hold.) Switching over to Zephyr Project's "Getting Started" online doc . . .

- Step (1) -

To install compilation tools . . .

- Step (2) -

 $ sudo apt install --no-install-recommends git cmake ninja-build gperf ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1

- Step (3) -

To create Python venv in local Zephyr project workspace . . .

 $ python3 -m venv ~/zephyr-project/.venv
 
 $

- Step (4) -

To check tool versions . . .

 ted@localhost:~/projects$ cmake --version
 cmake version 4.0.3
 
 CMake suite maintained and supported by Kitware (kitware.com/cmake).
 ted@localhost:~/projects$ python3 --version
 Python 3.10.12
 ted@localhost:~/projects$ dtc --version
 Version: DTC 1.6.1
 ted@localhost:~/projects$ python3 -m venv ~/zephyr-project/.venv

- Step (5) -

To start a python virtual environment session . . .

 $ source ~/projects/zephyr-project/.venv/bin/activate
 (.venv) ted@localhost:~/projects

- Step (6) -

To install `west` . . .

$ pip install west
Defaulting to user installation because normal site-packages is not writeable
Collecting west
  Downloading west-1.4.0-py3-none-any.whl (104 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 104.8/104.8 KB 1.5 MB/s eta 0:00:00
Requirement already satisfied: PyYAML>=5.1 in /usr/lib/python3/dist-packages (from west) (5.4.1)
Requirement already satisfied: colorama in /usr/lib/python3/dist-packages (from west) (0.4.4)
Requirement already satisfied: packaging in /usr/lib/python3/dist-packages (from west) (21.3)
Collecting pykwalify
  Using cached pykwalify-1.8.0-py2.py3-none-any.whl (24 kB)
Requirement already satisfied: docopt>=0.6.2 in /usr/lib/python3/dist-packages (from pykwalify->west) (0.6.2)
Collecting python-dateutil>=2.8.0
  Using cached python_dateutil-2.9.0.post0-py2.py3-none-any.whl (229 kB)
Collecting ruamel.yaml>=0.16.0
  Using cached ruamel.yaml-0.18.14-py3-none-any.whl (118 kB)
Requirement already satisfied: six>=1.5 in /usr/lib/python3/dist-packages (from python-dateutil>=2.8.0->pykwalify->west) (1.16.0)
Collecting ruamel.yaml.clib>=0.2.7
  Downloading ruamel.yaml.clib-0.2.12-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (722 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 722.2/722.2 KB 3.1 MB/s eta 0:00:00
Installing collected packages: ruamel.yaml.clib, python-dateutil, ruamel.yaml, pykwalify, west
Successfully installed pykwalify-1.8.0 python-dateutil-2.9.0.post0 ruamel.yaml-0.18.14 ruamel.yaml.clib-0.2.12 west-1.4.0
(.venv) ted@localhost:~/projects$

- Step (7) -

. . .

- Step (8) -

Call west with argument `zephyr-export` . . .

(.venv) ted@localhost:~/projects/zephyr-project$ west zephyr-export
Zephyr (/home/ted/projects/zephyr-project/zephyr/share/zephyr-package/cmake)
has been added to the user package registry in:
~/.cmake/packages/Zephyr

ZephyrUnittest (/home/ted/projects/zephyr-project/zephyr/share/zephyrunittest-package/cmake)
has been added to the user package registry in:
~/.cmake/packages/ZephyrUnittest

(.venv) ted@localhost:~/projects/zephyr-project$

Initialize west environment . . .

- Step (9) -

This does not look good, not consistent with running this command in a Python virtual environment:

(.venv) ted@localhost:~/projects/zephyr-project$ west packages pip --install
FATAL ERROR: Running pip install outside of a virtual environment
(.venv) ted@localhost:~/projects/zephyr-project$

Zephyr flash runners

Embedded Artists article on Zephyr, mentions `linkserver` from NXP:

• https://developer.embeddedartists.com/docs-mcu/howto/zephyr/

^ Zephyr toolchain pitfalls

• https://interrupt.memfault.com/blog/practical_zephyr_west

^ project location

2025-10-27: Strange issue in which project builds against Zephyr but ``west update`` does not update Zephyr to changed revision in project manifest. Some commands to investigate the current sitation:

(.venv) ted@localhost:~/projects/zephyr-project/psas/lv3.1-recovery/controlSystem/RecoveryBoard/firmware-zephyr/apps$

$ west manifest --path

/home/ted/projects/zephyr-project/zephyr/west.yml

$ west list
manifest     zephyr                       HEAD                                     N/A
acpica       modules/lib/acpica           8d24867bc9c9d81c81eeac59391cda59333affd4 https://github.com/zephyrproject-rtos/acpica
cmsis        modules/hal/cmsis            4b96cbb174678dcd3ca86e11e1f24bc5f8726da0 https://github.com/zephyrproject-rtos/cmsis
cmsis-dsp    modules/lib/cmsis-dsp        6489e771e9c405f1763b52d64a3f17a1ec488ace https://github.com/zephyrproject-rtos/cmsis-dsp
cmsis-nn     modules/lib/cmsis-nn         ea987c1ca661be723de83bd159aed815d6cbd430 https://github.com/zephyrproject-rtos/cmsis-nn
edtt         tools/edtt                   b9ca3c7030518f07b7937dacf970d37a47865a76 https://github.com/zephyrproject-rtos/edtt
fatfs        modules/fs/fatfs             427159bf95ea49b7680facffaa29ad506b42709b https://github.com/zephyrproject-rtos/fatfs
hal_adi      modules/hal/adi              dee9a7b1eff13a9da0560daf8842d61657f9d61e https://github.com/zephyrproject-rtos/hal_adi
hal_altera   modules/hal/altera           4fe4df959d4593ce66e676aeba0b57f546dba0fe https://github.com/zephyrproject-rtos/hal_altera
hal_ambiq    modules/hal/ambiq            e25327f026df1ee08f1bf01a4bbfeb5e5f4026f1 https://github.com/zephyrproject-rtos/hal_ambiq
hal_atmel    modules/hal/atmel            56d60ebc909ad065bf6554cee73487969857614b https://github.com/zephyrproject-rtos/hal_atmel
hal_espressif modules/hal/espressif        01fc4ec49b8b178d7aea765cdb8709311ee4c50b https://github.com/zephyrproject-rtos/hal_espressif
hal_ethos_u  modules/hal/ethos_u          8e2cf756b474eff9a32a9bdf1775d9620f1eadcf https://github.com/zephyrproject-rtos/hal_ethos_u
hal_gigadevice modules/hal/gigadevice       2994b7dde8b0b0fa9b9c0ccb13474b6a486cddc3 https://github.com/zephyrproject-rtos/hal_gigadevice
hal_infineon modules/hal/infineon         f25734a72c585f6675e8254a382e80e78a3cd03a https://github.com/zephyrproject-rtos/hal_infineon
hal_intel    modules/hal/intel            0905a528623de56b1bedf817536321bcdbc0efae https://github.com/zephyrproject-rtos/hal_intel
hal_microchip modules/hal/microchip        71eba057c0cb7fc11b6f33eb40a82f1ebe2c571c https://github.com/zephyrproject-rtos/hal_microchip
hal_nordic   modules/hal/nordic           ab5cb2e2faeb1edfad7a25286dcb513929ae55da https://github.com/zephyrproject-rtos/hal_nordic
hal_nuvoton  modules/hal/nuvoton          466c3eed9c98453fb23953bf0e0427fea01924be https://github.com/zephyrproject-rtos/hal_nuvoton
hal_nxp      modules/hal/nxp              862e001504bd6e0a4feade6a718e9f973116849c https://github.com/zephyrproject-rtos/hal_nxp
hal_openisa  modules/hal/openisa          eabd530a64d71de91d907bad257cd61aacf607bc https://github.com/zephyrproject-rtos/hal_openisa
hal_quicklogic modules/hal/quicklogic       bad894440fe72c814864798c8e3a76d13edffb6c https://github.com/zephyrproject-rtos/hal_quicklogic
hal_renesas  modules/hal/renesas          af77d7cdfeeff290593e7e99f54f0c1e2a3f91e6 https://github.com/zephyrproject-rtos/hal_renesas
hal_rpi_pico modules/hal/rpi_pico         fba7162cc7bee06d0149622bbcaac4e41062d368 https://github.com/zephyrproject-rtos/hal_rpi_pico
hal_silabs   modules/hal/silabs           a09dd1b82b24aa3060e162c0dfa40026c0dba450 https://github.com/zephyrproject-rtos/hal_silabs
hal_st       modules/hal/st               b77157f6bc4395e398d90ab02a7d2cbc01ab2ce7 https://github.com/zephyrproject-rtos/hal_st
hal_stm32    modules/hal/stm32            f1317150eac951fdd8259337a47cbbc4c2e6d335 https://github.com/zephyrproject-rtos/hal_stm32
hal_telink   modules/hal/telink           4226c7fc17d5a34e557d026d428fc766191a0800 https://github.com/zephyrproject-rtos/hal_telink
hal_ti       modules/hal/ti               b85f86e51fc4d47c4c383d320d64d52d4d371ae4 https://github.com/zephyrproject-rtos/hal_ti
hal_wurthelektronik modules/hal/wurthelektronik  e5bcb2eac1bb9639ce13b4dafc78eb254e014342 https://github.com/zephyrproject-rtos/hal_wurthelektronik
hal_xtensa   modules/hal/xtensa           a2d658525b16c57bea8dd565f5bd5167e4b9f1ee https://github.com/zephyrproject-rtos/hal_xtensa
hostap       modules/lib/hostap           a90df86d7c596a5367ff70c2b50c7f599e6636f3 https://github.com/zephyrproject-rtos/hostap
libmetal     modules/hal/libmetal         a6851ba6dba8c9e87d00c42f171a822f7a29639b https://github.com/zephyrproject-rtos/libmetal
liblc3       modules/lib/liblc3           1a5938ebaca4f13fe79ce074f5dee079783aa29f https://github.com/zephyrproject-rtos/liblc3
littlefs     modules/fs/littlefs          408c16a909dd6cf128874a76f21c793798c9e423 https://github.com/zephyrproject-rtos/littlefs
loramac-node modules/lib/loramac-node     fb00b383072518c918e2258b0916c996f2d4eebe https://github.com/zephyrproject-rtos/loramac-node
lvgl         modules/lib/gui/lvgl         2b498e6f36d6b82ae1da12c8b7742e318624ecf5 https://github.com/zephyrproject-rtos/lvgl
mbedtls      modules/crypto/mbedtls       a78176c6ff0733ba08018cba4447bd3f20de7978 https://github.com/zephyrproject-rtos/mbedtls
mcuboot      bootloader/mcuboot           ea2410697dd0262edec041a0ccb07fdbde7c1aff https://github.com/zephyrproject-rtos/mcuboot
mipi-sys-t   modules/debug/mipi-sys-t     71ace1f5caa03e56c8740a09863e685efb4b2360 https://github.com/zephyrproject-rtos/mipi-sys-t
net-tools    tools/net-tools              7c7a856814d7f27509c8511fef14cec21f7d0c30 https://github.com/zephyrproject-rtos/net-tools
nrf_hw_models modules/bsim_hw_models/nrf_hw_models 6c389b9b5fa0a079cd4502e69d375da4c0c289b7 https://github.com/zephyrproject-rtos/nrf_hw_models
open-amp     modules/lib/open-amp         76d2168bcdfcd23a9a7dce8c21f2083b90a1e60a https://github.com/zephyrproject-rtos/open-amp
openthread   modules/lib/openthread       3873c6fcd5a8a9dd01b71e8efe32ef5dc7923bb1 https://github.com/zephyrproject-rtos/openthread
percepio     modules/debug/percepio       b68d17993109b9bee6b45dc8c9794e7b7bce236d https://github.com/zephyrproject-rtos/percepio
picolibc     modules/lib/picolibc         764ef4e401a8f4c6a86ab723533841f072885a5b https://github.com/zephyrproject-rtos/picolibc
segger       modules/debug/segger         b011c45b585e097d95d9cf93edf4f2e01588d3cd https://github.com/zephyrproject-rtos/segger
tinycrypt    modules/crypto/tinycrypt     1012a3ebee18c15ede5efc8332ee2fc37817670f https://github.com/zephyrproject-rtos/tinycrypt
trusted-firmware-m modules/tee/tf-m/trusted-firmware-m 60ebade5d3d381a210af90191e475d8870b8adbc https://github.com/zephyrproject-rtos/trusted-firmware-m
trusted-firmware-a modules/tee/tf-a/trusted-firmware-a 713ffbf96c5bcbdeab757423f10f73eb304eff07 https://github.com/zephyrproject-rtos/trusted-firmware-a
uoscore-uedhoc modules/lib/uoscore-uedhoc   84ef879a46d7bfd9a423fbfb502b04289861f9ea https://github.com/zephyrproject-rtos/uoscore-uedhoc
zcbor        modules/lib/zcbor            75d088037eb237b18e7ec1f47c9ce494b9b95aab https://github.com/zephyrproject-rtos/zcbor

^ Zephyr Build Process

Zephyr based applications involve a build process which includes a kernel configuration or Kconfig parser, a Device Tree Source compiler `dtc`, and typically but not limited to a C or C++ compiler.

^ Build menuconfig target

How to build Zephyr app menuconfig target.

Zephyr's use of Kconfig has allowed for Zephyr project team to provide a 'menuconfig' build target as part of Zephyr's build configuration. This means that Kconfig options can be studied and changed, and saved, via an ncurses based interactive tool.

Here is an example invocation to build the parts of a Zephyr based application sufficient to provide a menuconfig interactive session with that project. The option past the double dashes spells out a relative path which fits the scenario in which the project's "primary" CMakeLists.txt file exists two directories below the project's `boards` directory:

 $ west build -b <board/soc_or_mcu/core> -t menuconfig -- -DBOARD_ROOT=../..

Older, to review and sort:

Possible to use Kconfig to pass along compiler options, such as `CONFIG_COMPILER_OPT`:

• https://github.com/zephyrproject-rtos/zephyr/issues/46382

^ Zephyr Issues on Github

An interesting place and a good place to learn about Zephyr is its issue tracker on Github. The following URLs link to a modest number of issues, which may be useful to follow and learn how the problems are solved and what parts of Zephyr code they involve . . .

Flash alignment issue #93779. Involves `zbus`, C++ and video library:

• https://github.com/zephyrproject-rtos/zephyr/issues/93779

^ Things to Investigate

These bullet point items are questions to answer.

[ ] Zephyr 3.7.0 holds cbprintf sources in `zephyr/lib/os`. Why there? These relate to ulibc or chosen C libraries in general?

[ ] Review and document each file in `zephyr/lib/libc/minimal/include`.

^ Zephyr Internals

Zephyr RTOS run time starting point, for Zephyr v3.4.0 is function function z_cstart() in source file init.c.

Zephyr util.h header file:

${ZEPHYR_WORKSPACE}/zephyr/include/zephyr/sys/util.h:43:#define POINTER_TO_UINT(x) ((uintptr_t) (x))

Error codes enumerated in errno.h:

zephyr/lib/libc/minimal/include/errno.h

^ Zephyr Macros

TODO 2024-07-31: add links and notes on Zephyr RTOS util.h header file, a collection of macros and helper functions for common task.

Zephyr RTOS employs a lot of macros throughout its code base. As a starting point, Zephyr's atomic services use macros including ATOMIC_BITMAP_SIZE. This macro is defined in file . . . atomic.h.

Excerpt from atomic.h:

 85  * @brief This macro computes the number of atomic variables necessary to
 86  * represent a bitmap with @a num_bits.
 87  *
 88  * @param num_bits Number of bits.
 89  */
 90 #define ATOMIC_BITMAP_SIZE(num_bits) (ROUND_UP(num_bits, ATOMIC_BITS) / ATOMIC_BITS)

^ Zephyr RTOS libc Choice And Constructs

Zephyr RTOS project uses a particular version of C library `libc`. Possibly entirely decoupled from this, Zephyr project uses in its toolchain a certain gcc cross compiler, which ships with some C header files containing important definitions.

Zephyr based apps coded in C can have routines qualified with the macro implemented type `__printf_like`. This macro has its definition in at least two files:

Figure x: definition for __printf_like:
"zephyr/include/zephyr/toolchain/gcc.h"
"zephyr/lib/libc/minimal/source/stdout/fprintf.c"

This may be worth exploring further. See also NetBSD online manual page for C / Unix programming topic "attribute" at https://man.netbsd.org/attribute.3. There is also a good forum post explanation on this macro at https://stackoverflow.com/questions/5825270/printflike-modifier.

^ Interrupts

Zephyr RTOS provides some API and code facilities to support hardware interrupts, but each processor architecture has its own ways of implementing interrupts. This local page section to cover issues and solutions to Zephyr application design with interrupts, and how to code for a given target processor.

First references:

• https://docs.zephyrproject.org/3.3.0/kernel/services/interrupts.html#interrupts
• https://docs.zephyrproject.org/3.3.0/kernel/services/interrupts.html#c.k_is_in_isr

• https://docs.zephyrproject.org/3.3.0/kernel/services/other/fatal.html#spurious-interrupts

A Zephyr documentation on architecture porting, with references to lower level interrupt configuration code:

• https://docs.zephyrproject.org/3.3.0/hardware/porting/arch.html#interrupt-and-exception-handling

Zephyr's API macro for connecting a routine to a hardware interrupt is defined in `irq.h`:

 31 /**
 32  * @brief Initialize an interrupt handler.
 33  *
 34  * This routine initializes an interrupt handler for an IRQ. The IRQ must be
 35  * subsequently enabled before the interrupt handler begins servicing
 36  * interrupts.
 37  *
 38  * @warning
 39  * Although this routine is invoked at run-time, all of its arguments must be
 40  * computable by the compiler at build time.
 41  *
 42  * @param irq_p IRQ line number.
 43  * @param priority_p Interrupt priority.
 44  * @param isr_p Address of interrupt service routine.
 45  * @param isr_param_p Parameter passed to interrupt service routine.
 46  * @param flags_p Architecture-specific IRQ configuration flags..
 47  */
 48 #define IRQ_CONNECT(irq_p, priority_p, isr_p, isr_param_p, flags_p) \
 49         ARCH_IRQ_CONNECT(irq_p, priority_p, isr_p, isr_param_p, flags_p)

^ Zephyr Threads

An important executing element of a Zephyr based app is an application defined thread. Zephyr based applications written in C will normally have at least one app side thread , which Zephyr will default to giving the name `main`. This name reflects that application code begins executing from a function named `main()`, as is a long standing convention of C language.

Zephyr based applications can define threads of their own. This is a multi-step action in the code, both at time of development and at run time. Application defined threads are given numeric identifiers by Zephyr at run time; only "main line" code of the app gets a named thread by default. Developers however may optionally call a _Zephyr_API_ to give additional threads human meaningful names.

^ Anatomy of a Zephyr thread

To create a Zephyr thread in an app involves declarations of certain thread elements, a call to Zephyr's thread_create API function, and at minimum an entry point function for the given thread. The following pieces:

• thread data structure
• thread priority
• thread stack size
• call to Zephyr "create thread" API
• thread entry point function

In English language, creation of a Zephyr application thread in simple terms involves the steps:

(1) create a thread's data structure of type `struct k_thread`
(2) pound define given thread's priority
(3) pound define given thread's static memory stack size in bytes
(4) call Zephyr's thread creation API function with its required ten parameters
(5) define an entry point function for the thread, which other application code most likely to call to start thread execution

A bit of repetition: Zephyr thread's data structure, priority and stack size are programmed in a declarative way. Stack size and thread data are typically declared as follows, the first of these involves a function like macro:

K_THREAD_STACK_DEFINE(thread_led_stack_area, THREAD_LED_STACK_SIZE);

struct k_thread thread_led_data;

Interestingly, the stack area parameter first parameter to macro like function is defined in the above macro, and then referenced typically only one or two times, in the call to Zephyr's `k_thread_create()` API.

The call to `thread_create` <- REVIEW looks like this:

int initialize_thread_led(void)
{
    int rstatus = 0;

    k_tid_t task_led_tid = k_thread_create(&thread_led_data,
                                           thread_led_stack_area,
                                           K_THREAD_STACK_SIZEOF(thread_led_stack_area),
                                           thread_led_entry_point,
                                           NULL, NULL, NULL,
                                           THREAD_LED_PRIORITY,
                                           0,
                                           K_MSEC(1000)); // K_NO_WAIT);

// REF https://docs.zephyrproject.org/2.6.0/reference/kernel/threads/index.html?highlight=k_thread_create#c.k_thread_name_set
// int k_thread_name_set(k_tid_t thread, const char *str)

    rstatus = k_thread_name_set(task_led_tid, MODULE_ID__THREAD_LED);
    if ( rstatus == 0 ) { } // avoid compiler warning about unused variable - TMH

    return (int)task_led_tid;
}

^ Thread API references

• https://docs.zephyrproject.org/latest/reference/kernel/threads/index.html?highlight=k_thread_define#c.K_THREAD_DEFINE
• https://docs.zephyrproject.org/latest/reference/kernel/threads/index.html?highlight=k_thread_create#c.k_thread_name_set

Zephyr mutex

./fatfs/zfs_ffsystem.c:61: return (int)(k_mutex_lock(&fs_reentrant_mutex[vol], FF_FS_TIMEOUT) == 0);

ed@localhost:~/projects/zephyr-project/modules$ grep -nr FF_FS_TIMEOUT ./* ./fatfs/zephyr_fatfs_config.h:70:#undef FF_FS_TIMEOUT ./fatfs/zephyr_fatfs_config.h:73:#define FF_FS_TIMEOUT K_FOREVER ./fatfs/zfs_ffsystem.c:61: return (int)(k_mutex_lock(&fs_reentrant_mutex[vol], FF_FS_TIMEOUT) == 0); ./fs/fatfs/include/ffconf.h:279:#define FF_FS_TIMEOUT 1000

^ Zephyr Hardware Abstractions

Zephyr RTOS 3.4.0 project as of 2024 Q1 supports several MCU architectures plus an array of development boards. Part of the framework for this support is a hardware abstraction layer, many of whose manifesting files are found along side Zephyr RTOS source tree in `$workspace/modules`. The path `$workspace/modules/hal` contains vendor provided hardware libraries.

An example of a Zephyr HAL is `$workspace/modules/hal/nxp`. This said, for Zephyr's supported in tree drivers there are sources which appear in Zephyr source tree itself to inform Zephyr about certain details of vendor HALs.

An example of source tree HAL references is the set of device tree source bindings files which live in `$workspace/zephyr/dts/bindings`. As a case in point details for NXP's LPC family MCU pin and peripheral configurations are expressed in the file:

  $workspace/zephyr/dts/bindings/pinctrl/nxp,lpc-iocon-pinctrl.yaml

TODO [ ] Complete the exploration of NXP pin control mark up file.

Topic:

Zephyr defines various on-chip peripherals such as I/O port controllers as C structures. An example of an I/O pin structure is `struct gpio_dt_spec *gpio`. This passed as a parameter to a function may then be used to set and to clear the logic level on the given pin:

 rc = gpio_pin_set_dt(gpio, 0);

Before this can take place, a Zephyr device tree macro needs to be placed in the source code such as with local scope in a routine:

 struct const gpio_dt_spec system_ready_gpio = GPIO_DT_SPEC_GET(SYSTEM_READY_NODE, gpios);

or file scoped as a static variable:

 static const struct gpio_dt_spec rocket_ready_gpio = GPIO_DT_SPEC_GET(ROCKET_READY_NODE, gpios);

^ Zephyr Drivers

Zephyr RTOS has a notion of in-tree drivers and out-of-tree drivers. The following local page section begin to cover these topics with a few references to specific peripheral drivers.

^ In-tree drivers

Early in contributor Ted's learning and use of Zephyr RTOS, "in tree" drivers and "out of tree" drivers concepts seemed distinct and referent to code bases which were completely located within Zephyr's source tree, and the latter located outside of the Zephyr RTOS source tree, respectively. This is not a correct view. Rather, Zephyr's "in tree" drivers have code in the Zephyr source tree which nearly always calls third party MCU library code bases.

Out-out-tree drivers in contrast have their code bases entirely outside of Zephyr RTOS source tree.

Zephyr RTOS code provides standardized structures to support peripherals and devices. These structures nearly always involve function pointers which ultimately point to a given target MCU or MCU family's driver library or Software Development Kit (SDK) code base.

Zephyr RTOS code base makes heavy use of function pointers and of macros. These pointers and macros can make it a challenge to locate a function definiton during static code analysis. The `ctags` utility does not always have a clear chain of symbols to follow to get to the ultimate definition of a function.

This NN article section on Zephyr in-tree drivers touches on this matter. The subsection here on SPI NOR FLASH touches on this challenge, and looks at one way of following list files from build artifacts, to get closer to driver function definitions.

^ ADC

Zephyr RTOS' in-tree Analog to Digital Converter (ADC) driver documentation point:

• https://docs.zephyrproject.org/3.2.0/hardware/peripherals/adc.html#c.adc_channel_cfg.channel_id

ADC in combination with resistor dividers and buttons leads to adc-keys node type, with child node with property "zephyr,code", detailed here:

• https://docs.zephyrproject.org/3.7.0/build/dts/api/bindings/input/adc-keys.html




^ UART

Zephyr in-tree UART driver supports polled, interrupt driven, and DMA based UART configurations. First link to section of Zephyr 3.3.0 documentation on UART in-tree driver:

• https://docs.zephyrproject.org/3.3.0/hardware/peripherals/uart.html#asynchronous-api

We are curious to see what support NXP offers in Zephyr 3.3.0 for UART DMA configuration. Here are a couple of blog posts which may shed some light on needed code, and which code we need look for:

• https://medium.com/embedded-iot/how-to-write-uart-dma-driver-for-zephyr-9b5b7ed23c6c
  
• https://medium.com/embedded-iot/how-to-write-uart-dma-driver-for-zephyr-part-2-5a035328cc35
  

On the topic of Zephyr UART via DMA support:

• https://devzone.nordicsemi.com/f/nordic-q-a/46426/dma-for-uart-with-zephyr-on-nrf9160
A Nordic ncs sample application, likely good for any architecture independent Kconfig symbols:
• https://github.com/nrfconnect/sdk-zephyr/tree/main/tests/drivers/uart/uart_async_api

Some mention of supported boards and dts overlay files in this testing yaml file:

• https://github.com/nrfconnect/sdk-zephyr/blob/main/tests/drivers/uart/uart_async_api/testcase.yaml
• https://docs.zephyrproject.org/3.7.0/doxygen/html/group__uart__interrupt.html#gab10942076ac47ecff29e924098049398




^ SPI

One specific SPI in-tree driver in Zephyr 3.4.0 is spi_mcux_flexcomm.c.

The way Zephyr's spi.h and spi_mcux_flexcomm.c files connect to one another in terms of function calls is not clear, but there is a connection.

Using `ctags` to follow symbol and entity definitions seems to give an implied cyclic definition of `spi_transceive_dt()` API call in a Zephyr based app. API spi_transceive_dt() maps to spi_transceive() per ctags results run in the Zephyr source tree. But the function definition ultimately points to a reference to api->transceive. Somehow, perhaps, the nature of the structures and pointers used to define a generalized interface which maps to a particular target MCU family makes it not possible for ctags to traverse the application side SPI transceive call to its ultimate definition.

The seeming circular definition point appears here in https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/drivers/spi.h#L761.

Zephyr's mandatory SPI driver API is called out in https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/drivers/spi.h#L647.

NXP / Freescale driver contribution spi_mcux_flexcomm.c provides this API here:

• https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/spi/spi_mcux_flexcomm.c#L803

This excerpt is a snapshot of Zephyr 3.4.0, commit 356c8cbe63ae. While it will change over time it is worth looking at here:

661 
662 static int transceive(const struct device *dev,
663                       const struct spi_config *spi_cfg,
664                       const struct spi_buf_set *tx_bufs,
665                       const struct spi_buf_set *rx_bufs,
666                       bool asynchronous,
667                       spi_callback_t cb,
668                       void *userdata)
669 {
670         struct spi_mcux_data *data = dev->data;
671         int ret;
672 
673         spi_context_lock(&data->ctx, asynchronous, cb, userdata, spi_cfg);
674 
675         ret = spi_mcux_configure(dev, spi_cfg);
676         if (ret) {
677                 goto out;
678         }
679 
680         spi_context_buffers_setup(&data->ctx, tx_bufs, rx_bufs, 1);
681 
682         spi_context_cs_control(&data->ctx, true);
683 
684         spi_mcux_transfer_next_packet(dev);
685 
686         ret = spi_context_wait_for_completion(&data->ctx);
687 out:
688         spi_context_release(&data->ctx, ret);
689 
690         return ret;
691 }
692 
693 static int spi_mcux_transceive(const struct device *dev,
694                                const struct spi_config *spi_cfg,
695                                const struct spi_buf_set *tx_bufs,
696                                const struct spi_buf_set *rx_bufs)
697 {
698 #ifdef CONFIG_SPI_MCUX_FLEXCOMM_DMA
699         return transceive_dma(dev, spi_cfg, tx_bufs, rx_bufs, false, NULL, NULL);
700 #endif
701         return transceive(dev, spi_cfg, tx_bufs, rx_bufs, false, NULL, NULL);
702 }
703 

Also worth noting:

 ./mcux/mcux-sdk/drivers/spi/fsl_spi.c:1052:status_t SPI_MasterTransferNonBlocking(SPI_Type *base, spi_master_handle_t *handle, spi_transfer_t *xfer

An subtle interesting facet of Zephyr in-tree SPI driver is its code to deal with TX and RX buffers whose lengths differ. See code at and around:

 https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/spi/spi_mcux_flexcomm.c#L106

- Recent code contributions to Zephyr SPI drivers -

A recent contributor issue to Zephyr in-tree driver code:

• https://github.com/zephyrproject-rtos/zephyr/pull/66402/commits/01210979f941730690e273a2dc68570450011c43




^ SPI NOR FLASH

Zephyr provides a SPI NOR FLASH driver API, which depending upon a developer's target MCU points to one or another third part SDK or driver code. When working working with Zephyr 3.4.0 and a Macronix FLASH memory device, `ctags` isn't sufficient to locate the flash erase function definition. A different search is needed.

Search steps:

Step (1) Begin with pattern match on project build artifact `build/cpu0/zephyr.lst`:

Excerpt:

25552 
25553 10012f36 <flash_erase>:
25554         rc = api->erase(dev, offset, size);
25555 10012f36:       6883            ldr     r3, [r0, #8]
25556 10012f38:       689b            ldr     r3, [r3, #8]
25557 10012f3a:       4718            bx      r3
25558   

There are other instances of routine name `flash_erase` but the clue in this excerpt is the data structure `api`. A search in . . .

Step (2) Use ctags in app source file on API call `flash_erase`. This goes to file `"$workspace/zephyr/include/zephyr/drivers/espi.h"`. In this file find:

 458 __subsystem struct espi_driver_api {
 459         espi_api_config config;
 460         espi_api_get_channel_status get_channel_status;
 461         espi_api_read_request read_request;
 462         espi_api_write_request write_request;
 463         espi_api_lpc_read_request read_lpc_request;
 464         espi_api_lpc_write_request write_lpc_request;
 465         espi_api_send_vwire send_vwire;
 466         espi_api_receive_vwire receive_vwire;
 467         espi_api_send_oob send_oob;
 468         espi_api_receive_oob receive_oob;
 469         espi_api_flash_read flash_read;
 470         espi_api_flash_write flash_write;
 471         espi_api_flash_erase flash_erase;
 472         espi_api_manage_callback manage_callback;
 473 };

Step (3) In zephyr.lst file use `ctags` to navigate to file `$workspace/zephyr/drivers/flash/soc_flash_nrf.c`. Here find:

482 static int erase(uint32_t addr, uint32_t size)
483 {
484         struct flash_context context = {  
485                 .flash_addr = addr,
486                 .len = size,
487 #ifndef CONFIG_SOC_FLASH_NRF_RADIO_SYNC_NONE
488                 .enable_time_limit = 0, /* disable time limit */
489 #endif /* !CONFIG_SOC_FLASH_NRF_RADIO_SYNC_NONE */ 
490 #if defined(CONFIG_SOC_FLASH_NRF_PARTIAL_ERASE)
491                 .flash_addr_next = addr
492 #endif
493         };
494 
495         return  erase_op(&context);
496 }

Given this it looks like step (2) did not directly help us reach the definition of `flash_erase()` API. The apparent routine referenced on line 495 above has in same file the definition:

328 static int erase_op(void *context)
329 {
330         uint32_t pg_size = nrfx_nvmc_flash_page_size_get();
331         struct flash_context *e_ctx = context;
332 
333 #ifndef CONFIG_SOC_FLASH_NRF_RADIO_SYNC_NONE
334         uint32_t i = 0U;
335 
336         if (e_ctx->enable_time_limit) {
337                 nrf_flash_sync_get_timestamp_begin();
338         }
339 #endif /* !CONFIG_SOC_FLASH_NRF_RADIO_SYNC_NONE */
340 
341 #ifdef CONFIG_SOC_FLASH_NRF_UICR
342         if (e_ctx->flash_addr == (off_t)NRF_UICR) {
343                 if (SUSPEND_POFWARN()) {
344                         return -ECANCELED;
345                 }
346 
347                 (void)nrfx_nvmc_uicr_erase();
348                 RESUME_POFWARN();
349                 return FLASH_OP_DONE;
350         }
351 #endif
352 
353         do {
354                 if (SUSPEND_POFWARN()) {
355                         return -ECANCELED;
356                 }
357 
358 #if defined(CONFIG_SOC_FLASH_NRF_PARTIAL_ERASE)
359                 if (e_ctx->flash_addr == e_ctx->flash_addr_next) {
360                         nrfx_nvmc_page_partial_erase_init(e_ctx->flash_addr,
361                                 CONFIG_SOC_FLASH_NRF_PARTIAL_ERASE_MS);
362                         e_ctx->flash_addr_next += pg_size;
363                 }
364
365                 if (nrfx_nvmc_page_partial_erase_continue()) {
366                         e_ctx->len -= pg_size;
367                         e_ctx->flash_addr += pg_size;
368                 }
369 #else
370                 (void)nrfx_nvmc_page_erase(e_ctx->flash_addr);
371                 e_ctx->len -= pg_size;
372                 e_ctx->flash_addr += pg_size;
373 #endif /* CONFIG_SOC_FLASH_NRF_PARTIAL_ERASE */
374 
375                 RESUME_POFWARN();
376 
377 #ifndef CONFIG_SOC_FLASH_NRF_RADIO_SYNC_NONE
378                 i++;
379 
380                 if (e_ctx->enable_time_limit) {
381                         if (nrf_flash_sync_check_time_limit(i)) {
382                                 break;
383                         }
384 
385                 }
386 #endif /* !CONFIG_SOC_FLASH_NRF_RADIO_SYNC_NONE */
387 
388         } while (e_ctx->len > 0);
389 
390         return (e_ctx->len > 0) ? FLASH_OP_ONGOING : FLASH_OP_DONE;
391 }

2024-11-26 Tuesday

Zephyr issue regarding SFDP magic 444653ff invalid. Run time error message is "SFDP magic 444653ff invalid".

• https://github.com/zephyrproject-rtos/zephyr/issues/63390
• https://community.st.com/t5/stm32-mcus-products/reading-worng-first-byte-from-serial-flash/td-p/453071




^ Driver Code Factoring

In-tree Zephyr drivers exist as part of Zephyr's source code tree, in other words, the code repo that entails Zephyr RTOS itself. Out-of-tree drivers written to cooperate with Zephyr exist outside of Zephyr's source code tree and are often their own independent code projects. See however this local page's In-tree drivers section for greater detail on driver code factoring in Zephyr RTOS.

Example Zephyr app and supporting code base which entails an out-of-tree driver factored along side app code:

• https://github.com/nrfconnect/ncs-example-application

^ Out-of-tree drivers

Stub section for Zephyr out-of-tree drivers.

^ Zephyr Work Queues

Zephyr RTOS provides an RTOS feature called a work queue, which developers may define and use. Zephyr also provides a system work queue. The following Golioth blog post talks a bit about these:

• https://blog.golioth.io/zephyr-threads-work-queues-message-queues-and-how-we-use-them/ Zephyr threads versus work queues

^ Zephyr RTOS Logger and Backend Features

Zephyr has five log levels ranging from LOG_LEVEL_NONE to LOG_LEVEL_DBG. These are defined in log_core.h.

Printing of log messages and other strings can be deferred, and there is a mechanism in place in Zephyr RTOS project called `cbprintf packages` to help in this:

• https://docs.zephyrproject.org/latest/services/formatted_output.html#cbprintf-packaging

It is also possible to reduce code size in a Zephyr app by avoiding libc library functions in the s*printf() family:

• https://docs.zephyrproject.org/latest/services/formatted_output.html#formatted-output

Following links need updating to Zephyr 3.4.0:

• https://docs.zephyrproject.org/2.6.0/reference/logging/index.html#logger-backend-interface
• https://docs.zephyrproject.org/2.6.0/reference/logging/index.html#default-frontend

Zephyr's thread_analyzer when not configured to dump reports to printk() instead sends thread data to LOG_INF(). Excerpt from Zephyr file `./zephyr/subsys/debug/thread_analyzer.c`:

 11 #include <kernel.h>
 12 #include <debug/thread_analyzer.h>
 13 #include <debug/stack.h>
 14 #include <kernel.h>
 15 #include <logging/log.h>
 16 #include <stdio.h>
 17 
 18 LOG_MODULE_REGISTER(thread_analyzer, CONFIG_THREAD_ANALYZER_LOG_LEVEL);
 19 
 20 #if IS_ENABLED(CONFIG_THREAD_ANALYZER_USE_PRINTK)
 21 #define THREAD_ANALYZER_PRINT(...) printk(__VA_ARGS__)
 22 #define THREAD_ANALYZER_FMT(str)   str "\n"
 23 #define THREAD_ANALYZER_VSTR(str)  (str)
 24 #else
 25 #define THREAD_ANALYZER_PRINT(...) LOG_INF(__VA_ARGS__)
 26 #define THREAD_ANALYZER_FMT(str)   str
 27 #define THREAD_ANALYZER_VSTR(str)  log_strdup(str)
 28 #endif

Zephyr macro `LOG_INF` is in turn defined:

ted@localhost:~/projects/zephyr-based/z4-sandbox-kionix-work/zephyr$ grep -nr LOG_INF ./* | grep define

./include/logging/log.h:61:#define LOG_INF(...)   Z_LOG(LOG_LEVEL_INF, __VA_ARGS__)

Define of Z_LOG:

ted@localhost:~/projects/zephyr-based/z4-sandbox-kionix-work/zephyr$ grep -nr 'Z_LOG[^_]' ./*

./include/logging/log_core.h:295:#define Z_LOG2(_level, _source, _dsource, ...) do { \
./include/logging/log_core.h:329:#define Z_LOG(_level, ...) \

$ grep -nr 'Z_LOG[^_]' ./*

$ vi ./include/logging/log_core.h

329 #define Z_LOG(_level, ...) \
330         Z_LOG2(_level, __log_current_const_data, __log_current_dynamic_data, __VA_ARGS__)

A Zephyr RTOS sample to check out:

`ted@localhost:~/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/samples/subsys/logging/logger$`

- 2022-10-05 -

Zephyr v2.6.0 source file `log_core.h` may also define `log_strdup()`:

./subsys/logging/log_core.c:1017:char *z_log_strdup(const char *str)

But it looks like the routine is statically in-lined in Zephyr header file `log.h`:

./include/logging/log.h:290:static inline char *log_strdup(const char *str)

^ Zephyr thread_analyzer_cb And Related

Zephyr 2.6.0's thread_analyzer_cb() routine gathers and populates a structure with all pertinent, reported run-time thread statistics. This is however a static routine so we cannot call it directly. Nor does it return the summary thread resource use data to its direct calling routine. There is yet hope, and to understand a path forward here excerpted is the definition of this important thread reporting routine from file `./zephyr/subsys/debug/thread_analyzer.c`:

 59 static void thread_analyze_cb(const struct k_thread *cthread, void *user_data)
 60 {
 61         struct k_thread *thread = (struct k_thread *)cthread;
 62 #ifdef CONFIG_THREAD_RUNTIME_STATS
 63         k_thread_runtime_stats_t rt_stats_all;
 64         k_thread_runtime_stats_t rt_stats_thread;
 65         int ret;
 66 #endif
 67         size_t size = thread->stack_info.size;
 68         thread_analyzer_cb cb = user_data;
 69         struct thread_analyzer_info info;
 70         char hexname[PTR_STR_MAXLEN + 1];
 71         const char *name;
 72         size_t unused;
 73         int err;
 74 
 75 
 76 
 77         name = k_thread_name_get((k_tid_t)thread);
 78         if (!name || name[0] == '\0') {
 79                 name = hexname;
 80                 snprintk(hexname, sizeof(hexname), "%p", (void *)thread);
 81         }
 82 
 83         err = k_thread_stack_space_get(thread, &unused);
 84         if (err) {
 85                 THREAD_ANALYZER_PRINT(
 86                         THREAD_ANALYZER_FMT(
 87                                 " %-20s: unable to get stack space (%d)"),
 88                         name, err);

 88                         name, err);
 89 
 90                 unused = 0;
 91         }
 92 
 93         info.name = name;
 94         info.stack_size = size;
 95         info.stack_used = size - unused;
 96 
 97 #ifdef CONFIG_THREAD_RUNTIME_STATS
 98         ret = 0;
 99 
100         if (k_thread_runtime_stats_get(thread, &rt_stats_thread) != 0) {
101                 ret++;
102         }
103 
104         if (k_thread_runtime_stats_all_get(&rt_stats_all) != 0) {
105                 ret++;
106         }
107         if (ret == 0) {
108                 info.utilization = (rt_stats_thread.execution_cycles * 100U) /
109                         rt_stats_all.execution_cycles;
110         }
111 #endif
112         cb(&info);
113 }

The routine which calls this is:

115 void thread_analyzer_run(thread_analyzer_cb cb)
116 {
117         if (IS_ENABLED(CONFIG_THREAD_ANALYZER_RUN_UNLOCKED)) {
118                 k_thread_foreach_unlocked(thread_analyze_cb, cb);
119         } else {
120                 k_thread_foreach(thread_analyze_cb, cb);
121         }
122 }

We should be able to directly call thread_analyzer_run(thread_analyzer_cb cb). If yes, and if we can learn how &info is defined, we should be able to redirect thread_analyzer reports to an arbitrary UART . . .

^ struct thread_analyzer_info

ted@localhost:~/projects/zephyr-based/z4-sandbox-kionix-work/zephyr$ grep -nr 'struct thread_analyzer_info' ./*
./include/debug/thre[[#top|^]] ad_analyzer.h:23:struct thread_analyzer_info {
./include/debug/thread_analyzer.h:44:typedef void (*thread_analyzer_cb)(struct thread_analyzer_info *info);

Structure definition for &info passed to thread_analyzer_cb() function above:

/** @defgroup thread_analyzer Thread analyzer
 *  @brief Module for analyzing threads
 *
 *  This module implements functions and the configuration that simplifies
 *  thread analysis.
 *  @{
 */

struct thread_analyzer_info {
        /** The name of the thread or stringified address of the thread handle
         * if name is not set.
         */
        const char *name;
        /** The total size of the stack*/
        size_t stack_size;
        /** Stack size in used */
        size_t stack_used;

#ifdef CONFIG_THREAD_RUNTIME_STATS
        unsigned int utilization;
#endif
};

^ Zephyr Shell

This section started 2023-06-12. Growth goal at this time is to learn how Zephyr shell supports multiple shell sessions, across one or many interfaces.

First reference noting here relates to develop needing to separate shell communications from Zephyr logging. Not quite multi-session / multi-context shell support but somewhere in the ballpark:

• https://github.com/zephyrproject-rtos/zephyr/issues/36057

This link asks salient questions to topic of multiple shell session support in Zephyr shell facility:

• https://devzone.nordicsemi.com/f/nordic-q-a/92193/multiple-zephyr-shell-instances-over-uart
• https://devzone.nordicsemi.com/f/nordic-q-a/92325/use-shell-over-uart-and-uart-async-api-on-nrf52840

2025-09-24

Goliath article on Zephyr shell, by Mike Szczys . . .

• https://blog.golioth.io/how-to-add-custom-shell-commands-in-zephyr/

Ctags gives following build artifact as one of the definitions of `struct shell`:

"build/zephyr/misc/generated/syscalls_links/include/zephyr/shell/shell.h" 1314L, 42481B

^ Ztest

Zephyr has extensive documentation on its Ztest framework. As an aside however, to understand a pattern "Arrange, Act, Assert" test organization see the Zephyr 3.7.0 source file ``zephyrtests/net/lib/lwm2m/block_transfer/src/main.c``.

^ Kernel Services

Zephyr stack sentinel

• https://docs.zephyrproject.org/3.6.0/kconfig.html#CONFIG_STACK_SENTINEL

^ Zephyr Memory Management

• https://link.springer.com/chapter/10.1007/978-3-030-25543-5_29

^ Zephyr Kernel Timing

System timing, timing of hardware and firmware running together is an important non-trivial feature of nearly all embedded systems. In RTOS situations the operating system must expend some resources to keep track of a system timing mechanism with a time granularity of n microseconds. The given system may use another unit of time but the concept remains the same. Local article contributor Ted believes this applies for operating systems (and bare metal projects employing a timing mechanism) where there's a "system tick" or "systick" implemented.

Zephyr provides an API to permit firmware at runtime to obtain systick time granularity:

// A Zephyr API to obtain MCU clock cycles per second: // sys_clock_hw_cycles_per_sec()

Program uptime or "running hours" may also be of import to a given project. Following link at Zephyr Project documentation pages has valuable info on various Zephyr timing and work queueing facilities:

• https://docs.zephyrproject.org/2.6.0/reference/kernel/timing/clocks.html?highlight=k_uptime
Similar documentation but describes sources of timing inaccuracies in running Zephyr RTOS relative to civil, real world time:
• https://docs.zephyrproject.org/2.6.0/reference/misc/timeutil.html?highlight=k_uptime_get
Must #include <kernel.h> . . .
• https://docs.zephyrproject.org/apidoc/latest/group__clock__apis.html#ga208687de625e0036558343b4e66143d3

Related:

• https://docs.zephyrproject.org/2.6.0/reference/kernel/timing/clocks.html?highlight=k_uptime#uptime

Important to follow up on this bug report relating to above mentioned Zephyr timing features:

• https://github.com/zephyrproject-rtos/zephyr/issues/16238

2023-12-06

In Zephyr a k_timeout_t is a structure.

^ Zephyr Application Code Relocation

• https://docs.zephyrproject.org/3.1.0/kernel/code-relocation.html

^ Data Structures

Multiple Producer Single Consumer circular buffer

• https://docs.zephyrproject.org/latest/kernel/data_structures/mpsc_pbuf.html