Multi-modal storage resource dynamic scheduling system under computing power limited scene

Abstract

The invention relates to the technical field of wireless communication and interface protocol switching, in particular to a Bluetooth and USB dynamic switching firmware system based on event driving. The system aims at solving the problems of resource conflicts, data integrity risks and rough switching caused by the fact that Bluetooth audio receiving and USB large-capacity storage share a flash memory on a resource-limited embedded platform. An event-driven architecture is adopted, and the switching opportunity is judged through cooperation of USB bus state detection and a timer; a lightweight index table is constructed by using a filename hash mapping mechanism, RAM occupation is reduced, and file search is accelerated; a transactional flash memory write-in process is introduced, and power-down consistency recovery is realized in combination with log rollback; gATT Indication and triple verification are adopted on the Bluetooth side, so that the transmission reliability is guaranteed; and mutual exclusion access of the dual-mode to the flash memory is ensured through mutual exclusion semaphore and physical layer isolation. According to the invention, safe, smooth and low-overhead dual-mode dynamic switching can be realized.

Description

Technical Field

[0001] This invention relates to the field of embedded systems and data storage technology, and in particular to a dynamic scheduling system for multimodal storage resources in scenarios with limited computing power. Background Technology

[0002] Limited by overall BOM cost and static power consumption constraints, edge nodes often use 32-bit microcontrollers with low computing power and narrow bandwidth memory (typically between 64KB and 128KB) as their control core. However, actual business logic requires these small pieces of hardware to run two or more extremely heavy and sensitive protocol stacks simultaneously: one is the Bluetooth Low Energy protocol responsible for real-time audio streaming, and the other is the USB mass storage protocol that emulates the device as a PC-side USB flash drive. When these two attempt to share the same non-volatile flash memory, a series of deep-seated underlying technical bottlenecks arise.

[0003] In traditional single-task embedded logic, developers typically use static switching or simple application-layer commands to forcibly shut down one module and start another. However, in real-world dual-mode scenarios like "Bluetooth audio + USB storage," this switching logic is extremely crude and dangerous.

[0004] The most typical technical pain point is that the USB protocol stack's timing is completely controlled by the host computer (such as a PC), and Flash operations initiated by the host computer (especially when writing critical metadata such as FAT file system table entries and cluster chain allocation) are not controlled by the MCU. If, while USB is performing a programming or erasing cycle on a physical sector of the Flash, the system immediately relinquishes bus control and forcibly switches to Bluetooth mode due to a captured Bluetooth connection event, the Flash's internal state machine will be in an undefined and uncontrollable state. This "dirty write" phenomenon caused by a lack of low-level state awareness not only corrupts the currently written file data, but more critically, it may cause logical corruption of the File Allocation Table (FAT), making the entire flash volume unrecognizable by the host computer upon the next mounting. Existing mutex mechanisms often struggle to avoid critical section corruption caused by interrupt preemption on computing-constrained platforms, and conventional kernel schedulers are powerless to handle such physical-level conflicts.

[0005] Another major bottleneck in computing-constrained scenarios lies in the conflict between file search efficiency and RAM usage. The standard FATFS file system is extremely cumbersome when handling long filenames or searching for a massive number of small files: it needs to read directory entries sector by sector, load the complete string into RAM, and then perform byte-by-byte comparisons via the CPU.

[0006] On platforms with less than 64KB of RAM, this approach is disastrous. To ensure uninterrupted Bluetooth real-time audio streaming, a sufficiently large circular buffer must be allocated in memory to smooth out latency fluctuations caused by link jitter. If the file system occupies a large amount of cache space and consumes hundreds of milliseconds due to scanning the entire directory, it will directly squeeze the survival space of the audio buffer, causing jitter in system task scheduling, and ultimately directly leading to loss of audio synchronization, which manifests as obvious physical frame breaks or nonlinear distortion at the acoustic output. A deeper problem is that frequent mode switching means that the system needs to repeatedly scan the directory tree. This O(n) complexity linear search not only slows down the system response speed but also greatly wastes valuable CPU computing power. On MCUs without complex memory management units, how to achieve O(1) level fast positioning with minimal RAM overhead is a problem that the industry urgently needs to solve.

[0007] Besides the competition for internal resources, the uncertainty of the external environment also brings a double blow to the system. First, there's the issue of Bluetooth communication reliability. In complex electromagnetic environments such as industrial sites or edge deployments, the standard Bluetooth Notify mechanism, lacking strict application-layer verification and retransmission strategies, is prone to packet loss or corrupted packets. If the system blindly submits these damaged audio data frames containing erroneous semantics directly to the Flash write process, it will cause permanent contamination of the stored content.

[0008] An even more severe challenge comes from power-loss security. Embedded Flash (especially NOR / NAND Flash) does not inherently support hardware-level transaction operations. If the device encounters power fluctuations or abnormal power outages during mode switching or critical moments of Flash programming, the lack of effective log rollback or snapshot recovery mechanisms can lead to the complete loss of partially written data, or even cause mapping table pointer corruption. In battery-powered or outdoor mobile devices, because this data consistency depends entirely on power stability, the system's robustness is extremely fragile.

[0009] Current solutions often compromise on one aspect while addressing another: security-focused solutions often sacrifice real-time performance by adopting a fully blocking operation mode, resulting in a poor user experience; while speed-focused solutions typically ignore the atomic operation requirements of the Flash underlying layer, leading to logical corruption of the file system after the device has been running for a period of time. This multi-faceted trade-off between "dynamic switching and data integrity," "storage density and memory usage," and "link unreliability and power-loss consistency" has become a core challenge hindering the evolution of multimodal edge nodes towards high reliability.

[0010] Therefore, there is an urgent need to build a completely new scheduling system. This system should have an event-driven top-level architecture, possess a keen awareness of the underlying hardware bus status, and ensure the physical security and logical integrity of heterogeneous protocol stacks sharing Flash memory without relying on a high-performance kernel. This can be achieved through collaborative optimization of memory allocation, the introduction of transactional write logic, and a lightweight hash mapping mechanism. This is not only crucial for improving the stability of edge devices but also an essential path to resolving the contradictions of multi-task concurrency in resource-constrained scenarios. Summary of the Invention

[0011] To achieve the aforementioned objectives, this invention proposes a dynamic scheduling system for multimodal storage resources in computing-constrained scenarios. The system is implemented using an embedded microcontroller platform and includes a main control module, a Bluetooth communication module, a USB interface module, and a file system module. The main control module, serving as the system's scheduling and arbitration core, runs on a 32-bit microcontroller kernel and is equipped with a direct memory access (DMA) controller, hardware timers, and an interrupt controller. The Bluetooth communication module is configured to receive real-time audio streams based on a low-power Bluetooth protocol stack and encapsulates them into a private frame structure containing a magic number segment, a serial number, a variable-length payload, and a checksum. The USB interface module is configured as a large-capacity storage device to support bursty file read / write operations, and its status register includes at least NakIn, NakOut, and Busy bits. The system indicates the instantaneous busy / idle state of the USB bus; the file system module, deployed on non-volatile flash memory and using a FAT-compatible format, maintains the logical consistency of the storage volume through a preset lightweight hash mapping table and transaction log area; after capturing a mode switching event, the main control module triggers a polling sequence of the USB interface module status register; if the bus is detected to be busy, the switching request is suspended and a hardware timer is activated to open the logical cluster write protection window; after confirming that the bus is idle or the protection window has timed out, the main control module performs an atomic switching operation, which includes: disabling the USB global interrupt, releasing the physical layer mutex semaphore and the file system level mutex lock, setting the USB data pin to a high impedance state to simulate a physical unplug signal, clearing the USB endpoint buffer RAM area, and starting a forced cold protection period to block flash memory access.

[0012] Preferably, the atomic switching operation enforces a cold protection period duration during which the main control module blocks all read / write scheduling requests for non-volatile flash memory.

[0013] Preferably, the file system module divides two independent sectors in the non-volatile flash memory, with physical addresses strictly aligned to the 4KB boundary, as reserved sectors for the mapping table. In response to file change events in USB mode, the main control module performs a CRC32 hash operation on the UTF-8 encoded long filename of the target file to generate a 32-bit value H, and calculates a 16-bit index identifier ID according to the formula ID=(H>>16)⊕(H&0xFFFF). The main control module constructs a key-value pair with the ID and the file's starting cluster number, and writes it, along with a dirty bit flag initially set to 1, into an empty slot in the reserved sector of the mapping table.

[0014] Preferably, at the critical point of switching from USB mode to Bluetooth mode, the main control module traverses the reserved sector of the mapping table and performs a synchronization operation, writes all entries with dirty bits set to 1 to flash memory and sets the dirty bits to 0; after entering Bluetooth mode, the main control module loads the entire mapping table into a preset 512-byte dedicated cache table in RAM, and subsequent file location requests perform O(1) complexity direct indexing in the cache table through the ID.

[0015] Preferably, the non-volatile flash memory has a preset transaction log area consisting of 64 16-byte log slots; each log slot contains a 2-byte target physical address, an 8-byte original data snapshot, a 2-byte checksum, and a 2-byte commit flag; before performing flash programming operations, the main control module first fills the address to be written and the original data into an empty log slot, and maintains the commit flag at the initial value of 0xFFFFFFFF; only after the data writing is completed and the verification is consistent, the main control module updates the corresponding commit flag to 0xA5A5A5A5 to form a transaction closed loop.

[0016] Preferably, during the power-on initialization or mode switching self-test phase, the system locates incomplete transactions with a commit flag of 0xFFFFFFFF by traversing the transaction log area and performs a rollback operation based on the original data snapshot in the log slot; if the abnormal write point is located in the reserved sector of the mapping table, the data is restored from the mirror sector; if it is located in the ordinary data area, the valid copy in the RAM cache is used to overwrite the abnormal write content.

[0017] Preferably, the Bluetooth communication module adopts a reliable transmission protocol that combines the GATT Indication mechanism with application layer verification. After receiving the Indication packet, the main control module performs triple verification in sequence, including magic number matching, payload CRC-16 comparison, and sequence number continuity and uniqueness checks. If any verification step fails, the main control module refuses to send the GATT Confirmation signal to force the sender to trigger link layer retransmission.

[0018] Preferably, the system sets the maximum continuous retransmission threshold to 10 times. If the continuous retransmission of frames with the same sequence number exceeds this threshold, the main control module executes the security protection logic, forcibly disconnects the Bluetooth connection and resets the protocol stack state machine.

[0019] Preferably, the physical layout of the non-volatile flash memory is strictly aligned with 4KB sectors as the smallest erase unit; the main control module controls the access timing of the heterogeneous protocol stack to the flash memory resources through mutex semaphores and file system locks. Any mode must release all mutex locks it holds before requesting flash memory access rights, following the atomic switching principle of "release first, acquire later".

[0020] Preferably, the status register polling of the USB interface module is initiated by the main control module immediately after capturing the Bluetooth connection establishment event; if the bus status bit indicates that there is currently active data transmission, the write operation of the current logical cluster is allowed to be fully executed through the protection window until all channels enter the idle state and there is no suspend request, before the atomic switching sequence between the physical layer and the logical layer is triggered.

[0021] The beneficial effects of this invention are as follows: This invention systematically solves the three major contradictions faced by computing-constrained edge devices in multimodal storage scheduling through four core technologies: state-aware delayed switching, lightweight hash indexing, transactional flash writing, and triple-check retransmission architecture. These contradictions are: the contradiction between dynamic switching and data integrity, the contradiction between high-density file storage and memory overhead, and the contradiction between unreliable communication and power-loss security. The technical solution achieves deterministic, secure, and efficient scheduling of shared flash resources without relying on a complex operating system kernel, demonstrating significant technological advancement and industrial applicability. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only for this invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of the overall structure of a multimodal storage resource dynamic scheduling system under computing power-constrained scenarios according to the present invention; Figure 2 This is a schematic diagram of the atomized switching sequence flow when the main control module performs mode switching in this invention; Figure 3 This is a schematic diagram of the lightweight hash mapping mechanism and the reserved sector structure of the mapping table in the file system module of this invention; Figure 4 This is a schematic diagram of the transaction log area layout and power failure recovery process of the present invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments.

[0025] This invention provides a dynamic scheduling system for multimodal storage resources in computing-constrained scenarios. Deployed on an embedded microcontroller platform, the system utilizes an event-driven mechanism to coordinate flash memory access rights between different protocols. Through state-aware atomic switching logic, it solves the resource contention problem on low-computing-power platforms. This not only prevents file system metadata corruption but also ensures the reliability of communication links, guaranteeing a smooth and uninterrupted switching process.

[0026] The main control module runs on a 32-bit microcontroller core and is equipped with a direct memory access (DMA) controller, hardware timers, and an interrupt controller. This microcontroller core is based on the ARM Cortex-M4 architecture, with a clock speed of 80MHz and 128KB of on-chip SRAM, of which 4KB of physical contiguous area is reserved for a USB endpoint buffer. The main control module is responsible for coordinating the operating states of each peripheral module and executing the core scheduling strategy. When a mode switching event is detected, the main control module implements a delayed preemption and atomic switching sequence based on the underlying bus state and memory operation stage to ensure stable system operation under resource-constrained conditions.

[0027] The Bluetooth communication module is built on the Bluetooth Low Energy protocol stack and uses the GATT Indication mechanism to achieve reliable audio stream transmission. This module connects to the main control module via SPI or a dedicated serial interface. Its proprietary frame structure includes a 2-byte magic number field, a 2-byte monotonically increasing sequence number, a variable-length payload, and a 2-byte CRC-16 checksum. The magic number field is fixed at 0x5AA5 and is used to identify valid data frames; the sequence number starts from 0 and increments by 1 after each successfully received frame; the payload carries encoded audio sample data; and the frame tail checksum is generated using the standard CRC-16-CCITT algorithm. Upon receiving the Indication packet, the main control module performs a triple check: first, it verifies if the magic number matches; second, it calculates the CRC-16 of the payload and compares it with the frame tail checksum; and finally, it checks if the sequence number is consecutive and not repeated. If any check fails, the GATTConfirmation signal is refused, forcing the transmitter to automatically retransmit the frame due to timeout. The system sets a maximum consecutive retransmission threshold of 10 times. If a frame with the same sequence number fails verification after more than 10 consecutive retransmissions, the main control module forcibly disconnects the current Bluetooth connection and resets the protocol stack state machine to prevent invalid data from being continuously written to the flash memory and causing physical wear. The uniqueness check is implemented by maintaining a 16-bit sliding window bitmap in RAM. The main control module compares the received sequence number with the currently expected sequence number. If the bitmap identifier corresponding to the sequence number is set to 1, it is determined to be a non-unique duplicate frame, and the Confirmation signal is refused to be sent.

[0028] The USB interface module is configured as a high-capacity storage device, supporting bursty file read / write operations. This module connects to the host module via a dedicated USBPHY. Its controller contains multiple endpoint buffers, with 2KB buffer space allocated for both the IN and OUT directions. The USB controller status register has NakIn, NakOut, and Busy bits, indicating whether the IN channel and OUT channel are in a NAK state, and whether there are active data transmission or control transactions, respectively. After capturing a Bluetooth connection establishment event, the host module immediately starts polling the USB controller status register, sequentially reading the three bits mentioned above to determine if there is active transmission. If any status bit indicates that the bus is busy, a hardware timer is activated, setting the time window to 1500 milliseconds (this value is calculated based on the superimposed redundancy of the typical USB Bulk transmission timeout threshold and the longest erase cycle of the Flash sector), allowing the current logical cluster write operation to complete completely. During this window, the system continuously monitors the USB controller status; once all transmission channels are detected to be idle and there are no suspend requests, an atomic switching operation is performed.

[0029] The atomic switching operation includes the following steps: disabling the USB controller global interrupt, releasing all associated physical layer mutex semaphores and file system-level mutex locks; setting the USBD+ and D- data pins to a high-impedance state to simulate a physical unplug signal, triggering the host operating system to uninstall the device driver; performing a zero-fill operation on the 4KB physical contiguous RAM area originally allocated to the USB endpoint buffer to eliminate interference from residual nondeterministic metadata on the Bluetooth ring buffer start pointer; subsequently initiating a 10-millisecond forced cold protection period, during which all read and write requests to the flash memory are blocked to ensure that the flash controller's internal state machine completes its reset. The 10-millisecond forced cold protection period is set based on the maximum redundancy between the NOR Flash's internal charge pump discharge time and the controller's logic reset cycle; during this period, the main control module pulls down the Flash chip select signal and stops all QSPI clock excitation, forcing the physical layer link into a high-impedance state, thereby inducing the Flash's internal hardware to automatically reset its instruction decoder state machine. This sequence strictly follows the "release first, acquire later" principle to prevent concurrent write conflicts.

[0030] The file system module is deployed on non-volatile flash memory, using a FAT-compatible format to manage storage volumes, and incorporates a lightweight hash mapping mechanism and transaction log protection strategy. The flash memory physical layout is strictly aligned to 4KB sectors, with all mapping tables, transaction log areas, and user data areas allocated in 4KB units as the smallest erase unit. The file system module allocates two independent 4KB sectors in the non-volatile flash memory as reserved sectors for the mapping table, with physical addresses 0x20000 and 0x21000 respectively, strictly aligned to the 4KB boundary to reduce write amplification. When the system is in USB mode and detects file creation, renaming, or deletion events, the main control module performs a CRC32 hash operation on the target file's UTF-8 encoded long filename, generating a 32-bit hash value H. Then, according to the formula... A 16-bit index identifier ID is calculated. This ID, along with the file's starting cluster number, forms a key-value pair and is written to a free slot in the reserved sector of the mapping table. Considering that directly storing the 32-bit CRC hash value would double the RAM overhead, this scheme compresses the hash value to 16 bits through a folded XOR operation. Experiments show that in typical embedded scenarios with fewer than 512 files in a single directory, the collision rate is less than 0.05%, which is sufficient to meet the needs of fast indexing. Each slot contains a 2-byte ID, a 4-byte starting cluster number, and a 1-byte dirty bit flag. The dirty bit flag is initially set to 1, indicating that the entry is newly written or modified; only at the mode switching critical point, i.e., before the transition from USB mode to Bluetooth mode, the main control module traverses the entire mapping table, synchronizes all entries with a dirty bit of 1 to flash memory, and sets the dirty bit to 0. The purpose of using this folded XOR structure is to compress the feature value to a 16-bit width suitable for small RAM indexes while maintaining the CRC32 avalanche effect, thus balancing the collision rate and memory addressing efficiency.

[0031] Upon entering Bluetooth mode, the main control module loads the entire mapping table into a dedicated cache table in RAM. This cache table has a fixed size of 512 bytes and can hold 256 key-value pairs. Subsequent file lookup operations are implemented by directly indexing the ID, eliminating the need to scan directory entries, thus reducing the lookup time complexity from O(n) to O(1) and compressing memory usage to less than 10% of the traditional FATFS scheme. This cache table is locked after the mode switch is completed and will not be updated until the next mode switch to avoid introducing additional memory access overhead during Bluetooth audio stream processing.

[0032] To ensure the atomicity and power-loss safety of flash memory writes, this invention pre-defines a transaction log area and a commit flag area in the flash memory physical layout. The transaction log area is located at offset 0x1000 from the beginning of the volume and consists of 64 16-byte log slots. Each log slot contains a 2-byte target physical address, an 8-byte original data snapshot, a 2-byte checksum, and a 2-byte commit flag. The commit flag is initially set to 0xFFFFFFFF. Before each write operation, the main control module fills the address to be written and the original data into an empty log slot, maintaining the commit flag at 0xFFFFFFFF. The actual flash memory programming operation is then performed. After programming, the main control module calculates the CRC checksum of the written data and compares it with the checksum in the log slot. Only if the checksum matches is the commit flag programmed to 0xA5A5A5A5, ensuring the atomicity of the flag write operation itself within the minimum flash programming cycle. During power-on initialization or mode-switching self-test phases, the system traverses all log slots, identifies incomplete transactions where the commit flag is still 0xFFFFFFFF, and performs rollback operations based on the original data snapshot: if the target address is located in the reserved sector of the mapping table, it recovers from the mirrored sector; if it is located in the ordinary data area, it uses a valid copy in the RAM cache to overwrite the abnormally written content. This mechanism ensures that even if an abnormal power outage occurs during programming, the file system can be restored to a consistent state.

[0033] In one specific embodiment, system initialization first completes the hardware peripheral configuration, including USBPHY enabling, Bluetooth RF calibration, flash controller parameter setting, and DMA channel allocation. Subsequently, the main control module loads the default operating mode as USB mode. In this mode, the USB interface module appears as a standard USB flash drive, supporting file read / write operations by the host computer. When the host computer initiates a write request, the USB controller receives the data and temporarily stores it in the endpoint buffer. The main control module triggers DMA transfer via an interrupt, moving the data to a temporary RAM buffer and calling the file system module to execute the write process. During this process, if the main control module detects a Bluetooth connection establishment event (e.g., via GPIO interrupt or BLE broadcast packet parsing), it immediately initiates the mode switching preparation process.

[0034] In a preferred embodiment of the present invention, the main control module first freezes the file system write queue during the mode switching preparation phase, prohibiting new write requests from entering. It then starts polling the USB controller status register; if the Nakin, NakOut, or Busy bit is detected as 1, a 1500-millisecond timer is started. During this period, the system allows currently ongoing logical cluster write operations to complete, but rejects any new USB transfer requests. Once the timer expires or all channels are detected to be idle, the main control module immediately executes the atomic switching sequence. After the switch is complete, the system enters Bluetooth mode, at which point the Bluetooth communication module begins receiving audio stream data and filters invalid frames using a triple check mechanism. Valid audio frames are decoded and temporarily stored in a dedicated circular buffer, and then scheduled by the main control module to be written to flash memory. The writing process also follows a transaction log mechanism to ensure the persistent security of each frame of data.

[0035] Furthermore, the main control module enforces the access order of flash resources by heterogeneous protocol stacks through a state machine and mutex semaphores. The system defines two mutex semaphores: `flash_access_mutex` and `fs_lock`. `flash_access_mutex` controls exclusive access to the physical layer of flash memory; any mode must acquire this semaphore before performing flash erase or programming operations. `fs_lock` controls access to file system metadata (such as the FAT table, root directory, and mapping tables), preventing concurrent modifications from causing logical inconsistencies. During mode switching, the main control module first releases all held mutex locks, then performs hardware-level isolation operations, and finally re-requests the required resources before the new mode is activated. This mechanism, in conjunction with the aforementioned atomic switching sequence, transaction log, and hash index, constitutes a complete closed-loop scheduling system.

[0036] To verify the technical effectiveness of this invention, the following embodiments and comparative examples were designed for comparative testing. The test platform used an STM32H743VIT6 microcontroller, equipped with 16MB QSPI NOR Flash as non-volatile storage, an nRF52840 Bluetooth module, and the USB PHY integrated within the main control chip. The test scenario was as follows: the host computer wrote a 10MB WAV audio file to the device via the USB interface, and then immediately established a Bluetooth connection and began receiving real-time audio streams. Data integrity, switching latency, and memory usage during mode switching were recorded for both schemes.

[0037] The embodiment employs the multimodal storage resource dynamic scheduling system described in this invention, enabling hash mapping, transaction logs, and atomic switching sequences. The comparative example uses a traditional scheme, which directly shuts down the USB controller and immediately starts the Bluetooth module during mode switching, lacking a delay preemption mechanism, transaction log protection, and relying on standard FATFS directory scanning for file lookup.

[0038] The test results are shown in the table below:

[0039] Data shows that while the implementation introduced a switching latency of approximately 1435 milliseconds (mainly from a 1500 millisecond wait window), it successfully ensured file system consistency and communication reliability. The comparative example, lacking state awareness and atomic switching mechanisms, experienced significant file corruption and audio frame loss in frequent switching scenarios. Furthermore, the implementation reduced RAM usage to 43% of the comparative example through lightweight hash mapping, significantly alleviating memory pressure. The transaction log mechanism enabled the implementation to recover successfully in over 95% of simulated power outage tests, while the comparative example, lacking rollback capabilities, failed to recover in nearly half of its test cases.

[0040] In a specific implementation detail, the write operation of the hash map table strictly follows the transaction log process. When a new file is added in USB mode, the main control module first constructs a new key-value pair (ID, starting cluster number) in RAM and sets the dirty bit to 1. Subsequently, before the entry is written to a free slot in the reserved sector of the map table, the main control module allocates a log slot in the transaction log area to record the target sector address, the original sector content (all FF filled), the checksum, and the initial commit flag 0xFFFFFFFF. After the log writing is completed, the actual sector programming is performed. After successful programming and verification, the commit flag is updated to 0xA5A5A5A5. If a power outage occurs during this process, after the system restarts, a log scan will detect uncommitted transactions, and the original data snapshot (all FF) will be written back to the target sector to ensure that the map table is not polluted by partial writes.

[0041] The writing of Bluetooth audio frames is also protected by a transaction log. Upon receiving a valid audio data frame, the main control module temporarily stores it in a RAM buffer and calculates the target flash memory address. Subsequently, it records the address, the original data (usually all FF), the checksum, and the commit flag in the transaction log area. The commit flag is updated after flash programming is complete. If programming fails or the checksum mismatch occurs, the frame is discarded without updating the commit flag, and subsequent recovery processes will ignore this transaction. This mechanism effectively isolates the impact of unreliable communication links on the storage layer.

[0042] The main control module's scheduling strategy is entirely event-driven, with no background tasks or polling threads. Key events include: USB transfer completion interrupt, Bluetooth Indication receive interrupt, hardware timer timeout interrupt, and GPIO mode switching request interrupt. Each event handling function is designed to be non-blocking, with execution time strictly controlled within 100 microseconds to meet real-time requirements. For example, the Bluetooth Indication receive interrupt service routine only performs frame header verification and sequence number checking; the payload CRC check and write scheduling are handled by the main loop after the interrupt exits, avoiding prolonged occupation of the interrupt context.

[0043] The flash memory controller configuration is also optimized for this invention. Erase operations are performed only in 4KB sectors, prohibiting cross-sector erasure to simplify state management. Programming operations use page write mode, with each page being 256 bytes. The main control module ensures that each write operation does not exceed one page, avoiding the complexity introduced by cross-page programming. Before all write operations, it is checked whether the target page has been erased (all FF). If not, sector erasure is performed first, and then the write operation is performed. This process is also protected by the transaction log.

[0044] In summary, this invention systematically solves three major contradictions faced by computing-constrained edge devices in multimodal storage scheduling through four core technologies: state-aware delayed switching, lightweight hash indexing, transactional flash writing, and triple-check retransmission architecture. These contradictions are: the contradiction between dynamic switching and data integrity, the contradiction between high-density file storage and memory overhead, and the contradiction between unreliable communication and power-loss security. The proposed technical solution achieves deterministic, secure, and efficient scheduling of shared flash resources without relying on a complex operating system kernel, demonstrating significant technological advancement and industrial applicability. Those skilled in the art can fully reproduce the technical effects of this invention by using the above-described implementation methods, combined with conventional embedded development toolchains (such as STM32CubeIDE, KeilMDK, etc.) and standard peripheral driver libraries.

[0045] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A multi-modal storage resource dynamic scheduling system in a limited computing power scenario, characterized in that, The system is implemented through an embedded microcontroller platform, including a main control module, a Bluetooth communication module, a USB interface module and a file system module; the main control module, as the scheduling and arbitration core of the system, runs in a 32-bit microcontroller kernel and is configured with a direct memory access (DMA) controller, a hardware timer and an interrupt controller; the Bluetooth communication module is configured to receive real-time audio streams based on a Bluetooth Low Energy (BLE) protocol stack and encapsulate them into a private frame structure containing a magic number field, a sequence number, a variable length payload and a checksum; the USB interface module is configured as a mass storage class to support burst file reading and writing, and its status register at least contains NakIn, NakOut and Busy bits to indicate the instantaneous busy state of the USB bus; the file system module is deployed in a non-volatile flash memory medium and uses a FAT compatible format to maintain the logical consistency of the storage volume through a pre-set lightweight hash mapping table and a transaction log area; after capturing a modal switching event, the main control module triggers a polling sequence of the USB interface module status register; If it is detected that the bus is in a busy state, the switching request is suspended and the hardware timer is activated to open a logical cluster write protection window; After confirming that the bus is idle or the protection window has timed out, the main control module performs an atomic switching operation, which includes: masking the USB global interrupt, releasing the physical layer mutex semaphore and the file system level mutex lock, setting the USB data pin to a high impedance state to simulate a physical pull-out signal, clearing the USB endpoint buffer RAM area, and starting a forced cold protection period to block flash access.

2. The system of claim 1, wherein, The duration of the forced cold protection period of the atomic switching operation, during which the main control module blocks all read and write scheduling requests for the non-volatile flash memory.

3. The system of claim 1, wherein, The file system module divides two independent sectors in the non-volatile flash memory into strictly 4KB boundary-aligned mapping table reserved sectors; In response to a file change event under the USB mode, the host module performs a CRC32 hash operation on a UTF-8 encoded long file name of a target file to generate a 32-bit value H, and writes the value H into a reserved sector of the mapping table according to a formula A 16-bit index identifier ID is calculated; the host module writes the ID and a file start cluster number into a key-value pair, along with a dirty bit flag initially set to 1, into an empty slot of the reserved sector of the mapping table.

4. The system of claim 3, wherein, At the critical point of switching from the USB mode to the Bluetooth mode, the main control module traverses the mapping table reserved sectors and performs a synchronization operation to write all entries with dirty bit 1 to the flash memory and set the dirty bit to 0; after entering the Bluetooth mode, the main control module loads the entire mapping table into a pre-set 512-byte dedicated cache table in RAM, and subsequent file positioning requests are executed through the ID in the cache table with O(1) complexity direct indexing.

5. The system of claim 1, wherein, The pre-set transaction log area in the non-volatile flash memory consists of 64 16-byte log slots; each log slot contains a 2-byte target physical address, an 8-byte original data snapshot, a 2-byte checksum and a 2-byte commit flag; before performing a flash programming operation, the main control module first fills the to-be-written address and the original data into an idle log slot, and maintains the commit flag as the initial value 0xFFFFFFFF; only after the data is written and the checksum is consistent, the main control module updates the corresponding commit flag to 0xA5A5A5A5 to form a transaction closed loop.

6. The system of claim 5, wherein, The system locates the unfinished transaction with the commit flag bit of 0xFFFFFFFF through traversing the transaction log area during the power-on initialization or modal switching self-checking stage, and performs rollback operation according to the original data snapshot in the log slot; if the abnormal writing point is located in the reserved sector of the mapping table, the data is recovered from the mirror sector; if it is located in the normal data area, the effective copy in the RAM cache is used to cover the abnormal writing content.

7. The system of claim 1, wherein, The Bluetooth communication module adopts a reliable transmission protocol combining GATT Indication mechanism and application layer verification; after receiving the Indication package, the master control module performs three verifications including magic number matching, payload CRC-16 comparison, sequence number continuity and uniqueness check in turn; if any verification link fails, the master control module refuses to send the GATT Confirmation signal to force the sending end to trigger the link layer retransmission.

8. The system of claim 7, wherein, The system sets the maximum continuous retransmission threshold to 10 times; if the frames of the same sequence number are continuously retransmitted more than the threshold, the master control module executes the safety protection logic, forcibly disconnects the Bluetooth connection and resets the protocol stack state machine.

9. The system of claim 1, wherein, The physical layout of the non-volatile flash memory is strictly aligned with 4KB sectors as the minimum erase unit; the master control module controls the access timing of the heterogeneous protocol stack to the flash memory resources through mutual exclusion semaphore and file system lock; any mode must release all the mutual exclusion locks held before applying for flash memory access right, and follows the atomic switching principle of "first release, then get".

10. The system of claim 1, wherein, The state register polling of the USB interface module is started immediately after the master control module captures the Bluetooth connection establishment event; if the bus state bit indicates that there is currently active data transmission, the write operation of the current logical cluster is allowed to be executed completely through the protection window, until all channels enter the idle state and there is no suspension request, and then the atomic switching sequence of the physical layer and the logical layer is triggered.

Images