Data caching method and system for IoT devices in mineral exploration

Abstract

This invention discloses a data caching method for IoT devices used in mineral exploration. This method is executed in a single thread. When a user needs to store data, the data is first cached through a first cache queue module in the microcontroller's memory. This module separates the element address from the data cache and dynamically utilizes the microcontroller's memory space to cache data based on the size of the data to be stored. When the external flash memory is idle, data is popped from the first cache queue module one by one and pushed into a second cache queue module of the external flash memory for persistent caching. When the user needs to retrieve and upload the cached data from the external flash memory, data is popped from the second cache queue module of the external flash memory one by one, and the space in the external flash memory is released simultaneously. This invention can implement a single-threaded, two-layer cache on a limited hardware basis, capable of handling sudden large data volumes without data loss, and maximizing energy savings.

Description

Technical Field

[0001] This invention relates to the field of mineral exploration equipment, and more particularly to a data caching method and system for Internet of Things (IoT) devices used in mineral exploration. Background Technology

[0002] During the preliminary, general, and detailed survey stages of mineral exploration, prospective areas are typically located in harsh field environments. Therefore, exploration personnel usually use portable, small equipment for field data collection. This equipment typically includes geophysical equipment (such as electrical resistivity tomography and magnetics), infrared spectroscopy equipment (shortwave infrared, Fourier transform infrared, etc.), and, in recent years, portable gas geochemical exploration equipment. These devices typically use digital electronic systems to collect and record data in the field, storing the data on the device's built-in hard drive or flash memory. After the fieldwork is completed and the team returns indoors, the data is transferred to a computer for processing.

[0003] For embedded devices used in the field, the microcontrollers are typically low-power chips with lower performance (their power consumption is usually only tens of milliwatts, which is about a hundred times less than that of solid-state drives). They usually have only one core and lack a memory management unit (MMU). Therefore, it is impossible to implement complex random access storage like that of solid-state drives on this hardware. Limited by the computing power of these devices, they usually cannot have a built-in general-purpose file system (such as FAT), so these devices typically use proprietary, simple data storage and transmission protocols.

[0004] This built-in storage method has three main problems: (1) Poor data security. The field environment is harsh, and if the equipment is damaged before the data is transmitted to the computer, the data will be permanently lost. (2) Low data transmission and processing efficiency. Exploration is usually a team effort, and the data collected in the field must be analyzed by experts working indoors before it becomes meaningful. However, the data from the current equipment can only be handed over to experts for analysis after the field personnel retrieve the data from the equipment at the end of each day's work, and indoor experts cannot obtain first-hand data immediately. (3) Poor compatibility. These devices usually use dedicated data cables to transmit data, and special application software usually needs to be installed on the computer. Although data transmission difficulties caused by physical damage to the data cable or incompatibility of application software due to operating system upgrades are not common, they can greatly affect the work progress and may even jeopardize the entire project's execution schedule.

[0005] In fact, the above-mentioned problems have existed in electronic devices across various industries, but the emergence of IoT technology has largely solved these problems. Relying on the internet as infrastructure, various devices within the IoT use a unified data transmission protocol to interact with each other. These devices can be wired or wirelessly connected. They offer advantages such as intelligent interconnection, big data processing, real-time monitoring and feedback, and flexible scalability.

[0006] The prerequisite for applying the Internet of Things is access to the international Internet. However, since mineral exploration work is usually carried out in the field where network infrastructure is relatively weak, it is impossible to guarantee that the equipment is always connected to the Internet. This means that mineral exploration equipment must be able to cache data when there is no network connection and send the cached data out when there is network access.

[0007] For desktop computers, mobile phones and other devices, due to their strong computing power, high degree of hardware abstraction, and strong multitasking capabilities, it is not difficult to implement caching on the file system without affecting other services. However, for IoT devices, their processors are usually microcontrollers with very low computing power and do not run operating systems. The degree of abstraction of the underlying hardware is low. It is not easy to implement reliable data caching without significantly changing the hardware architecture. The main difficulties are as follows: (1) Wear leveling needs to be done on the microcontroller. Flash memory blocks have a limited number of erase / write cycles (usually around 100,000). Therefore, if hard offsets are used for data address indexing, a small number of blocks will quickly run out of life and become unreadable. For solid-state drives, USB flash drives and other devices, there are usually dedicated hardware and software to implement wear leveling technology. Mineral exploration equipment is usually not equipped with such dedicated hardware, so wear leveling must be implemented entirely by the microcontroller software. (2) The waiting time for flash erasure is usually long. For example, the sector erasure time of W25Q128 EEPROM is usually 100 to 400 milliseconds. Solid-state drives (SSDs), USB flash drives, and similar devices typically use caching to reduce processor latency. However, flash memory used in mineral exploration equipment usually lacks caching, so this latency process must be handled at the software level. If the microcontroller's software doesn't perform other tasks while waiting, it can easily cause device lag and extend data acquisition intervals, negatively impacting exploration results.

[0008] The root cause of the above two problems lies in the fact that microcontrollers have very limited computing power and memory, making it very difficult to implement a general-purpose caching system. On the other hand, mineral exploration equipment typically has the characteristics of a large number of data entries but small individual data entries, and each data entry is independent of the others. Therefore, it is necessary to design a specialized caching system to achieve effective data caching.

[0009] To implement caching, a relatively easy approach is to use a single Flash buffer. Other approaches include using an operating system and multithreading on the microcontroller, but these present many potential problems: (1) increased firmware size and memory overhead; (2) communication between threads is prone to software defects due to thread conflicts; and (3) difficulty in debugging multithreading.

[0010] To implement a queue in memory, an easy approach is to use a method similar to vector or list in C++ STL. These data containers inevitably require dynamic memory allocation, which involves the use of the heap. However, since microcontrollers typically do not have dedicated MMU hardware, heap allocation and deallocation usually rely on functions such as brk and sbrk, meaning that allocation and deallocation must be done directly in physical memory via software. This presents several problems: (1) Low efficiency, because brk and sbrk functions usually linearly search for the next available block in memory, and efficiency inevitably decreases as the number of queue elements increases; (2) Memory fragmentation, resulting in insufficient free memory space that cannot be used because it is not contiguous; (3) Reduced program stability, because heap allocation is unpredictable at compile time and changes as the program runs, easily leading to insufficient memory. Generally speaking, using a heap on a microcontroller without an MMU is a poor design. If a heap is not used, an easy approach is to allocate a fixed array as a global variable, where the length of each element is the maximum possible data length. This inevitably leads to memory waste. This invention addresses a scenario where long data is less frequent, while short data is more common. For example, the longest data a program might encounter is 128 bytes. To cache 16 elements, at least 128 * 16 = 2KB of space would be needed. However, filling all 2KB is impossible because 128-byte data is infrequent. Ideally, data length and cache levels should be dynamically balanced. For instance, allocating 256 bytes of space allows for storing two 128-byte elements and 16 16-byte elements, maximizing the efficient use of cache space. This invention aims to solve this problem of efficient cache space utilization. Summary of the Invention

[0011] The main objective of this invention is to design and implement a system that allows mineral exploration equipment based on microcontroller technology to cache data in the flash memory of the microcontroller in a network-free environment and retrieve the data from the cache and send it to the network in a network-connected environment, taking into account the hardware characteristics of such equipment.

[0012] The technical solution adopted in this invention is:

[0013] A data caching method for IoT devices in mineral exploration is provided, which is executed in a single thread in the microcontroller of the IoT device in mineral exploration.

[0014] When a user needs to store data, the data is first cached through the first cache queue module in the microcontroller's memory. This first cache queue module specifically separates the element address and the data cache, and dynamically utilizes the microcontroller's memory space to cache the data according to the size of the data to be stored.

[0015] When the external flash memory is idle, according to the head offset position of the external flash memory stored in the auxiliary recording module in the microcontroller memory, the data in the first cache queue module is popped out one by one and pushed into the second cache queue module of the external flash memory for persistent data caching.

[0016] When a user needs to retrieve and upload data cached in the external flash memory, the data in the second cache queue module of the external flash memory is popped out one by one according to the head offset position of the external flash memory stored in the auxiliary recording module, and the space in the external flash memory is released at the same time.

[0017] According to the above technical solution, the first cache queue module includes a data push interface and a data pop interface. The data push interface is used to dynamically store non-uniform length data into the first cache queue module; the data pop interface is used to delete the stored data from the head of the first cache queue module and store the deleted data in a specified buffer.

[0018] Following the above technical solution, the first buffer queue module implements a FIFO data structure based on microcontroller memory and includes four sub-variables: the first sub-variable is an integer head, used to record the head level index; the second sub-variable is an integer back, used to record the tail level index; the third sub-variable is an integer array buffer, used to store the circular buffer of data at each level; and the fourth sub-variable is an integer array levels, used to index the starting offset of each level of the FIFO data structure on the integer array buffer.

[0019] According to the above technical solution, the auxiliary recording module includes a write interface, a read interface, an erase interface, an activation interface, an activation status check interface, and a recovery interface, wherein the write interface writes the head offset and tail offset positions of the external flash memory.

[0020] Following the above technical solution, the auxiliary recording module includes two page modules. The page module is an abstraction of the page of the microcontroller's flash memory. The page module contains four sub-variables: the first sub-variable is an integer addrSignature, which is used to store the page status information address of the microcontroller's flash memory; the second sub-variable is an integer addrBegin, which is used to store the starting address of the space of the microcontroller's flash memory; the third sub-variable is an integer addrEnd, which is used to store the ending address of the space of the microcontroller's flash memory; and the fourth sub-variable is an integer addrNext, which is used to store the address of the next write to the microcontroller's flash memory.

[0021] Following the above technical solution, this method specifically implements the reading, writing, and erasing of external flash memory through an external flash memory driver module set in the microcontroller.

[0022] Following the above technical solution, data of any length less than S is pushed into the first cache queue module, where S is the maximum data capacity of the FIFO. The pushed data is named "element" and has a length of "size". The specific execution process of the push interface is as follows:

[0023] Calculate the remaining space. If there is not enough remaining space, return an error or force pop a header element to free up space, depending on the situation.

[0024] If there is enough remaining space, calculate the tail level index and the tail offset after the push.

[0025] If the sum of the current tail offset and the length of the pushed data is less than or equal to S, then the data element is directly written to the circular buffer; otherwise, it indicates that the circular buffer has looped, and the data element needs to be written in segments.

[0026] Following the above technical solution, the specific execution process of the pop-up interface is as follows:

[0027] Check if the data in the first buffer queue module is empty. If it is not empty, calculate the next head position after the data is popped and update it.

[0028] Calculate the start and end offset positions of the current header data in the circular buffer. If the end offset position is greater than the start offset position, copy the header data directly to the specified position; otherwise, it indicates that the circular buffer has looped, so copy the header data in segments to the specified positions.

[0029] The present invention also provides a data caching system for IoT devices in mineral exploration, including a microcontroller and an external flash memory, which caches data through the method described above.

[0030] The present invention also provides a computer storage medium storing a computer program executable by a processor, the computer program executing the data caching method for IoT devices for mineral exploration described in the above technical solution.

[0031] The beneficial effects of this invention are as follows: This invention addresses the issue of low-power chips with limited performance in embedded devices used in the field. Based on this limited hardware, this invention implements a dedicated dual-layer buffered data structure, solving the data transfer problem between the memory cache and the external Flash cache using only a single thread, without causing program blocking. Specifically, by setting a cache queue module in the microcontroller's memory (i.e., volatile memory) of the mineral exploration IoT device, the element address (pointer) and data cache are separated, realizing a queue data structure (i.e., the first cache queue module) with dynamically adjustable element size. On the external flash memory (i.e., non-volatile memory), combined with the auxiliary recording module of the microcontroller's built-in flash memory, a similar queue data structure (i.e., the second cache queue module) is implemented in the external flash memory (non-volatile memory). Furthermore, data exchange between the two cache queues can be operated through a single thread, sufficient to handle sudden data writes. Therefore, this invention uses a memory queue and a Flash queue to implement a single-threaded dual-layer cache, capable of handling sudden large data volumes without data loss, while maximizing energy savings.

[0032] Of course, any product implementing this invention does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of the present 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 some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 This is a schematic diagram illustrating the implementation of three important software modules of a microcontroller in a data caching system for IoT devices used in mineral exploration, according to an embodiment of the present invention.

[0035] Figure 2 This is a flowchart of a data caching method for IoT devices used in mineral exploration, according to an embodiment of the present invention.

[0036] Figure 3 This is a schematic diagram of the execution flow of the push interface of the cache queue module according to an embodiment of the present invention;

[0037] Figure 4 This is a schematic diagram of the execution flow of the pop-up interface of the cache queue module according to an embodiment of the present invention;

[0038] Figure 5 This is a schematic diagram of the execution flow of the auxiliary recording module writing interface according to an embodiment of the present invention;

[0039] Figure 6 This is a schematic diagram of the execution flow of the recovery interface of the auxiliary recording module according to an embodiment of the present invention;

[0040] Figure 7 This is a schematic diagram of the execution flow of the auxiliary recording module writing interface according to an embodiment of the present invention;

[0041] Figure 8 This is a schematic diagram of the execution flow of the auxiliary recording module transfer interface according to an embodiment of the present invention;

[0042] Figure 9 This is a schematic diagram of the execution flow of the system push interface according to an embodiment of the present invention;

[0043] Figure 10 This is a schematic diagram of the execution flow of the system pop-up interface according to an embodiment of the present invention;

[0044] Figure 11 This is a schematic diagram of the execution flow of the system refresh interface according to an embodiment of the present invention. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0046] It should be noted that the illustrations provided in the embodiments of the present invention are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0047] In this invention, it should also be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application. Furthermore, the terms "first" and "second" are used only for descriptive and distinguishing purposes and should not be construed as indicating or implying relative importance.

[0048] Furthermore, it should be noted that the features of the various embodiments of the present invention can be combined or integrated in whole or in part, and as those skilled in the art will understand, they can interact and operate in different ways. Each embodiment can be implemented independently of each other or in association with one another.

[0049] The hardware layer of the data caching system for IoT devices in mineral exploration according to the present invention mainly includes a microcontroller and external flash memory. The microcontroller includes at least one processor core, a certain amount of RAM, and flash memory, wherein the flash memory must allow in-application programming (i.e., allowing user programs to read and write to specified flash memory areas via addresses). Simultaneously, the microcontroller should include the necessary peripheral interfaces for communicating with the external flash memory. External flash memory refers to a flash memory element that can be programmed via external circuitry, and it should provide write, read, and erase functions. The data caching system for IoT devices in mineral exploration is mainly used to implement the data caching method for IoT devices in mineral exploration as described in the following embodiments.

[0050] like Figure 2 As shown, the data caching method for mineral exploration IoT devices in this embodiment of the invention is executed in a single thread in the microcontroller of the mineral exploration IoT device, and mainly includes the following steps:

[0051] S1. When a user needs to store data, the data is first cached through the first cache queue module in the microcontroller's memory. The first cache queue module specifically separates the element address and the data cache, and dynamically utilizes the microcontroller's memory space to cache the data according to the size of the data to be stored.

[0052] S2. When the external flash memory is idle, according to the head offset position of the external flash memory stored in the auxiliary recording module in the microcontroller memory, the data in the first cache queue module is popped out one by one and pushed into the second cache queue module of the external flash memory for persistent data caching.

[0053] S3. When the user needs to retrieve and upload the data cached in the external flash memory, according to the header offset position of the external flash memory stored in the auxiliary recording module, the data in the second cache queue module in the external flash memory is popped out one by one, and the space in the external flash memory is released at the same time.

[0054] To implement the above method, at the software level, the system operates on a First-In-First-Out (FIFO) queue pattern. There are three main software modules (such as...). Figure 1As shown in the figure: a cache queue module, an auxiliary record module, and an external flash drive module. It provides three main interfaces for users: push, pop, and refresh. The push interface adds user data to the end of the queue; the pop returns the data at the head of the queue to the user and deletes it from the system; the refresh is a function that the user must run periodically to drive the system.

[0055] (1) Cache queue module

[0056] When the user pushes data into the system, the system may be waiting for flash I / O. At this time, the user data must be cached first and then written to the flash after the I / O wait ends, without blocking the caller. This module is the key to improving the system response speed.

[0057] The cache queue module is a memory-based FIFO data structure, containing 4 sub-variables: an integer head for recording the head level index, an integer back for recording the tail level index, an integer array buffer which is a circular buffer for storing data at each level, and an integer array levels for indexing the starting offset of each level of the FIFO on the buffer. The initial values of these variables are all 0. The length of the levels array is D, and the length of the buffer array is S. D and S are specified by the user. Here, D is the maximum depth of the FIFO (i.e., the maximum number of elements), and S is the maximum data capacity of the FIFO. This module provides two interfaces: push and pop. The execution methods of each interface are as follows:

[0058] Push interface: Any data with a length less than S can be pushed into this module. Let the data pushed by the caller be named element with a length of size. The execution process is as follows (as Figure 3 shown in the figure)

[0059] 1) Calculate the remaining space free. First, calculate the current head offset headAddress as levels[head], and the tail offset backAddress as levels[back]. When backAddress >= headAddress, free is S - (backAddress - headAddress); otherwise, free is headAddress - backAddress. If free < size, it means there is not enough space to push this element, and the user can return an error or forcefully pop a head element to release space according to the situation. If there is enough space, continue to the next step.

[0060] 2) Calculate the back level index after pushing in as (back+1)%D, and the back offset after pushing in as backAddressNext as (backAddress+size)%S.

[0061] Next, if backAddress + size <= S, then directly copy the element to the buffer + backAddress position; otherwise, it means that the buffer has looped, so calculate the length of the first part of the data as size0 = S - backAddress, first copy the data of length size0 of the element header to the buffer + backAddress position, and then copy the remaining data of the element to the buffer + 0 position.

[0062] 3) Update back to backNext, and update levels[backNext] to backAddressNext.

[0063] Pop-up interface: This allows data to be popped from the module header. The caller needs to provide a buffer element to store the returned data. Its execution process is as follows (e.g., Figure 4 (as shown)

[0064] 1) Check if the data in the module is empty. If back equals head, the data is empty, and no further operations will be performed. Otherwise, it is not empty, and execution continues.

[0065] 2) Calculate the next head position after popping, headNext is (head+1)%D. Calculate the offset of the head data in the buffer, start at levels[head] and end at levels[headNext]. Update head to headNext.

[0066] 3) If end > begin, then copy the data from buffer+begin to buffer+end to element; otherwise, it means that the buffer has looped, so first copy the data from buffer+begin to buffer+S to the beginning of element, and then copy the data from buffer+0 to buffer+end to the remaining space of element.

[0067] (2) Auxiliary recording module

[0068] This module stores the head and tail offset positions of the system. During runtime, this information is stored in memory; however, for persistent storage, this data must be saved to flash memory at appropriate times and restored from flash memory after each hardware reboot. This module consists of two sub-modules called "page modules." Page modules are an abstraction of the microcontroller's flash memory "pages," allowing users to write a certain length of data to flash memory and then read it back, while ensuring wear leveling within this flash memory area to extend its lifespan.

[0069] The page module contains four sub-variables: `addrSignature` (integer) stores the page status information address, `addrBegin` stores the starting address of the space, `addrEnd` stores the ending address of the space, and `addrNext` stores the address for the next write operation. When initializing this module, the user must specify the page number located in the flash memory corresponding to this page module and calculate the page starting address. `addrSignature` corresponds to the starting address of this page, `addrBegin` is `addrSignature + 1`, `addrEnd` is the page starting address plus the size of each page in the flash memory, and `addrNext` defaults to `addrBegin`. The page module provides the following interfaces:

[0070] Write Interface: Allows users to write data to the page. To identify the user-written data, the user needs to provide not only the data itself but also an integer data name. Let the user-provided data name be `name`, the data name be `object`, and the data size be `size` (note that `size` cannot exceed the flash page size). The interface returns the offset position `addr` for the next write operation. The write process executes as follows (e.g., ...). Figure 5 (as shown)

[0071] 1) Calculate the CRC value for the object and name it crc.

[0072] 2) Using the microcontroller's in-application programming interface, write crc, name, size, and object sequentially to the addrNext address. Although this step is a synchronous operation, the microcontroller's built-in flash memory is usually much faster to write and has a very short I / O wait time compared to external flash memory, so it usually does not have a significant impact on program performance.

[0073] 3) If the write operation is successful, update addrNext to addrNext + size + sizeof(name) + sizeof(crc) + sizeof(size) and return addrNext. If the write operation fails, it means that the current page is full, so return 0.

[0074] Read Interface: Allows users to read previously written data from a specified address. This interface typically doesn't require special design, as reading data from a microcontroller's flash memory can usually be done in the same way as accessing main memory—by address. This operation is relatively simple and therefore not illustrated.

[0075] Erase Interface: This interface calls the corresponding interface on the microcontroller to perform an erase operation on the page. After erasing, 0xFFFFAAAA is written to the addrSignature location. This operation is relatively simple, so no diagram is provided.

[0076] Activation Interface: This interface marks the page as active by writing the data 0xAAAAAAAA to the addrSignature location. This operation is relatively simple and therefore not illustrated.

[0077] Activation status check interface: This interface checks the data at the addrSignature position to determine whether the page is active. This operation is relatively simple, so no diagram is provided.

[0078] Recovery Interface: This interface is used to restore the module's relevant status data after each hardware reboot. This interface returns an integer array `index`. Calling this interface retrieves the names of all data written to this page, as well as the address of the latest version of that data. The execution process of this interface is as follows (e.g., ...). Figure 6 (as shown)

[0079] 1) Let address be addrBegin.

[0080] 2) Read the data at the address location, retrieve the previously written CRC, name, size, and object, and perform CRC verification on the object.

[0081] 3) If the validation fails, the process ends. If the validation passes, update the address to address + size + sizeof(name) + sizeof(crc) + sizeof(size), and re-execute step 2).

[0082] Using a single page is sufficient to complete the offset data recording for wear leveling. However, the erasure time after a page is full is usually long. To reduce I / O wait time, we need to merge two page modules into an auxiliary recording module and switch between the two page modules to achieve asynchronous erasure. Let the two page modules contained in the auxiliary recording module be named a and b, and contain the following sub-variables: a page module pointer active (recording the currently active page) and an integer array index (recording the address corresponding to the data name).

[0083] The auxiliary recording module provides the following interfaces:

[0084] Write interface (e.g.) Figure 7 (As shown): This interface is used to write data to the currently active page. Its parameters are identical to the write interface of the page module; therefore, the write interface of the page module corresponding to the active page is called directly to write the data. If the write fails, it means the page is full, so the transfer interface is executed, and the write interface of the page module corresponding to the active page is called again after the transfer interface is completed. Upon successful writing, the function returns `address`, and `index[name]` is updated to `address`.

[0085] Read interface: Consistent with the page module's read interface, directly calling the read interface of the page module corresponding to the active module. This operation is relatively simple, therefore no diagram is provided.

[0086] Transfer Interface: This interface is used to transfer data from a full active page module to another erased page module. For example... Figure 8 As shown, the execution steps are as follows:

[0087] 1) First, determine whether the target page module next is a or b by comparing it with active.

[0088] 2) Iterate through all elements in the index, with index i and data as address. If address is greater than 0, read the data at that address from active and write it to next. This completes the data transfer.

[0089] 3) Execute the activation interface of next.

[0090] 4) Execute the active erase interface.

[0091] 5) Update active to next.

[0092] Recovery Interface: This interface is used to restore the module's relevant status data after each hardware reboot. The operation is relatively simple and therefore not illustrated. The execution steps of this interface are as follows:

[0093] 1) Check whether the currently active page module is a or b through the page module's activation status check interface, and assign the currently active page module to active.

[0094] 2) Execute the active recovery interface to obtain the names and addresses of all data on the page and assign them to index.

[0095] Through the above design, the auxiliary recording module achieves wear-balanced and non-blocking data reading and writing on the microcontroller's flash memory. However, this module is only suitable for random recording of small amounts of data with low update frequency, because the flash memory space of microcontrollers is usually small, and the module does not implement a FIFO-type data interface.

[0096] (3) External flash drive module

[0097] This module is essentially an abstraction of external flash memory. The specific implementation varies depending on the hardware register definitions, but it is relatively simple and therefore not illustrated. This external flash memory driver module mainly implements the following interface functions: writing, reading, and erasing the external flash memory based on the tail offset position of the external flash memory stored in the auxiliary recording module.

[0098] The external flash drive module provides the following interfaces:

[0099] Write interface: The caller provides the page number, data, and data size, and writes the data to the external flash memory.

[0100] Read interface: The caller provides the page number and data size, and the interface returns the data from the external flash memory at that address.

[0101] Erase Interface: The caller provides the sector number to be erased, and execution will begin erasing that sector. This interface returns immediately after execution without waiting for the erasure to complete.

[0102] Erasure status query interface: Query whether the flash memory is currently being erased.

[0103] Generally speaking, the I / O operation speed of external flash memory is very fast; it is only the erasure process that takes a relatively long time.

[0104] (4) System interface

[0105] The above three modules constitute the main part of this system. However, in addition, the system requires some auxiliary variables: an integer `head` to record the header page number, an integer `back` to record the footer page number, and a boolean `dirty` to record changes to the header or footer page numbers. Assume the number of pages in the external flash memory is P, and the size of each page is N. The system provides the following interfaces:

[0106] Push Interface: This allows data of any length less than N to be pushed into the system. Let the data pushed by the caller be named `element`, and its length be `size`. For example... Figure 9 As shown, the execution process is as follows:

[0107] 1) Calculate the CRC checksum of the element.

[0108] 2) Execute the push interface of the cache queue module to push in a task data, which includes the following: the task type is write, the write page is back, and the write data is size, crc, and element.

[0109] 3) Update dirty to true. Calculate the sector S0 to which back belongs, then update back to (back+1)%P, and recalculate the sector S1 to which back belongs.

[0110] 4) If S0 is not equal to S1, it means that the next write will be to a new sector and needs to be erased. Then push a task data into the cache queue, which contains the following: the task type is erase and the erased sector is S1.

[0111] Pop-up interface: The execution process of this interface is as follows (e.g.) Figure 10 (as shown)

[0112] 1) Check if head equals back. If they are equal, it means there is no more data to pop from the system, so return empty and do not continue execution.

[0113] 2) Call the erase status query interface of the external flash drive module. If erasure is in progress, return empty directly and do not continue execution.

[0114] 3) Call the read interface of the external flash drive module to first read the first few bytes of the head page to determine the data size of the page. After reading all the data, update the head to (head+1)%P and the dirty to true. Perform CRC check on the read data. If the check passes, return the data; otherwise, return null.

[0115] Refresh Interface: The execution process of this interface is as follows (e.g.) Figure 11 (as shown)

[0116] 1) If dirty is true, the write interface of the auxiliary recording module is called to save head and back to the auxiliary recording module with different names (e.g., 0 and 1). Then dirty is updated to false.

[0117] 2) Call the erase status query interface of the external flash drive module. If erasure is in progress, return directly and do not continue execution.

[0118] 3) Call the pop-up interface of the cache queue module. If no new task data is popped up, return directly and do not continue execution; otherwise, obtain the type of new task data.

[0119] 4) If the task type is write, parse the write page, write data and size in the task, call the write interface of the external flash driver module to write the data to the corresponding page, and then return.

[0120] 5) If the task type is erase, parse the erase sector in the task, call the erase interface of the external flash drive module to erase the corresponding sector, and then return.

[0121] This invention constructs a caching system on a microcontroller, featuring an asynchronous push-in and pop-out first-in-first-out (FIFO) queue pattern, through the close cooperation of three modules. The key to this system lies in eliminating the primary source of I / O wait for external flash memory—erase operations—while ensuring balanced flash memory wear. Even when external flash memory is being erased, the system can still push data normally without blocking other business logic, significantly improving data processing efficiency compared to traditional blocking methods. Simultaneously, the system provides three simple interfaces, allowing user programs to enjoy the efficiency gains brought by asynchronous operations without complex specialized design. Designed specifically for the data generation and transmission characteristics of mineral exploration equipment—namely, high-frequency, small-scale, and numerous periodic data production—this system ensures that data is pushed into flash memory for caching as it is generated, even when the equipment is offline, and can be popped and sent to a remote server when a network connection is available. This design adapts to the network environment characteristics of field operations, enabling mineral exploration equipment to benefit from IoT technology, achieving secure and efficient data transmission and improving the efficiency of mineral exploration work.

[0122] It should be noted that this invention differs from solid-state drive (SSD) caching in the following ways: (1) Different purposes: SSDs are general-purpose storage devices, and their versatility is most directly reflected in their support for "random access," meaning that each write operation can specify an arbitrary write location. However, this invention addresses the problem of how to cache data when there is no signal, and therefore uses a simpler data structure, namely a queue. (2) Different methods: To achieve efficient random writing, the SSD controller system is usually quite complex. In terms of software, to achieve balanced writing of flash memory hardware, the controller chip must maintain a mapping table between virtual and physical addresses. For example, when repeatedly writing data to address 0xAA, the actual address of the corresponding flash memory chip changes each time. In addition, for frequently read and written data, to reduce the wear caused by erasing the flash memory chip and improve burst write performance, the SSD controller usually provides a large cache space on the volatile memory. However, to achieve random access, this cache usually uses a mapping table to record data, where the key of the mapping table is the data address and the value is the data at that address. At the hardware level, to handle the complex random read / write operations mentioned above, solid-state drives (SSDs) typically employ high-performance controller chips. These controller chips must provide a memory management unit (MMU) to enable efficient random access on volatile memory (i.e., RAM) to support mapping table data structures. Simultaneously, these chips usually have multiple cores to improve SSD read / write efficiency through multi-threaded operation. Due to this complex software and hardware configuration, SSDs typically consume a relatively high amount of power, usually around 3 watts.

[0123] This patent addresses embedded devices intended for field use. To maximize energy efficiency, the microcontroller is typically a low-power chip with lower performance (power consumption usually only tens of milliwatts, about a hundred times less than that of a solid-state drive). It usually has only one core and lacks a memory management unit (MMU). Therefore, it's impossible to implement complex random access storage like a solid-state drive on this hardware. However, since this invention addresses a specific problem in a specific field, the high-power-consumption general-purpose solution of solid-state drives is unnecessary. Based on this limited hardware, this invention implements a dedicated dual-layer buffered data structure. A queue data structure (first cache queue module) with dynamically adjustable element size is implemented on volatile memory. A similar queue data structure (second cache queue module) is implemented on non-volatile memory, combined with the microcontroller's built-in flash memory (auxiliary storage module). Furthermore, data exchange between the two cache queues can be handled by a single thread, sufficient to handle sudden data writes.

[0124] In summary, the SSD controller chip is equivalent to the microcontroller of this invention. The SSD cache chip is equivalent to the memory in the microcontroller of this invention. The SSD flash memory chip is equivalent to the flash memory chip of this invention. However, the SSD controller chip is expensive, high-performance, and consumes a lot of power, and has multiple cores. Multi-threaded programs are easily implemented on this basis. In contrast, the microcontroller of this invention is inexpensive, has poor performance, consumes little power, and has a single core. It typically only supports single-threaded programs, making multi-threaded programs more difficult to implement. The SSD cache chip includes a memory management unit (MMU) hardware, enabling the use of advanced data structures such as heaps, primarily used to implement mapping table data structures. The memory of this invention does not include an MMU, and using a heap easily leads to memory fragmentation and performance degradation; therefore, the software portion of this invention employs a special queue data structure. The SSD flash memory chip and the flash memory chip of this invention are generally similar, but due to the powerful performance of the SSD controller chip, a mapping table approach is typically used for wear leveling. This invention, limited by the performance and power consumption of the controller chip, cannot use a mapping table approach for wear leveling. However, the essence of this invention is a queue data structure, and a circular queue data structure can naturally achieve loss balancing, so no special design is needed.

[0125] In one specific embodiment of the present invention, the microcontroller is selected from the semiconductor STM32F103ZGT6, and the flash memory is W25Q128FW.

[0126] The W25Q128 flash memory has a capacity of 128 Mbit, or 16 Mbytes. Each page is 256 bytes, for a total of 65,536 pages. Each sector consists of 16 pages. The smallest erase unit for this flash memory is a sector, and the erase time per sector is 100 to 400 milliseconds. This flash memory connects to the microcontroller via an SPI interface.

[0127] The software portion of this system can be implemented using C++ code.

[0128] The implementation method of the cache queue module is as follows:

[0129] Define a template class named FIFO, where the template parameter SIZE is of type uint32, representing the buffer size, and the template parameter DEPTH is of type uint32, representing the maximum queue depth. This template class provides two public methods: Push—for pushing data into the queue; and Pop—for popping data from the queue. It also provides two private methods: Allocate—for allocating space from the buffer; and Deallocate—for releasing space from the buffer. Additionally, this class has four member variables: _head (uint8 type), used to store the queue head level index; _back (uint8 type), used to store the queue tail level index; _levels (uint32 type array of length DEPTH), used to store the starting offset of each level in the buffer; and _buffer (uint8 type array of length SIZE), used to store the data in the queue.

[0130] The specific implementation methods for each function are as follows:

[0131] The `Push` function returns a boolean value indicating whether the push was successful. It takes three parameters: `element` (a void constant pointer to the buffer containing the data to be pushed), `size` (an int representing the length in bytes of the data to be pushed), and `forced` (a boolean value specifying whether to pop an existing element to free up space when the queue is full). The function first checks if `size` is less than or equal to 0; if so, it returns `true` to indicate a successful push. Then, it allocates space at the end of the circular buffer using `size` and `forced`, obtaining the starting address of the allocated space (`address`). If allocation fails, it returns `false`. It calculates `address + size`. If `size` is less than or equal to `SIZE`, the buffer doesn't need to be circular, and `element` can be directly copied to `address`. If `size` is greater than `SIZE`, `element` is copied in segments to `address` and the beginning of the buffer. Finally, it returns `true` to indicate that one data item has been pushed.

[0132] The `pop` function returns an `int` representing the length of the popped data. It takes two arguments: `element`, a `void` pointer to the popped data buffer, and `size`, an `int` representing the length of the popped buffer in bytes. The function first checks if the queue buffer is empty by comparing `_head` and `_back`; if empty, it returns 0. Then, it defines two `uint32` variables, `begin` and `end`, calls the `Deallocate` function to release the space for the first element in the queue, and copies the start and end addresses of that element to `begin` and `end`. If `end` is greater than `begin`, the queue buffer is not circular, and the data between `begin` and `end` is copied directly to `element`. If `end` is less than `begin`, the buffer is circular, and the data between `begin` and `end` is copied in segments to `element`. Finally, it returns the length of the retrieved element.

[0133] The `Allocate` function returns a `uint32` value representing the starting address of the allocated queue buffer space. It takes two parameters: `size` (an `int`) representing the size of the space to be allocated, and `forced` (a `bool`) indicating whether to pop existing elements to free up space when the queue is full. The function first checks if there are any free levels in the `_levels` index. Specifically, it checks if `(_back+1)%DEPTH` equals `_head`. If they do, the queue is full. If `forced` is false, it returns the maximum value of `uint32`, indicating that no space can be allocated. Next, it checks if `size` is greater than `SIZE`. If it is, the element data length exceeds the length of the data buffer `_buffer`, and it also returns the maximum value of `uint32`, indicating that no space can be allocated. Next, the tail address of the queue buffer is retrieved using `_levels[_back]` and set as `backAddress`; the head address of the queue buffer is retrieved using `_levels[_head]` and set as `headAddress`; the level index in `_levels` for the next space allocation request is obtained by calculating `(_back+1)%DEPTH` and set as `backNext`; the address in `_buffer` for the next space allocation request is obtained by calculating `(backAddress+size)%SIZE` and set as `backNextAddress`. Then, the remaining space in `_buffer` is calculated. If `backAddress` is greater than or equal to `headAddress`, `SIZE-(backAddress-headAddress)` is calculated; otherwise, `headAddress-backAddress` is calculated, and the result is set as `free`. If `free` is less than or equal to `size`, it means there is insufficient remaining space in `_buffer`. In this case, if `forced` is false, the maximum value of `uint32` is returned directly, indicating that space cannot be allocated. If `forced` is true, the existing elements in the queue are released one by one until the available space in `_buffer` is not less than `size`. After ensuring sufficient space in _buffer, store backNextAddress in _levels[backNext], which is the starting position when space is requested again. Finally, return backAddress.

[0134] The `Deallocate` function is the opposite of `Allocate` and has no return value. It takes two parameters: `begin`, a `uint32` reference type, representing the starting address of the freed memory; and `end`, a `uint32` reference type, representing the ending address of the freed memory. This function sets `begin` to `_levels[_head]`, `_head` to `(_head+1)%DEPTH`, and finally sets `end` to `_levels[_head]`.

[0135] The above completes the implementation of the cache queue module.

[0136] The auxiliary recording module includes two classes: BucketPage and Bucket.

[0137] BucketPage encapsulates a single page within a Bucket, serving the Bucket class. It contains six public functions: Resume (to restore the page state from internal flash memory), Write (to write data to internal flash memory), Read (to read data from a specified address), IsActive (to check if the page is active), Activate (to activate the page), and Erase (to erase the page). It also contains one private function: Verify (to check if valid data exists at a specified address). Furthermore, it includes five private constants and variables: the constant _addrSignature (a uint32 type) represents the address of the page's state information; the constant _addrBegin (a uint32 type) represents the starting address of the page's storage area; the constant _addrEnd (a uint32 type) represents the ending address of the page's storage area; the variable _signature (a constant uint32 pointer type) is used to read the current page's state information; and the variable _addrNext represents the address where the page will be written next.

[0138] The specific implementation methods of each function in BucketPage are as follows:

[0139] The `Write` function returns a `uint32` value representing the address where the data is written. It takes three parameters: `name` (an `int8`) specifying the name of the data to be written; `object` (a constant `void` pointer pointing to the buffer containing the data to be written); and `size` (an `int` representing the size of the data in bytes to be written). The function first calculates the CRC checksum of the data pointed to by `object` and `name`. Then, it takes the first byte of the checksum and merges it with `name` and `size` into a `uint32` variable to form the header to be written. Next, it calls the microcontroller's internal Flash programming interface to write the data pointed to by `header` and `object` to the Flash memory. Finally, it calculates the address for the next write operation and updates `_addrNext` with that address.

[0140] The `Resume` function has no return value. It takes one parameter, `index`, a `uint32` pointer, which outputs the address indices of all data found in the flash memory. The function searches all data starting at address `_addrBegin` and ending at address `_addrEnd`. The actual search is performed by the `Verify` function. If `Verify` returns a valid data name, it also returns the address of the next valid data. If it returns an invalid data name, it means there is no more valid data. For each valid data, it is indexed into the `index` variable using its name as the sequence number and its address as the value. After the search is complete, the next address written is the address last substituted into the `Verify` function, and this address is assigned to `_addrNext`.

[0141] The Verify function returns a valid data name of type uint8. It takes one parameter, address, a uint32 reference, used to input the address of the data to be verified, and to output the address of the next data if verification is successful. This operation can be seen as the inverse operation of the Write function. Although it must retrieve the data at the target address during execution, its purpose is not to retrieve the data, but to verify whether the data stored in flash memory is valid. If it is valid data, it returns the name stored in the data header.

[0142] Since the BucketPage class is generally used in pairs, and only one of the two pages must be active, specific identification data is stored in _addrSignature to determine whether the page is active or has been erased and is ready for use. The activation state setting and retrieval are encapsulated using Activate and IsActive.

[0143] The Read and Erase functions are essentially wrappers around the read and erase methods provided by the STM32F103's HAL, so they will not be elaborated on here.

[0144] The Bucket class essentially merges two BucketPages together, encapsulating them into a single memory that provides name-based writing and reading. When a page is full, Bucket must also handle the transfer of data from the old page to the new one. Through the Bucket class, the auxiliary recording module is implemented, allowing upper-level programs to permanently store short data using uint8 formatted names without needing to worry about the underlying erasure and rewriting processes.

[0145] The above completes the implementation of the auxiliary recording module.

[0146] The external flash memory driver module is essentially a wrapper around the SPI register interface of the W25Q128FW. The W25Q128FW manual directly provides instructions on how to read, write, and erase data by accessing registers via the SPI interface, so these details will not be repeated here.

[0147] Based on the above underlying modules, a top-level class for caching can be implemented. This class mainly implements the second cache queue. To achieve simple and efficient data reading and writing in the second cache queue, the maximum length of each element in the queue is rigidly set to 256 bytes, which is the page size of the W25Q128FW. The main drawback of this design is that it limits the maximum length of elements and can easily lead to space waste for short data. However, in practical applications, the length of a single data item is usually short, and flash memory usually has a large amount of space (e.g., 16MB for the W25Q128FW), so the above two problems are not significant. The advantage of this design is obvious—the element data is aligned with the flash memory page. For example, when releasing the space occupied by an element, the entire sector can be erased without worrying about erasing "half" an element, thus making data management very simple.

[0148] In this class, the first buffer queue is used as a direct data cache. The encoding format for each element is as follows: the first byte of the element data is used to mark the operation type, which includes write (represented by 0x00) and erase (represented by 0x01). If the operation type is write, the remaining element data is the write address and the data to be written; if the operation type is erase, the remaining element data is the sector number to be erased.

[0149] This class contains three functions: Push, Pop, and Frame.

[0150] The Push function typically performs necessary checks, such as the size of the data to be written and whether the last page in the external flash memory has been erased. After these checks, the address of the tail of the second buffer queue, denoted as backAddress, is read from the auxiliary recording module. The data to be written is then encoded using a header encoding method similar to that in the auxiliary recording module, constructing a header containing CRC checksum and data size. A data block encoded as follows is then constructed: the first byte is 0x00, followed by backAddress, then the header, and finally the data to be written. This data is then pushed into the first buffer queue—an instance of a FIFO class—using its Push interface. Afterward, the tail address of the queue recorded in the auxiliary recording module is updated to the address of the next page in the external flash memory. It is important to note again that if the address of the next page is not in the same sector as the address of the previous page, an additional erase operation must be pushed into the first buffer queue to ensure that the corresponding sector in the external flash memory is writable the next time it is pushed in. Specifically, a data block is constructed with the following encoding: the first byte is 0x01, followed by the sector number corresponding to the address of the next page, and the Push interface of the first cache queue is called to push the data into the first cache queue. This completes the Push operation.

[0151] Because reading data from the W25Q128FW is relatively fast, the Pop function does not require the first buffer queue. The Pop function first reads the head and tail addresses of the second buffer queue in the auxiliary recording module. If they are equal, it indicates that there is no data in the second buffer queue, and the function returns directly. Otherwise, it indicates that there is data, and the function directly calls the read instruction of the external flash memory driver module, specifically the W25Q128FW's 0x03 instruction, to read the data at the head address. In the actual reading process, the element data header needs to be read first to determine the size of the data to be read, and then the element data is read and returned to the caller. After reading is complete, the head address of the second buffer queue in the auxiliary recording module needs to be updated to the address of the next page.

[0152] Finally, in the Frame function, the following logic is constructed: First, the driver interface of the W25Q128FW is called to check if the flash memory is busy. If it is busy, it returns directly. If it is not busy, the Pop interface of the first buffer queue is called to pop data. If no data is popped, it returns directly. If data is popped, the first byte of the data is checked. If it is 0x00, it indicates a write operation; if it is 0x01, it indicates an erase operation.

[0153] If it's a write operation, the write address, data content, etc., are parsed, and then the write interface of the W25Q128FW driver, i.e., instruction 0x02, is called to write the data to the specified address. Then it returns.

[0154] If it is an erase operation, the system parses out the sectors to be erased, then calls the erase interface of the W25Q128FW driver, specifically the 0x20 instruction, to erase the specified sectors. Then it returns.

[0155] The above completes the construction of the caching system of the present invention.

[0156] In practical use, the following operations can be performed at 10ms intervals: When the upper layer needs to push data (e.g., data received from UART), the Push interface is called to push the data in. When the upper layer needs to pop data (e.g., when a network connection is detected), the Pop interface is called to pop the data and send it to the network. After that, the Frame interface is executed once.

[0157] This application also provides a computer-readable storage medium, such as flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disk, server, App application store, etc., which stores a computer program, and the program implements corresponding functions when executed by a processor. The computer-readable storage medium of this embodiment implements a data caching method for IoT devices in mineral exploration, as described in this embodiment.

[0158] It should be noted that, depending on the implementation needs, the various steps / components described in this application can be broken down into more steps / components, or two or more steps / components or parts of the operation of steps / components can be combined into new steps / components to achieve the purpose of this invention.

[0159] The order of the steps in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0160] It should be understood that those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. A data caching method for mineral exploration Internet of Things devices, characterized by, The method is single-threaded in a microcontroller of a mineral exploration Internet of Things device; When a user needs to store data, the data is first cached through a first cache queue module in the microcontroller memory, and the first cache queue module specifically separates the element address and the data cache, and dynamically uses the microcontroller memory space to cache the data according to the size of the data to be stored; When the external flash memory is idle, the data in the first cache queue module is popped out one by one according to the head offset position of the external flash memory stored in the auxiliary recording module in the microcontroller memory, and is pushed into the second cache queue module in the external flash memory for persistent caching of the data; When the user needs to take out and upload the cached data in the external flash memory, the data in the second cache queue module in the external flash memory is popped out one by one according to the head offset position of the external flash memory stored in the auxiliary recording module, and the space in the external flash memory is released at the same time.

2. The data caching method for mineral exploration internet of things device according to claim 1, characterized in that, The first cache queue module includes a data push-in interface and a data pop-out interface, and the data push-in interface is used to dynamically store non-equal-length data into the first cache queue module; the data pop-out interface is used to delete the stored data from the head of the first cache queue module and store the deleted data into a specified buffer.

3. The data caching method for mineral exploration internet of things device according to claim 2, characterized in that, The first cache queue module is a FIFO data structure based on the microcontroller memory, and includes four sub-variables: a first sub-variable is an integer type head, used to record the head level index; a second sub-variable is an integer type back, used to record the tail level index; a third sub-variable is an integer type array buffer, used to store the ring buffer of each level data; and a fourth sub-variable is an integer type array levels, used to index the start offset of each level of the FIFO data structure on the integer type array buffer.

4. The data caching method for mineral exploration internet of things device according to claim 1, characterized in that, The auxiliary recording module includes a write interface, a read interface, an erase interface, an activation interface, an activation state check interface and a recovery interface, and the write interface writes the head offset and the tail offset position of the external flash memory.

5. The data caching method for mineral exploration internet of things device according to claim 1, characterized in that, The auxiliary recording module includes two page modules, and the page module is an abstraction of the page of the microcontroller flash memory, and the page module includes four sub-variables: a first sub-variable is an integer type addrSignature, used to store the page state information address of the microcontroller flash memory; a second sub-variable is an integer type addrBegin, used to store the start address of the microcontroller flash memory; A third sub-variable is an integer type addrEnd, used to store the end address of the microcontroller flash memory; and a fourth sub-variable is an integer type addrNext, used to store the next write address of the microcontroller flash memory.

6. The data caching method for mineral exploration internet of things device according to claim 1, characterized in that, The method specifically realizes reading, writing and erasing of the external flash memory through the external flash memory driving module provided in the microcontroller.

7. The data caching method for mineral exploration internet of things device according to claim 3, characterized in that, Any data with a length less than S is pushed into the first cache queue module, S is the maximum data capacity of the FIFO, the data is named element, and the length is size, and the specific execution process of the push-in interface is as follows: Calculate the remaining space, if the remaining space is not enough, return an error or forcibly pop out a head element to release the space according to the situation; If the remaining space is sufficient, calculate the tail level index after pushing and the tail offset after pushing; If the sum of the current tail offset and the length of the pushed data is less than or equal to S, the data element is directly written into the ring buffer; otherwise, it is indicated that the ring buffer has occurred a cycle, and the data element needs to be segmented and written.

8. The data caching method for mineral exploration internet of things device according to claim 3, characterized in that, The specific execution process of the pop-up interface is as follows: Check whether the data in the first cache queue module is empty, if not, calculate the position of the next head after the data is popped out and update it; Calculate the offset start position and offset end position of the current head data in the ring buffer, if the offset end position is greater than the offset start position, directly copy the head data to the specified position; otherwise, it is indicated that the ring buffer has occurred a cycle, and the head data is segmented and copied to the specified position.

9. A data caching system for mineral exploration internet of things devices, characterized in that, It comprises a microcontroller and an external flash memory, which caches data through the method of any one of claims 1-8.

10. A computer storage medium, characterized in that It stores a computer program executable by a processor, and the computer program executes the data caching method for mineral exploration Internet of Things devices in any one of claims 1-8.

Images