關于I2C總線讀寫應答機制

ID:266429 · 發表于 2021-10-26 10:06

I2C總線中的應答機制，屬于該總線規格中的關鍵內容，本來并不復雜，也很容易理解，但問題在于現有的教材基本都是含糊不清，有的甚至會引起誤解。因此，有必要詳細說明。
先說明兩個I2C總線中很重要的規則：
１. 總線在正常工作期間，從器件對時鐘線無控制權，即從器件的時鐘端口輸出應始終保持在高電位，時鐘線的狀態，只能由主器件進行操作；至于數據線，則主器件與從器件都有權參與操作。
２. 總線正常工作時，時鐘線處于高電位期間，不允許改變數據線的狀態，即此時無論主器件還是從器件，都不能對其數據端口進行狀態改變，除非是起始和終止操作。
記住這兩個規則，很重要。
以下均通過ＡＴ２４Ｃ的驗證。

一、應答原理
I2C總線，有點像我們用的對講機，盡管可以雙向通訊，但雙方不能同時說話，于是，就必須設有應答機制，而且，這個應答機制，必須是雙方互動的，一方的話說完了，就要問對方收到沒有，對方如果收到了這個問話，還得要再回個話。

二、向從器件寫入時的應答機制
I2C與這種對講機的應答的具體方式還是有些不一樣的，規定是這樣：在主機向從機發送數據時，規定每次發送一字節后就進行應答，主機每發送一字節數據后就停一下等待從機的反應，從機在收到一字節后的反應就是將其自身的數據端輸出低電位，也就是向主機發出信號說自己剛收到一字節，并等待主機的回應；主機接下來的操作就是拉高自身的數據端口電位，再檢測端口電位是否為低，如果檢測到為低，則認為從機已經收到了一個字節，然后要告訴從機我知道了也就是給從機一個回應，回應的方法是將時鐘線操作一個完整的總線時鐘周期即先拉高再拉低；從器件在收到主器件的這個回應后，就將其自身數據端口的電位拉高即交出對數據線的控制權，這樣就完成了一次完整的應答。
以上的時序是不能弄錯的，比如主器件在發送完成一字節數據后，拉高數據線端以檢測從器件的應答信號的操作，按I2C總線的規則必須先將時鐘線拉低才能再改變數據線，而一字節從發送到完成應答，時鐘線的操作只能是９個總線周期，這９個總線周期中減除最后一個完整的應答總線時鐘周期，那這個拉低的時間只能是安排在第８個周期。
另外，我們可以做一個實驗，就是監測數據線的電位高低變化，從實驗結果來看，在寫數據時，如果發送的數據的第０位為１的話，在時鐘線第８個總線周期的高電位時，數據線的電位也為高電位；而接下來時鐘線電位一旦變低，則數據線的電位也同時變為低電平，也就是說，這時從器件將對其自身的數據端口輸出低電位，這個就是從器件在寫入數據時的應答信號，這個信號是在第８個總線時鐘周期的低電位時發出的，而非有些教材說的在第９個時鐘周期時發出。

三、從發送方與接收方的角度來說明
對于i2c總線來說，在數據傳輸時，無論是主器件還是從器件，無論是讀還是寫，接收方在收到一字節數據后，規定是在時鐘線處于低電位時，立即在其數據端輸出低電平，而發送方則立即在其數據端口輸出高電平，然后發送方對數據線的電位進行檢測，所以，我們在編寫程序時，對于讀和寫的應答，程序是不一樣的，寫入時，程序是將數據線拉高；讀取時，是將數據線拉低。如果你在讀取時仍編寫成拉高數據線的電位，那就沒法連續讀取數據了。
以上操作之后，時鐘線發出第９個周期來完成雙方的互動式應答并復位主從器件的數據端口輸出值，即接收方釋放對數據線的控制權，將這個控制權交還給發送方，以便發送方向數據線輸出數據。根據總線正常工作期間，時鐘線處于高電位時不得改變數據線狀態的規則，接收方只能在第９個周期的低電位期間向其自身的數據端口輸出高電位。

四、從接收方應答的必須動作的角度來說明
我們再換一個角度來作說明，數據接收器件的應答有兩個動作，一個是發出表示自己收到了一字節的信號，就是向其數據端口輸出低電平，第二個動作是釋放數據端口。這兩個動作的發生時間均需由主器件的時鐘線發出的信號來控制，其發生的時序只能分配在第８、第９這最后兩個時鐘周期中執行，具體是第一個動作在第８個時鐘周期時執行，第二個動作是在第９個時鐘周期時執行。按照總線正常工作期間，時鐘線處于高電位時不得改變數據線的狀態的原則，這兩個動作只能在時鐘線處于低電位時執行。
所以，讀數據操作時，從器件在發送完成一字節數據后，在第８個總線時鐘周期中時鐘線處于低電位時，會立即釋放數據線的控制權，然后等待主器件的繼續讀取或停止指令。

五、讀指令發出后的應答機制
按照讀取數據時，先在時鐘線低電位時期放數據，再拉高時鐘線進行讀取的規定，則我們可以知道，在主器件讀取第一個字節的操作中，一旦從器件收到一字節的讀取指令，從器件就會與主器件互動進行應答，這個應答自然是按寫狀態進行操作，然后在第９個總線時鐘周期的低電平時期，從器件就會把所要讀取的這一字節數據的第７位數據放在數據線上，然后主器件就會拉高時鐘線電位后進行讀取，然后拉低時鐘線以讓從器件放上第６位數據，依此順推。
讀數據時，第一個應答信號中各動作后的電位變化如下：
i2cstart();//再次啟動總線，開始讀
I2cSendByte(0xa1); //向從器件寫入讀指令，讀取某一存儲單元中為10010110的數據。此動作后，數據線為低
I2CSDA=1;delayms(１);//此動作后，數據線仍為低
I2CSCL=1;delayms(１);//此動作后，數據線仍為低
I2CSCL=0;delayms(１); //此動作后，數據線變為高，說明應答一完成，從器件即將第７位數據（為１）放在了數據線上
說明一下，以上試驗，是本人在數據端口和時鐘端口分別接了一個燈（串了限流電阻）進行觀察所得。

六、關于非應答信號的質疑
前面說過了，數據發送方在發送完成一字節后，會立即釋放對數據線的控制權，所以，有些教材中“當主器件接收數據時，在最后一個數據字節，必須發送一個非應答位，使受控器件釋放數據線，以便主器件產生一個停止信號來終止總線數據傳輸”的說法是有問題的，因為最后一個字節發出去之后，受控器件已經主動釋放了數據線。當然了，你也可以這樣做，并不影響程序的運行，但我們不能這樣理解。
我們知道，每一次的數據傳輸之后，從器件的存儲器單元地址指針值都會加１，這個從器件存儲單元地址值加１的時序時間，是在從器件發送或接收到一個完整的字節后就立即進行的，與有無應答操作無關，所以，讀取最后一個數據后，我們根本無需進行所謂的非應答操作，而是可以直接發出停止信號退出總線。關于這一點，你可以進行試驗，在直接退出后，緊跟著輸入一個讀指令進行讀一個從器件單元中的數據的操作，一是看看這個退出是否是正常退出，二是看看讀出的結果是上一次操作中的最后一個單元的數據還是下一個單元的數據。

七、中斷應答
對于從器件這個情況比較少見，但也不是不可能發生，而主器件則不奇怪。
主器件對于自身中斷的處理比較容易，沒什么特殊的。
從器件在收到一字節數據后，如果暫時不想繼續接收數據比如其要先處理中斷，則可以將其時鐘線置低電位以獲取對時鐘的控制權。因此，嚴格來說，主器件每向從器件發送完成一字節后，主器件都應該檢測時鐘線及數據線的電位，以判斷從器件的狀態并確定其下一步的動作。

ID:266429 · 發表于 2021-10-26 21:15

讀應答有以下四個動作：
i2csda=0;delayus(4);
i2cscl=1;delayus(4);
i2cscl=0;delayus(4);
i2csda=1;delayus(4);
最后一個動作是主器件釋放對數據線的控制權，千萬別忘了。

ID:262 · 發表于 2021-10-27 17:26

好資料，51黑有你更精彩!!!

ID:266429 · 發表于 2021-10-27 19:45

本篇有些內容，顯然與教材是相沖突的，反正，要么教材錯了，要么我錯了，到底誰對誰錯呢？希望大家吱個聲。

ID:123289 · 發表于 2021-10-28 10:40

總結的很優秀，值得對I2C通訊認識模糊的人認真讀一下。
給個

ID:401564 · 發表于 2021-10-28 11:26

二、向從器件寫入時的應答機制
這個就是在第9個時鐘周期的時候,輸出應答位的,說破天了也是第9個
24Cxx是上升沿寫入的,在寫入完8個位的數據之后,SCL是低電平
然后把CSL拉高,這就是一個上升沿,就是第9個時鐘周期,如果再把時鐘拉低,那就是時鐘周期已經完成,從機就不再響應了

至于釋放數據線主要權什么,SDA=1;之類的,這僅僅只是8051端口的操作而已
有的別的單片機不是這樣操作,不存在把數據線拉高的說話
先學會看時序圖,配合時序看別人的代碼,這就行了,IIC很簡單

ID:123289 · 發表于 2021-10-28 15:00

【七、中斷應答】這一點能考慮到的人不多。
在I2C通訊過程序中，無論是哪一方，發生了中斷，中斷服務返回后（可能執行了一段時間），如何確保雙方的通訊接續上去而不受影響。是需要事先做預案的。

ID:266429 · 發表于 2021-10-29 11:49

Y_G_G 發表于 2021-10-28 11:26
二、向從器件寫入時的應答機制
這個就是在第9個時鐘周期的時候,輸出應答位的,說破天了也是第9個
24Cxx是 ...

第９個周期是發送器件的回應周期，目的是通知接收器件釋放對數據線的控制權；第８個周期才是接收器件的回應周期，告訴對方我收到一個字節了。
我都是站在這個總線協議設計者的角度來思考驗證的。很疑惑教材的說法，反正我在讀應答編程時，如果與寫應答的程序相同的話，在ＡＴ２４Ｃ上是沒法連續讀數據的。

ID:401564 · 發表于 2021-10-29 14:01

慢慢思考發表于 2021-10-29 11:49
第９個周期是發送器件的回應周期，目的是通知接收器件釋放對數據線的控制權；第８個周期才是接收器件的回 ...

你數一下是不是第9個

寫入的時候一樣的是第九個時鐘教材是有人審核的,不可能幾乎所有的教材都是錯的
隨便找個時序圖來看,它也是第9個
是最后一個字節發送完之后,時鐘是低電平,然后,時鐘線拉高,之后是等待SDA低電平
24Cxx是上升沿寫入,所以,這已經是第9個時鐘了,你隨便找一個IIC的寫函數看一下是不是這樣的

for(i = 0;i < 8;i++)
// {
// if(dat & 0x80) IIC_SDA = 1; //判斷發送位，先發送高位
// else IIC_SDA = 0;
// IIC_Delay();
// IIC_SCL = 1; //為SCL下降做準備
// IIC_Delay();
// IIC_SCL = 0; //時鐘是低電平
// dat<<=1;
// }
IIC_SDA = 1; //釋放數據線
IIC_Delay();
IIC_SCL = 1; //這是不是一個時鐘的上升沿?,這就是第8個時鐘完成之后的第9個時鐘!!!
IIC_Delay();
iic_ack |= IIC_SDA; //讀入應答位
IIC_SCL = 0;
return iic_ack; //返回應答信號

ID:624769 · 發表于 2021-10-29 17:17

Y_G_G 發表于 2021-10-29 14:01
你數一下是不是第9個

寫入的時候一樣的是第九個時鐘教材是有人審核的,不可能幾乎所有的教材都是錯的

16 和17 應該交換一下吧?

雖然有個 Delay 在前面，即便SCL高電平也已經能讀到ACK了，但是從規范上來講，應該先拉低時鐘，然后再讀ACK才可以吧？

ID:401564 · 發表于 2021-10-29 20:41

188610329 發表于 2021-10-29 17:17
16 和17 應該交換一下吧?

雖然有個 Delay 在前面，即便SCL高電平也已經能讀到ACK了，但是從規范上來 ...

低電平等于時鐘完成了,讀取不到電平狀態,協議上也是高電平的時候讀取的

ID:266429 · 發表于 2021-10-31 22:30

Y_G_G 發表于 2021-10-29 14:01
你數一下是不是第9個

寫入的時候一樣的是第九個時鐘教材是有人審核的,不可能幾乎所有的教材都是錯的

我先問一句：按教材的做法，能連續讀取數據么？這個實驗本來極其簡單，分分鐘的事。

ID:266429 · 發表于 2021-11-1 10:17

Y_G_G 發表于 2021-10-29 14:01
你數一下是不是第9個

寫入的時候一樣的是第九個時鐘教材是有人審核的,不可能幾乎所有的教材都是錯的

假設教材上寫的方案行得通，如果讓你來設計這個總線協議，你覺得哪種方案更合理？
總線協議，說起來總歸是純人為設計的東西，對于人為設計的東西，我們應該都可以質疑并找出更合理的方案，然后你自己就可以申請專利了，當然，Ｉ２Ｃ總線這么簡單的東西，就不要想了，當初弄出這東西的人，都是一群高智商的人。
Ｉ２Ｃ總線的這個問題，本來只是個非常簡單的問題，而且是個非常有意義的問題，沒想到參與討論的人這么少，只能嘆口氣了。

ID:401564 · 發表于 2021-11-1 10:49

慢慢思考發表于 2021-11-1 10:17
假設教材上寫的方案行得通，如果讓你來設計這個總線協議，你覺得哪種方案更合理？
總線協議，說起來總歸 ...

你看了我的代碼圖片沒有,你怎么數,它都是第9個時鐘
就算是你自己寫的,只要是能連續讀取的,它也是第9個時鐘,你把你的代碼文件上傳,C也行,匯編也行
我幫你改注釋,我讓你找出第9個出來
協議這種東西,你怎么設計才是合理的?
你搞低作為應答,就有人就會問"你為什么不把高電平作為應答呢?"
那我高電平作為應答,那還是有人會問"你為什么不把低電平作為應答呢?

ID:266429 · 發表于 2021-11-1 16:36

Y_G_G 發表于 2021-11-1 10:49
你看了我的代碼圖片沒有,你怎么數,它都是第9個時鐘
就算是你自己寫的,只要是能連續讀取的,它也是第9個時 ...

當然看過了，類似的代碼另外也看了不少。我手上提到Ｉ２Ｃ的紙質書就有四本，其中兩本的有關應答的時序圖中，在第８個時鐘周期時鐘線的低電位時，已有明確的應答低電位信號；一本則是第８周期時鐘線下降沿末端，數據線電位開始下降，在第９周期前達到低電位；最后一本則是含混不清，似乎是在第９周期時鐘線上升沿中達到低電位，真夠亂套的。
至于應答是用高電平還是低電平，這個Ｉ２Ｃ總線規格設計是這樣考慮的：器件在其端口輸出高電平，就意味著其交出對線路的控制權，所以，用低電平作應答信號。
至于我編的程序，二樓有讀出操作的應答程序。
下面是程序的主要部分，請指教：
void i2cstart()//開始程序，其實應分為開機初始化部分與總線開始部分這兩個子函數
{
i2cscl=1;delayus(4);
i2csda=1;delayus(4);
i2csda=0;delayus(4);
i2cscl=0;delayus(4);
}
//////
void i2cend()//結束
{
i2csda=0;delayus(4);
i2cscl=1;delayus(4);
i2csda=1;delayus(4);
}
//////
void i2cwack()//寫入應答
{
   i2csda=1; delayus(4);//執行后數據線狀態為低，說明從器件的應答信號已發出
i2cscl=1;delayus(4);//數據線狀態為低
   i2cscl=0;delayus(4);//數據線狀態為高
}
//////
void i2crack()//讀出應答
{
i2csda=0;delayus(4);
i2cscl=1;delayus(4);
i2cscl=0;delayus(4);
i2csda=1;delayus(4);//主器件釋放對數據線的控制權
}
///////
void i2cwritebyte(unsigned char wdat)//寫入一字節，加入應答
{
unsigned char i;
P2=wdat;
for(i=0;i<8;i++)
{
   i2csda=0x01&wdat>>7;
   wdat=wdat<<1;

   i2cscl=1;delayus(4);
   i2cscl=0;delayus(4);
}//完成后數據線狀態為低，與被輸入該字節數據０位的值無關
   i2cwack();
}
///////
unsigned char i2creadbyte()//讀出一字節，加入應答
{

   unsigned char rdat=0,i;
   for(i=0;i<8;i++)
   {
   i2cscl=1;delayus(4);
   rdat=rdat<<1|i2csda;
   i2cscl=0;delayus(4);
   }    //讀出來的這一字節數據最后一位無論是０還是１，此時數據線狀態均為１
   i2crack(); //應答完成后數據線狀態與下一待讀字節的最高位一致
   return(rdat);
}

//////
void main()//連續讀兩個字節并送至Ｐ２口
{
   i2cstart();
   i2cwritebyte(0xa0);
   i2cwritebyte(0x01);
   i2cend();

i2cstart();
i2cwritebyte(0xa1);
P2=i2creadbyte();
delayms(2000);
P2=i2creadbyte();
i2cend();

while(1);
}
注：讀出來的數據直接送到Ｐ２口，其上接有８只燈；數據線與時鐘線上各接有一只燈用以觀察實驗過程中端口電位。
寫入應答有三個動作，其三個動作分別執行后各自對應的數據線的狀態實測值已在程序中標注，由此可知寫入時從器件應答信號具體發出的時序時間。
讀數據時，最后一字節數據沒有用非應答，用的依然是應答，然后結束。

ID:975504 · 發表于 2021-11-1 16:49

51黑有你更精彩，感謝！

ID:401564 · 發表于 2021-11-1 18:23

慢慢思考發表于 2021-11-1 16:36
當然看過了，類似的代碼另外也看了不少。我手上提到Ｉ２Ｃ的紙質書就有四本，其中兩本的有關應答的時序圖 ...

以你的代碼為例
void i2cwritebyte(unsigned char wdat)//寫入一字節，加入應答
{
unsigned char i;
      P2=wdat;
      for(i=0;i<8;i++)
      {
         i2csda=0x01&wdat>>7;
         wdat=wdat<<1;

         i2cscl=1;delayus(4);
         i2cscl=0;delayus(4);//最后時鐘線是低電平,第8個時鐘已經結束
      }
      i2cwack();//應答中時鐘線是高電平,這就是第9 個時鐘
}
但是,你的應答并不對
應答是要等待SDA出現低電平,而不是簡單延時一下
這個SDA的低電平是24C02給出的
理論上應該是:
      SCL=1;//時鐘高電平,保持從機在第9個時鐘
Delay();//延時
SDA=1;//釋放SDA
while(SDA) ;等待從機出現應答,重點在這里,延時是不行的,必需得是等待,這是協議規定的

但是,在實際情況中,考慮從機有故障或者什么的,可能不會應答,while(SDA) ;會卡死
所以,可以使用:
while((SDA==1)&(k<1000)) //超時就不再等待應答
{
k++;
Delay();
}

而你的程序,本身就是錯誤的:
void i2cwack()//寫入應答
{
      i2csda=1; delayus(4);//執行后數據線狀態為低，說明從器件的應答信號已發出
      i2cscl=1;delayus(4);//數據線狀態為低
      i2cscl=0;delayus(4);//數據線狀態為高
}
應該是:
void i2cwack()//寫入應答
{
      i2csda=1; delayus(4);
      i2cscl=1;delayus(4);       while(i2csda);       //這里要等待,不是延時,重點!重點!重點!可以加入超時檢測退出,防止卡死
      i2cscl=0;delayus(4);
}
而且,IIC停止讀取之前要加一定不應答信號,這個信號要由單片機給出,告訴從機,不要再發送數據了
這個信號不是絕對需要,有的器件你直接停止就可以了,但有的不行,你要給出不應答才能正確讀取下一次的數據
像你的代碼,能正常就是運氣好,因為有的IIC器件硬件電氣性能很好,它的反應比單片機還快,它可能壓根就不需要應答

ID:266429 · 發表于 2021-11-1 19:41

Y_G_G 發表于 2021-11-1 18:23
以你的代碼為例
void i2cwritebyte(unsigned char wdat)//寫入一字節，加入應答
{

void i2cwritebyte(unsigned char wdat)//寫入一字節，加入應答
{
unsigned char i;
      P2=wdat;
      for(i=0;i<8;i++)
      {
         i2csda=0x01&wdat>>7;
         wdat=wdat<<1;

         i2cscl=1;delayus(4);
         i2cscl=0;delayus(4);//最后時鐘線是低電平,第8個時鐘已經結束，但結束時數據線已經是低電平
      }
      i2cwack();//應答中時鐘線是高電平,這就是第9 個時鐘。是一高一低，低時數據線恢復高電平
}

SCL=1;//時鐘高電平,保持從機在第9個時鐘
      Delay();//延時
      SDA=1;//釋放SDA
這里的延時，并不是用來等待從器件給出應答信號，而是為了讓時鐘線的高電位穩定一下。至于從器件的拉低數據線的應答信號，我在前面的實驗已經明確指出，它在這個ＳＣＬ=１執行之前，就已經發出了。原則上，在時鐘線處于高電位時，是不允許改變數據線狀態的，所以，在ＳＣＬ＝１執行之后，無論是從器件還是主器件，都不能對數據端口進行操作。
對應的，在讀取數據的程序編寫中，主器件的應答信號也就是拉低數據線的操作，也是在應答期ＳＣＬ＝１的操作之前進行的，也就是一個字節數據讀完、ＳＣＬ＝０之后就立即執行ＳＤＡ＝０這個操作，只能這樣安排順序。

至于我的程序中的“錯誤”，是因為僅是一個試驗應答規格的程序，所以嘛，沒有設計專門的程序來檢測，而是用人眼觀察數據線上燈的亮滅。

ID:401564 · 發表于 2021-11-1 23:32

慢慢思考發表于 2021-11-1 19:41
void i2cwritebyte(unsigned char wdat)//寫入一字節，加入應答
{
unsigned char i;

太神奇了
錯誤就是錯誤,
1,到底是不是我說的第9個時鐘?還是像你說的第8個?

2,我沒有看到你代碼中有等待應答的指令,一個沒有等待應答的IIC,它能叫IIC嗎?錯誤還加引號,敢情你還覺得這沒有等待應答的IIC代碼是對的?
你要說其它事,可能在每個人心里都有不一樣的看法,我覺得是對的,你也可以覺得是錯誤的,我有我的標準,你有你的標準

但這不一樣,這是單純的技術問題,它是有對錯的,有標準的
我可以肯定的告訴你:你這個IIC代碼是錯誤的,放哪都是錯誤的,別加引號你告訴我一下,你等待從機應答的代碼在哪里??????等待!等待!等待!

ID:266429 · 發表于 2021-11-2 08:41

Y_G_G 發表于 2021-11-1 23:32
太神奇了
錯誤就是錯誤,
1,到底是不是我說的第9個時鐘?還是像你說的第8個?

其實第一個問題，是第８個還是第９個，這個就是個怎么計數的問題，各人看法不一樣，無所謂，可以確定的是，在寫入操作中，最后一位數放在數據線上，時鐘線然后拉高讀取數據，然后再拉低后，從器件就將數據線拉成低電位了。
第二個問題嘛，正常編程當然不能這樣，我這本是根據我這個實驗的具體情況偷了個懶省了這一步，加個引號并不是認為這不是錯誤。實際上這種做法也是可以通過的，它在功能單一且對運行速度無太多要求的場合中，你的每一步之間的延時足夠長比如１０ms，基本上出錯的可能性也不大，但這樣絕對不規范。

ID:976973 · 發表于 2021-11-2 11:57

好資料，51黑有你更精彩!!!

帳號		自動登錄	找回密碼
密碼			立即注冊

久久久久久久999_99精品久久精品一区二区爱城_成人欧美一区二区三区在线播放_国产精品日本一区二区不卡视频_国产午夜视频_欧美精品在线观看免费

關于I2C總線讀寫應答機制