Communication method, electronic device, computer program product, and storage medium

Abstract

The application discloses a communication method, an electronic device, a computer program product and a storage medium, and belongs to the technical field of communication. When an interrupt request generated by a slave is detected, a slave address is analyzed and used as an index of an interrupt control table, and response information is read from the interrupt control table. The interrupt control table comprises response information corresponding to all slave addresses. A first device address table and a second device address table jointly constitute device information of all slaves. The second device address table and the interrupt control table are stored in host hardware, and the first device address table is stored in a memory. When data needs to be read from a slave, whether the slave address exists in the first device address table is queried. If yes, table entry exchange is performed, otherwise, communication information issued by a host program is received, and communication with the slave is implemented. The application can effectively solve the problem of frequent replacement of slave device information, and does not consume too many resources of host hardware.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a communication method, electronic device, computer program product, and storage medium. Background Technology

[0002] The Sideband Bus (SMB) is a system management bus for next-generation memory solutions. Based on the I3C Basic protocol, it is primarily used in systems with memory modules, such as RDIMMs (Registered Dual In-line Memory Modules). Each RDIMM can contain an SPD5 device acting as a hub for the Sideband Bus, responsible for re-driving the host bus signals to the local bus, thus connecting multiple local devices. Each local device acts as a slave, with its own address. For example, devices connected to the local bus might include a registered clock driver, two PMIC voltage regulators, and two temperature sensors. In some high-end server systems, multiple RDIMM modules are typically deployed.

[0003] To manage all slave devices on the bus, one current approach involves the host hardware recording some slave device information. If the information of a slave device that triggers an interrupt is not recorded in the hardware, software is used to synchronize this information to the hardware, allowing the hardware to respond to the interrupt based on this information. However, in high-temperature, high-load server environments, when multiple slave devices trigger interrupts simultaneously, frequent replacement operations occur. Furthermore, due to the randomness of these replacements, the information of a device about to trigger an interrupt may be overwritten, further contributing to the cumulative delay in interrupt response. Alternatively, some solutions record all necessary device information in the hardware to avoid replacements, but this increases hardware size, power consumption, and cost.

[0004] In summary, how to effectively realize communication between master and slave devices, solve the problem of frequent information replacement by slave devices and the resulting cumulative delay effect are technical problems that urgently need to be solved by those skilled in the art. Summary of the Invention

[0005] The purpose of this invention is to provide a communication method, electronic device, computer program product, and storage medium to effectively realize communication between master and slave devices, and to solve the problem of frequent information replacement by slave devices and the resulting cumulative delay effect.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0007] In a first aspect, the present invention provides a communication method applied to a communication controller in a host computer, comprising:

[0008] When an interrupt request generated by a slave device is detected, the slave address parsed from the interrupt request is used as an index to the interrupt control table, and the response information is read from the interrupt control table; wherein, the interrupt control table includes the response information corresponding to each of the slave addresses;

[0009] When the response information indicates that a response is needed to the slave device and data needs to be read from the slave device, the host program queries whether the slave device address exists in the first device address table; wherein, the first device address table and the second device address table together constitute the device information of all slave devices, the second device address table and the interrupt control table are both stored in the host hardware managed by the communication controller, and the first device address table is stored in memory;

[0010] If so, the host program selects the entry to be exchanged from the second device address table, exchanges the entry in the first device address table that carries the slave address with the entry to be exchanged, and receives the communication information sent by the host program after the exchange.

[0011] If not, then receive the communication information sent by the host program;

[0012] Based on the communication information, read the device information with the slave address from the second device address table;

[0013] The device communicates with the slave device based on the device information and reads data from the slave device.

[0014] In one implementation, when the response information indicates a need to respond to the slave device and to read data from the slave device, the host program queries whether the slave device address exists in the first device address table, including:

[0015] Determine whether the interrupt response field of the response information belongs to the interrupt response field that indicates a need to respond to the slave device;

[0016] If it belongs to an interrupt response field that indicates a need to respond to the slave device, then determine whether the interrupt payload field of the response information belongs to an interrupt payload field that indicates a need to read data from the slave device;

[0017] If it belongs to the interrupt load field indicating that data needs to be read from the slave device, the host program queries whether the slave device address exists in the first device address table.

[0018] In one implementation, querying whether the slave address exists in the first device address table via the host program includes:

[0019] The host program traverses each entry of the first device address table to determine whether the slave address exists in the first device address table, or the host program traverses each entry of the second device address table to determine whether the slave address exists in the first device address table.

[0020] In one implementation, the host program selects the entry to be exchanged from the second device address table, including:

[0021] The host program selects an entry to be exchanged from the second device address table by randomly selecting an entry.

[0022] In one implementation, the host program selects the entry to be exchanged from the second device address table, including:

[0023] The host program selects entries to be exchanged from the second device address table, and the slave addresses in the entries to be exchanged are slave addresses whose access popularity is below a threshold in the most recent first time period.

[0024] In one implementation, it further includes:

[0025] Determine whether the selected entry to be exchanged is an entry carrying a prohibited exchange flag;

[0026] If so, the host program will reselect the entry to be exchanged from the second device address table.

[0027] In one implementation, receiving communication information sent by the host program includes:

[0028] Receive communication information sent by the host program, which carries communication commands, communication data, communication timing, and a second device address table index.

[0029] In one implementation, reading device information with the slave address from the second device address table based on the communication information includes:

[0030] Based on the second device address table index in the communication information, read the device information with the slave address from the second device address table;

[0031] The device information read includes at least the slave address and the device type.

[0032] In one embodiment, the device type includes a two-wire serial communication device and an improved two-wire serial communication device; the communication controller is an improved two-wire serial communication controller.

[0033] In one implementation, communicating with the slave device based on the device information and reading data from the slave device includes:

[0034] A data packet is constructed based on the communication information and the device information;

[0035] According to the communication sequence, the data packet is sent to the slave device to communicate with the slave device and to read data from the slave device.

[0036] In one implementation, it further includes:

[0037] When a communication anomaly is detected with the slave device, preset communication anomaly handling measures are executed.

[0038] In one implementation, it further includes:

[0039] When the host initiates communication with the slave device, the host program queries whether the slave device's address exists in the first device address table.

[0040] If so, the host program selects the entry to be exchanged from the second device address table, exchanges the entry in the first device address table that carries the slave address with the entry to be exchanged, and receives the communication information sent by the host program after the exchange.

[0041] If not, then receive the communication information sent by the host program;

[0042] Based on the communication information, read the device information with the slave address from the second device address table;

[0043] Based on the device information, the device communicates with the slave device to read or write data to the slave device.

[0044] In a second aspect, the present invention provides an electronic device, comprising:

[0045] Memory, used to store computer programs;

[0046] A processor for implementing the communication method as described above when executing the computer program.

[0047] Thirdly, the present invention provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the communication method described above.

[0048] Fourthly, the present invention provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the communication method described above.

[0049] The technical solution provided in this invention uses a dedicated interrupt control table to store the slave device's response information. Other device information for the slave device is stored in a device address table. That is, the entries in the device address table include device information such as the slave device address, but do not need to include the slave device's response information. The device address table is divided into a software-stored first device address table and a hardware-stored second device address table. When an interrupt request generated by a slave device is detected, the response information can be read from the interrupt control table. The interrupt control table includes the response information corresponding to each of all slave device addresses. In other words, the interrupt control table is a complete table storing the response information of each slave device; it is a full-device interrupt control table. Therefore, this operation will not lead to a replacement operation, effectively reducing the frequency of replacement operations in this application. Furthermore, after obtaining the response information, subsequent responses are only performed when the response information indicates a need to respond to the slave device and read data from it, further reducing the frequency of replacement operations in this application.

[0050] When the response information indicates a need to respond to the slave device and read data from it, the host will query the first device address table via the host program. In this application, the first and second device address tables together constitute the device information for all slave devices. The first device address table is a software-stored device address table, which can be stored in memory, while the second device address table is stored in the host hardware managed by the communication controller; that is, the second device address table is a hardware-stored device address table. Therefore, if the slave address of the slave device initiating the interrupt exists in the first device address table, a replacement operation is required. Specifically, the host program selects the entry to be swapped from the second device address table and swaps the entry carrying the slave address from the first device address table with the entry to be swapped in the second device address table. After the swap is complete, the host controller can receive the communication information sent by the host program. Of course, if the slave address does not exist in the first device address table, it means that the slave address exists in the second device address table. In this case, no swap is needed, and the host controller can directly receive the communication information sent by the host program. After obtaining the communication information, the device information of the slave address of the slave that initiated the interrupt can be read from the second device address table based on the communication information. Then, communication can be carried out with the slave based on the device information, and data can be read from the slave to complete the interrupt response of the slave.

[0051] As can be seen, this application does not store all slave device information in the hardware. Instead, it uses a first device address table and a second device address table to construct all slave device information. This reduces the cost of the host hardware and avoids the increased hardware area, power consumption, and cost associated with full hardware recording in traditional solutions. In other words, this application effectively controls the cost of the host hardware. Furthermore, although this application stores all device response information in the interrupt control table and stores the interrupt control table through the host hardware, the content of the interrupt control table is relatively simple. Moreover, this application directly uses the slave address as the index of the interrupt control table. Compared to the device address table, storing the complete interrupt control table through the host hardware requires fewer host hardware resources, and the design of related peripheral circuits is not overly complex. In other words, the design of storing the complete interrupt control table through the host hardware effectively reduces the frequency of replacement operations without consuming excessive host hardware resources.

[0052] In summary, the solution proposed in this application can effectively realize communication between the master and slave devices, solve the problem of frequent information replacement of slave devices and the resulting cumulative delay effect, and will not consume too much host hardware resources, nor will it result in the increase in hardware area, power consumption and cost caused by the full hardware recording in traditional solutions. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0054] Figure 1 A flowchart illustrating the implementation of a communication method according to a specific embodiment of the present invention;

[0055] Figure 2 This is a schematic diagram illustrating the storage of the system-level device address table and interrupt control table in a specific embodiment of the present invention.

[0056] Figure 3 This is a schematic diagram of the structure of an electronic device provided in a specific embodiment of the present invention;

[0057] Figure 4 This is a schematic diagram of the structure of a computer-readable storage medium according to the present invention. Detailed Implementation

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

[0059] To enable those skilled in the art to better understand the present invention, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0060] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of a communication method provided by the present invention. This communication method can be applied to a communication controller in a host computer and includes the following steps:

[0061] Step S101: When an interrupt request generated by a slave device is detected, the slave address parsed from the interrupt request is used as the index of the interrupt control table, and the response information is read from the interrupt control table. The interrupt control table includes the response information corresponding to each of the slave device addresses.

[0062] The solution proposed in this application can be applied to the communication controller in the host computer. The communication controller can be, for example, an improved two-wire serial communication controller, namely an I3C (Improved Inter-Integrated Circuit) controller, which can effectively achieve compatibility between the I3C protocol and the I2C (Inter-Integrated Circuit) protocol. In the following description of this application, the I3C controller will also be used as an example.

[0063] The host in this application can be an integrated circuit carrying a communication controller. For example, in practical applications, the host can be a chip with an I3C controller on a server, such as a monitoring chip with an I3C controller mounted on the main board. The slave devices communicate with the host, such as various devices in the RDIMM modules that communicate with the host. Different slave devices have different addresses.

[0064] When a slave device initiates communication with the master, it needs to do so through an interrupt. That is, the slave device will generate an interrupt. When the I3C controller in the master detects an interrupt request generated by a slave device, it can parse the interrupt request and thus parse the slave address of the slave device that initiated the interrupt.

[0065] In this application, the entry index of the interrupt control table is the address of the interrupt requesting device. That is, the slave address is used as the index of the interrupt control table. Therefore, after parsing the slave address of the slave that initiated the interrupt from the interrupt request, it is used as the index of the interrupt control table. The response information of the slave can then be read from the interrupt control table, that is, the response information corresponding to the slave address can be read. Through the read response information, the response settings for the slave can be determined.

[0066] Step S102: When the response information indicates that a response is needed from the slave device and data needs to be read from the slave device, the host program checks whether the slave device address exists in the first device address table. If yes, proceed to step S103; otherwise, proceed to step S104.

[0067] The first device address table and the second device address table together constitute the device information of all slave devices. The second device address table and the interrupt control table are both stored in the host hardware managed by the communication controller, and the first device address table is stored in memory.

[0068] After receiving the response information, it is necessary to determine whether to respond to the slave device and read data from it. There are several ways to determine this, and the specific settings can be based on the format of the response information. If it is necessary to respond to the slave device and read data from it, the master device needs to initiate communication with the slave device. In this case, the master device needs to use a software program, specifically the master program, to check if the slave device address exists in the first device address table.

[0069] In one specific embodiment of the present invention, step S102 may specifically include:

[0070] Determine whether the interrupt response field in the response information belongs to the interrupt response field that indicates a need to respond to the slave device;

[0071] If it belongs to the interrupt response field that indicates that a response needs to be made to the slave, then determine whether the interrupt payload field of the response information belongs to the interrupt payload field that indicates that data needs to be read from the slave.

[0072] If it belongs to the interrupt payload field that indicates that data needs to be read from the slave device, then the host program queries whether the slave address exists in the first device address table.

[0073] In this implementation, the response information stored in the interrupt control table includes an interrupt response field and an interrupt payload field. That is, each entry in the interrupt control table includes the corresponding slave's interrupt response field and interrupt payload field. The interrupt response field controls whether to respond to the slave's interrupt request, while the interrupt payload field indicates whether the slave's interrupt request carries data.

[0074] Therefore, after obtaining the response information from the slave device that initiated the interrupt from the interrupt control table, it is necessary to determine whether the interrupt response field belongs to the interrupt response field that indicates a response to the slave device is required. For example, in one scenario, a content of 01 in the interrupt response field indicates a response to the slave device is required, while a content of 00 indicates no response is required. Furthermore, it is understandable that if the interrupt response field belongs to the interrupt response field that indicates no response is required to the slave device, the process can be terminated, and the master device does not need to respond to the interrupt request from that slave device.

[0075] If the interrupt response field indicates that a response is needed from the slave device, then it is necessary to further determine whether the interrupt payload field indicates that data needs to be read from the slave device. For example, in one scenario, an interrupt payload field value of 11 indicates that data needs to be read from the slave device, while an interrupt payload field value of 00 indicates that data does not need to be read from the slave device. Furthermore, it is understandable that if the interrupt payload field indicates that data does not need to be read from the slave device, the process can also be terminated, and the master device does not need to read data from that slave device.

[0076] Furthermore, it is understood that in practical applications, appropriate response methods can be set according to actual needs for situations where no response is required from the slave device, or where a response is required from the slave device but no data needs to be read from it. This application will not elaborate on this further. For example, for interrupt requests that do not require a response, although the master device does not respond, it will log the interrupt requests generated by the slave device and count the number of recent interruptions of the slave device.

[0077] If the interrupt payload field of the response information belongs to the interrupt payload field that indicates that data needs to be read from the slave, then the master needs to initiate communication with the slave. At this time, the master needs to query whether the slave address exists in the first device address table through the software program, that is, through the master program.

[0078] Furthermore, it is understood that the interrupt control table includes the response information corresponding to each of the slave addresses. In other words, the interrupt control table of this application is a complete table storing the response information of each slave, meaning it is a complete interrupt control information table for the entire device. Therefore, the operation in step S101 will not lead to a replacement operation, effectively reducing the frequency of replacement operations in this application's scheme. After obtaining the response information, subsequent responses will only be performed when the response information indicates that a response to the slave is required and data needs to be read from the slave, further reducing the frequency of replacement operations in this application's scheme.

[0079] See also Figure 2This is a schematic diagram illustrating the storage of the system-level device address table and interrupt control table in a specific implementation. In this example, the communication controller is specifically an I3C controller. The I3C protocol specifies 7 address bits, therefore there can be a maximum of 128 slave devices. Thus, the interrupt control table for the entire device contains 128 entries, each corresponding to one slave device, with the slave address of each slave device serving as the entry index in the interrupt control table. It can be seen that... Figure 2 The interrupt control table is a device-wide interrupt control table, with each entry having an interrupt response field and an interrupt payload field, totaling 128 entries. It should be noted that the interrupt control table in this application is stored in the host hardware managed by the communication controller; that is, the interrupt control table is stored through dedicated host hardware, such as the RAM in the monitoring chip mentioned in the previous example.

[0080] The interrupt control table is stored using dedicated host hardware, meaning it utilizes the chip's internal hardware resources. While these resources are limited, the interrupt control table in this application is relatively simple. Furthermore, the application directly uses the slave address as the index for the interrupt control table. This means that compared to a device address table, even with the entire device's interrupt control table stored in host hardware, the host hardware resources consumed by the interrupt control table are not excessive, and the design of its related peripheral circuits is not overly complex. In other words, this application's design of storing the entire device's interrupt control table in host hardware effectively reduces the frequency of replacement operations without consuming excessive host hardware resources.

[0081] When querying whether a slave address exists in the first device address table via a host program, there can be various implementation methods, typically involving traversal. In one specific embodiment of the present invention, step S102, which describes querying whether a slave address exists in the first device address table via a host program, may include:

[0082] The host program iterates through each entry of the first device address table to determine whether the slave address exists in the first device address table, or the host program iterates through each entry of the second device address table to determine whether the slave address exists in the first device address table.

[0083] This implementation takes into account that the first device address table and the second device address table together constitute the device information of all slave devices. Therefore, if a slave address does not exist in any entry of the first device address table, it exists in some entry of the second device address table, and vice versa. Thus, during traversal, the host program can traverse each entry of the first device address table to determine whether the slave address exists in the first device address table. That is, if after traversing each entry of the first device address table, there is an entry containing the slave address, then the slave address exists in the first device address table; otherwise, the slave address exists in the second device address table. Alternatively, the first device address table can be traversed instead of the second device address table. If after traversing each entry of the second device address table, there is an entry containing the slave address, then the slave address exists in the second device address table; otherwise, the slave address exists in the first device address table.

[0084] In this implementation, either the first device address table or the second device address table can be traversed, improving the implementation flexibility of the present application. Furthermore, in practical applications, it is usually preferable to traverse the first device address table, as this is software-stored and makes traversing the first device address table more convenient.

[0085] Step S103: The host program selects the entry to be exchanged from the second device address table, exchanges the entry carrying the slave address in the first device address table with the entry to be exchanged, and receives the communication information sent by the host program after the exchange.

[0086] The first device address table and the second device address table together constitute the device information of all slave devices. That is, the first device address table and the second device address table together constitute the device information of the entire device. The device information of a certain slave device described in this application, that is, a certain entry in the first device address table or the second device address table, refers to the device information of the slave device such as address and type. Typically, it can include the device type, device address (i.e., slave address) and other information of the slave device, and can be set and adjusted according to actual needs. However, it is understood that it is not necessary to include the response information of the slave device, because the response information of the entire device has been stored using the interrupt control table.

[0087] In this application, both the second device address table and the interrupt control table are stored in the host hardware managed by the communication controller, while the first device address table is stored in memory. That is, the second device address table is stored through dedicated host hardware, which the I3C controller can access to communicate with the corresponding slave device. The first device address table, stored in memory, is a software-stored device address table. Although it does not occupy dedicated host hardware resources, the I3C controller cannot directly access it. Therefore, if the host program finds that the slave address exists in the first device address table, it needs to swap the entry containing the slave address from the first device address table to the second device address table, that is, from memory to the host hardware, so that the I3C controller can read the device information of the slave device from the second device address table.

[0088] See also Figure 2 As described above, the I3C protocol specifies 7 address bits, allowing for a maximum of 128 slave devices. Therefore, in this implementation, the first device address table and the second device address table of this application have a total of 128 entries, with each entry corresponding to one slave device. The content of each entry is the device information of the corresponding slave device. Figure 2 In the example, the second device address table has N entries, while the first device address table has M entries, so N+M equals 128. Of course, in other implementations, when using protocols that can support more address bits, allowing the host to access more slave addresses, the total number of entries in the first and second device address tables, as well as the total number of entries in the interrupt control table, can be expanded accordingly.

[0089] For any entry in the first device address table and the second device address table, Figure 2 The example shows two fields for this table entry: the device type field and the slave address field. As described above, in practical applications, other fields can be set according to actual needs to include other required content in the device information.

[0090] Compared to the interrupt control table, the device address table is more complex. If both are stored in the host hardware, it would consume significant host hardware resources. Therefore, in this application, the device address table for the entire device is split into a first device address table stored in software and a second device address table stored in hardware, thereby effectively reducing host hardware costs. In other words, the internal hardware resources of the chip are limited; therefore, the internal hardware resources are used to store the second device address table, while the first device address table can be stored in external memory without consuming internal chip hardware resources.

[0091] Similar to the interrupt control table, a second device address table is stored in hardware, such as the RAM in the monitoring chip mentioned in the previous example. The first device address table, stored in software, can be stored in memory; for example, the monitoring chip can be connected to an external DDR memory chip to store the first device address table.

[0092] After the host program selects the entry to be swapped from the second device address table, it needs to swap the entry carrying the slave address in the first device address table with the entry to be swapped, which is a software replacement operation. For example, in a scenario where N=8 and M=120, the entry to be swapped selected from the second device address table is, for example, entry 2 in the second device address table (assuming the index of entry 2 in the second device address table is index_hw), and the entry in the first device address table carrying the slave address of the slave that initiated the interrupt is, for example, entry 50 in the first device address table (assuming the index of entry 50 in the first device address table is index_sw). Then, the entry with the index_sw in the first device address table needs to be swapped with the entry with the index_hw in the second device address table. That is, the entry with the index_sw originally stored in the first device address table needs to be stored in the second device address table, and the entry with the index_hw originally stored in the second device address table needs to be stored in the first device address table.

[0093] After the exchange is completed, the entry in the first device address table that corresponds to the slave address that needs to communicate is swapped to the second device address table, so that the I3C controller can subsequently read the device information of the slave from the second device address table and realize communication with the slave.

[0094] When selecting an entry to be exchanged from the second device address table, the specific selection method can be set according to actual needs. For example, in one specific embodiment of the present invention, selecting an entry to be exchanged from the second device address table by means of a host program can specifically include: selecting an entry to be exchanged from the second device address table by means of a random selection by the host program. This implementation method is a random selection, which is relatively simple and convenient to implement and does not require additional design.

[0095] Furthermore, in a specific embodiment of the present invention, selecting the entry to be exchanged from the second device address table by the host program may specifically include: selecting the entry to be exchanged from the second device address table by the host program, wherein the slave address in the entry to be exchanged is the slave address whose access popularity is lower than a threshold in the most recent first time period.

[0096] In this implementation, the slave address in the entry to be swapped is the slave address whose access frequency is below the threshold in the most recent first time period. In other words, in this implementation, the entry corresponding to the slave address with lower access frequency is preferentially selected as the entry to be swapped. This helps to reduce the probability of triggering the software replacement operation, which in turn helps to reduce the probability of triggering step S103 and increase the probability of triggering step S104. This also helps to improve the device interrupt response rate and improve the overall performance of the system.

[0097] Furthermore, it is understandable that in this implementation, for each slave address, it is necessary to count the access frequency of that slave address in the most recent first time period. For example, for each slave address, the number of interrupts initiated by that slave in the most recent first time period and the number of communications initiated by the master to that slave can be counted. The sum of these can be used as the access frequency of that slave address in the most recent first time period. This is relatively simple and convenient to implement.

[0098] Furthermore, in one specific embodiment of the present invention, it may also include:

[0099] Determine whether the selected item to be exchanged is an item carrying a prohibited exchange flag;

[0100] If so, the host program will reselect the entry to be swapped from the second device address table.

[0101] This implementation takes into account that in some situations, operators may not want to swap certain important slave device entries, but rather store them in a fixed hardware address table to avoid errors during software replacement. Therefore, in this implementation, after selecting the entry to be swapped, it can be determined whether the entry carries a "do not swap" flag. If it does, it means the entry is not allowed to be swapped, and the host program can then reselect the entry to be swapped from the second device address table, thus meeting the usage requirements of this implementation.

[0102] Step S104: Receive communication information sent by the host program.

[0103] The entry carrying the slave address in the first device address table is exchanged with the entry to be exchanged. After the exchange is completed, the I3C controller can receive the communication information sent by the host program. Of course, if the entry carrying the slave address is already stored in the second device address table, it means that no exchange is needed, and the operation of step S104 can be directly triggered so that the I3C controller can receive the communication information sent by the host program.

[0104] The specific content of the communication information sent by the host program can be set and adjusted according to actual needs, so that the I3C controller can effectively complete the communication with the slave device based on the communication information. For example, in a specific embodiment of the present invention, receiving the communication information sent by the host program may specifically include: receiving communication information sent by the host program that carries communication commands, communication data, communication timing, and a second device address table index.

[0105] In this embodiment, the communication information sent by the host program includes communication commands, communication data, communication timing, and a second device address table index, enabling the I3C controller to effectively complete the communication with the slave device. Of course, in other embodiments, the communication information sent by the host program may also carry other content as needed, which does not affect the implementation of the present invention.

[0106] Step S105: Read the device information with slave address from the second device address table based on the communication information.

[0107] After receiving the communication information, the I3C controller can read the device information with the slave address from the second device address table based on the communication information. In other words, the I3C controller can find the specific entry needed for this communication with the slave device in the second device address table based on the communication information. The device information in that entry is the device information that the I3C controller needs to read. Typically, the required entry can be located using the index of the second device address table in the communication information.

[0108] In one specific embodiment of the present invention, step S105 may specifically include:

[0109] Based on the second device address table index in the communication information, read the device information with slave address from the second device address table;

[0110] The device information read includes at least the slave address and the device type.

[0111] In this implementation, after receiving the communication information, the I3C controller can locate the required entry based on the second device address table index in the communication information, and then read the content of that entry, that is, read the device information of the required slave address. Furthermore, this implementation takes into account that different types of slave devices require different communication timings; therefore, the device information read must at least include the slave address and device type.

[0112] For example, in one scenario, the slave device type can include two-wire serial communication devices and improved two-wire serial communication devices; that is, the slave device type can include I2C devices and I3C devices. The communication controller can be an I3C controller, thus ensuring compatibility with both I2C and I3C devices.

[0113] Step S106: Communicate with the slave device based on the device information and read data from the slave device.

[0114] After reading the device information, the I3C controller can communicate with the slave device based on the device information, thereby reading data from the slave device.

[0115] In one specific embodiment of the present invention, step S106 may specifically include:

[0116] Data packets are constructed based on communication information and device information;

[0117] According to the communication sequence, data packets are sent to the slave device to communicate with it, and data is read from the slave device.

[0118] In this implementation, after reading the device information, the I3C controller can construct data packets based on the communication information and device information. For example, in one specific scenario, the I3C controller can assemble packets based on the communication commands and data in the communication information, combined with the slave address in the device information. Then, according to the communication timing sequence, the data packets are sent to the slave device to communicate with it. For example, when the slave device type is an I3C device, the data packets can be sent according to the I3C timing sequence, and when the slave device type is an I2C device, the data packets can be sent according to the I2C timing sequence.

[0119] In one specific embodiment of the present invention, the method may further include: when a communication anomaly with the slave device is detected, executing preset communication anomaly handling measures. This embodiment takes into account that the master device can detect communication anomalies, and when a communication anomaly with the slave device is detected, it can execute preset communication anomaly handling measures.

[0120] Of course, there are various methods for detecting communication anomalies and for implementing the preset communication anomaly handling measures. For example, in one specific embodiment of the present invention, bus hangup detection, timing violation detection, and slave response anomaly detection can be performed. Based on the specific type of communication anomaly, corresponding communication anomaly handling measures can be executed. For instance, when a slave device frequently experiences communication anomalies, it can be isolated. For errors such as timing violations and data integrity anomalies, data rereading / writing can be attempted. Furthermore, in some high-reliability scenarios, when a slave device frequently experiences communication anomalies, it can automatically switch to a backup slave device and record the fault information of the primary and secondary slave devices for subsequent troubleshooting.

[0121] In one specific embodiment of the present invention, it may further include:

[0122] When the host initiates communication with the slave device, the host program queries whether the slave device's address exists in the first device address table.

[0123] If so, the host program selects the entry to be exchanged from the second device address table, exchanges the entry carrying the slave address in the first device address table with the entry to be exchanged, and receives the communication information sent by the host program after the exchange.

[0124] If not, then receive the communication information sent by the host program;

[0125] Based on communication information, read device information with slave addresses from the second device address table;

[0126] The device communicates with the slave device based on the device information to read or write data to the slave device.

[0127] The process of the slave device initiating an interrupt and the master device responding has been described in detail above. This implementation further considers that the master device can also actively initiate communication with the slave device. Specifically, when the master device actively initiates communication with the slave device, the master program can query whether the slave device's slave address exists in the first device address table based on the slave device's slave address. The specific query method can be as described in the implementation method above.

[0128] If the slave address of the slave device exists in the first device address table, the entry containing that slave address needs to be swapped with the selected entry to be swapped in the second device address table. This ensures that the content of the entry corresponding to the slave address can be transferred to the second device address table. Of course, if the entry containing the slave address is already in the second device address table, no swapping is necessary. Subsequently, the I3C controller can receive communication information sent by the host program, and then read the device information with the slave address from the second device address table based on the communication information. Finally, it can communicate with the slave device based on the device information to read or write data to the slave device.

[0129] The technical solution provided in this invention uses a dedicated interrupt control table to store the slave device's response information. Other device information for the slave device is stored in a device address table. That is, the entries in the device address table include device information such as the slave device address, but do not need to include the slave device's response information. The device address table is divided into a software-stored first device address table and a hardware-stored second device address table. When an interrupt request generated by a slave device is detected, the response information can be read from the interrupt control table. The interrupt control table includes the response information corresponding to each of all slave device addresses. In other words, the interrupt control table is a complete table storing the response information of each slave device; it is a full-device interrupt control table. Therefore, this operation will not lead to a replacement operation, effectively reducing the frequency of replacement operations in this application. Furthermore, after obtaining the response information, subsequent responses are only performed when the response information indicates a need to respond to the slave device and read data from it, further reducing the frequency of replacement operations in this application.

[0130] When the response information indicates a need to respond to the slave device and read data from it, the host will query the first device address table via the host program. In this application, the first and second device address tables together constitute the device information for all slave devices. The first device address table is a software-stored device address table, which can be stored in memory, while the second device address table is stored in the host hardware managed by the communication controller; that is, the second device address table is a hardware-stored device address table. Therefore, if the slave address of the slave device initiating the interrupt exists in the first device address table, a replacement operation is required. Specifically, the host program selects the entry to be swapped from the second device address table and swaps the entry carrying the slave address from the first device address table with the entry to be swapped in the second device address table. After the swap is complete, the host controller can receive the communication information sent by the host program. Of course, if the slave address does not exist in the first device address table, it means that the slave address exists in the second device address table. In this case, no swap is needed, and the host controller can directly receive the communication information sent by the host program. After obtaining the communication information, the device information of the slave address of the slave that initiated the interrupt can be read from the second device address table based on the communication information. Then, communication can be carried out with the slave based on the device information, and data can be read from the slave to complete the interrupt response of the slave.

[0131] As can be seen, this application does not store all slave device information in the hardware. Instead, it uses a first device address table and a second device address table to construct all slave device information. This reduces the cost of the host hardware and avoids the increased hardware area, power consumption, and cost associated with full hardware recording in traditional solutions. In other words, this application effectively controls the cost of the host hardware. Furthermore, although this application stores all device response information in the interrupt control table and stores the interrupt control table through the host hardware, the content of the interrupt control table is relatively simple. Moreover, this application directly uses the slave address as the index of the interrupt control table. Compared to the device address table, storing the complete interrupt control table through the host hardware requires fewer host hardware resources, and the design of related peripheral circuits is not overly complex. In other words, the design of storing the complete interrupt control table through the host hardware effectively reduces the frequency of replacement operations without consuming excessive host hardware resources.

[0132] In summary, the solution proposed in this application can effectively realize communication between the master and slave devices, solve the problem of frequent information replacement of slave devices and the resulting cumulative delay effect, and will not consume too much host hardware resources, nor will it result in the increase in hardware area, power consumption and cost caused by the full hardware recording in traditional solutions.

[0133] Corresponding to the above methods and system embodiments, this invention also provides an electronic device, a computer-readable storage medium, and a computer program product, which can be referred to in conjunction with the above.

[0134] See Figure 3 As shown, the electronic device may include:

[0135] Memory 301 is used to store computer programs;

[0136] Processor 302 is configured to execute a computer program to implement the steps of the communication method as described in any of the above embodiments.

[0137] The computer program product includes a computer program / instructions that, when executed by a processor, implement the steps of the communication method as described in any of the above embodiments.

[0138] See also Figure 4 The computer-readable storage medium 40 stores a computer program 41, which, when executed by a processor, implements the steps of the communication method as described in any of the above embodiments. The computer-readable storage medium 40 referred to herein includes RAM (Random Access Memory), main memory, ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable Read Only Memory), registers, hard disks, removable disks, or any other form of storage medium known in the art.

[0139] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0140] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0141] This article uses specific examples to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the technical solutions and core ideas of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made to the present invention without departing from the principles of the present invention, and these improvements and modifications also fall within the protection scope of the present invention.

Claims

1. A communication method, characterized in that, The communication controller used in the host includes: When an interrupt request generated by a slave device is detected, the slave address parsed from the interrupt request is used as an index to the interrupt control table, and the response information is read from the interrupt control table; wherein, the interrupt control table includes the response information corresponding to each of the slave addresses; When the response information indicates that a response is needed to the slave device and data needs to be read from the slave device, the host program queries whether the slave device address exists in the first device address table; wherein, the first device address table and the second device address table together constitute the device information of all slave devices, the second device address table and the interrupt control table are both stored in the host hardware managed by the communication controller, and the first device address table is stored in memory; If so, the host program selects the entry to be exchanged from the second device address table, exchanges the entry in the first device address table that carries the slave address with the entry to be exchanged, and receives the communication information sent by the host program after the exchange. If not, then receive the communication information sent by the host program; Based on the communication information, read the device information with the slave address from the second device address table; The device communicates with the slave device based on the device information and reads data from the slave device.

2. The communication method according to claim 1, characterized in that, When the response information indicates a need to respond to the slave device and read data from the slave device, the host program queries whether the slave device address exists in the first device address table, including: Determine whether the interrupt response field of the response information belongs to the interrupt response field that indicates a need to respond to the slave device; If it belongs to an interrupt response field that indicates a need to respond to the slave device, then determine whether the interrupt payload field of the response information belongs to an interrupt payload field that indicates a need to read data from the slave device; If it belongs to the interrupt load field indicating that data needs to be read from the slave device, the host program queries whether the slave device address exists in the first device address table.

3. The communication method according to claim 1, characterized in that, The host program queries whether the slave address exists in the first device address table, including: The host program traverses each entry of the first device address table to determine whether the slave address exists in the first device address table, or the host program traverses each entry of the second device address table to determine whether the slave address exists in the first device address table.

4. The communication method according to claim 1, characterized in that, The host program selects the entry to be exchanged from the second device address table, including: The host program selects an entry to be exchanged from the second device address table by randomly selecting an entry.

5. The communication method according to claim 1, characterized in that, The host program selects the entry to be exchanged from the second device address table, including: The host program selects entries to be exchanged from the second device address table, and the slave addresses in the entries to be exchanged are slave addresses whose access popularity is below a threshold in the most recent first time period.

6. The communication method according to claim 1, characterized in that, Also includes: Determine whether the selected entry to be exchanged is an entry carrying a prohibited exchange flag; If so, the host program will reselect the entry to be exchanged from the second device address table.

7. The communication method according to claim 1, characterized in that, Receiving communication information sent by the host program, including: Receive communication information sent by the host program, which carries communication commands, communication data, communication timing, and a second device address table index.

8. The communication method according to claim 7, characterized in that, Based on the communication information, the device information having the slave address is read from the second device address table, including: Based on the second device address table index in the communication information, read the device information with the slave address from the second device address table; The device information read includes at least the slave address and the device type.

9. The communication method according to claim 8, characterized in that, The device types include two-wire serial communication devices and improved two-wire serial communication devices; the communication controller is an improved two-wire serial communication controller.

10. The communication method according to claim 1, characterized in that, Communicating with the slave device based on the device information and reading data from the slave device includes: A data packet is constructed based on the communication information and the device information; According to the communication sequence, the data packet is sent to the slave device to communicate with the slave device and to read data from the slave device.

11. The communication method according to claim 1, characterized in that, Also includes: When a communication anomaly is detected with the slave device, preset communication anomaly handling measures are executed.

12. The communication method according to any one of claims 1 to 11, characterized in that, Also includes: When the host initiates communication with the slave device, the host program queries whether the slave device's address exists in the first device address table. If so, the host program selects the entry to be exchanged from the second device address table, exchanges the entry in the first device address table that carries the slave address with the entry to be exchanged, and receives the communication information sent by the host program after the exchange. If not, then receive the communication information sent by the host program; Based on the communication information, read the device information with the slave address from the second device address table; Based on the device information, the device communicates with the slave device to read or write data to the slave device.

13. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the communication method as described in any one of claims 1 to 12.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the communication method as described in any one of claims 1 to 12.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the communication method as described in any one of claims 1 to 12.

Images