Controller program upgrading method and device, readable storage medium and electronic equipment

Abstract

The invention provides a controller program upgrading method and device, a readable storage medium and electronic equipment, and relates to the technical field of controller upgrading. The controller program upgrading method comprises the following steps: receiving a first upgrading file; determining a second upgrading file according to the coding format of the first upgrading file, wherein the second upgrading file is used for upgrading the controller program; and upgrading the controller program through the second upgrading file.

Description

Technical Field

[0001] The present application relates to the technical field of controller upgrades, and more particularly, to a method, device, readable storage medium, and electronic device for upgrading a controller program. Background Art

[0002] In related technologies, controllers are provided in devices such as electrical devices and household appliances, and the controller programs are run by the controllers in the devices to achieve different device functions. The above devices can perform post-maintenance or upgrade of the controller program through the OTA (Over the Air Technology) upgrade method.

[0003] The OTA upgrade files include various encoding formats, and the integrated development environments in the host computers of devices of different models and batches are different, so the supported encoding formats are also different. Therefore, it is necessary to edit OTA upgrade files for different types of devices separately, and the OTA upgrade is difficult and inefficient. Summary of the Invention

[0004] The present application aims to solve at least one of the technical problems existing in the prior art or related technologies.

[0005] To this end, a first aspect of the present application provides a method for upgrading a controller program;

[0006] A second aspect of the present application provides a device for upgrading a controller program;

[0007] A third aspect of the present application provides a device for upgrading a controller program;

[0008] A fourth aspect of the present application provides a readable storage medium;

[0009] A fifth aspect of the present application provides an electronic device.

[0010] In view of this, a first aspect of the present application provides a method for upgrading a controller program, the method including: receiving a first upgrade file; determining a second upgrade file according to the encoding format of the first upgrade file, the second upgrade file being used to upgrade the controller program; and upgrading the controller program by the second upgrade file.

[0011] In this technical solution, the controller program can be run by the controller in the device to achieve different device functions. For example, the device includes electrical devices such as photovoltaic energy storage devices, power transformation devices, and inverter devices, and the device also includes household appliances such as central air conditioners, kitchen and bathroom appliances, and household cleaning devices.

[0012] Taking a photovoltaic energy storage device as an example, the photovoltaic energy storage device can store the electric energy generated by the photovoltaic power generation device in the battery pack, and convert the DC signal output by the battery pack into an AC signal identical to that of the power grid for use as household electricity by users. Among them, in order to ensure electrical safety, the photovoltaic energy storage device generally integrates a battery management function and an insulation detection function. These functions are realized by running a controller program in the controller of the host computer of the photovoltaic energy storage device.

[0013] Exemplarily, the controller can be an embedded controller, a DSP (Digital Signal Processing) controller, an ARM (Advanced RISC Machine) microprocessor, etc.

[0014] With product iteration, the above functions will also continue to progress and be updated. When the functions are updated, in order to enable existing devices to synchronously update functions, device manufacturers will perform function upgrades on existing devices through OTA upgrades.

[0015] The OTA upgrade files include various encoding formats. For example, the common encoding formats of OTA upgrade files include the Bin (binary file) format, the Hex (hexadecimal file) format, and the S-Record format, etc. Among them, the content of the Bin format file is a single binary encoding (RawData) without task information, which is simple and direct. The Hex format file includes ASCII text lines (records), and the text records cover content such as memory addresses, types, lengths, and data. The content of the S-Record format file is similar to that of the Hex format file.

[0016] However, the integrated development environments (IDEs) in the host computers of devices of different models and batches are different, so the supported encoding formats are also different. For example, if the IDE integrated in device A supports the Bin format and the IDE integrated in device B supports the Hex format, then it is necessary to separately edit the Bin format upgrade file and the Hex format upgrade file for device A and device B respectively, resulting in the need to "reinvent the wheel" and reducing the efficiency of OTA upgrades.

[0017] In view of the above situation, the technical solution of this application sets up a process for identifying and converting the encoding format of OTA upgrade files on the device terminal side, so that when device manufacturers perform OTA upgrades on devices of different batches and models, there is no need to develop OTA upgrade files of different encoding formats one by one, nor to distinguish the IDEs of the host computers of each existing device.

[0018] Specifically, after the device receives an OTA upgrade file, such as the first upgrade file mentioned above, it identifies the encoding format of the received OTA upgrade file, and based on the encoding format of the received OTA upgrade file, automatically generates a second upgrade file that can upgrade the controller in the host computer of the current device, that is, the encoding format of which matches the encoding format supported by the IDE of the current host computer. That is, it can automatically convert the encoding format of the received OTA upgrade file to obtain an upgrade file that matches the encoding format supported by its own IDE. Therefore, regardless of which encoding format the OTA upgrade file pushed by the manufacturer uses, the terminal device can upgrade and maintain its own controller program through the received OTA upgrade file.

[0019] The technical solution of this application can automatically convert the encoding format of the OTA upgrade file on the device terminal side. Therefore, the manufacturer only needs to develop an OTA upgrade file in one encoding format to perform OTA upgrades on all deployed terminal devices, without having to develop OTA upgrade files in different encoding formats one by one, nor having to distinguish the IDEs of the host computers of each existing device, avoiding the work of reinventing the wheel, reducing the difficulty of OTA upgrades, and improving the efficiency of OTA upgrades.

[0020] In addition, the method for upgrading the controller program in the above technical solution provided by this application may also have the following additional technical features:

[0021] In some technical solutions of this application, optionally, the step of determining the second upgrade file according to the encoding format of the first upgrade file includes: when the first encoding format corresponding to the first upgrade file is different from the second encoding format corresponding to the controller program, performing format conversion processing on the first upgrade file to obtain the second upgrade file; or when the first encoding format is the same as the second encoding format, determining the first upgrade file as the second upgrade file; where the encoding format of the second upgrade file is the second encoding format.

[0022] In this technical solution, when the device terminal receives an OTA upgrade file, such as the first upgrade file mentioned above, it first identifies the encoding format of the received first upgrade file. After determining the first encoding format of the first upgrade file, the device determines whether the first encoding format of the first upgrade file is the same as the second encoding format corresponding to the controller of its own host computer, that is, the encoding format supported by its own IDE.

[0023] If the first encoding format of the first upgrade file is the same as the second encoding format supported by its own IDE, the device can perform OTA upgrades through the first upgrade file without converting the encoding format of the first upgrade file. At this time, the first upgrade file is determined as the second upgrade file, and the controller program can be upgraded through the second upgrade file.

[0024] If the first encoding format of the first upgrade file is different from the second encoding format supported by its own IDE, it is necessary to convert the encoding format of the first upgrade file. Specifically, the encoding format of the first upgrade file is converted from the first encoding format to the second encoding format supported by its own IDE. After the encoding format of the first upgrade file is converted and the second upgrade file with the second encoding format is obtained, the controller program is upgraded through the second upgrade file with the converted encoding format.

[0025] After receiving the OTA upgrade file, the technical solution of this application automatically determines whether the encoding format of the OTA upgrade file is supported, and when the encoding format of the received OTA upgrade file is different from the encoding format supported by its own IDE, it can automatically convert the encoding format of the OTA upgrade file and upgrade its own controller program through the file with the converted format, realizing the universality of the OTA upgrade file.

[0026] In some technical solutions of this application, optionally, the step of performing format conversion processing on the first upgrade file to obtain the second upgrade file includes: determining the corresponding format conversion command according to the first encoding format and the second encoding format; performing format conversion processing on the first upgrade file based on the format conversion command and the image file conversion tool to obtain the second upgrade file.

[0027] In this technical solution, different encoding formats can be converted through a file conversion tool, where the file conversion tool can be an open-source tool for image files. Exemplarily, the file conversion tool is srec_cat, which is an open-source tool and can run on multiple operating systems such as Linux, Windows, and Mac OS X.

[0028] When converting the encoding format of the upgrade file through the file conversion tool, it is necessary to clarify the encoding format of the input file and the encoding format of the target file. After receiving the first upgrade file, determine the current encoding format of the first upgrade file, that is, the first encoding format, and at the same time, in combination with the second encoding format supported by the IDE integrated in the device-side system, determine the corresponding format conversion command.

[0029] Taking the file conversion tool as srec_cat as an example, according to the input format and the output format, that is, the first encoding format and the second encoding format of the received first upgrade file, determine the srec_cat conversion command, convert the encoding format of the first upgrade file through srec_cat, generate the second upgrade file with the second encoding format, and upgrade the controller program through the second upgrade file.

[0030] The technical solution of this application converts the encoding format of the received OTA upgrade file through a file conversion tool, with fast response speed and low consumption of system resources, which is conducive to realizing wide deployment on device platforms with different hardware performances and reducing the difficulty of OTA upgrade.

[0031] In some technical solutions of this application, optionally, after the step of receiving the first upgrade file, the upgrade method further includes: determining the encoding format of the first upgrade file according to the suffix name of the first upgrade file.

[0032] In this technical solution, upgrade files with different encoding formats also have different suffix names. For example, the binary file encoding format, that is, the suffix name of the upgrade file in Bin format is generally ".bin", the hexadecimal file encoding format, that is, the suffix name of the upgrade file in Hex format is generally ".hex", and the suffix names of the upgrade files in S-Record format generally include ".s19", ".37", ".srec", and ".mot", etc.

[0033] Therefore, after receiving the first upgrade file, the encoding format of the first upgrade file can be determined according to the suffix name of the first upgrade file, without performing operations such as unpacking and decoding on the first upgrade file.

[0034] The technical solution of this application determines the encoding format of the received OTA upgrade file according to its suffix name, and automatically converts it when the encoding format of the OTA upgrade file is different from its own IDE. Therefore, when pushing OTA upgrades, there is no need to develop OTA upgrade files with different encoding formats one by one, nor to distinguish the IDE of the host computer of each existing device, avoiding duplicate work, reducing the difficulty of OTA upgrade, and improving the OTA upgrade efficiency.

[0035] In some technical solutions of this application, optionally, the step of upgrading the controller program through the second upgrade file includes: writing the second upgrade file into a memory, the memory is signal-connected to the controller, and the controller is associated with the controller program; the controller reads the second upgrade file in the memory to upgrade the controller program.

[0036] In this technical solution, the upgrade method of the controller program can be applied to electrical equipment such as photovoltaic energy storage devices. The photovoltaic energy storage device includes a host computer, and the host computer is used to control each electrical device in the photovoltaic energy storage device to realize different device functions.

[0037] Exemplarily, the host computer can be a device such as a microcomputer, an embedded system, or an engineering machine. A controller is provided in the host computer. Exemplarily, the controller can be an embedded controller, a DSP controller, an ARM, etc. The controller realizes different device functions by executing the controller program.

[0038] The memory is signal - connected to the controller, and the controller can read the programs or instructions stored in the memory to control different electrical modules in the device to perform corresponding operations.

[0039] Exemplarily, the memory can be the flash memory of a microcontroller. Exemplarily, the microcontroller includes an MCU (Micro Controller Unit), an EEPROM (Electrically EPROM, Electrically Erasable Programmable Read - Only Memory), a NOR Flash (NOR - type flash memory), or a NAND Flash (NAND flash memory), etc.

[0040] After converting the data format of the received first upgrade file, the obtained second upgrade file is burned into the memory through a host computer. The controller can access and read the second upgrade file stored in the memory, and upgrade or maintain the controller program.

[0041] Before burning the OTA upgrade file into the memory, the technical solution of this application judges and converts the data format of the OTA upgrade file, so that it can automatically convert the OTA upgrade file with an incompatible data format into an upgrade file with a compatible data format, improving the efficiency of OTA upgrade.

[0042] In some technical solutions of this application, optionally, before the step of writing the second upgrade file into the memory, the upgrade method further includes: converting the source code data of the second upgrade file into machine - code data; the step of writing the second upgrade file into the memory includes: writing the machine - code data into the memory.

[0043] In this technical solution, the source code of the OTA upgrade file pushed by the cloud is generally written in programming statements such as C language or assembly language. In a typical application program, in order to implement the operation of the upgrade program, it is necessary to convert the source code composed of programming statements in the OTA upgrade file into machine code through modules such as a compiler or an assembler. Among them, machine code is also called machine instruction, and machine instruction is the command encoding when the central processing unit of a computer executes an operation, and its structure is a specific binary number sequence composed of 1 and 0.

[0044] After converting the data format of the received first upgrade file to obtain a second upgrade file, the source code of the second file is converted into machine code that can be recognized by the controller through modules such as a compiler or an assembler, and the machine code is written into the memory.

[0045] At this time, the controller can read and access the machine code in the memory and perform corresponding upgrade operations according to the machine code.

[0046] Before writing the second upgrade file with the converted data format into the memory, the technical solution of this application converts the source code of the second upgrade file into machine code that can be directly read and recognized by the controller, enabling the controller to directly read and access the machine code, thereby performing the corresponding upgrade operation and improving the efficiency of OTA upgrade.

[0047] In some technical solutions of this application, optionally, the encoding format includes: Bin encoding format, Hex encoding format, and S-record encoding format.

[0048] In this technical solution, the encoding format of the OTA upgrade file includes the Bin encoding format. The content of the upgrade file in the Bin encoding format is a single binary encoding without task information, which is simple and direct. The controller can complete the upgrade by overwriting the data according to the address indicated in the upgrade file.

[0049] The encoding format of the OTA upgrade file includes the Hex encoding format. The upgrade file in the Hex encoding format is a hexadecimal file, including ASCII text lines (records), and the text records cover contents such as memory address, type, length, and data.

[0050] The encoding format of the OTA upgrade file includes the S-record encoding format. The upgrade file in the S-record encoding format conveys the hexadecimal values of binary information in the form of ASCII text and is usually used for programming the flash memory in programmable logic devices.

[0051] By setting the encoding format to the Bin encoding format, Hex encoding format, or S-record encoding format, the technical solution of this application has low development difficulty and good versatility, and can reduce the difficulty of OTA upgrade.

[0052] The second aspect of this application provides an upgrade device for a controller program, including: a receiving module for receiving a first upgrade file; a determining module for determining a second upgrade file according to the encoding format of the first upgrade file, where the second upgrade file is used to upgrade the controller program; and an upgrade module for upgrading the controller program through the second upgrade file.

[0053] In this technical solution, the controller program can be run by the controller in the device, thereby realizing different device functions. For example, the device includes electrical devices such as photovoltaic energy storage devices, power transformation devices, and inverter devices, and the device also includes household appliances such as central air conditioners, kitchen and bathroom devices, and household cleaning devices.

[0054] Taking a photovoltaic energy storage device as an example, the photovoltaic energy storage device can store the electric energy generated by the photovoltaic power generation device in the battery pack, and convert the direct current signal output by the battery pack into an alternating current signal identical to that of the power grid for use as household electricity by users. Among them, to ensure electrical safety, the photovoltaic energy storage device generally integrates battery management functions and insulation detection functions. These functions are realized by running a controller program in the controller of the host computer of the photovoltaic energy storage device.

[0055] Exemplarily, the controller can be an embedded controller, a DSP (Digital Signal Processing) controller, an ARM (Advanced RISC Machine) microprocessor, etc.

[0056] With product iteration, the above functions will also continue to progress and be updated. When the functions are updated, in order to enable existing devices to synchronously update their functions, device manufacturers will upgrade the functions of existing devices through OTA (Over-the-Air) upgrade.

[0057] OTA upgrade files include multiple encoding formats. For example, common encoding formats of OTA upgrade files include Bin (binary file) format, Hex (hexadecimal file) format, and S-Record format, etc. Among them, the content of a Bin format file is a single binary encoding (RawData) without task information, which is simple and direct. A Hex format file includes ASCII text lines (records), and the text records cover content such as memory address, type, length, data, etc. The content of an S-Record format file is similar to that of a Hex format file.

[0058] However, the integrated development environments (IDEs) in the host computers of devices of different models and batches are different, so the supported encoding formats are also different. For example, if the IDE integrated in device A supports the Bin format and the IDE integrated in device B supports the Hex format, then it is necessary to separately edit Bin format upgrade files and Hex format upgrade files for device A and device B respectively, resulting in the need to do "duplicate work", which reduces the efficiency of OTA upgrade.

[0059] In view of the above situation, the technical solution of this application sets up a process for identifying and converting the encoding format of OTA upgrade files on the device terminal side, so that when device manufacturers perform OTA upgrades on devices of different batches and models, there is no need to develop OTA upgrade files of different encoding formats one by one, nor to distinguish the IDEs of the host computers of each existing device.

[0060] Specifically, after the device receives an OTA upgrade file, such as the first upgrade file described above, it identifies the encoding format of the received OTA upgrade file, and based on the encoding format of the received OTA upgrade file, automatically generates a second upgrade file that can upgrade the controller in the host computer of the current device, that is, the encoding format matches the encoding format supported by the IDE of the current host computer. That is, it can automatically convert the encoding format of the received OTA upgrade file to obtain an upgrade file that matches the encoding format supported by its own IDE. Therefore, regardless of which encoding format the OTA upgrade file pushed by the manufacturer uses, the terminal device can upgrade and maintain its own controller program through the received OTA upgrade file.

[0061] The technical solution of this application can automatically convert the encoding format of the OTA upgrade file on the terminal side of the device. Therefore, the manufacturer only needs to develop an OTA upgrade file in one encoding format to perform OTA upgrades on all deployed terminal devices, without having to develop OTA upgrade files in different encoding formats one by one, nor having to distinguish the IDE of the host computer of each existing device, avoiding the work of reinventing the wheel, reducing the difficulty of OTA upgrades, and improving the efficiency of OTA upgrades.

[0062] The third aspect of this application provides an upgrade device for a controller program, including: a memory for storing programs or instructions; a processor for implementing the steps of the upgrade method for the controller program provided in any of the above technical solutions when executing the programs or instructions, and achieving the same technical effects. To avoid repetition, it will not be elaborated here.

[0063] The fourth aspect of this application provides a readable storage medium, on which programs or instructions are stored. When the programs or instructions are executed by a processor, the steps of the upgrade method for the controller program provided in any of the above technical solutions are implemented, and the same technical effects can be achieved. To avoid repetition, it will not be elaborated here.

[0064] The fifth aspect of this application provides an electronic device, including: the upgrade device for the controller program provided in any of the above technical solutions; and / or the readable storage medium provided in any of the above technical solutions, and thus also includes all its beneficial effects. To avoid repetition, it will not be elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] The above and / or additional aspects and advantages of this application will become apparent and easy to understand from the description of the embodiments in conjunction with the following drawings, where:

[0066] Figure 1 The flowchart of the upgrade method for the controller program showing some embodiments of this application is shown;

[0067] Figure 2The flowchart of the method for upgrading the controller program according to some embodiments of the present application is shown;

[0068] Figure 3 The block diagram of the structure of the device for upgrading the controller program according to some embodiments of the present application is shown;

[0069] Figure 4 The block diagram of the structure of the device for upgrading the controller program according to some embodiments of the present application is shown. Detailed implementation manners

[0070] In order to be able to more clearly understand the above objects, features and advantages of the present application, the present application will be further described in detail below in conjunction with the drawings and specific implementation manners. It should be noted that, without conflict, the embodiments of the present application and the features in the embodiments can be combined with each other.

[0071] In the following description, many specific details are set forth in order to fully understand the present application. However, the present application may also be implemented in other ways different from those described herein. Therefore, the protection scope of the present application is not limited by the specific embodiments disclosed below.

[0072] Next, refer to Figures 1 to 4 Describe the method, device, readable storage medium and electronic device for upgrading the controller program according to some embodiments of the present application.

[0073] In some embodiments of the present application, a method for upgrading a controller program is provided. Figure 1 The flowchart of the method for upgrading the controller program according to some embodiments of the present application is shown, as Figure 1 shown, the method includes:

[0074] Step 102, receiving a first upgrade file;

[0075] Step 104, determining a second upgrade file according to the encoding format of the first upgrade file, where the second upgrade file is used to upgrade the controller program;

[0076] Step 106, upgrading the controller program by using the second upgrade file.

[0077] In this embodiment, the controller program can be run by the controller in the device to implement different device functions. For example, the device includes electrical devices, such as photovoltaic energy storage devices, power transformation devices, inverter devices, etc., and the device also includes household electrical appliances, such as central air conditioners, kitchen and bathroom devices, household cleaning devices, etc.

[0078] Taking a photovoltaic energy storage device as an example, the photovoltaic energy storage device can store the electric energy generated by the photovoltaic power generation device in the battery pack, and convert the direct current signal output by the battery pack into an alternating current signal identical to that of the power grid for use as household electricity by users. Among them, to ensure electrical safety, the photovoltaic energy storage device generally integrates a battery management function and an insulation detection function. These functions are realized by running a controller program in the controller of the host computer of the photovoltaic energy storage device.

[0079] Exemplarily, the controller can be an embedded controller, a DSP (Digital Signal Processing) controller, an ARM (Advanced RISC Machine) microprocessor, etc.

[0080] With product iteration, the above functions will also continue to progress and be updated. When the functions are updated, in order to enable existing devices to synchronously update their functions, device manufacturers will perform function upgrades on existing devices through OTA upgrades.

[0081] The OTA upgrade files include multiple encoding formats. For example, the common encoding formats of OTA upgrade files include the Bin (binary file) format, the Hex (hexadecimal file) format, and the S-Record format, etc. Among them, the content of the Bin format file is a single binary encoding (RawData) without task information, which is simple and direct. The Hex format file includes ASCII text lines (records), and the text records cover content such as memory addresses, types, lengths, and data. The content of the S-Record format file is similar to that of the Hex format file.

[0082] Moreover, the integrated development environments (IDEs) in the host computers of devices of different models and batches are different, so the supported encoding formats are also different. For example, if the IDE integrated in device A supports the Bin format and the IDE integrated in device B supports the Hex format, then it is necessary to separately edit the Bin format upgrade file and the Hex format upgrade file for device A and device B respectively, resulting in the need to do "duplicate work", which reduces the efficiency of OTA upgrades.

[0083] In view of the above situation, in the device terminal side of the embodiments of the present application, a process for identifying and converting the encoding format of OTA upgrade files is set, so that when device manufacturers perform OTA upgrades on devices of different batches and models, there is no need to develop OTA upgrade files in different encoding formats one by one, nor to distinguish the IDEs of the host computers of each existing device.

[0084] Specifically, after the device receives an OTA upgrade file, such as the first upgrade file described above, it identifies the encoding format of the received OTA upgrade file, and based on the encoding format of the received OTA upgrade file, automatically generates a second upgrade file that can upgrade the controller in the host computer of the current device, that is, the encoding format of which matches the encoding format supported by the IDE of the current host computer. That is, it can automatically convert the encoding format of the received OTA upgrade file to obtain an upgrade file that matches the encoding format supported by its own IDE. Therefore, regardless of which encoding format the OTA upgrade file pushed by the manufacturer uses, the terminal device can upgrade and maintain its own controller program through the received OTA upgrade file.

[0085] The embodiment of the present application can automatically convert the encoding format of the OTA upgrade file on the device terminal side. Therefore, the manufacturer only needs to develop an OTA upgrade file in one encoding format to perform OTA upgrades on all deployed terminal devices, without having to develop OTA upgrade files in different encoding formats one by one, nor having to distinguish the IDEs of the host computers of each existing device, avoiding duplicate work, reducing the difficulty of OTA upgrades, and improving the efficiency of OTA upgrades.

[0086] In addition, the method for upgrading the controller program in the above embodiment provided by the present application may further have the following additional technical features:

[0087] In some embodiments of the present application, optionally, the step of determining the second upgrade file according to the encoding format of the first upgrade file includes: when the first encoding format corresponding to the first upgrade file is different from the second encoding format corresponding to the controller program, performing format conversion processing on the first upgrade file to obtain the second upgrade file; or when the first encoding format is the same as the second encoding format, determining the first upgrade file as the second upgrade file; wherein, the encoding format of the second upgrade file is the second encoding format.

[0088] In this embodiment, when the device terminal receives an OTA upgrade file, such as the first upgrade file described above, it first identifies the encoding format of the received first upgrade file. After determining the first encoding format of the first upgrade file, the device determines whether the first encoding format of the first upgrade file is the same as the second encoding format corresponding to the controller of its own host computer, that is, the encoding format supported by its own IDE.

[0089] If the first encoding format of the first upgrade file is the same as the second encoding format supported by its own IDE, the device can perform OTA upgrades through the first upgrade file without converting the encoding format of the first upgrade file. At this time, the first upgrade file is determined as the second upgrade file, and the controller program can be upgraded through the second upgrade file.

[0090] If the first encoding format of the first upgrade file is different from the second encoding format supported by its own IDE, it is necessary to convert the encoding format of the first upgrade file. Specifically, the encoding format of the first upgrade file is converted from the first encoding format to the second encoding format supported by its own IDE. After the encoding format of the first upgrade file is converted, and the second upgrade file with the second encoding format is obtained, the controller program is upgraded through the second upgrade file with the converted encoding format.

[0091] In the embodiment of the present application, after receiving the OTA upgrade file, it automatically determines whether the encoding format of the OTA upgrade file is supported, and when the encoding format of the received OTA upgrade file is different from the encoding format supported by its own IDE, it automatically performs format conversion on the encoding format of the OTA upgrade file, and upgrades its own controller program through the file after format conversion, realizing the generality of the OTA upgrade file.

[0092] In some embodiments of the present application, optionally, the step of performing format conversion processing on the first upgrade file to obtain the second upgrade file includes: determining the corresponding format conversion command according to the first encoding format and the second encoding format; performing format conversion processing on the first upgrade file based on the format conversion command and the image file conversion tool to obtain the second upgrade file.

[0093] In this embodiment, different encoding formats can be converted through a file conversion tool, where the file conversion tool can be an open-source tool for image files. Exemplarily, the file conversion tool is srec_cat, which is an open-source tool and can run on multiple operating systems such as Linux, Windows, and Mac OS X.

[0094] When converting the encoding format of the upgrade file through the file conversion tool, it is necessary to clarify the encoding format of the input file and the encoding format of the target file. After receiving the first upgrade file, determine the current encoding format of the first upgrade file, that is, the first encoding format, and at the same time, in combination with the second encoding format supported by the IDE integrated in the device-side system, determine the corresponding format conversion command.

[0095] Taking the file conversion tool as srec_cat as an example, according to the input format and the output format, that is, the first encoding format and the second encoding format of the received first upgrade file, determine the srec_cat conversion command, convert the encoding format of the first upgrade file through srec_cat, generate the second upgrade file with the second encoding format, and upgrade the controller program through the second upgrade file.

[0096] In the embodiments of the present application, a file conversion tool is used to convert the encoding format of the received OTA upgrade file, which has a fast response speed and low consumption of system resources, facilitating wide deployment on device platforms with different hardware performances and reducing the difficulty of OTA upgrades.

[0097] In some embodiments of the present application, optionally, after the step of receiving the first upgrade file, the upgrade method further includes: determining the encoding format of the first upgrade file according to the suffix name of the first upgrade file.

[0098] In this embodiment, upgrade files with different encoding formats also have different suffix names. For example, the suffix name of a binary file encoding format, that is, a Bin format upgrade file, is generally ".bin", the suffix name of a hexadecimal file encoding format, that is, a Hex format upgrade file, is generally ".hex", and the suffix names of S-Record format upgrade files generally include ".s19", ".37", ".srec", and ".mot", etc.

[0099] Therefore, after receiving the first upgrade file, the encoding format of the first upgrade file can be determined according to its suffix name without performing operations such as unpacking and decoding on the first upgrade file.

[0100] In the embodiments of the present application, the encoding format of the received OTA upgrade file is determined according to its suffix name, and when the encoding format of the OTA upgrade file is different from its own IDE, it is automatically converted. Therefore, when pushing OTA upgrades, it is not necessary to develop OTA upgrade files with different encoding formats one by one, nor to distinguish the IDE of the host computer of each existing device, avoiding duplicate work, reducing the difficulty of OTA upgrades, and improving the efficiency of OTA upgrades.

[0101] In some embodiments of the present application, optionally, the step of upgrading the controller program with the second upgrade file includes: writing the second upgrade file into a memory, the memory is signal-connected to the controller, and the controller is associated with the controller program; the controller reads the second upgrade file in the memory to upgrade the controller program.

[0102] In this embodiment, the upgrade method of the controller program can be applied to electrical devices such as photovoltaic energy storage devices. The photovoltaic energy storage device includes a host computer, and the host computer is used to control each electrical device in the photovoltaic energy storage device to achieve different device functions.

[0103] Exemplarily, the host computer can be a device such as a microcomputer, an embedded system, or an engineering machine. A controller is provided in the host computer. Exemplarily, the controller can be an embedded controller, a DSP controller, an ARM, etc. The controller realizes different device functions by executing the controller program.

[0104] The memory is signal - connected to the controller. The controller can read the programs or instructions stored in the memory to control different electrical modules in the device to perform corresponding operations.

[0105] Exemplarily, the memory can be the flash memory of a microcontroller. Exemplarily, the microcontroller includes an MCU (Micro Controller Unit), an EEPROM (Electrically EPROM, Electrically Erasable Programmable Read - Only Memory), a NOR Flash (NOR - type flash memory), or a NAND Flash (NAND flash memory), etc.

[0106] After converting the data format of the received first upgrade file, the obtained second upgrade file is burned into the memory through the host computer. The controller can access and read the second upgrade file stored in the memory, and upgrade or maintain the controller program.

[0107] Before burning the OTA upgrade file into the memory in the embodiments of the present application, the data format of the OTA upgrade file is judged and converted, so that the OTA upgrade file with incompatible data format can be automatically converted into an upgrade file with compatible data format, improving the efficiency of OTA upgrade.

[0108] In some embodiments of the present application, optionally, before the step of writing the second upgrade file into the memory, the upgrade method further includes: converting the source code data of the second upgrade file into machine - code data; the step of writing the second upgrade file into the memory includes: writing the machine - code data into the memory.

[0109] In this embodiment, the source code of the OTA upgrade file pushed by the cloud is generally written in programming statements such as C language or assembly language. In a typical application program, in order to implement the operation of the upgrade program, the OTA upgrade file needs to be converted into machine code through modules such as a compiler or an assembler. The OTA file's source code composed of programming statements is converted into machine code. Among them, machine code is also machine instructions. Machine instructions are command encodings when the central processing unit of a computer executes operations, and their structure is a specific binary number sequence composed of 1s and 0s.

[0110] After converting the data format of the received first upgrade file to obtain a second upgrade file, the source code of the second file is converted into machine code recognizable by the controller through modules such as a compiler or an assembler, and the machine code is written into the memory.

[0111] At this time, the controller can read and access the machine code in the memory and perform corresponding upgrade operations according to the machine code.

[0112] Before writing the second upgrade file with the converted data format into the memory, the embodiment of the present application converts the source code of the second upgrade file into machine code that can be directly read and recognized by the controller, enabling the controller to directly read and access the machine code, thereby performing the corresponding upgrade operation and improving the efficiency of OTA upgrade.

[0113] In some embodiments of the present application, optionally, the encoding format includes: Bin encoding format, Hex encoding format, and S-record encoding format.

[0114] In this embodiment, the encoding format of the OTA upgrade file includes the Bin encoding format. The content of the upgrade file in the Bin encoding format is a single binary encoding without task information, which is simple and direct. The controller can complete the upgrade by overwriting the data according to the address indicated in the upgrade file.

[0115] The encoding format of the OTA upgrade file includes the Hex encoding format. The upgrade file in the Hex encoding format is a hexadecimal file, including ASCII text lines (records), and the text records cover contents such as memory address, type, length, and data.

[0116] The encoding format of the OTA upgrade file includes the S-record encoding format. The upgrade file in the S-record encoding format conveys the hexadecimal values of binary information in the form of ASCII text and is usually used for programming the flash memory in programmable logic devices.

[0117] By setting the encoding format to the Bin encoding format, Hex encoding format, or S-record encoding format, the embodiment of the present application has low development difficulty and good versatility, and can reduce the difficulty of OTA upgrade.

[0118] In some embodiments of the present application, Figure 2 shows a flowchart of the upgrade method for the controller program of some embodiments of the present application, as Figure 2 shown, the method includes:

[0119] Step 202, introducing the OTA file in the original format;

[0120] Step 204, input format judgment;

[0121] Step 206, performing Srec_cat command conversion according to the input format;

[0122] Step 208, generating the OTA file in the target format;

[0123] Step 210, introducing and transmitting by the OTA host computer.

[0124] In some embodiments of the present application, an upgrade device for the controller program is provided,Figure 3 The structural block diagram of the upgrade device for the controller program of some embodiments of the present application is shown. As Figure 3 shown, the upgrade device 300 for the controller program includes: a receiving module 302, configured to receive a first upgrade file; a determining module 304, configured to determine a second upgrade file according to the encoding format of the first upgrade file, where the second upgrade file is used to upgrade the controller program; and an upgrade module 306, configured to upgrade the controller program by using the second upgrade file.

[0125] In this embodiment, the controller program can be run by the controller in the device, so as to implement different device functions. For example, the device includes electrical devices, such as photovoltaic energy storage devices, power transformation devices, inverter devices, etc., and the device also includes household appliances, such as central air conditioners, kitchen and bathroom appliances, household cleaning devices, etc.

[0126] Taking the photovoltaic energy storage device as an example, the photovoltaic energy storage device can store the electric energy generated by the photovoltaic power generation device in the battery pack, and convert the direct current signal output by the battery pack into an alternating current signal identical to the power grid for use as household electricity of users. Among them, in order to ensure electricity safety, the photovoltaic energy storage device generally integrates battery management functions and insulation detection functions. These functions are realized by running the controller program in the controller of the upper computer of the photovoltaic energy storage device.

[0127] Exemplarily, the controller can be an embedded controller, a DSP (Digital Signal Processing) controller, an ARM (Advanced RISC Machine) microprocessor, etc.

[0128] With product iteration, the above functions will also be continuously improved and updated. When the functions are updated, in order to enable existing devices to synchronously update functions, device manufacturers will perform function upgrades on existing devices through OTA upgrade.

[0129] The OTA upgrade files include various encoding formats. For example, the common encoding formats of OTA upgrade files include Bin (binary file) format, Hex (hexadecimal file) format, and S-Record format, etc. Among them, the content of the Bin format file is a single binary encoding (RawData) without task information, which is simple and direct. The Hex format file includes ASCII text lines (records), and the text records cover content such as memory address, type, length, data, etc. The content of the S-Record format file is similar to that of the Hex format file.

[0130] However, the Integrated Development Environments (IDEs) in the host computers of devices of different models and batches are different, so the supported encoding formats are also different. For example, the IDE integrated in device A supports the Bin format, and the IDE integrated in device B supports the Hex format. Then, it is necessary to separately edit the upgrade files in the Bin format and the Hex format for device A and device B respectively, resulting in the need to "reinvent the wheel", which reduces the efficiency of OTA upgrades.

[0131] In view of the above situation, in the embodiment of the present application, on the device terminal side, a process for identifying and converting the encoding format of the OTA upgrade file is set. Thus, when device manufacturers perform OTA upgrades on devices of different batch models, there is no need to develop OTA upgrade files in different encoding formats one by one, nor to distinguish the IDEs of the host computers of each existing device.

[0132] Specifically, after the device receives an OTA upgrade file, such as the above-mentioned first upgrade file, it identifies the encoding format of the received OTA upgrade file, and based on the encoding format of the received OTA upgrade file, automatically generates a second upgrade file that can upgrade the controller in the host computer of the current device, that is, the encoding format of which matches the encoding format supported by the IDE of the current host computer. That is, it can automatically convert the encoding format of the received OTA upgrade file to obtain an upgrade file that matches the encoding format supported by its own IDE. Therefore, regardless of which encoding format the OTA upgrade file pushed by the manufacturer adopts, the terminal device can upgrade and maintain its own controller program through the received OTA upgrade file.

[0133] The embodiment of the present application can automatically convert the encoding format of the OTA upgrade file on the device terminal side. Therefore, the manufacturer only needs to develop an OTA upgrade file in one encoding format to perform OTA upgrades on all deployed terminal devices, without the need to develop OTA upgrade files in different encoding formats one by one, nor to distinguish the IDEs of the host computers of each existing device, avoiding the work of reinventing the wheel, reducing the difficulty of OTA upgrades, and improving the efficiency of OTA upgrades.

[0134] In some embodiments of the present application, optionally, the upgrade device of the controller program further includes: a conversion module, configured to perform format conversion processing on the first upgrade file to obtain a second upgrade file when the first encoding format corresponding to the first upgrade file is different from the second encoding format corresponding to the controller program; a determination module, further configured to determine the first upgrade file as the second upgrade file when the first encoding format is the same as the second encoding format; wherein, the encoding format of the second upgrade file is the second encoding format.

[0135] In this embodiment, when the device terminal receives an OTA upgrade file, such as the first upgrade file described above, it first identifies the encoding format of the received first upgrade file. After determining the first encoding format of the first upgrade file, the device determines whether the first encoding format of the first upgrade file is the same as the second encoding format corresponding to the controller of its own host computer, that is, the encoding format supported by its own IDE.

[0136] If the first encoding format of the first upgrade file is the same as the second encoding format supported by its own IDE, the device can perform OTA upgrade through the first upgrade file without converting the encoding format of the first upgrade file. At this time, the first upgrade file is determined as the second upgrade file, and the controller program can be upgraded through the second upgrade file.

[0137] If the first encoding format of the first upgrade file is different from the second encoding format supported by its own IDE, it is necessary to convert the encoding format of the first upgrade file. Specifically, the encoding format of the first upgrade file is converted from the first encoding format to the second encoding format supported by its own IDE. After converting the encoding format of the first upgrade file, after obtaining the second upgrade file with the second encoding format, the controller program is upgraded through the second upgrade file with the converted encoding format.

[0138] In the embodiment of the present application, after receiving the OTA upgrade file, it automatically determines whether the encoding format of the OTA upgrade file is supported, and when the encoding format of the received OTA upgrade file is different from the encoding format supported by its own IDE, it can automatically convert the encoding format of the OTA upgrade file, and upgrade its own controller program through the file with the converted format, realizing the universality of the OTA upgrade file.

[0139] In some embodiments of the present application, optionally, the determination module is further configured to determine a corresponding format conversion command according to the first encoding format and the second encoding format; the conversion module is further configured to perform format conversion processing on the first upgrade file based on the format conversion command and the image file conversion tool to obtain the second upgrade file.

[0140] In this embodiment, different encoding formats can be converted through a file conversion tool, where the file conversion tool can be an open-source tool for image files. Exemplarily, the file conversion tool is srec_cat, which is an open-source tool and can run on multiple operating systems, such as Linux, Windows, and Mac OS X.

[0141] When converting the encoding format of the upgrade file through a file conversion tool, it is necessary to clarify the encoding format of the input file and the encoding format of the target file. After receiving the first upgrade file, determine the current encoding format of the first upgrade file, that is, the first encoding format, and at the same time, in combination with the second encoding format supported by the IDE integrated in the device-side system, determine the corresponding format conversion command.

[0142] Taking the file conversion tool srec_cat as an example, according to the input format and output format, that is, the first encoding format and the second encoding format of the received first upgrade file, determine the srec_cat conversion command, and use srec_cat to convert the encoding format of the first upgrade file to generate a second upgrade file in the second encoding format, and upgrade the controller program through the second upgrade file.

[0143] In the embodiment of the present application, the encoding format of the received OTA upgrade file is converted through a file conversion tool, with fast response speed and low consumption of system resources, which is conducive to realizing wide deployment on device platforms with different hardware performances and reducing the difficulty of OTA upgrade.

[0144] In some embodiments of the present application, optionally, the determining module is further configured to determine the encoding format of the first upgrade file according to the suffix name of the first upgrade file.

[0145] In this embodiment, upgrade files with different encoding formats have different suffix names. For example, the suffix name of a binary file encoding format, that is, an upgrade file in Bin format, is generally ".bin", the suffix name of a hexadecimal file encoding format, that is, an upgrade file in Hex format, is generally ".hex", and the suffix names of S-Record format upgrade files generally include ".s19", ".37", ".srec", and ".mot", etc.

[0146] Therefore, after receiving the first upgrade file, the encoding format of the first upgrade file can be determined according to the suffix name of the first upgrade file, without performing operations such as unpacking and decoding on the first upgrade file.

[0147] The embodiment of the present application determines the encoding format of the received OTA upgrade file according to its suffix name, and automatically converts it when the encoding format of the OTA upgrade file is different from its own IDE. Therefore, when pushing OTA upgrades, it is not necessary to develop OTA upgrade files in different encoding formats one by one, nor to distinguish the IDEs of the upper computers of each existing device, avoiding duplicate work, reducing the difficulty of OTA upgrade, and improving the efficiency of OTA upgrade.

[0148] In some embodiments of the present application, optionally, the upgrade device for the controller program further includes: a storage module for writing the second upgrade file into a memory, the memory being signal-connected to the controller, and the controller being associated with the controller program; a reading module for the controller to read the second upgrade file in the memory to upgrade the controller program.

[0149] In this embodiment, the upgrade method for the controller program can be applied to electrical devices such as photovoltaic energy storage devices. The photovoltaic energy storage device includes a host computer, and the host computer is used to control each electrical component in the photovoltaic energy storage device, so as to realize different device functions.

[0150] Exemplarily, the host computer can be a device such as a microcomputer, an embedded system, or an engineering machine. A controller is provided in the host computer. Exemplarily, the controller can be an embedded controller, a DSP controller, an ARM, etc. The controller realizes different device functions by executing the controller program.

[0151] The memory is signal-connected to the controller, and the controller can read the programs or instructions stored in the memory to control different electrical modules in the device to perform corresponding operations.

[0152] Exemplarily, the memory can be the flash memory of a microcontroller. Exemplarily, the microcontroller includes an MCU (Micro Controller Unit), an EEPROM (Electrically EPROM), a NOR Flash, or a NAND Flash, etc.

[0153] After converting the data format of the received first upgrade file, the obtained second upgrade file is burned into the memory through the host computer. The controller can access and read the second upgrade file stored in the memory, and upgrade or maintain the controller program.

[0154] Before burning the OTA upgrade file into the memory in the embodiments of the present application, the data format of the OTA upgrade file is judged and converted, so that the OTA upgrade file with an incompatible data format can be automatically converted into an upgrade file with a compatible data format, improving the efficiency of OTA upgrade.

[0155] In some embodiments of the present application, optionally, the conversion module is further used to convert the source code data of the second upgrade file into machine code data; the storage module is further used to write the machine code data into the memory.

[0156] In this embodiment, the source code of the OTA upgrade file pushed by the cloud is generally written using programming statements such as C language or assembly language. In a typical application program, to implement the operation of the upgrade program, the OTA upgrade file needs to be converted into machine code through modules such as a compiler or an assembler. The source code composed of programming statements in the OTA file is converted into machine code. Among them, machine code is also known as machine instructions. Machine instructions are command encodings when the central processing unit of a computer executes operations, and their structure is a specific binary number sequence composed of 1s and 0s.

[0157] After converting the data format of the received first upgrade file to obtain a second upgrade file, the source code of the second file is converted into machine code that can be recognized by the controller through modules such as a compiler or an assembler, and the machine code is written into the memory.

[0158] At this time, the controller can read and access the machine code in the memory and perform corresponding upgrade operations according to the machine code.

[0159] In the embodiment of the present application, before writing the second upgrade file with the converted data format into the memory, the source code of the second upgrade file is converted into machine code that can be directly read and recognized by the controller, so that the controller can directly read and access the machine code, thereby performing corresponding upgrade operations and improving the efficiency of OTA upgrades.

[0160] In some embodiments of the present application, optionally, the encoding formats include: Bin encoding format, Hex encoding format, and S-record encoding format.

[0161] In this embodiment, the encoding format of the OTA upgrade file includes the Bin encoding format. The content of the upgrade file in the Bin encoding format is a single binary encoding without task information, which is simple and direct. The controller can complete the upgrade by overwriting the data according to the address indicated in the upgrade file.

[0162] The encoding format of the OTA upgrade file includes the Hex encoding format. The upgrade file in the Hex encoding format is a hexadecimal file, including ASCII text lines (records). The text records cover contents such as memory addresses, types, lengths, and data.

[0163] The encoding format of the OTA upgrade file includes the S-record encoding format. The upgrade file in the S-record encoding format conveys the hexadecimal values of binary information in the form of ASCII text and is usually used for programming the flash memory in programmable logic devices.

[0164] By setting the encoding format to the Bin encoding format, Hex encoding format, or S-record encoding format in the embodiment of the present application, the development difficulty is low and the versatility is good, which can reduce the difficulty of OTA upgrades.

[0165] In some embodiments of the present application, an upgrading device for a controller program is provided. Figure 4 The structural block diagram of the upgrading device for the controller program according to some embodiments of the present application is shown. As Figure 4 shown, the upgrading device 400 for the controller program includes: a memory 402 for storing programs or instructions; a processor 404 for implementing the steps of the upgrading method for the controller program provided in any of the above embodiments when executing the programs or instructions, and can achieve the same technical effects. To avoid repetition, it will not be elaborated here.

[0166] In some embodiments of the present application, a readable storage medium is provided, on which programs or instructions are stored. When the programs or instructions are executed by a processor, the steps of the upgrading method for the controller program provided in any of the above embodiments are implemented, and the same technical effects can be achieved. To avoid repetition, it will not be elaborated here.

[0167] In some embodiments of the present application, an electronic device is provided, including: the upgrading device for the controller program provided in any of the above embodiments; and / or the readable storage medium provided in any of the above embodiments, and thus also includes all its beneficial effects. To avoid repetition, it will not be elaborated here.

[0168] The methods can be implemented in various different ways according to specific features and / or example applications. For example, these methods can be implemented by a combination of hardware, firmware, and / or software. For example, in a hardware implementation, the processor can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, electronic devices, other device units for performing the above functions, and / or combinations thereof.

[0169] A computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. A computer-readable storage medium can be an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing devices, without limitation. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disks (DVDs), memory cards, floppy disks, encoding mechanical devices (such as punched cards or grooves with raised structures having instructions recorded thereon), and any suitable combination of the foregoing devices. A computer-readable storage medium as used herein should not be construed as a signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium, or an electrical signal transmitted through a wire, etc.

[0170] In the description of the present application, the term "a plurality of" means two or more, unless otherwise clearly defined. The orientation or positional relationship indicated by terms such as "upper", "lower", etc. is based on the orientation or positional relationship shown in the drawings, and is only for the convenience of describing the present application and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and thus should not be construed as a limitation to the present application; terms such as "connected", "installed", "fixed", etc. should all be understood in a broad sense. For example, "connected" can be a fixed connection, a detachable connection, or an integral connection; it can be directly connected, or indirectly connected through an intermediate medium. For those of ordinary skill in the art, the specific meanings of the above terms in the present application can be understood according to specific circumstances.

[0171] In the description of the present application, the description of terms such as "one embodiment", "some embodiments", "specific embodiments", etc. means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the present application, the schematic representations of the above terms do not necessarily refer to the same embodiment or instance. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples.

[0172] The foregoing is only the preferred embodiment of the present application and is not used to limit the present application. For those skilled in the art, the present application can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the protection scope of the present application.

Claims

1. A method for upgrading a controller program, characterized in that Including: Receiving a first upgrade file; Determining a second upgrade file according to the encoding format of the first upgrade file, where the second upgrade file is used to upgrade the controller program; Upgrading the controller program by the second upgrade file.

2. The upgrade method according to claim 1, wherein The step of determining the second upgrade file according to the encoding format of the first upgrade file includes: In the case where the first encoding format corresponding to the first upgrade file is different from the second encoding format corresponding to the controller program, performing format conversion processing on the first upgrade file to obtain the second upgrade file; or In the case where the first encoding format is the same as the second encoding format, determining the first upgrade file as the second upgrade file; Wherein, the encoding format of the second upgrade file is the second encoding format.

3. The upgrade method according to claim 2, wherein The step of performing format conversion processing on the first upgrade file to obtain the second upgrade file includes: Determining a corresponding format conversion command according to the first encoding format and the second encoding format; Performing format conversion processing on the first upgrade file based on the format conversion command and an image file conversion tool to obtain the second upgrade file.

4. The upgrade method according to claim 1, characterized in that, After the step of receiving the first upgrade file, the upgrade method further includes: Determining the encoding format of the first upgrade file according to the suffix name of the first upgrade file.

5. The upgrade method according to any one of claims 1 to 4, characterized in that The step of upgrading the controller program by the second upgrade file includes: Writing the second upgrade file into a memory, where the memory is signal-connected to a controller, and the controller is associated with the controller program; The controller reads the second upgrade file in the memory to upgrade the controller program.

6. The upgrade method according to claim 5, wherein Before the step of writing the second upgrade file into the memory, the upgrade method further includes: Converting the source code data of the second upgrade file into machine code data; The step of writing the second upgrade file into the memory includes: Writing the machine code data into the memory.

7. The upgrade method according to any one of claims 1 to 4, characterized in that, The encoding format includes: Bin encoding format, Hex encoding format, and S-record encoding format.

8. An upgrade device for a controller program, characterized in that Including: A receiving module, configured to receive a first upgrade file; A determining module, configured to determine a second upgrade file according to the encoding format of the first upgrade file, where the second upgrade file is used to upgrade the controller program; An upgrading module, configured to upgrade the controller program by the second upgrade file.

9. An upgrade device for a controller program, characterized in that, Including: A memory, configured to store programs or instructions; A processor, configured to implement the steps of the upgrade method of the controller program as described in any one of claims 1 to 7 when executing the programs or instructions.

10. A readable storage medium having a program or instructions stored thereon, characterized in that, When the programs or instructions are executed by the processor, the steps of the upgrade method of the controller program as described in any one of claims 1 to 7 are implemented.

11. An electronic device, characterized in that, Including: The upgrade device of the controller program as described in claim 8 or 9; And / or The readable storage medium as described in claim 10.

Images