SPI总线实战：从时序模式到多从机调试的RT-Thread实践

做嵌入式工控的人，几乎都有被SPI“上一课”的经历。我前几天调试一块基于GD32H759的采集板，Flash读写一切正常，换到挂在同一条总线上的磁编码器时，数据突然开始乱跳，排查到最后才发现是片选时序和模式配置交叉踩坑。这篇是这个系列的第六篇，正好把SPI从底层时序、RT-Thread框架到工程排错完整梳理一遍，希望能帮你在自己项目里少走几步弯路。

SPI这名字听起来简单，就是四根线的主从通信（SCK、MOSI、MISO、CS），但真到工控现场，波特率余量、从机切换速度、DMA与Cache一致性、片选策略，每一处都是可以让人调半天的暗坑。别慌，这篇就从设计思路讲到落地代码，最后附上我自己实测踩过的坑，尽量让你一次看明白。

1. 整体设计与方案选型：为什么这块板子选硬件SPI而不是软件模拟

1.1 工控场景对SPI的核心需求拆解

GD32H759这个芯片，主频高、外设接口丰富，跑RT-Thread之后，拿来接外设是很顺手的玩法。但工控场景里SPI外设的典型需求从来不是"能通信就行"，而是稳定、可复现、好排查。我把这套板子的外设列出来你就会发现，SPI这条总线几乎承担了所有高速点的数据搬运：

• 板上有一颗W25Q64 8MB SPI Flash，用来存运行日志、配置参数和OTA固件备份，每次掉电前要把关键数据刷进去，不能丢。
• 另外挂了一个MT6816磁编码器，输出绝对角度，用来做电机闭环的位置反馈，数据要持续以固定周期读，不能有抖动。
• 后面还预留了SPI屏幕接口和ADC采集扩展口，留给后续升级。

这些外设对SPI的要求完全不同：Flash读写是突发大块数据，编码器是高频小数据，屏幕是连续大流量，ADC是单次触发。同一个SPI控制器要兼顾好几种工作模式，这比我以前用软件模拟SPI来驱动一个传感器要复杂得多。

1.2 为什么最终选了硬件SPI而非GPIO模拟

很多单片机项目里，软件模拟SPI也能跑，因为简单、引脚任意分配、代码一写就行。但当我把系统跑在RT-Thread上，配合定时器中断、DMA传输，再叠加多个SPI从设备之后，软件模拟带来的问题就非常具体了：

• 时序抖动：模拟SPI依赖关中断或忙等来保证时钟相位，但RT-Thread里，关中断是不能长时间容忍的，否则其他实时任务会超时。而开中断又可能让SCK波形中间被任务调度打断，逻辑分析仪上一看就是毛刺。
• CPU占用：块传输数据的时候，每个字节都要CPU去翻转引脚和移位，传输几百KB数据，CPU基本干不了别的，这在工控板上是不能接受的。
• 多从机切换难：模拟SPI往往只有一个全局状态，总线上挂多个从机时，切换片选和模式很痛苦。

因此，这版方案从一开始就锁定了GD32H759片上硬件SPI，只做引脚初始化和RT-Thread设备注册，所有字节搬运交给硬件和DMA，软件只关心缓冲区头尾。

1.3 同一总线挂多个从机：模式不可能只有一个

SPI总线上挂多个从机这事，很多教程都默认所有设备用同一个模式（常见的Mode 0：CPOL=0，CPHA=0）。但只要你同时接Flash和编码器，就会发现问题：W25Q64通常在Mode 0或Mode 3都能工作，MT6816的手册推荐的却是Mode 3（CPOL=1，CPHA=1）。同一根SCK，不同的时钟极性和采样沿，硬件上只有一套SPI控制器，怎么切？

答案就是"每次传输前重配模式，切换片选后立即更新寄存器"。RT-Thread的SPI框架恰恰支持在每次传输前调用配置接口来指定模式，这就比裸机时代舒服很多，框架里已经把这个逻辑塞进了传输函数里，从机枚举和配置管理简单一大截。

这也是我决定在RT-Thread上做这版SPI驱动的原因：不是因为它"新潮"，而是因为设备模型已经把多从机、动态模式切换、中断处理这些脏活杂活提前规范化了，我们能专心写应用逻辑。

2. SPI协议核心细节：时序模式、极性与相位，不搞懂后面全是坑

2.1 四种模式是怎么来的：CPOL和CPHA到底改了谁

SPI之所以有四种模式，本质就是两个布尔开关的组合：时钟极性（CPOL）和时钟相位（CPHA）。我把它们的作用说直白一点：

• CPOL决定SCK空闲时是高电平还是低电平。空闲低叫CPOL=0，空闲高叫CPOL=1。
• CPHA决定数据是在SCK第一个边沿采样还是第二个边沿采样。CPHA=0是第一个边沿，CPHA=1是第二个边沿。

用生活里的类比就是：两个人配合搬东西，一个人打拍子（SCK），另一个人看拍子动作来递东西（MOSI/MISO）。CPOL决定了"不搬的时候拍子举着还是垂着"，CPHA决定了"你是听第一下拍子响就递，还是听第二下响再递"。两下没对上，东西就掉地上了——数据就是错的。

组合起来就成了Mode 0到Mode 3，每次跟一颗新芯片对接，第一件事永远是翻手册确认它工作在哪个模式。别看手册里最小电气参数一大堆，模式能定下来，通信就成功一半了。

2.2 为什么时钟极性不一致会导致稳定工作一秒后突然乱码

模式不匹配的现象很迷惑人：有时刚上电通信正常，跑几秒钟突然出现错数据，然后又恢复，让人怀疑是接触不良。实际上是因为从机芯片内部有个上电初始化的过程，刚开始主从双方处于某种"巧合对齐"的状态，一旦内部逻辑切换或数据包边界对齐丢失，相位错误就导致采样点落在数据翻转的瞬间。

MT6816这个片子我印象很深，它明确要求Mode 3。如果你板子上其他外设是Mode 0，忘了在切换后重新配置，通信看起来能出数据，但是偶发跳变。抓到示波器上对比空闲电平和采样点就能破案。这块在RT-Thread里就是每次访问外设前把spi_mode配好，框架会帮你写到寄存器里，不要偷懒配一次就以为全总线统一了。

2.3 字节序、位顺序和CS最小间隔这些隐藏参数的细节

模式之外，SPI通信还有几个藏在数据手册深处、但直接影响能否收到正确数据的参数：

• 字节序：大部分器件的SPI寄存器先发高位（MSB first），但也有少数用LSB first。写Flash的WRITE命令时，命令字节一般是MSB first，但你发现读回的数据全是反着的位顺序，就要检查这里。
• CS最小间隔：很多从机要求CS在两次片选事务之间保持高电平一段时间，最短可能有几百纳秒甚至几微秒。如果连续快速访问两个从机，主控在CS拉低之前没留够间隔，从机内部状态机就可能没复位，导致响应错乱。
• 数据保持时间：SCK边沿采样后，数据线还要保持一小段时间才允许变化，高频通信时这一项容易被忽略，拉高传输速率后开始出错，多半是它。

在RT-Thread里，这些参数通常由驱动内部实现，但如果你用的是框架的通用SPI设备接口，有些高要求的从机就得自己用"自定义传输控制块"来掌控CS释放时机和位宽，这也是为什么RT-Thread的SPI框架里会留一个自定义控制字段的原因。

3. RT-Thread SPI设备框架：分层架构、配置步骤与驱动实现

3.1 框架分层：设备层、驱动层和控制器层各管什么

RT-Thread的SPI框架分得很清楚，从下往上依次是：

• 控制器驱动层：负责GD32H759的SPI硬件寄存器操作，包括初始化时钟、配置引脚MUX、设置波特率、模式，以及触发DMA收发。
• 总线核心层：负责SPI多从机的管理、总线锁、模式切换调度。它维护了一张设备链表，每次传输时把目标从机对应的模式参数写入。
• 设备驱动层：针对具体从机设备的驱动，比如W25Q64的驱动、MT6816的驱动，它们只做"发给FPGA读命令、解析返回数据"这类逻辑，不直接碰寄存器。

这个分层最大的好处我举个例子：如果后天把W25Q64换成W25Q128，设备驱动层的Flash代码基本不用改，只要改容量参数和ID识别逻辑。因为硬件差异已经被框架隔离了。模块化调试的时候，每一层都可以单独验证。

3.2 基于GD32H759的SPI驱动裁剪与注册步骤

我用的是RT-Thread Studio环境，添加SPI驱动主要分几步：

第一步：在menuconfig里使能SPI外设，打开BSP下的SPI驱动，选上SPI0或者SPI1对应你自己的引脚。

# 这里以RT-Thread env为例，实际在Board Config里勾选即可 menuconfig --enable-drivers-spi

如果你在Studio里操作就更直观，直接双击芯片配置页面，把SPI勾上，然后检查PinMux定义：确认SPI_SCK、SPI_MOSI、SPI_MISO、SPI_CS分别对应到了GD32H759的哪几个GPIO口，并且确保这几个口没被其他外设占用，不然后面焊线的时候就很玄学了。

第二步：调用rt_hw_spi_device_attach来把总线注册到框架。

#include <rtdevice.h> static int hw_spi_device_attach(void) { rt_err_t ret; ret = rt_hw_spi_device_attach("spi0", "spi00", SPI_CS0_PIN); if (ret != RT_EOK) { return -RT_ERROR; } return RT_EOK; } INIT_BOARD_EXPORT(hw_spi_device_attach);

这段代码含义是：在名为"spi0"的总线上挂一个叫"spi00"的设备，片选引脚是SPI_CS0_PIN。之后应用层就能通过rt_device_find("spi00")找到这个设备来发数据了。

第三步：根据需要动态注册更多从机，比如我再加一个编码器设备：

rt_hw_spi_device_attach("spi0", "spi01", SPI_CS1_PIN);

总线上可以挂多个从机，只要片选引脚不同，框架会帮你管切换，前提是每次传输前设备节点里配置的模式和速率是正确的。

3.3 具体外设驱动：W25Q64的读写流程示例

驱动里最常用到的一个操作是读Flash ID，既能验证通信，也能拿到容量信息。我用rt_device_find找到设备后，把配置结构体准备好，然后发起传输。

#include <rtdevice.h> #include <spi.h> struct spi_device *flash_dev; struct rt_spi_config cfg; flash_dev = (struct spi_device *)rt_device_find("spi00"); if (!flash_dev) { rt_kprintf("spi00 not found\n"); return -RT_ERROR; } cfg.data_width = 8; cfg.mode = RT_SPI_MASTER | RT_SPI_MODE_0 | RT_SPI_MSB; cfg.max_hz = 50 * 1000 * 1000; // 根据PCB走线和器件手册降额 rt_spi_configure(flash_dev, &cfg);

这里特别注意max_hz，不是标称50MHz就真跑50MHz，还要看GD32H759的时钟树分频、PCB走线长度和Flash本身手册。我发现跑到40MHz以上后，读回来的ID偶尔不稳定，降到20MHz后就一直没问题，可能跟我的杜邦线太长有关，反正能稳就绝不挑战极限。

读ID的传输代码：

static rt_uint8_t read_flash_id(void) { rt_uint8_t cmd[4] = {0x9F, 0x00, 0x00, 0x00}; rt_uint8_t buf[4] = {0}; struct rt_spi_message msg; msg.send_buf = cmd; msg.recv_buf = buf; msg.length = 4; msg.cs_take = 1; msg.cs_release = 1; rt_spi_transfer_message(flash_dev, &msg); return buf[1]; // 根据W25Q64返回格式，第二个字节是MID }

这段代码用了rt_spi_transfer_message，把命令发出去的同时收4个字节回来。cs_take和cs_release都置1，表示一次传输自动拉低CS、结束后自动拉高，省得我手动画CS引脚。

3.4 MT6816编码器：指定模式后高频读取的稳定姿势

MT6816和Flash不同，它是带角度计算功能的芯片，读取时序更敏感。我用的读取方式很简单，通过SPI发0x00读寄存器，芯片返回3个字节的角度数据。关键是模式必须设成Mode 3，否则数据不稳定。

cfg.mode = RT_SPI_MASTER | RT_SPI_MODE_3 | RT_SPI_MSB; cfg.max_hz = 10 * 1000 * 1000; // 编码器不需要太高速度 rt_spi_configure(enc_dev, &cfg);

这是一个很典型的场景：同一个控制器上，Flash用Mode 0，编码器用Mode 3，每次切换设备时框架都会重新应用mode设置。实际用下来，只要驱动里没有偷懒少配置，编码器数据可以做到连续读取几千个小时不出一个错位。还有一个细节：编码器数据是多字节连续的，必须一次性读完整包，不能用两条短传输拼凑，否则CS中间的拉高会让芯片内部FIFO错位。

3.5 DMA与中断结合：SPI收发不占CPU的实现方式

高频大块数据搬运，比如读Flash的整页数据，再快的硬件SPI如果靠CPU逐字节读，也扛不住。我在这块上把DMA加上，CPU只负责把缓冲区地址告诉DMA，传输完成后进中断IP。

RT-Thread的SPI框架对DMA的接入方式取决于BSP驱动是否实现了DMA适配，GD32H759这套库里目前是可以配置的。核心思路是：

// 伪代码示意 rt_uint8_t tx_buf[1024]; rt_uint8_t rx_buf[1024]; struct rt_spi_message msg; msg.send_buf = tx_buf; msg.recv_buf = rx_buf; msg.length = 1024; msg.cs_take = 1; msg.cs_release = 1; rt_spi_transfer_message(flash_dev, &msg); // 如果驱动实现了异步API，可以注册回调，在传输完成后得到通知

这里有一个M7内核特有的陷阱：数据缓存一致性。GD32H759带D-Cache，如果开启了，CPU写tx_buf后DMA去读，可能读到的还是Cache里的旧数据，或者DMA写rx_buf后CPU去读，读到的是Cache里的过期内容。这个坑我一开始完全没意识到，查了很久才发现。解决办法是把DMA缓冲区放进非Cache区域，或者在传输前后做Cache Clean和Invalidate操作。

RT-Thread默认工程不一定开D-Cache，有些版本的BSP没有使能I-Cache和D-Cache，所以很多人没遇到这个问题。但一旦你真的开启D-Cache去跑DMA，就一定会遇到。我在正式驱动里专门为SPI DMA分配了一片非Cache内存，从那以后传输再没有出现过莫名数据错乱。

4. 硬件设计与接线：片选策略、飞线与抗干扰，影响稳定的隐形成本

4.1 硬件片选与软件片选的选择逻辑

SPI挂多个从机时，每个从机的CS引脚怎么控制，两种常见做法是：

• 硬件片选：由SPI控制器自己控制CS脚，传输开始时自动拉低，结束自动拉高。优点是不占CPU，时序精准；缺点是有些片子的CS时序要求和硬件自动行为无法完全对齐。
• 软件片选：把CS映射成普通GPIO，传输前手动拉低，完事手动拉高。优点是灵活，想高想低、想延后多久都行；缺点是每次操作多几步代码，且中断里切换GPIO也有一点开销。

正常来说，稳定优先的项目里，我倾向于高速大块数据传输用硬件片选，因为自动时序没有毛刺；而像编码器这类要求CS有确定保持时间的，用软件片选更放心。RT-Thread的框架对软硬件片选都有支持，软件片选时把cs_take和cs_release置0，自己用GPIO拉CS即可。

4.2 唯一的GPIO引脚冲突是怎么被发现的

这块板子设计的时候有个教训：SPI0的MISO引脚和编码器的一个PWM输出脚在PinMux上是互斥的，如果某天把外设配置打开两个功能，编译可能不报错，但运行时其中一个功能就是死的。

这类引脚冲突最隐蔽。我当时排查的方法是把所有外设的GPIO配置打印出来，对着芯片手册逐脚核对，才在板级初始化里找到了那个被占用的引脚。现在的GD32H759的RT-Thread BSP里做了引脚复用冲突检测，但如果你的外设库比较老，还是要自己留个心眼。

4.3 接线顺序、上拉电阻和电平匹配的实战经验

SPI线数不多，但连接顺序出错是最大白痴错误。我吃过一次亏：MOSI和MISO两根线在接插件上定义反了，导致主控发给从机的数据被从机当输入收到，而从机回的数据又被主控当MISO线读取，两边都发都收，通信看起来在跑，实际上全是垃圾。

接线时建议按这个顺序检查：

1. 主控MISO接到从机MISO（接收端），不是交叉连接，SPI不像UART那样需要TX-RX交叉。
2. SCK必须共地，地线一定要可靠连接，我见过SPI高速时波形糜烂，换了根粗杜邦线地线立刻稳定的案例。
3. 如果从机支持并希望IO上拉，CS和MOSI上拉到3.3V，上拉电阻4.7k到10k都可以。但MISO一般不上拉，因为可能被多从机输出形成争用。

还有电平匹配：GD32H759的供电如果按3.3V设计，SPI口一般也是3.3V，接5V器件需要电平转换。W25Q64和MT6816都是3.3V供电，接口匹配没有压力。有一些别的传感器是5V供电，SPI直连就可能烧引脚，这种场合要加转换芯片或者用电阻分压，千万别图省事。

4.4 高阻态、线与逻辑与线缆长度的界限

SPI是同步总线，但高速时钟频率对线缆长度很敏感。工控现场如果SPI走线超过20cm，尽量把速率降到5MHz以下，如果你用的是FPC排线或者手拧杜邦线，线间串扰会直接影响采样。

多从机共用一个MISO时，从机在CS无效时必须把MISO输出置为高阻态（这也是SPI协议标准要求）。如果某个从机的驱动设计不好，CS拉高后MISO还保持输出，就会和其他从机打架，总线上出现错误的电平。这块在硬件层面通常靠每个从机的CS引脚来保证片选隔离，软件层面则是访问哪个从机就只拉低对应CS。调试时只要看到波形异常，先用万用表量两个从机CS电压，多半能找到问题。

5. 常见问题与排查技巧实录：这套板子SPI部分的典型故障

5.1 问题一：Flash能读ID但写入校验失败

现象是读ID完全正常，但是写数据后读出来对不上，或者读的时候就偶尔跳几个字节。排查思路：

1. 先确认写入命令前发0x06写使能的时序，很多Flash要求每次写之前都要发写使能，如果CMD里漏了，写入被拒绝。
2. 检查状态寄存器，Flash写完后需要轮询字节(BUSY位)确认内部擦写结束，再读才能读到数据。
3. 如果轮询正常还出现偶发错位，重点看CS在指令之间是否被拉到位、以及CS释放后的时间去读状态寄存器是否太早。

我最后发现是因为RTT的传输里，两条连续消息之间CS release和CS take之间没有延时，Flash内部状态机没跟上，后来在驱动里加了个spi_delay就稳定了。

5.2 问题二：编码器角度数据偶发跳变，且和电机转速相关

MT6816的SPI数据跳变，一开始怀疑是电气干扰，但我从编码器返回的数据波形看，大概率是采样时序和总线切换的问题。电机一转，共模噪声干扰SPI波形，加上Mode配置没切干净，就会出现偶发采样错误。

处理办法：

• MT6816的SPI时钟速率降到1MHz，电机运行时稳定性大增。
• 模式必须严格Mode 3，这芯片对采样沿非常挑剔。
• 在软件上做了数据合法性校验：连续读两包角度，差超过一个阈值就丢弃重读，以防偶发抖动进闭环控制。

这算是工控项目里很通用的"数据卫生"手段了，通信不一定保证100%不丢包，但控制环需要100%可靠数据，那就得在应用层加校验。

5.3 问题三：RT-Thread启动时SPI设备找不到

如果你调用rt_device_find("spi00")返回空指针，最常见的两个原因：

• 板级初始化阶段没执行hw_spi_device_attach，或者添加了但编译时被条件宏裁剪掉了。
• 总线名和从机名不匹配。框架里总线名"spi0"，从机名"spi00"，拼写必须和attach时保持一致，少个0都找不到。

解决方法是把attach函数放在INIT_BOARD_EXPORT里，让它更早执行，并且在调用时打印总线枚举情况。我调试时喜欢先调rt_spi_bus_attach_device确认总线设备链表有东西，再调应用那层找设备，这样定位很快。

5.4 常见故障速查表

5.5 排查工具与调试方法

这一部分我着重说三样工具：

• 逻辑分析仪：跑SPI调试时，十几块钱的8通道逻辑分析仪就够了。单次抓上千字节数据，看CS下拉时刻、CLK频率、数据字节顺序，多数通信问题一眼就能看出来。
• 示波器：如果需要看波形上升沿质量、振铃和电平阈值，逻辑分析仪不够，用示波器。测SCK高电平和低电平是否达到芯片VIH/VIL阈值，以及MISO在采样点是否稳定。
• RT-Thread FinSH命令行：框架的SPI设备可以在命令行里手动执行读写命令，快速验证硬件与驱动是否就绪。不用写完整的应用代码就能测试外设，这极大简化了调试。

我用这套组合拳排查过至少三个不同主控的SPI问题，逻辑分析仪抓时序、示波器看边沿、FinSH跑自测，基本上没有过夜调试的难题。

6. 实操记录与性能实测：一次完整的数据搬运流程

6.1 实测环境与参数记录

为了给你一个可以直接参考的坐标，我列一下我这块板的实际参数：

实际跑起来，一次读取编码器3字节耗时大约在20us以内，包含CS拉低、传输、CS拉高，主循环里完全看不出开销。Flash整页256字节读取，DMA完成在100us级别，也不影响其他任务。

6.2 代码示例：一个完整的RT-Thread SPI读传感器任务

我写一个真实任务函数的骨架，展示SPI读取编码器角度并发布到消息队列的全过程：

#include <rtthread.h> #include <rtdevice.h> #include <string.h> static struct rt_spi_device *enc_dev; void encoder_thread_entry(void *parameter) { rt_uint8_t cmd[3] = {0x00, 0x00, 0x00}; // 编码器读角度指令可能是这样 rt_uint8_t buf[3] = {0}; struct rt_spi_message msg = {0}; rt_uint16_t angle_raw = 0; enc_dev = (struct rt_spi_device *)rt_device_find("spi01"); if (!enc_dev) { rt_kprintf("find spi01 failed\n"); return; } // 配置编码器设备 struct rt_spi_configuration cfg; cfg.data_width = 8; cfg.mode = RT_SPI_MASTER | RT_SPI_MODE_3 | RT_SPI_MSB; cfg.max_hz = 1 * 1000 * 1000; rt_spi_configure(enc_dev, &cfg); while (1) { cmd[0] = 0x00; msg.send_buf = cmd; msg.recv_buf = buf; msg.length = 3; msg.cs_take = 1; msg.cs_release = 1; if (rt_spi_transfer_message(enc_dev, &msg) == RT_EOK) { angle_raw = (buf[1] << 8) | buf[2]; // 发送到消息队列或直接控制逻辑 } rt_thread_mdelay(1); // 1kHz 读取周期 } }

这里有个经验：rt_spi_transfer_message返回成功时，仅仅表示SPI控制器层面的传输完成，不代表数据内容有效。要在应用层再做合理性判断，比如角度值不能突变过大，或者包尾的校验字节要对得上。

6.3 开启DMA和Cache后我踩过的一个经典坑

这块板子开启D-Cache后遇到过一次很隐蔽的问题。一开始我只需要读Flash ID，没开DMA，直接使用寄存器轮询方式，一切正常。后来为了快速读整块Flash，启用了DMA，数据就开始随机出错。

原因就是之前说的Cache一致性。具体表现是：CPU往tx_buf里填了数据，但写操作停在Cache里，DMA直接去读内存，读到的可能是旧数据；反过来DMA往rx_buf写好了数据，但CPU第一次读时Cache还是空的或者旧的，读到的不是DMA刚搬进来的内容。

解决办法两条路：

1. 把SPI DMA缓冲区定义在非Cache的SRAM区域，这样所有读写都直接穿透Cache，不经过缓存。
2. 每次DMA传输前做Cache Clean，传输完成做Cache Invalidate，保证Cache与内存同步。

RT-Thread和GD32的HAL库里其实都提供了对应接口，关键在于你有没有想到这个层面。这类M7内核的通用坑，尤其在高性能MCU上跑SPI DMA时，几乎必然遇到，我建议你在驱动设计阶段就考虑好缓冲区放置策略，而不是出了问题才补救。

7. 工程经验总结与项目扩展建议

7.1 几个影响SPI稳定性的关键习惯

做了这么多SPI调试，我认为最重要的习惯是这几点：

第一个习惯：任何外设第一次接入，先把时钟降到手册允许的1/4或更低，验证通信正确后再逐步提速。总能在某个速度点发现问题，这个过程能帮你掌握板和线的极限。

第二个习惯：每次修改外设配置（模式或速率）后，不能只发一次命令验证，要多跑几千次连续通信，统计错误率。偶发错误在工控项目里是不可接受的，哪怕千分之一也不行。

第三个习惯：在RT-Thread里，给每个SPI设备配置独立互斥访问。不然两个线程同时发消息到同一个SPI设备，总线数据必然交错。RTT的SPI框架里传输函数本身带总线锁，但如果你跨设备访问同一个控制器，还是要保证应用层的同步逻辑正确。

7.2 后续可以在SPI框架上扩展的方向

SPI这块目前在板上的应用只是初级水平，后续还可以扩展的东西我没有全做完，但思路已经清晰：

• SPI屏驱动：很多SPI屏要显存，低端屏可以开一个小帧缓冲。帧率要求不高的情况下，直接DMA刷屏即可。
• 多SPI控制器并行：如果Flash和编码器分开挂在两个SPI控制器上，就能同时访问互不干扰，还能降低总线压力和调度延迟。
• SPI从机模式：GD32H759可以配置为SPI从机，用于和主控板通信。这种场景调试要从时序仿真入手，我在手册里看到官方有相关例程，但还没在实战中用完善。
• 基于SPI的Modbus网关：有些工控采集模块通过SPI接到主控，做协议转换上送到RS485总线，这条路也可以扩展。

最后我个人的体会是：SPI本身协议不复杂，真正的复杂度在于现场环境、多设备共存的时序管理、缓存同步、任务调度交互。把每一层拆开，先硬件后软件，先单设备后多设备，再复杂的通信系统都能稳下来。希望这篇基于GD32H759 + RT-Thread的实践记录，能对正在做类似工控项目的朋友有点用。