Communication method, controller and communication system

Abstract

The application relates to a communication method, a controller and a communication system, and relates to the technical field of communication, wherein the method comprises the following steps: sending a preset number of SCL pulses to a slave device through an SCL, and acquiring the level state of an SDA; in response to the SDA being low, sending a stop signal to the slave device through the SCL and the SDA; in response to the SDA being high, sending an SCL pulse to the slave device through the SCL, starting to record the number of SCL pulses, and when a preset condition is met, stopping sending the SCL pulse and sending a stop signal to the slave device through the SCL and the SDA, the stop signal can release the deadlock state of I2C communication and restore the slave device to an idle state to avoid the slave device from sending a start communication exception; the preset condition comprises that the recorded number of SCL pulses is not greater than the number of pulses required for one data frame and the SDA is low, or the recorded number of SCL pulses is greater than the number of pulses required for one data frame.

Description

Technical Field

[0001] This disclosure relates to the field of communication technology, and more particularly to a communication method, controller, and communication system. Background Technology

[0002] The I2C (Inter-Integrated Circuit Bus) bus is a multi-master, two-wire, low-speed serial communication bus that enables bidirectional transmission between master and slave devices through a serial data line (SDA) and a serial clock line (SCL). It is widely used for communication between microcontrollers and various peripheral devices.

[0003] In practical applications, when communication between the master and slave devices is out of sync, I2C communication can enter an abnormal state due to misalignment between the master and slave devices (e.g., state machine corruption or data corruption in the slave device), or even a deadlock state, where I2C communication is in a stopped state that cannot be automatically recovered from. Related technologies, when using software methods to resolve I2C communication deadlocks, are only effective for deadlocks under certain specific circumstances and cannot prevent communication anomalies in the slave device. Summary of the Invention

[0004] This disclosure provides a communication method, controller, and communication system.

[0005] In a first aspect, embodiments of this disclosure provide a communication method applied to a master device in an I2C communication system. The master device is connected to at least one slave device via an I2C bus. The method includes: sending a preset number of SCL pulses to the slave device via the serial clock line SCL of the I2C bus, and acquiring the level state of the serial data line SDA of the I2C bus; the preset number is not less than the number of pulses required for one I2C communication; in response to SDA being low, sending a stop signal to the slave device via SCL and SDA; in response to SDA being high, sending SCL pulses to the slave device via SCL, and starting to record the number of SCL pulses until a preset condition is met, then stopping the sending of SCL pulses and sending a stop signal to the slave device via SCL and SDA; the preset condition includes: the number of recorded SCL pulses is not greater than the number of pulses required to send a data frame and SDA is low; or, the number of recorded SCL pulses is greater than the number of pulses required to send a data frame; wherein, the stop signal can release the deadlock state of the I2C communication and restore the slave device to an idle state to avoid communication abnormalities occurring in the slave device.

[0006] Secondly, this disclosure provides an I2C controller, which is a master device in an I2C communication system. The I2C controller is configured to connect to an I2C bus and execute the communication method described in the above embodiments.

[0007] Thirdly, embodiments of this disclosure provide a communication system, including: at least one slave device, at least one master device, and an I2C bus connecting the slave device and the master device, wherein the master device includes the I2C controller in the above embodiments.

[0008] The communication method of this disclosure can resolve various deadlock situations in I2C communication through signal control without introducing additional hardware modules, thus solving the problem that the prior art can only resolve deadlocks under specific conditions. Furthermore, by stopping the signal to restore the device to an idle state, communication abnormalities of the slave device can be avoided, which helps to improve the reliability of I2C communication.

[0009] Other features and advantages of this disclosure will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the disclosure. Other advantages of this disclosure may be realized and obtained by means of the methods described in the description and the accompanying drawings. Attached Figure Description

[0010] The accompanying drawings are used to provide an understanding of the technical solutions disclosed herein and form part of the specification. They are used together with the embodiments of the present disclosure to explain the technical solutions of the present disclosure and do not constitute a limitation on the technical solutions of the present disclosure.

[0011] Figure 1 This is a flowchart illustrating an embodiment of the communication method disclosed herein; Figure 2 This is a flowchart illustrating yet another embodiment of the communication method disclosed herein; Figure 3 This is a timing diagram of the master device reading data phase in one embodiment of the communication method of this disclosure; Figure 4 A timing diagram of the master device writing data phase in one embodiment of the communication method of this disclosure; Figure 5 This is a flowchart illustrating yet another embodiment of the communication method disclosed herein; Figure 6 This is a schematic diagram of the structure of one embodiment of the communication system disclosed herein. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this disclosure clearer, the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be arbitrarily combined with each other.

[0013] The embodiments disclosed herein are not necessarily limited to the dimensions shown in the drawings, and the shapes and sizes of the components in the drawings do not reflect actual proportions. Furthermore, the drawings schematically illustrate ideal examples, and the embodiments of this disclosure are not limited to the shapes or values ​​shown in the drawings.

[0014] The ordinal numbers such as "first" and "second" in this disclosure are used to avoid confusion among the constituent elements and do not indicate any order, quantity, or importance.

[0015] In this disclosure, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linkage" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; a mechanical connection or an electrical connection; a direct connection, an indirect connection via an intermediate component, or a connection within two components. Those skilled in the art can understand the specific meaning of these terms in this disclosure according to the specific circumstances.

[0016] In related technologies, when using software methods to resolve deadlocks in I2C communication, the following steps are typically included: The master device in the I2C system sends an SCL pulse via the serial clock line SCL and then reads the level of the serial data line SDA. If the SDA level is low, the timer count is incremented by 1, and then SCL pulses are sent again while the SDA level is read. If SDA remains low, the timer records the number of SCL pulses. When the number of SCL pulses exceeds 10, it indicates that deadlock recovery has failed. If SDA is high before the number of SCL pulses exceeds 10, the master device sends a stop signal via SDA to resolve the deadlock.

[0017] In the above method, when the number of SCL pulses is greater than 10, the deadlock recovery is considered to have failed. It can be seen that this method cannot cover all deadlock situations. For example, in the following situations: When the master device is reading data and is reset while the slave device outputs a high level, SDA is high. This method would send a stop signal at this point, but since the slave device is still in the output state, it cannot receive the stop signal, thus failing to unlock. When the master device is reading data and is reset after writing the slave device address, the slave device is waiting for the master device's acknowledgement (ACK) signal. Even if the master device sends 10 SCL pulses, the slave device cannot receive the stop signal, thus failing to unlock. When the master device is reading the slave device's register and is reset after writing the slave device address, the slave device is waiting for the master device's acknowledgement signal. Even if the master device sends 10 SCL pulses, the slave device cannot receive the stop signal, thus failing to unlock. When the master device is writing data to the slave device and is reset, SDA is controlled by the master device. If the master device's SDA pin is pulled up, the SDA read by the master device is high. The above method would send a stop signal at this point, but since the slave device is still waiting for the master device to write data, it cannot receive the stop signal, thus failing to unlock.

[0018] In addition, after the master device is reset in I2C communication, it will resend the start signal. At this time, if the master device can pull SDA to a low level (for example, the slave device is in the receiving state or is outputting a high level), the slave device will think that a bus error has occurred (i.e., SDA changes when SCL is high). This situation may cause communication abnormalities such as state machine confusion and data corruption in the slave device.

[0019] To address the aforementioned problems, this disclosure provides a communication method applied to a master device in an I2C communication system, wherein the master device is connected to at least one slave device via an I2C bus. For example... Figure 1 As shown, the method may include the following steps.

[0020] Step 110: Send a preset number of SCL pulses to the slave device through the serial clock line SCL of the I2C bus, and obtain the level status of the serial data line SDA of the I2C bus.

[0021] The preset number is no less than the number of pulses required for one I2C communication.

[0022] In this embodiment, the master device may be equipped with an I2C controller. The SCL and SDA pins of the I2C controller are connected to the SCL and SDA pins of the I2C bus, respectively, allowing the master device to communicate with the slave device via the I2C bus. The master device can send a preset number of SCL pulses (also known as clock pulses) to the SCL pin, which are then transmitted to the slave device via the SCL pin. The master device can obtain the SDA level status via the SDA pin.

[0023] According to the I2C protocol, each frame in I2C communication is 9 bits (i.e., corresponding to 9 SCL pulses). A complete I2C communication usually includes an address frame, a device sub-address frame, and a data frame. Therefore, the preset number can be no less than the sum of the SCL pulses corresponding to the address frame, device sub-address frame, and data frame.

[0024] In some implementations of this embodiment, the preset quantity can be determined based on the number of bits in the slave device's address. For example, if the slave device's address is 7 bits, the preset quantity can be 27; if the slave device's address is 10 bits, the preset quantity can be 36.

[0025] In other embodiments of this example, the preset number is at least greater than the sum of the address frames, device sub-address frames, and data frames in I2C communication, or the preset number is at least greater than the sum of the address frames and data frames in I2C communication; wherein, the number of address frames is From the device's address bits / I2C communication one frame of bits .

[0026] In this embodiment, the master device sends a preset number of SCL pulses to the slave device to ensure that when the master device reads data during the last communication, the slave device can complete data transmission and NAK acknowledgment signal (Not Acknowledge, NAK) after receiving the preset number of SCL pulses, and thus be in a state of waiting for the master device to send a stop signal.

[0027] Step 120: In response to SDA being low, a stop signal is sent to the slave device via SCL and SDA.

[0028] In this embodiment, the stop signal can release the deadlock state of I2C communication and restore the slave device to an idle state to avoid communication abnormalities in the slave device.

[0029] As an example, the master device can generate a stop signal by pulling the SDA pin high during the SCL high level, and then send it to the slave device.

[0030] According to the I2C protocol, during the communication phase where the master device writes and the slave device reads, after the master device sends each byte of data (i.e., one data frame), the slave device can reply with an ACK signal (i.e., a low SDA level) to indicate that it has received the data and can continue sending. At this point, the master device can either send the next data frame or signal a stop to end the current communication.

[0031] In this embodiment, after the master device sends a preset number of SCL pulses, if SDA is low, it indicates that the slave device is in a state of waiting to receive signals. If the I2C communication was previously deadlocked, the master device can release the deadlock by sending a stop signal. Simultaneously, the stop signal can restore the slave device to an idle state, thereby preventing communication anomalies such as state machine confusion or data corruption caused by misalignment between the master and slave devices. If the I2C communication was previously normal, steps 110 and 120 will not affect the I2C communication state.

[0032] Step 130: In response to SDA being high, send an SCL pulse to the slave device via SCL and start recording the number of SCL pulses until a preset condition is met. Then, stop sending SCL pulses and send a stop signal to the slave device via SCL and SDA.

[0033] The preset conditions include: the number of recorded SCL pulses is not greater than the number of pulses required to send a data frame and SDA is low; or, the number of recorded SCL pulses is greater than the number of pulses required to send a data frame.

[0034] In this embodiment, after the master device sends a preset number of SCL pulses, if SDA is high, it indicates that the last communication involved the master device reading and the slave device writing, and the slave device is currently in the data transmission phase of the last communication. In step 130, the master device sends SCL pulses to allow the slave device to continue sending data. When the slave device finishes sending data, it sends an ACK or NAK signal (i.e., SDA high) to complete the last communication and enter a waiting state. Here, a preset condition can be used to determine whether the slave device has completed the last communication and entered a waiting state.

[0035] As an example, the number of pulses required to send a data frame can be 9. In step 110, after the master device sends a preset number of SCL pulses to the slave device, if SDA remains high, it indicates that the previous I2C communication involved the master device reading and the slave device writing. In this case, the slave device needs a maximum of 9 SCL pulses to complete the data transmission process of the previous communication. In step 130, the master device sends SCL pulses again and reads the SDA level. If SDA is high, the count is incremented. Before completing the transmission of 9 SCL pulses, if SDA becomes low, it indicates that the slave device has completed the data transmission of the previous communication and sent an ACK signal. At this time, the slave device is in a waiting state, and the master device can end the communication by sending a stop signal. If, after the master device sends 9 SCL pulses again, SDA does not become low, it indicates that the slave device has completed the data transmission of the previous communication and sent an ACK signal. At this time, the slave device is in a waiting state, and the master device can end the communication by sending a stop signal.

[0036] Here, if the I2C communication was previously in a deadlock state, after step 130, the slave device receives the stop signal sent by the master device and can enter the idle state. On the one hand, this can end the previous communication and restore the communication to the normal state, thereby releasing the deadlock state; on the other hand, it can avoid communication abnormalities caused by misalignment between the master device and the slave device.

[0037] In this embodiment, the master device sends the required number of SCL pulses to the slave device to complete one I2C communication before determining the SDA level. This ensures the slave device completes the current data transmission and avoids misinterpreting a low-level data output from the slave device as an ACK signal. This solves the problem in existing technologies where determining the SDA level after only one pulse is sent, leading to partial unlocking failures. Furthermore, this embodiment does not directly send a stop signal when detecting a high SDA level. Instead, it continues sending SCL pulses until the number of pulses sent exceeds one frame of data, and the SDA remains high before sending a stop signal. This further solves the unlocking failure problem caused by sending a stop signal immediately upon a high SDA level in existing technologies.

[0038] exist Figure 1 In the embodiment shown, deadlocks in I2C communication can be resolved by signal control, and all deadlock situations in existing I2C communication can be covered without introducing additional hardware modules. Furthermore, by stopping the signal, the device can be restored to an idle state, which can also prevent communication abnormalities from occurring on the device and help improve the reliability of I2C communication.

[0039] The following is for reference. Figure 2 , Figure 2 A flowchart illustrating yet another embodiment of the communication method of this disclosure is shown, as follows: Figure 2 As shown, the process may include the following steps.

[0040] Step 210: Determine whether the main device is in the preset state.

[0041] The preset state indicates that the I2C communication is in a deadlock state or that there is a risk of communication abnormality in the slave device.

[0042] As an example, communication anomalies in slave devices can be caused by state machine corruption or data corruption. The master device can determine whether I2C communication is in a deadlock state or whether there is a risk of state machine corruption or data corruption in the slave device by monitoring the states of the SCL and SDA pins in the I2C controller. For example, if the last communication was not completed, and the master device resets or is unable to pull the SDA level high after a reset, it indicates that I2C communication is in a deadlock state or that there is a risk of communication anomalies in the slave device, thus determining that the master device is in a preset state.

[0043] Step 220: When the master device is in the preset state, configure the SCL pin of the master device to GPIO output mode so as to send SCL pulse to SCL.

[0044] In this embodiment, the master device configures the SCL pin to GPIO mode, and can control the level of the SCL pin through the GPIO controller and output high and low levels to simulate the SCL pulse.

[0045] Step 230: Configure the SDA pin of the master device to GPIO input mode in order to obtain the level state of SDA.

[0046] In this embodiment, the master device configures the SDA pin to GPIO input mode (i.e., input pull-up) in order to read the state of SDA and use it to determine the state of the slave device.

[0047] Step 240: Send a preset number of SCL pulses to the slave device through the serial clock line SCL of the I2C bus, and obtain the level status of the serial data line SDA of the I2C bus.

[0048] In this embodiment, steps 240 to 260 correspond to steps 110 to 130 as described above, and will not be repeated here.

[0049] Step 250: In response to SDA being low, a stop signal is sent to the slave device via SCL and SDA.

[0050] Step 260: In response to SDA being high, send an SCL pulse to the slave device via SCL and start recording the number of SCL pulses until a preset condition is met. Then, stop sending SCL pulses and send a stop signal to the slave device via SCL and SDA.

[0051] exist Figure 2In the embodiment shown, after the master device is reset, the SCL pin and SDA pin of the master device can be configured to GPIO mode to send SCL pulses and read the level of SDA, so as to release the deadlock state of I2C communication and avoid communication abnormalities such as state machine chaos and data corruption in the slave device, which helps to improve the reliability of I2C communication.

[0052] In some implementations of this embodiment, the preset state may include at least one of the following: the master device is in an abnormal waiting state, or the master device is unable to pull up the SDA level, wherein the abnormal waiting state indicates that the master device has been in a waiting state for a longer than a preset duration.

[0053] Accordingly, step 210 above can determine whether the master device is in a preset state in the following way: if the master device is in an abnormal waiting state or cannot pull the SDA level low, it is determined that the master device is in a preset state.

[0054] Typically, I2C communication deadlock is caused by a lack of synchronization between the master and slave devices. In this state, the master device will remain in a waiting state (e.g., waiting for the slave device to release SDA). Therefore, the deadlock status of I2C can be determined by monitoring the master device's waiting time. The preset duration can be set based on experience or actual needs, for example, it can be multiple SCL clock cycles.

[0055] In some examples of this implementation, the master device can be determined to be in an abnormal state when any of the following conditions are met: Figure 3 and Figure 4 Examples are provided to illustrate various scenarios of abnormal waiting states. Figure 3 This is a timing diagram for reading data from the master device in I2C communication. Figure 4 This is a timing diagram for the master device writing data in I2C communication. Figure 3 and Figure 4 This illustrates the different scenarios that occur at each stage of I2C communication.

[0056] like Figure 3 As shown, during the data reading phase of the master device, the following situations may cause the master device to be in an abnormal waiting state, namely, the I2C is in a deadlock state or there is a risk of communication abnormality in the slave device.

[0057] In the first scenario, the master device is reading data (such as...) Figure 3When SDA is reset (for data transmission), if the slave device is in the data transmission phase after the reset (SDA is low), it will occupy SDA, causing SDA to go low. The master device can only wait for the slave device to release SDA, resulting in a deadlock in I2C communication. Conversely, if SDA goes high after the reset, the change in SDA will cause the master device to send a start signal, which will lead the slave device to interpret as a bus error. This may result in communication abnormalities such as state machine chaos or data corruption in the slave device.

[0058] In the second scenario, the master device is reset when it sends an acknowledgment signal after completing data reading. In this case, the slave device will wait indefinitely for the master device to send an ACK (e.g., ...). Figure 3 A) or NAK (e.g.) Figure 3 In This signal can cause communication anomalies such as state machine confusion or data corruption in the slave device during the next I2C communication.

[0059] In the third scenario, the master device is reset when it sends a stop signal after reading data (e.g., Figure 3 (P in the original text). In this situation, the slave device will wait indefinitely for the master device to send a stop signal, which may cause an I2C communication deadlock or communication anomalies such as state machine chaos or data corruption in the slave device in the next I2C communication.

[0060] In the fourth scenario, the master device is reset after sending the write address. In this case, the master device writes the address and reads data. After the master device correctly writes the address and is reset, it will wait indefinitely for the slave device to reply with an ACK, while the slave device will wait indefinitely for the ACK and data to be sent, causing the I2C to enter a deadlock state.

[0061] In the fifth scenario, the master device is reset during the write address transmission process and sends an SCL pulse after the reset. In this case, the master device writes the address and reads data. The master device being reset during the address write process while the address is valid can cause the I2C to enter a deadlock state.

[0062] In the sixth scenario, when the master device reads the value from the slave device's register, the master device sends the device address (e.g., ...). Figure 3 SLAVEADDR and write flag (i.e., write bit, such as SLAVEADDR) and write flag (i.e., write bit, such as SLAVEADDR) and write flag (i.e., write bit, such as SLAVEADDR) and write flag (i.e., write flag ... Figure 3 In If the master device is reset after not receiving an ACK signal from the slave device, the master device will send its device address and write flag and wait for an ACK from the slave device. The master device's reset at this point will cause the I2C to enter a deadlock state.

[0063] In the seventh scenario, when the master device reads the value of a register in the slave device, the master device is reset when sending the device address and write flag, and the device address is a valid address.

[0064] pass Figure 3 As can be seen, the above seven scenarios cover all stages when the master device reads data. This allows us to determine whether the master device is in an abnormal waiting state at different stages when reading data, and thus determine whether the I2C communication is in a deadlock state or whether there is a risk of communication abnormality in the slave device.

[0065] like Figure 4 As shown, during the master device's data writing phase, the following situations can cause the master device to be in an abnormal waiting state, i.e., the I2C is in a deadlock state or there is a risk of deadlock.

[0066] In the eighth scenario, when the master device writes data to the slave device, the master device sends the device address (e.g., ...). Figure 4 SLAVEADDR) and write flag (e.g. Figure 4 In When the device is reset and the device address is a valid address.

[0067] In the ninth scenario, the master device is reset during the data writing process while writing data to the slave device. In this case, the slave device is in a state of waiting for the master device to write data. The enable signal sent by the master device in the next I2C communication may cause an I2C communication deadlock or communication anomalies such as state machine confusion or data corruption in the slave device.

[0068] In the tenth scenario, when the master device writes data to the slave device, the master device is reset while waiting for an acknowledgment signal from the slave device. In this case, the slave device will be in a state of waiting to send an ACK (e.g., ...). Figure 4 The state of A) in the diagram causes I2C communication to enter a deadlock state.

[0069] In the 11th scenario, the master device is reset when it sends a stop signal after writing data (e.g., ...). Figure 4 (P in the original text). In this situation, the slave device will wait for the master device to send a stop signal. The start signal sent by the master device in the next I2C communication may cause I2C communication deadlock or communication abnormalities such as state machine chaos and data corruption in the slave device.

[0070] from Figure 4 As can be seen, the above four scenarios cover all stages of the master device writing data. This allows us to determine whether the master device is in an abnormal waiting state at different stages of writing data, and thus determine whether the I2C communication is in a deadlock state or whether there is a risk of communication abnormality in the slave device.

[0071] The following is combined with Figure 1The steps described in this disclosure illustrate that the communication method in this embodiment can cover all deadlock situations in the prior art I2C communication. For the first and second situations, since SDA is high, the slave device will receive a NAK (such as...) sent by the master device. Figure 3 In In the first scenario, if the slave device receives the NAK signal from the master device, and then sends a stop signal to the slave device after step 120, the slave device can return to an idle state, preventing it from entering a communication abnormal state. In the second scenario, if the slave device has already received the NAK signal from the master device, and then sends a stop signal to the slave device after step 120, the slave device can return to an idle state, preventing it from entering a communication abnormal state. In the third scenario, if the slave device has already received the NAK signal from the master device, and then sends a stop signal to the slave device after step 120, the deadlock state can be released. In the fourth scenario, if the slave device replies with an ACK signal and outputs data after step 110, and receives the NAK signal from the master device, and then sends a stop signal to the slave device after step 120, the deadlock state can be released. In the fifth scenario, if the address is valid, when the master device sends the SCL pulse in step 110, the slave device can output data, and after the output is complete, it receives the NAK signal from the master device. Then, after step 120, the master device sends a stop signal to the slave device, which can restore the slave device to an idle state, preventing it from entering a communication abnormal state.

[0072] In the sixth scenario, after step 110, when the master device sends an SCL pulse, the slave device will reply with an ACK signal. Since the read / write flag is set to write, when the master device continues to send SCL pulses, the slave device will assume that the master device is writing data, and since the master device's SDA pin is high, the slave device will receive 0xff data. If the device address is valid, the read / write flag is 1 (i.e., a read operation), and the slave device assumes that the master device is reading register data. When the master device continues to send SCL pulses, the slave device will output data and receive a NAK signal from the master device after the output is complete. After step 120, the deadlock can be resolved by the master device sending a stop signal. If the device address is invalid, the slave device returns a NAK signal, and after step 120, the deadlock can be resolved by the master device sending a stop signal.

[0073] For cases 7 and 8, when the master device sends the SCL pulse, SDA is high. If the address is valid, the slave device receives a read operation. When the master device continues to send the SCL pulse, the slave device can output data and receive the NAK signal sent by the master device after the output is completed. After step 120, the master device sends a stop signal to restore the slave device to the idle state, thus preventing the slave device from entering the communication state.

[0074] For scenarios 9 and 10, after step 110, the slave device remains in a state of waiting to write or reply with an ACK signal. After step 130, when the master device continues to send SCL pulses, two possibilities exist: one is that the slave device finishes sending data and replies with an ACK signal, the master device detects the low level of SDA, can stop sending SCL pulses and send a stop signal, thus resolving the deadlock; the other possibility is that the slave device finishes sending data and waits to send an ACK signal. In this case, the master device sends an SCL pulse, allowing the slave device to reply with an ACK signal, and the master device then sends a stop signal to resolve the deadlock.

[0075] In this embodiment, the master device sends the required number of SCL pulses to the slave device to complete one I2C communication session before determining the SDA level. This ensures the slave device completes the current data transmission and avoids misinterpreting a low-level data output from the slave device as an ACK signal. This solves the problem in existing technologies where only one pulse is sent to determine the SDA level, leading to partial unlocking failures. Furthermore, this embodiment does not directly send a stop signal when detecting a high SDA level. Instead, it continues sending SCL pulses until the number of pulses sent exceeds one frame of data, and the SDA remains high before sending a stop signal. This further solves the unlocking failure problem caused by sending a stop signal immediately upon a high SDA level in existing technologies. The various scenarios in this example cover all stages of I2C communication for the master device. Based on these scenarios, it can be determined whether the master device is in an abnormal waiting state at each stage of I2C communication, thereby determining whether the I2C communication is in a deadlock state or at risk of deadlock. Subsequent steps can then resolve the deadlock. Thus, the communication method in this embodiment can cover all deadlock scenarios in existing I2C communication, thereby improving the reliability of I2C communication.

[0076] The following is for reference. Figure 5 , Figure 5 A flowchart illustrating yet another embodiment of the communication method of this disclosure is shown, as follows: Figure 5 As shown, the process may include the following steps.

[0077] Step 510: In the event of a reset or power-on of the main device, determine that the main device is in a preset state.

[0078] Typically, deadlock in I2C communication is caused by a reset or power-on of the master device. Here, when the master device is reset or powered on, it is determined that the master device is in a preset state, which means that there is at least a risk of deadlock in I2C communication or a risk of communication abnormality in the slave device. This is so that the risk of deadlock or communication abnormality in the slave device can be avoided through subsequent steps.

[0079] Step 520: When the master device is in the preset state, configure the SCL pin of the master device to GPIO output mode so as to send SCL pulse to SCL.

[0080] In this embodiment, steps 520 to 560 correspond to steps 220 to 260 described above, and will not be repeated here.

[0081] Step 530: Configure the SDA pin of the master device to GPIO input mode in order to obtain the level state of SDA.

[0082] Step 540: Send a preset number of SCL pulses to the slave device through the serial clock line SCL of the I2C bus, and obtain the level status of the serial data line SDA of the I2C bus.

[0083] Step 550: In response to SDA being low, a stop signal is sent to the slave device via SCL and SDA.

[0084] Step 560: In response to SDA being high, send an SCL pulse to the slave device via SCL and start recording the number of SCL pulses until a preset condition is met. Then, stop sending SCL pulses and send a stop signal to the slave device via SCL and SDA.

[0085] Step 570: Initialize I2C communication.

[0086] As an example, initialization may include operations such as initializing the master device, resetting the slave device, and configuring the slave device.

[0087] In this embodiment, since steps 520 to 570 have no impact on normal I2C communication, there is no need to determine whether I2C communication is in a deadlock or abnormal waiting state. When the master device is reset or powered on again at any time, the deadlock state can be released through steps 520 to 570, or the risk of deadlock and communication abnormality of the slave device can be avoided, which helps to further improve the reliability of I2C communication.

[0088] like Figure 6 As shown, this disclosure also provides an I2C controller, which is a master device in an I2C communication system. The I2C controller is configured to connect to an I2C bus and execute the communication method in any of the above embodiments.

[0089] like Figure 6 As shown in the embodiments of this disclosure, a communication system is also provided, including: at least one slave device, at least one master device, and an I2C bus connecting the slave device and the master device, wherein the master device includes the I2C controller in the above embodiments.

[0090] It will be understood by those skilled in the art that all or some of the steps, systems, or apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

Claims

1. A communication method applied to a master device in an I2C communication system, wherein the master device is connected to at least one slave device via an I2C bus, characterized in that, The method includes: A preset number of SCL pulses are sent to the slave device via the serial clock line SCL of the I2C bus, and the level state of the serial data line SDA of the I2C bus is obtained; wherein, the preset number is not less than the number of pulses required for one I2C communication. In response to SDA being low, a stop signal is sent to the slave device via SCL and SDA; In response to SDA being high, an SCL pulse is sent to the slave device via SCL, and the recording of the number of SCL pulses is started until a preset condition is met. Then, the sending of SCL pulses stops, and a stop signal is sent to the slave device via SCL and SDA. The preset condition includes: the number of recorded SCL pulses is not greater than the number of pulses required to send one data frame and SDA is low; or, the number of recorded SCL pulses is greater than the number of pulses required to send one data frame. The stop signal can release the deadlock state of I2C communication and restore the slave device to an idle state to avoid communication abnormalities in the slave device.

2. The method according to claim 1, characterized in that, Before sending a preset number of SCL pulses to the slave device via the serial clock line SCL of the I2C bus, the method further includes: When the master device is in the preset state, the SCL pin of the master device is configured to GPIO output mode so as to send an SCL pulse to SCL; and the SDA pin of the master device is configured to GPIO input mode so as to obtain the level state of SDA. The preset state indicates that the I2C communication is in a deadlock state or that the slave device is at risk of communication abnormality.

3. The method according to claim 2, characterized in that, The preset state includes at least one of the following: the master device is in an abnormal waiting state, and the master device is unable to pull the SDA level high; The abnormal waiting state indicates that the master device has been in a waiting state for a longer than a preset time.

4. The method according to claim 3, characterized in that, Also includes: The master device is determined to be in an abnormal waiting state if any of the following conditions are met: The master device is reset when reading data, and SDA is low after the reset; The master device is reset when it replies with an acknowledgment signal after reading the data; The master device is reset when it sends a stop signal after reading data; The master device is reset after sending the write address; The master device is reset during the write address transmission process and sends an SCL pulse after the reset; When the master device reads the value of the register in the slave device, it is reset if it does not receive an acknowledgment signal from the slave device after sending the device address and write flag. When the master device reads the value of the register in the slave device, the master device is reset when it sends the device address and write flag, and the device address is a valid address. When the master device writes data to the slave device, the master device is reset when sending the device address and write flag, and the device address is a valid address. When the master device writes data to the slave device, the master device is reset during the data writing process; When the master device writes data to the slave device, the master device is reset while waiting for the slave device's response signal; The master device is reset when it sends a stop signal after writing data.

5. The method according to claim 3, characterized in that, Determining whether the main device is in a preset state includes: In the event of a reset or power-on of the main device, the main device is determined to be in a preset state.

6. The method according to claim 5, characterized in that, After sending a stop signal to the slave device via SCL and SDA, the method further includes: Perform I2C communication initialization.

7. The method according to claim 1, characterized in that, The preset quantity is determined based on the number of bits in the slave device's address.

8. The method according to claim 1, characterized in that, The preset number is at least greater than the sum of address frames, device sub-address frames, and data frames in I2C communication, or the preset number is at least greater than the sum of address frames and data frames in I2C communication; wherein, the number of address frames is The number of address bits of the slave device / the number of bits per I2C communication frame .

9. An I2C controller, characterized in that, The I2C controller is a master device located in the I2C communication system, and the I2C controller is configured to: connect to the I2C bus, and execute the communication method according to any one of claims 1 to 8.

10. A communication system, characterized in that, include: At least one slave device, at least one master device, and an I2C bus connecting the slave device and the master device, wherein the master device includes the I2C controller of claim 9.

Images