引子

STM32的硬件I2C很多人都對它望而卻步。因為很多電工都說，STM32 硬件 I2C有BUG、不穩(wěn)定、死機等等……最后都使用GPIO模擬I2C。

的確，模擬I2C好用。但是在我看來在一個72M的Cortex-M3的MCU上這樣做非常不妥。一般來說I2C是一種慢速總線，就算工作在400kHz的快速模式上，I2C傳送每個字節(jié)仍需要至少23us——還沒有計算地址、起始信號和結(jié)束信號的發(fā)送。如果使用GPIO模擬的I2C，這23us的CPU時間都在空轉(zhuǎn)中浪費了，而這23us已經(jīng)可以做不少的事情了，所以在STM32上I2C還是使用硬件為佳——雖然它多多少少有點缺陷。

這篇文章不是給完全沒有接觸過STM32 硬件I2C的新手看的，看這篇文章之前至少先閱讀STM32的參考手冊(RM0008)。

概覽

我們先來看一下STM32 I2C硬件的結(jié)構(gòu)

我們可以看見STM32的硬件I2C有兩個和數(shù)據(jù)有關(guān)的寄存器“數(shù)據(jù)寄存器(Data register)”(DR)和“數(shù)據(jù)移位寄存器(Data shift register)”(DSR)，我們的軟件寫入的是DR， DSR用于I2C數(shù)據(jù)的移位發(fā)送和接收，DR和DSR的數(shù)據(jù)交換由硬件控制——發(fā)送時DSR為空，DR不為空時，硬件自動把DR的數(shù)據(jù)寫進DSR；接收時DR為空，DSR不為空，硬件自動把DSR數(shù)據(jù)寫進DR。連續(xù)數(shù)據(jù)傳輸時，這樣兩個寄存器的數(shù)據(jù)交換使得軟件讀出和寫入DR不會影響I2C總線中的數(shù)據(jù)接收和發(fā)送，使I2C的效率更高，這看起來十分美好，但是正是這個特點在某些情況下會變成電工們的噩夢。原因有二。

1、硬件上，DR和DSR的交換機制存在缺陷。 2、軟件上，因為DR和DSR一共能容納兩個字節(jié)的數(shù)據(jù)，導(dǎo)致接收時候NACK的設(shè)置有一定的不可預(yù)料性。

硬件

硬件I2C上的缺陷，新版英文ErrSheet已經(jīng)寫得很清楚，就不引用了，這里只簡單說說要點和一些個人總結(jié)。

1、EV7, EV7_1, EV6_1, EV6_3, EV2, EV8 和 EV3 必須在當前字節(jié)傳輸前處理完成，不然，有可能會導(dǎo)致數(shù)據(jù)出錯。

這幾個事件都涉及到DR和DSR，個人猜測(主要是有個”may be”才敢猜測)可能是讀出或者寫入DR的同時DSR被填滿或清空，導(dǎo)致數(shù)據(jù)出錯。理想情況下“讀出或者寫入DR的同時DSR被填滿或清空”是不可能發(fā)生的，中斷一來臨的時候，CPU馬上處理中斷請求，讀出或者寫入DR數(shù)據(jù)，這時DSR的數(shù)據(jù)還是“新鮮滾熱辣”的，可能連一位都沒有接收或發(fā)送。但是，在實際使用時，可能有別的中斷優(yōu)先級比I2C的事件中斷要高，I2C事件沒有及時處理而出現(xiàn)了上述的情況。所以，ST建議把I2C的事件中斷設(shè)置成最高優(yōu)先級。

2、產(chǎn)生STOP前DSR必須為空，不然，會導(dǎo)致DSR里的數(shù)據(jù)左移一位。

這個沒什么好說的，就是一個硬件的BUG，保證發(fā)送STOP前DSR沒有數(shù)據(jù)就可以了。

3、總線上，開始條件(S)后沒有進行數(shù)據(jù)傳輸就馬上設(shè)置停止條件(P)，或者S后忘記P會導(dǎo)致硬件I2C不能再次產(chǎn)生S，必須軟復(fù)位I2C。

這個ST解釋成是，STM32嚴格按照了I2C的標準，S之后沒有數(shù)據(jù)傳輸是不能P的。其實這點可以體諒，但是，這點如果沒有處理好，總線上的錯誤會導(dǎo)致STM32 I2C陷入癱瘓。

軟件

由于DR和DSR的存在，編程上需要一些技巧，新版英文ErrSheet和參考手冊(RM0008)都有相關(guān)的操作介紹(Closing the communication)，排除硬件上的缺陷，編程的難點主要在接收時如何可靠地設(shè)置NACK上。

在只有DSR的MCU上設(shè)置NACK是非常簡單的，在讀出倒數(shù)第二個數(shù)據(jù)前設(shè)置一下就可以了，但是個方法在似乎在STM32上行不通，因為STM32有DR和DSR，在倒數(shù)第二個數(shù)據(jù)被接收的時候(RxNE置位)，馬上設(shè)置NACK，理想情況下沒有任何問題，NACK也被正確的發(fā)送，但是如果有其他更高優(yōu)先級的中斷打斷了這個過程，NACK就不能及時設(shè)置，導(dǎo)致從器件收到的是ACK沒有釋放總線……

ST提供的資料上(筆者所見)，給電工們的建議。

1、接收2個字節(jié)或1個字節(jié)時，切換GPIO模式為OD，然后軟件下拉SCL引腳，使硬件I2C發(fā)生時鐘延展，把下一個字節(jié)開始傳輸?shù)臅r機延后，設(shè)置完NACK后，再把GPIO設(shè)置回AFOD，但是這只能解決小于兩個字節(jié)的接收。

2、大于2個字節(jié)用DMA，DMA可以說是特效藥，“屢試不爽”。不過要注意，接收大于或等于2個字節(jié)時才能使用DMA，不然不能產(chǎn)生EOT-1事件導(dǎo)致NACK不能正確發(fā)送。

3、設(shè)置I2C事件中斷為最高優(yōu)先等級。

方案

讀到這里你可能會想，硬件有缺陷，軟件也得這么“猥瑣”，可以說是寸步難行。真的沒有其他辦法了嗎？其實，我們可以把DR和DSR兩個當一個用，全部判斷BTF，不理會TxE和RxE，用時間來換穩(wěn)定性，慢點就慢點總比沒得用好。發(fā)送時：開始，發(fā)送寫地址，器件應(yīng)答，清ADDR，一字節(jié)數(shù)據(jù)到寫DR，硬件把DR數(shù)據(jù)寫入到DSR，當DSR傳輸完畢時，DR也為空，BTF置位，這時我們再寫一字節(jié)數(shù)據(jù)到DR，如此循環(huán)，最后一次BTF置位的時候發(fā)送P或者重起始（R）。這樣操作，“硬件把DR數(shù)據(jù)寫入到DSR”執(zhí)行的時間是我們可以預(yù)料的，不存在上面提及的沖突問題。接收時：1、接收一個字節(jié)：按照ST給的方法。開始，發(fā)送讀地址，器件應(yīng)答，清ADDR前軟件下拉SCL，寫完NACK、STOP和DR后軟件再釋放SCL。RxNE時讀DR。 2、接收兩個字節(jié)：也是按照ST的方法。開始，發(fā)送讀地址，器件應(yīng)答，設(shè)置POS和ACK，下拉SCL，清ADDR，設(shè)置NACK，釋放SCL。BTF時，軟件拉低SCL，發(fā)送STOP，讀DR，釋放SCL，再讀DR。 3、接收兩個以上字節(jié)：開始，發(fā)送讀地址，器件應(yīng)答，直接清ADDR。BTF時，讀DR一次。再BTF，再讀DR一次，如此循環(huán)。倒數(shù)第二次BTF時設(shè)置NACK(注意DR和DSR各有一字節(jié)的數(shù)據(jù))，讀DR一次。再等到最后一次BTF時，軟件拉低SCL，發(fā)送STOP，讀DR，釋放SCL，再讀DR。 4、請注意在讀取SR2到操作其他I2C寄存器期間使用軟件產(chǎn)生時鐘延展。2016.02.03 thx:iguesser

干擾

當總線空閑時，無論是SCL的跳變(電平高低高)，還是SDA的跳變，都會導(dǎo)致STM32的硬件I2C癱瘓，不能產(chǎn)生下一個S。當總線正在傳輸數(shù)據(jù)時，總線上的信號干擾對STM32的硬件I2C來說是致命的。

1、空閑時SDA跳變，會產(chǎn)生一個S和一個P，幸好這個P會產(chǎn)生一個中斷，我們可以用一個收到P就軟復(fù)位硬件I2C的策略。這樣能避免空閑時SDA跳變帶來的干擾。

2、空閑時SCL跳變，這是一個I2C的錯誤信號，但是STM32卻會認為這是一個S，所以SCL跳變會導(dǎo)致BUSY置位，而且不會像SDA跳變那樣會產(chǎn)生一個P中斷。如果在單主的情況下，你可以為I2C的S做一個超時，超時了就軟復(fù)位I2C就可以，當然最簡單的方法還是空閑時關(guān)閉I2C(PE置零)。在多從機的情況下，只能等待別的主機發(fā)送的一個P，或者伺機軟復(fù)位。

3、傳輸途中因干擾，產(chǎn)生總線錯誤(BERR)。單主接收途中出現(xiàn)BERR，可以在關(guān)閉硬件I2C后，連續(xù)模擬產(chǎn)生9個以上的SCL，在保證SDA為高電平的情況下軟復(fù)位I2C。

4、傳輸途中因干擾，導(dǎo)致仲裁丟失(ARLO)。單主時和BERR的處理方法相同。

其他

還有什么值得注意的?

很多電工們反映，上電也是一個大問題，I2C一上電就馬上BUSY了，第一次的S都不能發(fā)送，我是沒有遇上這個問題。Google了一下很多都說是初始化順序的問題。說說我的初始化吧，打開I2C外設(shè)的時鐘、打開I2C引腳所在的GPIO的時鐘、配置 GPIO_AF_OD、 I2C_DeInit、 I2C_Init、 I2C_Cmd，沒有什么特別。還有一種可能就是，上電時上電的脈沖干擾了總線，導(dǎo)致某個從設(shè)鎖死了總線(拉低了SDA)導(dǎo)致的BUSY置位，這個可以用處理BERR的方法，使總線恢復(fù)正常。(2012 Jun 6)

總線上的P產(chǎn)生后最好不要配置CR1的ACK位。STOP發(fā)送后配置ACK位——作為主機接收最后一字節(jié)時需要發(fā)送NACK，同時我們需要響應(yīng)自己的從機地址，這時需要重新配置ACK為”1″——有可能導(dǎo)致下一次作為主機通信發(fā)送地址時，硬件不發(fā)送地址而直接發(fā)送P——這應(yīng)該是一個硬件BUG，暫時還沒有看見相關(guān)資料——具體表現(xiàn)為EV6死循環(huán)。推薦的做法是設(shè)置P前，軟件下拉SCL，設(shè)置P，設(shè)置ACK，釋放SCL，這樣總線上的P將在釋放SCL后產(chǎn)生。(2012 Jul 3)

總結(jié)

這些都是我調(diào)STM32硬件I2C的一些心得。上文提及到的中斷接收和發(fā)送方法，我用TIM自動更新，產(chǎn)生最高占先優(yōu)先級的中斷，并在中斷里停留70us左右，且重裝載值是一個素數(shù)的情況下，STM32F103VET6 400kHz的I2C跑了近一周沒有發(fā)現(xiàn)數(shù)據(jù)錯誤。

至此，STM32 I2C的問題基本解決，歡迎廣大電工們指正、反饋。