这个系列写到第三篇前两篇我们解决了FreeRTOS的系统移植和MQTT通信链路步进电机也能正常转了。但做到这一步你会发现整套设备还缺一个特别关键的东西——本地存储。电机参数、配置文件、运行日志总不能每次都打开调试器改代码重新烧录吧。于是就有了这一篇的内容SD卡驱动、FatFS文件系统移植以及ini配置文件读取的实现。需要说明的是这篇文章虽然叫“步进电机控制三”但SD卡、FatFS和ini解析这套方案其实完全可以单独拿出来用在你手头任何一个需要本地存储的物联网项目上。我会尽量把每一步的“为什么这样做”讲透而不是只贴代码让你复制粘贴。因为SD卡这玩意做起来问题特别多网上教程也五花八门你不理解底层原理遇到问题根本无从下手。1. 为什么步进电机控制器需要一张SD卡很多初学者会问一个问题我一个电机控制器要SD卡干嘛数据又不复杂为什么不直接把参数写死在代码里或者存到Flash里这个问题问得很有道理。当初我在设计这套系统时一开始也是把电机参数放在结构体里每次改参数就重新编译、下载、复位几分钟的事情。但当你把设备部署到现场或者要交给非技术人员使用的时候问题就来了。现场调试时你可能需要根据负载情况微调电机的加减速曲线、细分设置、回零速度——这些参数如果都在代码里每一次调整都需要带着电脑去现场插上ST-Link重新烧录。而且一旦改错还得还原。用SD卡存放一个配置文件让设备上电时自动读取改动就变成了一件极其简单的事情拔卡插到电脑上用记事本改参数插回去重启。任何会使用记事本的人都能完成参数调整这是第一个刚需。第二个刚需是日志记录。工业控制现场设备出问题时最让人头疼的就是“不知道它在什么时间发生了什么”。电机堵转、通信超时、急停触发——这些事件如果能按时间戳记录到SD卡里事后排查起来会轻松得多。我的做法是让FreeRTOS的一个低优先级任务定时把环形队列里的日志刷入SD卡这样既不阻塞实时控制任务又能保证关键数据落盘。第三个刚需和MQTT有关。联网设备难免遇到断网MQTT链路断了之后传感器采集到的数据如果只存在内存里RAM有限存不了多少而且一断电就全丢。SD卡可以作为断网期间的本地缓存区恢复通信后再把数据补传上去。STM32F103RCT6这种级别的芯片内部Flash才256KBRAM才48KB你要缓存大量数据根本不现实。一张2GB的SD卡对日志和参数配置来说永远用不完。所以说SD卡在这个项目里的定位实际上是一个“可移动的本地存储介质”。它既承载了参数配置的灵活性又提供了日志记录的空间同时也是断网缓存的基础。理解了这些你再回过头来看后面的驱动移植和文件系统就会明白每一部分解决的是什么实际问题。2. SD卡底层驱动选SDIO还是SPI初始化顺序才是重点SD卡和单片机通信有两种主流方式SDIO和SPI。很多新手一上来就纠结选哪个其实这个选择没有绝对的好坏完全看你的应用场景和硬件资源。2.1 SDIO与SPI的关键差异我直接给一张对比表这是我在实际项目中反复权衡后得出的结论对比项SDIO接口SPI接口通信速率最高可达48MHz4bit模式一般18MHz~36MHz具体看分频引脚占用CLK、CMD、D0~D3共6个引脚CS、SCK、MOSI、MISO共4个引脚是否支持4bit模式支持传输速度快不支持只能1bit驱动复杂度较复杂需要处理命令应答和CRC相对简单逻辑更直观DMA支持STM32的SDIO外设支持但要注意FIFOSPI配合DMA也很成熟兼容性标准SD卡和microSD卡都支持对卡的兼容性稍差部分卡在SPI模式下有兼容性问题如果你用的是STM32F103系列它的SDIO外设是支持4bit模式的实际读写速度比SPI快很多。做步进电机控制时如果你需要频繁记录运动状态或者要写入较大的日志我会无脑推荐SDIO。但要注意SDIO的时序要求更严格遇到问题也更难排查。如果你的项目对速率不敏感比如只用来存配置参数、偶尔写点状态数据那SPI反而更省引脚、代码也更简单排查问题容易得多。我这套系统用的是SDIO 4bit模式配DMA原因很简单我需要日志实时落盘而且电机运行过程中还要实时记录位置和电流数据速度太慢了会影响数据完整性。如果你的系统对速度没这么高要求选SPI完全够用后面我讲底层驱动的思路两种接口也是通用的。2.2 SD卡初始化的先后顺序SD卡驱动里最核心的难点不是读写而是初始化。很多人的卡读写不稳定九成以上是初始化过程出了问题。SD卡的初始化其实是一个状态机你必须按照规范里的顺序来不能跳步上电后先延时至少74个时钟周期给卡内部上电稳定时间发送CMD0把卡切到SPI模式或确认SDIO模式发送CMD8确认卡支持的电压范围这是判断SD V2.0以上卡的关键循环发送ACMD41在SDIO模式下或ACM41在SPI模式下直到卡返回空闲状态发送CMD2获取CID发送CMD3获取RCA相对卡地址发送CMD7选中卡然后发送CMD6读取SCR判断卡支持的位宽模式如果要切4bit模式发送ACMD6设置位宽。这里有个常见的坑很多教程里一笔带过的“延时”其实非常讲究。卡上电后内部的电压稳定需要时间74个时钟周期只是最低要求实测中有些卡需要更久。我曾经碰到一张老旧的TF卡上电后立刻初始化大概率失败多等500ms就百分百成功。所以我在初始化函数开头加了一个可配置的延时参数默认500ms所有卡都能稳稳通过。另外一个重点是CMD8和ACMD41的配合。CMD8会返回卡的电压范围信息如果返回的状态不正确说明这张卡可能不支持你当前的电压区间。ACMD41的循环发送次数也有限制不能无限循环等卡响应一般循环100次左右就可以判断初始化失败。我见过有的代码里没有循环上限一旦卡损坏或者接触不良整个程序就死在初始化里连FreeRTOS的任务调度器都启动不了——这在实时系统里是不可接受的。2.3 底层的读、写、擦除函数怎么设计SD卡底层的核心操作无非三个读单块/多块、写单块/多块、擦除。SD卡的读写最小单位是一个扇区通常是512字节。也就是说哪怕你只想读1个字节底层也会把整个512字节读上来再从缓冲区里取出那个字节。理解了这一点你就能明白为什么FatFS在操作小文件时效率会有损耗。我的底层驱动封装了四个函数SD_ReadBlocks、SD_WriteBlocks、SD_EraseBlocks、SD_GetStatus。前两个都带DMA版本因为FreeRTOS环境下如果你用阻塞式读写一个读操作可能卡住几十毫秒这种延时对于PID控制循环来说简直是灾难。DMA方式的好处是CPU只需要发起传输然后就可以去做别的事等DMA传输完成中断再回来处理结果。这里要特别提醒DMA缓冲区必须放在特定的内存区域。STM32F103的DMA1和DMA2都不能访问所有内存地址比如F103的DMA无法访问CANTB和SDIO的FIFO区域时而SDIO外设的FIFO地址必须用DMA访问这就需要对缓冲区地址做些处理。实际中问题更常见的是如果缓冲区定义在堆上malloc动态分配或者某个特定的内存段而该地址不在DMA可访问范围内DMA传输会直接卡死或者传输错误数据。所以我在项目里统一使用静态分配的全局缓冲区定义在__attribute__((section(DMA_RAM)))指定段里。你如果用CubeMX生成代码它会自动帮你处理好这些细节这也是我建议新手直接用CubeMX的原因之一。DMA传输完成后还要做一件事检查数据CRC是否正确。SD卡协议里每个数据块后面都跟了CRC校验信息虽然实际使用中很多人会忽略这个校验但我在日志系统里还是加上了校验失败重传的逻辑。SD卡终究是机械闪存结构在工业现场振动环境下数据可能出现位翻转错误。一次校验失败就重读一次能解决绝大部分偶发错误。3. FatFS移植连接文件系统与底层驱动的五个关键函数底层SD卡驱动搞定后你在单片机上面对的是一个个扇区使用起来非常痛苦。比如你想存一条日志“2024-01-15 10:30:25 电机A堵转”如果直接在扇区里按固定偏移写那改一个字节可能要把整个扇区读出来改完再写回去。要管理多个文件更是不可能。所以我们需要文件系统这一层抽象。FatFS是一个面向嵌入式场景的FAT文件系统实现大名鼎鼎在STM32上几乎是标配。3.1 FatFS的分层架构和移植思路FatFS的分层很清晰从上到下是应用层f_open、f_read、f_write、f_close这些API供你的业务代码直接调用FatFS模块层文件系统逻辑、FAT表管理、目录操作这部分完全不需要你修改底层接口层disk_initialize、disk_read、disk_write、disk_ioctl、disk_status这些是FatFS和你的硬件驱动之间的桥梁也是移植时唯一需要你动手写代码的地方。这个设计非常巧妙它把和硬件相关的部分完全隔离在底层接口层。不管你用的是SDIO还是SPI、SD卡还是NAND Flash甚至是片内Flash模拟的U盘只需要实现这几个接口FatFS的整个文件系统逻辑就能原封不动地跑起来。3.2 每个disk_xx函数的实现要点我逐个讲一下这几个函数因为这里面的细节直接决定了文件系统稳不稳。disk_initialize这个函数在FatFS调用f_mount时被触发。实现要点是调用前面写好的SD_Init完成底层初始化并返回操作结果。要注意这个函数可能被反复调用比如拔卡重插后重新挂载所以内部不能有只能执行一次的静态判断逻辑。disk_statusFatFS的f_mount内部会先调用disk_status检查磁盘状态返回STA_NOINIT表示未初始化FatFS就会自动调用disk_initialize。所以这个函数不需要太多逻辑把SD卡的状态变量返回上去即可。我还在里面加了检测卡插入状态的逻辑用SDIO的数据线D3上的上拉状态来判断是否有卡插入SD卡规范里D3线空闲状态是高电平这样我能实时感知卡是否被拔出。disk_read三个参数扇区号、缓冲区指针、扇区数量。实现时要处理两种情况单扇区读和多扇区读。SDIO的读操作支持连续多块读取效率很高。但如果缓冲区不是4字节对齐的从FatFS传下来的指针一般是对齐的DMA会出错。我在这里加了一个分支如果指针地址不是4的倍数就退回到轮询方式读单块虽然慢一点但不会出错。disk_write同样处理单块和多块。这里有一个重要区别SD卡写操作之前必须保证目标扇区是擦除过的。FAT文件系统在逻辑上会保证这一点因为它在写文件之前会先更新FAT表分配扇区那些扇区理论上已经是擦除状态。但SD卡内部的FTL闪存转换层会用逻辑映射把擦除操作隐藏所以你的驱动里不需要主动做擦除操作直接写就行。disk_ioctl这是一个命令分发函数用来处理FatFS发来的各种控制命令。最常见的是CTRL_SYNC和GET_SECTOR_SIZE。CTRL_SYNC要求把所有缓存在硬件层的数据真正写到盘上对于SD卡来说就是等待之前发起的写操作完成GET_SECTOR_SIZE返回扇区大小一般是512。还有个CTRL_TRIM命令如果开启了这个配置项文件删除时会触发底层擦除延长SD卡寿命。我在日志系统里会定期清理旧日志开启TRIM能减少闪存写入放大。3.3 ffconf.h里的关键开关FatFS的灵活性体现在ffconf.h配置头文件里移植时这些开关直接影响你后续所有操作FF_USE_LFN长文件名支持。设为1时在ARM上需要额外的静态缓冲区来存放长文件名转换结果设为2时动态申请内存但FreeRTOS环境下堆管理有碎片问题我建议用静态缓冲区。这个开关不开超过8.3格式的文件名全部乱码。FF_FS_RTC时间戳支持。开启后需要提供一个get_fattime()函数返回当前时间。我的系统里维护了一个从MQTT同步的RTC时间get_fattime直接读RTC寄存器拼接成FAT时间格式。有这个功能日志文件里才能看到正确的时间戳排查问题时太重要了。FF_USE_MKFS格式化功能。如果你不想用电脑给SD卡格式化成FAT32想让设备自己格式化就需要开启这个。SD卡出厂一般是FAT32但偶尔拿到一张格式不对的卡开机时如果挂载失败我就可以提示用户选择是否让设备自动格式化。FF_FS_EXFATexFAT支持。嵌入式设备一般用不上而且exFAT有专利问题我默认关闭。FF_MULTI_PARTITION多分区支持。如果一张卡要分两个区存储不同类型数据可以开这个。但大多数场景不需要保持默认就行。3.4 挂载和文件读写时序文件系统挂载和访问有固定的时序要求。正确流程是上电初始化SD卡调用f_mount挂载文件系统。如果返回FR_NO_FILESYSTEM说明卡上还没有有效的FAT文件系统这时可以提示用户格式化之后就可以正常f_open、f_read、f_write、f_close了系统关机前必须f_mount(NULL, ...)卸载文件系统并把底层SD卡切回空闲状态确保所有缓存数据已经落盘。断电保护是个值得专门说的话题。很多人直接在写文件过程中断电结果下次开机发现文件损坏或者整个目录都乱了。FatFS用f_sync可以强制把缓冲区数据刷到盘上这个函数在写日志时非常有用。我的策略是日志每积累一定条数或者每过一定时间间隔就调用一次f_sync把文件系统缓存亮到SD卡上。虽然频繁sync多一点时序开销但换来的是断点不丢数据的安全感。注意f_open后每隔一段时间f_sync一次是一个被很多老工程师验证过的最稳妥方案比f_close之后重新打开要安全得多。因为f_close内部也做了类似sycn的操作但它要求你上一次写的句柄全部合法。在长时间运行的系统里反复打开关闭文件容易积累句柄冲突问题。4. FreeRTOS环境下的文件系统访问稍不留神就踩的内存和调度坑在裸机环境下使用FatFS写个文件和在FreeRTOS多任务环境下使用完全不是一个难度等级。这里要处理的不是文件系统本身而是并发资源访问和任务调度问题。4.1 FatFS本身不是线程安全的这是最重要的一句话FatFS的API在默认配置下不保证多任务安全。如果两个任务同时调用f_open或者f_write内部的全局工作区变量就会被互相覆盖轻则写错数据重则直接HardFault。解决方案是在文件系统外面套一层互斥锁。我建了一个统一的文件系统访问入口模块内部维护一个FreeRTOS互斥量。所有对FatFS API的调用都通过这个模块转发进入函数时拿锁出函数时放锁。这样虽然会让文件系统访问串行化但换来了绝对的安全性。在实际项目中文件操作本来就不是高频操作串行化的影响完全可以忽略。用互斥锁而不是二值信号量是故意的。互斥量具备优先级继承机制如果一个低优先级任务拿着锁高优先级任务来敲门时系统会把低优先级任务的优先级临时提升到高优先级任务的级别从而避免优先级反转问题。这是嵌入式实时系统里非常经典的一个场景如果你用二值信号量优先级反转的情况会真实发生表现为一个高优先级控制任务被一个低优先级文件任务卡住几十毫秒这在运动控制里是致命的。4.2 文件操作任务和电机控制任务的调度关系步进电机控制这类应用里实时控制任务的调度周期通常在1ms到10ms之间而且这个任务是硬实时的不能被长时间打断。但SD卡写操作哪怕用了DMA也可能被文件系统日志计算、FAT表更新等操作占住几百微秒。如何协调两者我的做法是把文件系统操作独立成一个任务优先级设到最低。电机控制任务需要记录数据时不发文件操作请求而是把数据塞到一个环形缓冲区里然后给文件任务发送一个通知。文件任务收到通知后才把环形缓冲区里的数据取出来组织成日志行再写入SD卡。这个设计的好处是电机控制任务永远只做轻量的内存操作不会因为SD卡忙而阻塞。SD卡慢一点没关系反正数据已经进了环形缓冲区只要缓冲区容量够大别溢出就行。环形缓冲区的容量可以根据SD卡最慢写入时间和数据产生速率来计算。比如我每秒产生200字节日志SD卡最差写入速度是5KB/s环形缓冲区留个10KB就足够撑过最坏情况了。4.3 任务栈分配与内存泄漏的隐性坑FreeRTOS每个任务的栈是独立分配的文件系统操作尤其是开了长文件名和路径解析后栈消耗会比想象中大得多。FatFS的f_open内部处理长文件名时静态缓冲区加上局部变量轻松吃掉几百字节栈空间。如果你给文件任务只分了512字节的栈运行一段时间后就会栈溢出表现就是系统的“某一个功能偶发性死机”——特别难排查。我的经验值是文件系统相关任务的栈至少给1024字节加上日志格式化用snprintf的话最好给1536字节以上。你可以在FreeRTOS里用uxTaskGetStackHighWaterMark函数检测每个任务的栈剩余空间把系统跑上几天后把这些数据打出来看看这是排查栈溢出的最直观手段。还有一个非常隐蔽的坑是堆碎片化。FreeRTOS默认的pvPortMalloc实现heap_4.c支持合并相邻空闲块但长期高频地分配和释放大小不等的内存块依然可能产生不可合并的碎片。文件操作时如果你用f_malloc动态分配长文件名缓冲区或者日志任务每处理一条日志都malloc一块临时内存时间长了堆会慢慢变小直至分配失败。我的建议是文件系统相关的缓冲区尽量定义为静态变量或任务内局部变量减少动态分配如果非要动态分配就用内存池而不是通用堆。5. ini配置文件读取小身材、大作用但请你别真的手写解析器前面SD卡驱动和FatFS都搞定了到了这一步设备的存储能力已经具备了。但存储只是基础真正让用户方便的是“改一个文件就能改设备行为”的体验。这时候就要用到配置文件了。常见的配置文件格式有JSON、YAML、ini等。在单片机上我选了ini格式。5.1 为什么嵌入式场景选ini而不是JSONJSON在Web领域是主流但在单片机上用JSON纯属找罪受。解析JSON需要一个功能比较完整的解析器占用几千字节的代码空间很正常。而ini格式极其简单本质上就是“节section”“键值对keyvalue”用几百行C代码就能写一个够用的解析器。拿我的电机控制配置举例配置文件长这样[motor1] enable1 microstep8 speed_rpm120 accel_profilesmooth max_current1.5 [motor2] enable0 microstep16 speed_rpm80 accel_profiletrapezoid max_current0.8 [system] debug_level2 log_enable1 ble_enable0用config.ini记录这些任何一个工程师拿到脑子里就能看懂。JSON版本长什么样括号、引号、逗号——你虽然不嫌多但对一个低性能MCU来说解析JSON的开销纯属浪费。而且ini文件可以直接用记事本修改用不着专门工具这对现场调试的友好度是很重要的。5.2 解析器的核心设计思路既然决定用ini接下来就是怎么解析的问题。网上能找到很多开源的ini解析库比如minIni但我建议你自己先写一版因为需求非常简单而且自己写能完全掌控内存占用。我的解析器核心就两个接口int ini_get_int(const char* filename, const char* section, const char* key, int default_val); const char* ini_get_string(const char* filename, const char* section, const char* key, const char* default_str);每次调用时解析器打开文件、逐行读取、跳过空白行和注释行以;开头的行、判断当前处于哪个section然后在目标section里查找目标key。找到后返回对应的值如果没找到返回默认值。这个设计是典型的“无状态解析器”每次调用都从头解析文件优点是简单、无内存残留缺点是多次调用时会重复读文件性能差一点。但配置文件读取一般只发生在上电启动阶段运行中很少反复读取所以完全能接受。解析过程中有两个细节值得注意第一个是字符串值的缓存问题。ini_get_string返回一个const char*这个指针不能是临时缓冲区否则函数一返回就失效了。我的做法是调用者传入一个缓冲区解析器把字符串填进去。虽然丑但非常可靠。char cfg_buffer[32]; ini_get_string(config.ini, system, wifi_ssid, default, cfg_buffer, sizeof(cfg_buffer));第二个是注释处理。ini格式的注释标准并不统一有人用;有人用#有的还支持行尾注释。我建议只支持行首注释因为行尾注释处理起来有歧义如果value本身包含#字符呢比如ssidmy_wifi#2行尾注释解析器就会把#2截掉导致配置错误。所以行首注释最安全规规矩矩不出歧义。5.3 配置读取的“默认值哲学”很多人在做配置读取时只考虑了“文件里写了什么就读什么”没有考虑读不出来时怎么办。但在实际项目中SD卡可能没插、文件可能被误删、格式可能有误任何一种情况都可能导致读取失败。这时候怎么处理崩溃吗不行。用一组默认值继续跑是唯一合理的方案。于是我在读取每个参数时都指定一个默认值并且启动时先用默认值配置系统然后再尝试读取ini里的覆盖值。这个设计很符合软件工程里的“fail-safe”思想开机默认参数能跑——保证设备绝不因为配置问题就罢工若有配置文件则覆盖默认值——满足个性化调整需求文件损坏或缺失时设备用默认配置启动并记录一条警告日志——“config.ini不存在使用默认参数”。这样一来现场人员即使误删了SD卡里的文件设备也能继续运转。而且我在系统状态LED上还会给出提示告诉维护人员配置文件丢了。5.4 配置检查与回写机制读取配置之后还有一个容易被忽略的点参数校验。ini文件是文本用户有可能把speed_rpm填成“abc”或者填一个超出电机能承受范围的数值。解析出来的值是字符串转换成整数时必然会有判断但这个判断只是“是不是数字”还得设置合理范围。我的做法是解析完成后调用一个config_sanitize函数逐项检查所有配置值的范围越界的强制拉回最大最小值不合法的直接恢复默认值。还有另一种应用场景是配置回写。例如用户通过手机APP修改了电机参数APP通过MQTT把新参数下发到设备设备实时调整运动参数后需要把这些新参数固化到SD卡里保证下次上电依然生效。这时就需要一个ini_set_value功能能修改内存中的配置对象并写回config.ini文件。我在固件中实现了这个功能先读入原文件逐行匹配key并覆盖新值然后写回临时文件最后替换原文件。整个过程注意断电保护先完整写临时文件。即使写了一半掉电原文件还有效。5.5 日志文件命名与轮转ini配置文件解决了参数问题之后还有一个问题是日志文件怎么管理。如果日志一直追加到同一个文件文件会越来越大SD卡总会被写满。我的方案是日志系统按日期生成文件——比如LOG_20240115.TXT每天一个文件保留最近30天更早的自动删除。这个逻辑在文件任务里周期性检查一遍用f_findfirst和f_findnext遍历日志目录按文件修改时间删掉过期文件。这里面有一个值得注意的问题FAT32文件系统的簇大小与SD卡容量有关。容量越大默认簇越大小文件占用的空间也越多。如果一张64GB的卡格式化默认簇大小是32KB存一个内容只有100字节的日志文件实际占用还是32KB写几万个日志文件就会消耗几GB空间。所以如果你的项目要写大量小文件格式化SD卡时可以考虑手动设置较小的簇大小。当然插入设备时用程序格式化也不能自由控制簇大小但你可以用电脑格式化时做这个选择。这是很多人都忽略的坑我特意写出来提醒一下。6. 和MQTT任务的数据流转从云端到SD卡再到现场调试这一篇的主题虽然是SD卡和FatFS但如果你把它放回到整个物联网系统中看实际上SD卡是MQTT通信链路的一个重要补充。这里我简单说一下三者怎么配合工作方便你理解整体架构。6.1 参数更新的双通道机制步进电机的运动参数速度、加速度、细分有两条更新路径一条是通过MQTT订阅云端下发的指令另一条就是上电时从SD卡的config.ini里读取本地配置。两条通道还需要有优先级关系当MQTT下发新指令时设备把新参数更新到运行参数中并同时本地回写config.ini文件当设备重启后从config.ini读到的就是上次MQTT下发过的最新参数。这样即使云端暂时连不上设备依然能保持上次的配置运行。我在代码里用了一个结构体来存储所有运行参数两个来源都修改这个结构体然后由“参数变更通知”机制告知电机控制任务重新计算加减速曲线。这种做法比直接在文件系统、网络栈和电机控制之间互相调用要清晰得多。6.2 断网日志补传日志记录的实际用途之一是断网诊断。设备断网时MQTT链路断了但设备本身还在运行电机可能持续在工作中。这个时间段内的事件不能丢失所以我让日志系统把这些事件实时写入SD卡。网络恢复后一个专门的“补传任务”会扫描SD卡里尚未上传的日志段尝试通过MQTT发布到云端。这个机制在公司部署的多个现场设备里非常管用。有一次现场反馈设备在凌晨3点莫名停机第二天我通过云端收到了设备在断网期间记录的电机电流异常日志锁定是负载瞬时过大触发了过流保护。如果没有SD卡日志备份这种偶发现象几乎没法定位。6.3 固件远程升级中的SD卡角色顺便提一个我在项目里验证过的扩展固件升级文件也可以暂时放在SD卡里。云端通过MQTT下发升级固件时如果固件比较大几十KB到几百KB直接放在RAM里解析会吃掉太多资源。我的做法是把收到的固件先写入SD卡校验完整后再引导Bootloader从SD卡读取固件并完成升级。这种方式比传统的串口升级稳定得多——升级文件不怕断电随时可重来。7. 移植完成后实测中必须验证的几个边界场景这一篇写到这里无非是提供代码思路和原理分析。但实际的坑比我在前面提到的还要多。所以我把实测阶段必须做的事和你可能要经历的排查过程好好列一下。7.1 拔卡和异常断电测试SD卡方案最怕的是什么是拔卡。而且是系统正在写文件时拔开。如果只在启动时读配置写的时候不多这个问题不大。一旦开了日志功能运行中随时有SD卡写入就一定要考虑拔卡场景。拔卡瞬间底层驱动可能卡在等待SD卡响应的状态。SDIO外设在读SD卡时如果卡没了内部状态机会超时。这个超时时间如果不设置默认可能很长会导致文件任务长时间阻塞。我的做法是利用HAL_SD_GetCardState的返回值来检查卡状态在disk_read和disk_write中加入超时判断超时后直接返回错误让FatFS感知到磁盘错误。等卡重新插入时再调用disk_initialize恢复文件系统。断电测试则更痛苦但也更重要在写日志的过程中直接断电反复几十次然后检查SD卡上的文件系统是否损坏。FAT文件系统写操作如果正好卡在FAT表更新时断电确实有损坏风险。FatFS的f_sync可以降低风险窗口的宽度但不能完全消除。因此日常运行中建议每几条或每几秒就sync一次宁可写入次数多一点也不要让数据在内存中积压太久。7.2 兼容性测试不同品牌、不同容量的SD卡千万别假设SD卡都长一个样。我实测过市面上常见的几个品牌的SD卡发现初始化时序和读写兼容性差异明显。有些卡在SPI模式下拉不上去虽然标注是SPI兼容有些卡在DMA方式读写时会出现偶发性CRC校验错误还有极少数卡在SDIO 4bit模式下完全无法工作只能降级到1bit模式。所以在批量产品出厂前我建议至少测5种以上不同品牌、不同容量的卡验证初始化、读写、格式化、拔插等场景。如果没有条件测那么多优先选择工业级的SD卡工作温度-40℃~85℃虽然贵一点但在振动和温度环境下稳定性好很多。另外SD卡的品质参差不齐很多高速卡Class10、UHS-I在STM32F103的系统里反而不如老旧的Class4卡稳定。这不是玄学而是高速卡内部电压转换逻辑可能和STM32的3.3V电平不匹配导致信号完整性问题。如果你的板子上SD卡走线较长试试降低SDIO时钟频率比如降到12.5MHz大概率能解决很多信号问题。7.3 文件系统长期运行的“磨损”与写入次数SD卡是闪存每个扇区的擦写次数有限消费级卡一般在几百次到几千次P/E。如果日志系统高频写入固定位置比如每次都更新某个文件头部的时间戳长期运行下来这个区域的闪存会先于其他区域失效。还好FAT文件系统在设计时会把文件数据的扇区分散在整张卡上加上SD卡内部的磨损均衡机制正常情况下不会太快损耗。但如果你的日志文件反复追加、删除、再追加文件碎片会越来越严重写入性能也会逐渐下降。我的方案是每周或每月生成一个新的日志文件并控制文件总数这样文件不会长期集中在同一个区域。定期清理旧日志也很有必要如果日志能通过MQTT上传到云端本地只保留近期一小部分即可。写在最后这套基于FreeRTOS、MQTT和SD卡的方案在我的步进电机控制器项目上已经稳定运行了很长时间。最让我欣慰的是现场调试效率的提升——以前改一个电机参数需要带电脑、连调试器、重新烧录现在只要把SD卡拔出来记事本改一个数字插回去重启一遍就完事了。对于一个物联网设备的研发和运维来说这种“用户能自行调整”的灵活性某种意义上比增加更多新功能更重要。如果让我重新做一遍这套系统最希望能提前做的是给配置文件解析写好完整的异常注入测试。很多问题都是到了现场才暴露出来的手误删了一行、多加了一个空格、文件编码变成了UTF-8带BOM……这些在你自己电脑上不容易复现的情况在用户手里就是日常。只有提前把解析器打磨得足够健壮才能在各种意外输入面前依然安全运行。下一步我计划在这个基础上做Bootloader的远程升级功能机器人在线接收固件并更新到SD卡再引导重启。那会用到更多FreeRTOS底层机制和FatFS的写保护切换功能等测试稳定了再来和大家分享。 基于FreeRTOS的SD卡驱动与FatFS移植：步进电机控制器本地存储方案
这个系列写到第三篇前两篇我们解决了FreeRTOS的系统移植和MQTT通信链路步进电机也能正常转了。但做到这一步你会发现整套设备还缺一个特别关键的东西——本地存储。电机参数、配置文件、运行日志总不能每次都打开调试器改代码重新烧录吧。于是就有了这一篇的内容SD卡驱动、FatFS文件系统移植以及ini配置文件读取的实现。需要说明的是这篇文章虽然叫“步进电机控制三”但SD卡、FatFS和ini解析这套方案其实完全可以单独拿出来用在你手头任何一个需要本地存储的物联网项目上。我会尽量把每一步的“为什么这样做”讲透而不是只贴代码让你复制粘贴。因为SD卡这玩意做起来问题特别多网上教程也五花八门你不理解底层原理遇到问题根本无从下手。1. 为什么步进电机控制器需要一张SD卡很多初学者会问一个问题我一个电机控制器要SD卡干嘛数据又不复杂为什么不直接把参数写死在代码里或者存到Flash里这个问题问得很有道理。当初我在设计这套系统时一开始也是把电机参数放在结构体里每次改参数就重新编译、下载、复位几分钟的事情。但当你把设备部署到现场或者要交给非技术人员使用的时候问题就来了。现场调试时你可能需要根据负载情况微调电机的加减速曲线、细分设置、回零速度——这些参数如果都在代码里每一次调整都需要带着电脑去现场插上ST-Link重新烧录。而且一旦改错还得还原。用SD卡存放一个配置文件让设备上电时自动读取改动就变成了一件极其简单的事情拔卡插到电脑上用记事本改参数插回去重启。任何会使用记事本的人都能完成参数调整这是第一个刚需。第二个刚需是日志记录。工业控制现场设备出问题时最让人头疼的就是“不知道它在什么时间发生了什么”。电机堵转、通信超时、急停触发——这些事件如果能按时间戳记录到SD卡里事后排查起来会轻松得多。我的做法是让FreeRTOS的一个低优先级任务定时把环形队列里的日志刷入SD卡这样既不阻塞实时控制任务又能保证关键数据落盘。第三个刚需和MQTT有关。联网设备难免遇到断网MQTT链路断了之后传感器采集到的数据如果只存在内存里RAM有限存不了多少而且一断电就全丢。SD卡可以作为断网期间的本地缓存区恢复通信后再把数据补传上去。STM32F103RCT6这种级别的芯片内部Flash才256KBRAM才48KB你要缓存大量数据根本不现实。一张2GB的SD卡对日志和参数配置来说永远用不完。所以说SD卡在这个项目里的定位实际上是一个“可移动的本地存储介质”。它既承载了参数配置的灵活性又提供了日志记录的空间同时也是断网缓存的基础。理解了这些你再回过头来看后面的驱动移植和文件系统就会明白每一部分解决的是什么实际问题。2. SD卡底层驱动选SDIO还是SPI初始化顺序才是重点SD卡和单片机通信有两种主流方式SDIO和SPI。很多新手一上来就纠结选哪个其实这个选择没有绝对的好坏完全看你的应用场景和硬件资源。2.1 SDIO与SPI的关键差异我直接给一张对比表这是我在实际项目中反复权衡后得出的结论对比项SDIO接口SPI接口通信速率最高可达48MHz4bit模式一般18MHz~36MHz具体看分频引脚占用CLK、CMD、D0~D3共6个引脚CS、SCK、MOSI、MISO共4个引脚是否支持4bit模式支持传输速度快不支持只能1bit驱动复杂度较复杂需要处理命令应答和CRC相对简单逻辑更直观DMA支持STM32的SDIO外设支持但要注意FIFOSPI配合DMA也很成熟兼容性标准SD卡和microSD卡都支持对卡的兼容性稍差部分卡在SPI模式下有兼容性问题如果你用的是STM32F103系列它的SDIO外设是支持4bit模式的实际读写速度比SPI快很多。做步进电机控制时如果你需要频繁记录运动状态或者要写入较大的日志我会无脑推荐SDIO。但要注意SDIO的时序要求更严格遇到问题也更难排查。如果你的项目对速率不敏感比如只用来存配置参数、偶尔写点状态数据那SPI反而更省引脚、代码也更简单排查问题容易得多。我这套系统用的是SDIO 4bit模式配DMA原因很简单我需要日志实时落盘而且电机运行过程中还要实时记录位置和电流数据速度太慢了会影响数据完整性。如果你的系统对速度没这么高要求选SPI完全够用后面我讲底层驱动的思路两种接口也是通用的。2.2 SD卡初始化的先后顺序SD卡驱动里最核心的难点不是读写而是初始化。很多人的卡读写不稳定九成以上是初始化过程出了问题。SD卡的初始化其实是一个状态机你必须按照规范里的顺序来不能跳步上电后先延时至少74个时钟周期给卡内部上电稳定时间发送CMD0把卡切到SPI模式或确认SDIO模式发送CMD8确认卡支持的电压范围这是判断SD V2.0以上卡的关键循环发送ACMD41在SDIO模式下或ACM41在SPI模式下直到卡返回空闲状态发送CMD2获取CID发送CMD3获取RCA相对卡地址发送CMD7选中卡然后发送CMD6读取SCR判断卡支持的位宽模式如果要切4bit模式发送ACMD6设置位宽。这里有个常见的坑很多教程里一笔带过的“延时”其实非常讲究。卡上电后内部的电压稳定需要时间74个时钟周期只是最低要求实测中有些卡需要更久。我曾经碰到一张老旧的TF卡上电后立刻初始化大概率失败多等500ms就百分百成功。所以我在初始化函数开头加了一个可配置的延时参数默认500ms所有卡都能稳稳通过。另外一个重点是CMD8和ACMD41的配合。CMD8会返回卡的电压范围信息如果返回的状态不正确说明这张卡可能不支持你当前的电压区间。ACMD41的循环发送次数也有限制不能无限循环等卡响应一般循环100次左右就可以判断初始化失败。我见过有的代码里没有循环上限一旦卡损坏或者接触不良整个程序就死在初始化里连FreeRTOS的任务调度器都启动不了——这在实时系统里是不可接受的。2.3 底层的读、写、擦除函数怎么设计SD卡底层的核心操作无非三个读单块/多块、写单块/多块、擦除。SD卡的读写最小单位是一个扇区通常是512字节。也就是说哪怕你只想读1个字节底层也会把整个512字节读上来再从缓冲区里取出那个字节。理解了这一点你就能明白为什么FatFS在操作小文件时效率会有损耗。我的底层驱动封装了四个函数SD_ReadBlocks、SD_WriteBlocks、SD_EraseBlocks、SD_GetStatus。前两个都带DMA版本因为FreeRTOS环境下如果你用阻塞式读写一个读操作可能卡住几十毫秒这种延时对于PID控制循环来说简直是灾难。DMA方式的好处是CPU只需要发起传输然后就可以去做别的事等DMA传输完成中断再回来处理结果。这里要特别提醒DMA缓冲区必须放在特定的内存区域。STM32F103的DMA1和DMA2都不能访问所有内存地址比如F103的DMA无法访问CANTB和SDIO的FIFO区域时而SDIO外设的FIFO地址必须用DMA访问这就需要对缓冲区地址做些处理。实际中问题更常见的是如果缓冲区定义在堆上malloc动态分配或者某个特定的内存段而该地址不在DMA可访问范围内DMA传输会直接卡死或者传输错误数据。所以我在项目里统一使用静态分配的全局缓冲区定义在__attribute__((section(DMA_RAM)))指定段里。你如果用CubeMX生成代码它会自动帮你处理好这些细节这也是我建议新手直接用CubeMX的原因之一。DMA传输完成后还要做一件事检查数据CRC是否正确。SD卡协议里每个数据块后面都跟了CRC校验信息虽然实际使用中很多人会忽略这个校验但我在日志系统里还是加上了校验失败重传的逻辑。SD卡终究是机械闪存结构在工业现场振动环境下数据可能出现位翻转错误。一次校验失败就重读一次能解决绝大部分偶发错误。3. FatFS移植连接文件系统与底层驱动的五个关键函数底层SD卡驱动搞定后你在单片机上面对的是一个个扇区使用起来非常痛苦。比如你想存一条日志“2024-01-15 10:30:25 电机A堵转”如果直接在扇区里按固定偏移写那改一个字节可能要把整个扇区读出来改完再写回去。要管理多个文件更是不可能。所以我们需要文件系统这一层抽象。FatFS是一个面向嵌入式场景的FAT文件系统实现大名鼎鼎在STM32上几乎是标配。3.1 FatFS的分层架构和移植思路FatFS的分层很清晰从上到下是应用层f_open、f_read、f_write、f_close这些API供你的业务代码直接调用FatFS模块层文件系统逻辑、FAT表管理、目录操作这部分完全不需要你修改底层接口层disk_initialize、disk_read、disk_write、disk_ioctl、disk_status这些是FatFS和你的硬件驱动之间的桥梁也是移植时唯一需要你动手写代码的地方。这个设计非常巧妙它把和硬件相关的部分完全隔离在底层接口层。不管你用的是SDIO还是SPI、SD卡还是NAND Flash甚至是片内Flash模拟的U盘只需要实现这几个接口FatFS的整个文件系统逻辑就能原封不动地跑起来。3.2 每个disk_xx函数的实现要点我逐个讲一下这几个函数因为这里面的细节直接决定了文件系统稳不稳。disk_initialize这个函数在FatFS调用f_mount时被触发。实现要点是调用前面写好的SD_Init完成底层初始化并返回操作结果。要注意这个函数可能被反复调用比如拔卡重插后重新挂载所以内部不能有只能执行一次的静态判断逻辑。disk_statusFatFS的f_mount内部会先调用disk_status检查磁盘状态返回STA_NOINIT表示未初始化FatFS就会自动调用disk_initialize。所以这个函数不需要太多逻辑把SD卡的状态变量返回上去即可。我还在里面加了检测卡插入状态的逻辑用SDIO的数据线D3上的上拉状态来判断是否有卡插入SD卡规范里D3线空闲状态是高电平这样我能实时感知卡是否被拔出。disk_read三个参数扇区号、缓冲区指针、扇区数量。实现时要处理两种情况单扇区读和多扇区读。SDIO的读操作支持连续多块读取效率很高。但如果缓冲区不是4字节对齐的从FatFS传下来的指针一般是对齐的DMA会出错。我在这里加了一个分支如果指针地址不是4的倍数就退回到轮询方式读单块虽然慢一点但不会出错。disk_write同样处理单块和多块。这里有一个重要区别SD卡写操作之前必须保证目标扇区是擦除过的。FAT文件系统在逻辑上会保证这一点因为它在写文件之前会先更新FAT表分配扇区那些扇区理论上已经是擦除状态。但SD卡内部的FTL闪存转换层会用逻辑映射把擦除操作隐藏所以你的驱动里不需要主动做擦除操作直接写就行。disk_ioctl这是一个命令分发函数用来处理FatFS发来的各种控制命令。最常见的是CTRL_SYNC和GET_SECTOR_SIZE。CTRL_SYNC要求把所有缓存在硬件层的数据真正写到盘上对于SD卡来说就是等待之前发起的写操作完成GET_SECTOR_SIZE返回扇区大小一般是512。还有个CTRL_TRIM命令如果开启了这个配置项文件删除时会触发底层擦除延长SD卡寿命。我在日志系统里会定期清理旧日志开启TRIM能减少闪存写入放大。3.3 ffconf.h里的关键开关FatFS的灵活性体现在ffconf.h配置头文件里移植时这些开关直接影响你后续所有操作FF_USE_LFN长文件名支持。设为1时在ARM上需要额外的静态缓冲区来存放长文件名转换结果设为2时动态申请内存但FreeRTOS环境下堆管理有碎片问题我建议用静态缓冲区。这个开关不开超过8.3格式的文件名全部乱码。FF_FS_RTC时间戳支持。开启后需要提供一个get_fattime()函数返回当前时间。我的系统里维护了一个从MQTT同步的RTC时间get_fattime直接读RTC寄存器拼接成FAT时间格式。有这个功能日志文件里才能看到正确的时间戳排查问题时太重要了。FF_USE_MKFS格式化功能。如果你不想用电脑给SD卡格式化成FAT32想让设备自己格式化就需要开启这个。SD卡出厂一般是FAT32但偶尔拿到一张格式不对的卡开机时如果挂载失败我就可以提示用户选择是否让设备自动格式化。FF_FS_EXFATexFAT支持。嵌入式设备一般用不上而且exFAT有专利问题我默认关闭。FF_MULTI_PARTITION多分区支持。如果一张卡要分两个区存储不同类型数据可以开这个。但大多数场景不需要保持默认就行。3.4 挂载和文件读写时序文件系统挂载和访问有固定的时序要求。正确流程是上电初始化SD卡调用f_mount挂载文件系统。如果返回FR_NO_FILESYSTEM说明卡上还没有有效的FAT文件系统这时可以提示用户格式化之后就可以正常f_open、f_read、f_write、f_close了系统关机前必须f_mount(NULL, ...)卸载文件系统并把底层SD卡切回空闲状态确保所有缓存数据已经落盘。断电保护是个值得专门说的话题。很多人直接在写文件过程中断电结果下次开机发现文件损坏或者整个目录都乱了。FatFS用f_sync可以强制把缓冲区数据刷到盘上这个函数在写日志时非常有用。我的策略是日志每积累一定条数或者每过一定时间间隔就调用一次f_sync把文件系统缓存亮到SD卡上。虽然频繁sync多一点时序开销但换来的是断点不丢数据的安全感。注意f_open后每隔一段时间f_sync一次是一个被很多老工程师验证过的最稳妥方案比f_close之后重新打开要安全得多。因为f_close内部也做了类似sycn的操作但它要求你上一次写的句柄全部合法。在长时间运行的系统里反复打开关闭文件容易积累句柄冲突问题。4. FreeRTOS环境下的文件系统访问稍不留神就踩的内存和调度坑在裸机环境下使用FatFS写个文件和在FreeRTOS多任务环境下使用完全不是一个难度等级。这里要处理的不是文件系统本身而是并发资源访问和任务调度问题。4.1 FatFS本身不是线程安全的这是最重要的一句话FatFS的API在默认配置下不保证多任务安全。如果两个任务同时调用f_open或者f_write内部的全局工作区变量就会被互相覆盖轻则写错数据重则直接HardFault。解决方案是在文件系统外面套一层互斥锁。我建了一个统一的文件系统访问入口模块内部维护一个FreeRTOS互斥量。所有对FatFS API的调用都通过这个模块转发进入函数时拿锁出函数时放锁。这样虽然会让文件系统访问串行化但换来了绝对的安全性。在实际项目中文件操作本来就不是高频操作串行化的影响完全可以忽略。用互斥锁而不是二值信号量是故意的。互斥量具备优先级继承机制如果一个低优先级任务拿着锁高优先级任务来敲门时系统会把低优先级任务的优先级临时提升到高优先级任务的级别从而避免优先级反转问题。这是嵌入式实时系统里非常经典的一个场景如果你用二值信号量优先级反转的情况会真实发生表现为一个高优先级控制任务被一个低优先级文件任务卡住几十毫秒这在运动控制里是致命的。4.2 文件操作任务和电机控制任务的调度关系步进电机控制这类应用里实时控制任务的调度周期通常在1ms到10ms之间而且这个任务是硬实时的不能被长时间打断。但SD卡写操作哪怕用了DMA也可能被文件系统日志计算、FAT表更新等操作占住几百微秒。如何协调两者我的做法是把文件系统操作独立成一个任务优先级设到最低。电机控制任务需要记录数据时不发文件操作请求而是把数据塞到一个环形缓冲区里然后给文件任务发送一个通知。文件任务收到通知后才把环形缓冲区里的数据取出来组织成日志行再写入SD卡。这个设计的好处是电机控制任务永远只做轻量的内存操作不会因为SD卡忙而阻塞。SD卡慢一点没关系反正数据已经进了环形缓冲区只要缓冲区容量够大别溢出就行。环形缓冲区的容量可以根据SD卡最慢写入时间和数据产生速率来计算。比如我每秒产生200字节日志SD卡最差写入速度是5KB/s环形缓冲区留个10KB就足够撑过最坏情况了。4.3 任务栈分配与内存泄漏的隐性坑FreeRTOS每个任务的栈是独立分配的文件系统操作尤其是开了长文件名和路径解析后栈消耗会比想象中大得多。FatFS的f_open内部处理长文件名时静态缓冲区加上局部变量轻松吃掉几百字节栈空间。如果你给文件任务只分了512字节的栈运行一段时间后就会栈溢出表现就是系统的“某一个功能偶发性死机”——特别难排查。我的经验值是文件系统相关任务的栈至少给1024字节加上日志格式化用snprintf的话最好给1536字节以上。你可以在FreeRTOS里用uxTaskGetStackHighWaterMark函数检测每个任务的栈剩余空间把系统跑上几天后把这些数据打出来看看这是排查栈溢出的最直观手段。还有一个非常隐蔽的坑是堆碎片化。FreeRTOS默认的pvPortMalloc实现heap_4.c支持合并相邻空闲块但长期高频地分配和释放大小不等的内存块依然可能产生不可合并的碎片。文件操作时如果你用f_malloc动态分配长文件名缓冲区或者日志任务每处理一条日志都malloc一块临时内存时间长了堆会慢慢变小直至分配失败。我的建议是文件系统相关的缓冲区尽量定义为静态变量或任务内局部变量减少动态分配如果非要动态分配就用内存池而不是通用堆。5. ini配置文件读取小身材、大作用但请你别真的手写解析器前面SD卡驱动和FatFS都搞定了到了这一步设备的存储能力已经具备了。但存储只是基础真正让用户方便的是“改一个文件就能改设备行为”的体验。这时候就要用到配置文件了。常见的配置文件格式有JSON、YAML、ini等。在单片机上我选了ini格式。5.1 为什么嵌入式场景选ini而不是JSONJSON在Web领域是主流但在单片机上用JSON纯属找罪受。解析JSON需要一个功能比较完整的解析器占用几千字节的代码空间很正常。而ini格式极其简单本质上就是“节section”“键值对keyvalue”用几百行C代码就能写一个够用的解析器。拿我的电机控制配置举例配置文件长这样[motor1] enable1 microstep8 speed_rpm120 accel_profilesmooth max_current1.5 [motor2] enable0 microstep16 speed_rpm80 accel_profiletrapezoid max_current0.8 [system] debug_level2 log_enable1 ble_enable0用config.ini记录这些任何一个工程师拿到脑子里就能看懂。JSON版本长什么样括号、引号、逗号——你虽然不嫌多但对一个低性能MCU来说解析JSON的开销纯属浪费。而且ini文件可以直接用记事本修改用不着专门工具这对现场调试的友好度是很重要的。5.2 解析器的核心设计思路既然决定用ini接下来就是怎么解析的问题。网上能找到很多开源的ini解析库比如minIni但我建议你自己先写一版因为需求非常简单而且自己写能完全掌控内存占用。我的解析器核心就两个接口int ini_get_int(const char* filename, const char* section, const char* key, int default_val); const char* ini_get_string(const char* filename, const char* section, const char* key, const char* default_str);每次调用时解析器打开文件、逐行读取、跳过空白行和注释行以;开头的行、判断当前处于哪个section然后在目标section里查找目标key。找到后返回对应的值如果没找到返回默认值。这个设计是典型的“无状态解析器”每次调用都从头解析文件优点是简单、无内存残留缺点是多次调用时会重复读文件性能差一点。但配置文件读取一般只发生在上电启动阶段运行中很少反复读取所以完全能接受。解析过程中有两个细节值得注意第一个是字符串值的缓存问题。ini_get_string返回一个const char*这个指针不能是临时缓冲区否则函数一返回就失效了。我的做法是调用者传入一个缓冲区解析器把字符串填进去。虽然丑但非常可靠。char cfg_buffer[32]; ini_get_string(config.ini, system, wifi_ssid, default, cfg_buffer, sizeof(cfg_buffer));第二个是注释处理。ini格式的注释标准并不统一有人用;有人用#有的还支持行尾注释。我建议只支持行首注释因为行尾注释处理起来有歧义如果value本身包含#字符呢比如ssidmy_wifi#2行尾注释解析器就会把#2截掉导致配置错误。所以行首注释最安全规规矩矩不出歧义。5.3 配置读取的“默认值哲学”很多人在做配置读取时只考虑了“文件里写了什么就读什么”没有考虑读不出来时怎么办。但在实际项目中SD卡可能没插、文件可能被误删、格式可能有误任何一种情况都可能导致读取失败。这时候怎么处理崩溃吗不行。用一组默认值继续跑是唯一合理的方案。于是我在读取每个参数时都指定一个默认值并且启动时先用默认值配置系统然后再尝试读取ini里的覆盖值。这个设计很符合软件工程里的“fail-safe”思想开机默认参数能跑——保证设备绝不因为配置问题就罢工若有配置文件则覆盖默认值——满足个性化调整需求文件损坏或缺失时设备用默认配置启动并记录一条警告日志——“config.ini不存在使用默认参数”。这样一来现场人员即使误删了SD卡里的文件设备也能继续运转。而且我在系统状态LED上还会给出提示告诉维护人员配置文件丢了。5.4 配置检查与回写机制读取配置之后还有一个容易被忽略的点参数校验。ini文件是文本用户有可能把speed_rpm填成“abc”或者填一个超出电机能承受范围的数值。解析出来的值是字符串转换成整数时必然会有判断但这个判断只是“是不是数字”还得设置合理范围。我的做法是解析完成后调用一个config_sanitize函数逐项检查所有配置值的范围越界的强制拉回最大最小值不合法的直接恢复默认值。还有另一种应用场景是配置回写。例如用户通过手机APP修改了电机参数APP通过MQTT把新参数下发到设备设备实时调整运动参数后需要把这些新参数固化到SD卡里保证下次上电依然生效。这时就需要一个ini_set_value功能能修改内存中的配置对象并写回config.ini文件。我在固件中实现了这个功能先读入原文件逐行匹配key并覆盖新值然后写回临时文件最后替换原文件。整个过程注意断电保护先完整写临时文件。即使写了一半掉电原文件还有效。5.5 日志文件命名与轮转ini配置文件解决了参数问题之后还有一个问题是日志文件怎么管理。如果日志一直追加到同一个文件文件会越来越大SD卡总会被写满。我的方案是日志系统按日期生成文件——比如LOG_20240115.TXT每天一个文件保留最近30天更早的自动删除。这个逻辑在文件任务里周期性检查一遍用f_findfirst和f_findnext遍历日志目录按文件修改时间删掉过期文件。这里面有一个值得注意的问题FAT32文件系统的簇大小与SD卡容量有关。容量越大默认簇越大小文件占用的空间也越多。如果一张64GB的卡格式化默认簇大小是32KB存一个内容只有100字节的日志文件实际占用还是32KB写几万个日志文件就会消耗几GB空间。所以如果你的项目要写大量小文件格式化SD卡时可以考虑手动设置较小的簇大小。当然插入设备时用程序格式化也不能自由控制簇大小但你可以用电脑格式化时做这个选择。这是很多人都忽略的坑我特意写出来提醒一下。6. 和MQTT任务的数据流转从云端到SD卡再到现场调试这一篇的主题虽然是SD卡和FatFS但如果你把它放回到整个物联网系统中看实际上SD卡是MQTT通信链路的一个重要补充。这里我简单说一下三者怎么配合工作方便你理解整体架构。6.1 参数更新的双通道机制步进电机的运动参数速度、加速度、细分有两条更新路径一条是通过MQTT订阅云端下发的指令另一条就是上电时从SD卡的config.ini里读取本地配置。两条通道还需要有优先级关系当MQTT下发新指令时设备把新参数更新到运行参数中并同时本地回写config.ini文件当设备重启后从config.ini读到的就是上次MQTT下发过的最新参数。这样即使云端暂时连不上设备依然能保持上次的配置运行。我在代码里用了一个结构体来存储所有运行参数两个来源都修改这个结构体然后由“参数变更通知”机制告知电机控制任务重新计算加减速曲线。这种做法比直接在文件系统、网络栈和电机控制之间互相调用要清晰得多。6.2 断网日志补传日志记录的实际用途之一是断网诊断。设备断网时MQTT链路断了但设备本身还在运行电机可能持续在工作中。这个时间段内的事件不能丢失所以我让日志系统把这些事件实时写入SD卡。网络恢复后一个专门的“补传任务”会扫描SD卡里尚未上传的日志段尝试通过MQTT发布到云端。这个机制在公司部署的多个现场设备里非常管用。有一次现场反馈设备在凌晨3点莫名停机第二天我通过云端收到了设备在断网期间记录的电机电流异常日志锁定是负载瞬时过大触发了过流保护。如果没有SD卡日志备份这种偶发现象几乎没法定位。6.3 固件远程升级中的SD卡角色顺便提一个我在项目里验证过的扩展固件升级文件也可以暂时放在SD卡里。云端通过MQTT下发升级固件时如果固件比较大几十KB到几百KB直接放在RAM里解析会吃掉太多资源。我的做法是把收到的固件先写入SD卡校验完整后再引导Bootloader从SD卡读取固件并完成升级。这种方式比传统的串口升级稳定得多——升级文件不怕断电随时可重来。7. 移植完成后实测中必须验证的几个边界场景这一篇写到这里无非是提供代码思路和原理分析。但实际的坑比我在前面提到的还要多。所以我把实测阶段必须做的事和你可能要经历的排查过程好好列一下。7.1 拔卡和异常断电测试SD卡方案最怕的是什么是拔卡。而且是系统正在写文件时拔开。如果只在启动时读配置写的时候不多这个问题不大。一旦开了日志功能运行中随时有SD卡写入就一定要考虑拔卡场景。拔卡瞬间底层驱动可能卡在等待SD卡响应的状态。SDIO外设在读SD卡时如果卡没了内部状态机会超时。这个超时时间如果不设置默认可能很长会导致文件任务长时间阻塞。我的做法是利用HAL_SD_GetCardState的返回值来检查卡状态在disk_read和disk_write中加入超时判断超时后直接返回错误让FatFS感知到磁盘错误。等卡重新插入时再调用disk_initialize恢复文件系统。断电测试则更痛苦但也更重要在写日志的过程中直接断电反复几十次然后检查SD卡上的文件系统是否损坏。FAT文件系统写操作如果正好卡在FAT表更新时断电确实有损坏风险。FatFS的f_sync可以降低风险窗口的宽度但不能完全消除。因此日常运行中建议每几条或每几秒就sync一次宁可写入次数多一点也不要让数据在内存中积压太久。7.2 兼容性测试不同品牌、不同容量的SD卡千万别假设SD卡都长一个样。我实测过市面上常见的几个品牌的SD卡发现初始化时序和读写兼容性差异明显。有些卡在SPI模式下拉不上去虽然标注是SPI兼容有些卡在DMA方式读写时会出现偶发性CRC校验错误还有极少数卡在SDIO 4bit模式下完全无法工作只能降级到1bit模式。所以在批量产品出厂前我建议至少测5种以上不同品牌、不同容量的卡验证初始化、读写、格式化、拔插等场景。如果没有条件测那么多优先选择工业级的SD卡工作温度-40℃~85℃虽然贵一点但在振动和温度环境下稳定性好很多。另外SD卡的品质参差不齐很多高速卡Class10、UHS-I在STM32F103的系统里反而不如老旧的Class4卡稳定。这不是玄学而是高速卡内部电压转换逻辑可能和STM32的3.3V电平不匹配导致信号完整性问题。如果你的板子上SD卡走线较长试试降低SDIO时钟频率比如降到12.5MHz大概率能解决很多信号问题。7.3 文件系统长期运行的“磨损”与写入次数SD卡是闪存每个扇区的擦写次数有限消费级卡一般在几百次到几千次P/E。如果日志系统高频写入固定位置比如每次都更新某个文件头部的时间戳长期运行下来这个区域的闪存会先于其他区域失效。还好FAT文件系统在设计时会把文件数据的扇区分散在整张卡上加上SD卡内部的磨损均衡机制正常情况下不会太快损耗。但如果你的日志文件反复追加、删除、再追加文件碎片会越来越严重写入性能也会逐渐下降。我的方案是每周或每月生成一个新的日志文件并控制文件总数这样文件不会长期集中在同一个区域。定期清理旧日志也很有必要如果日志能通过MQTT上传到云端本地只保留近期一小部分即可。写在最后这套基于FreeRTOS、MQTT和SD卡的方案在我的步进电机控制器项目上已经稳定运行了很长时间。最让我欣慰的是现场调试效率的提升——以前改一个电机参数需要带电脑、连调试器、重新烧录现在只要把SD卡拔出来记事本改一个数字插回去重启一遍就完事了。对于一个物联网设备的研发和运维来说这种“用户能自行调整”的灵活性某种意义上比增加更多新功能更重要。如果让我重新做一遍这套系统最希望能提前做的是给配置文件解析写好完整的异常注入测试。很多问题都是到了现场才暴露出来的手误删了一行、多加了一个空格、文件编码变成了UTF-8带BOM……这些在你自己电脑上不容易复现的情况在用户手里就是日常。只有提前把解析器打磨得足够健壮才能在各种意外输入面前依然安全运行。下一步我计划在这个基础上做Bootloader的远程升级功能机器人在线接收固件并更新到SD卡再引导重启。那会用到更多FreeRTOS底层机制和FatFS的写保护切换功能等测试稳定了再来和大家分享。