Storage I/O Characterization for an Embedded Multi-Sensor Platform: Performance Bottlenecks and Design Guidelines

Abstract

Microcontroller-based embedded systems integrating multiple sensors are increasingly required to support continuous data acquisition, on-board processing, and long-term storage within tightly coupled hardware–software architectures. In such platforms, overall performance is often constrained not by computational capability but by storage I/O behavior, particularly under real-time constraints and concurrent workloads. This study presents a comprehensive empirical evaluation of eMMC storage performance on an STM32U5 microcontroller running the ThreadX RTOS. The proposed methodology combines multi-dimensional stress testing, controlled task concurrency (0–4 tasks), and long-duration aging analysis (90 h), together with timing variability assessment under electrical stress and interrupt-driven preemption. Both synthetic workloads and realistic sensor-node scenarios with heterogeneous and asynchronous access patterns are considered. The results highlight significant performance limitations, including up to 98% throughput degradation under four concurrent tasks and a nonlinear increase in metadata latency as free space decreases below 40% (from 10 ms to over 200 ms for file creation). Additionally, timing jitter increases by 2–5× under voltage variation and interrupt load. Based on these findings, practical firmware-level design guidelines are derived, including sector-aligned buffering, dedicated I/O task architectures, and proactive capacity management, enabling substantial improvements in throughput and latency. This study provides quantitative insights and reproducible methodologies for optimizing storage subsystems in multi-sensor embedded applications.

1. Introduction

Multi-sensor embedded platforms must carefully balance their limited resources across sensing, computation, and data storage, while still meeting strict real-time deadlines and operating under tight energy constraints. On these systems, memory input/output (on-chip flash, external flash modules, SD cards, and other forms of non-volatile storage) frequently emerges as the primary performance bottleneck that constrains overall system throughput. This constraint is especially acute when high-rate data logging must be maintained in parallel with application-level computation and real-time task scheduling by an RTOS (e.g., Azure RTOS ThreadX), since these activities together create stringent and often competing timing demands.

The proliferation of advanced multi-sensor platforms for biomedical, environmental, and industrial monitoring has driven increasing integration of diverse sensing modalities—chemical, optical, electrical, and mechanical—within compact, energy-efficient form factors [1]. Recent advances in flexible electronics and functional materials have enabled wearable and implantable sensor systems that continuously monitor physiological signals, environmental conditions, or structural health with unprecedented spatial and temporal resolution [2]. Multi-modal wearable platforms combining inertial measurement units (IMUs), photoplethysmography (PPG), electrocardiography (ECG), and environmental sensors produce aggregate data rates exceeding several megabytes per second [1]. As these platforms evolve from single-sensor prototypes to system-level integrated solutions, the storage subsystem—responsible for buffering, organizing, and persisting sensor data—emerges as a critical performance bottleneck that can limit achievable sampling rates, introduce data loss, or constrain deployment duration [3]. While substantial research addresses sensor design, signal processing algorithms, and wireless communication protocols, the characterization of storage I/O behavior under realistic multi-sensor workloads remains underexplored, particularly for resource-constrained embedded platforms where memory hierarchy, filesystem semantics, and RTOS scheduling interact in complex ways. This work addresses this gap by systematically evaluating storage subsystem performance on a representative microcontroller-based multi-sensor platform; quantifying the impact of access patterns, concurrency, and long-term operation on throughput, latency, and timing determinism; and deriving firmware-level design guidelines to optimize storage performance for continuous multi-sensor data logging applications.

Against this backdrop, the present work targets two main goals. First, we seek to perform a systematic and exhaustive characterization of storage I/O access patterns, latency, and throughput under concurrent workloads that closely mirror real deployment conditions, explicitly including the interaction between logging activities and RTOS scheduling behavior. Second, using the empirical insights from this characterization, we aim to formulate a set of firmware-level design recommendations to guide the construction of embedded systems that achieve higher data throughput, lower storage access latency, and more predictable timing behavior. Fulfilling these objectives is intended to improve temporal determinism, increase the effective utilization of scarce hardware resources, and ultimately enhance both the efficiency and robustness of embedded platforms in realistic, multi-sensor operating scenarios.

This work offers the following primary contributions:

• It presents a rigorous benchmarking framework for analyzing storage read/write behavior on an eMMC-based embedded platform. The framework incorporates both intensive stress-test workloads and synthetic sensor-driven access patterns that approximate real-world data logging use cases.
• It delivers an in-depth, quantitative evaluation of system performance, including sustained throughput, I/O latency, and timing jitter, measured under carefully controlled degrees of concurrency and resource contention.
• It extracts a detailed set of firmware engineering guidelines such as buffering policies, transfer size configuration, task decomposition and scheduling, and filesystem handling derived from an empirical study of how storage subsystem dynamics impact end-to-end system performance.

The novelty of this work lies in the integrated experimental characterization of storage I/O behavior under controlled concurrency and long-duration operation scenarios. Unlike prior works, our study combines synthetic stress tests, filesystem metadata analysis, and long-term storage aging experiments to derive practical firmware design guidelines for embedded developers.

The remainder of this paper is organized as follows. Section 2 reviews related work on embedded storage systems, RTOS scheduling, and memory optimization techniques. Section 3 describes the hardware platform and software architecture used in our experiments. Section 4 presents the experimental methodology and benchmark design. Section 5 reports the experimental results and analyzes key performance trends. Section 6 discusses the implications of these results, summarizes firmware design recommendations, and highlights the limitations of the study. Finally, Section 7 concludes the paper and outlines directions for future work.

2. Related Work

In microcontroller units (MCUs) that operate under strict resource constraints, achieving high-rate data acquisition while preserving strong temporal determinism requires a carefully organized partitioning of system responsibilities. A commonly employed architectural pattern separates signal sampling, data movement, and persistent storage into distinct processing stages, typically implemented via direct memory access (DMA) controllers, double-buffering schemes, and dedicated tasks or threads for handling these functions [3,4]. By moving bulk data transfers out of interrupt service routines (ISRs), such designs measurably reduce interrupt-handling overhead and improve the predictability of execution timing—properties that are especially important in heterogeneous, multi-sensor systems that must satisfy demanding real-time constraints and tight latency guarantees.

Nonetheless, even carefully crafted firmware remains susceptible to disturbances rooted in the characteristics of the underlying hardware–software platform. Factors including task scheduling algorithms, synchronization primitives, and contention on shared interconnects or communication fabrics contribute additional latency and amplify timing jitter. Recent benchmarking and performance analysis efforts for real-time operating systems, such as studies of ThreadX-based platforms, have introduced systematic experimental methodologies to quantify the overhead contributed by the operating system in scenarios with concurrently running tasks [5]. Drawing on this interference-injection perspective, our work concentrates specifically on storage input/output subsystems, enabling a detailed assessment of how storage access patterns, traffic load, and filesystem semantics jointly shape end-to-end timing characteristics in complex, representative multi-sensor application scenarios.

A primary issue in such platforms is the behavior of the non-volatile memory subsystem while the application is executing. Many members of the STM32 microcontroller family adopt a dual-bank flash layout that supports read-while-write (RWW) operation, which can significantly mitigate execution stalls that would otherwise arise during in-place flash programming [6,7]. Yet, the precise timing behavior is highly dependent on the concrete flash design (including bank organization, word-line structure, and erase-block size) and on device- and workload-specific configuration parameters (such as the number of wait states, prefetch configuration, and voltage scaling). Accordingly, empirical, platform-specific timing measurements become indispensable for any workload that must both execute from on-chip flash and sustain near-continuous logging because even short or sporadic pauses may break real-time guarantees.

The substantial performance and energy penalties of flash erase and program operations have spurred hardware–firmware co-design approaches that directly address non-volatile memory as a primary bottleneck. As one example, Chien et al. embed a ReRAM-based buffer into a sensor-hub microcontroller, using the ReRAM as a high-speed staging area to mask the millisecond-scale latency of flash erase and program operations [8]. Sensor samples are first written into this buffer and later committed to flash under explicit firmware control, yielding a buffer-first pipeline with programmable commit policies; their results demonstrate that judicious buffering and deferred persistence can substantially reduce both execution latency and total energy consumption relative to naïve, immediate flash logging. Collectively, these findings suggest two general firmware design principles for embedded non-volatile memory management: (i) minimize write amplification by coalescing updates into larger, alignment-aware transactions that better conform to the native flash erase/program geometry, and (ii) explicitly orchestrate flush and commit activities so that persistence is deferred and batched, thereby trading higher individual write latency for greater effective throughput and improved energy efficiency whenever the application’s timing requirements permit such flexibility.

Energy aspects are fundamentally coupled to these performance trade-offs. Borgeson et al. contend that meaningful power comparisons for ultra-low-power MCUs demand a decomposition of energy use by operating mode—standby, peripheral activity, storage operations, and active computation—and a subsequent weighting according to the application’s duty cycle [9]. This framing has direct consequences for firmware design: frequent or poorly aggregated logging can dominate both the energy and timing budget, while aggressive low-power configuration is the main determinant of system longevity in deployments characterized by long idle intervals. At a more radical architectural level, Hayashikoshi et al. introduce normally-off MCU architectures, in which the processor remains powered down by default and is only activated when computation is required [10]. In such settings, firmware must aim to minimize the number of wake-ups, tightly bound the duration of each active interval, and curtail state-management overhead (e.g., checkpointing and metadata operations), since interference among concurrent tasks and memory I/O can extend active times and erode the anticipated energy gains. The present work centers on performance-oriented metrics; a systematic characterization of energy behavior is left as an important avenue for future research.

Beyond techniques that refine how data is captured, an expanding literature investigates what information should be acquired in the first place. Bellarmino et al. leverage compressed sensing together with regularized linear models to integrate prediction and feature selection, enabling substantial dimensionality reduction at the moment of logging; they report compression ratios up to 32:1 with only minimal degradation in predictive accuracy [11]. For multi-sensor firmware operating under concurrent workloads, such on-device dimensionality reduction—executed directly at the point of data generation—can match, and in some configurations even exceed, the gains achievable via advanced buffering and scheduling mechanisms, particularly when storage bandwidth, write latency, or energy usage represents the dominant system constraint.

A persistent, foundational challenge in this area stems from the pronounced heterogeneity of MCU architectures. Across vendors and product families, one encounters wide variation in memory hierarchies, interconnect and bus organizations, DMA subsystems, and power-management mechanisms, to the extent that I/O and logging optimizations cannot be presumed to transfer across platforms without meticulous, platform-specific performance analysis and benchmarking [12]. This architectural diversity also surfaces in the intricate couplings among data-acquisition chains, networking components, and non-volatile storage systems—a tightly interdependent behavior previously documented in earlier generations of embedded control hardware [13] and, in contemporary contexts, further extended to RTOS-based deployments with multiple sensors. In such modern platforms, contention may arise not only on shared physical buses, but likewise within multi-layered driver stacks and kernel-managed services, thereby exacerbating the challenge of accurately forecasting end-to-end timing. The comparative evaluation by Sakr et al., which examines several algorithms across a range of STM32 microcontroller series, serves as a concrete illustration of how to plan and carry out systematic experimental studies, perform in-depth temporal profiling, and document results comprehensively. Their approach successfully operationalizes high-level guidelines for reproducible and transparent experimentation into a concrete protocol for timing analysis and reporting tailored to this line of research [14].

Our experimental testbed is an ST multi-sensor board from the SensorTile product line [15,16]; Section 3 details the microcontroller, associated memory devices, and the full firmware software stack. Across the examined literature, a recurrent insight is that impactful firmware-level optimization demands a holistic co-design of power-state management, buffering and commit strategies, and task scheduling so as to reduce both average and tail latencies of memory I/O under realistic concurrency. Nevertheless, there remains a significant scarcity of empirical work that systematically explores storage I/O behavior under controlled yet adversarial circumstances—namely, settings in which concurrent computation and file-access patterns simultaneously contend for shared storage and bus resources. This gap motivates our own comprehensive experimental study, which precisely quantifies throughput, latency, and temporal variability of core storage I/O operations under both quiescent (idle) and highly loaded (stressed) operating conditions, and extracts concrete design recommendations from these empirical observations.

3. Platform and Experimental Setup

3.1. Hardware

The experimental configuration is built around a custom embedded platform specifically designed to meet the performance and power requirements of high-performance, ultra-low-power biomedical workloads. The principal hardware characteristics of this platform are summarized in

Table 1. Hardware summary.

Component	Specification
MCU	STM32U5A5QJI6Q Arm® Cortex®-M33 32-bit core @ 160 MHz (240 DMIPS)
Internal Memory	4 MB Flash (Dual-bank architecture), 2.5 MB SRAM
External NVM	4 GB eMMC 5.1 (Kingston EMMC04G-M657-K03u)
Sensors	IMU: LSM6DSRX, PPG: ADPD4100/ADPD4101 (platform-supported)
Power	3.7 V, 500 mAh Li-Po Battery

. At its core, the system employs an STM32U5A5QJI6Q microcontroller (MCU) from STMicroelectronics, which is implemented on a 32-bit Arm® Cortex®-M33 CPU architecture. This MCU integrates a hardware Floating Point Unit (FPU) to accelerate numerical computations and supports Arm TrustZone® technology, enabling secure partitioning and isolation of sensitive code and data at the hardware level. In terms of computational throughput, the device is capable of achieving up to 240 DMIPS, providing sufficient processing capacity for real-time biomedical signal processing and control tasks. The MCU is equipped with 4 MB of on-chip Flash memory for program and non-volatile data storage, along with 2.5 MB of embedded SRAM to support data buffering and runtime memory needs. Furthermore, it incorporates a MIPI DSI host interface together with an LCD-TFT Display Controller (LTDC), which collectively facilitate efficient driving of high-resolution graphical displays and support advanced visualization functions for user interfaces and real-time data monitoring.

The platform is designed to interface with external sensors for multi-modal data acquisition. The target application profile includes motion tracking via a six-degree-of-freedom Inertial Measurement Unit (IMU) and physiological signal acquisition through optical sensing. While the current experimental campaign focuses on storage subsystem characterization rather than sensor-driven data acquisition, the platform architecture and software stack are designed to support these sensor modalities in production deployments.

Non-volatile memory functionality is implemented using a Kingston EMMC04G-M657-K03u device (4 GB, eMMC 5.1 standard). This component is connected to the MCU through a high-speed, 8-bit-wide parallel interface, a configuration selected to maximize sustained data bandwidth for intensive logging operations and to support robust firmware management, including redundancy and reliable over-the-air update mechanisms.

The energy supply for the system is provided by a 3.7 V, 500 mAh Lithium-Polymer (Li-Po) rechargeable cell, whose output is conditioned and supervised by integrated on-board power management and regulation circuitry. Figure 1 shows a high-level block diagram of the system component integration. During the development phase—including firmware programming, iterative re-flashing, and continuous, real-time debugging—the system interfaces with a Segger J-Link Plus debug probe, which establishes a connection to the microcontroller through the Serial Wire Debug (SWD) interface to enable low-level access and control.

3.2. Software Stack

The firmware stack, whose overall structure is schematically depicted in Figure 2, was implemented within the STM32CubeIDE integrated development environment and built using the GNU Arm Embedded Toolchain to generate target-specific binaries. At the hardware interface level, abstraction is provided by the STM32Cube MCU Package, which adopts a mixed driver paradigm: HAL (Hardware Abstraction Layer) components are employed for high-level configuration and initialization of peripherals, while LL (Low-Layer) drivers are reserved for latency-sensitive and time-critical routines. This combined approach is intended to preserve code portability and maintainability, while simultaneously achieving high execution efficiency in performance-critical sections. The runtime behavior of the system is governed by Azure RTOS ThreadX, a deterministic Real-Time Operating System that implements a priority-based, preemptive scheduling policy. ThreadX is responsible for orchestrating concurrent tasks, performing context switching, and managing system resources such as memory, synchronization objects, and inter-thread communication mechanisms. For persistent data management, the architecture incorporates Azure RTOS FileX as the file system layer. FileX provides a robust, high-throughput interface for non-volatile storage and is configured to operate on the Kingston eMMC device via the SDMMC peripheral, thereby enabling reliable data logging, configuration storage, and retrieval under real-time operating constraints.

The application layer adopts a multi-threaded design that enables systematic validation of the system under conditions closely approximating those encountered in real deployments. Within this framework, a dedicated storage-management thread is responsible for all file system interactions. This thread generates synthetic data patterns and commits them to the eMMC storage device to assess both the robustness of the storage subsystem (e.g., data integrity over time) and the effective write throughput achievable on the target hardware. In parallel, and to emulate the computational workload of a fully featured production unit, four additional worker threads execute concurrently. These auxiliary computation tasks impose a deterministic CPU load on the microcontroller by repeatedly performing vector-based arithmetic over pre-allocated memory regions. Each thread operates on its own data arrays and, in each iteration, first performs an element-wise scalar increment—adding a constant value of one to every entry in the vector—followed immediately by a vector reduction step, in which the sum of all updated elements is computed. By continuously cycling through this combination of per-element updates and global summation, the threads maintain a stable, realistic processing demand on the Cortex-M33 processor core, thereby enabling comprehensive evaluation of the system’s performance under conditions of sustained compute and I/O activity.

4. Experimental Methodology

To characterize the I/O performance of the embedded storage subsystem, we designed a benchmark suite targeting sequential throughput, metadata overhead, concurrent access, and long-duration behavior. All experiments were conducted on the target platform under controlled conditions, with the system in a quiescent state to minimize interference from background processes. Each test configuration was repeated multiple times to ensure statistical reliability, and results are reported as mean values unless otherwise noted.

To evaluate the performance of the storage subsystem, we report the following metrics:

• Throughput: Measured as the amount of data transferred per unit of time ($\mathrm{kB}{\mathrm{s}}^{-1}$ or $\mathrm{MB}{\mathrm{s}}^{-1}$), computed as the ratio of total data size to transfer time.
• Latency ($\mathit{L}$): The duration of a single I/O operation, from initiation to completion. We report mean latency values, particularly for random access and metadata operations.

All measurements were performed on an STM32U5A5QJI6Q microcontroller. Timestamps were captured using high-resolution hardware timers at the immediate start and end of each execution block. The elapsed time $\Delta t=t_{\mathrm{end}}-t_{\mathrm{start}}$ was used to calculate throughput and latency metrics, ensuring minimal measurement overhead and microsecond-level precision.

The benchmark suite is organized into three workload categories designed to stress different aspects of the storage subsystem:

(i)

Baseline single-thread I/O: Sequential read and write transfers on files of 1 MiB and 4 MiB with variable chunk sizes ranging from 1 byte to 2 MiB. An additional benchmark using a fixed workload of 500 iterations per chunk size enables precise characterization of throughput stability and isolation of anomalous behaviors.

(ii)

Stress workload: Evaluation of system throughput under multi-tasking conditions, with concurrent task counts varying from 0 to 4, to measure contention effects and quantify performance degradation under load. Additionally, metadata-intensive bursts involving rapid creation, opening, closing, and deletion of file sets (200–1000 files) stress the filesystem’s metadata management subsystem.

(iii)

Mock sensor nodes: Simulation of embedded sensing scenarios, including random access patterns representative of indexed data retrieval, and long-term periodic sampling (every 30 min) until storage saturation. This category focuses on the complete file lifecycle (create, open, write, flush, close) and reveals aging effects as the filesystem approaches capacity limits.

A comprehensive overview of the experimental configurations is provided in

Table 2. Benchmark Scenarios and Experimental Configurations.

ID	I/O Pattern	Concurrent Load	Configuration/Objective
B0	Seq. Read/Write	None	1 MiB file, chunks 1–1024 B. Analyzes 512 B sector alignment.
B1	Seq. Read/Write	None	4 MiB file, chunks up to 2 MiB. Investigates large-scale behavior.
B2	Fixed Iterations	None	500 iterations per chunk size. Targets B1 anomalies.
S1	Concurrent I/O	0 to 4 Tasks	Throughput scaling for chunks up to 8192 B.
S2	Metadata Burst	None	200–1000 files. Measures Create/Open/Close/Delete latency.
M1	Random Access	None	1000 random reads on 1 MiB file. Evaluates seek overhead.
M2	Sensor Stream	3 File Streams	File lifecycle every 30 min. Analyzes aging until saturation.

.

Test B0 measures read and write throughput on a 1 MiB file while varying the chunk size from 1 to 1024 bytes in powers of two. For each chunk size configuration, 10 independent measurements were collected for both read and write operations. The total transfer time was recorded, and throughput was computed as the ratio of file size to transfer time. This test aims to characterize the overhead introduced by small transfer sizes and identify the threshold at which performance transitions from overhead-dominated to transfer-dominated regimes, with particular attention to the 512-byte sector boundary alignment specified in the eMMC datasheet.

Building upon Test B0, test B1 extends the chunk size range up to 2 MiB while operating on a larger 4 MiB file. The extended range allows observation of throughput behavior when chunk sizes approach or exceed typical buffer and cache sizes within the storage controller. As in Test B0, 10 measurements per configuration were collected for both read and write operations. This test is designed to reveal potential anomalies at large transfer sizes that may arise from internal controller buffer management or DMA constraints.

To investigate unexpected throughput variations observed in Test B1 at large chunk sizes, a controlled experiment (Test B2) was designed with a fixed number of 500 iterations per chunk size configuration. This approach decouples the number of I/O operations from chunk size, allowing clearer observation of per-operation behavior independent of total data volume. Both read and write throughput were measured across the full range of chunk sizes from 1 byte to 2 MiB. By maintaining constant iteration count, this test isolates throughput anomalies attributable to specific chunk sizes rather than cumulative effects.

Test S1 evaluates throughput degradation under concurrent load conditions. Read and write throughput were measured for chunk sizes from 1 to 8192 bytes while varying the number of concurrent tasks from 0 (single task, no contention) to 4 additional tasks. A fixed number of iterations was maintained across all configurations to ensure comparability. This test quantifies the effective serialization overhead imposed by the storage subsystem under multi-task workloads typical of RTOS-based embedded applications.

Test S2 examines filesystem metadata operation overhead through two complementary experiments:

• Open/Close Latency. The time required to open and close varying numbers of pre-existing files was measured. File counts of 200, 400, 600, 800, and 1000 were tested, with 10 runs per configuration. For each run, all files in the set were opened and immediately closed in sequence. Both the total operation time and the per file latency were recorded to assess how metadata operations scale with filesystem population.
• Create/Delete Timing. Using the same file count configurations (200–1000 files in steps of 200) and 10 runs per configuration, the total time to create all files and, separately, the total time to delete them was measured. Per file latencies were computed to quantify the overhead of inode allocation, directory entry management, and block allocation/deallocation.

To characterize non-sequential access patterns representative of indexed data retrieval in embedded databases or configuration storage, a 1 MiB file was created and subjected to 1000 random read accesses per test run, with chunk sizes ranging from 1 to 1024 bytes (Test M1). Each configuration was repeated for 10 runs. For each run, we measured the mean latency (time between operation initiation and completion) and computed the aggregate random access throughput. This test reveals the seek-time overhead inherent to the storage subsystem and its interaction with transfer size.

Test M2 investigates the impact of filesystem utilization on metadata operation latency over an extended period, simulating a realistic sensor node deployment scenario. The experiment continuously creates, opens, writes, flushes, and closes files at 30 min intervals until the storage volume is nearly full, monitoring operation latencies throughout the process. Three concurrent file streams were maintained to assess consistency across parallel operations and to simulate multi-sensor data logging. The test ran for approximately 90 h, during which available storage decreased from approximately $3.7$ $\mathrm{GB}$ to near zero. For each file operation cycle, the latencies of create, open, close, and flush operations were recorded along with the current available storage capacity. This test reveals how filesystem performance degrades as the volume approaches full capacity and internal fragmentation accumulates—a critical consideration for long-duration autonomous deployments where storage management directly impacts system reliability. All experiments were conducted under controlled laboratory conditions using a regulated power supply in order to isolate the performance characteristics of the storage subsystem from external disturbances. While this approach enables reproducible benchmarking and precise identification of architectural bottlenecks, it does not fully capture the potential impact of real-world operating conditions.

5. Results Analysis

The experimental results reveal several noteworthy characteristics of the embedded storage subsystem, with implications for both system design and application optimization. We organize the discussion around six major themes: the impact of chunk size on sequential I/O performance, the asymmetry between read and write operations, random access characteristics, filesystem metadata overhead, anomalous behaviors at large transfer sizes, and the effects of concurrent access.

5.1. Sequential I/O Performance and the 512-Byte Threshold

The throughput measurements on the 1 MiB file (Test B0, Figure 3) demonstrate a clear correlation between chunk size and I/O efficiency. Read throughput increases from approximately 150 $\mathrm{kB}{\mathrm{s}}^{-1}$ at 1-byte chunks to over 4000 $\mathrm{kB}{\mathrm{s}}^{-1}$ at 1024 bytes, representing a 27-fold improvement. The write path exhibits a similar trend, though with consistently lower absolute values ranging from approximately 100 $\mathrm{kB}{\mathrm{s}}^{-1}$ to 1650 $\mathrm{kB}{\mathrm{s}}^{-1}$. The pronounced inflection point in the throughput curve around 512 bytes aligns with the native block size of the eMMC device, as specified in the manufacturer’s datasheet. This confirms that sub-block transfers incur substantial overhead due to read–modify–write cycles inherent to flash memory operations. When a write request is smaller than the native block size, the storage controller must read the entire block, modify the relevant portion in an internal buffer, and write the complete block back to the flash array—effectively tripling the I/O workload for small writes. This observation carries direct practical implications: applications performing frequent small writes should employ buffering strategies to aggregate data into 512-byte aligned chunks whenever possible. The cost of byte-granularity access is particularly severe, with write times exceeding 11 $\mathrm{s}$ for a 1 MiB file when using 1-byte chunks, compared to approximately 600 $\mathrm{m}$$\mathrm{s}$ at 1024-byte chunks—a reduction of more than 18×.

5.2. Read/Write Asymmetry

A consistent asymmetry between read and write performance emerges across all sequential tests, with reads outperforming writes by a factor ranging from 1.5× to 2.5× depending on chunk size and file dimensions. This behavior is characteristic of NAND flash storage, where write operations require page programming and potential block erasure, whereas reads can proceed at the native speed of the flash array without modification overhead. The comparative throughput plots from Tests B0 and B1 reveal that this asymmetry is more pronounced at smaller chunk sizes, where the per-operation overhead dominates the total transfer time. At larger chunk sizes approaching 2 MiB (Test B1, Figure 4), the performance gap narrows somewhat, suggesting that the storage controller can better amortize write overhead when handling larger contiguous transfers. However, even at the largest tested chunk sizes, read throughput maintains a measurable advantage, reaching approximately 28,000 $\mathrm{kB}{\mathrm{s}}^{-1}$ compared to 26,000 $\mathrm{kB}{\mathrm{s}}^{-1}$ for writes—a ratio of approximately 1.08×. The narrowing of the read/write gap at large chunk sizes can be attributed to the increasing dominance of bulk data transfer time over per-operation setup costs. For very large transfers, both read and write operations approach the theoretical bandwidth limit of the storage interface, with the intrinsic flash programming overhead becoming a smaller fraction of total operation time.

5.3. Random Access Characteristics

Test M1 provides insight into the random access performance profile, which differs substantially from sequential patterns (Figure 5). The latency measurements show relatively stable values around 193 $\mathrm{m}$$\mathrm{s}$ to 198 $\mathrm{m}$$\mathrm{s}$ for chunk sizes up to 64 bytes, followed by a progressive increase to approximately 270 $\mathrm{m}$$\mathrm{s}$ at 1024 bytes. This bimodal behavior reflects the interplay between two distinct cost components: seek time, which dominates at small transfer sizes, and data transfer time, which becomes significant for larger chunks. For small random accesses, the latency is dominated by the time required to locate and address the target block within the flash array. This seek component remains approximately constant regardless of how much data is ultimately transferred. As chunk size increases, the data transfer component grows proportionally, adding to the baseline seek latency and producing the observed increase in total operation time. The corresponding throughput curve exhibits the expected inverse relationship with latency, reaching approximately 3700 $\mathrm{kB}{\mathrm{s}}^{-1}$ at 1024-byte chunks. Notably, the random access throughput remains substantially below sequential throughput even at equivalent chunk sizes: at 1024 bytes, random read throughput is approximately 3700 $\mathrm{kB}{\mathrm{s}}^{-1}$ compared to 4050 $\mathrm{kB}{\mathrm{s}}^{-1}$ for sequential reads—a penalty of approximately 9%. This penalty would be expected to grow at larger chunk sizes where sequential access can better exploit read-ahead mechanisms and contiguous block allocation. These findings underscore the importance of access pattern optimization in embedded applications, particularly those involving database operations, indexed file access, or logging systems with frequent random writes.

5.4. Filesystem Metadata Operations

Test S2 examines metadata-intensive operations, revealing important scalability characteristics of the filesystem implementation that warrant careful consideration in application design.

5.4.1. Open/Close Latency Scaling

The open/close latency test (

Table 3. Open/Close Time and Latency (Mean ± Std Dev).

Number of Files	Open/Close Time (ms)	Latency (μs)
200	723.00 ± 0.00	3615.00 ± 0.00
400	2720.50 ± 0.50	6801.25 ± 1.25
600	5991.60 ± 0.49	9986.00 ± 0.82
800	10,538.20 ± 0.40	13,172.75 ± 0.56
1000	16,360.70 ± 0.64	16,360.70 ± 0.64

) shows a remarkably linear relationship between file count and per file latency, increasing from approximately $3.6$ $\mathrm{m}$$\mathrm{s}$ per file at 200 files to $16.3$ $\mathrm{m}$$\mathrm{s}$ at 1000 files. This linear degradation suggests that directory traversal or inode lookup operations scale with $O\left(n\right)$ complexity, possibly indicating a linear search through directory entries rather than indexed access structures such as B-trees or hash tables. The total time for open/close operations across the entire file set exhibits superlinear growth, consistent with $O\left(n^2\right)$ complexity when accounting for both the number of files processed and the per file latency increase. Specifically, processing 200 files requires approximately $0.7$ $\mathrm{s}$, while 1000 files requires approximately $16.3$ $\mathrm{s}$—a ratio of 23× for a 5× increase in file count, closely matching the expected quadratic relationship. This scalability behavior warrants careful consideration in applications managing large numbers of files. Alternative architectural strategies such as hierarchical directory structures (distributing files across multiple subdirectories), reduced file counts through data aggregation (consolidating multiple logical records into single physical files), or memory-resident caching of frequently accessed file handles may prove beneficial for maintaining acceptable performance.

5.4.2. Creation and Deletion Asymmetry

The create/delete timing results (

Table 4. Delete and Create Time (Mean ± Std Dev).

Number of Files	Delete Time (ms)	Create Time (ms)
200	782.30 ± 2.31	2029.40 ± 3.63
400	2602.20 ± 0.75	7531.20 ± 1.25
600	5467.40 ± 3.78	16,498.20 ± 6.92
800	9373.20 ± 2.64	28,929.90 ± 1.73
1000	14,324.90 ± 4.53	44,841.00 ± 15.56

) reveal a striking asymmetry: file creation requires approximately 3× longer than deletion across all tested configurations. At 200 files, the mean creation time is approximately 2 $\mathrm{s}$ versus $0.9$ $\mathrm{s}$ for deletion; at 1000 files, these values grow to approximately 44 $\mathrm{s}$ and $14.5$ $\mathrm{s}$, respectively. This disparity likely reflects the additional work required during file creation, including: (1) allocation and initialization of an inode structure, (2) insertion of a new directory entry with appropriate linking, (3) initial data block allocation if the file is created with a non-zero size, and (4) filesystem journal updates for crash consistency. In contrast, deletion primarily involves marking the inode and associated data blocks as free and removing the directory entry—operations that can often be performed with fewer synchronous writes to persistent storage. The superlinear growth in creation time with file count (from approximately 2 $\mathrm{s}$ at 200 files to 44 $\mathrm{s}$ at 1000 files) suggests potential contention for filesystem metadata structures, possibly including the inode allocation bitmap, free block map, or directory entry tables. This growth rate exceeds simple $O\left(n\right)$ scaling and may indicate $O(nlogn)$ or $O\left(n^2\right)$ behavior depending on the underlying filesystem implementation.

5.5. Anomalous Behavior at Large Chunk Sizes

Test B2 was specifically designed to investigate the unexpected throughput variations observed in Test B1 when using large chunk sizes on the 4 MiB file. By fixing the number of iterations at 500 regardless of chunk size, this test decouples the number of I/O operations from the transfer size, enabling clearer observation of per-operation scaling behavior. The read throughput curve (Figure 6) reveals a saturation effect, with throughput reaching a plateau around 14,000 $\mathrm{kB}{\mathrm{s}}^{-1}$ for chunks exceeding 64 KiB. This ceiling likely represents a hardware limitation within the storage subsystem. Potential bottlenecks include: the DMA transfer buffer size within the eMMC controller, memory controller bandwidth limitations when moving data between storage and system memory, or the capacity of internal read-ahead buffers within the eMMC device itself. The saturation behavior indicates that, beyond a certain transfer size, increasing chunk dimensions provides no additional throughput benefit for read operations. Applications can exploit this finding by limiting read buffer sizes to approximately 64 KiB, thereby reducing memory footprint without sacrificing performance. The write throughput behavior presents a more complex and unexpected pattern, with a pronounced dip at 128 KiB before recovering at larger chunk sizes (Figure 6). This anomaly resists straightforward explanation and may stem from several potential causes:

1.

Internal boundary effects: The 128 KiB transfer size may interact unfavorably with internal page or block boundaries within the eMMC device, triggering additional wear-leveling or garbage collection operations.

2.

Write cache behavior: The storage controller may employ different caching strategies depending on transfer size. A 128 KiB transfer might exceed an internal cache threshold, triggering synchronous flush operations that temporarily degrade throughput, while larger transfers engage a different (more efficient) bulk transfer mode.

3.

Memory management overhead: The operating system’s memory allocator may handle 128 KiB allocations differently than smaller or larger sizes, potentially crossing a threshold between slab allocation and direct page allocation with different performance characteristics.

4.

Bus protocol transitions: The underlying communication protocol (likely SDIO or similar) may employ different command sequences or transfer modes at this size boundary.

Further investigation with additional instrumentation—such as examination of eMMC controller registers, kernel memory allocation tracing, or bus protocol analysis—would be required to definitively identify the root cause. For practical purposes, applications targeting this platform should either avoid the 128 KiB transfer size for write operations or implement adaptive chunking strategies capable of detecting and responding to such device-specific anomalies.

Figure 6. Test B2 results: Throughput measurements with fixed iteration count (500) to investigate large chunk anomalies.

Figure 6. Test B2 results: Throughput measurements with fixed iteration count (500) to investigate large chunk anomalies.

5.6. Concurrent Access Degradation

Test S1 quantifies the impact of concurrent task execution on I/O throughput, revealing severe and systematic performance degradation as the number of competing tasks increases (Figure 7). The results are presented on a logarithmic scale to accommodate the wide dynamic range of observed throughput values.

With no concurrent tasks (single-task baseline), read throughput ranges from approximately 800 $\mathrm{kB}{\mathrm{s}}^{-1}$ to 8000 $\mathrm{kB}{\mathrm{s}}^{-1}$ across the tested chunk sizes. The introduction of concurrent tasks produces dramatic degradation:

• 1 concurrent task: Throughput decreases by approximately 50%, suggesting significant contention overhead even with minimal concurrency.
• 2 concurrent tasks: Throughput drops by approximately one order of magnitude, with read performance falling to 150 $\mathrm{kB}{\mathrm{s}}^{-1}$ to 1000 $\mathrm{kB}{\mathrm{s}}^{-1}$.
• 3–4 concurrent tasks: Performance collapses to 5 $\mathrm{kB}{\mathrm{s}}^{-1}$ to 200 $\mathrm{kB}{\mathrm{s}}^{-1}$ regardless of chunk size, representing a reduction of nearly two orders of magnitude from the single-task baseline.

Write throughput exhibits even more dramatic degradation under concurrent load, with four concurrent tasks reducing performance to approximately 3 $\mathrm{kB}{\mathrm{s}}^{-1}$ to 100 $\mathrm{kB}{\mathrm{s}}^{-1}$. The near-complete flattening of the throughput curves at high concurrency levels is particularly noteworthy: the characteristic improvement with increasing chunk size, clearly visible in the single-task case, essentially disappears when four concurrent tasks compete for storage access.

This flattening suggests that under heavy contention, the system becomes entirely bottlenecked by synchronization and scheduling overhead rather than actual data transfer. The residual throughput represents the fraction of time during which a task successfully acquires exclusive access to the storage subsystem and completes useful work before yielding to another waiting task. The concurrent workload experiments indirectly illustrate the phenomenon: as additional computational tasks compete for CPU time, the effective throughput of storage operations decreases dramatically due to scheduling contention. While our experiments focused on task-level concurrency rather than interrupt-level preemption, similar mechanisms apply when storage tasks are interrupted by high-frequency ISR activity.

These findings carry significant implications for embedded system architecture. The storage subsystem, despite being based on solid-state technology with theoretically parallel internal structure, behaves as an effectively serial resource when accessed through the standard filesystem interface. The absence of meaningful performance scaling with concurrency—indeed, the severe degradation—indicates that the filesystem and block layer implementations do not effectively exploit any internal parallelism the eMMC device might offer. Indeed, storage accesses typically involve multiple software layers, including filesystem management, block device drivers, and peripheral communication handlers. As a result, these operations may be preempted by higher-priority tasks or interrupts during execution. When high-priority interrupt routines (such as sensor acquisition, communication interfaces, or system timers) preempt storage-related tasks, the completion time of I/O operations may increase, introducing additional latency variability and timing jitter. Applications requiring concurrent I/O access should consider architectural approaches such as:

• Dedicated I/O task with request queuing: Centralizing all storage operations through a single task with a request queue eliminates filesystem-level contention and allows application-level optimization of access patterns.
• Explicit operation serialization: Using mutexes or semaphores to serialize storage operations at the application level, accepting the resulting latency in exchange for predictable throughput.
• Workload segregation: Separating high-bandwidth sequential operations (e.g., data logging) from latency-sensitive random access patterns (e.g., configuration reads), potentially using separate storage volumes or time-division multiplexing.

5.7. Long-Duration Performance Degradation

Test M2 provides critical insight into the temporal evolution of filesystem performance as storage capacity is progressively consumed. This experiment, spanning approximately 90 h of continuous operation, reveals severe degradation patterns that have significant implications for long-running embedded systems.

The time-series plot (Figure 8) tracks create, open, close, and flush latencies for a representative file stream over the entire test duration. The results reveal a clear divergence in behavior between different operation types:

• Create and Open Operations. Both file creation and opening exhibit dramatic latency increases as the test progresses. Initial latencies of approximately 10 $\mathrm{m}$$\mathrm{s}$ to 20 $\mathrm{m}$$\mathrm{s}$ grow to over 1000 $\mathrm{m}$$\mathrm{s}$ for create operations and approximately 700 $\mathrm{m}$$\mathrm{s}$ for open operations by the end of the test. The degradation follows a distinctly nonlinear trajectory, with relatively stable performance during the first 40 h followed by accelerating degradation. This pattern suggests that the filesystem maintains acceptable performance while sufficient free space and contiguous allocation regions remain available, but encounters increasing difficulty as fragmentation accumulates and free space management structures grow more complex.
• Close and Flush Operations. In stark contrast, close operations maintain remarkably stable latencies throughout the test, remaining consistently around 2 $\mathrm{m}$$\mathrm{s}$ to 10 $\mathrm{m}$$\mathrm{s}$ with occasional spikes. Flush operations similarly show stable baseline performance around 18 $\mathrm{m}$$\mathrm{s}$ to 25 $\mathrm{m}$$\mathrm{s}$ with sporadic excursions to 35 $\mathrm{m}$$\mathrm{s}$ to 46 $\mathrm{m}$$\mathrm{s}$. This stability indicates that these operations are largely decoupled from the filesystem’s space allocation mechanisms—close primarily releases in-memory resources and updates access timestamps, while flush synchronizes already-allocated buffers to persistent storage.

Figure 8. Test M2 temporal evolution: Operation latencies for create, open, close, and flush operations over the 90-h test duration. Note the severe degradation of create and open latencies while close and flush remain stable.

Figure 8. Test M2 temporal evolution: Operation latencies for create, open, close, and flush operations over the 90-h test duration. Note the severe degradation of create and open latencies while close and flush remain stable.

The curve fitting analysis reveals distinct behaviors across the three filesystem operations. The close latency exhibits a nearly constant trend over time, as confirmed by a linear fit with a negligible slope (−0.080) and very low coefficient of determination ($R^2=0.0027$), indicating the absence of a meaningful temporal dependency. In contrast, both create and open operations show a clear exponential growth pattern, with fitted parameters $A=38.06$, $B=0.96$ and $A=20.60$, $B=0.93$, respectively. The high goodness-of-fit values ($R^2=0.9853$ for create and $R^2=0.9844$ for open) confirm that an exponential model accurately captures the observed performance degradation. This behavior suggests that filesystem aging and resource saturation disproportionately impact metadata-intensive operations, leading to rapidly increasing latencies over time, while simpler operations such as file closure remain largely unaffected.

To isolate the effect of storage utilization from potential time-dependent factors (such as thermal effects or background system activity), the operation latencies were plotted against available storage capacity. At time 0, the available bytes are $3.8\times {10}^9$, while at the end of the 90-min test they decrease to $2.8\times {10}^7$, exhibiting the same behavior observed in Figure 8.

• Create Time vs. Available Space. The create operation latency shows a clear inverse correlation with available storage. When approximately $3.5$ $\mathrm{GB}$ remains available, creation latency is under 50 $\mathrm{m}$$\mathrm{s}$. As available space decreases below $1.5$ $\mathrm{GB}$, latency begins increasing more rapidly, reaching approximately 400 $\mathrm{m}$$\mathrm{s}$ at 1 $\mathrm{GB}$ available and exceeding 1200 $\mathrm{m}$$\mathrm{s}$ as the volume approaches full capacity. All three file streams exhibit nearly identical behavior, confirming that the degradation is a filesystem-level phenomenon rather than file-specific. The shape of this curve—relatively flat initially, then increasingly steep—is consistent with the behavior expected from a filesystem that must search increasingly fragmented free space maps to locate suitable allocation regions. As free space becomes scarce and fragmented, the allocator must examine more candidate regions before finding one that satisfies the allocation request.
• Open Time vs. Available Space. The open operation latency follows a similar pattern, though with somewhat lower absolute values. This correlation is initially surprising, as file opening should primarily involve inode lookup rather than space allocation. However, the observed behavior can be explained by several mechanisms: (1) the filesystem may perform speculative block preallocation during open for write access, (2) inode table fragmentation may increase as more inodes are allocated, requiring longer search times, or (3) internal filesystem caches may become less effective as the number of allocated objects grows.
• Close Time vs. Available Space. Close operation latency shows no meaningful correlation with available storage capacity. The latency remains bounded within 1 $\mathrm{m}$$\mathrm{s}$ to 5 $\mathrm{m}$$\mathrm{s}$ for the vast majority of operations, with occasional spikes to 15 $\mathrm{m}$$\mathrm{s}$ to 26 $\mathrm{m}$$\mathrm{s}$ that appear randomly distributed across the capacity range. This confirms that close operations are independent of space allocation state and can be relied upon for consistent timing even on nearly-full volumes.
• Flush Time vs. Available Space. Similarly, flush operation latency exhibits no systematic dependence on available capacity. The baseline latency of approximately 18 $\mathrm{m}$$\mathrm{s}$ with occasional spikes to 45 $\mathrm{m}$$\mathrm{s}$ remains consistent throughout the capacity range. The sporadic spikes likely reflect background filesystem housekeeping activities (journal commits, metadata writeback) rather than space-related effects.

The findings from Test M2 have significant implications for embedded systems designed for long-duration autonomous operation:

• Capacity Headroom Requirements. The nonlinear degradation pattern suggests that maintaining a minimum free space buffer is essential for consistent performance. Based on the observed data, performance remains acceptable (create latency under 200 $\mathrm{m}$$\mathrm{s}$) when at least 40–50% of the volume capacity remains available. Systems should implement proactive space management policies that trigger data archival, compression, or deletion well before the volume approaches full capacity.
• Operation Selection for Time-Critical Paths. Applications with real-time constraints should minimize create and open operations in time-critical code paths when operating on volumes with limited free space. Pre-opening files during initialization or maintaining pools of pre-created files can help isolate time-sensitive operations from allocation-related latency variability.
• Monitoring and Alerting. The clear correlation between available space and operation latency provides a basis for predictive performance monitoring. Systems can track create/open latencies as early indicators of impending performance degradation, triggering maintenance actions before user-visible performance impacts occur.

5.8. Comparative Analysis with Related Works

To summarize, from a system-level perspective, the results indicate that storage I/O behavior fundamentally constrains the achievable performance envelope of embedded multi-sensor platforms. In particular:

• Throughput collapse under concurrent access implies that naïve multi-threaded designs do not scale and may lead to system-level bottlenecks.
• Metadata latency growth directly impacts system responsiveness and can violate real-time constraints in long-running deployments.
• Storage-induced timing jitter propagates to higher-level tasks, potentially degrading sensing accuracy and control stability.

Therefore, storage must be treated as a first-class system component, co-designed together with task scheduling, buffering strategies, and data management policies.

To contextualize our findings within the broader embedded systems literature,

Table 5. Comparison of related work on embedded systems, file systems, and real-time I/O performance.

Study	Platform/System	Primary Focus	Key Quantitative Metrics
This Work	STM32U5 + eMMC 5.1 + ThreadX	Multi-sensor data logging, filesystem aging	Sequential: 14 MB/s read, 6–8 MB/s write; Metadata: 10–200+ ms (capacity-dependent); Concurrent degradation: 50% (1 task) to 98% (4 tasks)
Werbet et al. [17]	Nano-FS (resource-restricted)	Flash file system efficiency	Qualitative: “quite efficient” for severe computing restrictions
Phatrapornnant et al. [18]	Time-triggered architecture + DVS	Jitter reduction in embedded systems	Jitter reduced from 4.5 ms to 0.5 ms (89% reduction) with time-triggered architecture
Poudel et al. [19]	STM32L4 flash operations	Partial flash operations for energy saving	Energy savings: 50–75%; Latency: 2–10 ms (partial) vs. 20–100 ms (full)
Zhao et al. [20]	PRET-based I/O controller	Timing-accurate GPIO for multi-core	Timing accuracy: <1 μs jitter; Throughput: 1 MHz GPIO toggling
Qi et al. [21]	Emerging memory in MCUs	Memory technology survey	ReRAM: 10 ns write, 50 ns read; MRAM: 20 ns write/read; PCM: 100 ns write, 50 ns read
Jiang et al. [22]	Hardware/algorithm co-design	Real-time I/O control	Timing accuracy: 0.1 μs; Robustness: 99.9% under interference
Vaknin et al. [23]	Proper Timed I/O	High-accuracy real-time control	Timing accuracy: 1 μs; Jitter: <500 ns on conventional OS
Culic et al. [24]	Tock OS + eBPF (Rust-based)	Low-latency secure OS optimization	Original syscall latency: 5127 μs; Optimized interrupt handling: 60–208 μs (eBPF); Interrupt rate: up to 2 KHz

presents a quantitative comparison of our platform’s performance against representative studies addressing embedded storage, real-time I/O optimization, and timing determinism. The comparison spans diverse system architectures, from specialized real-time I/O controllers to general-purpose embedded file systems, highlighting the distinct design space our work addresses.

This comparative analysis positions our work as addressing a distinct but important design space: RTOS-based multi-sensor platforms with eMMC storage, where filesystem-level behavior dominates end-to-end performance. The quantitative baselines we establish complement existing work on ultra-low-latency I/O [20,22,23], and resource-optimized file systems [17], providing guidance for a class of embedded applications that balance throughput, capacity, and moderate real-time constraints.

6. Discussion and Limitations

Although the experimental setup employs synthetic workloads, the benchmark scenarios are designed to closely emulate real embedded multi-sensor deployments. The M2 scenario (periodic file lifecycle with three concurrent streams) directly models a system with multiple heterogeneous sensors (e.g., IMU, PPG, environmental sensors), each producing asynchronous data streams. Similarly, the concurrent workload experiments (S1) reproduce the interaction between sensing, processing, and storage tasks in a typical RTOS-based architecture. These mappings ensure that the observed performance limitations are representative of real deployment conditions rather than artificial benchmarks.

The comprehensive experimental characterization presented in this work reveals that optimal utilization of embedded storage subsystems requires careful attention to multiple interacting factors. In this section, we analyze the dominant performance bottlenecks, synthesize actionable guidelines for firmware developers, acknowledge threats to the validity of our findings, and outline directions for future work.

6.1. Performance Bottleneck Analysis

The experimental results allow us to identify and rank the primary factors limiting storage performance across different operating regimes.

• Flash Erase/Program Cycles. The consistent read/write asymmetry observed across all sequential tests (Tests B0, B1, B2) confirms that NAND flash programming overhead remains a fundamental constraint. Write operations require page programming and, when crossing block boundaries, potentially trigger erase cycles that dominate transfer time. The 512-byte threshold effect (Test B0) further demonstrates that sub-block writes incur read–modify–write penalties intrinsic to flash architecture. This bottleneck is largely hardware-determined and can only be mitigated through software buffering strategies.
• Filesystem Overhead. The superlinear scaling of metadata operations (Test S2) and the severe latency degradation observed as storage capacity diminishes (Test M2) indicate that filesystem overhead constitutes a major bottleneck for metadata-intensive workloads. The apparent $O\left(n\right)$ to $O\left(n^2\right)$ complexity of directory operations suggests that the FileX filesystem implementation employs linear search algorithms rather than indexed structures. This overhead becomes dominant when applications create, open, or delete files frequently, or when operating on nearly-full volumes where free space fragmentation complicates block allocation.
• RTOS Contention. The dramatic throughput collapse under concurrent access (Test S1)—approaching two orders of magnitude degradation with four concurrent tasks—reveals that RTOS-level contention for the storage subsystem represents the most severe bottleneck in multi-tasked environments. The flattening of throughput curves at high concurrency suggests that scheduling and synchronization overhead, rather than actual I/O operations, dominates execution time. This indicates that the filesystem and block driver implementations serialize access at a coarse granularity, failing to exploit any internal parallelism the eMMC device might offer.
• Bus Bandwidth. The read throughput saturation observed in Test B2 at approximately 14 $\mathrm{MB}{\mathrm{s}}^{-1}$ for chunk sizes exceeding 64 KiB suggests that bus bandwidth becomes limiting only for large sequential transfers. For typical embedded workloads involving smaller transfers or random access patterns, bus bandwidth is not the primary constraint. The SDIO interface connecting the MCU to the eMMC device appears adequately provisioned for most use cases.
• Cache and Memory Effects. The anomalous write throughput dip at 128 KiB (Test B2) may reflect interactions between transfer size and cache/memory management policies, though definitive attribution requires further investigation. The relatively stable performance of flush operations across all capacity levels (Test M2) suggests that write caching operates consistently regardless of volume utilization, indicating that cache effects do not introduce systematic performance variability under normal operating conditions.

6.2. Guidelines for Firmware Developers

Based on our experimental findings, we synthesize the following actionable guidelines for firmware developers targeting similar embedded platforms. In addition to low-level optimizations, we also highlight recurring software design patterns and lightweight architectural views, in line with recommended practices for software architecture description [25].

• Block Size Selection. Data transfers should be aligned with the 512-byte native sector boundary and preferably sized at 4 KiB or larger for sequential operations. This configuration minimizes per-operation overhead and avoids the severe performance penalties associated with sub-block transfers. For read-intensive applications, chunk sizes beyond 64 KiB provide no additional throughput benefit due to hardware saturation; memory can be conserved by limiting read buffers to this size.
• Buffering Strategy. Applications performing frequent small writes should implement application-level buffering to aggregate data into sector-aligned chunks before committing to storage. A ring buffer or double-buffering scheme can decouple data generation from storage commits, allowing the application to batch multiple small records into single write operations. This is particularly critical for sensor logging applications where individual samples may be only a few bytes.
  Design pattern perspective: This corresponds to a Producer–Consumer pattern, where data producers (e.g., sensors) enqueue samples and a dedicated consumer handles storage. The buffer can be modeled as a reusable architectural component mediating between data sources and storage.
  Example: Sensor tasks push samples into a shared queue, while a storage task periodically flushes aligned chunks to the filesystem.
• Task Architecture. Concurrent storage access should be explicitly managed rather than delegated to filesystem-level arbitration. Recommended approaches include:

  –

  Dedicated I/O task: Centralize all storage operations through a single task with a request queue, eliminating filesystem-level contention and enabling application-aware access pattern optimization.

  Design pattern: This reflects a Mediator or Active Object pattern, where the I/O task encapsulates all interactions with the storage subsystem.

  –

  Time-division multiplexing: Schedule storage-intensive operations during periods of low system activity, avoiding concurrent access entirely.

  –

  Workload segregation: Isolate high-bandwidth sequential operations (data logging) from latency-sensitive random access (configuration retrieval) using separate time slots or priority levels.

  Architectural note: This organization can be represented using a component-and-connector view, where application tasks interact with a single storage component via asynchronous message passing. This improves analyzability and reduces contention, as recommended in modern software architecture description practices [25].
• File Management Strategy. To mitigate metadata operation overhead:

  –

  Minimize file count through data aggregation, consolidating multiple logical records into single physical files with application-level indexing.

  –

  Employ hierarchical directory structures to reduce per-directory file counts when large numbers of files are unavoidable.

  –

  Cache file handles for frequently accessed files rather than repeatedly opening and closing them.

  –

  Pre-allocate files during system initialization when real-time constraints apply to subsequent operations.

  Design pattern perspective: File aggregation and indexing can be interpreted as an application-level Facade over the filesystem, hiding multiple logical records behind fewer physical files and simplifying access.
• Capacity Management. For systems designed for extended autonomous operation:

  –

  Maintain at least 40–50% free space to ensure consistent create/open latencies below 200 $\mathrm{m}$$\mathrm{s}$.

  –

  Implement proactive space management policies that trigger data archival, compression, or deletion before the volume approaches full capacity.

  –

  Monitor create/open latencies as early indicators of impending performance degradation.

  –

  Consider circular logging strategies that overwrite oldest data rather than accumulating files indefinitely.

  Architectural consideration: Capacity monitoring can be modeled as a cross-cutting concern (monitoring component) interacting with storage and application layers, aligning with architectural viewpoints discussed in [25].
• Anomaly Avoidance. The unexplained write throughput anomaly at 128 KiB demonstrates that device-specific non-monotonic performance characteristics may exist at certain operating points. Developers should:

  –

  Characterize target hardware empirically before finalizing buffer size selections.

  –

  Avoid chunk sizes that exhibit anomalous behavior, or implement adaptive chunking strategies.

  –

  Document device-specific quirks for future maintenance and porting efforts.

  Example: A simple adaptive strategy may dynamically switch between predefined chunk sizes based on observed throughput during runtime.

6.3. Threats to Validity

Several factors may limit the generalizability of our findings and should be considered when applying these results to other systems.

• Instrumentation Overhead. All timing measurements were performed using hardware timers with microsecond resolution, introducing minimal overhead. However, the act of measurement itself—particularly timestamp capture and result storage—may slightly perturb the quantities being measured. For very short operations (sub-millisecond), this overhead could represent a non-negligible fraction of the measured duration. We mitigated this concern by focusing analysis on operations with durations substantially exceeding instrumentation overhead.
• Caching Effects. The storage subsystem employs multiple caching layers (eMMC internal cache, filesystem buffer cache, potentially RTOS-level caching) whose behavior may not be fully characterized by our experiments. Repeated access to the same data regions may benefit from caching in ways that would not occur in production workloads with greater data diversity. We attempted to minimize cache effects by using file sizes exceeding typical cache capacities and by performing fresh file creation for each test iteration where appropriate.
• Temperature and Voltage Variations. All experiments were conducted under laboratory conditions with stable ambient temperature and regulated power supply. Embedded systems deployed in field conditions may experience temperature extremes and voltage fluctuations that affect flash memory performance. NAND flash programming times are known to exhibit temperature dependence, and these effects are not captured in our characterization.
• Storage Wear State. The eMMC device used in our experiments was relatively new, with minimal prior write cycling. Flash memory performance degrades over its lifetime as cells accumulate wear and the controller must increasingly rely on error correction and bad block management. Our results may therefore represent optimistic performance bounds that would not be sustained over the full device lifetime in write-intensive applications.
• Workload Representativeness. The mock sensor node workload (Test M2) was designed to approximate realistic embedded sensing scenarios, but actual deployment conditions vary widely. Applications with different file sizes, access patterns, or timing requirements may experience performance characteristics not fully captured by our benchmark suite. The 30 min sampling interval in Test M2 represents a specific use case that may not generalize to high-frequency data acquisition scenarios.
• Filesystem Implementation. Our results reflect the behavior of the specific filesystem implementation (Azure RTOS FileX) and its configuration on the target platform. Alternative filesystems (littlefs, SPIFFS, FatFs, ext4) or different configuration options (cluster size, caching parameters) would likely yield different performance characteristics. The guidelines presented should be validated against the specific filesystem employed in production.

6.4. Application Scenarios

The proposed storage characterization and derived design guidelines are directly applicable to several classes of embedded multi-sensor systems.

• Wearable biomedical monitoring: Platforms combining IMU, PPG, and ECG sensors typically generate continuous multi-modal data streams (tens to hundreds of kB/s). In such systems, improper buffering or concurrent I/O access may lead to data loss or timing violations. The observed throughput degradation under concurrency (up to 98%) highlights the need for centralized storage management in wearable devices.
• Environmental monitoring nodes: Long-term deployments (weeks to months) require continuous logging with minimal maintenance. The exponential increase in metadata latency observed when storage utilization exceeds 60% demonstrates the importance of proactive capacity management policies.
• Industrial condition monitoring: High-frequency vibration and acoustic sensors require deterministic logging under real-time constraints. The measured timing jitter and latency variability indicate that storage I/O must be decoupled from control loops using buffering and dedicated I/O tasks.

These scenarios demonstrate that storage I/O is not a secondary concern but a system-level design constraint that directly impacts reliability, determinism, and deployment lifetime.

7. Conclusions and Future Work

This work presents a systematic characterization of I/O performance for an eMMC-based storage subsystem on an STM32U5 microcontroller platform. Through a suite of seven benchmark tests spanning sequential throughput, random access, metadata operations, concurrent access, and long-duration capacity-fill scenarios, we have quantified the performance envelope and identified critical bottlenecks affecting embedded storage systems. Our principal findings include: (1) the 512-byte sector alignment threshold below which write performance degrades by up to 18×; (2) filesystem metadata operations exhibiting $O\left(n^2\right)$ scaling that severely limits scalability with file count; (3) concurrent access degradation approaching two orders of magnitude with four competing tasks; and (4) create/open latency increases exceeding 50× as storage volumes approach capacity. These results underscore the importance of storage-aware firmware design and provide quantitative guidance for developers targeting similar platforms. Key limitations of the study include generalizability across platforms, restricted workload diversity, scalability beyond four concurrent tasks, and lack of validation under real-world environmental conditions.

Several directions merit further investigation:

• Energy Profiling. The current work focuses exclusively on timing metrics. Correlating I/O operations with energy consumption would enable optimization for battery-powered deployments where energy efficiency may be as important as throughput.
• Wear Impact Analysis. Longitudinal studies tracking performance evolution over extended write cycling would quantify the degree to which our results degrade over device lifetime and inform wear-leveling strategy selection.
• Alternative Filesystems. Comparative evaluation of embedded-optimized filesystems (littlefs, SPIFFS, FatFs) against the FileX implementation characterized here would identify whether the observed bottlenecks are fundamental to flash storage or artifacts of filesystem implementation choices.
• Broader Platform Coverage. Extending the benchmark suite to other MCU families (e.g., NXP i.MX RT, Espressif ESP32, Raspberry Pi RP2350) and storage technologies (SD cards, NOR flash, external SPI NAND) would establish the generalizability of our findings and identify platform-specific optimization opportunities.
• Real-Time Guarantees. Formal analysis of worst-case execution times for storage operations, incorporating the variability observed in our experiments, would support the development of storage access patterns compatible with hard real-time constraints.
• DMA and Advanced Transfer Strategies. Systematic evaluation of DMA configurations, double-buffering schemes, and alternative transfer modes would complement the current characterization and potentially reveal additional optimization opportunities not explored in this study.