概覽我們先來看一下STM32 I2C硬件的結構我們可以看見STM32的硬件I2C有兩個和數據有關的寄存器“數據寄存器(Data register)”(DR)和“數據移位寄存器(Data shift register)”(DSR)，我們的軟件寫入的是DR， DSR用于I2C數據的移位發送和接收，DR和DSR的數據交換由硬件控制——發送時DSR為空，DR不為空時，硬件自動把DR的數據寫進DSR；接收時DR為空，DSR不為空，硬件自動把DSR數據寫進DR。連續數據傳輸時，這樣兩個寄存器的數據交換使得軟件讀出和寫入DR不會影響I2C總線中的數據接收和發送，使I2C的效率更高，這看起來十分美好，但是正是這個特點在某些情況下會變成電工們的噩夢，原因有二：1、硬件上，DR和DSR的交換機制存在缺陷。2、軟件上，因為DR和DSR一共能容納兩個字節的數據，導致接收時候NACK的設置有一定的不可預料性。硬件硬件I2C上的缺陷，新版英文ErrSheet已經寫得很清楚，就不引用了，這里只簡單說說要點和一些個人總結。1、EV7, EV7_1, EV6_1, EV6_3, EV2, EV8 和 EV3 必須在當前字節傳輸前處理完成，不然，有可能會導致數據出錯。這幾個事件都涉及到DR和DSR，個人猜測(主要是有個”may be”才敢猜測)可能是讀出或者寫入DR的同時DSR被填滿或清空，導致數據出錯。理想情況下“讀出或者寫入DR的同時DSR被填滿或清空”是不可能發生的，中斷一來臨的時候，CPU馬上處理中斷請求，讀出或者寫入DR數據，這時DSR的數據還是“新鮮滾熱辣”的，可能連一位都沒有接收或發送。但是，在實際使用時，可能有別的中斷優先級比I2C的事件中斷要高，I2C事件沒有及時處理而出現了上述的情況。所以，ST建議把I2C的事件中斷設置成最高優先級。2、產生STOP前DSR必須為空，不然，會導致DSR里的數據左移一位。這個沒什么好說的，就是一個硬件的BUG，保證發送STOP前DSR沒有數據就可以了。3、總線上，開始條件(S)后沒有進行數據傳輸就馬上設置停止條件(P)，或者S后忘記P會導致硬件I2C不能再次產生S，必須軟復位I2C。這個ST解釋成是，STM32嚴格按照了I2C的標準，S之后沒有數據傳輸是不能P的。其實這點可以體諒，但是，這點如果沒有處理好，總線上的錯誤會導致STM32 I2C陷入癱瘓。軟件由于DR和DSR的存在，編程上需要一些技巧，新版英文ErrSheet和參考手冊(RM0008)都有相關的操作介紹(Closing the communication)，排除硬件上的缺陷，編程的難點主要在接收時如何可靠地設置NACK上。在只有DSR的MCU上設置NACK是非常簡單的，在讀出倒數第二個數據前設置一下就可以了，但是個方法在似乎在STM32上行不通，因為STM32有DR和DSR，在倒數第二個數據被接收的時候(RxNE置位)，馬上設置NACK，理想情況下沒有任何問題，NACK也被正確的發送，但是如果有其他更高優先級的中斷打斷了這個過程，NACK就不能及時設置，導致從器件收到的是ACK沒有釋放總線……1、接收2個字節或1個字節時，切換GPIO模式為OD，然后軟件下拉SCL引腳，使硬件I2C發生時鐘延展，把下一個字節開始傳輸的時機延后，設置完NACK后，再把GPIO設置回AFOD，但是這只能解決小于兩個字節的接收。2、大于2個字節用DMA，DMA可以說是特效藥，“屢試不爽”。不過要注意，接收大于或等于2個字節時才能使用DMA，不然不能產生EOT-1事件導致NACK不能正確發送。3、設置I2C事件中斷為最高優先等級。方案讀到這里你可能會想，硬件有缺陷，軟件也得這么“猥瑣”，可以說是寸步難行。真的沒有其他辦法了嗎？其實，我們可以把DR和DSR兩個當一個用，全部判斷BTF，不理會TxE和RxE，用時間來換穩定性，慢點就慢點總比沒得用好。發送時：開始，發送寫地址，器件應答，清ADDR，一字節數據到寫DR，硬件把DR數據寫入到DSR，當DSR傳輸完畢時，DR也為空，BTF置位，這時我們再寫一字節數據到DR，如此循環，最后一次BTF置位的時候發送P或者重起始（R）。這樣操作，“硬件把DR數據寫入到DSR”執行的時間是我們可以預料的，不存在上面提及的沖突問題。接收時：1、接收一個字節：按照ST給的方法。開始，發送讀地址，器件應答，清ADDR前軟件下拉SCL，寫完NACK、STOP和DR后軟件再釋放SCL。RxNE時讀DR。2、接收兩個字節：也是按照ST的方法。開始，發送讀地址，器件應答，設置POS和ACK，下拉SCL，清ADDR，設置NACK，釋放SCL。BTF時，軟件拉低SCL，發送STOP，讀DR，釋放SCL，再讀DR。3、接收兩個以上字節：開始，發送讀地址，器件應答，直接清ADDR。BTF時，讀DR一次。再BTF，再讀DR一次，如此循環。倒數第二次BTF時設置NACK(注意DR和DSR各有一字節的數據)，讀DR一次。再等到最后一次BTF時，軟件拉低SCL，發送STOP，讀DR，釋放SCL，再讀DR。干擾當總線空閑時，無論是SCL的跳變(電平高低高)，還是SDA的跳變，都會導致STM32的硬件I2C癱瘓，不能產生下一個S。當總線正在傳輸數據時，總線上的信號干擾對STM32的硬件I2C來說是致命的。1、空閑時SDA跳變，會產生一個S和一個P，幸好這個P會產生一個中斷，我們可以用一個收到P就軟復位硬件I2C的策略。這樣能避免空閑時SDA跳變帶來的干擾。2、空閑時SCL跳變，這是一個I2C的錯誤信號，但是STM32卻會認為這是一個S，所以SCL跳變會導致BUSY置位，而且不會像SDA跳變那樣會產生一個P中斷。如果在單主的情況下，你可以為I2C的S做一個超時，超時了就軟復位I2C就可以，當然最簡單的方法還是空閑時關閉I2C(PE置零)。在多從機的情況下，只能等待別的主機發送的一個P，或者伺機軟復位。3、傳輸途中因干擾，產生總線錯誤(BERR)。單主接收途中出現BERR，可以在關閉硬件I2C后，連續模擬產生9個以上的SCL，在保證SDA為高電平的情況下軟復位I2C。4、傳輸途中因干擾，導致仲裁丟失(ARLO)。單主時和BERR的處理方法相同。(mbbeetchina)