有人使用STM32F4芯片驗證SPI功能。當使用片內(nèi)兩個SPI模塊基于中斷方式進行收發(fā)時，發(fā)現(xiàn)總是出現(xiàn)接收數(shù)據(jù)丟失的情況，貌似總丟失末尾2個數(shù)據(jù)。代碼使用HAL庫提供的API函數(shù)。這是怎么回事呢？

我拿STM32F407開發(fā)板進行驗證測試。使用SPI1做發(fā)送，SPI3做接收，都使用中斷方式。

很快重現(xiàn)了問題現(xiàn)象，即發(fā)生接收數(shù)據(jù)丟失的情形。見下圖驗證結果，發(fā)了8個數(shù)據(jù)，只收到6個數(shù)據(jù)。

現(xiàn)在是同一顆芯片，即同一CPU基于中斷方式完成收發(fā)。懷疑會不會是不同SPI收發(fā)模塊中斷優(yōu)先級的安排不合理導致的問題。如果二者優(yōu)先級一樣的話，這里的發(fā)送中斷往往先于接收中斷的產(chǎn)生，勢必會出現(xiàn)接收不及時的情形。通過對代碼跟蹤調(diào)試，也的確發(fā)現(xiàn)了SPI接收溢出的現(xiàn)象，即接收數(shù)據(jù)提取不及時。

這樣分析下來，感覺數(shù)據(jù)丟失應該跟通信速率有關，丟失數(shù)據(jù)的多少不應該固定。于是，我大幅度提升SPI通信速率再行測試，果真丟失的數(shù)據(jù)更多了。見下圖測試結果，發(fā)8個數(shù)據(jù)只收到1個數(shù)據(jù)?！厩懊鏈y試時SPI波特率是5.25Mb/s,現(xiàn)在改為21Mb/s了】

我將SPI3接收中斷的優(yōu)先級調(diào)得比SPI1發(fā)送中斷的還高，如下圖所示。

基于重新調(diào)整中斷優(yōu)先級后的代碼再做測試，結果就完全正常了。

當然，我們還可以有其它靈活處理的辦法。比方發(fā)送用中斷，接收用DMA，或者發(fā)送用輪訓，接收用中斷或DMA，或者都用DMA方式也行。

這里的核心問題是中斷優(yōu)先級沒有合理安排好。STM32ARM核中斷的內(nèi)容不多，不過內(nèi)容不多的東西往往意味著使用上更為靈活。好，今天的話題就分享到這里。

審核編輯：湯梓紅