引子
STM32的硬件I2C很多人都對(duì)它望而卻步。因?yàn)楹芏?a target="_blank">電工都說(shuō),STM32 硬件 I2C有BUG、不穩(wěn)定、死機(jī)等等……最后都使用GPIO模擬I2C。
的確,模擬I2C好用。但是在我看來(lái)在一個(gè)72M的Cortex-M3的MCU上這樣做非常不妥。一般來(lái)說(shuō)I2C是一種慢速總線,就算工作在400kHz的快速模式上,I2C傳送每個(gè)字節(jié)仍需要至少23us——還沒(méi)有計(jì)算地址、起始信號(hào)和結(jié)束信號(hào)的發(fā)送。如果使用GPIO模擬的I2C,這23us的CPU時(shí)間都在空轉(zhuǎn)中浪費(fèi)了,而這23us已經(jīng)可以做不少的事情了,所以在STM32上I2C還是使用硬件為佳——雖然它多多少少有點(diǎn)缺陷。
這篇文章不是給完全沒(méi)有接觸過(guò)STM32 硬件I2C的新手看的,看這篇文章之前至少先閱讀STM32的參考手冊(cè)(RM0008)。
概覽
我們先來(lái)看一下STM32 I2C硬件的結(jié)構(gòu)
我們可以看見(jiàn)STM32的硬件I2C有兩個(gè)和數(shù)據(jù)有關(guān)的寄存器“數(shù)據(jù)寄存器(Data register)”(DR)和“數(shù)據(jù)移位寄存器(Data shift register)”(DSR),我們的軟件寫(xiě)入的是DR, DSR用于I2C數(shù)據(jù)的移位發(fā)送和接收,DR和DSR的數(shù)據(jù)交換由硬件控制——發(fā)送時(shí)DSR為空,DR不為空時(shí),硬件自動(dòng)把DR的數(shù)據(jù)寫(xiě)進(jìn)DSR;接收時(shí)DR為空,DSR不為空,硬件自動(dòng)把DSR數(shù)據(jù)寫(xiě)進(jìn)DR。連續(xù)數(shù)據(jù)傳輸時(shí),這樣兩個(gè)寄存器的數(shù)據(jù)交換使得軟件讀出和寫(xiě)入DR不會(huì)影響I2C總線中的數(shù)據(jù)接收和發(fā)送,使I2C的效率更高,這看起來(lái)十分美好,但是正是這個(gè)特點(diǎn)在某些情況下會(huì)變成電工們的噩夢(mèng)。原因有二。
1、硬件上,DR和DSR的交換機(jī)制存在缺陷。 2、軟件上,因?yàn)镈R和DSR一共能容納兩個(gè)字節(jié)的數(shù)據(jù),導(dǎo)致接收時(shí)候NACK的設(shè)置有一定的不可預(yù)料性。
硬件
硬件I2C上的缺陷,新版英文ErrSheet已經(jīng)寫(xiě)得很清楚,就不引用了,這里只簡(jiǎn)單說(shuō)說(shuō)要點(diǎn)和一些個(gè)人總結(jié)。
1、EV7, EV7_1, EV6_1, EV6_3, EV2, EV8 和 EV3 必須在當(dāng)前字節(jié)傳輸前處理完成,不然,有可能會(huì)導(dǎo)致數(shù)據(jù)出錯(cuò)。
這幾個(gè)事件都涉及到DR和DSR,個(gè)人猜測(cè)(主要是有個(gè)”may be”才敢猜測(cè))可能是讀出或者寫(xiě)入DR的同時(shí)DSR被填滿(mǎn)或清空,導(dǎo)致數(shù)據(jù)出錯(cuò)。理想情況下“讀出或者寫(xiě)入DR的同時(shí)DSR被填滿(mǎn)或清空”是不可能發(fā)生的,中斷一來(lái)臨的時(shí)候,CPU馬上處理中斷請(qǐng)求,讀出或者寫(xiě)入DR數(shù)據(jù),這時(shí)DSR的數(shù)據(jù)還是“新鮮滾熱辣”的,可能連一位都沒(méi)有接收或發(fā)送。但是,在實(shí)際使用時(shí),可能有別的中斷優(yōu)先級(jí)比I2C的事件中斷要高,I2C事件沒(méi)有及時(shí)處理而出現(xiàn)了上述的情況。所以,ST建議把I2C的事件中斷設(shè)置成最高優(yōu)先級(jí)。
2、產(chǎn)生STOP前DSR必須為空,不然,會(huì)導(dǎo)致DSR里的數(shù)據(jù)左移一位。
這個(gè)沒(méi)什么好說(shuō)的,就是一個(gè)硬件的BUG,保證發(fā)送STOP前DSR沒(méi)有數(shù)據(jù)就可以了。
3、總線上,開(kāi)始條件(S)后沒(méi)有進(jìn)行數(shù)據(jù)傳輸就馬上設(shè)置停止條件(P),或者S后忘記P會(huì)導(dǎo)致硬件I2C不能再次產(chǎn)生S,必須軟復(fù)位I2C。
這個(gè)ST解釋成是,STM32嚴(yán)格按照了I2C的標(biāo)準(zhǔn),S之后沒(méi)有數(shù)據(jù)傳輸是不能P的。其實(shí)這點(diǎn)可以體諒,但是,這點(diǎn)如果沒(méi)有處理好,總線上的錯(cuò)誤會(huì)導(dǎo)致STM32 I2C陷入癱瘓。
軟件
由于DR和DSR的存在,編程上需要一些技巧,新版英文ErrSheet和參考手冊(cè)(RM0008)都有相關(guān)的操作介紹(Closing the communication),排除硬件上的缺陷,編程的難點(diǎn)主要在接收時(shí)如何可靠地設(shè)置NACK上。
在只有DSR的MCU上設(shè)置NACK是非常簡(jiǎn)單的,在讀出倒數(shù)第二個(gè)數(shù)據(jù)前設(shè)置一下就可以了,但是個(gè)方法在似乎在STM32上行不通,因?yàn)镾TM32有DR和DSR,在倒數(shù)第二個(gè)數(shù)據(jù)被接收的時(shí)候(RxNE置位),馬上設(shè)置NACK,理想情況下沒(méi)有任何問(wèn)題,NACK也被正確的發(fā)送,但是如果有其他更高優(yōu)先級(jí)的中斷打斷了這個(gè)過(guò)程,NACK就不能及時(shí)設(shè)置,導(dǎo)致從器件收到的是ACK沒(méi)有釋放總線……
ST提供的資料上(筆者所見(jiàn)),給電工們的建議。
1、接收2個(gè)字節(jié)或1個(gè)字節(jié)時(shí),切換GPIO模式為OD,然后軟件下拉SCL引腳,使硬件I2C發(fā)生時(shí)鐘延展,把下一個(gè)字節(jié)開(kāi)始傳輸?shù)臅r(shí)機(jī)延后,設(shè)置完NACK后,再把GPIO設(shè)置回AFOD,但是這只能解決小于兩個(gè)字節(jié)的接收。
2、大于2個(gè)字節(jié)用DMA,DMA可以說(shuō)是特效藥,“屢試不爽”。不過(guò)要注意,接收大于或等于2個(gè)字節(jié)時(shí)才能使用DMA,不然不能產(chǎn)生EOT-1事件導(dǎo)致NACK不能正確發(fā)送。
3、設(shè)置I2C事件中斷為最高優(yōu)先等級(jí)。
方案
讀到這里你可能會(huì)想,硬件有缺陷,軟件也得這么“猥瑣”,可以說(shuō)是寸步難行。真的沒(méi)有其他辦法了嗎?其實(shí),我們可以把DR和DSR兩個(gè)當(dāng)一個(gè)用,全部判斷BTF,不理會(huì)TxE和RxE,用時(shí)間來(lái)?yè)Q穩(wěn)定性,慢點(diǎn)就慢點(diǎn)總比沒(méi)得用好。發(fā)送時(shí):開(kāi)始,發(fā)送寫(xiě)地址,器件應(yīng)答,清ADDR,一字節(jié)數(shù)據(jù)到寫(xiě)DR,硬件把DR數(shù)據(jù)寫(xiě)入到DSR,當(dāng)DSR傳輸完畢時(shí),DR也為空,BTF置位,這時(shí)我們?cè)賹?xiě)一字節(jié)數(shù)據(jù)到DR,如此循環(huán),最后一次BTF置位的時(shí)候發(fā)送P或者重起始(R)。這樣操作,“硬件把DR數(shù)據(jù)寫(xiě)入到DSR”執(zhí)行的時(shí)間是我們可以預(yù)料的,不存在上面提及的沖突問(wèn)題。接收時(shí):1、接收一個(gè)字節(jié):按照ST給的方法。開(kāi)始,發(fā)送讀地址,器件應(yīng)答,清ADDR前軟件下拉SCL,寫(xiě)完NACK、STOP和DR后軟件再釋放SCL。RxNE時(shí)讀DR。 2、接收兩個(gè)字節(jié):也是按照ST的方法。開(kāi)始,發(fā)送讀地址,器件應(yīng)答,設(shè)置POS和ACK,下拉SCL,清ADDR,設(shè)置NACK,釋放SCL。BTF時(shí),軟件拉低SCL,發(fā)送STOP,讀DR,釋放SCL,再讀DR。 3、接收兩個(gè)以上字節(jié):開(kāi)始,發(fā)送讀地址,器件應(yīng)答,直接清ADDR。BTF時(shí),讀DR一次。再BTF,再讀DR一次,如此循環(huán)。倒數(shù)第二次BTF時(shí)設(shè)置NACK(注意DR和DSR各有一字節(jié)的數(shù)據(jù)),讀DR一次。再等到最后一次BTF時(shí),軟件拉低SCL,發(fā)送STOP,讀DR,釋放SCL,再讀DR。 4、請(qǐng)注意在讀取SR2到操作其他I2C寄存器期間使用軟件產(chǎn)生時(shí)鐘延展。2016.02.03 thx:iguesser
干擾
當(dāng)總線空閑時(shí),無(wú)論是SCL的跳變(電平高低高),還是SDA的跳變,都會(huì)導(dǎo)致STM32的硬件I2C癱瘓,不能產(chǎn)生下一個(gè)S。當(dāng)總線正在傳輸數(shù)據(jù)時(shí),總線上的信號(hào)干擾對(duì)STM32的硬件I2C來(lái)說(shuō)是致命的。
1、空閑時(shí)SDA跳變,會(huì)產(chǎn)生一個(gè)S和一個(gè)P,幸好這個(gè)P會(huì)產(chǎn)生一個(gè)中斷,我們可以用一個(gè)收到P就軟復(fù)位硬件I2C的策略。這樣能避免空閑時(shí)SDA跳變帶來(lái)的干擾。
2、空閑時(shí)SCL跳變,這是一個(gè)I2C的錯(cuò)誤信號(hào),但是STM32卻會(huì)認(rèn)為這是一個(gè)S,所以SCL跳變會(huì)導(dǎo)致BUSY置位,而且不會(huì)像SDA跳變那樣會(huì)產(chǎn)生一個(gè)P中斷。如果在單主的情況下,你可以為I2C的S做一個(gè)超時(shí),超時(shí)了就軟復(fù)位I2C就可以,當(dāng)然最簡(jiǎn)單的方法還是空閑時(shí)關(guān)閉I2C(PE置零)。在多從機(jī)的情況下,只能等待別的主機(jī)發(fā)送的一個(gè)P,或者伺機(jī)軟復(fù)位。
3、傳輸途中因干擾,產(chǎn)生總線錯(cuò)誤(BERR)。單主接收途中出現(xiàn)BERR,可以在關(guān)閉硬件I2C后,連續(xù)模擬產(chǎn)生9個(gè)以上的SCL,在保證SDA為高電平的情況下軟復(fù)位I2C。
4、傳輸途中因干擾,導(dǎo)致仲裁丟失(ARLO)。單主時(shí)和BERR的處理方法相同。
其他
還有什么值得注意的?
很多電工們反映,上電也是一個(gè)大問(wèn)題,I2C一上電就馬上BUSY了,第一次的S都不能發(fā)送,我是沒(méi)有遇上這個(gè)問(wèn)題。Google了一下很多都說(shuō)是初始化順序的問(wèn)題。說(shuō)說(shuō)我的初始化吧,打開(kāi)I2C外設(shè)的時(shí)鐘、打開(kāi)I2C引腳所在的GPIO的時(shí)鐘、配置 GPIO_AF_OD、 I2C_DeInit、 I2C_Init、 I2C_Cmd,沒(méi)有什么特別。還有一種可能就是,上電時(shí)上電的脈沖干擾了總線,導(dǎo)致某個(gè)從設(shè)鎖死了總線(拉低了SDA)導(dǎo)致的BUSY置位,這個(gè)可以用處理BERR的方法,使總線恢復(fù)正常。(2012 Jun 6)
總線上的P產(chǎn)生后最好不要配置CR1的ACK位。STOP發(fā)送后配置ACK位——作為主機(jī)接收最后一字節(jié)時(shí)需要發(fā)送NACK,同時(shí)我們需要響應(yīng)自己的從機(jī)地址,這時(shí)需要重新配置ACK為”1″——有可能導(dǎo)致下一次作為主機(jī)通信發(fā)送地址時(shí),硬件不發(fā)送地址而直接發(fā)送P——這應(yīng)該是一個(gè)硬件BUG,暫時(shí)還沒(méi)有看見(jiàn)相關(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自動(dòng)更新,產(chǎn)生最高占先優(yōu)先級(jí)的中斷,并在中斷里停留70us左右,且重裝載值是一個(gè)素?cái)?shù)的情況下,STM32F103VET6 400kHz的I2C跑了近一周沒(méi)有發(fā)現(xiàn)數(shù)據(jù)錯(cuò)誤。
至此,STM32 I2C的問(wèn)題基本解決,歡迎廣大電工們指正、反饋。
-
寄存器
+關(guān)注
關(guān)注
31文章
5294瀏覽量
119823 -
STM32
+關(guān)注
關(guān)注
2264文章
10854瀏覽量
354305 -
I2C
+關(guān)注
關(guān)注
28文章
1477瀏覽量
123061
原文標(biāo)題:淺談 STM32 硬件I2C的使用 (中斷方式 無(wú)DMA 無(wú)最高優(yōu)先級(jí))
文章出處:【微信號(hào):RTThread,微信公眾號(hào):RTThread物聯(lián)網(wǎng)操作系統(tǒng)】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論