A multi-modal storage resource dynamic scheduling system in a computing power limited scenario

Abstract

The application 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 to solve the resource conflict, data integrity risk and switching roughness problems caused by the sharing of flash memory for Bluetooth audio receiving and USB mass storage on a resource-restricted embedded platform. An event-driven architecture is adopted, the switching time is judged through the cooperation of USB bus state detection and a timer, a lightweight index table is constructed by using a file name hash mapping mechanism to reduce the RAM occupation and accelerate file searching, a transactional flash memory writing process is introduced to realize power failure consistency recovery in combination with log rollback, GATT Indication is adopted on the Bluetooth side to guarantee the transmission reliability in combination with triple verification, and mutual exclusion signals and physical layer isolation are used to ensure the mutual exclusion access of the dual-mode to the flash memory. The application can realize safe, smooth and low-overhead dual-mode dynamic switching.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of embedded systems and data storage technology, and particularly relates to a multi-modal storage resource dynamic scheduling system in a computing power limited scenario. BACKGROUND

[0002] Limited by the BOM cost and static power consumption constraints of the whole machine, edge nodes often use 32-bit microcontrollers with low computing power and narrowband memory (usually between 64KB and 128KB) as control cores. However, the actual business logic requires these “small” hardware to run two or even multiple heavy and sensitive protocol stacks at the same time: one is the low-power Bluetooth protocol responsible for real-time transmission of audio streams, and the other is the USB mass storage protocol that simulates the device as a PC-end USB flash drive. When the two try to share the same non-volatile flash memory, a series of deep underlying technical bottlenecks will follow.

[0003] In traditional single-task embedded logic, developers usually use static switching or simple application layer instructions to forcibly close one module and open another. However, in the actual “Bluetooth audio + USB storage” dual-mode scenario, this switching logic is very rough and dangerous.

[0004] The most typical technical pain point is that the USB protocol stack is completely dominated by the host computer (such as a PC) in timing, and the Flash operation initiated by the host computer (especially when updating the FAT file system table, cluster chain allocation, and other key metadata writing) is not controlled by the MCU. If the USB is performing a physical sector programming cycle or erase cycle on the Flash, and the system immediately deprives the bus control right and forcibly enters the Bluetooth mode due to capturing a Bluetooth connection event, the state machine inside the Flash will be in an undefined and uncontrollable state. This “dirty write” phenomenon caused by the lack of underlying state awareness not only destroys the current file data being written, but more critically, it can cause logical damage to the File Allocation Table (FAT), making the entire flash volume unable to be recognized by the host computer when mounted next time. Existing mutex mechanisms often cannot avoid the critical region damage caused by interrupt preemption on computing power limited platforms, and the regular kernel scheduler is powerless when dealing with such physical level conflicts.

[0005] Another major bottleneck in the computing power limited scenario is the contradiction between file search efficiency and RAM occupation. The standard FATFS file system is extremely cumbersome when dealing with long file names or searching for a large number of small files: it needs to read directory entries one by one, load the complete string into RAM, and then perform byte-by-byte comparison through the CPU.

[0006] On platforms with less than 64KB of total RAM, this approach is nothing short of a disaster. To ensure that the Bluetooth real-time audio stream does not drop, a large enough ring buffer must be allocated in memory to smooth out the delay fluctuations caused by link jitter. If the file system is occupied by a full directory scan at this time, it will directly squeeze the survival space of the audio buffer, causing system task scheduling to jitter, ultimately leading to audio synchronization loss, which is manifested as obvious physical frame loss or nonlinear distortion on the acoustic output end. The deeper problem is that frequent mode switching means that the system needs to repeatedly scan the directory tree, and this O(n) complexity linear search not only slows down the system response speed, but also wastes valuable CPU power. On MCUs without complex memory management units, how to achieve O(1) level fast positioning with minimal RAM overhead is a difficult problem that the industry urgently needs to solve.

[0007] In addition to internal resource competition, the uncertainty of the external environment also brings double blows to the system. First, the reliability of Bluetooth communication. In complex electromagnetic environments such as industrial sites or edge deployment scenarios, the standard Bluetooth Notify mechanism lacks strict application layer verification and retransmission strategies, making it prone to packet loss or bad packets. If the system blindly submits these damaged, error-containing audio data frames directly to the Flash write process, it will cause permanent pollution of the storage content.

[0008] The more severe test comes from power safety. Embedded Flash (especially NOR / NAND Flash) does not support hardware-level transaction operations. Once the device encounters power fluctuations or abnormal power failure during mode switching or critical moments of Flash programming, the system will lose the data that has been partially written due to the lack of effective log rollback or snapshot recovery mechanism, and even cause the mapping table pointer to be disordered. In battery-powered or outdoor mobile devices, since such data consistency completely depends on power stability, the system robustness is extremely fragile.

[0009] Current attempts to solve the problem often have to give up something: schemes that pursue safety often sacrifice real-time performance by using a full blocking operation mode, resulting in a poor user experience; while schemes that pursue speed usually ignore the atomic operation requirements of the Flash bottom layer, resulting in logical damage to the file system after the device has been running for a period of time. This multiple game between "dynamic switching and data integrity", "storage density and memory occupation", "unreliable link and power consistency" has become a core problem that restricts the evolution of multi-modal edge nodes towards high reliability.

[0010] Therefore, it is urgent to build a new scheduling system. The system should be event-driven as the top-level architecture, have a keen perception of the state of the underlying hardware bus, and be able to ensure the physical security and logical completeness of the heterogeneous protocol stack when sharing the Flash without relying on high-performance kernels through collaborative optimization of memory allocation, introduction of transactional write logic, and lightweight hash mapping mechanism. This is not only the key to improving the stability of edge devices, but also the only way to solve the contradiction of multi-task concurrency in resource-constrained scenarios. SUMMARY

[0011] To achieve the above invention purpose, the application provides a multi-modal storage resource dynamic scheduling system in a computing power limited scenario, which is realized through 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, 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 low-power Bluetooth 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 contains at least 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 medium and uses a FAT compatible format to maintain the logical consistency of the storage volume through a pre-configured lightweight hash mapping table and transaction log area. After capturing the modal switching event, the main control module triggers a polling sequence of the USB interface module status register. If it detects that the bus is busy, it suspends the switching request and activates the hardware timer 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: 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.

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

[0013] Preferably, the file system module reserves two physical addresses in the non-volatile flash memory as mapping table reserved sectors, which are strictly aligned to 4KB boundaries; in response to a file change event in USB mode, the host module performs a CRC32 hash operation on the UTF-8 encoded long file name 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 host module writes the ID and the file start cluster number into the mapping table reserved sector as a key-value pair, along with a dirty bit flag initially set to 1.

[0014] Preferably, at the critical point of switching from USB mode to Bluetooth mode, the host module traverses the mapping table reserved sector and performs a synchronization operation, writing all entries with dirty bit 1 to the flash memory and setting the dirty bit to 0; after entering Bluetooth mode, the host module loads the entire mapping table into a pre-set 512-byte dedicated cache table in RAM, and subsequent file positioning requests are performed through direct indexing in the cache table with O(1) complexity.

[0015] Preferably, a pre-set transaction log area in the non-volatile flash memory is composed 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 host module first fills the to-be-written address and original data into an idle log slot, and maintains the commit flag at the initial value 0xFFFFFFFF; only after the data is written and the checksum is consistent, the host module updates the corresponding commit flag to 0xA5A5A5A5 to form a transaction loop.

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

[0017] Preferably, the Bluetooth communication module uses a reliable transmission protocol combining GATT Indication mechanism and application layer verification; after receiving an Indication packet, the host module performs three verifications in sequence, including magic number matching, payload CRC-16 comparison, and sequence number continuity and uniqueness check; if any verification step fails, the host module refuses to send a GATT Confirmation signal to force the sending end to trigger link layer retransmission.

[0018] Preferably, the system sets the maximum continuous retransmission threshold to 10 times, and if the frames of the same sequence number are continuously retransmitted beyond the threshold, the master module executes the safety 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 minimum erase unit; the master module controls the access timing of the heterogeneous protocol stack to the flash memory resource through mutual exclusion semaphores and file system locks, and any mode must release all the mutual exclusion locks held before applying for flash memory access, and follows the atomic switching principle of'release first and get later'.

[0020] Preferably, the state register polling of the USB interface module is started immediately after the master module captures the Bluetooth connection establishment event; if the bus state bit indicates that there is currently an 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.

[0021] The beneficial effects of the present application: The present application solves the three contradictions faced by the limited computing power edge device in multi-modal storage scheduling through four core technologies of state-aware delay switching, lightweight hash index, transactional flash write and triple verification retransmission architecture: 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 failure safety. The technical solution realizes the deterministic, safe and efficient scheduling of shared flash memory resources without relying on complex operating system kernels, and has significant technical progress and industrial applicability. BRIEF DESCRIPTION OF DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the present application or prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description only illustrate the present application, and for those skilled in the art, other drawings can also be obtained without creative labor.

[0023] Figure 1 It is a whole structure schematic diagram of the multi-modal storage resource dynamic scheduling system in the limited computing power scene of the present application.

[0024] Figure 2 It is an atomic switching sequence flowchart when the master module in the present application executes mode switching.

[0025] Figure 3 It is a lightweight hash mapping mechanism and mapping table reserved sector structure schematic diagram in the file system module of the present application.

[0026] Figure 4 Fig. 1 is a schematic diagram of the transaction log area layout and power failure recovery process of the present application. DETAILED DESCRIPTION

[0027] In order to make the objectives, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to specific embodiments.

[0028] The present application provides a multi-modal storage resource dynamic scheduling system in a limited computing power scenario, which is deployed on an embedded microcontroller platform. The system uses an event-driven mechanism to coordinate flash memory access rights between different protocols, and solves the resource competition problem under a low computing power platform through atomic switching logic with state awareness. This not only prevents file system metadata damage, but also takes into account the reliability of the communication link, ensuring a smooth switching process without freezing.

[0029] The main control module runs in a 32-bit microcontroller kernel, which is configured with a direct memory access (DMA) controller, a hardware timer and an interrupt controller. The microcontroller kernel is of ARM Cortex-M4 architecture, with a main frequency set at 80MHz and an on-chip SRAM capacity of 128KB, of which 4KB of physically contiguous area is reserved for USB endpoint buffer. The main control module is responsible for coordinating the running state of each peripheral module and executing the core scheduling strategy. When a modal switching event is detected, the main control module implements a delay deprivation and atomic switching sequence according to the underlying bus state and storage operation phase, to ensure stable operation of the system under resource-limited conditions.

[0030] The Bluetooth communication module is built based on the low-power Bluetooth protocol stack, and uses the GATT Indication mechanism to realize reliable audio stream transmission. The module is connected with the host module through SPI or a dedicated serial interface, and its private 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 as 0x5AA5 and is used to identify a valid data frame; the sequence number starts from 0 and is incremented by 1 after each successful reception of a frame; the payload part carries the encoded audio sample data; and the frame tail checksum is generated using the standard CRC-16-CCITT algorithm. After receiving the Indication packet, the host module performs three verifications in turn: first, it verifies whether 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 whether the sequence number is continuous and not repeated. If any verification fails, the GATT Confirmation signal is refused to be sent, forcing the sending end to automatically retransmit the frame due to timeout. The system sets the maximum continuous retransmission threshold to 10 times, and if the same sequence number frame is continuously retransmitted more than 10 times and still fails to pass the verification, the host module forcibly disconnects the current Bluetooth connection and resets the protocol stack state machine, preventing invalid data from being continuously written into the flash memory and causing physical wear and tear. The uniqueness check is realized by maintaining a 16-bit sliding window bitmap in RAM; the host module compares the received sequence number with the current expected sequence number, and if the bitmap corresponding to the sequence number is already set to 1, it is determined that the frame is not unique and repeated, and the Confirmation signal is refused to be sent.

[0031] The USB interface module is configured as a mass storage device class and supports burst file read and write operations. The module is connected with the host module through a dedicated USB PHY, and its controller internally includes multiple endpoint buffers, of which 2KB buffer spaces are allocated for IN and OUT directions respectively. The NakIn bit, NakOut bit and Busy bit are set in the USB controller status register, which respectively indicate whether the IN channel is in NAK state, whether the OUT channel is in NAK state, and whether there is an active data transmission or control transaction. After capturing the Bluetooth connection establishment event, the host module immediately starts polling operation on the USB controller status register, and reads the above three bits in turn to determine whether there is an active transmission. If any state bit indicates that the bus is busy, a hardware timer is activated, and the time window is set to 1500 milliseconds (this value is calculated based on the superposition redundancy of the typical USB Bulk transmission timeout threshold and the longest erase period of the flash sector), allowing the current logical cluster write operation to be completed completely. During this window period, the system continuously monitors the USB controller status, and once it detects that all transmission channels are idle and there is no pending request, it performs an atomic switching operation.

[0032] The atomization switching operation includes the following steps: closing the USB controller global interrupt, releasing all associated physical layer mutual exclusion semaphores and file system level mutual exclusion locks; setting the USBD+ and D- data pins to high impedance state, simulating a physical pull-out signal, triggering the host operating system to unload the device driver; performing a full zero padding operation on the 4KB physically continuous RAM region originally allocated to the USB endpoint buffer, performing full zero padding to eliminate the interference of residual non-deterministic metadata on the starting pointer of the Bluetooth ring buffer; then starting a 10 millisecond forced cold protection period, during which all read and write requests to the flash memory are blocked, ensuring that the flash memory controller internal state machine completes the reset. Setting the 10 millisecond forced cold protection period is based on the maximum redundancy value of the NOR flash internal charge pump discharge time and the controller logic reset period; during this period, the master module pulls down the flash chip select signal and stops all QSPI clock excitation, forcing the physical layer link to enter the high impedance state, thereby inducing the flash internal hardware to automatically reset its instruction decoder state machine. The sequence strictly follows the "release first, get later" principle, eliminating concurrent write conflicts.

[0033] The file system module is deployed in the non-volatile flash memory medium, uses the FAT compatible format to manage the storage volume, and introduces a lightweight hash mapping mechanism and a transaction log protection strategy. The flash memory physical layout is strictly aligned to 4KB sectors, and all mapping tables, transaction log areas and user data areas are allocated with 4KB as the minimum erase unit. The file system module divides two independent 4KB sectors as mapping table reserved sectors in the non-volatile flash memory, whose physical addresses are 0x20000 and 0x21000 respectively, strictly aligned to the 4KB boundary to reduce the write amplification effect. When the system is in USB mode and detects file creation, renaming or deletion events, the master module performs CRC32 hash operation on the UTF-8 encoded long file name of the target file, generating a 32-bit hash value H. Then according to the formula A 16-bit index identifier ID is calculated. The ID and the file start cluster number form a key-value pair, which is written to the free slot of the mapping table reserved sector. Considering that storing a 32-bit CRC hash value directly will double the RAM overhead, this scheme compresses the hash value to 16 bits through folding XOR operation. Experiments show that in typical embedded scenarios where the number of single directory files is less than 512, the collision rate is less than 0.05%, which is sufficient to meet the demand of fast indexing. Each slot contains a 2-byte ID, a 4-byte start 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 modal switching critical point, i.e. before switching from USB mode to Bluetooth mode, the main control module traverses the entire mapping table, synchronizes all entries with dirty bit 1 to the flash memory, and sets the dirty bit to 0. The purpose of using such a folding XOR structure is to compress the characteristic value to 16 bits suitable for small RAM index while maintaining the CRC32 avalanche effect, to balance the conflict rate and memory addressing efficiency.

[0034] After entering the Bluetooth mode, the main control module loads the entire mapping table into a dedicated cache table in RAM. The cache table size is fixed at 512 bytes, which can accommodate 256 key-value pairs. Subsequent file lookup operations are implemented through direct indexing ID, without the need to scan directory items, thereby reducing the lookup time complexity from O(n) to O(1), and compressing the memory occupancy to less than 10% of the traditional FATFS scheme. The cache table is locked after the modal switching is completed and is not updated until the next modal switching, to avoid introducing additional memory access overhead during Bluetooth audio stream processing.

[0035] To ensure the atomicity of flash writing and the safety of power failure, the application pre-sets a transaction log area and a commit flag area in the physical layout of the flash memory. The transaction log area is located at the offset 0x1000 of the volume start and is composed of 64 16-byte log slots, each of which contains a 2-byte target physical address, an 8-byte original data snapshot, a 2-byte checksum, and a 2-byte commit flag. The initial value of the commit flag is 0xFFFFFFFF. Before each writing operation, the host module fills the to-be-written address and the original data into the idle log slot and keeps the commit flag as 0xFFFFFFFF. Then the actual flash programming operation is performed. After the programming is completed, the host module calculates the CRC checksum of the written data and compares it with the checksum in the log slot. Only when the checksums are consistent, the commit flag is programmed as 0xA5A5A5A5 to ensure the atomicity of the flag writing operation itself within the minimum programming period of the flash memory. During the power-on initialization or the modal switching self-checking stage, the system traverses all the log slots, identifies the unfinished transactions whose commit flags are still 0xFFFFFFFF, and performs a rollback operation according to the original data snapshot: if the target address is located in the reserved sector of the mapping table, the mirror sector is restored; if it is located in the normal data area, the valid copy in the RAM buffer is used to overwrite the abnormal writing content. This mechanism ensures that even if an abnormal power failure occurs during programming, the file system can be restored to a consistent state.

[0036] In a specific embodiment, the system initialization first completes the hardware peripheral configuration, including USB PHY enablement, Bluetooth radio frequency calibration, flash memory controller parameter setting, and DMA channel allocation. Then the host module loads the default running mode as the USB mode, at which time the USB interface module presents as a standard U disk device to the outside, supporting the host computer to perform file read / write operations. When the host computer initiates a writing request, the USB controller receives the data and temporarily stores it in the endpoint buffer, the host module moves the data to the temporary RAM buffer through the DMA transmission triggered by the interrupt, and calls the file system module to execute the writing process. In this process, if the host module detects a Bluetooth connection establishment event (for example, through the GPIO interrupt or BLE broadcast packet analysis), the modal switching preparation process is immediately started.

[0037] As a preferred embodiment of the present application, the host module first freezes the file system write queue and prohibits new write requests from entering during the modal switching preparation phase. Then it starts polling the USB controller status register, and if it detects that the NakIn, NakOut or Busy bits are 1, it starts a 1500 ms timer. During this period, the system allows the current ongoing logical cluster write operation to complete, but rejects any new USB transmission request. Once the timer expires or all channels are detected to be idle, the host module immediately executes the atomic switching sequence. After the switching is completed, the system enters the Bluetooth modal, at which time the Bluetooth communication module starts receiving audio stream data and filtering invalid frames through a triple-checking mechanism. Valid audio frames are temporarily stored in a dedicated ring buffer and then written to the flash memory by the host module. The writing process also follows the transaction log mechanism to ensure the safety of each frame of data.

[0038] Further, the host module strictly defines the access order of the heterogeneous protocol stack to the flash memory resources through the state machine and mutual exclusion semaphores. The system defines two mutual exclusion semaphores: flash_access_mutex and fs_lock. The flash_access_mutex controls exclusive access to the flash memory physical layer, and any modal must acquire this semaphore before performing flash erase or programming operations; the fs_lock controls access to file system metadata (such as FAT table, root directory, mapping table), preventing concurrent modifications from causing logical inconsistencies. During modal switching, the host module first releases all held mutual exclusion locks, then performs isolation operations at the hardware level, and finally re-applies the required resources before activating the new modal. This mechanism works in conjunction with the aforementioned atomic switching sequence, transaction log, and hash index to form a complete closed-loop scheduling system.

[0039] To verify the technical effects of the present application, the following examples and comparative examples are designed for comparative testing. The test platform uses an STM32H743VIT6 microcontroller, equipped with a 16 MB QSPINOR flash as a non-volatile storage medium, a Bluetooth module nRF52840, and a USB PHY integrated inside the host chip. The test scenario is as follows: the host computer writes a 10 MB WAV audio file to the device through the USB interface, and then immediately establishes a Bluetooth connection and starts receiving real-time audio streams. The data integrity, switching delay, and memory usage during modal switching are recorded for both schemes.

[0040] The example uses the multi-modal storage resource dynamic scheduling system described in the present application, enabling hash mapping, transaction logging, and atomic switching sequences. The comparative example uses the traditional scheme, i.e., directly turning off the USB controller and immediately starting the Bluetooth module during modal switching, without a delay deprivation mechanism, without transaction log protection, and relying on standard FATFS directory scanning for file searching.

[0041] The test results are shown in the following table:

[0042]

[0043] The data show that the embodiment introduces a switching delay of about 1435 milliseconds (mainly from a 1500 millisecond waiting window), but successfully guarantees the consistency of the file system and the reliability of communication. The comparative example lacks state awareness and atomic switching mechanism, and in the frequent switching scene, a large number of file damage and audio frame loss occur. At the same time, the embodiment reduces the RAM occupancy to 43% of the comparative example through the lightweight hash mapping, significantly relieving the memory pressure. The transaction log mechanism makes the embodiment more than 95% successful in recovery in the simulated power failure test, while the comparative example cannot recover nearly half of the test cases due to the lack of rollback capability.

[0044] In one specific implementation detail, the write operation of the hash mapping table strictly follows the transaction log process. When a new file is added under the USB mode, the host module first constructs a new key-value pair (ID, starting cluster number) in RAM, and the dirty position 1. Then, before the entry is written to the free slot of the mapping table reserved sector, the host module allocates a log slot in the transaction log area, records the target sector address, the original sector content (filled with FF), the checksum, and the initial commit flag 0xFFFFFFFF. After completing the log writing, the actual sector programming is performed. After successful programming and verification, the commit flag is updated to 0xA5A5A5A5. If power failure occurs during this process, the system restarts and finds uncommitted transactions through log scanning, writes the original data snapshot (all FF) back to the target sector, and ensures that the mapping table is not contaminated by partial writing.

[0045] The writing of Bluetooth audio frames is also protected by the transaction log. After receiving a frame of valid audio data, the host module temporarily stores it in the RAM buffer and calculates the target flash address. Then, the address, the original data (usually all FF), the checksum, and the commit flag are recorded in the transaction log area. After completing the flash programming, the commit flag is updated. If the programming fails or the verification does not match, the frame is discarded and the commit flag is not updated, and the subsequent recovery process will ignore this transaction. This mechanism effectively isolates the impact of unreliable communication links on the storage layer.

[0046] The scheduling strategy of the master module is completely driven by events, without background tasks or polling threads. Key events include: USB transmission completion interrupt, Bluetooth indication reception interrupt, hardware timer timeout interrupt, and GPIO mode switching request interrupt. Each event processing 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 reception interrupt service program only performs frame header verification and sequence number checking, and the CRC verification and write scheduling of the payload are handled by the main loop after the interrupt exits, avoiding long-term occupation of the interrupt context.

[0047] The configuration of the flash controller is also optimized for the present application. Erase operations are only performed in 4KB sectors, and cross-sector erasing is prohibited to simplify state management. Programming operations use page write mode, with each page being 256 bytes, and the master module ensures that no more than one page is written at a time, avoiding the complexity introduced by cross-page programming. Before all write operations, it is checked whether the target page has been erased (all FF), and if not, sector erasing is performed before writing, and this process is also included in the transaction log protection.

[0048] In summary, the present application systematically solves the three major contradictions faced by power-limited edge devices in multi-modal storage scheduling through four core technologies: state-aware delay switching, lightweight hash indexing, transactional flash writing, and triple-check retransmission architecture. These technologies achieve deterministic, safe, and efficient scheduling of shared flash resources without relying on complex operating system kernels, making significant technical progress and industrial practicality. Based on the above embodiments, combined with conventional embedded development tool chains (such as STM32CubeIDE, KeilMDK, etc.) and standard peripheral driver libraries, the technical effects of the present application can be fully reproduced.

[0049] The above-described embodiments are only used to illustrate the technical solutions of the present application, and not to limit them. Although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can modify the technical solutions described in the foregoing embodiments, or make equivalent replacements to some technical features; and these modifications or replacements 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 the present application, and should be included in the protection scope of the present application.

Claims

1. A dynamic scheduling system for multimodal storage resources in computing-constrained scenarios, characterized in that, The system is implemented using 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, 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 employs a reliable transmission protocol combining the GATT Indication mechanism with application-layer verification. Upon receiving an Indication packet, the main control module sequentially performs triple verification, 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 packet. The Confirmation signal forces the sender to trigger a link layer retransmission; the Bluetooth communication module is configured to receive real-time audio streams based on the Bluetooth Low Energy protocol stack and encapsulate them into a private frame structure containing a magic number segment, serial number, variable-length payload, and checksum; the USB interface module is configured as a large-capacity storage device to support bursty file read / write operations, and its status register contains at least NakIn, NakOut, and Busy bits to indicate the instantaneous busy / idle state of the USB bus; the file system module is deployed on non-volatile flash memory and uses a FAT-compatible format, maintaining logical consistency of the storage volume with the transaction log area through a preset lightweight hash mapping table; the lightweight hash mapping table is implemented as follows: 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 hash value H; then, according to the formula... A 16-bit index identifier ID is calculated; the ID and the file's starting cluster number form a key-value pair, which is written into a free slot in the reserved sector of the mapping table; the main control module traverses the entire mapping table and synchronizes all entries with dirty bits set to 1 to the flash memory; after entering Bluetooth mode, the main control module loads the mapping table entries into the RAM cache, and subsequent file search operations are implemented through direct index ID; after capturing the mode switching event, the main control module triggers a polling sequence of the USB interface module's status register; If the bus is detected to be busy, the switching request is suspended and a hardware timer is activated to enable 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.

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

3. The system according to claim 1, characterized in that, 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 a file change event 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 then follows the formula... The 16-bit index identifier ID is calculated; the main control module constructs a key-value pair with the ID and the file's starting cluster number, and writes it, along with the dirty bit flag initially set to 1, into the free slot of the reserved sector in the mapping table.

4. The system according to claim 3, characterized in that, At the critical point of switching from USB mode to Bluetooth mode, the main control module traverses the reserved sectors 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 512-byte dedicated cache table preset in RAM, and subsequent file location requests perform O(1) complexity direct indexing in the cache table through the ID.

5. The system according to claim 1, characterized in that, The non-volatile flash memory has a preset transaction log area, which 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 flash programming operations, the main control module first fills the address to be written and the original data into an empty log slot and keeps the commit flag at its initial value of 0xFFFFFFFF. Only after the data is written and the verification is consistent will the main control module update the corresponding commit flag to 0xA5A5A5A5 to form a transaction loop.

6. The system according to claim 5, characterized in that, 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 rollback operations 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.

7. The system according to claim 6, characterized in that, The system sets the maximum consecutive retransmission threshold to 10 times. If the number of consecutive retransmissions 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.

8. The system according to claim 1, characterized in that, 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 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".

9. The system according to claim 1, characterized in that, The status register polling of the USB interface module is initiated immediately by the main control module after capturing the Bluetooth connection establishment event. If the bus status bit indicates that there is 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.

Images