Firmware data processing method and apparatus, storage medium, and electronic device

Abstract

This application discloses a firmware data processing method, apparatus, storage medium, and electronic device. The method includes, in response to a firmware data processing request, obtaining a first address and a first parameter; obtaining a second parameter, wherein the second parameter represents the amount of firmware data requested initially, and the second parameter is less than the first parameter; generating and sending a first request to a server based on the first address and the second parameter; storing first data in response to obtaining a first response corresponding to the first request; generating and sending at least one second request to the server in response to successful storage of the first data; and storing second data corresponding to the second request. This application reduces the amount of firmware data processed per batch by requesting firmware data in batches, eliminating the need to copy firmware data, saving storage resources, and improving the processing speed of firmware data.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and in particular to firmware data processing methods, apparatus, storage media, and electronic devices. Background Technology

[0002] In related technologies, terminal devices typically need to request firmware data over the network before processing it. During this request, the terminal device sends a single network request to the firmware. However, when the firmware data volume is large, the terminal device may need to provide significant storage space to receive it, putting pressure on its storage. Furthermore, for some resource-constrained terminal devices, insufficient storage space may prevent firmware data requests from failing. Summary of the Invention

[0003] In order to reduce the consumption of storage resources during firmware data interaction and improve the interaction performance of firmware data, embodiments of this application provide firmware data processing methods, apparatus, storage media and electronic devices.

[0004] On one hand, embodiments of this application provide a firmware data processing method, the method comprising:

[0005] In response to a firmware data processing request, a first address and a first parameter are obtained, wherein the first address represents the storage address of the firmware data on the server, and the first parameter represents the total amount of firmware data.

[0006] Obtain the second parameter, which represents the amount of firmware data requested in the first request, and the second parameter is less than the first parameter;

[0007] Based on the first address and the second parameter, a first request is generated and sent to the server. The first request is used to obtain first data, which is data in the firmware data whose data volume is equal to the second parameter.

[0008] In response to obtaining the first response corresponding to the first request, the first data is stored;

[0009] In response to the successful data storage of the first data, at least one second request is generated and sent to the server, the at least one second request being used to request second data, the second data being the difference between the firmware data and the first data;

[0010] In response to receiving a second response corresponding to the at least one second request, the second data is stored.

[0011] On the other hand, embodiments of this application provide a firmware data processing apparatus, the apparatus comprising:

[0012] A parameter acquisition request is used to respond to a firmware data processing request and acquire a first address and a first parameter, wherein the first address represents the storage address of the firmware data on the server and the first parameter represents the total amount of firmware data.

[0013] The second parameter acquisition module is used to acquire a second parameter, which represents the amount of firmware data requested for the first time, and the second parameter is less than the first parameter.

[0014] The first data processing module is configured to generate and send a first request to the server based on the first address and the second parameter. The first request is used to obtain first data, which is data in the firmware data whose data volume is equal to the second parameter.

[0015] The first data storage module is used to store the first data in response to obtaining the first response corresponding to the first request;

[0016] The second data processing module is configured to generate and send at least one second request to the server in response to the successful data storage of the first data. The at least one second request is used to request second data, which is the difference between the firmware data and the first data.

[0017] The second data storage module is used to store the second data in response to obtaining a second response corresponding to the at least one second request.

[0018] On the other hand, embodiments of this application provide a computer-readable storage medium storing at least one instruction or at least one program, wherein the at least one instruction or at least one program is loaded and executed by a processor to implement the aforementioned firmware data processing method.

[0019] On the other hand, embodiments of this application provide an electronic device, including at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the at least one processor implements the aforementioned firmware data processing method by executing the instructions stored in the memory.

[0020] On the other hand, embodiments of this application provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement the aforementioned firmware data processing method.

[0021] This application provides a firmware data processing method, apparatus, storage medium, and device. The method provided reduces the amount of firmware data processed per batch by requesting firmware data in batches. The storage space used for processing firmware data each time can be reused. Furthermore, firmware data can be directly parsed in the AT framework buffer, eliminating the need to copy the firmware data to the corresponding application buffer on the terminal device, further saving storage resources and improving firmware data processing speed. Attached Figure Description

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

[0023] Figure 1 This is a schematic diagram of a firmware upgrade method based on the related technology provided in the embodiments of this application;

[0024] Figure 2 This is a schematic diagram of a feasible implementation framework for the firmware data processing method provided in the embodiments of this application;

[0025] Figure 3 This is a flowchart of the firmware data processing method provided in the embodiments of this application;

[0026] Figure 4 This is a schematic diagram illustrating the changes in the first and second position marks provided in the embodiments of this application;

[0027] Figure 5 This is a schematic diagram of the firmware data processing method provided in the embodiments of this application;

[0028] Figure 6 This is a schematic diagram of the firmware data processing sequence provided in the embodiments of this application;

[0029] Figure 7 This is a schematic diagram illustrating the stages of firmware upgrade provided in an embodiment of this application;

[0030] Figure 8 This is a block diagram of the firmware data processing apparatus provided in the embodiments of this application;

[0031] Figure 9 This is a schematic diagram of the hardware structure of a device for implementing the method provided in the embodiments of this application. Detailed Implementation

[0032] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the embodiments of this application.

[0033] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of the embodiments of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the present application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices.

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

[0035] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "multiple" means two or more. To facilitate understanding of the above-described technical solutions and their resulting technical effects in the embodiments of this application, the embodiments of this application first explain the relevant technical terms:

[0036] AT commands: AT commands are used for connection and communication between terminal devices and firmware modules. AT stands for Attention. Each AT command line can contain only one AT command; for AT command transmission, in addition to the two AT characters, a maximum length of 1056 characters (including the final null character) can be received.

[0037] AT module: A module that interacts with terminal devices based on AT commands, that is, a module that supports AT commands.

[0038] AT Framework: A framework that shields the differences between underlying AT modules and provides network read / write interfaces for the application layer. It can be used with AT modules and can be considered as an AT module adaptation layer located above the underlying driver (AT module) of the terminal device.

[0039] HTTP (Hypertext Transfer Protocol) is a simple request-response protocol that typically runs on top of the Transmission Control Protocol (TCP). It specifies what messages a client might send to a server and what responses it might receive. The headers of request and response messages are given in ASCII (American Standard Code for Information Interchange) format.

[0040] HTTP fragmentation: A communication protocol based on the HTTP protocol that enables data to be retrieved in fragments.

[0041] EEPROM: Electrically Erasable Programmable Read-Only Memory, is a type of memory chip that retains data even when power is off. EEPROMs can be erased and reprogrammed on a computer or dedicated device. They are typically used in plug-and-play applications.

[0042] FLASH: FLASH is a type of memory chip that allows data to be modified through a specific program. In the electronics and semiconductor fields, FLASH often refers to flash memory. Flash memory combines the advantages of read-only memory (ROM) and random access memory (RAM), possessing not only the performance of electronically erasable programmable memory (EEPROM) but also the ability to quickly read data, ensuring that data is not lost due to power outages.

[0043] Zero-copy firmware upgrade: After receiving the firmware data, the firmware data can be processed directly to upgrade the firmware without copying it separately. This is the technical effect achieved by the solution provided in this application.

[0044] Firmware, also known as firmware, is the program written into memory. Firmware refers to the device "driver" stored inside a device. Through firmware, the operating system can implement specific machine operations according to standard device drivers; for example, optical drives and CD burners all have internal firmware. Firmware is the software that performs the most basic and lowest-level work of a system. In hardware devices, firmware is the soul of the hardware device, because some hardware devices have no other software components besides firmware. Therefore, firmware, to a certain extent, determines the functionality and performance of the hardware device.

[0045] MQTT stands for Message Queuing Telemetry Transport. It is a publish / subscribe messaging protocol based on the ISO standard (ISO / IEC PRF 20922). It is designed for remote devices with low hardware performance and poor network conditions.

[0046] In related technologies, firmware upgrades for terminal devices primarily involve requesting firmware via HTTP. Data is sent from the HTTP server to the AT module, which caches the data in the AT framework's buffer. The terminal device then copies the data from the buffer to the corresponding application buffer of the AT module, parses the data in the application buffer, and finally burns it into the FLASH memory. Please refer to [link / reference]. Figure 1 This diagram illustrates a firmware upgrade method according to an embodiment of this application. An HTTP server stores the data required for firmware upgrades. An IoT device (terminal device) requests the firmware data needed for the upgrade from the HTTP server. After the HTTP server sends the firmware data to the IoT device, the IoT device stores the firmware data in the AT framework's buffer (at buffer). Then, this data is copied from the at buffer to the corresponding application buffer (application buffer). Only then can the data be parsed in the application buffer and burned into the FLASH memory. Of course, in some embodiments, the parsed data can also be stored in a different memory than FLASH, undergo secondary transmission, or be processed in other ways. This application does not limit this.

[0047] This firmware upgrade method directly pulls firmware data via HTTP and uses the common AT framework, passively receiving the firmware data for the upgrade. The terminal device needs to use additional computing resources to copy the firmware data and then allocate additional application buffer space to store it, resulting in high storage and performance costs. Firstly, directly requesting firmware via HTTP can result in large amounts of data, which resource-constrained terminal devices may not be able to provide enough storage space, potentially leading to data loss or even upgrade failure. Requesting a large cache poses a significant challenge to the memory of resource-constrained devices. Secondly, related technologies require at least one copy of the data from the AT framework's buffer to the corresponding application buffer in the firmware upgrade process, further consuming storage resources and degrading performance.

[0048] Of course, the drawbacks of the above firmware upgrade method also exist in other firmware-related operations such as firmware download and firmware upload. In other words, the above problems may exist in various scenarios of firmware data interaction with other devices.

[0049] To reduce storage resource consumption and improve firmware data interaction performance during firmware data exchange, this application provides a firmware data processing method. This method requests firmware data in batches, reducing the amount of firmware data processed per transaction. The storage space used for processing firmware data each time can be reused, significantly reducing the storage space requirements of the terminal device during firmware data exchange. This allows terminal devices with limited storage space to participate in firmware data exchange processes with larger data volumes, eliminating the bottleneck of storage space constraints. Furthermore, by optimizing the processing details of firmware data, firmware data can be directly parsed in the AT framework buffer, eliminating the need to copy firmware data to the corresponding application buffer on the terminal device, further saving storage resources and improving firmware data processing speed.

[0050] This application's embodiments may involve cloud technology and cloud gaming. Cloud technology refers to a hosting technology that unifies hardware, software, network, and other resources within a wide area network (WAN) or local area network (LAN) to achieve data computation, storage, processing, and sharing. Cloud technology is a general term for network technology, information technology, integration technology, management platform technology, and application technology applied based on the cloud computing business model. It can form resource pools, be used on demand, and is flexible and convenient. Cloud computing technology will become an important support. The backend services of technical network systems require a large amount of computing and storage resources, such as video websites, image websites, and many portal websites. With the rapid development and application of the Internet industry, in the future, every item may have its own identification mark, which needs to be transmitted to the backend system for logical processing. Data of different levels will be processed separately, and various industry data will all require strong system support, which can only be achieved through cloud computing. Cloud gaming is an online gaming technology based on cloud computing technology. Cloud gaming technology enables lightweight devices with relatively limited graphics processing and data computing capabilities to run high-quality games. Based on cloud gaming, game on-demand or game live streaming can be performed.

[0051] The methods provided in this application embodiment can also involve blockchain, meaning that the methods provided in this application embodiment can be implemented based on blockchain, or the data involved in the methods provided in this application embodiment can be stored based on blockchain, or the executing entity of the methods provided in this application embodiment can be located in blockchain. Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include a blockchain underlying platform, a platform product service layer, and an application service layer.

[0052] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operational monitoring. The user management module is responsible for managing the identity information of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between user real identities and blockchain addresses (access management). Furthermore, under authorization, it monitors and audits transactions of certain real identities and provides risk control rule configuration (risk control audit). The basic services module is deployed on all blockchain node devices to verify the validity of business requests. After consensus is reached on valid requests, they are recorded in storage. For a new business request, the basic services first perform interface adaptation parsing and authentication (interface adaptation), and then encrypt the business information through a consensus algorithm (consensus management). After encryption, the data is transmitted completely and consistently to the shared ledger (network communication) and recorded and stored. The smart contract module is responsible for contract registration, issuance, triggering, and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). According to the contract terms, the key or other events are invoked to trigger execution and complete the contract logic. It also provides functions for contract upgrades and cancellations. The operation monitoring module is mainly responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time status visualization output during product release, such as alarms, monitoring network conditions, and monitoring the health status of node devices.

[0053] The platform's product service layer provides the basic capabilities and implementation frameworks for typical applications. Developers can leverage these basic capabilities, along with the specific characteristics of their business needs, to implement blockchain-based business logic. The application service layer provides blockchain-based application services to business stakeholders.

[0054] Please see Figure 2 , Figure 2 This is a schematic diagram illustrating a feasible implementation framework for the firmware data processing method provided in the embodiments of this specification, such as... Figure 2 As shown, this implementation framework may include at least a terminal device 01, a firmware data management server 02, and a firmware data storage server 03. The terminal device 01 can be a device located in the Internet of Things (IoT) and can provide users with various optional IoT-based services, each of which can be deployed in the firmware. The terminal device 01 includes, but is not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, and in-vehicle terminals. This invention can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, assisted driving, video media, and instant messaging.

[0055] Firmware data management server 02 is used to manage firmware data. For example, it can manage the storage address of firmware data in firmware data storage server 03, as well as the data volume, version number, summary information, developer information, development logs, test records, download count, download records, etc. Firmware data storage server 03 is used to store firmware data, and the storage location of firmware data on firmware data storage server 03 is recorded in firmware data management server 02.

[0056] The terminal device can obtain the storage address and total data volume of the firmware data by interacting with the firmware management server 02. Based on the storage address and total data volume, it can request firmware data from the firmware data storage server 03. By optimizing the process of requesting firmware data from the firmware data storage server 03 and the process of processing firmware data, storage resource consumption can be reduced and firmware data processing speed can be improved.

[0057] The following describes a firmware data processing method according to an embodiment of this application. Figure 3 This diagram illustrates a flowchart of a firmware data processing method according to an embodiment of this application. The embodiment provides the method operation steps described in the embodiments or flowchart, but based on conventional or non-inventive methods, more or fewer operation steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual systems, terminal devices, or server products, the method can be executed sequentially according to the embodiments or drawings, or in parallel (e.g., in a parallel processor or multi-threaded processing environment). The above method may include:

[0058] S101. In response to the firmware data processing request, obtain a first address and a first parameter, wherein the first address represents the storage address of the firmware data on the server, and the first parameter represents the total amount of firmware data.

[0059] This application does not limit the processing method of firmware data processing requests in its embodiments. In one embodiment, a user can trigger a firmware data processing request through the human-computer interaction interface of a terminal device. In another embodiment, the firmware data processing request can also be sent to the terminal device by another device and obtained by the terminal device. This other device can be a terminal device or a server used to control firmware data processing, for example, in... Figure 2 In the implementation framework shown, the server can be firmware data management server 02.

[0060] The embodiments of this application do not limit the content of the firmware data processing request. In one embodiment, the firmware data processing request may include a firmware data identifier or a firmware data version number. The content in the firmware data processing request can be used to uniquely determine the data that the terminal device needs to obtain from the firmware storage server.

[0061] In one embodiment, the aforementioned first address and the aforementioned first parameter can be carried by the aforementioned firmware data processing request; in another embodiment, Figure 2 Under the illustrated implementation framework, in this embodiment of the application, terminal device 01 can obtain a first address and a first parameter returned by firmware data management server 02 by sending a firmware data query request to firmware data management server 02. The first address is the storage address of firmware data in firmware data storage server 03. Of course, the firmware data query request can be generated based on the content of a firmware data processing request. For example, if the firmware data processing request includes the firmware data identifier and version number, then the firmware data query request can be generated based on the firmware data identifier and version number and the network address of the terminal device, so that firmware data management server 02 returns the first address and the first parameter.

[0062] S102. Obtain the second parameter, which represents the amount of firmware data requested for the first time, and the second parameter is less than the first parameter.

[0063] Unlike related technologies that request all firmware data at once, this application reduces the amount of firmware data requested in a single batch. The size of the second parameter in this application can be preset or automatically calculated based on the first parameter. For example, a total batch number can be set, and the second parameter can be calculated based on the total batch number and the first parameter. For instance, if the total batch number is 10 and the first parameter is 100KB, then the second parameter is 10KB. Because the second parameter is smaller than the first parameter, this embodiment requires at least two requests to the firmware data storage server 03 to obtain all the firmware data.

[0064] S103. Based on the first address and the second parameter, generate and send a first request to the server. The first request is used to obtain first data, which is data in the firmware data whose data volume is equal to the second parameter.

[0065] In this embodiment, the first request sent to the firmware data storage server 03 is a first request to obtain the firmware data corresponding to the second parameter. For example, the firmware data pointed to by the first address occupies 100KB of storage space, and the first data can be the first 10KB of data in this storage space. The first address corresponds to the storage address of the firmware data. Based on the first address, the first request can be sent to the server, triggering the server to read the firmware data from the location pointed to by the first address and send it back to the terminal device.

[0066] S104. In response to obtaining the first response corresponding to the first request, store the first data.

[0067] After the firmware data storage server 03 sends out a first response, the terminal device 01 can store the first data in the first response. In related technologies, after the terminal device obtains the firmware data, it first stores the firmware data in the buffer of the AT framework, then copies the firmware data to the application buffer corresponding to the firmware, and only then can the firmware data be parsed and stored in the application buffer. In this embodiment of the application, the above process is improved to increase the processing speed of firmware data and reduce storage resource consumption.

[0068] The terminal device in this embodiment is a firmware data processing device, including a firmware instruction adaptation component and a firmware storage component. The firmware instruction adaptation component also functions as the AT framework in related technologies, that is, it is used to shield the differences between different firmware, and the firmware storage component is used to store the parsing results of the firmware data.

[0069] In this embodiment, in response to receiving a first response corresponding to the first request, the first data is stored in a first region, which is a storage region within the firmware instruction adaptation component. The data in the first region is parsed, and the parsing result is stored in a second region, which is a storage region within the firmware storage component. In other words, the data in the firmware instruction adaptation component can be directly parsed, and the parsing result can be directly stored without needing to copy the firmware data.

[0070] In response to receiving the first response corresponding to the first request, storing the first data in the first region includes:

[0071] S201. In response to the acquisition of the first data packet, a first location marker is acquired, wherein the first location marker points to the starting position of the available area of ​​the first region for storing the firmware data, and the first data packet is a data packet carrying the data corresponding to the first response.

[0072] S202. Store the first data packet in the first region according to the first location marker, and update the second location marker, wherein the second location marker points to the end of the region in the first region where the firmware data is stored.

[0073] S203. Update the first position mark according to the second position mark.

[0074] In one embodiment, the acquired data packets can be stored sequentially, in which case the first position marker points to the next storage location corresponding to the second position marker.

[0075] S204. In response to the acquisition of a second data packet, the first position marker is acquired, wherein the second data packet is the next data packet after the first data packet.

[0076] S205. Store the second data packet in the first area according to the first location marker, and update the second location marker.

[0077] In this embodiment, the number of data packets used to transmit the data in the first response is not limited. Taking two data packets as an example, the data storage server 03 sends data packet 1 and data packet 2 to the terminal device 01. Data packet 1 is the first data packet, and data packet 2 is the second data packet. Figure 4 The diagram illustrates the changes in the first and second location markers. In response to the acquisition of data packet 1, the first location marker is acquired. In one embodiment, the first location marker can be acquired directly, pointing to the starting address of the remaining space in the first region. In another embodiment, since data packet 1 is the first data packet acquired in response to firmware data processing instructions, if the first region was initialized before acquiring this data packet, the first location marker points to the starting address of the first region.

[0078] Figure 4 Figure (1) shows the positions of the first position marker 100 and the second position marker 200 before data packet 1 is acquired. Figure 4 Figure (2) shows the positions of the first position marker 100 and the second position marker 200 after data packet 1 is acquired. Obviously, the data in data packet 1 occupies 3 storage locations.

[0079] After data packet 2 arrives, the first position marker can be updated according to the second position marker, and data packet 2 can be stored in the first area according to the first position marker, while the second position marker is updated. The data in data packet 1 occupies... Figure 4 In the first three positions of (2), the second position mark points to the third storage position, and data packet 2 should be stored starting from the fourth storage position. Figure 4Figure (3) shows the positions of the first position marker 100 and the second position marker 200 after data packet 2 is acquired. Obviously, the data in data packet 2 occupies two storage locations.

[0080] In one embodiment, parsing the data in the first region and storing the parsing result in the second region includes: in response to successfully storing the first data packet, parsing the first data packet, storing the parsing result corresponding to the first data packet in the second region, and releasing the storage space corresponding to the first data packet in the first region. Continuing with the above example... Figure 4 (4) shows the positions of the first position mark 100 and the second position mark 200 after the data packet 1 is parsed and stored. After the data packet 1 is successfully stored, the terminal device 01 can parse its corresponding data and store it in the second area. The storage position of the data packet 1 in the first area is released so that it can be reused later.

[0081] S105. In response to the successful storage of the first data, generate and send at least one second request to the server, wherein the at least one second request is used to request second data, wherein the second data is the difference between the firmware data and the first data.

[0082] In this application, firmware data can be requested in multiple batches. Taking 10 requests as an example, the first request corresponds to the first request in step S103, and the remaining 9 requests are all second requests. Obviously, the first and second requests are used to request firmware data in batches. The batch requests can be generated based on existing fragmentation communication protocols or custom communication protocols. This application does not limit this.

[0083] In one embodiment, generating and sending at least one second request to the server in response to the successful storage of the first data includes: obtaining a third parameter, which represents the amount of firmware data to be requested in the next request, in response to the successful storage of the first data; generating and sending the at least one second request to the server based on the first address and the third parameter; and storing the data in the second response in response to obtaining a second response corresponding to the second request. Further, generating and sending the at least one second request to the server based on the first address and the third parameter includes: generating and sending the second request to the server based on the first address and the third parameter; storing the data in the response corresponding to the second request in response to obtaining a response corresponding to the second request; and in response to successfully storing the data in the response corresponding to the second request but before all the second data has been obtained, obtaining a third parameter, which represents the amount of firmware data to be requested in the next request, and repeating the operation of generating and sending the second request to the server based on the first address and the third parameter until all the second data has been obtained.

[0084] For example, if the second data is 25KB, after the first data is acquired, a third parameter (10KB) can be obtained. Based on the first address and the third parameter, a second request is generated and sent to the server, thus obtaining 10KB of the second data. In this case, the second data is not yet fully acquired, so the third parameter (also 10KB) can be acquired. Again, based on the first address and the third parameter, a second request is generated and sent to the server, obtaining another 10KB of the second data. In this case, the server has transmitted a total of 20KB of the second data. The second data is still not fully acquired, so the third parameter (only 5KB) can be acquired. Again, based on the first address and the third parameter, a second request is generated and sent to the server, obtaining another 5KB of the second data. At this point, the server has transmitted a total of 25KB of the second data, and the acquisition of the second data is complete. The operation of acquiring the third parameter and sending the second request then stops.

[0085] In one embodiment, the third parameter obtained each time can be the same as or different from the second parameter. For example, if the first parameter is 99KB, and the firmware data is obtained in 10 parts, the first 9 parts can each obtain 10KB of firmware data, and the last part can obtain 9KB of firmware data.

[0086] S106. In response to obtaining a second response corresponding to the at least one second request, store the second data.

[0087] In this embodiment of the application, in response to receiving a response to the second request, the data in the response to the second request is stored in the first area; the data in the first area is parsed, and the parsing result is stored in the second area. The process of parsing and storing the data in the response to the second request is the same as the approach of parsing and storing the data in the first response described above, and will not be repeated here.

[0088] Please refer to Figure 5 This diagram illustrates a firmware data processing method in an embodiment of this application. IoT devices can retrieve firmware data by sending requests in batches and store it in the storage space of the firmware instruction adapter component. The data in the storage space can be directly read, parsed, and stored. The storage result can be burned into FLASH, or used to update or add firmware. This method is particularly suitable for resource-constrained devices, significantly reducing storage resource consumption and improving performance. For example, if an IoT device is an STM32F10 microcontroller with only 62KB of memory, and the total firmware data is 100KB, according to related technologies, sending one HTTP request could result in a maximum of 100KB of data on the other end. The device's memory is clearly insufficient to meet this requirement, potentially preventing firmware upgrades. Using the method in this embodiment, only about 10KB of data can be retrieved each time, which is sufficient for the device's memory and allows for successful firmware upgrades. Furthermore, in related technologies, after acquiring and storing firmware data in the AT framework, at least one data copy is required, consuming an additional 100KB of storage resources. This embodiment eliminates the need for data copying, saving storage resources in the application buffer.

[0089] Please refer to Figure 6 This diagram illustrates the sequence of firmware data processing in an embodiment of this application. Terminal device 01 communicates with firmware data management server 02 and firmware data storage server 03 via an AT module. Terminal device 01 requests a first address and first parameters from firmware data management server 02 by sending an MQTT message. Then, terminal device 01 requests firmware data from firmware data storage server 03 in batches according to the first address. After a successful upgrade, the upgrade result can be fed back to firmware data management server 02 so that firmware data management server 02 can record the upgrade status. Each time firmware data fed back by firmware storage server 03 reaches the AT module, it can notify terminal device 01 via a serial terminal and be stored in the storage space of the firmware instruction adapter component of terminal device 01.

[0090] In this embodiment, the parsed and stored firmware data can be directly burned into the FLASH memory or used to update the firmware. Please refer to... Figure 7This diagram illustrates the stages of firmware upgrade in this embodiment. Upon receiving a firmware upgrade request, firmware data is requested in batches, and then burned after the data is acquired in batches.

[0091] This application provides a firmware data processing method. This method reduces the amount of firmware data processed per batch by requesting firmware data in batches. The storage space used for processing firmware data each time can be reused. Furthermore, firmware data can be parsed directly in the AT framework buffer, eliminating the need to copy the firmware data to the corresponding application buffer on the terminal device, further saving storage resources and improving firmware data processing speed. This application effectively saves memory for resource-constrained devices and improves the overall efficiency of Over-the-Air (OTA) downloads, making it highly suitable for IoT scenarios.

[0092] Please refer to Figure 8 This diagram illustrates a block diagram of a firmware data processing apparatus according to this embodiment, the apparatus comprising:

[0093] Parameter acquisition request 101 is used to respond to firmware data processing request and acquire a first address and a first parameter. The first address represents the storage address of the firmware data on the server, and the first parameter represents the total amount of firmware data.

[0094] The second parameter acquisition module 102 is used to acquire a second parameter, which represents the amount of firmware data requested for the first time, and the second parameter is less than the first parameter.

[0095] The first data processing module 103 is used to generate and send a first request to the server based on the first address and the second parameter. The first request is used to obtain first data, which is data in the firmware data whose data volume is equal to the second parameter.

[0096] The first data storage module 104 is used to store the first data in response to obtaining the first response corresponding to the first request.

[0097] The second data processing module 105 is used to generate and send at least one second request to the server in response to the successful storage of the first data. The at least one second request is used to request second data, which is the difference between the firmware data and the first data.

[0098] The second data storage module 106 is used to store the aforementioned second data.

[0099] In one embodiment, the second data processing module described above is configured to perform the following operations;

[0100] In response to the successful data storage of the first data, a third parameter is obtained, which represents the amount of firmware data requested in the next request.

[0101] Based on the first address and the third parameter, generate and send at least one second request to the server.

[0102] In response to obtaining the second response corresponding to the second request, the data in the second response is stored.

[0103] In one embodiment, the second data processing module is further configured to perform the following operations:

[0104] Based on the first address and the third parameter, generate and send the second request to the server.

[0105] In response to receiving a response to the second request, the data in the response to the second request is stored.

[0106] In response to the situation where the data in the response corresponding to the second request is successfully stored but the second data has not been fully acquired, the operation of acquiring the third parameter, which represents the amount of firmware data in the next request, and repeating the operation of generating and sending the second request to the server based on the first address and the third parameter are performed.

[0107] In one embodiment, the first data storage module described above is configured to perform the following operations:

[0108] In response to obtaining the first response corresponding to the first request, the first data is stored in the first region, which is the storage region in the firmware instruction adaptation component.

[0109] The data in the first region is parsed, and the parsing results are stored in the second region, which is the storage region in the firmware storage component.

[0110] The second data storage module described above is used to perform the following operations:

[0111] In response to receiving a response to the second request, the data in the response to the second request is stored in the first area.

[0112] The data in the first region is parsed, and the parsing results are stored in the second region.

[0113] In one embodiment, the first data storage module described above is configured to perform the following operations:

[0114] In response to the acquisition of the first data packet, a first location marker is acquired, the first location marker pointing to the starting position of the available area of ​​the first region for storing the firmware data, and the first data packet is a data packet carrying the data corresponding to the first response;

[0115] The first data packet is stored in the first region according to the first location marker, and the second location marker is updated, with the second location marker pointing to the end of the region in the first region where the firmware data is stored.

[0116] Update the first position marker according to the second position marker;

[0117] In response to the acquisition of a second data packet, the aforementioned first position marker is acquired, wherein the second data packet is the next data packet following the first data packet;

[0118] The second data packet is stored in the first area according to the first location marker, and the second location marker is updated.

[0119] In one embodiment, the first data storage module is further configured to perform the following operations:

[0120] In response to the successful storage of the first data packet, the first data packet is parsed, and the parsing result corresponding to the first data packet is stored in the second area, while the storage space corresponding to the first data packet in the first area is released.

[0121] In one embodiment, the device further includes a firmware processing module for updating or burning firmware based on the first data and the second data.

[0122] Specifically, the firmware data processing apparatus disclosed in this application and the corresponding method embodiments described above are both based on the same inventive concept. For details, please refer to the method embodiments, which will not be repeated here.

[0123] This application also provides a firmware data processing system, including a terminal device, a firmware data management server, and a firmware data storage server. The terminal device includes the aforementioned firmware data processing device. The firmware data management server and firmware data storage server have been described above and will not be repeated here.

[0124] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the firmware data processing method described above.

[0125] This application also provides a computer-readable storage medium that can store multiple instructions. These instructions are adaptable for a processor to load and execute the firmware data processing method described in this application.

[0126] In one embodiment, the firmware data processing method described above includes:

[0127] In response to a firmware data processing request, a first address and a first parameter are obtained, wherein the first address represents the storage address of the firmware data on the server, and the first parameter represents the total amount of firmware data.

[0128] Obtain the second parameter, which represents the amount of firmware data requested in the first request, and the second parameter is less than the first parameter.

[0129] Based on the first address and the second parameter, a first request is generated and sent to the server. The first request is used to obtain first data, which is data in the firmware data whose data volume is equal to the second parameter.

[0130] In response to obtaining the first response corresponding to the first request, the first data is stored.

[0131] In response to the successful data storage of the first data, at least one second request is generated and sent to the server. The at least one second request is used to request second data, which is the difference between the firmware data and the first data.

[0132] Store the second data mentioned above.

[0133] In another embodiment, in response to the successful storage of the first data, generating and sending at least one second request to the server includes:

[0134] In response to the successful data storage of the first data, a third parameter is obtained, which represents the amount of firmware data requested in the next request.

[0135] Based on the first address and the third parameter, generate and send at least one second request to the server.

[0136] In response to obtaining the second response corresponding to the second request, the data in the second response is stored.

[0137] In another embodiment, generating and sending at least one second request to the server based on the first address and the third parameter includes:

[0138] Based on the first address and the third parameter, generate and send the second request to the server.

[0139] In response to receiving a response to the second request, the data in the response to the second request is stored.

[0140] In response to the situation where the data in the response corresponding to the second request is successfully stored but the second data has not been fully acquired, the operation of acquiring the third parameter, which represents the amount of firmware data in the next request, and repeating the operation of generating and sending the second request to the server based on the first address and the third parameter are performed.

[0141] In another embodiment, the above method is applied to a firmware data processing device, which includes a firmware instruction adaptation component and a firmware storage component. In response to obtaining a first response corresponding to the first request, storing the first data includes:

[0142] In response to obtaining the first response corresponding to the first request, the first data is stored in the first region, which is the storage region in the firmware instruction adaptation component.

[0143] The data in the first region is parsed, and the parsing results are stored in the second region, which is the storage region in the firmware storage component.

[0144] In the case of receiving a second response corresponding to the second request, the data in the second response is stored, including:

[0145] In response to receiving a response to the second request, the data in the response to the second request is stored in the first area;

[0146] The data in the first region is parsed, and the parsing results are stored in the second region.

[0147] In another embodiment, in response to obtaining the first response corresponding to the first request, storing the first data in the first region includes:

[0148] In response to the acquisition of the first data packet, a first location marker is acquired, the first location marker pointing to the starting position of the available area of ​​the first region for storing the firmware data, and the first data packet is a data packet carrying the data corresponding to the first response;

[0149] The first data packet is stored in the first region according to the first location marker, and the second location marker is updated, with the second location marker pointing to the end of the region in the first region where the firmware data is stored.

[0150] Update the first position marker according to the second position marker;

[0151] In response to the acquisition of a second data packet, the aforementioned first position marker is acquired, wherein the second data packet is the next data packet following the first data packet;

[0152] The second data packet is stored in the first area according to the first location marker, and the second location marker is updated.

[0153] In another embodiment, parsing the data in the first region and storing the parsing result in the second region includes:

[0154] In response to the successful storage of the first data packet, the first data packet is parsed, and the parsing result corresponding to the first data packet is stored in the second area, while the storage space corresponding to the first data packet in the first area is released.

[0155] In another embodiment, the above method further includes:

[0156] Perform firmware updates or firmware burning based on the first and second data mentioned above.

[0157] Furthermore, Figure 9 A schematic diagram of a hardware structure for implementing the method provided in the embodiments of this application is shown. This device can participate in or include the apparatus or system provided in the embodiments of this application. Figure 9 As shown, device 10 may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 9 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, device 10 may also include a... Figure 9 The more or fewer components shown, or having the same Figure 9 The different configurations shown.

[0158] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the device 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0159] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the method described in the embodiments of this application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the firmware data processing method described above. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the device 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0160] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of device 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a radio frequency (RF) module used for wireless communication with the Internet.

[0161] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows a user to interact with the user interface of device 10 (or a mobile device).

[0162] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

[0163] The embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and server embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0164] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0165] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present application should be included within the protection scope of the present application.

Claims

1. A firmware data processing method, characterized in that, The method includes: In response to a firmware data processing request, a first address and a first parameter are obtained, wherein the first address represents the storage address of the firmware data on the server, and the first parameter represents the total amount of firmware data. Obtain the second parameter, which represents the amount of firmware data requested in the first request, and the second parameter is less than the first parameter; Based on the first address and the second parameter, a first request is generated and sent to the server. The first request is used to obtain first data, which is data in the firmware data whose data volume is equal to the second parameter. In response to obtaining the first response corresponding to the first request, the first data is stored; In response to the successful data storage of the first data, at least one second request is generated and sent to the server, the at least one second request being used to request second data, the second data being the difference between the firmware data and the first data; In response to receiving a second response corresponding to the at least one second request, the second data is stored.

2. The method according to claim 1, characterized in that, In response to the successful data storage of the first data, generating and sending at least one second request to the server includes: In response to the successful data storage of the first data, a third parameter is obtained, wherein the third parameter represents the amount of firmware data requested in the next request; Based on the first address and the third parameter, generate and send the at least one second request to the server; In response to receiving a second response corresponding to the second request, the data in the second response is stored.

3. The method according to claim 2, characterized in that, The step of generating and sending the at least one second request to the server based on the first address and the third parameter includes: Based on the first address and the third parameter, generate and send the second request to the server; In response to receiving a response to the second request, the data in the response to the second request is stored; In response to the situation where the data in the response corresponding to the second request is successfully stored but the second data has not been fully acquired, the operation of acquiring a third parameter, the third parameter representing the amount of firmware data in the next request, and repeating the operation of generating and sending the second request to the server based on the first address and the third parameter are performed.

4. The method according to any one of claims 1 to 3, characterized in that, The method is applied to a firmware data processing device, which includes a firmware instruction adaptation component and a firmware storage component. The step of storing the first data in response to receiving a first response corresponding to the first request includes: In response to receiving a first response corresponding to the first request, the first data is stored in a first region, where the first region is a storage region in the firmware instruction adaptation component. The data in the first region is parsed, and the parsing result is stored in the second region, which is the storage region in the firmware storage component; In response to receiving a second response corresponding to the second request, the data in the second response is stored, including: In response to receiving a response to the second request, the data in the response to the second request is stored in the first area; The data in the first region is parsed, and the parsing results are stored in the second region.

5. The method according to claim 4, characterized in that, In response to receiving a first response corresponding to the first request, storing the first data in a first region includes: In response to the acquisition of the first data packet, a first location marker is acquired, the first location marker pointing to the starting position of the available area of ​​the first region for storing firmware data, and the first data packet is a data packet carrying the data corresponding to the first response; The first data packet is stored in the first region according to the first location marker, and the second location marker is updated, the second location marker pointing to the end of the region in the first region where the firmware data is stored; Update the first position marker according to the second position marker; In response to the acquisition of a second data packet, the first location marker is acquired, wherein the second data packet is the next data packet after the first data packet; The second data packet is stored in the first area according to the first location marker, and the second location marker is updated.

6. The method according to claim 5, characterized in that, The step of parsing the data in the first region and storing the parsing results in the second region includes: In response to the successful storage of the first data packet, the first data packet is parsed, and the parsing result corresponding to the first data packet is stored in the second area, while the storage space corresponding to the first data packet in the first area is released.

7. The method according to claim 1, characterized in that, The method further includes: Perform firmware updates or firmware burning based on the first and second data.

8. A firmware data processing device, characterized in that, The device includes: A parameter acquisition request is used to respond to a firmware data processing request and acquire a first address and a first parameter, wherein the first address represents the storage address of the firmware data on the server and the first parameter represents the total amount of firmware data. The second parameter acquisition module is used to acquire a second parameter, which represents the amount of firmware data requested for the first time, and the second parameter is less than the first parameter. The first data processing module is configured to generate and send a first request to the server based on the first address and the second parameter. The first request is used to obtain first data, which is data in the firmware data whose data volume is equal to the second parameter. The first data storage module is used to store the first data in response to obtaining the first response corresponding to the first request; The second data processing module is configured to generate and send at least one second request to the server in response to the successful data storage of the first data. The at least one second request is used to request second data, which is the difference between the firmware data and the first data. The second data storage module is used to store the second data in response to obtaining a second response corresponding to the at least one second request.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction or at least one program, which is loaded and executed by a processor to implement a firmware data processing method as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, The system includes at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the at least one processor implements a firmware data processing method as described in any one of claims 1 to 7 by executing the instructions stored in the memory.

11. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by the processor, they implement a firmware data processing method according to any one of claims 1 to 7.

Images