Mesh network, and data processing method and device for mesh network

Abstract

The present disclosure provides a Mesh network, and a data processing method and device for a Mesh network. The Mesh network comprises a plurality of devices interconnected by means of a Mesh bus; a single line in the mesh bus is configured for device ID generation; each device contends for the single line when powered on; a master device that has successfully contended for the signal line determines, on the basis of a locked ID, a new ID as an ID to be locked, and sends to other slave devices by means of the signal line ID data of the ID to be locked; the salve devices receive the ID data, return confirmation information, verify the ID data and return verification failure information to the master device when the verification fails; when the master device receives the confirmation information but does not receive the verification failure information, the master device locks the ID to be locked as a master device ID, and releases the single line; devices of which IDs have not been locked continue to contend for the single line to become the master device, and so on until all the device IDs are locked, without adding an additional management device, thereby reducing the hardware cost and complexity of mesh network device ID generation.

Description

[0001] The present disclosure claims priority to Chinese Patent Application No. 202410710937.1, filed on June 3, 2024 with the Chinese Patent Office, entitled “Mesh Network, Data Processing Method and Device of Mesh Network”, the entire contents of which are incorporated herein by reference. TECHNICAL FIELD

[0002] Mesh (grid) network refers to a server cluster based on a Mesh architecture, for example, a heterogeneous server based on a Mesh architecture. In the hardware devices of large models and cloud computing, heterogeneous servers often use Mesh architecture, and Mesh architecture is also widely used in multi-head and multi-tail shared computing, storage and memory architecture. In actual application, in order to distinguish different devices in the Mesh network, it is necessary to configure an identity code (Identity Document, referred to as ID) for the devices in the Mesh network. Each device in the Mesh network is interconnected through a Mesh bus, and the topological connection relationship between devices is a peer-to-peer relationship, so the Mesh network itself has many connection lines and high management complexity. At present, an additional management device is usually used to assign IDs for different devices in the Mesh network, and the increase of the management device will significantly increase the complexity of the topological relationship and the number of connection lines of the Mesh network, and increase the hardware cost of generating the ID of the Mesh network device and the complexity of the connection line between devices. The present disclosure provides a Mesh network, a data processing method and device of the Mesh network, to solve the problem that increasing the management device for assigning the ID of the device will significantly increase the complexity of the topological relationship and the number of connection lines of the Mesh network, and increase the hardware cost of generating the ID of the Mesh network device and the complexity of the connection line between devices. In a first aspect, the present disclosure provides a Mesh network, comprising: a plurality of devices, the plurality of devices being interconnected through a Mesh bus, a single line in the Mesh bus being configured for generating a device ID; each of the devices occupies the single line after being powered on, a device successfully occupying the single line serving as a master device, and a device failing to occupy the single line serving as a slave device; the master device determines a new ID as a to-be-locked ID based on a locked ID, and sends ID data of the to-be-locked ID to the slave device through the single line; the slave device receives the ID data through the single line, returns confirmation information of the ID data to the master device, verifies the ID data, and returns verification failure information of the ID data to the master device when the verification fails; and the master device locks the to-be-locked ID as the ID of the master device and releases the single line when receiving the confirmation information and not receiving the verification failure information.In an optional embodiment, the slave device verifies the ID data, and returns verification failure information of the ID data to the master device through the single line when verification fails, including: the slave device verifies the check information in the received ID data, and returns first verification failure information indicating that the ID data is verified incorrectly to the master device through the single line when the verification is incorrect; and / or the slave device verifies whether there is an ID conflict between the to-be-locked ID in the received ID data and the stored locked ID, and returns second verification failure information indicating that there is an ID conflict to the master device through the single line when there is an ID conflict. sending ID data of the to-be-locked ID to a second device through a single line, the second device being a device other than the first device in the Mesh network; locking the to-be-locked ID as the ID of the first device if receiving confirmation information of the ID data from the second device and not receiving verification failure information of the ID data; in an optional embodiment, the method further comprises: if receiving second verification failure information indicating that there is an ID conflict, increasing the to-be-locked ID by a preset increment as a new to-be-locked ID, and sending ID data of the new to-be-locked ID to the second device through the single line; in an optional embodiment, the method further comprises: if receiving first verification failure information indicating that the ID data is verified to be incorrect, entering a request state and reoccupying the single line; in an optional embodiment, the method further comprises: entering a request state after power-on and monitoring whether the single line meets an idle condition; when monitoring that the single line meets the idle condition, sending a clock synchronization command through the single line, the clock synchronization command being used to occupy the single line and perform clock synchronization; and entering a sending state after successfully occupying the single line; in an optional embodiment, the method further comprises: when receiving a single line release command, if the ID of the first device has not been locked, entering a request state and occupying the single line; in an optional embodiment, after locking the to-be-locked ID as the ID of the first device, the method further comprises: sending a single line release command through the single line to release the single line, entering a receiving state, and not occupying the single line any more; in an optional embodiment, the method further comprises: when monitoring that the single line does not meet the idle condition, entering a receiving state; receiving ID data sent by a second device through the single line, and sending confirmation information to the second device through the single line; verifying the received ID data, if the verification of the received ID data fails, sending verification failure information to the second device through the single line; and if the verification of the received ID data succeeds, storing the received ID data as a locked ID; in an optional embodiment, the verifying of the received ID data, if the verification of the received ID data fails, sending verification failure information to the second device through the single line, comprises: verifying check information in the received ID data, and if the verification is incorrect, sending first verification failure information indicating that the ID data is verified to be incorrect to the second device through the single line; The Mesh network, the data processing method and the device of the Mesh network provided by the present disclosure, the Mesh network comprises a plurality of devices, the plurality of devices are interconnected through a Mesh bus, a single line in the Mesh bus is configured to generate a device ID, each device occupies the single line after being powered on, the device successfully occupying the single line is a master device, and the device failing to occupy the single line is a slave device. The master device determines a new ID as a to-be-locked ID based on the locked ID, and sends ID data of the to-be-locked ID to the slave device through the single line. The slave device receives the ID data through the single line, returns confirmation information of the ID data to the master device, verifies the ID data, and returns verification failure information of the ID data to the master device through the single line when the verification fails. The master device locks the to-be-locked ID as the ID of the master device and releases the single line when the confirmation information of the slave device is received and no verification failure information is received. After the single line is released, other devices that have not locked the ID continue to occupy the single line, the device successfully occupying the single line is a new master device, generates and locks the device ID, and the ID generation of all devices in the Mesh network is completed until all devices successfully lock the device ID. The present disclosure reserves a single line in the Mesh bus of the Mesh network for generating the device ID, and provides a single-line communication scheme, the devices in the Mesh network automatically generate the device ID through single-line communication, realize the automatic generation of the device ID in the Mesh network, decouple the original complex topology connection relationship of the Mesh network, do not need to increase additional management devices, and reduce the hardware cost of the device ID generation of the Mesh network and the complexity of the Mesh network topology compared with the Mesh network increasing the management devices for generating the device ID. BRIEF DESCRIPTION OF DRAWINGS The drawings incorporated herein and forming a part of the specification, show embodiments consistent with the present disclosure, and together with the specification, serve to explain the principles of the present disclosure.Figure 1 is an example diagram of a Mesh network provided by an embodiment of the present disclosure; Figure 2 is an architecture diagram of a Mesh network that automatically generates a device ID provided by an example embodiment of the present disclosure; Figure 3 is a framework diagram of device ID automatic generation in a Mesh network provided by an example embodiment of the present disclosure; Figure 4 is a state transition diagram of state attributes of ID information provided by an example embodiment of the present disclosure; Figure 5 is a format diagram of a clock synchronization command provided by an example embodiment of the present disclosure; Figure 6 is a diagram of a data format provided by an example embodiment of the present disclosure; Figure 7 is a flowchart of verifying ID data by a slave device provided by an example embodiment of the present disclosure; Figure 8 is a format diagram of a single-wire release command provided by an example embodiment of the present disclosure; Figure 9 is a diagram of a device state machine provided by an example embodiment of the present disclosure; Figure 10 is a flowchart of a device ID generation method of a Mesh network provided by an example embodiment of the present disclosure; Figure 11 is a flowchart of a data processing method of a Mesh network provided by an example embodiment of the present disclosure; Figure 12 is a flowchart of a method executed by any device in a Mesh network provided by an example embodiment of the present disclosure; Figure 13 is an architecture diagram of a heterogeneous server provided by an example embodiment of the present disclosure; Figure 14 is a structure diagram of a device of a Mesh network provided by an embodiment of the present disclosure. The above-described figures show specific embodiments of the present disclosure, which will be described in more detail below. These figures and written description are not intended to limit the scope of the present disclosure concept in any way, but rather to illustrate the present disclosure concept to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0003] Mesh Network: Also known as a mesh network, it refers to a server cluster based on a mesh architecture, such as heterogeneous servers based on a mesh architecture. Heterogeneous Servers: Refers to servers in a server cluster that use different hardware or software architectures. Common heterogeneous servers include servers using different operating systems or different processor architectures. This design allows for the selection of the most suitable hardware and software based on the needs of different applications, thereby improving the overall system performance and efficiency. Single-Wire Communication Protocol: Also known as a physical single-wire protocol, single-wire protocol, or single-wire transmission protocol, it typically refers to a communication protocol that transmits data through a single communication line (i.e., a single wire). It is a half-duplex communication method, where the single wire simultaneously acts as a clock line, data line, and control line. Ideally, the number of slave devices on a single bus is virtually unlimited, providing great scalability.

[0004] Idle: Idle state, indicating the idle state of the bus. Large model refers to a deep learning model with a large number of model parameters, usually containing hundreds of millions, hundreds of millions, or even tens of billions of model parameters. Large model can also be called Foundation Model (FM). Through large-scale unlabeled corpus pre-training, a pre-trained model with hundreds of millions of parameters is produced. This model can adapt to a wide range of downstream tasks, and the model has good generalization ability. For example, large-scale language model (LLM), multi-modal pre-training model, etc. In practical application, only a small amount of sample is needed to fine-tune the pre-trained model to apply it to different tasks. Large model can be widely used in natural language processing (NLP), computer vision and other fields. Specifically, it can be applied to computer vision tasks such as visual question answering (VQA), image caption (IC), image generation, and natural language processing tasks such as text-based sentiment classification, text summary generation, and machine translation. The main application scenarios of large model include digital assistants, intelligent robots, search, online education, office software, e-commerce, intelligent design, etc. With the rapid development of large models and cloud computing technologies, heterogeneous servers are often used in Mesh architecture in large model and cloud computing hardware devices. Mesh architecture is also widely used in multi-head and multi-tail shared computing, storage and memory architecture.

[0005] A Mesh network refers to a server cluster based on a Mesh architecture, for example, a heterogeneous server based on a Mesh architecture. Devices in the Mesh network are interconnected through a Mesh bus, and the topological connection relationship between devices is a peer-to-peer relationship. For example, FIG. 1 is an example diagram of a Mesh network provided by an embodiment of the present disclosure. As shown in FIG. 1, three examples of Mesh networks are provided. Among them, the leftmost Mesh network includes three devices (also referred to as nodes), device 1, device 2, and device 3. The middle Mesh network includes four devices: device 1, device 2, device 3, and device 4. The rightmost Mesh network includes five devices: device 1, device 2, device 3, device 4, and device 5. The topological connection relationship between multiple devices in the Mesh network is full peer-to-peer, all devices are connected to each other, and each device has multiple connection channels. This network structure allows direct communication between devices without the need for a central node or router. In actual applications, a Mesh network usually includes a large number of devices (nodes), and the full peer-to-peer relationship of devices in the Mesh network determines that the Mesh network itself has a large number of connection lines and high management complexity. If an additional management device for assigning device IDs is added to the Mesh network, the complexity of the topological relationship and the number of connection lines of the Mesh network will significantly increase, increasing the hardware cost of generating device IDs in the Mesh network and the complexity of the Mesh network topology. The present disclosure provides a Mesh network including a plurality of devices, the plurality of devices being interconnected through a Mesh bus, and a single line in the Mesh bus being configured to generate device IDs. The IDs of the devices in the Mesh network are determined in the following manner: each device occupies the single line after being powered on, the device that successfully occupies the single line is the master device, and the device that fails to occupy the single line is the slave device. The master device determines a new ID as a to-be-locked ID based on the locked ID, and sends ID data of the to-be-locked ID to the slave device through the single line. The master device monitors information returned by the slave device on the single line. The slave device receives the ID data through the single line, returns confirmation information to the master device, verifies the ID data, and returns verification failure information to the master device through the single line when the verification fails. The master device locks the to-be-locked ID as the ID of the master device and releases the single line when receiving the confirmation information from the slave device and not receiving the verification failure information.After the single line is released, other devices that have not locked the ID continue to seize the single line (seize the right to use the single line to send ID data), and the device that successfully seizes the single line serves as a new master device to perform the processing of the master device to lock the device IDo until all devices successfully lock the device ID, and the ID generation of all devices in the Mesh network is completed. The method of the present disclosure reserves a single line in the Mesh bus of the Mesh network for generating the device ID, and provides a single line communication scheme, and the devices in the Mesh network automatically generate the device ID through single line communication, realize the automatic generation of the device ID in the Mesh network, decouple the original complex topology connection relationship of the Mesh network, do not need to increase additional management devices, and compared with the Mesh network that increases the management devices for generating the device ID, the hardware cost of the Mesh network device ID generation and the complexity of the Mesh network topology are reduced. The technical solutions of the present disclosure and how the technical solutions of the present disclosure solve the above technical problems will be described in detail in the specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes can not be described again in some embodiments. The embodiments of the present disclosure will be described below with reference to the drawings. The present embodiment provides a Mesh network, comprising: a plurality of devices, the plurality of devices are interconnected through a Mesh bus, and a single line in the Mesh bus is configured to generate a device ID. In the present embodiment, a physical single line in the Mesh bus that realizes the interconnection of devices in the Mesh network is reserved for generating the device ID. Through the single line, the automatic generation of the device ID in the Mesh network is realized based on a single line communication protocol. FIG. 2 is an architecture diagram of a Mesh network for automatically generating a device ID according to the present embodiment, as shown in FIG. 2, taking a Mesh network including three devices (device 1, device 2 and device 3 shown in FIG. 2) as an example, the devices in the Mesh network are interconnected through the reserved single line, and the single line is used for generating the device ID. Specifically, each device in the Mesh network includes a complex programming logic device (CPLD), the reserved single line is connected to the input / output (in / out) pin of the CPLD, and the pin can be configured as an output mode, for example, can be configured as an open drain (OD) mode. The devices in the Mesh network are interconnected through the reserved single line, and through the single line, the automatic generation of the device ID in the Mesh network is realized based on a single line communication protocol.It should be noted that, in order to highlight the reserved single line, the connection of the single line is separately drawn in Figure 2, although it is not drawn in the middle of the main line, but the single line is one of the physical single lines of the Mesh bus of the Mesh network. Figure 3 is a framework diagram of automatic generation of device ID in the Mesh network provided by an exemplary embodiment of the present disclosure. As shown in Figure 3, the process of automatic generation of device ID in the Mesh network is as follows: specifically, after each device in the Mesh network is powered on (started), the single line is preempted, and the right to use the single line to send ID data is obtained through preemption of the single line. The device that successfully preempts the single line is the current master device, and the device that fails to preoccupy the single line is the current slave device. The master device determines a new ID as a to-be-locked ID based on the locked ID, and sends ID data of the to-be-locked ID to the slave device through the single line. Then the master device monitors the return information of the slave device on the single line. After the slave device receives the ID data sent by the master device through the single line, the slave device returns the confirmation information of the ID data to the master device, verifies the ID data, and returns the verification failure information of the ID data to the master device through the single line when the verification fails. Wherein, each device can store the locked ID locally. In the case that the master device receives the confirmation information and does not receive the verification failure information, it is confirmed that the to-be-locked ID is available, and the to-be-locked ID is locked as the ID of the master device. Through the above process, the master device successfully locks the ID used by itself, and after locking the ID, the master device releases the single line and no longer preoccupies the single line. After the single line is released, other devices that have not locked the ID continue to preoccupy the single line, and the device that preoccupies the single line will become a new master device, and the master device performs the above process of locking its own ID. In this way, until all devices lock the ID, the automatic generation of the device ID in the Mesh network is completed. In Figure 3, it is exemplarily illustrated that the Mesh network includes M devices, M is an integer greater than 2, and the number of devices in the Mesh network is not specifically limited, which can be constructed according to the requirements of the actual application scene. This embodiment provides a single-line communication scheme without fixed master-slave devices, and the devices in the Mesh network compete to become master devices by preoccupying the single line. The master device that successfully preoccupies the single line generates and locks its own ID, and then releases the single line. After the single line is released, other devices can continue to preoccupy the single line to become master devices and generate and lock their own IDs.After all the devices lock the IDs, the automatic generation of the device IDs in the Mesh network is completed, and the original complex topology connection relationship of the Mesh network is decoupled, without the need to increase additional management devices. Compared with the Mesh network that increases management devices for generating device IDs, the hardware cost of generating device IDs in the Mesh network and the complexity of the Mesh network topology are reduced. In an optional embodiment, each device locally stores ID information and state attributes of the ID information. The locally stored ID information has three state attributes, namely, active, to-be-locked, and locked. The locked state indicates that the ID information has been bound as the device ID of the device itself, and other devices cannot bind the same ID. The active state indicates that the locally stored ID information has not been bound as the device ID of the device itself and can be updated at any time. The to-be-locked state is a state that may exist only for the ID information stored by the master device, indicating that the master device has sent ID data of the to-be-locked ID to the slave device, but has not yet locked the to-be-locked ID as the device ID of the device itself. The ID information stored by each device is initialized to the same preset value, and the state attribute of the ID information is configured as the active state. The preset value can be configured according to actual needs, for example, the preset value can be “0x0000” or other values, which are not limited here. In this embodiment, the ID information in the active state can also store the device ID locked the last time, that is, the newly generated locked ID. After the device successfully occupies the single line and becomes the master device, the locally stored ID information is read as the newly generated locked ID, and a new ID obtained by increasing a preset increment (such as 1, 2, etc.) to the locked ID is taken as the to-be-locked ID. The master device sends ID data of the to-be-locked ID to the slave device through the single line, updates the locally stored ID information to the to-be-locked ID, and sets the locally stored ID information to the to-be-locked state. When the master device receives the confirmation information from the slave device and does not receive the verification failure information sent by the slave device, it is confirmed that the to-be-locked ID is available, the locally stored ID information is set to the locked state, and the to-be-locked ID is locked as the ID of the master device. The locally stored ID information of the device is locked as the device ID of the device itself and is no longer updated.②, The master device confirms that the ID to be locked is available, and sets the locally stored ID information to a locked state. The ID information locally stored by the device is locked as the device ID of the device itself and is no longer updated. In the method of the embodiment, each device locally stores ID information and a state attribute of the ID information. The ID information is in a default active state, and the value is a preset value (such as 0x0000). The ID information in the active state can change as each device continuously locks the ID, and the ID that is locked last time is recorded. After the device successfully occupies the single line and becomes the master device, a new ID can be generated as the ID to be locked according to the locally stored ID information (the ID that is locked last time). The ID to be locked is updated to the locally stored ID information, and after the ID to be locked is successfully locked as the device ID, the state attribute of the locally stored ID information (the ID to be locked) is set to the locked state and is no longer updated, so that automatic generation of the device ID in the Mesh network can be implemented. In an optional embodiment, each device occupies the single line after being powered on, and the occupation of the single line can be implemented in the following manner: After each device is powered on, whether the single line meets an idle condition is monitored. When it is monitored that the single line meets the idle condition, a single line occupation command is sent through the single line. The single line occupation command is usually a low-level signal that lasts for a first time length. The first time length can be configured according to actual application requirements, for example, the first time length can be 5 milliseconds, 6 milliseconds, and the like, which is not limited here. After the single line is successfully occupied and the device becomes the master device, the master device sends a clock synchronization command to other slave devices through the single line, so as to implement clock synchronization between devices. The monitoring time length of whether the single line meets the idle condition is N X 10 ms (milliseconds), where N is a random number. If the single line is always in an idle state (that is, an Idle state) within N X 10 ms, the single line can be occupied. In an optional embodiment, a clock synchronization (Clock Sync) command is provided, and the clock synchronization command implements occupation of the single line and clock synchronization. FIG. 5 is a format schematic diagram of the clock synchronization command provided in the embodiment, as shown in FIG. 5, the clock synchronization command includes a low-level signal lasting for a first time length and a continuously flipping level signal. The low-level signal lasting for the first time length is used to occupy the single line, and the first time length can be configured according to actual application requirements. In FIG. 5, 5 ms is taken as an example to exemplarily illustrate the first time length, and the first time length is not limited here. The continuously flipping level signal indicates that the clock continuously flips and is used to synchronize the clock frequency. The length of the continuously flipping level signal can be configured according to actual application requirements. In FIG. 5, 32 bits of continuous flipping is taken as an example to exemplarily illustrate the length of the continuously flipping level signal, and in other embodiments, the length of the continuously flipping level signal can also be 64 bits, and the like. The length of the continuously flipping level signal is not limited here.In this embodiment, each device occupies the single line after power-on, which can be implemented in the following manner: after each device is powered on, whether the single line meets the idle condition is monitored, and when it is monitored that the single line meets the idle condition, a clock synchronization command is sent to the slave device through the single line, and the clock synchronization command is used to occupy the single line and perform clock synchronization. After the clock synchronization (Clock Sync) command is sent, the device can send ID data through the single line. Generally, after the clock synchronization (Clock Sync) command is sent, the device needs to send ID data within a short time (such as 5 ms) to avoid the single line entering the Idel state due to long-time non-use of the single line to send data, and other devices occupying the single line. In an optional embodiment, a format for sending data through the single line is provided. FIG. 6 is a schematic diagram of the data format provided in this embodiment, as shown in FIG. 6, the master device sends ID data through the single line, and the ID data includes a start flag (Start Code), main data (DATA), and check information (such as ECC). A second time length is reserved after the ID data is sent for state switching (SWITCH, denoted as SW), and the master device switches the input / output pin from the sending state to the receiving state. The next third time length is used to receive the confirmation information (ACK) of the slave device. The next fourth time length is used to receive the verification failure information (Err) of the slave device. Among them, the start flag (Start Code) is a fixed value, which is used as an identifier for starting to send ID data, followed by the main data (DATA) to be sent. The bit width and specific value of the start flag can be configured according to actual application requirements, which are not limited here. Exemplarily, the bit width of the start flag (Start Code) can be 6 bits, and the default value is 011010. The main data (DATA) refers to the ID to be locked and the necessary flag bit (i.e., the flag bit reserved for other applications) that needs to be expanded, and the bit width of the main data (DATA) can be configured according to actual application requirements, which is not limited here. Exemplarily, the bit width of the main data (DATA) can be 16 bits or 32 bits. The check information is used to check the correctness of the main data (DATA), so as to realize the correctness of the ID data sent by the master device checked by the slave device. In FIG. 6, the ECC check code generated by the ECC (Error Checking and Correction) check algorithm is exemplarily taken as an example for illustration, and the check information can also be a check code generated by other data check algorithms, which is not limited here.The bit width occupied by the check information can be configured according to actual application requirements, for example, the ECC check code can occupy 4 bits, and the state switching (SW) occupies a bit width of 2 bits. After the master device sends the ID data, the input and output pins are switched to a receiving state. The bit width (i.e., the second time length) occupied by the state switching (SW) can be configured according to actual application requirements, and is not specifically limited here. The confirmation information (ACK): a bit width of 3 bits, received by the master device, and 1-3 clocks pulled low by the slave device to indicate confirmation of the master device sending the ID data. In addition, the bit width (i.e., the third time length) occupied by the confirmation information (ACK) can be configured according to actual application requirements, and is not specifically limited here. The verification failure information (Err): a bit width of 3 bits, received by the master device, and 1-3 clocks pulled low by the slave device to return verification failure information to the master device. The single-bit low Err indicates that there is an ID conflict. The double-bit low Err indicates that the ID data check error, that is, the check error of the preceding check information. An example of a data format is shown in Table 1. As shown in Table 1, the start code Start Code in the ID data occupies a bit width of 6 bits, and the default value is 011010, followed by the main data DATA. The main data DATA occupies a bit width of 16 bits, including the ID to be locked and the reserved expandable flag bit. The check information is ECC, occupying a bit width of 4 bits. After the ID data is sent, the 2-bit SW is used to switch the pins of the master device to a receiving state, and the subsequent confirmation information ACK and verification failure information Err returned by the slave device oAfter the SW, the acknowledgement information ACK occupies a bit width of 3 bits, and then the verification failure information Err occupies a bit width of 3 bits. The Err pulled down by a single bit indicates that there is an ID conflict. The Err pulled down by two bits indicates that there is an ID data check error, that is, the check information check error. The "X" in Table 1 indicates a single bit value, which can be 0 or 1. FIG. 7 is a flowchart of verifying ID data by a slave device according to an example embodiment of the present disclosure. Based on any of the foregoing embodiments, in an optional embodiment, as shown in FIG. 7, the slave device verifies the ID data, verifies the ID data, and returns the verification failure information of the ID data to the master device through a single line when the verification fails, and is specifically implemented by the following steps: Step S700, the slave device receives the ID data sent by the master device through a single line. The device that fails to occupy the single line as a slave device enters a receiving state and receives the ID data sent by the master device through the single line. Step S701, the slave device returns the acknowledgement information to the master device through the single line. After receiving the ID data sent by the master device, the slave device returns the acknowledgement information to the master device. Step S702, the slave device verifies the received ID data. After receiving the ID data sent by the master device through the single line, the slave device verifies the received ID data, including: the slave device checks the check information in the received ID data, and / or the slave device verifies whether the to-be-locked ID in the received ID data and the stored locked ID have an ID conflict. In an optional implementation manner, the slave device can first check the check information in the received ID data. If the check information check error, the slave device returns the first verification failure information to the master device, and the first verification failure information indicates that the ID data check error. If the check information check is correct, the slave device verifies whether the to-be-locked ID in the ID data and the stored locked ID have an ID conflict. If there is an ID conflict, the slave device returns the second verification failure information to the master device, and the second verification failure information indicates that there is an ID conflict. In another optional implementation manner, the slave device can check the check information in the received ID data. If the check information check error, the slave device returns the verification failure information to the master device. In another optional implementation manner, the slave device verifies whether the to-be-locked ID in the ID data and the stored locked ID have an ID conflict. If there is an ID conflict, the slave device returns the verification failure information to the master device.In the embodiment, when verifying whether the to-be-locked ID in the ID data conflicts with the stored locked ID, the to-be-locked ID can be compared with the stored locked ID. If any of the following conditions occurs, it is determined that there is an ID conflict: the to-be-locked ID is identical to any locked ID; or, on the premise that the preset increment is positive, the to-be-locked ID is less than any locked ID; or, on the premise that the preset increment is negative, the to-be-locked ID is greater than any locked ID. In addition, the rule for verifying whether the to-be-locked ID in the ID data conflicts with the stored locked ID can be configured and adjusted according to the needs of device ID configuration in actual application, which is not specifically limited here. For example, when the state attribute of the locally stored ID information of the slave device is an active state, the locally stored ID information is the ID that is locked most recently. Assuming that the preset increment can be positive (for example, 1), when verifying whether the to-be-locked ID in the ID data conflicts with the stored locked ID, if the to-be-locked ID is less than or equal to the locally stored ID information, and the state attribute of the locally stored ID information is an active state, it is determined that the to-be-locked ID in the ID data conflicts with the stored locked ID. Step S703: If the received ID data is verified successfully, the slave device stores the to-be-locked ID in the received ID data as a locked ID. Based on the verification result of step S702, if the received ID data is verified successfully, the slave device stores the to-be-locked ID in the received ID data as a locked ID, so that the locked ID can be recorded locally. Subsequently, the slave device can verify other received ID data based on the locally stored locked ID. In addition, after the slave device successfully occupies the single wire to become the master device, a new ID can be generated based on the locally stored locked ID as a to-be-locked ID. Optionally, each device can store all locked IDs. Optionally, the slave device can locally store an ID information and a state attribute of the ID information. In the case where the state attribute of the locally stored ID information is an active state, the slave device updates the locally stored ID information to the to-be-locked ID in the received ID data, so that the locally stored ID information is the ID that is locked most recently. Step S704: If the received ID data is verified unsuccessfully, the slave device returns verification failure information to the master device through the single wire. Based on the verification result of step S702, if the slave device checks the information in the received ID data incorrectly, the slave device returns first verification failure information to the master device through the single wire. The first verification failure information indicates that the ID data checking is incorrect.Exemplarily, based on the data format in Table 1, the first verification failure information can be a double-bit pulled-down Err, indicating an ID data check error, that is, a check error of the preceding check information. Further, in a case where the master device receives the first verification failure information returned by the slave device, that is, receives the verification failure information of the slave device on the ID data and the verification failure information indicates an ID data check error, the master device confirms that the data is incorrect, and the master device needs to re-preempt the single line. Specifically, the master device monitors whether the single line satisfies an idle condition, and when it is monitored that the single line satisfies the idle condition, the master device re-preempts the single line and performs clock synchronization. For details, refer to the related content in the preceding embodiments, which will not be described here. Based on the verification result in step S702, if the slave device verifies that the to-be-locked ID in the received ID data conflicts with the stored locked ID, the slave device returns second verification failure information to the master device through the single line. The second verification failure information indicates that there is an ID conflict. Exemplarily, based on the data format in Table 1, the second verification failure information can be a single-bit pulled-down Err, indicating that there is an ID conflict. Further, in a case where the master device receives the second verification failure information returned by the slave device, that is, receives the verification failure information of the slave device and the verification failure information indicates that there is an ID conflict, the master device generates a new to-be-locked ID and sends ID data of the new to-be-locked ID to the slave device through the single line. Specifically, the master device can increase the to-be-locked ID by a preset increment as the new to-be-locked ID. The preset increment can be configured and adjusted according to actual application requirements, for example, the preset increment can be 1, 2, etc., which will not be specifically limited here. In an optional embodiment, after the master device generates the to-be-locked ID, the master device needs to update the locally stored ID information to the newly generated to-be-locked ID. The embodiment of the present disclosure also provides a single line release command (Stop Code), which indicates that the master device will release the single line and stop data sending after the single line release command is sent. Exemplarily, FIG. 8 is a format schematic diagram of the single line release command provided by the embodiment, as shown in FIG. 8, the single line release command Stop Code occupies a bit width of 6 bits, and the default value is 0x10010. In addition, the bit width and value of the single line release command can be configured according to actual application requirements, which will not be specifically limited here. In an optional embodiment, after the master device locks the to-be-locked ID as the ID of the master device, the master device sends the single line release command through the single line to release the single line. The device with the locked device ID will not preempt the single line in the future.When each device receives the single-line release command through the single line, if the ID of the device has not been locked, the device occupies the single line. After successfully occupying the single line, the device becomes the master device, generates and locks the ID of the device. For details, refer to the function of the master device in the foregoing embodiments, which will not be described here. In an optional embodiment, a state machine is used to represent the device state. FIG. 9 is a schematic diagram of a device state machine provided in this embodiment. As shown in FIG. 9, the device state includes three states: request, send, and receive. After each device is powered on, the device enters the request state. In the request state, the device monitors whether the single line meets the idle condition. The monitoring duration is NX 10 ms, where N is a random number. If the single line is always in the idle state within NX 10 ms, the device can occupy the single line. After successfully occupying the single line, the device enters the send state (corresponding to the state transition ① in FIG. 9). In the request state, the device detects a low level on the single line at any time (i.e., a command for occupying the single line sent by another device), and enters the receive state (corresponding to the state transition ⑤ in FIG. 9). In the send state, the master device sends a clock synchronization command through the single line, and other slave devices in the receive state adjust the clock to be aligned. Then the master device sends ID data in the data format, and receives the acknowledgement information (ACK) and the verification failure information (Err) returned by other slave devices. If the acknowledgement information (ACK) is received and no verification failure information (Err) is received, the master device enters the receive state (corresponding to the state transition ③ in FIG. 9). If the acknowledgement information (ACK) is received and the verification failure information (Err) is received, it is determined whether to enter the request state or remain in the send state according to the type of the verification failure information (Err). In the case of receiving the verification failure information (Err) indicating that there is an ID conflict, the master device remains in the send state (corresponding to the state transition ② in FIG. 9). In the case of receiving the verification failure information (Err) indicating that the ID data is incorrect, the master device enters the request state (corresponding to the state transition ⑥ in FIG. 9), and then the device needs to occupy the single line again. In the receive state, the slave device returns the acknowledgement information ACK to the master device, and verifies the received ID data. The slave device checks the check information in the ID data. If the check information is incorrect, the slave device returns the verification failure information (Err) indicating that the ID data is incorrect to the master device through the single line. The slave device verifies whether the ID to be locked in the received ID data conflicts with the locked ID stored by the slave device. If there is an ID conflict, the slave device returns the verification failure information (Err) indicating that there is an ID conflict to the master device through the single line.If the received ID data is verified, the locally stored ID information is updated as the to-be-locked ID in the received ID data. In the receiving state, if the state attribute of the locally stored ID information is the active state, the device enters the request state when receiving the single-line release command (corresponding to the state switching of ④ in FIG. 9). If the ID of the device is locked, the device remains in the receiving state. Based on the device state machine in the embodiment, each device enters the request state after being powered on, and monitors whether the single line satisfies the idle condition. When it is monitored that the single line satisfies the idle condition, a clock synchronization command is sent to the slave device through the single line, and the clock synchronization command is used to preempt the single line and perform clock synchronization. After successfully preoccupying the single line, the device becomes the master device and enters the sending state. In the embodiment, after the master device locks the to-be-locked ID as the ID of the master device, a single-line release command is sent through the single line to release the single line, and the device enters the receiving state and no longer preoccupies the single line. Further, when each device receives the single-line release command through the single line, if the ID of the device has not been locked, the device enters the request state and preoccupies the single line. FIG. 10 is a flowchart of a device ID generation method of a Mesh network provided by an example embodiment of the present disclosure. As shown in FIG. 10, the specific process of generating the device ID in the Mesh network based on the single-line communication protocol is as follows: in step S1000, each device monitors whether the single line satisfies the idle condition. In step S1001, it is detected that the single line satisfies the idle condition, the single line is preoccupied, the device that successfully preoccupies the single line is the master device and enters the sending state, and the device that fails to preoccupy the single line is the slave device and enters the receiving state. In step S1002, the master device determines a new ID as the to-be-locked ID based on the locked ID, and sends the ID data of the to-be-locked ID to the slave device through the single line. In step S1003, the master device monitors the return information of the slave device on the single line. In step S1004, the slave device receives the ID data, and returns the confirmation information to the master device through the single line. In step S1005, the slave device verifies the information in the received ID data. If the verification is incorrect, step S1006 is performed, and if the verification is correct, step S1007 is performed. In step S1006, if the verification is incorrect, the slave device returns the first verification failure information indicating that the ID data verification is incorrect to the master device through the single line. In step S1007, if the verification is correct, the slave device verifies whether there is an ID conflict. In this step, the slave device verifies whether the to-be-locked ID in the received ID data conflicts with the stored locked ID.S1008, if the ID conflict exists, the slave device returns second verification failure information indicating that the ID conflict exists to the master device through the single wire. S1009, if the ID conflict does not exist, the slave device stores the to-be-locked ID in the received ID data as a locked ID. S1010, the master device receives the confirmation information returned by the slave device and does not receive any verification failure information, and the master device locks the to-be-locked ID as the ID of the master device. S1011, the master device releases the single wire, enters a receiving state, and no longer preoccupies the single wire. S1012, the master device receives the second verification failure information indicating that the ID conflict exists returned by the slave device, increases the to-be-locked ID by a preset increment as a new to-be-locked ID, and sends ID data of the new to-be-locked ID to the slave device through the single wire. After this step, the step S1002 is executed. S1013, the master device receives the first verification failure information indicating that the ID data check error is returned by the slave device, and the master device enters a request state and reoccupies the single wire. After this step, the step S1000 is executed. S1014, when the slave device receives the single wire release command, if the ID of the device has not been locked, the slave device enters a request state and preoccupies the single wire. The implementation principle and technical effects of this embodiment are described above, and will not be described here. The scheme of this embodiment defines the state synchronous switching of the single wire state machine and the ID information attribute, and contains the ECC check and permission conflict resolution scheme of the ID data, which prompts the reliability of the device ID generation. FIG. 11 is a flowchart of a data processing method of a Mesh network provided by an example embodiment of the present disclosure. The present embodiment provides a data processing method of a Mesh network, and the execution subject is any device (referred to as a first device) in the Mesh network (other devices in the Mesh network are referred to as second devices). As shown in FIG. 11, the specific steps of the method are as follows: S1101, preoccupy the single wire after power-on. In this step, any device in the Mesh network preoccupies the single wire after power-on (start), and obtains the permission to send ID data through the preoccupied single wire. For any first device, the first device is the current master device after successfully preoccupying the single wire, and the first device is the current slave device after failing to preoccupy the single wire. In an optional embodiment, the first device preoccupies the single wire and performs clock synchronization based on the clock synchronization command shown in FIG. 5. Specifically, after power-on, the first device enters a request state and monitors whether the single wire meets the idle condition.When it is monitored that the single line meets the idle condition, a clock synchronization command is sent to the second device through the single line, and the clock synchronization command is used to preempt the single line and perform clock synchronization. The first device is called a master device after the single line is successfully preempted, and enters a sending state. In step S1102, after the single line is successfully preempted, a new ID is determined as a to-be-locked ID based on the locked ID, and ID data of the to-be-locked ID is sent to the second device through the single line. The second device is a device in the Mesh network except the first device, the first device is the master device, and the rest of the second devices are slave devices, and the processing procedure of the slave device is executed. In step S1103, if the confirmation information of the second device to the ID data is received, and the verification failure information of the ID data is not received, the to-be-locked ID is locked as the ID of the first device. In step S1104, a single line release command is sent through the single line to release the single line. In the embodiment, after the to-be-locked ID is locked as the ID of the first device, the first device releases the single line, enters a receiving state, and no longer preempts the single line. In step S1105, if the second verification failure information indicating that there is an ID conflict is received, the to-be-locked ID is increased by a preset increment as a new to-be-locked ID, and ID data of the new to-be-locked ID is sent to the second device through the single line. In step S1106, if the first verification failure information indicating that the ID data is checked to be wrong is received, a request state is entered, and the single line is preempted again. In the embodiment, after the single line is successfully preempted, the first device executes the processing logic of the master device, generates and locks the device ID of itself, and specific implementation principles and technical effects can be referred to the scheme executed by the master device in the foregoing embodiment, which will not be described herein. In an optional embodiment, after the single line is preempted unsuccessfully, the first device becomes a slave device and enters a receiving state, at this time, the master device is one of the second devices, and can be any second device that successfully preempts the single line to become the master device. In the generation process of the device ID of the Mesh network, the master device will change constantly. The first device as the slave device receives the ID data sent by the master device, verifies the ID data, and sends the confirmation information or the verification failure information to the master device through the single line. Specifically, the first device as the slave device receives the ID data sent by the second device (the current master device) through the single line, and sends the confirmation information to the second device through the single line. The received ID data is verified, and if the verification of the received ID data fails, the verification failure information is sent to the second device through the single line.If the received ID data is verified successfully, the received ID data is stored as a locked ID. Further, the first device verifies the received ID data, and if the received ID data fails verification, sends verification failure information to the second device through the single line, specifically including: checking the check information in the received ID data, and if the check is incorrect, sending first verification failure information indicating that the ID data check is incorrect to the second device through the single line; and / or, verifying whether the to-be-locked ID in the received ID data and the stored locked ID have ID conflicts, and if there are ID conflicts, sending second verification failure information indicating that there are ID conflicts to the second device through the single line. As a slave device, when receiving the single line release command, if the ID of the first device has not been locked, enters the request state and occupies the single line. In the embodiment, after the first device fails to occupy the single line, the processing logic of the slave device is executed, and the specific implementation principle and technical effects are described with reference to the scheme executed by the master device in the foregoing embodiment, which will not be described herein. FIG. 12 is a method flowchart executed by any device in a Mesh network according to an embodiment of the present disclosure. As shown in FIG. 12, after power-on, the device monitors the idle state of the single line and determines whether the single line satisfies the idle condition. When it is detected that the single line satisfies the idle condition, the single line is successfully occupied to become a master device, enters the sending state, and sends ID data of a to-be-locked ID, which can be obtained by adding 1 to the locally stored ID. Then, the device monitors the ACK and Err returned by other devices (currently acting as slave devices) on the single line, and determines whether the ACK and Err are received. When it is monitored that there is ACK and no Err, that is, the ACK is received and the Err is not received, the to-be-locked ID is locked, and the device enters the receiving state. When it is monitored that there is ACK and Err, according to the type of the Err, if the Err indicating that there are ID conflicts is received, the locally stored ID information is updated, and the locally stored ID is added by 1. Then, the step of sending ID data of a to-be-locked ID is executed, and the to-be-locked ID is still obtained by adding 1 to the current locally stored ID (equivalent to adding 1 to the previous to-be-locked ID). If the Err indicating that the ID data check is incorrect is received, it is confirmed that the data is incorrect, the device returns to the request state, and waits for the single line occupation. When it is detected that the single line does not satisfy the idle condition, the device enters the receiving state as a slave device. When in the receiving state, if the single line release command is received and the local ID is in the active state (that is, the state attribute of the locally stored ID information is in the active state), the device returns to the request state and waits for the single line occupation.In the receiving state, if no single-wire release command is received and the local ID is in the active state, the slave device returns an ACK to the master device through the single wire after receiving the ID data sent by the master device. Next, the slave device checks the ECC in the ID data. If the ECC check fails, the slave device returns an Err indicating that the ID data check fails to the master device. If the ECC check is correct, the slave device verifies whether there is an ID conflict between the ID to be locked in the ID data and the locally stored ID. If there is an ID conflict, the slave device returns an Err indicating that there is an ID conflict to the master device. If there is no ID conflict, no Err is returned, and if the locally stored ID is in the active state, the locally stored ID is updated to the ID to be locked, and the slave device waits to return to the request state after receiving the single-wire release command. The embodiment also provides a heterogeneous server, and FIG. 13 is an architecture diagram of the heterogeneous server provided by the embodiment of the present disclosure. As shown in FIG. 13, the heterogeneous server includes a plurality of GPU nodes (three GPU nodes, namely, GPU 1, GPU 2, and GPU 3, are taken as an example for illustrative purposes in FIG. 13), and the plurality of GPU nodes are interconnected through a Mesh bus to form a Mesh network. One single wire in the Mesh bus is configured to generate an ID of the GPU node. Through the single wire, the automatic generation of the ID of the GPU node in the heterogeneous server is implemented based on a single-wire communication protocol. It should be noted that, in order to highlight the reserved single wire, the connection of the single wire is separately drawn in FIG. 13, although it is not drawn in the middle of the bus, the single wire is one physical single wire in the Mesh bus of the Mesh network. After each GPU node is powered on, the single wire is preempted, the GPU node that successfully preempts the single wire is the current master device, and the GPU node that fails to preoccupy the single wire is the current slave device. The master device determines a new ID as the ID to be locked based on the locked ID, and sends the ID data of the ID to be locked to the slave device through the single wire. Then, the master device monitors the return information of the slave device on the single wire. The slave device receives the ID data through the single wire, returns the confirmation information to the master device, verifies the ID data, and returns the verification failure information to the master device through the single wire when the verification fails; and the master device locks the ID to be locked as the ID of the master device and releases the single wire after receiving the confirmation information and without receiving the verification failure information. Through the above process, the GPU node as the master device successfully locks the ID used by itself, and after locking the ID, the GPU node releases the single wire and no longer preoccupies the single wire.After the single line is released, other GPU nodes that have not locked the ID continue to seize the single line, and the GPU node that seizes the single line will be the new master device, and perform the above process of locking the ID. In this way, until all GPU nodes lock the ID, the automatic generation of the ID of the GPU node in the heterogeneous server is completed. In an optional embodiment, the slave device verifies the ID data, and returns verification failure information to the master device through the single line when the verification fails, including: the slave device checks the information in the received ID data, and if the check is incorrect, the slave device returns first verification failure information indicating that the ID data check is incorrect to the master device through the single line; and / or, the slave device verifies whether the to-be-locked ID in the received ID data conflicts with the stored locked ID, and if there is an ID conflict, the slave device returns second verification failure information indicating that there is an ID conflict to the master device through the single line. Further, in the case of receiving the second verification failure information, the master device increases the to-be-locked ID by a preset increment as a new to-be-locked ID, and sends ID data of the new to-be-locked ID to the slave device through the single line. In the case of receiving the first verification failure information, the master device enters a request state and re-seizes the single line. The processing flow of the plurality of GPUs seizing the single line, the master device, and the slave device in the embodiment is described with reference to the processing flow of the devices seizing the single line, the master device, and the slave device in the Mesh network in the foregoing embodiment, which is not described herein. The embodiment provides a single line communication scheme without fixed master and slave devices, and the GPU nodes in the heterogeneous server compete to become the master device by seizing the single line, the master device that successfully seizes the single line generates and locks the ID of the master device, and then releases the single line. After the single line is released, other GPU nodes can continue to seize the single line to become the master device and generate and lock the ID of the master device. Until all GPU nodes lock the ID, the automatic generation of the ID of the GPU node in the heterogeneous server is completed, and the original complex topology connection relationship of the GPU node in the heterogeneous server is decoupled, without the need to increase an additional management device, and compared with the heterogeneous server that increases the management device for generating the device ID, the hardware cost of generating the ID of the GPU node in the heterogeneous server and the complexity of the topology between the GPU nodes in the heterogeneous server are reduced. FIG. 14 is a structural schematic diagram of a device of a Mesh network provided by an embodiment of the disclosure. As shown in FIG. 14, the Mesh network device includes a memory 1401 and a processor 1402. The memory 1401 is configured to store computer execution instructions and can be configured to store various data to support operations on the Mesh network device.The processor 1402 is connected with the memory 1401, and is configured to execute computer-executable instructions stored in the memory 1401, so as to implement the technical solutions provided by any of the foregoing method embodiments, and the specific functions and technical effects that can be achieved are similar, and will not be repeated here. Optionally, as shown in FIG. 14, the Mesh network device further includes a firewall 1403, a load balancer 1404, a communication component 1405, a power supply component 1406 and other components. Only part of the components are shown in FIG. 14, and this does not mean that the Mesh network device only includes the components shown in FIG. 14. In FIG. 14, only the Mesh network device deployed in the cloud as a cloud Mesh network device is exemplarily illustrated, and the Mesh network device can also be deployed locally, which is not limited here. The embodiments of the present disclosure further provide a computer-readable storage medium, and the computer-readable storage medium stores computer-executable instructions. When a processor executes the computer-executable instructions, the method of any of the foregoing embodiments is implemented, and the specific functions and technical effects that can be achieved will not be repeated here. The embodiments of the present disclosure further provide a computer program product, including a computer program. When the computer program is executed by a processor, the method of any of the foregoing embodiments is implemented. The computer program is stored in a readable storage medium, and at least one processor of the Mesh network device can read the computer program from the readable storage medium. The at least one processor executes the computer program, so that the Mesh network device executes the technical solutions provided by any of the foregoing method embodiments, and the specific functions and technical effects that can be achieved will not be repeated here. The embodiments of the present disclosure provide a chip, including a processing module and a communication interface. The processing module can execute the technical solutions of the Mesh network device in the foregoing method embodiments. Optionally, the chip further includes a storage module (such as a memory). The storage module is configured to store instructions. The processing module is configured to execute the instructions stored in the storage module, and the execution of the instructions stored in the storage module causes the processing module to execute the technical solutions provided by any of the foregoing method embodiments. The integrated modules in the form of software function modules can be stored in a computer-readable storage medium. The software function modules are stored in a storage medium, and include a plurality of instructions for causing a computer device or a processor to execute part of the steps of the method of the embodiments of the present disclosure.It should be understood that the above processor can be a central processing unit (CPU), a graphics processing unit (GPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in combination with the present disclosure can be directly embodied as hardware processor execution, or executed by a combination of hardware and software modules in at least one processor. The storage can include a high-speed random access memory (RAM), and can also include a non-volatile storage, such as at least one disk memory, and can also be a U disk, a mobile hard disk, a read-only memory, a magnetic disk or an optical disk, etc. The above storage can be object storage (OSS). The above storage can be realized by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk. The above communication component is configured to facilitate wired or wireless communication between the device where the communication component is located and other devices.The device in which the communication component is located can access a wireless network based on a communication standard, such as a mobile hotspot (WiFi), a second generation mobile communication system (2G), a third generation mobile communication system (3G), a fourth generation mobile communication system (4G) / Long Term Evolution (LTE), a fifth generation mobile communication system (5G), or the like, or a combination thereof. In an example embodiment, the communication component receives a broadcast signal or broadcast related information from an external broadcast management system via a broadcast channel. In an example embodiment, the communication component further includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on Radio Frequency Identification (RFID) technology, infrared technology, Ultra Wide Band (UWB) technology, Bluetooth technology, and other technologies. The power supply component provides power to various components of the device in which the power supply component is located. The power supply component can include a power supply management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply component is located. The storage medium can be implemented by any type of volatile or non-volatile storage devices or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read only memory (EEPROM), erasable programmable read only memory (EPROM), programmable read only memory (PROM), read only memory (ROM), magnetic storage, flash memory, magnetic or optical disks. The storage medium can be any available medium that can be accessed by a general or special purpose computer. An example storage medium is coupled to the processor, such that the processor can read information from, and write information to, the storage medium. Of course, the storage medium can be part of the processor. The processor and the storage medium can be located in an application specific integrated circuit. The processor and the storage medium can also be located in a remote terminal or server. It is understood that the terms "including," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements recited, but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus.Without more limitations, the element defined by the statement "comprising a ……" does not exclude the presence of additional identical elements in the process, method, article, or apparatus including the element. The order of the above-described embodiments is merely an example and does not indicate the advantages of the embodiments. In addition, in some of the processes described in the above-described embodiments and accompanying drawings, a plurality of operations appear in a certain order. However, it should be clearly understood that the operations can be performed in a different order or in parallel to each other, and the order is merely used to distinguish different operations. In addition, the processes can include more or fewer operations, and the operations can be performed in sequence or in parallel. It should be noted that the "first", "second", and the like in the description herein are used to distinguish different messages, devices, modules, and the like, and do not represent the order. In addition, "first" and "second" are different types. The meaning of "a plurality of" is two or more, unless otherwise explicitly specified. Through the description of the above embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment method can be realized by software and a necessary general hardware platform. Of course, it can also be realized by hardware, but in many cases, the former is a better embodiment. Based on this understanding, the technical solutions of the disclosure can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, or optical disc) and includes a plurality of instructions for causing a terminal device to execute the method of each embodiment of the disclosure. Those skilled in the art can easily derive other embodiments of the disclosure after considering the specification and practicing the disclosed invention. The disclosure is intended to cover any variations, uses, or adaptations of the disclosure that follow the general principles of the disclosure and include common knowledge or conventional techniques in the art that are not disclosed in the disclosure. The above is only the preferred embodiment of the disclosure, and does not limit the patent scope of the disclosure. Any equivalent structure or equivalent process transformation using the content of the specification and drawings, or directly or indirectly applied to other related technical fields, is also included in the patent protection scope of the disclosure.

Claims

CLAIM 1. A Mesh network, wherein, The application relates to a method for generating a device ID in a mesh bus, comprising the following steps: a plurality of devices are interconnected through a mesh bus, and a single line in the mesh bus is configured to generate a device ID; each device occupies the single line after being powered on, a device successfully occupying the single line is a master device, and a device failing to occupy the single line is a slave device; the master device determines a new ID as a to-be-locked ID based on a locked ID, sends ID data of the to-be-locked ID to the slave device through the single line, the slave device receives the ID data through the single line, returns confirmation information of the ID data to the master device, verifies the ID data, and returns verification failure information of the ID data to the master device when verification fails; the master device locks the to-be-locked ID as an ID of the master device when the confirmation information is received and the verification failure information is not received, and releases the single line.

2. The Mesh network of claim 1, wherein, the slave device verifies the ID data, and returns verification failure information of the ID data to the master device when verification fails, which comprises the following steps: the slave device checks the check information in the received ID data, and returns first verification failure information indicating that the ID data is checked incorrectly to the master device when the check is incorrect; and / or the slave device verifies whether the to-be-locked ID in the received ID data and the stored locked ID have ID conflicts, and returns second verification failure information indicating that there is an ID conflict to the master device when there is an ID conflict.

3. The Mesh network of claim 2, wherein, The application further comprises the following steps: when the second verification failure information is received, the master device increases the to-be-locked ID by a preset increment as a new to-be-locked ID, and sends ID data of the new to-be-locked ID to the slave device through the single line.

4. The Mesh network of claim 2 or 3, wherein, The application further comprises the following steps: when the first verification failure information is received, the master device enters a request state and re-occupies the single line.

5. The Mesh network of any of claims 1-4, wherein, The application further comprises the following steps: each device enters a request state after being powered on, and monitors whether the single line meets idle conditions; when it is monitored that the single line meets idle conditions, a clock synchronization command is sent through the single line, the clock synchronization command is used for occupying the single line and performing clock synchronization; and after successfully occupying the single line, the device enters a sending state.

6. The Mesh network of any one of claims 1-5, wherein, The application further comprises the following steps: the single line is released, a single line release command is sent through the single line, the single line is released, a receiving state is entered, and the single line is no longer occupied.

7. The Mesh network of any one of claims 1-6, wherein, The application further comprises the following steps: when a single line release command is received through the single line, each device enters a request state and occupies the single line if the ID of the device has not been locked.

8. A data processing method of a Mesh network, wherein, A first device applied to a Mesh network, devices in the Mesh network are interconnected through a Mesh bus, a single line in the Mesh bus is configured to generate a device ID, the method comprising: occupying the single line after power-on; After successfully occupying the single line, a new ID is determined as a to-be-locked ID based on the locked ID, and ID data of the to-be-locked ID is sent to a second device through the single line, the second device being a device other than the first device in the Mesh network. The slave device receives the ID data through the single line, returns confirmation information to the master device, verifies the ID data, and returns verification failure information to the master device through the single line when verification fails; the master device locks the to-be-locked ID as the ID of the master device when receiving the confirmation information and not receiving the verification failure information, and releases the single line.

17. The heterogeneous server of claim 16, wherein, The slave device verifies the ID data, and returns verification failure information to the master device through the single line when verification fails, comprising: the slave device checks the check information in the received ID data, if the check is wrong, the slave device returns first verification failure information indicating that the ID data check is wrong to the master device through the single line; and / or, the slave device verifies whether the to-be-locked ID in the received ID data and the stored locked ID exist ID conflict, if there is ID conflict, the slave device returns second verification failure information indicating that there is ID conflict to the master device through the single line.

18. The heterogeneous server of claim 17, wherein, Further comprising: In the case of receiving the second verification failure information, the master device increases the to-be-locked ID by a preset increment as a new to-be-locked ID, and sends ID data of the new to-be-locked ID to the slave device through the single line; in the case of receiving the first verification failure information, the master device enters a request state and re-occupies the single line.

19. A computer-readable storage medium, wherein, The computer readable storage medium stores computer execution instructions, when the processor executes the computer execution instructions, the method of any one of claims 8-15 is realized.

20. A computer program product comprising a computer program, wherein, The computer program is executed by the processor to realize the method of any one of claims 8-15. 19

Images