Display device, adapter and device upgrading method

Abstract

The embodiment of the invention belongs to the equipment upgrading technology, and provides a display device, an adapter and an equipment upgrading method.The equipment upgrading method comprises the steps that under the condition that an upgrading file is recognized, according to the upgrading priority of the upgrading file, the sending sequence of the upgrading file is determined, the sending sequence is used for representing a dependency relationship between software change points corresponding to different upgrading files; for at least part of two adjacent upgrading files in the sending sequence, taking the previous upgrading file in the two adjacent upgrading files as a first upgrading file, taking the later upgrading file as a second upgrading file, and sending the first upgrading file to an adapter; and sending a second upgrading file to the adapter under the condition of determining that the upgrading result corresponding to the first upgrading file is successful. According to the method, a proper upgrading mechanism can be provided, and it is ensured that multi-device upgrading can be achieved more reliably and more efficiently.

Description

Technical Field

[0001] The embodiments of the present application relate to device upgrade technology, and more specifically, to a display device, an adapter, and a device upgrade method. Background Art

[0002] In the relevant technical solutions, the main device generally communicates with each device separately. If multiple devices are involved in upgrading, the main device will match each received upgrade data packet with each discovered device separately until the target device corresponding to each upgrade data packet is matched, and then the upgrade will be started.

[0003] Because each upgrade data packet is discovered and matched to the target device at different times, the upgrade process for multiple devices is chaotic and disorganized. This disorganized and disorganized upgrade process results in multiple devices not meeting actual requirements, requiring re-upgrades. This wastes significant time and reduces the efficiency of multiple device upgrades.

[0004] Therefore, a suitable upgrade mechanism needs to be established to ensure that multiple devices can be upgraded more reliably and efficiently. Summary of the Invention

[0005] The embodiment of the present application provides a display device that can establish a suitable upgrade mechanism to ensure the reliability of multi-device upgrades in a multi-device nested connection scenario.

[0006] In a first aspect, an embodiment of the present application provides a display device, including:

[0007] At least one processor, the processor being configured to:

[0008] When an upgrade file is identified, determining a sending order for the upgrade file based on its upgrade priority, wherein the sending order is used to characterize the dependency relationship between software change points corresponding to different upgrade files;

[0009] For the two upgrade files that are at least partially adjacent in the sending sequence, the earlier upgrade file in the two adjacent upgrade files is used as the first upgrade file, and the later upgrade file is used as the second upgrade file, and the first upgrade file is sent to the adapter;

[0010] When it is determined that the upgrade result corresponding to the first upgrade file is successful, a second upgrade file is sent to the adapter, wherein the upgrade file is used to upgrade the adapter or the remote controller corresponding to the adapter.

[0011] In the above embodiment, upgrade priorities are set for different upgrade files, and the upgrade priorities define the sending order. When sending at least partially adjacent two upgrade files in the order, the second upgrade file that is sorted later in the two adjacent upgrade files is sent only when the upgrade result corresponding to the first upgrade file that is sorted earlier is set to be successful. By flexibly setting the upgrade priority, the upgrade order between multiple devices can be flexibly set to solve the problem of multi-device version dependency. In addition, the upgrade results of multiple devices are made to be more in line with actual needs, ensuring that the dependency relationship is correct (such as upgrading the underlying driver first and then upgrading the upper-level application), and because the upgrade is strictly carried out step by step according to the upgrade priority, stable and reliable upgrades of multiple devices can be achieved. Compared with the related technical solutions where the upgrade of multiple devices is disordered and messy, which sometimes requires re-upgrade and reduces the efficiency of multi-device upgrades, the solution provided in this embodiment controls the upgrade order between multiple devices so that the upgrade results of multiple devices meet actual needs, do not need to be re-upgraded, save multi-device upgrade time, and improve multi-device upgrade efficiency.

[0012] In addition, the upgrade file name directly carries the upgrade priority, without the need for additional configuration files, which simplifies version management and significantly reduces maintenance costs.

[0013] Furthermore, the display device only needs to communicate with the adapter, reducing the complexity of managing multiple devices. The adapter also provides feedback to the display device regarding upgrade results, creating a closed-loop control system. Compared to related solutions where the display device directly connects to all devices, this embodiment achieves centralized management through devices that communicate directly with the display device, making it more suitable for complex device networks.

[0014] In a second aspect, an embodiment of the present application provides an adapter, comprising:

[0015] At least one processor, the processor being configured to:

[0016] Receiving a first upgrade file sent by a display device; wherein the upgrade file is sent according to a sending order determined by the display device based on an upgrade priority of the upgrade file; the sending order is used to represent a dependency relationship between software change points corresponding to different upgrade files;

[0017] After determining that the upgrade corresponding to the first upgrade file is completed, sending an instruction indicating that the upgrade of the first upgrade file is successful to the display device;

[0018] A second upgrade file is received from the display device, wherein the second upgrade file is sent by the display device when it is determined that the upgrade result corresponding to the first upgrade file is successful; among the at least partially adjacent two upgrade files in the sending order, the earlier upgrade file of the two adjacent upgrade files is the first upgrade file, and the later upgrade file is the second upgrade file.

[0019] In the above embodiment, upgrade priorities are set for different upgrade files, and the upgrade priorities define the sending order. For the second upgrade file that is sorted later in the two upgrade files that are at least partially adjacent in the sending order, it is set that the second upgrade file will not be sent until the first upgrade file is successfully upgraded. By flexibly setting the upgrade priority, the upgrade order between multiple devices can be flexibly set to solve the problem of multi-device version dependency. In addition, the upgrade results of multiple devices are more in line with actual needs, ensuring that the dependency relationship is correct (such as upgrading the underlying driver first and then upgrading the upper-level application), and because the upgrade is strictly carried out step by step according to the upgrade priority, stable and reliable upgrades of multiple devices can be achieved. Compared with the related technical solutions where the upgrades of multiple devices are disordered and messy, which sometimes require re-upgrades and reduce the efficiency of multi-device upgrades, the solution provided by this embodiment controls the upgrade order between multiple devices so that the upgrade results of multiple devices meet actual needs, do not need to be re-upgraded, save multi-device upgrade time, and improve multi-device upgrade efficiency.

[0020] In addition, the upgrade file name directly carries the upgrade priority, without the need for additional configuration files, which simplifies version management and significantly reduces maintenance costs.

[0021] Furthermore, the display device only needs to communicate with the adapter, reducing the complexity of managing multiple devices. The adapter also provides feedback to the display device regarding upgrade results, creating a closed-loop control system. Compared to related solutions where the display device directly connects to all devices, this embodiment achieves centralized management through devices that communicate directly with the display device, making it more suitable for complex device networks. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the implementation methods in the embodiments of the present application or related technologies, the following is a brief introduction to the drawings required for use in the embodiments or related technology descriptions. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0023] Figure 1 A schematic diagram of a display device provided in accordance with an embodiment of the present application;

[0024] Figure 2 Another schematic diagram of a display device provided by one embodiment of the present application;

[0025] Figure 3 Another schematic diagram of a display device provided by one embodiment of the present application;

[0026] Figure 4 Another schematic diagram of a display device provided by one embodiment of the present application;

[0027] Figure 5 A schematic diagram of a flow chart of a device upgrade method provided in one embodiment of the present application;

[0028] Figure 6 Another flowchart of a device upgrade method provided in one embodiment of the present application;

[0029] Figure 7 Another flowchart of a device upgrade method provided in one embodiment of the present application;

[0030] Figure 8 Another flowchart of a device upgrade method provided in one embodiment of the present application;

[0031] Figure 9 Another flowchart of a device upgrade method provided in one embodiment of the present application;

[0032] Figure 10 A schematic diagram of the interaction between a display device, an adapter, and a remote control provided in one embodiment of the present application;

[0033] Figure 11 A flowchart of the interaction between SOC and UWB provided in one embodiment of the present application;

[0034] Figure 12 Another flowchart of a device upgrade method provided in one embodiment of the present application;

[0035] Figure 13 A timing diagram of the interaction between a display device, an adapter, and a remote control provided in one embodiment of the present application;

[0036] Figure 14 A schematic diagram of a device upgrading apparatus provided in one embodiment of the present application;

[0037] Figure 15 A schematic diagram of a device upgrading apparatus provided in another embodiment of the present application. DETAILED DESCRIPTION

[0038] The following embodiments are described in detail, with examples illustrated in the accompanying drawings. When the following description refers to the drawings, identical numbers in different figures represent identical or similar elements unless otherwise indicated. The embodiments described in the following embodiments are not intended to represent all possible implementations consistent with the present application. They are merely examples of systems and methods consistent with certain aspects of the present application, as detailed in the claims.

[0039] It should be noted that the brief descriptions of terms in this application are only for the purpose of facilitating the understanding of the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise specified, these terms should be understood according to their ordinary and usual meanings.

[0040] In the specification and claims of this application and the accompanying drawings, the terms "first," "second," "third," etc. are used to distinguish similar or similar objects or entities, and are not necessarily intended to limit a particular order or sequence, unless otherwise noted. It should be understood that the terms used in this manner are interchangeable under appropriate circumstances.

[0041] The terms "comprise," "include," and "have," and any variations thereof, are intended to cover but not exclude inclusion; for example, a product or device comprising a list of components is not necessarily limited to all the components expressly listed but may include other components not expressly listed or inherent to such product or device.

[0042] The term "module" refers to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code that is capable of performing the functionality associated with that element.

[0043] In the embodiments of the present application, the display device 200 generally refers to a device capable of displaying images and processing data. For example, the display device 200 includes but is not limited to a smart TV, a mobile terminal, a computer, a monitor, an advertising screen, a wearable device, a virtual reality device, an augmented reality device, etc.

[0044] Figure 1 This is a schematic diagram of an operation scenario between a display device and a control device provided in some embodiments of the present application. Figure 1 As shown in FIG, a user can operate the display device 200 through touch operation, the mobile terminal 300 and the control device 100. For example, the control device 100 can be a remote controller, a stylus pen, a handle, etc.

[0045] The mobile terminal 300 can serve as a control device for human-computer interaction between a user and the display device 200. The mobile terminal 300 can also serve as an adapter for establishing a communication connection with the display device 200 and exchanging data. In some embodiments, the mobile terminal 300 can install software applications with the display device 200, enabling communication via a network communication protocol for one-to-one control and data communication. Audio and video content displayed on the mobile terminal 300 can also be transmitted to the display device 200 for synchronized display.

[0046] like Figure 1 As shown in FIG, the display device 200 also communicates data with the server 400 through various communication methods. The display device 200 may be allowed to communicate via a local area network (LAN), a wireless local area network (WLAN), and other networks.

[0047] The display device 200 may provide a broadcast receiving television function, and may also additionally provide an intelligent network television function with a computer support function, including but not limited to network television, smart TV, Internet Protocol television (IPTV), etc.

[0048] Figure 2 Some embodiments of this application provide Figure 1 2 is a block diagram of the hardware configuration of the display device 200.

[0049] In some embodiments, the display device 200 may include at least one of a tuner 210, a communication device 220, a detector 230, a device interface 240, a controller 250, a display 260, an audio output device 270, a memory, a power supply, and a user input interface.

[0050] In some embodiments, detector 230 is used to collect signals from the external environment or external interactions. For example, detector 230 may include a light receiver, such as a sensor for collecting ambient light intensity; or an image collector, such as a camera, for collecting external environmental scenes, user attributes, or user interaction gestures; or a sound collector, such as a microphone, for receiving external sounds.

[0051] In some embodiments, the display 260 includes a display component for presenting images and a driver component for driving image display. The display 260 is configured to receive image signals output from the controller 250 for display. For example, the display 260 can be used to display video content, image content, menu control interface components, and user control UI interfaces.

[0052] In some embodiments, the communication device 220 is a component used to communicate with an external device or server 400 according to various communication protocol types. The display device 200 can be provided with multiple communication devices 220 depending on the supported communication methods. For example, if the display device 200 supports wireless network communication, the display device 200 can be provided with a communication device 220 including WiFi functionality. If the display device 200 supports Bluetooth connection communication, the display device 200 needs to be provided with a communication device 220 including Bluetooth functionality.

[0053] The communication device 220 can establish a communication connection between the display device 200 and an external device or server 400 via a wireless or wired connection. A wired connection can connect the display device 200 to an external device via a data cable, an interface, or other components. A wireless connection can connect the display device 200 to an external device via a wireless signal or wireless network. The display device 200 can establish a connection with an external device directly or indirectly through a gateway, router, or connection device.

[0054] In some embodiments, the controller 250 may include at least one of a central processing unit (CPU), a video processor, an audio processor, a graphics processor, and a power processor, and first to nth interfaces for input / output. The controller 250 controls the operation of the display device and responds to user operations through various software control programs stored in a memory. The controller 250 controls the overall operation of the display device 200.

[0055] In some embodiments, the controller 250 and the tuner 210 may be located in different separate devices, that is, the tuner 210 may also be located in an external device of the main device where the controller 250 is located, such as an external set-top box.

[0056] In some embodiments, the user may input a user command through a graphical user interface (GUI) displayed on the display 260 , and the user input interface receives the user input command through the graphical user interface (GUI).

[0057] In some embodiments, the audio output device 270 may be a local speaker of the display device 200, or an external audio output device connected to the display device 200. For the external audio output device connected to the display device 200, the display device 200 may further be provided with an external audio output terminal, through which the audio output device may be connected to the display device 200 to output the sound of the display device 200.

[0058] In some embodiments, the user input interface 280 may be configured to receive instructions from a user.

[0059] Figure 3 Some embodiments of this application provide Figure 1 The hardware configuration diagram of the control device in the figure is as follows. Figure 3 As shown, the control device 100 may include: a controller 110, a communication interface 130, a user input / output interface, a memory, and a power supply.

[0060] The control device 100 is configured to control the display device 200 , and can receive user input operation instructions, and convert the operation instructions into instructions that the display device 200 can recognize and respond to, playing the role of an interactive intermediary between the user and the display device 200 .

[0061] In some embodiments, the control device 100 may be a smart device. For example, the control device 100 may be installed with various applications for controlling the display device 200 according to user needs.

[0062] In some embodiments, as Figure 1As shown, the mobile terminal 300 or other intelligent electronic devices can play a similar function as the control device 100 after installing the application for controlling the display device 200 .

[0063] The controller 110 includes a processor 112, RAM 113, ROM 114, a communication interface 130, and a communication bus. The controller 110 is used to control the operation and operation of the control device 100, as well as the communication and cooperation between internal components and external and internal data processing functions.

[0064] Under the control of the controller 110, the communication interface 130 communicates control signals and data signals with the display device 200. The communication interface 130 may include at least one of a WiFi chip 131, a Bluetooth module 132, an NFC module 133, or other near field communication modules.

[0065] The user input / output interface 140 includes at least one of a microphone 141 , a touch panel 142 , a sensor 143 , a button 144 and other input interfaces.

[0066] In some embodiments, the control device 100 includes at least one of a communication interface 130 and an input / output interface 140. The control device 100 is configured with the communication interface 130, such as a WiFi, Bluetooth, or NFC module, to encode user input commands via the WiFi protocol, Bluetooth protocol, or NFC protocol and transmit them to the display device 200.

[0067] The memory 190 is used to store various operating programs, data and applications for driving and controlling the control device 100 under the control of the controller. The memory 190 can store various control signal instructions input by the user.

[0068] The power supply 180 is used to provide operating power support for each component of the control device 100 under the control of the controller.

[0069] To facilitate user interaction, in some embodiments, the display device 200 may run an operating system. The operating system is a computer program for managing and controlling the hardware and software resources in the display device 200. The operating system may provide a user interface (control the display device), allow the user to interact with the display device 200, and support the running of various application programs.

[0070] It should be noted that the operating system can be a native operating system based on a specific operating platform, or a third-party operating system deeply customized based on a specific operating platform, or an independent operating system specially developed for display devices.

[0071] The operating system can be divided into different modules or layers according to the functions implemented, e.g. Figure 4 As shown, in some embodiments, the system is divided into four layers, from top to bottom, namely, the application layer (referred to as "application layer"), the application framework layer (referred to as "framework layer"), the system library layer and the kernel layer.

[0072] In some embodiments, the application layer provides services and interfaces for applications, enabling the display device 200 to run applications and interact with the user based on the applications. The application layer can host at least one application, which can include built-in window programs, system settings programs, clock programs, and the like, or applications developed by third-party developers. In specific implementations, the application packages in the application layer are not limited to the examples above.

[0073] The framework layer provides applications with an application programming interface (API) and programming framework. The application framework layer includes predefined functions. The application framework layer acts as a processing center, determining the actions taken by applications in the application layer. Through the API, applications can access system resources and services during execution.

[0074] like Figure 4 As shown, in the embodiment of the present application, the application framework layer includes a view system, managers, content providers, etc., wherein the view system can design and implement the interface and interaction of the application, and the view system includes lists, grids, text boxes, buttons, etc. The manager includes at least one of the following modules: an activity manager for interacting with all activities running in the system; a location manager for providing system services or applications with access to the system location service; a package manager for retrieving various information related to the application packages currently installed on the device; a notification manager for controlling the display and clearing of notification messages; and a window manager for managing icons, windows, toolbars, wallpapers, and desktop widgets on the user interface.

[0075] In some embodiments, the activity manager is used to manage the lifecycle of each application and common navigation back functions, such as controlling application exit, opening, and back. The window manager is used to manage all window programs, such as obtaining the display screen size, determining whether there is a status bar, locking the screen, taking screenshots, and controlling changes in display windows, such as shrinking, shaking, or distorting the display window.

[0076] In some embodiments, the system runtime layer can provide support for the framework layer. When the framework layer is used, the operating system will run the instruction library contained in the system runtime layer, such as the C / C++ instruction library, to implement the functions to be implemented by the framework layer.

[0077] In some embodiments, the kernel layer is a functional layer between the hardware and software of the display device 200. The kernel layer can implement functions such as hardware abstraction, multitasking, and memory management. Figure 4 As shown, the kernel layer can be configured with hardware drivers, and the drivers included in the kernel layer can be at least one of the following drivers: audio driver, display driver, Bluetooth driver, camera driver, WIFI driver, USB driver, HDMI driver, sensor driver (such as fingerprint sensor, temperature sensor, pressure sensor, etc.), and power driver, etc.

[0078] In some embodiments, the display device 200 includes a display 260 as described above, one or more external device interfaces, and at least one processor 112. The display 260 is configured to display content from a broadcast system, a network, or a user interface. The one or more external device interfaces are configured to communicate with one or more external devices according to a communication protocol, the communication protocol including at least a Bluetooth protocol. The processor 112 is configured to execute instructions. Specifically, the processor 112 is configured to execute the following device upgrade method applied to the display device. Reference may be made to the following description of the device upgrade method applied to the display device, which will not be repeated here.

[0079] In some embodiments, the processor is configured to: when an upgrade file is identified, determine the sending order of the upgrade file according to the upgrade priority of the upgrade file, and the sending order is used to characterize the dependency relationship between the software change points corresponding to different upgrade files; for two upgrade files that are at least partially adjacent in the sending order, use the earlier upgrade file of the two adjacent upgrade files as the first upgrade file and the later upgrade file as the second upgrade file, and send the first upgrade file to the adapter; when it is determined that the upgrade result corresponding to the first upgrade file is successful, send the second upgrade file to the adapter, wherein the upgrade file is used to upgrade the adapter or the remote control corresponding to the adapter.

[0080] In some embodiments, the processor executes a process of sending the upgrade file to the adapter, and is configured to: determine the target device for upgrading the upgrade file; if the target device meets the upgrade conditions, send the upgrade file to the adapter; the upgrade conditions include: the system image file is normal, the power is greater than the preset power, the storage status is normal, the operating status is normal, or at least one of the connection status with the display device is normal.

[0081] It should be noted that the above example is only a simple division of the operating system functions and does not constitute a limitation on the specific operating system form of the display device 200 in the embodiment of the present application. Depending on factors such as the function of the display device and the type of operating system, the number of levels and specific level types contained in the operating system may be expressed in other forms.

[0082] Some embodiments of the present application further provide an adapter. The adapter includes at least one processor configured to execute the following device upgrade method applied to the adapter. The following description of the device upgrade method applied to the adapter can be referenced and will not be repeated here.

[0083] In some embodiments, the processor is configured to: receive a first upgrade file sent by a display device; wherein the upgrade file is sent according to the sending order after the display device determines the sending order based on the upgrade priority of the upgrade file; the sending order is used to characterize the dependency relationship between the corresponding software change points of different upgrade files; after determining that the upgrade corresponding to the first upgrade file is completed, send an instruction to the display device indicating that the upgrade of the first upgrade file is successful; receive a second upgrade file sent by the display device, wherein the second upgrade file is sent by the display device when it is determined that the upgrade result corresponding to the first upgrade file is successful; among the at least partially adjacent two upgrade files in the sending order, the earlier upgrade file in the two adjacent upgrade files is the first upgrade file, and the later upgrade file is the second upgrade file.

[0084] In some embodiments, the processor executes, after determining that the upgrade corresponding to the first upgrade file is completed, sending an instruction to the display device indicating that the upgrade of the first upgrade file is successful, and is configured to: when the target product indicated by the first upgrade file is the product in the adapter, upgrade according to the first upgrade file, and send an instruction to the display device indicating that the upgrade of the first upgrade file is successful after the upgrade is completed; when the target product indicated by the first upgrade file is the product in the remote control, send the first upgrade file to the remote control, and send an instruction to the display device indicating that the upgrade of the first upgrade file is successful after receiving the upgrade success result feedback from the remote control.

[0085] In some embodiments, after receiving the first upgrade file sent by the display device, the processor is further configured to: parse to obtain the product unique code and product model of the target product indicated by the first upgrade file; if the product unique code is the same as the locally stored product unique code, determine that the target product indicated by the upgrade file is the product in the adapter; if the product unique code is different from the locally stored product unique code, determine that the target product indicated by the upgrade file is the product in the remote control.

[0086] In some embodiments, the processor includes a system-on-chip (SOC); the first upgrade file is used to upgrade the SOC; the processor executes the upgrade according to the first upgrade file, and after the upgrade is completed, sends an instruction to the display device indicating that the upgrade of the first upgrade file is successful, and is configured to: after moving the data in the first upgrade file to the SOC program backup area, verify the integrity of the first upgrade file; after the verification is passed, switch the SOC program running address to the SOC program backup area, and restart the SOC to upgrade the SOC according to the first upgrade file; if the update is successful after the SOC is restarted, it is determined that the upgrade is complete, and send an instruction to the display device indicating that the upgrade of the first upgrade file is successful.

[0087] In some embodiments, the processor also includes an ultra-wideband module UWB, and the first upgrade file is used for upgrading the UWB; the processor executes the upgrade according to the first upgrade file, and after the upgrade is completed, sends an instruction to the display device indicating that the upgrade of the first upgrade file is successful, and is configured to: move the data in the first upgrade file to the UWB based on the SOC to upgrade the UWB according to the first upgrade file; if the UWB upgrade is completed, send an instruction to the display device indicating that the upgrade of the first upgrade file is successful.

[0088] In some embodiments, the processor executes the movement of data in the first upgrade file to the UWB based on the SOC, and is configured to: read the UWB version information based on the SOC, and when the BIN file version in the upgrade file is higher than the current UWB software version, reset the UWB and output the control timing to control the UWB to enter the upgrade mode; for at least part of the data packets in the first upgrade file, when the UWB returns to normal, move the data packets to the UWB based on the SOC.

[0089] In some embodiments, when the target device for upgrading the upgrade file is an adapter, the processor is further configured to: run the upgrade program based on the upgrade file, and each time a flag is reached, if the current running order of the upgrade program is the running order represented by the flag, set the flag to be run to valid; wherein the flag is pre-set in the upgrade program to represent the running order of the upgrade program; before executing the upgrade program erase operation, if any flag is not set to valid, the upgrade program erase operation will not be executed.

[0090] The following describes how to implement a device upgrade method for a display device, using a display device processor as an example. This device upgrade method can be applied to scenarios where a display device, an adapter (dongle), and a remote control are connected. The adapter communicates directly with the display device, and the remote control communicates directly with the adapter.

[0091] The following detailed description of the technical solution of the present application is provided in conjunction with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0092] Figure 5 This is a flow chart of a device upgrade method provided by this application. Figure 5 As shown, the method includes the following steps:

[0093] S510 , when an upgrade file is identified, determining a sending order for the upgrade file according to the upgrade priority of the upgrade file, wherein the sending order is used to represent the dependency relationship between corresponding software change points of different upgrade files.

[0094] The upgrade file can be understood as an OTA (Over The Air) upgrade file. The upgrade file format can be ZIP, BIN, or other formats. The target product indicated by the upgrade file can include the product in the adapter or the product in the remote control.

[0095] For ease of understanding, the following description assumes that the upgrade file is a BIN file.

[0096] Manage the upgrade files through the display device. When an upgrade BIN file that needs to be upgraded is identified, the upgrade priority of the upgrade file is extracted.

[0097] In some scenarios, multiple devices need to be upgraded in a pre-set upgrade order. For example, every time a product (here, product can be understood as software) changes, the new product version may become incompatible with the old product version. In this case, the upgrade order of the new products needs to be adjusted according to the actual situation to ensure that the new product version is compatible with the old product version and the new product can be upgraded.

[0098] To achieve this function, it is necessary to set an upgrade priority for each BIN file used for upgrade according to the dependency of the software change points of different devices on other devices during each upgrade, and according to the order in which each BIN file is upgraded during each OTA. The upgrade priority of each upgraded BIN file can be evaluated according to each software change point, and the evaluated upgrade priority can be added to the upgrade file. When defining the upgrade priority, it is necessary to ensure that each BIN file has a unique priority definition. Correspondingly, the sending order determined by the display device according to the upgrade priority of the upgrade file is used to characterize the dependency between the corresponding software change points of different upgrade files.

[0099] The upgrade priority can be expressed as numbers, such as 1, 2, 3, and 4, or as letters, such as A, B, C, and D. It can also be expressed in other forms, which are not limited in this embodiment.

[0100] In one embodiment, the upgrade priority of the BIN file can be extracted according to the file name of the upgrade file. The upgrade priority is represented by a number. For example, if the file name of the upgrade file is CRF6A65V1.20_1.BIN, 1 represents the upgrade priority.

[0101] In one embodiment, the upgrade priority indication may also be set in the file attribute data of the upgrade file.

[0102] The OTA application of the display device extracts the upgrade priority of the BIN file of the corresponding device during OTA upgrade from the file name of the upgrade file, and sorts the upgrade files from high to low according to the upgrade priority (for example, from 1 to 4, where 1 has the highest priority). The sorting result represents the sending order of multiple upgrade files.

[0103] S520: For two upgrade files that are at least partially adjacent in the sending sequence, use the earlier upgrade file as the first upgrade file and the later upgrade file as the second upgrade file of the two adjacent upgrade files, and send the first upgrade file to the adapter.

[0104] The adapter communicates directly with the display device and has more communication protocols. It's compatible with other devices besides the display device, allowing for the forwarding of update files to other devices. For example, the adapter can communicate directly with the display device via Universal Serial Bus (USB) and with the remote control via Bluetooth Low Energy (BLE), allowing the adapter to forward update files to the remote control.

[0105] When there are multiple products that need to be upgraded, in order to ensure that the OTA application upgrades each BIN file one by one according to the order in which it is sent, the upgrade files need to be sent in the order in which they are sent. First, the first upgrade file is sent to the adapter.

[0106] S530: When it is determined that the upgrade result corresponding to the first upgrade file is successful, a second upgrade file is sent to the adapter, wherein the upgrade file is used to upgrade the adapter or the remote control corresponding to the adapter.

[0107] The upgrade result is the upgrade result of the target product.

[0108] The first upgrade file may be ranked 1 in the sending sequence, and the second upgrade file may be ranked 2. The first upgrade file may be ranked 2, and the second upgrade file may be ranked 3.

[0109] In one embodiment, for upgrade files that are not the first in the sending sequence, after confirming that the upgrade BIN file corresponding to the previous upgrade file has been successfully upgraded, the sending of the upgrade file currently to be sent is started, ensuring that all upgrade BIN files are upgraded one by one in strict accordance with the priority order, thereby improving the reliability of equipment upgrades.

[0110] In the above embodiment, upgrade priorities are set for different upgrade files, and the upgrade priorities define the sending order. When sending at least partially adjacent two upgrade files in the order, the second upgrade file that is sorted later in the two adjacent upgrade files is sent only when the upgrade result corresponding to the first upgrade file that is sorted earlier is set to be successful. By flexibly setting the upgrade priority, the upgrade order between multiple devices can be flexibly set to solve the problem of multi-device version dependency. In addition, the upgrade results of multiple devices are made to be more in line with actual needs, ensuring that the dependency relationship is correct (such as upgrading the underlying driver first and then upgrading the upper-level application), and because the upgrade is strictly carried out step by step according to the upgrade priority, stable and reliable upgrades of multiple devices can be achieved. Compared with the related technical solutions where the upgrade of multiple devices is disordered and messy, which sometimes requires re-upgrade and reduces the efficiency of multi-device upgrades, the solution provided in this embodiment controls the upgrade order between multiple devices so that the upgrade results of multiple devices meet actual needs, do not need to be re-upgraded, save multi-device upgrade time, and improve multi-device upgrade efficiency.

[0111] In addition, the upgrade file name directly carries the upgrade priority, without the need for additional configuration files, which simplifies version management and significantly reduces maintenance costs.

[0112] Furthermore, the display device only needs to communicate with the adapter, reducing the complexity of managing multiple devices. The adapter also provides feedback to the display device regarding upgrade results, creating a closed-loop control system. Compared to related solutions where the display device directly connects to all devices, this embodiment achieves centralized management through devices that communicate directly with the display device, making it more suitable for complex device networks.

[0113] For some examples, see Figure 6 The process of sending the upgrade file to the adapter includes:

[0114] S610: Determine a target device for upgrading the upgrade file.

[0115] The target device indicated by the upgrade file is determined according to the model and version information of each device that directly or indirectly communicates with the display device.

[0116] The upgrade file contains a unique product code and model number, identifying the target product. The device's model and version information includes the unique product code and model number of the product configured on the device. By comparing the unique product code and model number in the upgrade file with the device's model and version information, you can determine the target device where the target product is installed.

[0117] The OTA corresponding product unique code (i.e. the product ID value in the table) and the OTA corresponding product model can be referred to in Table 1. Table 1:

[0118]

[0119] In some embodiments, the model and version information of each device may be pre-stored before the upgrade file is identified.

[0120] S620: If the target device meets the upgrade conditions, the upgrade file is sent to the adapter.

[0121] The upgrade conditions include: the system image file is normal, the power level is greater than a preset power level, the storage status is normal, the operation status is normal, or the connection status with the display device is normal. Preferably, to improve communication reliability, the upgrade file is sent to the adapter when all conditions are met.

[0122] Insufficient battery power on the target device can prevent the upgrade from working properly. Similarly, issues such as abnormal storage status (e.g., insufficient memory, damaged memory modules), abnormal operating status (e.g., busy), or abnormal connection status (unable to communicate properly) can also prevent the upgrade from working properly. The system image file is the core file used during the device upgrade process. An abnormal system image file can prevent the upgrade from working properly, so it is necessary to verify that the system image file is functioning properly.

[0123] During the process of sending the upgrade file, it is necessary to obtain the target device's power information at least once and send the upgrade file within a preset time period when the target device's power level is greater than the preset power level to prevent the upgrade file from being received normally due to insufficient power during the sending process. The preset time period can be set based on the target device's power level obtained last time. If the target device's power level is high, the preset time period is longer; if the target device's power level is low, the preset time period is shorter. The preset power level can be set according to actual needs.

[0124] Delivering the BIN file to the target device when its system image file is normal, its battery level is above a preset level, its storage status is normal, its connection status is normal, or its operating status is normal can mitigate the risk of a target device upgrade failure. Furthermore, delivering the upgrade file within the preset duration while the target device's battery level is above a preset level can further mitigate the risk of a failed upgrade.

[0125] For easier understanding, please refer to Figure 7 The flowchart shown is for determining whether a target device meets the upgrade conditions.

[0126] Assuming the target device is a remote control, the display device connects to the remote control via BLE or USB. Hybrid communication between BLE transmission and the SPI interface enables cross-protocol compatibility. Compared to traditional remote control upgrades that require a physical connection, this embodiment achieves full wireless connectivity and supports multi-chip collaboration.

[0127] In the first step, the display device sends a host packet 3 to read the remote control model and version information, and receives the remote control model and version information replied by a response packet 10.

[0128] In the second step, when the remote control is determined to be the target device based on the remote control model and version information replied, the host package 4 is sent to read the remote control power information, and the remote control power information replied by the response package 8 is received.

[0129] In the third step, if it is determined that the power level of the remote control is greater than the preset power level, the image information (i.e., the system image file) is sent again. During the sending process, it is again determined whether the remote control is low on power (the power level is less than or equal to the preset power level). If the remote control is low on power, the remote control power level information is replied through response packet 3. If the remote control is not low on power, the external Flash of the remote control is further determined to be normal (which can be understood as determining whether the storage status is normal). If the external Flash is abnormal, the response packet 4 is used to reply that the external Flash is abnormal. If the external Flash is normal, the image information is further determined to be correct. If it is not correct, the response packet 5 is used to reply that the image information is abnormal. If it is correct, the response packet 9 is used to reply that the image information is correct. The order of judging the power level, external Flash, and image information is not necessarily the order shown in the figure. The image information can also be judged first, and then the power level and external Flash can be judged in sequence.

[0130] The fourth step is to send host package 2 to send the data packet in the upgrade file when it is determined that the power of the remote control is greater than the preset power, the image information is correct, and the external Flash is normal. Determine whether the time length for the remote control to receive the data packet has timed out, for example, whether it has timed out for 30 seconds (s) as shown in the figure. If it has timed out, end. If it has not timed out, continue to determine whether the operating status of the remote control is busy (the above-mentioned abnormal operating status includes the operating status being busy). If the operating status of the remote control is busy, the remote control replies to the remote control that it is busy through response package 12. If the operating status of the remote control is not busy, determine whether the packet sequence number of the data packet is correct. If the packet sequence number is incorrect, the remote control repeatedly requests the current data packet through response package 2. If the packet sequence number is correct, request the next data packet. Correspondingly, the display device responds to continuous requests and continues to send data packets until all the data in the upgrade file has been sent, otherwise exit.

[0131] Step 5: After the host packet 5 represents that all data in the upgrade file has been sent, the integrity of the upgrade file is verified. If the verification fails, the remote control responds with a response packet 3 indicating an upgrade file verification error. If the verification passes, it is again determined whether the remote control is low on battery. If the remote control is low on battery, the remote control responds with a response packet 8 indicating the remote control battery level and the process ends. If the remote control is not low on battery, the process proceeds to the remote control Flash upgrade and remote control Flash data processing (data migration or address switching processing, and updating of the corresponding product). Determine whether the reset is successful. If the reset is successful, the remote control responds with a response packet 11 indicating a successful remote control upgrade and the process ends. If the reset is unsuccessful, the process returns to the remote control Flash data processing.

[0132] In the above embodiment, by judging in advance whether the system image file of the target device is normal, whether the power is greater than the preset power, whether the storage status is normal, whether the operation status is normal, whether the connection status with the display device is normal, etc., some factors that lead to abnormal upgrade failures are avoided in advance, thereby improving the reliability of device upgrades.

[0133] In some embodiments, the logical data channel, data format and command definition for interactive commands between the adapter and the display device are as shown in Table 2. Table 2:

[0134]

[0135] The following describes how the adapter implements the device upgrade method by taking the adapter's processor as an example.

[0136] The following detailed description of the technical solution of the present application is provided in conjunction with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0137] Figure 8 This is a flow chart of a device upgrade method provided by this application. Figure 8 As shown, the method includes the following steps:

[0138] S810: Receive a first upgrade file sent by a display device.

[0139] The upgrade file is sent according to the sending order determined by the display device based on the upgrade priority of the upgrade file; the sending order is used to represent the dependency relationship between the corresponding software change points of different upgrade files.

[0140] For the description of display device sending upgrade files, please refer to the above description and will not be repeated here.

[0141] Regarding the processing of the upgrade file by the display device, please refer to the above description, which will not be repeated here.

[0142] S820: After determining that the upgrade of the first upgrade file is completed, send an instruction indicating that the upgrade of the first upgrade file is successful to the display device.

[0143] The unique product code and product model number carried in the upgrade file identify the target product. After receiving the first upgrade file, the device compares the unique product code and product model number carried in the first upgrade file with the locally stored unique product code and product model number. If the device determines that the target product is its own product, it upgrades the target product based on the upgrade file and sends the upgrade results to the superior device.

[0144] S830: Receive a second upgrade file sent by the display device, wherein the second upgrade file is sent by the display device when it is determined that the upgrade result corresponding to the first upgrade file is successful; among at least partially adjacent two upgrade files in the sending order, the earlier upgrade file of the two adjacent upgrade files is the first upgrade file, and the later upgrade file is the second upgrade file.

[0145] Regarding the process of the display device sending the second upgrade file, reference may be made to the above-mentioned related description, which will not be repeated here.

[0146] In the above embodiment, upgrade priorities are set for different upgrade files, and the upgrade priorities define the sending order. For the second upgrade file that is sorted later in the two upgrade files that are at least partially adjacent in the sending order, it is set that the second upgrade file will not be sent until the first upgrade file is successfully upgraded. By flexibly setting the upgrade priority, the upgrade order between multiple devices can be flexibly set to solve the problem of multi-device version dependency. In addition, the upgrade results of multiple devices are more in line with actual needs, ensuring that the dependency relationship is correct (such as upgrading the underlying driver first and then upgrading the upper-level application), and because the upgrade is strictly carried out step by step according to the upgrade priority, stable and reliable upgrades of multiple devices can be achieved. Compared with the related technical solutions where the upgrades of multiple devices are disordered and messy, which sometimes require re-upgrades and reduce the efficiency of multi-device upgrades, the solution provided by this embodiment controls the upgrade order between multiple devices so that the upgrade results of multiple devices meet actual needs, do not need to be re-upgraded, save multi-device upgrade time, and improve multi-device upgrade efficiency.

[0147] In addition, the upgrade file name directly carries the upgrade priority, without the need for additional configuration files, which simplifies version management and significantly reduces maintenance costs.

[0148] Furthermore, the display device only needs to communicate with the adapter, reducing the complexity of managing multiple devices. The adapter also provides feedback to the display device regarding upgrade results, creating a closed-loop control system. Compared to related solutions where the display device directly connects to all devices, this embodiment achieves centralized management through devices that communicate directly with the display device, making it more suitable for complex device networks.

[0149] In some embodiments, step S820 includes:

[0150] Step 1: When the target product indicated by the first upgrade file is the product in the adapter, the adapter is upgraded according to the first upgrade file, and after the upgrade is completed, an instruction indicating that the upgrade of the first upgrade file is successful is sent to the display device.

[0151] The first upgrade file carries a product unique code and a product model, based on which it is possible to determine whether the target product is the product in the adapter. If it is the product in the adapter, the adapter is upgraded according to the first upgrade file.

[0152] In step 2, when the target product indicated by the first upgrade file is the product in the remote control, the first upgrade file is sent to the remote control, and after receiving the upgrade success result feedback from the remote control, an instruction indicating that the upgrade of the first upgrade file is successful is sent to the display device.

[0153] If the target product indicated by the first upgrade file is not the user's own product but the product in the remote control, the first upgrade file is sent to the remote control and the remote control replies with the upgrade result of the target product. If the upgrade result of the target product is successful, a command indicating the success of the first upgrade file is sent to the display device.

[0154] In some embodiments, after step S810, the following steps are further included:

[0155] Step 1: parse and obtain the unique product code and product model of the target product indicated by the first upgrade file.

[0156] The upgrade file carries a unique product code and product model number, which are used to identify the target product. The target product is used to upgrade the target device. For details about the unique product code and product model number, refer to Table 1.

[0157] In some embodiments, step 1 includes verifying the integrity of the first upgrade file. If the first upgrade file is confirmed to be complete, the unique product code and product model number are parsed. The first upgrade file includes a verification code that can be used to verify integrity. If the first upgrade file is incomplete, the first upgrade file can be requested again from the superior device.

[0158] Step 2: If the product unique code is the same as the locally stored product unique code, the target product indicated by the upgrade file is determined to be the product in the adapter; if the product unique code is different from the locally stored product unique code, the target product indicated by the upgrade file is determined to be the product in the remote control.

[0159] The device's model and version information includes the unique product code and product model of the product configured on the device. By comparing the unique product code and product model in the upgrade file with the device's model and version information, you can determine the target device where the target product resides. If the target device is an adapter, the target product is the product in the adapter. If the target device is a remote control, the target product is the product in the remote control.

[0160] In some embodiments, the processor includes a system on a chip (SOC) and an ultra wideband (UWB). The first upgrade file is used for upgrading the SOC or for upgrading the UWB.

[0161] See Figure 9 The flow chart and Figure 10 The diagram of the interaction between the display device, the adapter, and the remote control shown in FIG. 1 shows that, when the first upgrade file is for upgrading the SOC, upgrading according to the first upgrade file and sending an instruction indicating that the upgrade of the first upgrade file is successful to the display device after the upgrade is completed include:

[0162] S910 , after moving the data in the first upgrade file to the SOC program backup area, verify the integrity of the first upgrade file.

[0163] The display device sends the upgrade file to the adapter's SOC via USB. The USB data transmission processing function module of the SOC is responsible for storing the data in the upgrade file in the appropriate location of the SOC and verifying the data.

[0164] When data integrity is confirmed, the device BIN file is determined by checking the unique product code and model number contained in the first upgrade file received. If the BIN file indicates that the target product is the adapter's SOC, the corresponding data is moved to the SOC program backup area and re-verified.

[0165] If the target product is a remote control SoC, the adapter activates the Bluetooth upgrade service and sends the upgrade file to the remote control via the Bluetooth GATT (Generic Attribute Profile) service (BLE data transceiver processing module). The remote control receives the data using the BLE data transceiver processing module. The remote control SoC verifies the received upgrade file, moves it to the SoC program backup area, and verifies it again.

[0166] S920: After verification, the SOC program execution address is switched to the SOC program backup area, and the SOC is restarted to upgrade the SOC according to the first upgrade file. If the SOC is successfully updated after restarting, the upgrade is determined to be complete, and a command indicating that the first upgrade file has been successfully upgraded is sent to the display device.

[0167] If the target product is the SOC in the adapter, after the verification is passed, the SOC program running address is switched to the backup area and the SOC is restarted. After the restart is successful, an instruction indicating that the first upgrade file has been successfully upgraded is sent to the display device, which is used to indicate that the SOC upgrade is successful.

[0168] If the target product is the SOC in the remote control, after verification, the OTA upgrade processing module switches the SOC program running address to the backup area and restarts the SOC. After the restart is successful, the adapter is replied with the upgrade result that the remote control SOC upgrade was successful.

[0169] In some embodiments, when the first upgrade file is for UWB upgrade, the method further includes:

[0170] Step 1: Based on the SOC, the data in the first upgrade file is moved to the UWB to upgrade the UWB according to the first upgrade file; if the UWB upgrade is completed, an instruction indicating that the upgrade of the first upgrade file is successful is sent to the display device.

[0171] If the product model carried by the first upgrade file is the local UWB model, the data is moved to the UWB module through the SPI interface based on the SOC in the adapter.

[0172] When the first upgrade file indicates the target product is the UWB module in the remote control, the adapter initiates the Bluetooth upgrade service and sends the upgrade BIN file to the remote control via the Bluetooth GATT service. The remote control's SOC verifies the received upgrade file and sends the data to the UWB module via the SPI interface. After the UWB module responds with a successful upgrade, the remote control sends a successful UWB upgrade message to the adapter. Upon receiving the command, the adapter sends a command to the display device indicating the successful upgrade of the first upgrade file. This command serves as a confirmation of the successful UWB upgrade.

[0173] In some embodiments, migrating data in the first upgrade file to the UWB based on the SOC includes:

[0174] Step 1: Read the UWB version information based on the SOC. If the BIN file version in the upgrade file is higher than the current UWB software version, reset the UWB and output the control timing to control the UWB to enter the upgrade mode.

[0175] The control sequence can be understood as the following startup command, data command, etc. Entering the upgrade mode can be understood as the following UWB sending startup response.

[0176] Step 2: for at least part of the data packets in the first upgrade file, when the UWB returns to normal, the data packets are moved to the UWB based on the SOC.

[0177] UWB can reply to the SOC once every fixed time. If the reply is abnormal, the data packet will not be moved to UWB.

[0178] In some embodiments, when a start upgrade command is sent to UWB based on SOC and UWB returns to normal, the first data packet is sent to UWB; for non-first data packets in the upgrade file, when UWB returns to normal, the non-first data packet is sent to UWB.

[0179] A normal UWB response can be understood as the following UWB response duration not exceeding the preset duration. Correspondingly, an abnormal response can be understood as the UWB response duration exceeding the preset duration.

[0180] See Figure 11 Flowchart of the interaction between SOC and UWB shown.

[0181] In the first step, the SOC reads the UWB software version number (version information) and determines whether the BIN file version is higher than the current UWB software version.

[0182] In the second step, if it is higher than that, the SOC resets the UWB, pulls down the CS (Chip Select) for 210ms and then pulls it high to activate the SPI interface of the UWB module and prepare for data transmission.

[0183] The third step is to determine whether the UWB receives a notification of entering the data transmission state, that is, whether it receives an ENTER NTF (Notification).

[0184] In the fourth step, if UWB receives the notification of entering the data transmission state, the SOC sends a start command, namely START CMD (command).

[0185] In the fifth step, UWB sends a start response, namely START RSP (Response).

[0186] In step 6, the SOC sends a data command, or DATA CMD. This command contains the data in the upgrade file to be transferred, and may also include the data format, destination address, or other related information. The UWB module will transmit data according to this command.

[0187] In the seventh step, UWB determines whether the data packet carrying the data command is a non-last packet (8N package, which can be understood as a non-last packet when the data packet is divided into 8 packets) or the last packet (last package). For both non-last and last packets, it is necessary to determine whether the duration of the UWB response acknowledgment signal (Acknowledge character, abbreviated as ACK) exceeds the preset duration (for example, 1 second in the figure). If it does not exceed the preset duration, it then determines whether UWB responds with an acknowledgment signal.

[0188] Step 8: Determine whether the duration of the UWB's QUIT RSP response exceeds the preset duration (1s shown in the figure). If it does not, determine whether the UWB has responded with a QUIT RSP response. If the UWB has responded with a QUIT NTF response, determine whether the duration of the UWB's QUIT NTF response exceeds the preset duration. If it has not, determine whether the UWB has responded with a QUIT NTF response. If the UWB has responded with a QUIT NTF response, perform a hardware reset on the UWB.

[0189] In the ninth step, in the following three cases, namely, no confirmation signal is returned in the seventh step, no stop response is returned in the eighth step, and no stop notification is returned in the eighth step, it is determined whether the number of repeated transmissions exceeds a preset number (eg, 3 times as shown).

[0190] In step 10, if the number of repeated transmissions does not exceed the preset number, the SOC repeats sending the data command and returns to step 8 until the SOC sends a stop command (QUIT CMD).

[0191] In the eleventh step, if CS is not pulled high in the second step and UWB does not receive the notification of entering the data transmission state in the second step for a period exceeding the preset period, if the duration of UWB's response in the third step exceeds the preset period (for example, 1s in the figure), if the duration of UWB's response ACK in the seventh step exceeds the preset period, if the duration of UWB's response to the stop response (QUIT RSP) in the eighth step exceeds the preset period, if the duration of UWB's response to the stop notification (QUIT NTF) in the eighth step exceeds the preset period, and if the ninth step exceeds the preset number of times, UWB will be hardware reset and the SPI chip select pin will be pulled high.

[0192] Step 12: If the BIN file version in the first step is lower than the current UWB software version, pull the SPI chip select pin high.

[0193] In the above embodiment, during the UWB upgrade process, upon confirming that the UWB has entered upgrade mode and is receiving data normally, the data packets in the upgrade file are distributed in batches, reducing communication overhead and balancing transmission efficiency and reliability. Furthermore, the UWB is forcibly reset and enters a specific mode before the upgrade to avoid state conflicts. Compared to traditional solutions that often rely on single-packet confirmation or full-data transmission, this embodiment optimizes the stability of large-scale firmware transmission.

[0194] In addition, the SOC inside the device acts as a secondary agent to coordinate the upgrade of itself and UWB.

[0195] In some embodiments, a program erase and write interlock mechanism is provided. Figure 12 When the target device for upgrading the upgrade file is an adapter, the upgrade process based on the upgrade file includes:

[0196] S1210 , running the upgrade program based on the upgrade file. Every time a flag is reached, if the current running order of the upgrade program is the running order represented by the flag, the flag reached is set to be valid.

[0197] The flag is pre-set in the upgrade program to indicate the running order of the upgrade program.

[0198] When performing OTA, multiple flag sequences with running order are added to the OTA application process. Every time the program runs to a flag, the corresponding flag is set to valid.

[0199] S1220: Before executing the upgrade program erase / write operation, if any flag bit is not set to be valid, the upgrade program erase / write operation is not executed.

[0200] Before performing a program erase / write operation, all flag bits are checked for validity. Only when all flag bits are set to valid is the upgrade program erase / write operation allowed. If any flag bit is not set to valid, for example, set to invalid, the upgrade program erase / write operation is not performed.

[0201] In the above embodiment, an anti-abnormal erase and write mechanism is added. The upgrade program is only allowed to be erased and written when all flags in the upgrade program are set to valid. This can prevent abnormal erase and write operations of program data caused by abnormal program jumps. In addition, multiple security conditions must be met simultaneously (each flag bit is set to valid) before the program erase and write operation is allowed. Compared with the traditional solution of single-condition judgment, this embodiment can better improve the security of device upgrades.

[0202] In some embodiments, the processor includes a boot loader area (Bootloader area), an application area, and a data area (user data area). A program area hard lock mechanism is set. When the program is running normally, the boot loader area and the application area are hardware locked using register configuration to ensure that the running code is not abnormally changed. When performing a program erase and write operation, the program area register is unlocked, and then the validity of the upgrade program is determined. Hardware-level locking can avoid erroneous operations caused by program runaway. Compared with traditional solutions that rely more on software locks, this embodiment can significantly improve security.

[0203] In some embodiments, a dual backup mechanism for configuration data is provided, whereby configuration data in the data area is backed up in the application area. Backup is performed based on the configuration data in the data area, and the default configuration is stored in the application area. The process of upgrading the target product based on the upgrade file also includes:

[0204] Step 1: When the boot loader area starts running, the flag bit of the configuration data in the data area is checked.

[0205] If the flag is normal, the program will jump to the normal position and start running according to the configuration information.

[0206] Step 2: If the flag is invalid, run the upgrade program based on the configuration data in the application area.

[0207] If the flag is invalid (i.e., abnormal), the program reads the default configuration stored in the application area and jumps to the default location to start running.

[0208] Step 3: When the upgrade program based on the configuration data of the application area runs normally, the configuration data of the data area is updated according to the configuration data of the application area.

[0209] That is, the abnormal configuration data in the data area is updated with reference to the configuration data in the application area.

[0210] In the above embodiment, the configuration data in the data zone is backed up in the application zone. If a flag in the data zone configuration data is invalid, the upgrade program is run based on the configuration data in the application zone. This allows the program to be restored to a usable state without manual intervention, and the default configuration supports downgrade compatibility. Compared to traditional backup schemes that often rely on a single copy or periodic backup mechanisms, this embodiment achieves redundancy through dual zones to improve program reliability.

[0211] In some embodiments, an application zone recovery mechanism is provided. The device upgrade method further includes:

[0212] Step 1: When the boot loader area jumps to the application area, the flag bit of the application area is checked. If the flag bit is invalid, a higher version of the program is downloaded to the application area.

[0213] The bootloader stores the default program version information. When the bootloader jumps to the application area, the flag in the application area is checked. If the flag in the application area is normal, the program jumps to the application area and runs normally. If the flag in the application area is abnormal, the program returns the default program version information to the host. The host then determines the version based on the default program version information and downloads the higher version program to the application area. The host can also be a display device.

[0214] The above embodiment determines whether the program in the application area can run normally by judging whether the flag bit in the application area is normal. If it cannot run normally, the higher version program is downloaded to the application area to ensure that the program in the application area can run reliably.

[0215] In some embodiments, it is assumed that there are two upgrade files. Figure 13The interaction timing diagram between the display device, adapter and remote control is shown.

[0216] In the first step, the display device recognizes the upgrade file and extracts the upgrade priority according to the file name of the upgrade file.

[0217] In the second step, the display device determines the sending order of the multiple upgrade files according to the upgrade priorities of the multiple upgrade files.

[0218] In the third step, the display device sends the first upgrade file to the adapter.

[0219] In the fourth step, the adapter determines that the target product indicated by the upgrade file is not its own product, and sends the first upgrade file to the remote controller.

[0220] In the fifth step, the remote controller determines that the target product indicated by the first upgrade file is the remote controller itself, and upgrades the target product based on the first upgrade file.

[0221] Step 6: The remote controller replies to the adapter with the upgrade result of the target product.

[0222] In the seventh step, the adapter responds to the display device with the upgrade result of the target product.

[0223] In step 8, when the display device determines that the upgrade result is successful, it continues to send the second upgrade file.

[0224] In step 9, when the adapter determines that the target product indicated by the upgrade file is its own product, the adapter upgrades the target product based on the upgrade file.

[0225] In step 10, the adapter responds to the display device with the upgrade result of the target product.

[0226] Figure 14 This is a schematic diagram of the structure of a device upgrade device 10 provided in this application, which is applied to a display device. Figure 14 As shown, the device 10 includes a processing module 11 and a communication module 12 .

[0227] The processing module 11 is used to determine the sending order of the upgrade files according to the upgrade priority of the upgrade files when an upgrade file is identified. The sending order is used to represent the dependency relationship between software change points corresponding to different upgrade files.

[0228] The communication module 12 is configured to send the first upgrade file to the adapter by using the earlier upgrade file as the first upgrade file and the later upgrade file as the second upgrade file for at least partially adjacent upgrade files in the sending sequence.

[0229] The communication module 12 is further configured to send a second upgrade file to the adapter when it is determined that the upgrade result corresponding to the first upgrade file is successful, wherein the upgrade file is used to upgrade the adapter or the remote control corresponding to the adapter.

[0230] In some embodiments, the communication module 12 is also used to determine the target device for upgrading the upgrade file; if the target device meets the upgrade conditions, the upgrade file is sent to the adapter; the upgrade conditions include: the system image file is normal, the power is greater than the preset power, the storage status is normal, the operating status is normal, or at least one of the connection status with the display device is normal.

[0231] The device upgrade apparatus provided in the embodiment of the present application can execute the device upgrade method applied to the display device in the above method embodiment, and its implementation principle and technical effect are similar, which will not be described in detail here. Figure 14 The division of the modules shown is only a schematic illustration, and this application does not limit the division of the modules and the naming of the modules.

[0232] Figure 15 This is a schematic diagram of the structure of a device upgrade device 20 provided in this application, which is applied to an adapter. Figure 15 As shown, the device 20 includes a communication module 21 and a processing module 22 .

[0233] The communication module 21 is used to receive a first upgrade file sent by a display device; wherein, the upgrade file is sent according to the sending order determined by the display device based on the upgrade priority of the upgrade file; the sending order is used to characterize the dependency relationship between the corresponding software change points of different upgrade files.

[0234] The communication module 21 is further configured to, after determining that the upgrade corresponding to the first upgrade file is completed, send an instruction indicating that the upgrade of the first upgrade file is successful to the display device;

[0235] The communication module 21 is further configured to receive a second upgrade file sent by the display device, wherein the second upgrade file is sent by the display device when the display device determines that the upgrade result corresponding to the first upgrade file is successful; and among at least partially adjacent two upgrade files in the sending order, the earlier upgrade file of the two adjacent upgrade files is the first upgrade file, and the later upgrade file is the second upgrade file.

[0236] In some embodiments, the communication module 21 is used to upgrade according to the first upgrade file when the target product indicated by the first upgrade file is the product in the adapter, and send an instruction indicating that the upgrade of the first upgrade file is successful to the display device after the upgrade is completed; when the target product indicated by the first upgrade file is the product in the remote control, send the first upgrade file to the remote control, and send an instruction indicating that the upgrade of the first upgrade file is successful to the display device after receiving the upgrade success result feedback from the remote control.

[0237] In some embodiments, the processing module 22 is used to parse and obtain the product unique code and product model of the target product indicated by the first upgrade file; if the product unique code is the same as the locally stored product unique code, it is determined that the target product indicated by the upgrade file is the product in the adapter; if the product unique code is different from the locally stored product unique code, it is determined that the target product indicated by the upgrade file is the product in the remote control.

[0238] In some embodiments, the processor includes a system-on-chip (SOC). The first upgrade file is used to upgrade the SOC. The communication module 21 is configured to, after moving the data in the first upgrade file to the SOC program backup area, verify the integrity of the first upgrade file; if the integrity is verified, switch the SOC program execution address to the SOC program backup area and restart the SOC to upgrade the SOC according to the first upgrade file; if the update is successful after the SOC restarts, the upgrade is determined to be complete, and a command indicating that the first upgrade file has been successfully upgraded is sent to the display device.

[0239] In some embodiments, the processor further includes an ultra-wideband (UWB) module, and the first upgrade file is used to upgrade the UWB. The communication module 21 is configured to transfer data in the first upgrade file to the UWB based on the SOC, thereby upgrading the UWB according to the first upgrade file; and if the UWB upgrade is complete, transmit a command to the display device indicating that the first upgrade file has been successfully upgraded.

[0240] In some embodiments, the communication module 21 is used to: read the UWB version information based on the SOC, and when the BIN file version in the upgrade file is higher than the current UWB software version, reset the UWB and output the control timing to control the UWB to enter the upgrade mode; for at least part of the data packets in the first upgrade file, when the UWB returns to normal, move the data packets to the UWB based on the SOC.

[0241] In some embodiments, when the target device for upgrading the upgrade file is an adapter, the processing module 22 is further used to: run the upgrade program based on the upgrade file, and each time a flag is reached, if the current running order of the upgrade program is the running order represented by the flag, the flag is set to be valid; wherein the flag is pre-set in the upgrade program to represent the running order of the upgrade program; before executing the upgrade program erase operation, if any flag is not set to be valid, the upgrade program erase operation is not executed.

[0242] In some embodiments, the processor includes a boot loader area, an application area, and a data area; the configuration data of the data area is backed up in the application area; the processing module 22 is also used, during the process of upgrading the target product based on the upgrade file, to: check the flag bit of the configuration data in the data area when the boot loader area starts running, and if the flag bit is invalid, run the upgrade program based on the configuration data in the application area; and update the configuration data in the data area according to the configuration data in the application area when the upgrade program runs normally based on the configuration data in the application area.

[0243] In some embodiments, hardware locking is performed between the boot loader area and the application area using register configuration.

[0244] In some embodiments, the processing module 22 is further configured to: when the boot loader area jumps to the application area, check the flag bit of the application area; if the flag bit is invalid, download a higher version of the program to the application area.

[0245] The present application also provides a computer-readable storage medium, which may include: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, and other media that can store program codes. Specifically, the computer-readable storage medium stores program instructions, and the program instructions are used for the methods in the above embodiments.

[0246] The present application also provides a program product, which includes execution instructions stored in a readable storage medium. At least one control module of a display device can read the execution instructions from the readable storage medium, and at least one control module executes the execution instructions to cause the display device to implement the methods provided in the various embodiments described above.

[0247] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some or all of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

[0248] For ease of explanation, the above description has been made with reference to specific embodiments. However, the above exemplary discussion is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Based on the above teachings, various modifications and variations can be obtained. The above embodiments are selected and described to better explain the principles and practical applications, so that those skilled in the art can better utilize the embodiments and various different variations of the embodiments suitable for specific use considerations.

Claims

1. A display device, characterized in that: include: At least one processor, the processor being configured to: When an upgrade file is identified, determining a sending order for the upgrade file based on its upgrade priority, wherein the sending order is used to characterize the dependency relationship between software change points corresponding to different upgrade files; For the two upgrade files that are at least partially adjacent in the sending sequence, the earlier upgrade file in the two adjacent upgrade files is used as the first upgrade file, and the later upgrade file is used as the second upgrade file, and the first upgrade file is sent to the adapter; When it is determined that the upgrade result corresponding to the first upgrade file is successful, a second upgrade file is sent to the adapter, wherein the upgrade file is used to upgrade the adapter or the remote controller corresponding to the adapter.

2. The display device according to claim 1, wherein The processor executes a process of sending the upgrade file to the adapter and is configured to: Determine the target device for upgrading the upgrade file; If the target device meets the upgrade conditions, the upgrade file is sent to the adapter; The upgrade condition includes at least one of: a normal system image file, a power level greater than a preset power level, a normal storage status, a normal operating status, or a normal connection status with a display device.

3. An adapter, characterized in that: include: At least one processor, the processor being configured to: Receiving a first upgrade file sent by a display device; wherein the upgrade file is sent according to a sending order determined by the display device based on an upgrade priority of the upgrade file; the sending order is used to represent a dependency relationship between software change points corresponding to different upgrade files; After determining that the upgrade corresponding to the first upgrade file is completed, sending an instruction indicating that the upgrade of the first upgrade file is successful to the display device; A second upgrade file is received from the display device, wherein the second upgrade file is sent by the display device when it is determined that the upgrade result corresponding to the first upgrade file is successful; among the at least partially adjacent two upgrade files in the sending order, the earlier upgrade file of the two adjacent upgrade files is the first upgrade file, and the later upgrade file is the second upgrade file.

4. The adapter according to claim 3, wherein: The processor is configured to, after determining that the upgrade corresponding to the first upgrade file is completed, send an instruction to the display device indicating that the upgrade of the first upgrade file is successful: In a case where the target product indicated by the first upgrade file is the product in the adapter, upgrading according to the first upgrade file, and after the upgrade is completed, sending an instruction indicating that the upgrade of the first upgrade file is successful to the display device; When the target product indicated by the first upgrade file is the product in the remote control, the first upgrade file is sent to the remote control, and after receiving a result of successful upgrade feedback from the remote control, an instruction indicating that the first upgrade file has been successfully upgraded is sent to the display device.

5. The adapter according to claim 4, wherein: After receiving the first upgrade file sent by the display device, the processor is further configured to: Parsing and obtaining a unique product code and product model of the target product indicated by the first upgrade file; If the product unique code is the same as the locally stored product unique code, the target product indicated by the upgrade file is determined to be the product in the adapter; if the product unique code is different from the locally stored product unique code, the target product indicated by the upgrade file is determined to be the product in the remote control.

6. The adapter according to claim 5, wherein: The processor includes a system-on-chip (SOC); the first upgrade file is used to upgrade the SOC; the processor executes the upgrade according to the first upgrade file and sends an instruction indicating that the upgrade of the first upgrade file is successful to the display device after the upgrade is completed, and is configured to: After moving the data in the first upgrade file to the SOC program backup area, verifying the integrity of the first upgrade file; After the verification is passed, the SOC program running address is switched to the SOC program backup area, and the SOC is restarted to upgrade the SOC according to the first upgrade file; If the update is successful after the SOC is restarted, it is determined that the upgrade is complete, and an instruction indicating that the first upgrade file is successfully upgraded is sent to the display device.

7. The adapter according to claim 6, wherein: The processor further includes an ultra-wideband module UWB, and the first upgrade file is used for upgrading the UWB; the processor executes the upgrade according to the first upgrade file, and after the upgrade is completed, sends an instruction to the display device indicating that the upgrade of the first upgrade file is successful, and is configured to: Moving data in the first upgrade file to the UWB based on the SOC, so as to upgrade the UWB according to the first upgrade file; If the UWB upgrade is completed, an instruction indicating that the first upgrade file has been successfully upgraded is sent to the display device.

8. The adapter according to claim 7, wherein: The processor executes the migration of data in the first upgrade file to the UWB based on the SOC, and is configured to: Based on the SOC reading of UWB version information, if the BIN file version in the upgrade file is higher than the current UWB software version, the UWB is reset and the control timing is output to control the UWB to enter the upgrade mode; For at least part of the data packets in the first upgrade file, when the UWB returns to normal, the data packets are moved to the UWB based on the SOC.

9. The adapter according to any one of claims 3 to 8, characterized in that: In a case where the target device for upgrading the upgrade file is an adapter, the processor is further configured to: Running the upgrade program based on the upgrade file, each time a flag is reached, if the current running order of the upgrade program is the running order represented by the flag, setting the flag reached to be valid; wherein the flag is pre-set in the upgrade program to represent the running order of the upgrade program; Before executing the upgrade program erase / write operation, if any flag bit is not set to be valid, the upgrade program erase / write operation will not be executed.

10. A device upgrade method, characterized in that: Applicable to adapters, including: Receiving a first upgrade file sent by a display device; wherein the upgrade file is sent according to a sending order determined by the display device based on an upgrade priority of the upgrade file; the sending order is used to represent a dependency relationship between software change points corresponding to different upgrade files; After determining that the upgrade corresponding to the first upgrade file is completed, sending an instruction indicating that the upgrade of the first upgrade file is successful to the display device; A second upgrade file is received from the display device, wherein the second upgrade file is sent by the display device when it is determined that the upgrade result corresponding to the first upgrade file is successful; among the at least partially adjacent two upgrade files in the sending order, the earlier upgrade file of the two adjacent upgrade files is the first upgrade file, and the later upgrade file is the second upgrade file.

Images