做嵌入式工控的人几乎都有被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 0CPOL0CPHA0。但只要你同时接Flash和编码器就会发现问题W25Q64通常在Mode 0或Mode 3都能工作MT6816的手册推荐的却是Mode 3CPOL1CPHA1。同一根SCK不同的时钟极性和采样沿硬件上只有一套SPI控制器怎么切答案就是每次传输前重配模式切换片选后立即更新寄存器。RT-Thread的SPI框架恰恰支持在每次传输前调用配置接口来指定模式这就比裸机时代舒服很多框架里已经把这个逻辑塞进了传输函数里从机枚举和配置管理简单一大截。这也是我决定在RT-Thread上做这版SPI驱动的原因不是因为它新潮而是因为设备模型已经把多从机、动态模式切换、中断处理这些脏活杂活提前规范化了我们能专心写应用逻辑。2. SPI协议核心细节时序模式、极性与相位不搞懂后面全是坑2.1 四种模式是怎么来的CPOL和CPHA到底改了谁SPI之所以有四种模式本质就是两个布尔开关的组合时钟极性CPOL和时钟相位CPHA。我把它们的作用说直白一点CPOL决定SCK空闲时是高电平还是低电平。空闲低叫CPOL0空闲高叫CPOL1。CPHA决定数据是在SCK第一个边沿采样还是第二个边沿采样。CPHA0是第一个边沿CPHA1是第二个边沿。用生活里的类比就是两个人配合搬东西一个人打拍子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线读取两边都发都收通信看起来在跑实际上全是垃圾。接线时建议按这个顺序检查主控MISO接到从机MISO接收端不是交叉连接SPI不像UART那样需要TX-RX交叉。SCK必须共地地线一定要可靠连接我见过SPI高速时波形糜烂换了根粗杜邦线地线立刻稳定的案例。如果从机支持并希望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完全正常但是写数据后读出来对不上或者读的时候就偶尔跳几个字节。排查思路先确认写入命令前发0x06写使能的时序很多Flash要求每次写之前都要发写使能如果CMD里漏了写入被拒绝。检查状态寄存器Flash写完后需要轮询字节(BUSY位)确认内部擦写结束再读才能读到数据。如果轮询正常还出现偶发错位重点看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 常见故障速查表现象可能原因排查与解决办法读ID全FF或全00片选引脚错误、MOSI/MISO接反、从机未上电万用表量CS示波器抓CLK确认有时钟对调MOSI/MISO试一下数据中有固定位翻转错乱MSB/LSB位置配置错误检查byte order/位顺序寄存器按从机手册要求配置偶发错位长时间运行后出现引脚干扰、供电不稳、模式切换延迟降低SPI时钟检查GND和电源纹波切换传输前确保模式生效打开DMA后数据错乱D-Cache一致性未处理缓冲区放非Cache区或传输前后做Clean/Invalidate多个从机互相干扰MISO高阻态没做好、CS隔离失效确认每个从机CS都独立受控无效时MISO必须释放为高阻RTOS下SPI传输卡死中断优先级或互斥锁导致死锁检查SPI中断优先级与调度器设置确认消息传输用超时返回而非死等5.5 排查工具与调试方法这一部分我着重说三样工具逻辑分析仪跑SPI调试时十几块钱的8通道逻辑分析仪就够了。单次抓上千字节数据看CS下拉时刻、CLK频率、数据字节顺序多数通信问题一眼就能看出来。示波器如果需要看波形上升沿质量、振铃和电平阈值逻辑分析仪不够用示波器。测SCK高电平和低电平是否达到芯片VIH/VIL阈值以及MISO在采样点是否稳定。RT-Thread FinSH命令行框架的SPI设备可以在命令行里手动执行读写命令快速验证硬件与驱动是否就绪。不用写完整的应用代码就能测试外设这极大简化了调试。我用这套组合拳排查过至少三个不同主控的SPI问题逻辑分析仪抓时序、示波器看边沿、FinSH跑自测基本上没有过夜调试的难题。6. 实操记录与性能实测一次完整的数据搬运流程6.1 实测环境与参数记录为了给你一个可以直接参考的坐标我列一下我这块板的实际参数参数实测值备注主控GD32H759 550MHz带MPU、Cache跑RT-Thread系统节拍1000Hz定时器驱动配合调度SPI外设SPI0挂Flash和编码器Flash最大速率25MHz降频后稳定可靠编码器速率1MHz电机运行下稳定传输方式DMA中断大块数据不占CPU应用层读取周期编码器1kHz读取无丢包、无错位实际跑起来一次读取编码器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刚搬进来的内容。解决办法两条路把SPI DMA缓冲区定义在非Cache的SRAM区域这样所有读写都直接穿透Cache不经过缓存。每次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的实践记录能对正在做类似工控项目的朋友有点用。
