简介这套STM32 SPI通信例程专为入门者设计清晰演示如何通过SPI协议在两块STM32板子之间交换数据并顺带实现液晶屏显示。资源包共60个文件、约450KB包含C/H源码、Keil工程文件uvproj、TXT说明文档、hex/axf可执行文件以及编译生成的lst/map等中间文件便于对照研读和直接烧录验证。目前已有3073人学习使用。例程从GPIO引脚复用和SPI主从模式选择入手逐步讲解CPOL/CPHA组合、CR1/CR2/SR/DR等关键寄存器配置以及数据收发与错误处理的完整流程同时给出液晶显示的驱动思路。每一步都配有详细注解和设计意图可帮助新手理解同步串行通信的协议时序与硬件机制缩短从理论到动手实践的摸索过程适合课程设计或自学入门。1. 为什么我最后还是选了硬件SPI来做板间通信先说结论如果你只是想在两块STM32板子之间传数据SPI是比UART更“省心”的选择前提是你愿意多花几根线。我做这个例程的起因很实际——手头有两块F103的开发板一块做主、一块做从需要把主板上采集到的一组传感器数据实时丢给从板去驱动显示和告警。用UART当然也能干但SPI的速率上限高得多而且全双工主从关系清晰调试起来反而比想象中容易。开始之前先泼一盆冷水STM32的SPI例程网上遍地都是但大多数是“一块板子自发自收”也就是把MOSI和MISO短接起来测环回真正做两块板子互联的反而少。自发自收只能验证SPI外设本身没配错验证不了主从时序、片选极性、数据对齐这些跨板问题。所以这篇文章直接跳过环回测试上来就是主从双板真实通信的完整流程。这篇文章适合谁看刚把STM32环境搭好、想从流水灯进阶到板间通信的初学者以及被SPI从机模式折腾过、卡在“从机收不到数据”或“首字节丢数据”这类问题上的朋友。涉及的知识点包括CubeMX初始化、硬件片选与软件片选的区别、SPI时钟极性和相位的匹配以及跨板通信里非常容易踩的“从机提前发送”坑。我的验证环境给各位做个参考项目配置主控芯片STM32F103C8T6主板 / STM32F103CBT6从板开发环境Keil MDK 5 STM32CubeMX 6.x通信速率1 Mbps分频后数据模式SPI Mode 0CPOL0CPHA1边沿采样片选方式硬件NSS 软件控制后面会说为什么不直接用硬件NSS接线方式4线SCLK、MOSI、MISO、CS外加共地GND这套配置跑起来之后双向数据都能稳定传输长时间运行没有出现乱码或者丢字节的问题。下面就把整个实现过程、原理、以及我踩过的坑从头捋一遍。2. SPI板间通信的主从角色设计谁做主、谁做从决定了接线难度2.1 主从关系的本质是“谁产生时钟”很多初学者上来就问“两块板子哪个做主机”答案其实很明确**产生SCLK时钟的那一方就是主机另一方只能是被动接收时钟的从机。**SPI不像UART那样双方各自有独立的波特率时钟它所有的数据移位都靠主机输出的SCLK来驱动。所以如果你的应用场景是“主板采集数据从板负责显示”那就让采集板做主机显示板做从机。这样主机根据自己的节奏发数据从机只要在每次CS拉低之后等待时钟到来即可。这里有个容易被忽略的点**从机虽然不产生时钟但它同样需要配置SPI外设而且必须提前初始化好。**我见过不少新手把从机的SPI完全交给“被动接收”连外设都没开结果自然是一帧数据都收不到。从机的SPI外设必须处于启用状态只是它不会主动输出SCLK而已。2.2 时钟极性和相位必须一致Mode 0不是随便选的SPI通信里最容易出问题的就是CPOL和CPHA不匹配。CPOL决定空闲时SCLK的电平CPHA决定数据在哪个边沿被采样。两个参数组合出四种模式SPI模式CPOLCPHA空闲时钟电平采样边沿Mode 000低电平上升沿Mode 101低电平下降沿Mode 210高电平上升沿Mode 311高电平下降沿大多数SPI从设备默认支持的就是Mode 0STM32和STM32之间互联用Mode 0最简单。如果你用的是现成的传感器模块或者Flash芯片一定要去查数据手册里的时序图确认它在哪个边沿采样数据。极性和相位配错的表现非常典型能偶尔收到数据但内容全是乱的而且你很难从逻辑上推断出错在哪。我在做这个例程时一开始就老老实实选了Mode 0两块板子的CubeMX配置里保持一致省去了后面排查的麻烦。2.3 接线细节地线不共神仙难救直接把两块板子的GND连在一起是必须的但很多人会忽略这点。SPI是同步通信接收方判断SCLK的上升沿/下降沿需要一个共同的参考电位。如果两块板子各自用独立的电源GND又不连通那主机的SCLK和从机的SCLK之间可能有很大的电压差轻则数据错乱重则烧毁IO口。我见过有人用两个USB口分别给两块板子供电结果死活通信不上最后发现是GND没接——这个问题在SPI里比UART更致命因为UART的起始位容忍度相对高一些。还有一点如果你手头只有杜邦线尽量让SCLK、MOSI、MISO三根线长度接近避免信号反射导致波形畸变。低速1Mbps以下情况下杜邦线完全够用但如果你把速率拉到18Mbps甚至更高就必须考虑等长走线和阻抗匹配了。3. CubeMX初始化时的关键配置项从机模式远比你想的讲究3.1 片选信号该用硬件NSS还是软件控制这是我在这个例程里纠结最久的一个点。STM32的SPI外设支持两种NSS工作方式硬件NSS由外设自动控制和软件NSS由GPIO手动控制。很多人看到“硬件NSS”就觉得更靠谱实际用起来却常常被坑。硬件NSS在主机模式下会自动拉低CS、发送完一帧再拉高看起来非常完美。但它有一个隐藏问题从机模式下NSS引脚的电平会直接影响SPI外设的从机选择状态如果你的MCU恰好没有专用的NSS引脚映射到目标IO或者你希望CS信号晚一点拉低、早一点拉高比如做多字节连续传输硬件NSS就不够灵活。我的方案是主机和从机都用普通GPIO模拟CS控制SPI外设本身配置为软件NSSSSM1SSI1。好处有三点CS的拉低和拉高完全由代码控制想什么时候发就什么时候发不会因为外设自动控制产生意外字节。主机和从机的GPIO可以随便选不用受硬件NSS引脚的映射约束。做多字节帧传输时可以在开始前把CS拉低传完整个缓冲区再把CS拉高避免每传一个字节CS就跳一次。注意软件NSS模式下从机仍然需要把NSS配置为输入模式吗不一定。CubeMX里如果选择的是软件NSSNSS引脚不再作为片选输入使用而是通过SPI-CR1里的SSI位来模拟片选状态。所以从机端只要软件置位SSI为1它就一直处于“被选中”状态实际的CS信号完全由主机端的GPIO控制。3.2 主从机的速度等级匹配主机可以配置较高的时钟频率但从机如果跑得太低比如主机输出SCLK频率远超过从机的SPI外设最大时钟从机就会丢数据。STM32F103的SPI最大时钟是PCLK的二分频我这里PCLK1是36MHzSPI1挂在APB2上则是72MHz。我在主机和从机上都把波特率分频设为7272MHz/721MHz两边配置一致从机完全跟得上。另外要注意从机的SPI时钟频率并不是自己配置出来的它只是被动接收主机的SCLK。所以CubeMX里从机的波特率分频设置其实不直接影响通信但最好也按相同速率配置这样在对调主从角色或者做环回测试时代码不用改来改去。3.3 数据长度、帧格式与MSB/LSBSTM32F1系列SPI支持8位或16位数据帧。我的例程用8位数据帧这也是最常用的配置。如果你要传的是float之类的多字节数据可以一个字节一个字节地发接收端再拼接不必非得用16位模式。数据格式建议统一为MSB First这是SPI最常见的传输顺序如果主机和从机一个MSB一个LSB数据会整个倒过来。还有一个非常隐蔽的坑从机模式下当主机把CS拉高之后SPI从机的接收缓冲区里可能还残留着上一帧的最后一个字节。如果你在CS上升沿之后立刻去读DR寄存器有可能读到的是旧数据。我会在主循环里通过检查RXNE标志来读取并且每次开始新一帧传输前先清一下接收缓冲区。4. 主从通信的发送与接收逻辑从机别急着发数据4.1 从机第一个字节怎么发这是最容易卡死的地方做从机最经典的问题是主机在CS拉低后立刻开始输出时钟从机如果此时还没准备好要发送的数据那它发给主机的就全是0xFF或者上一次的残留数据。解决思路有两种。第一种是从机提前准备好要回的数据在CS下降沿主机拉低CS的中断里就把第一个字节写入DR寄存器这样主机发出第一个SCLK时数据已经躺在移位寄存器里了。第二种是主机发送特定的命令字节来触发从机响应从机收到命令后才更新发送缓冲区。我的例程采用了第二种思路理由很简单从机的数据不是固定不变的它需要根据主机请求来更新状态。所以通信流程设计成这样主机拉低CS发送命令字节比如0xA5表示“请求从机状态”。从机收到0xA5后向DR寄存器写入当前状态字节。主机继续发送一个填充字节0x00作为时钟驱动同时读出从机返回的状态。主机拉高CS完成一次交互。这里最关键的是第3步SPI是全双工协议每发一个字节同时也会收到一个字节。如果你只想读取从机数据主机也必须持续输出SCLK最简单的方式就是发送0x00或者0xFF。很多人在这一步卡住从机明明把数据写进了DR但主机就是读不到——原因就是主机在发送完命令字节之后就不再输出时钟了从机的数据根本没机会被移位出来。4.2 用中断还是DMA我的例程数据量不大每次交互只有几个字节所以用中断收发就够了。CubeMX里SPI1和SPI2都开启了全局中断发送用HAL_SPI_Transmit_IT接收用HAL_SPI_Receive_IT。这里有个值得注意的细节HAL库的HAL_SPI_Transmit_IT在发送完成后会调用回调函数但从机模式下如果你想一边发一边收最好用HAL_SPI_TransmitReceive_IT。这个函数会同时处理发送和接收避免你只调用Transmit时不产生RXNE标志导致收不到数据。我在例程里就是主从两端都调HAL_SPI_TransmitReceive_IT主机发命令同时读回数据从机自发自收地回填状态。DMA是后来的优化方向。如果你的数据量大比如传输一整个数组的ADC采样结果建议改用DMA但要注意DMA的中断优先级和SPI中断的配合不然容易发生数据覆盖。小数据量用中断完全够没有必要一上来就上DMA反而增加调试难度。4.3 收发缓冲区大小与帧结束判断SPI没有UART那样的帧结束符概念接收方只能靠CS的上升沿来判断一帧结束。我在主机端维护了一个rxBuffer[8]每次CS拉低到拉高之间只发固定长度比如8字节的数据从机也按8字节接收。这种做法牺牲了灵活性但换来了协议极简和极高的稳定性。在主机的发送循环里我会在每发完一帧后加一个小的延时比如1ms目的是给从机留出处理时间。如果你连续高速发送从机CPU来不及处理RXNE中断HAL库的接收缓冲区就会出问题。1ms的延时在大多数场景下完全可以接受。5. 主从机具体代码实现可以直接抄的稳定版本5.1 主机端核心代码发送命令并读取从机状态主机初始化部分用CubeMX生成重点看发送逻辑。我定义了一个结构体来封装一次完整的主从交互// 主机端发送命令并接收从机回复 void SPI_Master_Exchange(uint8_t cmd, uint8_t* rxData, uint16_t len) { uint8_t txBuffer[16]; uint8_t rxBuffer[16]; uint16_t i; // 填充发送缓冲区第一个字节是命令其余是填充 txBuffer[0] cmd; for (i 1; i len; i) { txBuffer[i] 0x00; } // 拉低CS开始一帧 HAL_GPIO_WritePin(SPI_CS_GPIO_Port, SPI_CS_Pin, GPIO_PIN_RESET); // 使用TransmitReceive同时收发 HAL_SPI_TransmitReceive(hspi1, txBuffer, rxBuffer, len, 100); // 拉高CS结束一帧 HAL_GPIO_WritePin(SPI_CS_GPIO_Port, SPI_CS_Pin, GPIO_PIN_SET); // 拷贝接收数据到外部缓冲区 for (i 0; i len; i) { rxData[i] rxBuffer[i]; } }主循环里每500ms调用一次这个函数命令用0xA5接收长度设为4字节while (1) { uint8_t status[4]; SPI_Master_Exchange(0xA5, status, 4); printf(Slave status: %02X %02X %02X %02X\r\n, status[0], status[1], status[2], status[3]); HAL_Delay(500); }注意这里HAL_SPI_TransmitReceive传递的是数组首地址调用时会同时产生SCLK发送txBuffer里的数据并把接收到的数据存到rxBuffer中。整个过程是同步阻塞的直到4字节全部收发完成才会拉高CS。5.2 从机端核心代码中断方式接收命令并回复从机的代码稍微复杂一点因为它需要响应主机的命令并填充回复数据。我用了一个共享的状态变量在收到特定命令后更新volatile uint8_t slave_status 0x00; volatile uint8_t rx_cmd 0x00; volatile uint8_t tx_data 0x00; volatile uint8_t spi_rx_complete 0; // 中断回调每次SPI收发完成时调用 void HAL_SPI_TxRxCpltCallback(SPI_HandleTypeDef *hspi) { if (hspi-Instance SPI1) { // 注意这里HAL库在TransmitReceive完成时会调用TxRxCpltCallback // 我们需要根据协议确定当前收发的字节位置 } }这里有个细节要说明如果用HAL_SPI_TransmitReceive_IT每次调用只能处理指定长度的数据从机不知道主机什么时候会发命令所以从机在主循环里要持续处于“等待接收”状态。我的做法是从机先调用一次HAL_SPI_TransmitReceive_IT接收4字节同时发送4字节填充数据等回调完成后更新状态然后再次调用形成循环接收。// 从机端持续等待主机的命令帧 void SPI_Slave_Prepare(void) { uint8_t txBuf[4] {0x00, 0x00, 0x00, 0x00}; uint8_t rxBuf[4] {0x00, 0x00, 0x00, 0x00}; // 用TransmitReceive能同时保证发送缓冲区和接收缓冲区都被处理 HAL_SPI_TransmitReceive_IT(hspi1, txBuf, rxBuf, 4); }如果希望更高效可以在从机中断里直接填回复数据。不过我的经验是小数据量下中断回调里更新状态变量就够了别在中断里做复杂的逻辑容易把SPI时序拖垮。5.3 回调函数的准确写法HAL库里SPI相关的回调函数不止一个很多新手搞混。我用的是HAL_SPI_TxRxCpltCallback对应HAL_SPI_TransmitReceive的完成中断。如果你用的是单独的Transmit或Receive则分别对应HAL_SPI_TxCpltCallback和HAL_SPI_RxCpltCallback。在一个点很重要不要同时在中断回调里再次调用TransmitReceive除非你非常清楚自己在做什么。在回调函数里初始化下一次接收容易造成重入问题最好通过一个标志位让主循环去启动下一次接收。我的代码里用了spi_rx_complete标志void HAL_SPI_TxRxCpltCallback(SPI_HandleTypeDef *hspi) { if (hspi-Instance SPI1) { // 从rxBuf中解析命令 rx_cmd rx_buff[0]; if (rx_cmd 0xA5) { slave_status 0x5A; // 模拟一个状态值 } spi_rx_complete 1; } }主循环判断标志while (1) { if (spi_rx_complete) { spi_rx_complete 0; // 准备下一次接收 SPI_Slave_Prepare(); // 处理刚收到的数据... } }5.4 初次测试的迷你协议先跑通再扩展建议第一次测试时不要直接传业务数据先传固定格式的命令和状态验证链路通畅后再扩展。我的协议只有两个元素命令字节0xA5表示状态查询状态字节从机收到查询后返回0x5A如果主机能打印出5A说明SCLK、MOSI、MISO、CS四条线全部工作正常。之后再扩展成发送数组、浮点数、结构体都是在现有骨架上加内容出问题时也容易定位。6. 实际测试中遇到的典型问题从机没反应、数据错位、干扰6.1 排查链路从波形到寄存器一步步缩小范围第一次上电测试时主机串口打印的全是FF——从机完全没有回应。当时我不确定问题是出在从机没初始化好还是硬件接线问题只能一步步排查。我的排查链路大概是这样的先排除基本接线错误用万用表测SCLK、MOSI、MISO、CS四根线的通断确认杜邦线没有松动或插错位置。这一步看似低级但确实解决过好几次问题。用逻辑分析仪抓波形把逻辑分析仪接在主机的SCLK和MOSI上触发CS下降沿看主机发出的时钟是否符合1MHz。如果时钟有毛刺或者频率完全不对先查CubeMX分频配置。检查从机SPI外设是否使能在调试模式下暂停从机看hspi1.State是否为HAL_SPI_STATE_READY同时确认从机的GPIO模式是否配成了AF_PP复用推挽输出。检查从机的中断是否真正触发在HAL_SPI_TxRxCpltCallback里设断点如果主机发数据但从机没进回调说明从机的SPI中断没配置好或者中断优先级被别的中断抢占且未正确处理。最终用寄存器直接读如果HAL库调用正常但数据不对直接在从机调试窗口里读SPI1-DR判断SCLK是否真的把数据移进来了。这套链路走下来大部分问题都能定位到具体环节。我遇到的最坑的一个问题是从机中断里调用了printf导致系统卡死之后所有回调函数里一律不放重负载操作。6.2 常见错误列表与对策错误现象可能原因解决办法主机收到的全是0xFF从机发送缓冲区没填充或从机SPI未初始化从机在接收前先往DR里写默认数据首字节丢失从机未在CS下降沿前准备好数据用CS下降沿中断提前写DR或采用命令触发模式数据错位收到的是上次的值帧同步问题CS拉高时机不对确认每次收发长度一致收完一帧再拉高CS偶尔乱码时钟极性和相位不匹配检查主从机CPOL/CPHA是否一致从机卡死中断回调里做了耗时操作回调只置标志位具体处理放主循环速率高时丢数据杜邦线过长或SCLK边缘不够陡降低速率或换短线、双绞线6.3 为什么速率不是越快越好很多人一上来就想用最高速率觉得18Mbps才够看。但对于双板杜邦线互联过高的速率反而会带来信号完整性问题。1Mbps下SCLK的周期是1us波形保真度很高几乎不会误码。当你把速率提到9Mbps以上杜邦线之间的电容耦合、串扰、地弹都会开始影响信号表现就是数据偶发错位。合理做法是先以1Mbps跑通逻辑再逐步提高倍率每提高一档就验证一次通信稳定性。如果你确实需要高吞吐建议改用FDCAN或者SPIDMA配合同时缩短连接线长度。7. 从机做“主动上报”的可能性SPI天生主从别硬改成双向平等不少人在做完主从通信后会问能不能让从机主动发数据给主机答案是不能直接做SPI的时序决定了一切数据交换都要以主机产生的SCLK为前提。但你可以用变通方式第一根额外的IO线作为“从机请求线”。从机要上报数据时先把这个IO拉高主机检测到后主动发起SPI读取。本质上还是主机发起传输但从机拥有了“通知”能力。这种设计在传感器节点、从设备状态上报场景里很实用。如果确实需要两块板子完全平等地双向通信SPI并不是最合适的协议。UART或者CAN天生就是多主架构收发双方各自有独立的时钟不用等对方发起传输。我之前在博客里写过UART双机通信的例程如果需要做实时双向数据交换还是换UART更省心。还有一种场景需要特别注意两块STM32通过SPI互联如果其中一方复用了同一个SPI外设的其他功能比如读Flash、驱动屏幕需要做好互斥访问。我在扩展例程时把主机端的SPI分时复用先读完传感器再切换CS到从机保证同一时刻只有一个从设备在总线上。SPI总线上多个从机共用一个SCLK/MOSI/MISO靠不同的CS来选中这个机制理解透了你就可以把SPI从“两块板的通信”扩展到“一主多从的分布式采集系统”。8. 给后来的实践者接线、波形、调试三步走的经验总结最后分享几条只有实际跑过才会体会到的经验。第一GPIO的复用配置要检查两遍。CubeMX生成代码后SCLK、MOSI、MISO脚位会被自动配置成复用推挽输出或浮空输入但如果你在同一组GPIO上还开了其他外设很容易冲突。以PB13、PB14、PB15SPI2为例这三个引脚同时也可以作为I2C或USART的复用脚CubeMX会警告引脚复用冲突这时候别硬改代码先回到CubeMX重新规划引脚。第二CS的GPIO模式要设置为推挽输出速度设为High。虽然CS只是电平信号但给足驱动能力和翻转速度能减少边沿失真。有些教程推荐开漏输出加外部上拉在标准SPI从机场景下没必要推挽输出用起来最直接。第三逻辑分析仪是必备工具。如果条件允许不要只靠串口打印判断数据对不对直接抓SCLK、MOSI、CS三条线的波形一眼就能看出时钟极性、相位、帧长度是否有问题。我遇到过一次诡异现象主机发出的SCLK频率是配置值的一半后来发现是CubeMX里PLL倍频配置不对导致APB2总线频率比预期低这个问题如果不看波形很难发现。第四从机的发送缓冲区初始值不要全填0xFF填0x00更好排查。如果主机读回来的是全0x00至少能确定SCLK把数据移进去了只是从机回的数据是0如果全0xFF可能是MISO线悬空或从机根本没驱动。调试时用有区分度的初始值能少走很多弯路。第五约定好CS的释放时机。我在协议里固定“发送方必须在所有字节发送完毕且确认接收方处理后才拉高CS”。如果你提前拉高CS从机可能还在处理中断数据直接从移位寄存器里丢出来。对于一些要求严格的场景甚至可以在拉高CS之后再延时几微秒再发起下一帧给从机足够的处理时间。这套主从通信例程我后来扩展成了一个小型数据采集系统主机读取三个传感器并通过SPI发给从机从机做OLED显示和异常告警。整个系统在1Mbps下跑得非常稳定没有出现过一次数据错位。如果你也打算做类似的双板项目建议按照上面的步骤一步步来先把最简链路跑通再去叠加业务逻辑。遇到问题时记住一个原则从波形出发定位问题而不是靠猜。本文还有配套的精品资源点击获取