Return value sending method and device, storage medium and electronic equipment

By using remote procedure call protocol (RPC) as a unified interface between the functional device and the master control device, the problem that different hardware interfaces in the prior art require their respective design of transmission protocols is solved, and the effect of simplifying development and reducing transmission complexity is achieved.

CN119829096APending Publication Date: 2025-04-15QINGDAO HAIER INTELLIGENT HOME APPLIANCE TECHNOLOGY CO LTD +1
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411929470.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-12-25
Publication Date
2025-04-15

AI Technical Summary

Technical Problem

In the prior art, it is necessary to formulate and implement their respective application transmission protocols for different hardware interfaces, resulting in higher transmission complexity.

Method used

By using the Remote Procedure Call Protocol (RPC) as a unified interface, the update data transmission and processing between the functional device and the master device is realized, avoiding the complexity of designing and implementing the application transmission protocol for each hardware interface separately.

Benefits of technology

Simplifies the development and maintenance process, reduces transmission complexity, and improves the efficiency and reliability of OTA functions.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119829096A_ABST
    Figure CN119829096A_ABST
Patent Text Reader

Abstract

The invention discloses a return value sending method and device, a storage medium and electronic equipment, and relates to the technical field of smart home, the return value sending method comprises the following steps: under the condition that a target program of functional equipment is to be updated, receiving update data sent by main control equipment through a first interface, the first interface is an interface of a remote procedure call protocol type; verifying the updated data to determine a first verification result of the updated data; under the condition that the first verification result indicates that the update data passes verification, a first return value is sent to the main control equipment through the first interface, and the target program is updated according to the update data; and under the condition that the first verification result indicates that the update data does not pass the verification, sending a second return value to the main control equipment through the first interface.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of smart home technology, and more specifically, to a method and device for sending a return value, a storage medium, and an electronic device. Background Art

[0002] In the current field of embedded devices, Over-the-air (OTA) technology has become a key means to achieve remote upgrades and maintenance of devices. With the increasing functionality of devices, the main control device often needs to connect and manage different types of peripherals through a variety of hardware interfaces (such as UART, USB, SDIO, etc.). These peripherals may include sensors, actuators, or other modules with independent functions, and their roles and functions in the system are different. For the implementation of OTA functions, the traditional method is to design and implement a set of application transmission protocols for each hardware interface separately for information and data exchange between devices.

[0003] Although this approach can meet the specific needs of different interfaces, it also brings significant complexity and development costs. First, the protocol design of each interface needs to fully consider its physical characteristics, such as transmission speed, data format, and exception handling mechanism, which requires developers to have a deep understanding of each hardware interface.

[0004] Therefore, although the method of separately formulating and implementing application transmission protocols for different hardware interfaces in the prior art can ensure the accuracy of communication between devices, it also significantly increases the complexity and cost of OTA function development.

[0005] In the related technologies, it is necessary to formulate and implement respective application transmission protocols for different hardware interfaces, which leads to the problem of high transmission complexity. No effective solution has been proposed yet. Summary of the invention

[0006] The embodiments of the present application provide a method and device for sending a return value, a storage medium, and an electronic device, so as to at least solve the problem in the related art that it is necessary to formulate and implement respective application transmission protocols for different hardware interfaces, resulting in high transmission complexity.

[0007] According to an embodiment of the embodiments of the present application, a method for sending a return value is provided, including: when a target program of a functional device is to be updated, receiving update data sent by a main control device through a first interface, wherein the first interface is an interface of a remote procedure call protocol type; verifying the update data to determine a first verification result of the update data; when the first verification result indicates that the update data passes the verification, sending a first return value to the main control device through the first interface, and updating the target program according to the update data; when the first verification result indicates that the update data fails the verification, sending a second return value to the main control device through the first interface.

[0008] In an exemplary embodiment, receiving update data sent by a master control device through a first interface includes: receiving multiple data packets sent by the master control device through the first interface, wherein each data packet carries sub-update data, an offset, a data length, and a check code; and splicing the sub-update data carried in the multiple data packets according to the offset and the data length carried by each data packet to obtain the update data.

[0009] In an exemplary embodiment, the update data is verified to determine a first verification result of the update data, including: generating a target verification code corresponding to each sub-update data based on a target verification method; determining whether the target verification code corresponding to each sub-update data is consistent with the verification code corresponding to each sub-update data; when the target verification code corresponding to each sub-update data is consistent with the verification code corresponding to each sub-update data, determining that the first verification result indicates that the update data has passed the verification; when the target verification code corresponding to any sub-update data is inconsistent with the verification code corresponding to any sub-update data, determining that the first verification result indicates that the update data has not passed the verification.

[0010] In an exemplary embodiment, updating the target program according to the update data includes: receiving an update data completion notification sent by the main control device through a second interface, wherein the second interface is a remote procedure call protocol type interface, and the update data completion notification is used to indicate that the sending of the update data has been completed; verifying the update data completion notification to determine a second verification result of the update data completion notification; if the second verification result indicates that the update data completion notification has not passed the verification, sending a third return value to the main control device through the second interface; if the second verification result indicates that the update data completion notification has passed the verification, sending a fourth return value to the main control device through the second interface, and updating the target program according to the update data.

[0011] In an exemplary embodiment, receiving update data sent by a master control device through a first interface includes: receiving update command information sent by the master control device through a third interface, wherein the third interface is a remote procedure call protocol type interface; if the update command information fails to pass verification, sending a fifth return value to the master control device through the third interface; if the update data information passes verification, sending a sixth return value to the master control device through the third interface, and receiving the update data sent by the master control device through the first interface.

[0012] In an exemplary embodiment, after receiving update command information sent by the main control device through the third interface, the method also includes: parsing the update command information to obtain the data volume of the update data and the verification information of the update data; determining the storage space of the functional device, and determining whether the storage space can store the update data based on the storage space and the data volume; and determining whether the update command information is safe based on the verification information; if the storage space can store the update data and the update command information is safe, determining that the update command information has passed the verification; if the storage space cannot store the update data and / or the update command information is not safe, determining that the update command information has not passed the verification.

[0013] In an exemplary embodiment, after updating the target program according to the update data, the method further includes: when the functional device successfully updates the target program, sending a seventh return value to the main control device through a fourth interface, wherein the fourth interface is a remote procedure call protocol type interface; when the functional device fails to successfully update the target program, sending an eighth return value to the main control device through the fourth interface.

[0014] According to another embodiment of the embodiments of the present application, a return value sending device is also provided, including: a receiving module, used to receive update data sent by a main control device through a first interface when a target program of a functional device is to be updated, wherein the first interface is an interface of a remote procedure call protocol type; a verification module, used to verify the update data to determine a first verification result of the update data; a first sending module, used to send a first return value to the main control device through the first interface when the first verification result indicates that the update data has passed the verification, and update the target program according to the update data; a second sending module, used to send a second return value to the main control device through the first interface when the first verification result indicates that the update data has not passed the verification.

[0015] According to another aspect of the embodiments of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the above-mentioned method for sending a return value when running.

[0016] According to another aspect of an embodiment of the present application, there is also provided an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the return value sending method through the computer program.

[0017] In an embodiment of the present application, when the target program of the functional device is to be updated, the update data sent by the main control device through the first interface is received, wherein the first interface is an interface of the remote procedure call protocol type; the update data is verified to determine the first verification result of the update data; when the first verification result indicates that the update data passes the verification, a first return value is sent to the main control device through the first interface, and the target program is updated according to the update data; when the first verification result indicates that the update data does not pass the verification, a second return value is sent to the main control device through the first interface; in an embodiment of the present application, when the target program of the functional device is to be updated, the update data sent by the main control device through the first interface is received, wherein the "first interface" specifically refers to an interface of the RPC type. RPC, as a standardized network communication protocol, allows remote object calls between different systems without having to care about the underlying network technology. Therefore, whether the functional device and the main control device are connected through a network interface, UART, USB or SDIO interface, the transmission and processing of the update data can follow the same set of RPC interface specifications. This uniformity greatly simplifies the development and maintenance process, avoiding the complexity of designing and implementing application transmission protocols for each hardware interface separately. This solves the problem of needing to formulate and implement respective application transmission protocols for different hardware interfaces, which results in high transmission complexity. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0019] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0020] Figure 1It is a hardware environment diagram of a method for sending a return value according to an embodiment of the present application;

[0021] Figure 2 is a flowchart of a method for sending a return value according to an embodiment of the present application;

[0022] Figure 3 is a schematic diagram of a method for sending a return value according to an embodiment of the present application;

[0023] Figure 4 is a structural block diagram of a return value sending device according to an embodiment of the present application (I);

[0024] Figure 5 This is a structural block diagram (II) of a return value sending device according to an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0026] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0027] According to one aspect of an embodiment of the present application, a method for sending a return value is provided. The method for sending a return value is widely used in smart home, smart home, smart home device ecology, smart residential (Intelligence House) ecology and other whole-house intelligent digital control application scenarios. Optionally, in this embodiment, the above-mentioned method for sending a return value can be applied to Figure 1 In the hardware environment composed of the terminal device 102 and the server 104 shown in FIG. Figure 1As shown, the server 104 is connected to the terminal device 102 via a network, and can be used to provide services (such as application services, etc.) for the terminal or a client installed on the terminal. A database can be set on the server or independently of the server to provide data storage services for the server 104. Cloud computing and / or edge computing services can be configured on the server or independently of the server to provide data computing services for the server 104.

[0028] The network may include but is not limited to at least one of the following: wired network, wireless network. The wired network may include but is not limited to at least one of the following: wide area network, metropolitan area network, local area network, and the wireless network may include but is not limited to at least one of the following: WIFI (Wireless Fidelity), Bluetooth. The terminal device 102 may be but is not limited to a PC, a mobile phone, a tablet computer, a smart air conditioner, a smart range hood, a smart refrigerator, a smart oven, a smart stove, a smart washing machine, a smart water heater, a smart washing device, a smart dishwasher, a smart projection device, a smart TV, a smart clothes drying rack, a smart curtain, a smart audio and video, a smart socket, a smart speaker, a smart fresh air device, a smart kitchen and bathroom device, a smart bathroom device, a smart sweeping robot, a smart window cleaning robot, a smart mopping robot, a smart air purification device, a smart steamer, a smart microwave oven, a smart kitchen treasure, a smart purifier, a smart water dispenser, a smart door lock, etc.

[0029] In this embodiment, a method for sending a return value is provided, which is applied to a functional device. Figure 2 : is a flow chart of a method for sending a return value according to an embodiment of the present application, and the flow includes the following steps:

[0030] Step S202, when the target program of the functional device is to be updated, receiving update data sent by the main control device through the first interface, wherein the first interface is a remote procedure call protocol type interface;

[0031] Functional devices usually refer to embedded devices or modules that perform specific functions. They may not have independent network connectivity or their main functions do not involve advanced data processing or decision making. In the system, functional devices rely on other devices (usually master devices) for data transmission and control. Examples of functional devices include:

[0032] Sensor modules: such as temperature sensors, humidity sensors, accelerometers, etc., which are responsible for collecting data and transmitting it to the main control device.

[0033] Actuator modules: such as motor controllers, LED drivers, relays, etc., which perform physical operations based on the instructions they receive.

[0034] Peripheral devices: such as printers, displays, storage units, etc., which provide external output or storage capabilities.

[0035] Special function modules: such as signal processing units, encryption and decryption units, etc., which perform specific processor-intensive or special functions.

[0036] The above-mentioned main control device may be the above-mentioned terminal device.

[0037] The functional device is in the state of waiting for update, that is, the software or firmware version running on the device is inconsistent with the latest available version, and the software needs to be updated through OTA technology. In this case, the master device, as the initiator of the OTA upgrade, will send update data to the functional device through an RPC type interface (first interface). RPC (Remote Procedure Call) is a network communication protocol that allows methods on remote objects to be called between different systems without knowing the specific implementation of the underlying network technology.

[0038] Step S204, verifying the updated data to determine a first verification result of the updated data;

[0039] After receiving the update data, the functional device will immediately verify it. The purpose of the verification is to ensure the integrity and correctness of the data and prevent update failures due to errors or malicious tampering during data transmission. The verification process may include but is not limited to calculating the checksum of the data (such as CRC or MD5) and comparing it with the verification information provided by the sender, checking the integrity of the data packet, verifying the digital signature of the data packet to ensure the reliability of its source, etc.

[0040] Step S206, when the first verification result indicates that the update data passes verification, sending a first return value to the main control device through the first interface, and updating the target program according to the update data;

[0041] Step S208: When the first verification result indicates that the updated data fails verification, a second return value is sent to the main control device through the first interface.

[0042] After the verification is completed, the functional device will generate a return value based on the verification result. If the update data passes the verification (first verification result), the functional device will send a return value indicating success (first return value) to the main control device through the first interface. At the same time, the functional device will start using the received update data to perform software updates, which may include writing the new firmware to the memory, verifying the integrity of the new firmware, and restarting the device to load the new firmware. If the update data does not pass the verification (the first verification result indicates failure), the functional device will send a return value indicating verification failure (second return value) to the main control device through the first interface.

[0043] Through the above steps, when the target program of the functional device is to be updated, the update data sent by the main control device through the first interface is received, wherein the first interface is an interface of the remote procedure call protocol type; the update data is verified to determine the first verification result of the update data; when the first verification result indicates that the update data passes the verification, a first return value is sent to the main control device through the first interface, and the target program is updated according to the update data; when the first verification result indicates that the update data does not pass the verification, a second return value is sent to the main control device through the first interface; in the embodiment of the present application, when the target program of the functional device is to be updated, the update data sent by the main control device through the first interface is received for updating and the return value is returned, wherein the "first interface" specifically refers to an interface of the remote procedure call protocol RPC type. RPC, as a standardized network communication protocol, allows remote object calls between different systems without having to care about the underlying network technology. Therefore, whether the functional device and the main control device are connected through a network interface, UART, USB or SDIO interface, the transmission and processing of the update data can follow the same set of RPC interface specifications. This unification greatly simplifies the development and maintenance process, avoiding the complexity of designing and implementing application transmission protocols for each hardware interface. This also solves the problem of needing to develop and implement separate application transmission protocols for different hardware interfaces, which results in high transmission complexity.

[0044] In an exemplary embodiment, receiving update data sent by a master control device through a first interface includes: receiving multiple data packets sent by the master control device through the first interface, wherein each data packet carries sub-update data, an offset, a data length, and a check code; and splicing the sub-update data carried in the multiple data packets according to the offset and the data length carried by each data packet to obtain the update data.

[0045] The functional device receives multiple data packets sent by the master device through the first interface. Each data packet contains sub-update data (i.e., part of the update file), offset (indicating the starting position of the sub-data in the update file), data length (the size of the sub-data), and checksum (used to verify the integrity and correctness of the sub-data). In this way, even large files can be transmitted in blocks, avoiding the problem of transmission failure or data packet damage that may be caused by excessive single transmission data.

[0046] The functional device splices the sub-update data according to the offset and data length information of each data packet. The offset and data length are the key to data packet reassembly, which ensure that the sub-data can be spliced ​​into complete update data in the correct order and position. This offset-based data packet management strategy enables the functional device to accurately identify and locate each piece of data in the multiple data packets received, and can correctly reassemble the update file even if the data packet transmission order is disordered or delayed.

[0047] Each data packet contains a checksum, which is used to verify the integrity of the sub-update data immediately after the packet is received. Even if the entire update file is divided into multiple data packets during the transmission process, the checksum allows the functional device to independently complete the check on each data packet as it arrives, ensuring data security during the transmission process. Once a check failure is found for a data packet, the master device can be notified immediately, avoiding unnecessary data splicing and subsequent updates, thereby improving the efficiency and reliability of the entire OTA update process.

[0048] Through the embodiment of the present application, multiple data packets carrying sub-update data, offset, data length and check code are received through the RPC interface, and then the data packets are spliced ​​and checked according to the offset and data length information, which not only solves the problem of large file transmission, but also improves data security and transmission reliability through the use of check codes. This strategy simplifies the processing of update data by functional devices through standardized data packet management and verification mechanisms, and reduces the complexity and error rate that may be caused by hardware interface differences and transmission interruptions.

[0049] In an exemplary embodiment, the update data is verified to determine a first verification result of the update data, including: generating a target verification code corresponding to each sub-update data based on a target verification method; determining whether the target verification code corresponding to each sub-update data is consistent with the verification code corresponding to each sub-update data; when the target verification code corresponding to each sub-update data is consistent with the verification code corresponding to each sub-update data, determining that the first verification result indicates that the update data has passed the verification; when the target verification code corresponding to any sub-update data is inconsistent with the verification code corresponding to any sub-update data, determining that the first verification result indicates that the update data has not passed the verification.

[0050] After receiving the sub-update data, the functional device will independently generate a target check code for each sub-data according to a preset check method (such as CRC, MD5 or SHA algorithm). That is, the functional device will recalculate the check value of each data packet and compare it with the received check code.

[0051] After the target checksum is generated, the functional device checks whether the target checksum is consistent with the checksum carried in the data packet, thereby ensuring that the data has not been tampered with or damaged during transmission.

[0052] If the target check codes of all sub-update data are consistent with the corresponding check codes, then it can be determined that the check result indicates that the update data passes the check, that is, the integrity of the entire update data packet is maintained during the transmission process, and no data is damaged or tampered with.

[0053] If the target checksum of any sub-update data is inconsistent with the checksum carried in the data packet, the check result will indicate that the update data has failed the checksum. This mechanism can quickly identify any anomalies in data transmission and avoid updating with damaged or tampered data, thereby protecting the device from potential security threats.

[0054] Each sub-packet is checked immediately after it arrives, which can quickly discover and isolate errors in data transmission without waiting for the entire file to be transferred, improving the efficiency and accuracy of the check. If the check fails, it can accurately locate which packet has a problem, which helps the master device resend a specific packet instead of retransmitting the entire update file, saving transmission time and network resources.

[0055] In an exemplary embodiment, updating the target program according to the update data includes: receiving an update data completion notification sent by the main control device through a second interface, wherein the second interface is a remote procedure call protocol type interface, and the update data completion notification is used to indicate that the sending of the update data has been completed; verifying the update data completion notification to determine a second verification result of the update data completion notification; if the second verification result indicates that the update data completion notification has not passed the verification, sending a third return value to the main control device through the second interface; if the second verification result indicates that the update data completion notification has passed the verification, sending a fourth return value to the main control device through the second interface, and updating the target program according to the update data.

[0056] After the master device completes sending all update data packets, it will send an update data completion notification to the functional device through the second interface (also of RPC type). This notification informs the functional device that all sub-update data have been transmitted and the functional device can prepare for software update.

[0057] After receiving the notification of completion of updating data, the functional device will perform a check on it to determine the second check result. The purpose of the check is to confirm that the notification itself has not been damaged or tampered with during the transmission process, and to ensure the reliability and accuracy of its content. If the notification fails the check, it means that an abnormality may have occurred during the transmission process. The functional device will send a specific return value (third return value) back to the master device through the second interface, indicating that the notification reception failed.

[0058] If the update data completion notification passes the verification, the functional device will send a confirmation signal (fourth return value) to the main control device, indicating that the notification has been correctly received. At this time, the functional device can use the received update data to update the target program according to the predetermined update process.

[0059] By using the return value mechanism of the RPC interface for exception handling, the functional device can promptly feed back the verification result of the update data completion notification to the master device, which helps the master device understand the real-time status of the update process and make timely adjustments or retransmission decisions, avoiding unnecessary waiting or waste of resources.

[0060] In an exemplary embodiment, receiving update data sent by a master control device through a first interface includes: receiving update command information sent by the master control device through a third interface, wherein the third interface is a remote procedure call protocol type interface; if the update command information fails to pass verification, sending a fifth return value to the master control device through the third interface; if the update data information passes verification, sending a sixth return value to the master control device through the third interface, and receiving the update data sent by the master control device through the first interface.

[0061] At the beginning of the OTA update, the master device sends an update command message to the functional device through the third interface (also using the RPC type). This message contains key details about the software or firmware update, such as the size of the OTA file, version information, checksum, etc.

[0062] After receiving the update command information, the functional device first needs to verify it to confirm the authenticity and integrity of the information. Verification usually involves checking the checksum or digital signature in the information to ensure that the update command has not been tampered with or destroyed during transmission. If the verification fails, it means that the update command information may be unreliable. The functional device will send a specific return value (fifth return value) to the master device through the third interface, indicating that the update command information failed to be received or was rejected. At this time, the master device can take corresponding measures, such as resending the command information or terminating the update process, to avoid using unreliable update information for subsequent operations.

[0063] If the update command information passes the verification, the functional device will send a confirmation signal (sixth return value) to the master device through the third interface, indicating that the command information has been correctly received. Subsequently, the functional device will prepare to receive the update data sent by the master device through the first interface. The standardization of this process ensures that subsequent update data will be received only after the reliability and integrity of the update command information are confirmed, thereby improving the security and efficiency of OTA updates.

[0064] In an exemplary embodiment, after receiving update command information sent by the main control device through the third interface, the method also includes: parsing the update command information to obtain the data volume of the update data and the verification information of the update data; determining the storage space of the functional device, and determining whether the storage space can store the update data based on the storage space and the data volume; and determining whether the update command information is safe based on the verification information; if the storage space can store the update data and the update command information is safe, determining that the update command information has passed the verification; if the storage space cannot store the update data and / or the update command information is not safe, determining that the update command information has not passed the verification.

[0065] In the embodiment of the present application, the functional device first needs to parse the received update command information and extract the data volume and verification information of the update data. The data volume information tells the functional device how much storage space is needed to receive the new data; the verification information is used to verify the integrity and security of the update data.

[0066] The functional device will then check its own storage space to assess whether it can accommodate the update data to be received. This assessment is based on the amount of data obtained from the command message to ensure that the update data will not fail due to insufficient storage during the reception process. If there is insufficient storage space, it means that the current state of the device cannot support OTA updates, and the update command message will be considered to have failed verification.

[0067] The functional device will verify whether the command information itself is safe based on the verification information in the command information. This includes but is not limited to checking the checksum, digital signature or version number, etc., to ensure that the command information has not been tampered with and that the indicated update data is the correct version for the functional device. If the command information is confirmed to be unsafe, such as verification failure or version mismatch, the update command information will also be marked as failed verification.

[0068] Based on the results of the storage space assessment and command information security confirmation, the functional device will determine whether the update command information has passed the verification. The update command information is considered to have passed the verification only when the storage space is sufficient and the command information is secure. At this point, the functional device can prepare to receive and process the update data. On the contrary, if the storage space is insufficient or the command information is not secure, the update command information has not passed the verification, and the functional device will feedback this status to the master device, and the master device will adopt other strategies, such as reducing the size of the update data or aborting the update process.

[0069] Through this series of steps, functional devices can ensure that OTA updates are performed under safe and feasible conditions, avoiding update failures caused by insufficient storage or tampering of command information. This verification mechanism based on information parsing and conditional evaluation provides an additional layer of security and feasibility for OTA updates of embedded devices.

[0070] In an exemplary embodiment, after updating the target program according to the update data, the method further includes: when the functional device successfully updates the target program, sending a seventh return value to the main control device through a fourth interface, wherein the fourth interface is a remote procedure call protocol type interface; when the functional device fails to successfully update the target program, sending an eighth return value to the main control device through the fourth interface.

[0071] When the functional device successfully completes the update of the target program using the received update data, it sends a specific return value (the seventh return value) to the master device through the fourth interface, indicating that the update operation has been completed and no problems have been encountered. This feedback not only confirms the success of the software update, but can also contain additional information about the update process, such as the update time, update version number, etc.

[0072] If the functional device encounters a problem when trying to update the target program using the update data (such as interruption of the update process, storage error, data verification failure, etc.), it will send another specific return value (eighth return value) to the master device through the fourth interface, indicating that the update operation failed. This feedback mechanism allows the master device to quickly understand the update failure and take appropriate remedial measures, such as resending the update data, optimizing the update strategy, or troubleshooting.

[0073] Whether the update is successful or failed, timely feedback through the fourth interface can establish an effective exception handling mechanism between the master device and the functional device. The master device can quickly identify the update status and respond based on the type of return value received, avoiding long unnecessary waiting times, and also helping to improve the efficiency and reliability of the entire OTA update process.

[0074] Through the RPC interface, standardized and unified communication can be achieved between the main control device and the functional device, which simplifies the OTA upgrade process and reduces the complexity caused by differences in hardware interfaces. At the same time, the return value mechanism of the RPC interface provides a centralized and clear way for exception handling. Compared with traditional asynchronous event handling or customized error codes, this method can significantly improve the stability and development efficiency of the OTA process. In short, the embodiments of the present application effectively solve the transmission complexity and exception handling problems when performing OTA upgrades under multiple hardware interfaces.

[0075] In order to better understand the process of the above-mentioned return value sending method, the implementation method flow of the above-mentioned return value sending is described below in combination with an optional embodiment, but it is not used to limit the technical solution of the embodiment of the present application.

[0076] In this embodiment, a method for sending a return value is provided. Figure 3 is a schematic diagram of a method for sending a return value according to an embodiment of the present application, such as Figure 3 As shown, the specific steps are as follows:

[0077] Step S1: the master control device sends an upgrade command (equivalent to the update command information in the above embodiment) through the upgrade command interface (equivalent to the third interface in the above embodiment);

[0078] The information carried includes: OTA file size, file verification information, serial number, and identification code;

[0079] Step S2: The functional device processes the upgrade command and sets the return value according to the actual situation;

[0080] Step S3: the master control device sends an upgrade data packet (equivalent to the data packet in the above embodiment) through an upgrade data interface (equivalent to the first interface in the above embodiment);

[0081] The information carried in each upgrade data packet includes: offset, data length, and checksum;

[0082] Step S4: The functional device processes the upgrade data packet and sets the return value according to the actual situation;

[0083] Step S5: the master control device sends an upgrade data completion notification (equivalent to the update data completion notification in the above embodiment) through the upgrade data completion notification interface (equivalent to the second interface in the above embodiment);

[0084] Step S6: Verify the functional device and perform OTA, and set the return value according to the actual situation;

[0085] Step S7: the functional device sends an upgrade result notification through the upgrade result notification interface (equivalent to the fourth interface in the above embodiment);

[0086] Step S8: When the main control device receives the return value indicating that the functional device has successfully received the data, it proceeds to the next step;

[0087] Step S9: When the main control device receives the return value indicating that the functional device has failed to receive, it performs unified exception processing according to the return value.

[0088] In an embodiment of the present application, four RPC interfaces are constructed, namely, an upgrade command interface, an upgrade data sending interface, an upgrade data completion notification interface, and an upgrade result notification interface. These four interfaces are called in sequence, and each interface has a return value. Returning 0 indicates success, and only success will continue to call the next interface. When the interface returns a non-zero value, it indicates that an exception has occurred and exception handling is required. These exceptions include but are not limited to timeout, upgrade is not allowed, upgrade information exception (including version mismatch), data verification failure, data offset exception, upgrade failure (including insufficient resources, etc.), etc. At this time, it is necessary to call a unified exception handling.

[0089] The embodiment of the present application uses the RPC framework to unify the entire data transmission implementation. RPC can run as an independent component with good portability and compatibility. A set of OTA interfaces implemented on the RPC framework allows users to simply handle the transmission of OTA information and data, especially to abstract a single exception handling logic, simplifying the development process.

[0090] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods of each embodiment of the present application.

[0091] Figure 4 1 is a structural block diagram of a device for sending a return value according to an embodiment of the present application (I); Figure 4 As shown, including:

[0092] A receiving module 42, configured to receive update data sent by the main control device through a first interface when the target program of the functional device is to be updated, wherein the first interface is a remote procedure call protocol type interface;

[0093] A verification module 44, configured to verify the update data to determine a first verification result of the update data;

[0094] A first sending module 46, configured to send a first return value to the main control device through the first interface when the first verification result indicates that the update data passes verification, and update the target program according to the update data;

[0095] The second sending module 48 is configured to send a second return value to the main control device through the first interface when the first verification result indicates that the updated data fails the verification.

[0096] Through the above-mentioned device, when the target program of the functional device is to be updated, the update data sent by the main control device through the first interface is received, wherein the first interface is an interface of the remote procedure call protocol type; the update data is verified to determine the first verification result of the update data; when the first verification result indicates that the update data passes the verification, a first return value is sent to the main control device through the first interface, and the target program is updated according to the update data; when the first verification result indicates that the update data does not pass the verification, a second return value is sent to the main control device through the first interface; in the embodiment of the present application, when the target program of the functional device is to be updated, the update data sent by the main control device through the first interface is received, wherein the "first interface" specifically refers to an interface of the RPC type. RPC, as a standardized network communication protocol, allows remote object calls between different systems without having to care about the underlying network technology. Therefore, whether the functional device and the main control device are connected through a network interface, UART, USB or SDIO interface, the transmission and processing of the update data can follow the same set of RPC interface specifications. This uniformity greatly simplifies the development and maintenance process, avoiding the complexity of designing and implementing application transmission protocols for each hardware interface separately. This solves the problem of needing to formulate and implement respective application transmission protocols for different hardware interfaces, which results in high transmission complexity.

[0097] In an exemplary embodiment, the receiving module 42 is used to receive multiple data packets sent by the main control device through the first interface, wherein each data packet carries sub-update data, an offset, a data length, and a check code; and the sub-update data carried in the multiple data packets are spliced ​​according to the offset and data length carried by each data packet to obtain the update data.

[0098] In an exemplary embodiment, the verification module 44 is used to generate a target verification code corresponding to each sub-update data based on a target verification method; determine whether the target verification code corresponding to each sub-update data is consistent with the verification code corresponding to each sub-update data; when the target verification code corresponding to each sub-update data is consistent with the verification code corresponding to each sub-update data, determine that the first verification result indicates that the update data has passed the verification; when the target verification code corresponding to any sub-update data is inconsistent with the verification code corresponding to any sub-update data, determine that the first verification result indicates that the update data has not passed the verification.

[0099] In an exemplary embodiment, the receiving module 42 is used to receive an update data completion notification sent by the master control device through a second interface, wherein the second interface is a remote procedure call protocol type interface, and the update data completion notification is used to indicate that the sending of the update data has been completed;

[0100] A verification module 44, configured to verify the update data completion notification to determine a second verification result of the update data completion notification;

[0101] A second sending module 48, configured to send a third return value to the main control device through the second interface when the second verification result indicates that the update data completion notification fails to pass the verification;

[0102] A first sending module 46, configured to send a fourth return value to the main control device through the second interface when the second verification result indicates that the update data completion notification has passed the verification;

[0103] like Figure 5 As shown, the above device also includes: an updating module 52, which is used to update the target program according to the update data.

[0104] In an exemplary embodiment, the receiving module 42 is used to receive update command information sent by the main control device through a third interface, wherein the third interface is a remote procedure call protocol type interface;

[0105] A second sending module 48, configured to send a fifth return value to the main control device through the third interface if the update command information fails to pass the verification;

[0106] A first sending module 46, configured to send a sixth return value to the main control device through the third interface if the update data information passes the verification;

[0107] The receiving module 42 is used to receive the update data sent by the main control device through the first interface.

[0108] In an exemplary embodiment, Figure 5 As shown, the above device further includes: a parsing module 54, used to parse the update command information to obtain the data volume of the update data and the verification information of the update data;

[0109] The verification module 44 is used to determine the storage space of the functional device, and determine whether the storage space can store the update data based on the storage space and the data volume; and determine whether the update command information is safe based on the verification information; if the storage space can store the update data and the update command information is safe, determine that the update command information has passed the verification; if the storage space cannot store the update data and / or the update command information is not safe, determine that the update command information has not passed the verification.

[0110] In an exemplary embodiment, the second sending module 48 is used to send a seventh return value to the main control device through the fourth interface when the functional device successfully updates the target program, wherein the fourth interface is a remote procedure call protocol type interface; the first sending module 46 is used to send an eighth return value to the main control device through the fourth interface when the functional device fails to successfully update the target program.

[0111] An embodiment of the present application further provides a storage medium, which includes a stored program, wherein the program executes any of the above methods when it is run.

[0112] Optionally, in this embodiment, the storage medium may be configured to store program codes for executing the following steps:

[0113] S1, when a target program of a functional device is to be updated, receiving update data sent by a main control device through a first interface, wherein the first interface is a remote procedure call protocol type interface;

[0114] S2, verifying the updated data to determine a first verification result of the updated data;

[0115] S3, when the first verification result indicates that the update data passes verification, sending a first return value to the main control device through the first interface, and updating the target program according to the update data;

[0116] S4: When the first verification result indicates that the updated data fails verification, send a second return value to the main control device through the first interface.

[0117] An embodiment of the present application further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0118] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0119] Optionally, in this embodiment, the processor may be configured to perform the following steps through a computer program:

[0120] S1, when a target program of a functional device is to be updated, receiving update data sent by a main control device through a first interface, wherein the first interface is a remote procedure call protocol type interface;

[0121] S2, verifying the updated data to determine a first verification result of the updated data;

[0122] S3, when the first verification result indicates that the update data passes verification, sending a first return value to the main control device through the first interface, and updating the target program according to the update data;

[0123] S4: When the first verification result indicates that the updated data fails verification, send a second return value to the main control device through the first interface.

[0124] Optionally, in this embodiment, the above-mentioned storage medium may include but is not limited to: a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and other media that can store program codes.

[0125] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any one of the above method embodiments are implemented.

[0126] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above method embodiments are implemented.

[0127] The embodiments of the present application also provide a computer program, which includes computer instructions, which are stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the steps in any one of the above method embodiments.

[0128] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be described in detail here.

[0129] Obviously, those skilled in the art should understand that the above modules or steps of the present application can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, and optionally, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order from that herein, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present application is not limited to any specific combination of hardware and software.

[0130] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for sending a return value, characterized in that: Applied to functional equipment, including: In the case where the target program of the functional device is to be updated, receiving update data sent by the main control device through the first interface, wherein the first interface is a remote procedure call protocol type interface; Verifying the updated data to determine a first verification result of the updated data; When the first verification result indicates that the updated data has passed the verification, a first return value is sent to the main control device through the first interface, and the target program is updated according to the updated data; when the first verification result indicates that the updated data has not passed the verification, a second return value is sent to the main control device through the first interface.

2. The method for sending a return value according to claim 1, characterized in that: Receiving update data sent by the master control device through the first interface, including: receiving a plurality of data packets sent by the master control device through the first interface, wherein each data packet carries sub-update data, an offset, a data length, and a check code; The sub-update data carried in the multiple data packets are spliced ​​according to the offset and the data length carried by each data packet to obtain the update data.

3. The method for sending a return value according to claim 2, characterized in that: Verifying the updated data to determine a first verification result of the updated data includes: Generate a target verification code corresponding to each sub-update data based on the target verification method; Determine whether the target check code corresponding to each sub-update data is consistent with the check code corresponding to each sub-update data; When the target check code corresponding to each sub-update data is consistent with the check code corresponding to each sub-update data, it is determined that the first check result indicates that the update data has passed the check; when the target check code corresponding to any sub-update data is inconsistent with the check code corresponding to any sub-update data, it is determined that the first check result indicates that the update data has not passed the check.

4. The method for sending a return value according to claim 1, characterized in that: Updating the target program according to the update data includes: receiving an update data completion notification sent by the master control device through a second interface, wherein the second interface is a remote procedure call protocol type interface, and the update data completion notification is used to indicate that the sending of the update data has been completed; Verifying the update data completion notification to determine a second verification result of the update data completion notification; When the second verification result indicates that the update data completion notification fails the verification, sending a third return value to the main control device through the second interface; When the second verification result indicates that the update data completion notification passes the verification, a fourth return value is sent to the main control device through the second interface, and the target program is updated according to the update data.

5. The method for sending a return value according to claim 1, characterized in that: Receiving update data sent by the master control device through the first interface, including: Receiving update command information sent by the main control device through a third interface, wherein the third interface is a remote procedure call protocol type interface; If the update command information fails to pass the verification, sending a fifth return value to the main control device through the third interface; When the update data information passes the verification, a sixth return value is sent to the master device through the third interface, and the update data sent by the master device through the first interface is received.

6. The method for sending a return value according to claim 5, characterized in that: After receiving the update command information sent by the master control device through the third interface, the method further includes: Parsing the update command information to obtain the data volume of the update data and the verification information of the update data; determining a storage space of the functional device, and determining whether the storage space can store the update data according to the storage space and the data volume; and determining whether the update command information is safe according to the verification information; If the storage space can store the update data and the update command information is safe, determining that the update command information passes verification; In a case where the storage space cannot store the update data and / or the update command information is not secure, it is determined that the update command information fails verification.

7. The method for sending a return value according to claim 1, characterized in that: After updating the target program according to the update data, the method further includes: When the functional device successfully updates the target program, a seventh return value is sent to the main control device through the fourth interface, wherein the fourth interface is a remote procedure call protocol type interface; when the functional device fails to successfully update the target program, an eighth return value is sent to the main control device through the fourth interface.

8. A device for sending a return value, characterized in that: include: A receiving module, used for receiving update data sent by the main control device through a first interface when the target program of the functional device is to be updated, wherein the first interface is a remote procedure call protocol type interface; A verification module, used to verify the update data to determine a first verification result of the update data; a first sending module, configured to send a first return value to the main control device through the first interface when the first verification result indicates that the update data passes verification, and update the target program according to the update data; The second sending module is used to send a second return value to the main control device through the first interface when the first verification result indicates that the updated data fails to pass the verification.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein the program executes the method described in any one of claims 1 to 7 when executed.

10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 7 through the computer program.