Energy-constrained real-time systems are subject to multiple constraints during their execution: On the one side, applications come with tasks that require real-time guarantees. On the other hand, the available energy is constrained through a limited power supply. These constraints require a careful handling of resources and resource savings are especially beneficial. The key components for energy savings, for example, are the clock subsystems on modern embedded platforms. These subsystems are intertwined with all components on Systemon-Chip devices and regulate both energy consumption and temporal behavior. As Zephyr is already aware of the clock components via its device tree, we want to bring attention to the availability and usability of a clock-subsystem abstraction and discuss possible goals in the near future.
The rise of IoT and intermittent systems has led to a significant increase in the use of embedded devices. Their applications, ranging from automotive systems to medical devices, often have specific timing and energy constraints, which are fundamental to many safety-critical domains. Therefore, it is crucial that the developers of these systems take care to comply with those constraints:
Timing Constraints To ensure guarantees regarding their timely execution, real-time tasks must
be finished within predefined deadlines. Therefore, it is necessary to know an upper bound for the
worst-case execution time (WCET) of each task, which denotes the most extended timespan a task needs
for its execution on a given hardware platform for any given input and adverse hardware states (e.g.,
cache misses). Determining accurate WCET bounds is a problem that has been the focus of extensive
research [
Phase-Locked Loop (PLL) 9 Low-Speed Osc. (RC)
8 Mid-Speed Oscillator /N Divider r e x e l p i t l u M 1 : 2 /N Divider Power Gate End-Device Requirement CPU Ô
Energy Constraints Another consideration is energy, as the embedded nature of IoT devices often
imposes dificulties concerning their energy storage and, therefore, energy consumption. Many of these
systems are either battery-operated or harvest energy from their surroundings [
One of the critical challenges in embedded real-time systems is managing the tradeof between energy
consumption and computing time. This balance is primarily controlled through complex clock
subsystems known as clock distribution networks or clock trees, which serve the essential function of delivering
clock signals to all components within the system. An example clock distribution network is shown
in Fig. 1. It is composed of several types of nodes, each serving a distinct role:
• Input nodes: The inputs provide the network with various clock sources, each ofering a diferent
set of properties. For real-time systems, the frequency of the clock source is a crucial factor as it
impacts the device’s timing behavior and power consumption. Additionally, the precision and
stability of the clock source may play a significant role for some output devices.
• Output nodes: These nodes typically correspond to processing units, sensors, or actuators.
Examples are the central processing unit, speed or temperature sensors, and motors or LEDs. Each of
these devices may have diferent requirements regarding its input clock signal. These include the
frequency, as well as the accuracy and stability of the input clock signal. For instance, the radio
on an ESP32-C3 only works with the phase-locked loop (PLL) clock source [
With these components, the clock distribution network can be configured not only to meet timing objectives but also to improve the system’s energy eficiency simultaneously. However, a key factor when interacting with the clock distribution network is the overhead associated with clock-configuration changes. These reconfiguration penalties influence both the timing and energy behavior and include both software- and hardware-related costs, e.g., for initializing or reconfiguring hardware. The significance of the reconfiguration costs becomes evident when the transition costs outweigh the potential energy savings. For instance, although using a low-power sleep mode is generally the most energy-eficient option during idle periods, the transition overhead associated with entering and exiting the sleep mode can result in a higher overall energy consumption.
When reconfiguring the system, additional reconfiguration penalties may arise. These penalties can be hardware-related or result from necessary software initialization or device configurations. In both cases, the time and energy needed for these reconfigurations is non-negotiable and may render an otherwise optimal configuration unprofitable in terms of overall energy savings. Therefore, although dynamically adjusting the clock subsystem between tasks can ofer significant benefits, the impact of reconfiguration overheads should be considered to ensure that such adjustments truly improve the overall eficiency.
As discussed in Section 1.1, the primary component controlling the energy consumption and timing behavior of modern embedded devices is the clock distribution network. There exist multiple approaches to improve diferent aspects of operation for this topic, which we will discuss in this chapter.
Before the clock distribution network can be utilized, the possible configuration space must be explored
and evaluated. This process involves identifying all possible configuration parameters within the
system, which requires studying the hardware along with its available clock sources. In practice,
implementing clock reconfigurations in software typically requires modifying specific system registers
or memory-mapped bit fields. Once the configuration parameters are understood, the next step is to
establish which settings within the clock distribution network are both possible and valid. To utilize
the potential energy savings, the energy consumption behavior of each clock configuration as well
as its reconfiguration penalties must be known. These parameters can be determined either through
manual measurements or by exploration during an initial setup phase. One example of such an online
setup phase is ScaleClock [
To implement optimal configurations, the operating system must not only be aware of all available
configurations but also actively apply them. In the case of ScaleClock, the insights gained during the
initialization phase are employed at runtime within the RIOT operating system: For each task, the
system determines its most eficient clock configuration in terms of energy consumption based on the
derived performance metrics. The operating system then applies this configuration before the task is
dispatched. A diferent approach called Power Clocks [
A key challenge in real-time systems is ensuring that real-time guarantees are met. Although strategies
exist for scheduling task execution, integrating these strategies with dynamic clock reconfiguration to
lower energy consumption is a relatively recent development. Our group has introduced two approaches
– FusionClock [
As an operating system supporting IoT devices, Zephyr should aim to cater to IoT-specific system characteristics of the target domain. The operation of IoT systems is often subject to resource constraints: Timing constraints require real-time–aware operation, energy constraints necessitate eficient and energy-aware operations. To make the operating system ready to support the management of such constrained applications, the modeling of power domains and sleep states should be considered together with the clock tree configuration. Clocks play a central role as specialized devices that power the processor and peripheral devices. The following sections provide a detailed examination of the current state of clock modeling in Zephyr (Section 3.1) and propose three goals (Sections 3.2, 3.3, 3.4).
As of now, Zephyr enables the expression of a myriad of features, relations, and requirements regarding
clock configurations through device-tree specifications. Zephyr allows specifying available power states
for the platform and groups them into predefined categories covering diferent sleep states [
Listing 2: Excerpt of the device tree for the ESP32-C3 showing the processor clock description [18]. cpus { }; } }; }; cpu-power-states = <&light_sleep &deep_sleep>; clock-source = <ESP32_CPU_CLK_SRC_PLL>; clock-frequency = <DT_FREQ_M(160)>; xtal-freq = <DT_FREQ_M(40)>;
Listing 3: Excerpt of the device tree for the ESP32-C3 showing the clock specification [18]. clock: clock { compatible = "espressif,esp32-clock"; fast-clk-src = <ESP32_RTC_FAST_CLK_SRC_RC_FAST>; slow-clk-src = <ESP32_RTC_SLOW_CLK_SRC_RC_SLOW>; #clock-cells = <1>; device-specific device-tree schemes provide further custom clock information. A schema for Espressif RISC-V CPUs [16], for example, requires specifying available processor clock sources and frequencies. Platforms compatible with the ESP32 family must further provide the properties fast-clk-src and slow-clk-src as specific clock sources [17].
We illustrate the current state with the example of the device tree for the ESP32-C3 [18]. Listing 1 shows the definition of power states, including their reconfiguration penalties. Listing 2 shows the part of the CPU description that features information about the processor clocks while Listing 3 shows an excerpt of additional clock configuration. A header file ultimately provides macro definitions for the clock sources and supported frequencies [19].
In summary, Zephyr’s support for device trees already provides access to much of the information about the clock subsystem required for optimizations, as depicted in Fig. 2. The status quo provides a foundation for a fine-granular modeling of clock trees and the resulting optimization potential to achieve minimal resource consumption.
An existing RFC proposes an architecture for a precision clock subsystem in Zephyr, catering to the diverse clocks found in embedded platforms [20]. Among other points, the RFC emphasizes the need for a modular system that supports multiple clock domains and highlights the importance of low-power optimizations in the target domain. The RFC correctly states that optimizations for resource usage in constrained devices require operating-system support for switching between clock sources and clock domains to utilize the configurability of the clock tree fully. We further believe that minimizing resource usage is only possible with a fine-granular modeling of the resource demands of possible clock-tree configurations and transitions between configurations.
While the status quo of clock-tree modeling provides a solid and valuable foundation, we argue that a greater level of detail regarding clock-subsystem information is beneficial. That begins with enriching the clock model with explicit information about the efects on power consumption both when the clock configuration is active and for transitions between clock configurations.
Approaches like FusionClock [
Ultimately, fine-granular clock-tree specifications in the device trees are not an end in themselves but enable the reconstruction of the clock tree into a resource-consumption–aware model. Such a powerful model paves the way towards resource monitoring and optimizing the system’s resource demand.
The resource-constrained characteristics of IoT devices necessiate a deliberate approach to resource management and strict monitoring of resource budgets. Fine-grained clock-tree models enriched with resource-consumption data enable Zephyr to be an operating system that helps applications manage their resource demand and operate eficiently in resource-constrained environments. Knowledge about the efects of clock reconfigurations and the associated overheads positions Zephyr to ensure minimal invasive interventions by the operating system, thereby preserving resources for the applications.
With the help of existing static analysis approaches that provide bounds on resource consumption, the operating system can minimize the resource consumption of applications. Clock-configuration–aware resource bounds allow the determination of alternative clock configurations that still adhere to application constraints but minimize the resource demand. Fine-granular clock models provide the necessary knowledge about reconfiguration overheads to ensure that switching clock configurations between application phases does not nullify the obtained resource savings. The ability to find the optimal clock configuration that leads to the minimal resource demand for diferent application phases, considering operating-system overheads, would enable Zephyr to provide an eficient execution environment suitable for low-power operation to applications.
Advances in battery-free operation and the growing Internet of Things require operating systems like Zephyr to provide environments for execution under resource constraints. Zephyr’s existing device-tree support already provides the ability to express comprehensive information about the clock subsystem and power domains. In this positional paper, we argue for advancing the clock-subsystem abstraction to enable Zephyr to cater to the needs of resource-constrained systems. A more finegranular understanding of the heterogeneous clock subsystems provided by embedded platforms including information about the resource consumption of clock configurations would benefit Zephyr’s role as an embedded, real-time–ready operating system.
Fine-grained, resource-aware clock-tree models and clock-tree–aware resource-consumption models are powerful tools for finding application-specific clock configurations that minimize overall resource demand. Integrating such a clock-system abstraction would enable Zephyr to configure systems optimally for the respective applications and further enhance the usability of Zephyr.
The authors have not employed any Generative AI tools. [16] The Zephyr Project, Source code, 2025. URL: https://github.com/zephyrproject-rtos/zephyr/blob/ main/dts/bindings/cpu/espressif%2Criscv.yaml. [17] The Zephyr Project, Source code, 2025. URL: https://github.com/zephyrproject-rtos/zephyr/blob/ main/dts/bindings/clock/espressif%2Cesp32-clock.yaml. [18] The Zephyr Project, Source code, 2025. URL: https://github.com/zephyrproject-rtos/zephyr/blob/ main/dts/riscv/espressif/esp32c3/esp32c3_common.dtsi. [19] The Zephyr Project, Source code, 2025. URL: https://github.com/zephyrproject-rtos/zephyr/blob/ main/include/zephyr/dt-bindings/clock/esp32c3_clock.h. [20] Proposal for a precision clock subsystem architecture, 2024. URL: https://github.com/ zephyrproject-rtos/zephyr/issues/76335.