V3s开发板用着用着IO口总是不够用。传感器要挂在GPIO上继电器要驱动还要接几个编码器板子本身引出的引脚很快就见底了。更麻烦的是有些外设对实时性有要求靠Linux用户态去翻转GPIO延迟经常飘到毫秒级以上。后来我把一块某国产厂商的W806单片机180MHz主频的RISC-V核做成V3s的协处理器中间用SDIO链路连接算是把这套方案彻底跑通了。这篇文章就把整个方案的设计思路、硬件连接、两端代码框架和调试中踩过的坑完整写出来。如果你也遇到Linux板卡IO不够用、实时性达不到要求、又不想换更高端的SoC这种情况这篇文章会比较对胃口。文章覆盖的内容包括为什么选SDIO而不是UART/SPI/I2C、W806端从机协议栈怎么写、V3s端Linux下如何把自定义MMC命令封装成驱动、以及联调中几个非常容易翻车的地方。1. 为什么选SDIO做V3s的IO扩展而不是UART、SPI、I2C1.1 三条候选通信链路的能力对比做Linux板卡和MCU之间的通信大多数人第一反应是UART。串口简单、两边都有现成驱动、调试也方便但问题特别明显带宽太低。V3s上的UART一般跑115200bps换算一下也就11.5KB/s左右极限也不过几Mbps。如果协处理器要周期性上报大量传感器数据或者要执行一波批量IO操作这个带宽根本不够用。我最初用UART试过一轮几百个字节的数据就能把链路占满更别说还要留余量给日志输出。SPI是第二反应。SPI速率可以拉到几十MHzLinux这边有spi-dev驱动MCU端几乎所有单片机都带SPI外设看起来是个好选择。实际用起来有几个问题一是SPI是主从严格同步的V3s作为主设备持续产生时钟W806被动响应如果从机处理不及时主设备会一直等容易把内核线程卡死二是SPI全双工虽然可以同时收发但Linux用户态通过spi-dev做双向交互时每次transaction都伴随不小的调度开销三是在V3s这种板卡上SPI总线上往往已经挂了Flash、显示屏之类的设备中断优先级和设备冲突处理起来很烦。SDIO是很多人容易忽略的一条路。V3s自带SD/MMC控制器本身就跑着MMC子系统SDIO协议栈在Linux内核里已经是成熟代码。只要W806有SDIO从机接口这一点很关键不是所有MCU都支持从机模式两边就可以直接用SDIO协议通信。SDIO的CLK只要25MHz1-bit模式就有25Mbps4-bit模式理论上可以到100Mbps级别实际跑到6-8MB/s很轻松比UART高两三个数量级。而且SDIO的物理层本身就带了CRC7命令校验和CRC16数据校验数据传输的可靠性比裸UART高很多。对比表放在这里直观一点链路方案典型有效带宽双向实时性MCU端要求可靠性保护总成本UART0.01-0.5MB/s一般任意MCU需自行加帧校验最低SPI1-5MB/s主从轮流实时性一般任意MCU带SPI从机需自行加帧校验低SDIO 1-bit3-6MB/s好支持双向并发需SDIO从机控制器协议自带CRC7/CRC16中SDIO 4-bit6-8MB/s以上好支持双向并发同上协议自带中1.2 SDIO链路真正适合什么场景不过SDIO并不是万金油。如果一个工程里的协处理器只是读几个按键、点几个LED那用I2C更划算两根线就能搞定W806这类MCU的I2C从机实现也简单带宽需求又不大。SDIO的复杂度主要在于MCU端必须真有硬件SDIO从机控制器软件初始化时序也比UART复杂调试阶段要用到逻辑分析仪抓波形才能看清楚问题。真正适合SDIO方案的场景我认为有这几个特征第一包量比较大。比如一块板子上接了十几个温湿度传感器每个都周期上报几十字节数据加上时间戳和状态字段带宽要在几十KB/s以上这时候SDIO的价值就出来了。第二需要双向高频交互。比如一边要频繁下发PWM控制参数另一边又要快速回传编码器计数这种读写交错频繁的场景SDIO的CMD/DAT分离机制比SPI轮转式全双工更灵活。第三未来可能要跑文件系统。如果后续想把W806外挂的SD卡空间也挂到Linux上或者想通过SDIO做固件升级通道SDIO本身就是存储类总线的标准路径迁移成本比UART低很多。总结一句话如果只是低速IO别折腾SDIO如果链路是瓶颈SDIO值得认真考虑。2. 硬件连接与从机时序先把手脚摆对2.1 引脚对接方案与上拉细节W806这颗芯片的SDIO控制器支持从机模式官方SDK里有一套配置路径但网上文档写得比较分散。先看引脚对接。V3s这边一般用SDC0接口引出的是SDC0_CLK、SDC0_CMD、SDC0_D0到D3共六根线。W806的SDIO从机引脚分布在PB组和PC组具体是哪几个引脚要以对应开发板的原理图为准但一般也就那五六根。连接方式很简单CLK接CLKCMD接CMDD0-D3分别对应两边共地。这里有一个非常容易被忽略的细节上拉电阻。SD总线的CMDUCT信线在空闲状态需要保持高电平所以CMD和DAT线必须接上拉电阻。数值选10kΩ比较稳妥V3s内部虽然也有上拉但不同板子的配置不一样外置上拉可以避免时好时坏的毛病。CLK线不用上拉而且尽量走短一点SDIO时钟频率只要上了25MHz长走线加上寄生电容波形就会明显劣化。另外V3s的SDIO接口通常会有一个CDCard Detect引脚用于检测SD卡是否存在。我们要接的是协处理器设备完全不需要CD检测直接不连接这个引脚并且在设备树里把卡检测配置关掉。如果默认开着CD检测内核会认为总线上根本没有卡后面的自定义MMC命令就发不出去。这个坑我后面会专门再讲这里先记住这个结论。还有一个电源时序问题W806和V3s是两套独立供电系统上电顺序不同会导致SDIO控制器在时钟未稳定时收到乱码命令。我建议给W806单独加一个MOS管控制电源由V3s的一个空闲GPIO来给W806上电这样V3s先启动完再把W806拉起来时序完全可控。2.2 SDIO从机时序的基本逻辑SDIO的时序本质上和SD存储卡是一样的所有操作由HostV3s发起每笔事务包含CMD阶段、可选的DATA阶段、以及CRC校验。CMD线传输48位命令带7位CRC校验从机收到命令后如果CRC不对可以直接忽略。DATA线在4-bit模式下每个时钟周期传输4位数据每块数据末尾有16位CRC。W806作为从机核心工作就是监听CMD线解析Host发来的命令然后按照命令要求通过DATA线接收或发送数据块。这个过程中从机完全靠CLK信号同步所以两边不需要像UART那样约定波特率也不需要高精度时钟校准只要CLK稳定数据就能正确采样。从时序图的角度看整个流程是V3s的MMC控制器把命令发出去经过几微秒到几十微秒的命令响应时间W806在DAT线上返回一个带有CRC的响应块然后进入数据阶段。数据阶段需要把块长度和块数量事先约定好否则从机不知道要收多久。实际操作层面我用的办法是让V3s把每次交互设计成命令固定长度数据块的形式。命令里包含操作码和参数参数里直接写清数据块长度。W806收到命令后先解析再决定DMA收发长度这样从机端逻辑简单很多不用做复杂的连续流解析。3. W806端裸机SDIO从机协议栈把数据按时序收进来3.1 中断DMA双缓冲的收包框架W806端的程序没有操作系统就是一个裸机循环加中断处理。SDIO从机需要响应Host随时发来的命令如果用轮询的方式查寄存器很容易错过命令窗口所以必须走中断。数据量大一点的时候得让DMA干活CPU只在中断里做包的解析和响应调度。我采用的框架是双缓冲接收。给DMA准备两个接收缓冲区一个被DMA填充数据另一个由CPU解析处理两边交替使用避免DMA还没写完CPU就开始读导致的半包问题。缓冲区大小要根据最大协议帧来定我这边设的是512字节内部再划分出帧头和载荷区。初始化W806端SDIO的核心步骤可以归纳为这么几步使能对应引脚的SDIO复用功能配置好总线宽度1-bit或4-bit。打开SDIO控制器时钟配置从机模式把DAT线方向设为输入。挂SDIO中断使能命令接收中断和数据传输结束中断。设置DMA把第一个接收缓冲区的地址交给SDIO控制器。等待Host发起命令。给一个伪代码片段参考整体思路#include wm_sdio.h static uint8_t rx_buf[2][512] __attribute__((aligned(4))); static uint8_t tx_buf[2][512] __attribute__((aligned(4))); static volatile uint8_t rx_cur 0; void SDIO_IRQHandler(void) { uint32_t stat SDIO-INT_STAT; if (stat SDIO_INT_CMD_END) { /* 收到完整命令进入命令解析流程 */ handle_sdio_command(); } if (stat SDIO_INT_DATA_END) { /* 当前DMA缓冲接收完成切到另一块缓冲 */ rx_cur ^ 1; SDIO_SetRxDMA(rx_buf[rx_cur]); parse_frame(rx_buf[rx_cur ^ 1]); } SDIO-INT_STAT stat; /* 清中断标志 */ }注意一个很关键的细节切换到下一块缓冲区必须在DMA停止的状态下进行否则可能出现缓冲区指针被DMA改写一半的竞态。我在代码里加了关中断保护。3.2 帧格式与状态机SDIO只负责把字节从A搬到了B字节本身是啥意思还得自己定义。所以要设计一套简单的协议帧覆盖读IO、写IO、批量上报、固件升级这些操作。我用的帧格式是字段长度字节说明帧头2固定0xA5 0x5A用于同步和识别命令字10x01读IO状态0x02写IO0x03批量采集0x04固件升级载荷长度2小端序表示后面载荷的字节数载荷N按命令字解释的业务数据CRC162从帧头开始到载荷末尾的CRC16校验这个帧格式参考的是常见的Modbus风格好处是状态机好写排查问题也直观。所有长度字段用小端序避免两端的字节序问题——W806的RISC-V核是小端V3s的ARM核也是小端两边天然对齐但写协议的时候还是要明确标出来。W806端收包状态机分四个阶段找帧头、收命令字、收长度、收载荷和CRC。因为DMA已经帮我们把数据按块收好了状态机只需要在内存里处理缓冲区的字节逻辑不复杂typedef enum { ST_WAIT_HEAD, ST_WAIT_CMD, ST_WAIT_LEN, ST_WAIT_PAYLOAD, } parse_state_t; static parse_state_t pstate ST_WAIT_HEAD; static uint32_t expect_len 0; static uint8_t *payload_ptr; void parse_frame(uint8_t *buf) { uint32_t i 0; while (i RX_BLOCK_LEN) { switch (pstate) { case ST_WAIT_HEAD: if (buf[i] 0xA5 i 1 RX_BLOCK_LEN) { if (buf[i 1] 0x5A) { pstate ST_WAIT_CMD; i 2; } } i; break; case ST_WAIT_CMD: cur_cmd buf[i]; pstate ST_WAIT_LEN; break; case ST_WAIT_LEN: expect_len buf[i] | (buf[i 1] 8); i 2; payload_ptr buf[i]; pstate ST_WAIT_PAYLOAD; break; case ST_WAIT_PAYLOAD: if (i expect_len 2 RX_BLOCK_LEN) { if (crc16(buf, i expect_len) 0) { exec_cmd(cur_cmd, payload_ptr, expect_len); } } pstate ST_WAIT_HEAD; i expect_len 2; break; } } }执行命令的时候比如写IO命令就直接操作W806的GPIO输出寄存器批量采集命令就去读所有ADC通道和编码器计数把结果打包塞进发送缓冲区等Host下次读的时候发出去。注意不要在中断里做大量浮点运算或复杂业务逻辑中断里只做数据搬移置标志位真正算编码器、滤波这些事放到主循环里。4. V3s端Linux侧数据通路让SDIO从机出现在/dev下4.1 自定义MMC命令与驱动挂载Linux端要做的第一件事是让SDIO总线上能识别到W806这个设备。SDIO协议标准里有一种叫自定义/厂商专用命令SDIO CMD52/CMD53的东西SDIO外设通过分配好的I/O地址进行读写我们可以把W806的帧接口抽象成一个带地址空间的IO设备。更简化一点的做法是把自定义命令直接封装成V3s MMC控制器能发的MMC命令通过mmc_wait_for_req往总线上发。首先要确保内核的MMC子系统初始化好了这个host。V3s的设备树里SDC0节点需要设置成支持SDIO的模式并且去掉CD引脚检测sdc0 { status okay; bus-width 4; max-frequency 25000000; broken-cd; /* 不检测卡中断 */ non-removable; /* 视为不可移除设备 */ };broken-cd和non-removable这两个属性就是我前面说的坑的关键配置没有它们内核会在探测阶段认为总线上没有设备后续发命令直接返回媒体不存在的错误。驱动侧我写了一个platform驱动挂在MMC子系统下面。基本思路是驱动probe时通过mmc_alloc_host注册一个新的mmc_host然后在驱动的ioctl接口里把用户态传进来的命令载荷组装成mmc_request调用mmc_wait_for_req发给W806。整个过程在进程上下文里同步执行内核线程负责异步收数据。驱动骨架大概长这样static long w806_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { struct mmc_host *host g_host; struct w806_req ureq; struct mmc_command mcmd {0}; struct mmc_data mdata {0}; struct mmc_request mrq {0}; struct scatterlist sg; uint8_t *buf; if (copy_from_user(ureq, (void __user *)arg, sizeof(ureq))) return -EFAULT; buf kmalloc(ureq.len 4, GFP_KERNEL); /* 组装帧帧头命令字长度载荷 */ // ... mcmd.opcode MMC_SET_BLOCK_COUNT; /* 用自定义opcode也可 */ mcmd.arg 0xA55A0000 | ureq.cmd; mcmd.flags MMC_RSP_R1; mdata.flags (ureq.dir W806_READ) ? MMC_DATA_READ : MMC_DATA_WRITE; mdata.blksz ureq.len; mdata.blocks 1; sg_init_one(sg, buf, ureq.len); mdata.sg sg; mdata.sg_len 1; mrq.cmd mcmd; mrq.data mdata; mmc_set_data_timeout(mdata, host); mmc_wait_for_req(host, mrq); if (mcmd.error || mdata.error) { kfree(buf); return -EIO; } if (ureq.dir W806_READ) copy_to_user((void __user *)ureq.buf, buf FIXED_HEAD_SZ, ureq.len); kfree(buf); return 0; }这里注意一点内核里直接组装自定义MMC命令时cmd.opcode不能撞上标准固定命令的数值尽量用保留给厂商自定义的区间。如果MMC框架不认可以用SDIO_RW_EXTENDED这类标准命令功能号定义成自家设备的ID这样兼容性更好。4.2 内核线程、等待队列与用户态ioctl有了ioctl读写接口之后用户态可以直接打开/dev/w806_io每次调用ioctl来完成一次读或写帧操作。但是如果有周期性的批量采样需求频繁从用户态发起系统调用就会引入调度延迟。更实际的做法是在驱动里开一个内核线程专门负责数据流程。核心机制是一个环形缓冲加等待队列。内核线程从mmc子系统的收包队列里取数据解析帧之后放入环形缓冲区。用户态通过read接口在没有数据时阻塞在等待队列上内核线程每收完一包就唤醒等待队列用户态醒来后从缓冲区取数据。我最初以为最方便的通信方式是走TCP/IP或UART这类成熟路径但实测下来在SDIO链路上内核里直接用等待队列的延迟最稳定。等待队列的唤醒延迟一般在几十微秒量级用户态再通过read拿到数据整体往返大概120微秒左右这个结果后面实测会提到。用户态的调用代码反而很简单封装成这样int w806_read(unsigned char cmd, void *payload, int len) { int fd open(/dev/w806_io, O_RDWR); struct w806_req rq; rq.cmd cmd; rq.dir W806_READ; rq.len len; rq.buf payload; int ret ioctl(fd, W806_IOC, rq); close(fd); return ret; }这里有个设计取舍每次调用都open/close设备文件文件开关的开销大概几次微秒如果采样频率很高建议fd在程序初始化时打开一次不要每次释放。实测高频采样下反复open/close会明显拉高平均延迟我从每秒100次加到每秒1000次才注意到这个问题。5. 联调实测与三个最容易翻车的点5.1 实测吞吐与往返延迟整套系统联调时我重点测了两个指标批量数据传输的吞吐率以及单帧命令的往返延迟。测试方法是用W806的定时器产生一个GPIO脉冲V3s端循环读这个IO状态每次读帧打一个时间戳统计平均延迟。4-bit模式、25MHz时钟下我这块板子调到的最优结果是写W806寄存器帧16字节载荷的往返延迟稳定在120微秒左右其中内核驱动处理占了大头剩下的才是总线和从机处理时间。批量读256字节传感器数据时有效吞吐在6.2MB/s左右。这个数字和理论峰值有差距但UART和SPI几乎不可能到这个量级。如果遇到吞吐上不去的情况优先检查DMA配置。W806端和V3s端如果有一边没有真正走DMA而是用CPU逐字节拷贝吞吐会掉到1MB/s以下。还有个隐蔽点V3s的MMC控制器在做4-bit数据传输时SG链表要求每一段缓冲区地址对齐到块边界不满足对齐就会触发fallback一样掉速。5.2 坑一SD卡检测引脚让内核以为卡不存在这个锅我在前面无线索地埋了几次现在是详细版本。V3s的SDC0接口默认带着CD检测设备树里没做好配置的时候内核扫描SDIO总线看到没有卡插入直接不创建SDIO client。在这种情况下我的驱动根本拿不到hostioctl调用返回的是ENXIO。表现形式特别迷惑总线上电测量CLK和CMD波形都正常W806端也能收到命令但V3s端上报卡检测失败或media event ERROR。排查方式是把设备树里的sdc0节点加上non-removable属性并用broken-cd明确告诉内核不检测CD引脚状态。这个配置改了之后重新编译设备树清空mmcblk相关的自动挂载配置再启动就能看到类似mmc0: new SDIO card的日志。我在另一块板子上试过同样的W806固件只改设备树从完全不通变成可以正常收发问题就出在这。5.3 坑二时钟未稳定前的垃圾命令导致从机状态错乱前面提到过电源时序现在说说它会引发什么后果。V3s启动早期MMC控制器可能在SDIO外设还没有初始化完的时候就开始发命令或者CLK中间不停抖动W806的SDIO从机控制器会把这些毛刺误判成命令头。一旦进入解析了半个命令的状态后面即使收到正常命令也可能因为状态机错位而丢弃。表现是按复位键重新启动V3s之后第一次调用ioctl总是超时第二次就好了。这是因为第一次的命令被W806端错误状态吞了等到超时后再发重试命令W806才回到正常状态。解决方案有两个我都试过都有效一是在V3s的设备树里把max-frequency配低一点比如降到12.5MHz上电初期波形质量会好很多二是在W806端初始化SDIO中断的时候增加一个时钟锁存逻辑让W806在CLK引脚持续高电平一定时间后才打开命令中断。第二种方案更彻底因为它是从根上屏蔽了乱序命令。5.4 坑三DMA缓冲对齐与Cache一致性问题第三个坑和Linux内存的底层机制有关。mmc_wait_for_req要求SG缓冲区在ARM架构下保持Cache line对齐如果缓冲区是普通kmalloc分配的往往只能对齐到8字节而DMA传输需要64字节对齐。不满足对齐条件时内核会启用bounce buffer数据在cache和DMA缓冲区之间反复搬运不仅速度慢有时还会出现数据内容偶发不一致。我的修改方式很简单分配缓冲区时从kmalloc换成dma_alloc_coherent或者aligned allocation确保地址对齐到L1 Cache line大小。驱动里再加一句WARN_ON检查如果sg缓冲区地址不是64字节对齐就打印调试信息防止后续改动破坏这个条件。这个坑的表现是传输偶尔出错CRC校验失败率大概在千分之一到百分之一之间看起来像是信号质量问题实际根因是cache里残留了旧数据。用dma_alloc_coherent之后这个问题就彻底消失了CRC失败率降到了零。最后再分享一个调试期的小技巧。SDIO链路上如果数据老是错先不要急着改代码用逻辑分析仪同时抓CLK、CMD和D0三根线看看从机的响应是否在命令后规定的64个时钟周期内返回。很多看似神秘的错误最终都归结为响应超时这一个原因。我这次联调最耗时间的部分其实不是在写协议栈而是在波形和日志之间来回找线索。把这几个点都排干净之后整套SDIO扩展IO的方案跑得非常省心目前已经稳定运行了很长一段时间。
