' h( ~2 M& B! z
有人使用STM32F4芯片验证SPI功能。当使用片内两个SPI模块基于中断方式进行收发时，发现总是出现接收数据丢失的情况，貌似总丢失末尾2个数据。代码使用HAL库提供的API函数。这是怎么回事呢？
! `' d0 A7 o0 D6 s: O: g- ]# i
我拿STM32F407开发板进行验证测试。使用SPI1做发送，SPI3做接收，都使用中断方式。


: ]/ {& Y& B8 Y& T& s9 u2 S3 I& W
$ f- h' i% _6 ?# z: f. t很快重现了问题现象，即发生接收数据丢失的情形。见下图验证结果，发了8个数据，只收到6个数据。


% n9 \$ z7 W2 B- A: E) k4 I
现在是同一颗芯片，即同一CPU基于中断方式完成收发。怀疑会不会是不同SPI收发模块中断优先级的安排不合理导致的问题。如果二者优先级一样的话，这里的发送中断往往先于接收中断的产生，势必会出现接收不及时的情形。通过对代码跟踪调试，也的确发现了SPI接收溢出的现象，即接收数据提取不及时。

: R+ u- p8 G: y0 G+ L5 j

+ L% h' K' y! g* }- j7 Z7 D. ~2 O这样分析下来，感觉数据丢失应该跟通信速率有关，丢失数据的多少不应该固定。于是，我大幅度提升SPI通信速率再行测试，果真丢失的数据更多了。见下图测试结果，发8个数据只收到1个数据。【前面测试时SPI波特率是5.25Mb/s,现在改为21Mb/s了】
+ [" o& |! i* V


我将SPI3接收中断的优先级调得比SPI1发送中断的还高，如下图所示。
8 u0 J' o+ D' a" s) U1 P( j$ R# Z& _


# ^9 B) n, B8 \& {( v! C0 `" ~8 z基于重新调整中断优先级后的代码再做测试，结果就完全正常了。
! {: K# u$ U6 M/ f7 a
" ]8 M+ l# a: V+ o( m. q1 Q/ w$ ^
# g1 j% B0 T$ d. r: S: p
7 F' k* J' R  D  K当然，我们还可以有其它灵活处理的办法。比方发送用中断，接收用DMA，或者发送用轮训，接收用中断或DMA，或者都用DMA方式也行。
- T3 `- `/ S9 z' H
这里的核心问题是中断优先级没有合理安排好。STM32 ARM核中断的内容不多，不过内容不多的东西往往意味着使用上更为灵活。好，今天的话题就分享到这里。
9 \' _+ W( t* w% c( G" C! a
8 W! ^) j) h. v转载自： 茶话MCU
6 Z6 ~3 [+ l) G- v! D如有侵权请联系删除
* h  [" v3 S; u" z/ T; N5 ?# T; c
; `* t5 z) m) u5 G4 W# ^. O

8 u& `6 c) _4 F' ]' y5 Z, H