Activities in I2C status, software problems introduced by hardware interruptions

Wait until the I2C bus is idle.Code

Void wait (INT i2cnum)
{
2010tmp;

TMP = read_reg (i2c_raw_intr_star_ch (i2cnum); // try to combine the two
While (! (TMP & 0x200 ))
{
TMP = read_reg (i2c_raw_intr_star_ch (i2cnum ));
}

// Printk ("i2c_txflr: % d \ n", read_reg (i2c_txflr_ch (i2cnum )));
TMP = read_reg (i2c_status_ch (i2cnum ));
// Printk ("i2c_status: 0x % x \ n", TMP );
While (TMP & 0x01) = 0x1) // maybe after the I2C clock line stops working, that is, after the stop condition is generated, i2C is still working internally and needs to be completed internally
{
TMP = read_reg (i2c_status_ch (i2cnum ));
// Printk ("i2c_status: 0x % x \ n", TMP );
}
// Printk ("i2c_txflr: % d \ n", read_reg (i2c_txflr_ch (i2cnum )));
// Printk ("i2c_status: 0x % x \ n wait over \ n", TMP );
// This problem may occur during the operation. After the CPU operates on the I2C module, the I2C should theoretically respond, but the result is before the CPU sends the Second instruction to I2C, the internal working speed of I2C differs greatly from that of the CPU, which causes a problem.
// The latency that can be considered when the CPU performs two consecutive operations on a module is the same as the following interruption.
// Mdelay (10 );

/*
TMP = read_reg (i2c_raw_intr_star_ch (i2cnum);
while (! (TMP & 0x200)
{< BR style = "line-Height: normal; "> TMP = read_reg (i2c_raw_intr_star_ch (i2cnum);
}< BR style =" line-Height: normal; "> // read_reg (i2c_clr_stop_det_ch (i2cnum);
*/

}

If only the read operation causes the interruption of the Stop condition, the first time data is written to i2c_data_cmd, there is a certain probability that the status bit of I2C will not change at all (this probability is not detected, the latency of the printk may be due to a loop. However, when reading and writing a single byte, only the status bit does indeed cause the overflow of the sending cache, which means that the waiting loop is skipped ), therefore, there is an overflow problem in the subsequent word interpretation. In addition, when only the interrupt is used to implement the wait function, when reading the data, the first data is actually a random number, followed by the real data, which indicates that after the interruption, the I2C state machine does not stop working. It takes time to write internal work to accept FIFO.

In fact, all the above data can be easily solved as long as the imitation code is completed before reading it. Unfortunately, I cannot get it. Another problem is that if there is no data in the first-in-first-out (FIFO) reception, what is read by the read operation? 0, 1, or a random number, or the setting of the preceding imitation code, I will try the I2S module next time.