AT指令读写U盘：从挂载到可靠落盘的工程实践

1. 先想清楚为什么要把U盘挂到模组上而不是绕开它很多人第一次接触“用AT指令读写U盘文件”这个需求时第一反应是绕路——既然模组算力有限、串口带宽也有限为什么不干脆加一颗单片机专门管U盘或者换成SD卡、SPI Flash这个疑问本身没错但如果真的做过几个现场项目就会明白U盘在嵌入式设备里的位置很特殊它是唯一一种用户自己就能买到、自己就能插拔、自己就能在电脑上打开看内容的存储介质。SD卡也行但普通用户手上未必有读卡器SPI Flash更是得拆机。所以凡是涉及“现场导出数据”“离线升级配置”“售后取日志”这类场景U盘几乎是零培训成本的答案。这套AT指令方案解决的核心问题是把USB Host的整套复杂度——设备枚举、SCSI命令块、FAT文件系统解析、簇链管理——全部封装进模组固件内部对外只暴露几条形如ATFSOPEN、ATFSWRITE的文本命令。你在主控MCU这边只需要一个串口发字符串、收字符串就能完成挂载、建目录、写文件、读文件、卸载的全流程。主控不需要跑USB协议栈不需要移植FatFs甚至连文件系统是什么都不用关心。对于用8位机、16位机做主控RAM只有几KB的项目这个价值是决定性的。但“能跑通”和“能用在产品里”是两码事。我见过太多人在实验室里插上U盘几条指令下去OK回来就觉得这事成了结果到了现场客户拿一个64GB的新U盘插上去模组毫无反应或者日志写了三天某次断电之后整个U盘在电脑上提示需要格式化。这些问题的根子都不在AT指令本身而在于USB供电、文件系统格式、写入时序这些“协议之外”的细节。后面几节我会把这些坑一个一个拆开讲包括完整的排查链路和实测数据。这篇文章适合三类人看一是手上有一款支持USB Host的通信模组想快速验证U盘功能是否可用的验证型开发者二是已经把功能跑通、准备往产品里集成需要评估吞吐和可靠性的工程人员三是被现场U盘问题折腾过、想弄明白底层到底发生了什么的排错者。全文的指令示例基于常见实现方式具体命令字和参数顺序请以你手上固件的指令手册为准但流程逻辑和坑位是通用的。2. 五分钟跑通的完整链路从接线到第一次回读成功2.1 硬件准备里最容易被忽略的那一项VBUS供电能力先把接线说清楚。绝大多数支持U盘功能的模组板子上会引出一个USB Host接口通常有四根线VBUS、D-、D、GND。有些板子做成标准A型母座直接插U盘有些只引出排针需要自己接一个A型座子或者用OTG转接线。这一步不难难的是很多人根本没确认过VBUS那一路到底能出多大电流。U盘的标称工作电流一般在100mA到300mA之间但这只是平均值。U盘刚插入的瞬间内部主控上电、闪存初始化浪涌电流可能冲到500mA以上持续几十毫秒到上百毫秒。如果你的模组VBUS是由内部LDO直接从主电源引出的额定只有100mA或者200mA那么现象会非常诡异有时候能识别有时候识别不了小容量U盘能用大容量U盘一插就死空U盘能挂载一读写就掉线重启。这类问题最坑的地方在于它看起来像软件问题你会去反复查AT指令顺序查了半天发现指令没错。我的建议是在动手写第一行指令之前先做一件事用一根带电流显示的USB测试线或者串一个电流表实测一下U盘插入瞬间的峰值电流。如果峰值超过你模组VBUS的额定输出就别硬扛了老老实实给U盘单独供电——用带外部供电的USB HUB或者自己做一个VBUS由独立5V电源供电、D/D-和GND仍与模组相连的转接板。注意这种情况下VBUS不要和模组的VBUS直接并联避免两路电源打架。第二件事是U盘本身的格式。这套方案走的通常是FAT文件系统解析能认的是FAT16和FAT32。NTFS、exFAT大概率不支持尤其是exFAT很多嵌入式文件系统栈压根没实现。而现在市面上买的64GB以上U盘出厂默认格式十有八九是exFAT。这就是“客户的新U盘插上去没反应”的头号原因。动手前先在电脑上把U盘格式化成FAT32簇大小用默认值即可。注意Windows自带的格式化工具对大于32GB的分区不提供FAT32选项需要用第三方工具处理这一点得提前跟客户或者产线交代清楚别等现场才发现。第三件事是串口工具。别用那种会自动在末尾补\r\n、又会把收到的二进制数据当文本渲染的简易助手。读写文件时会涉及到十六进制数据和长度字段工具至少要支持HEX收发、支持自定义行尾、支持按字节计数。我习惯用支持脚本的串口终端能把“发送命令—等待提示符—发送定长数据—等待OK”这一串动作写成宏重复测试的时候省很多事。2.2 指令时序挂载、打开、写入、回读、卸载的五段式整个流程可以归纳成五个阶段顺序不能乱查询状态 → 挂载 → 打开文件 → 读写 → 关闭并卸载。跳过卸载直接拔盘是文件系统损坏最常见的人为原因后面会专门讲。第一阶段是确认模组认到了设备。插上U盘后先发一条查询命令典型形式是ATUDISK?返回值可能是UDISK: 1表示已插入但未挂载UDISK: 0表示未检测到设备。如果一直是0先别怀疑指令回到上一节查供电和接触。有些固件会在插拔时主动上报URC形如UDISK: 1这时候你可以省掉轮询直接等这个消息。要注意URC和命令回显可能混在一起解析时得按行区分。第二阶段是挂载。命令通常是ATUDISKMOUNT或者带盘符参数的ATUDISKMOUNT0。挂载这个动作在底层做的事不少读取U盘第一个扇区拿到MBR分区表找到第一个分区起始LBA读该分区的引导扇区拿到BPB参数每扇区字节数、每簇扇区数、FAT表位置和数量、根目录起始簇然后加载FAT表的部分内容到内存缓存。整个过程耗时跟U盘容量和文件数量有关小U盘几十毫秒到几百毫秒塞满小文件的大U盘可能到一两秒。所以这条命令的超时时间别设太短给到5秒比较稳妥。第三阶段是打开文件和目录操作。列目录一般用ATFSLS路径返回值是一串文件名和大小。打开文件用ATFSOPEN句柄号,文件名,模式模式用数字表示常见约定是0读、1读写、2创建并写、3追加。句柄号是你自己指定的后续读写都用它来定位同时打开多个文件时靠这个区分。这里有个细节路径分隔符用正斜杠/根目录写/子目录要一级一级来不能指望它自动创建中间目录。很多固件提供了ATFSMKDIR路径来建目录但递归创建基本不支持得自己拆开逐级建。第四阶段是写和读。写命令一般形式是ATFSWRITE句柄号,长度模组回一个提示符表示“我准备好了你把数据发过来”然后你发送指定长度的原始字节发完等OK。这个“提示符定长”的机制是关键它让你能安全地传输二进制内容包括0x0D、0x0A这种会被文本解析器误判的字节。读命令是ATFSREAD句柄号,长度模组先回FSREAD: 实际长度这样的头然后跟原始数据。这里必须按长度截取绝不能按行读到换行为止——文件内容里到处都是换行。第五阶段是收尾。先ATFSCLOSE句柄号把缓冲区里的数据刷进闪存、更新文件长度字段再ATUDISKUMOUNT把FAT表的脏页写回、清空缓存。这两步做完U盘才算处于一致状态这时候拔盘才是安全的。2.3 一份可以直接照着敲的串口交互实录下面这段是我在验证阶段常用的最小闭环写一个几十字节的文本文件再读回来比对。所有开头的行是模组返回其余是我发送的。指令名以常见实现为例。AT OK ATUDISK? UDISK: 1 OK ATUDISKMOUNT OK ATFSMKDIR/log OK ATFSOPEN0,/log/t.txt,2 OK ATFSWRITE0,11 hello world OK ATFSCLOSE0 OK ATFSOPEN0,/log/t.txt,0 OK ATFSREAD0,11 FSREAD: 11 hello world OK ATFSCLOSE0 OK ATUDISKUMOUNT OK这套流程跑通说明硬件、格式、指令时序三样都对上了五分钟确实够。但我得提醒一句这段实录里文件只有11字节写入是原子的几乎不可能出问题。真实业务里你要写的是几KB到几MB的日志那时候才会遇到缓冲区、超时、掉电这些真正的麻烦。所以别把“跑通”当成“完成”接下来的验证重点应该放在大文件、反复插拔、异常断电这三件事上。还有个小技巧验证阶段不要只写ASCII文本。故意写一段包含0x00、0x0D、0x0A、0xFF的二进制数据进去再读回来做逐字节比对。这一步能提前暴露固件在长度处理和缓冲区边界上的问题。我见过有固件在遇到数据里包含0x1ACtrlZ时会提前截断这在纯文本测试里永远发现不了。3. 挂载失败与读写异常的排查链路3.1 枚举失败和挂载超时先分清是电的问题还是协议的问题排查这类问题我习惯先做一个二分模组到底有没有在USB总线上看到这个设备。这个信息一般能从查询命令或者URC里拿到。如果ATUDISK?一直返回0说明设备压根没被枚举上问题在物理层和供电层如果返回1但ATUDISKMOUNT一直超时或者报错说明设备枚举成功了问题在文件系统层。这两条路的排查方向完全不同混在一起查只会浪费时间。返回0的情况按这个顺序过一遍先换一根短一点的USB线长线和劣质线在高速信号上衰减明显尤其是D/D-走排线引出的板子超过10厘米就开始不稳定再换一个已知良好的小容量U盘比如8GB、16GB的USB 2.0盘排除U盘本身兼容性问题然后量VBUS电压插上U盘后如果从5.0V掉到4.5V以下基本可以确定是供电不足这时候必须外部供电最后检查D/D-有没有接反这个听起来很低级但自制转接板接反的比例相当高而且接反了通常不会烧只是死活枚举不上很容易被忽略。返回1但挂载失败的情况优先怀疑格式。把U盘插到电脑上看一眼分区表类型如果是GPT分区表很多嵌入式文件系统栈只认MBR读第一个扇区发现不是55AA结尾的引导记录就直接放弃了。解决办法是在电脑上把U盘重新分区为MBR再格式化成FAT32。另外注意有些U盘出厂带一个隐藏的引导分区或者加密分区这类盘在嵌入式环境下经常表现异常最省事的做法是整盘重新分区只留一个主分区。还有一种情况是挂载能成功但极慢动辄三五秒。这通常是因为U盘里文件太多根目录项占了几十个扇区固件在挂载时要把整个根目录扫一遍。解决办法很简单U盘上不要堆文件按日期或者设备号建子目录每个目录下控制在几十个文件以内。这个习惯对后续的列目录性能也有好处。3.2 能列目录却不能读、能写却不能回读分别意味着什么这两类现象很有代表性指向的底层环节不一样。“能列目录但不能读文件”说明挂载成功、FAT表和目录项解析正常问题出在簇链读取或者数据区寻址上。常见的具体原因有三个一是文件本身跨越了不连续的簇而固件的簇链遍历有bug读到第一个簇结束就停了表现是文件前一部分正常、后面全是乱码或者读不出二是文件大小超过固件内部缓冲区或地址变量的位宽比如用16位变量存偏移超过64KB就溢出表现是大于64KB的文件只能读出前64KB三是长文件名LFN解析有问题短文件名能读、长文件名读不了这类问题在只实现了8.3短名支持的固件上很常见。验证方法很直接分别建一个1KB、100KB、1MB的文件测试再建一个纯英文短名和一个长名文件对比。“能写但不能回读”或者“写完在电脑上看是0字节”核心是关闭文件这一步有没有真正落盘。文件长度、起始簇号这些元数据是在FSCLOSE时才写回目录项的如果只FSWRITE不FSCLOSE数据可能还在模组缓存里或者写进了数据区但目录项仍指向旧值。我在调试时养成的习惯是每写完一个文件立刻关闭然后用另一条独立的读流程去验证而不是紧接着在同一个句柄上切模式。有些固件不支持在同一个句柄上从写模式切到读模式必须关掉重开这一点手册里往往写得很含糊。还有一种更隐蔽的情况写入返回OK关闭也返回OK但在电脑上打开文件末尾少了若干字节。这通常是缓冲区刷写策略的问题——固件按扇区512字节为单位刷写最后不足一个扇区的尾巴留在缓存里如果FSCLOSE没有强制刷这个尾扇区数据就丢了。测试方法是用非512整数倍的长度反复写比如1000字节、1500字节、2000字节看每次读回来是不是都完整。这个坑我在两个不同项目上各踩过一次症状都是“大部分时候对偶尔少几十字节”排查成本极高。3.3 断电、热拔与文件系统损坏的善后处理U盘文件系统最脆弱的时间窗口就是写入过程中断电或者被拔掉。FAT32的一致性依赖于FAT表和目录项的同步更新写入新数据时要先分配簇、更新FAT表、再写数据、最后更新目录项里的文件长度。如果在这中间断电就会出现“簇被占用但没有文件指向它”的丢失簇或者“目录项长度已经更新但数据没写完”的半截文件。前者表现为U盘可用空间莫名减少后者表现为文件打不开或者内容错乱。从设备侧能做的最有效的防护是缩短危险窗口。具体做法有这么几条。第一写文件采用“临时文件重命名”模式先写xxx.tmp写完全部内容、关闭、确认返回OK再删掉旧的正式文件把临时文件改名。这样即使断电坏掉的也只是tmp文件正式文件仍然完整。前提是固件支持重命名命令如果不支持就只能接受这个风险靠上层逻辑做校验。第二控制单次写入的数据量不要一次攒几MB再写改成攒到几KB就落一次盘。写得频繁一点单次危险窗口就短一点。第三在设备面板或者外壳上贴一句“数据写入中请勿拔盘”配一个LED指示正在写入这个成本几乎为零但能挡掉相当一部分人为误操作。从主机侧电脑恢复的手段也得知道。Windows的磁盘检查能修复大部分丢失簇问题命令行用chkdsk X: /f注意要先备份能读出来的文件再修因为修复过程有可能把本来还能凑合读的文件弄坏。遇到提示“需要格式化”的情况先别急着点格式化用数据恢复工具扫描一遍很多时候数据区是完好的只是引导扇区或者FAT表被写坏了重建一下就能读。还有一个容易被忽略的点热插拔的检测时机。有些模组在检测到U盘拔出时来不及完成卸载流程就断了电缓存里的脏页全部丢失。所以如果你的产品允许用户随时拔盘最好在软件层做一个“拔出前静默期”——检测到拔出事件后立刻停止新的写入请求等待当前写入完成。更稳妥的做法是根本不支持运行中拔盘把U盘接口做成需要拧螺丝才能打开的面板从物理上限制误操作。这不是偷懒是工程上最可靠的方案。4. 把AT指令用进产品吞吐、缓冲与可靠性设计4.1 串口带宽才是真正的天花板先算清楚再谈方案很多人对这套方案性能的期待是错的。他们以为瓶颈在U盘的写入速度实际上瓶颈几乎永远在串口上。AT指令走的是串口透传数据必须先完整地从主控经串口送到模组再由模组写进U盘。所以整条链路的吞吐上限就是串口的有效带宽乘以协议开销系数。算一下就很清楚。串口8N1每传1个字节实际要发10个比特1起始8数据1停止。115200bps的理论字节速率是11520字节/秒也就是约11.2KB/s。但AT透传不是纯数据流每条ATFSWRITE命令本身有几十字节的指令开销和等待提示符的往返延迟实测有效吞吐大概在理论值的70%到80%也就是8KB/s左右。这个速度意味着写1MB数据要两分钟以上。波特率理论字节速率实测有效写入速率约写1MB耗时约适用场景11520011.2 KB/s8 KB/s130 秒小配置文件、几百行日志46080045 KB/s34 KB/s30 秒中等日志、参数备份92160090 KB/s65 KB/s16 秒较大日志、离线数据包2000000195 KB/s140 KB/s7.5 秒需确认模组和主控都支持这张表是我实际测出来的量级你的具体数值会因固件实现、单次写入长度、U盘本身速度而有出入但数量级是可靠的。看这张表就该明白一个结论这套方案适合传“小而关键”的数据不适合传“大而可重传”的数据。几百KB的日志、几十KB的配置、几KB的证书都是它的舒适区几百MB的图片、视频用它就是自找苦吃应该考虑别的路径。另外提醒一点波特率不是想提就能提。主控的串口外设时钟精度、走线质量、模组的接收容错都会限制实际可用的最高波特率。我的经验是超过921600之后如果线长超过20厘米又没有做阻抗控制误码率会明显上升表现为偶发的数据错位、文件内容中间插进几个乱字节。这种错误极难排查因为它不报错只是数据悄悄坏了。所以除非你的板子是专门为高速串口设计的否则老老实实用460800或者921600配合CRC校验兜底。4.2 单次写多少字节最划算缓冲区与耗时的平衡ATFSWRITE的第二个参数是本次要写的长度。这个值设多大直接影响吞吐和内存占用是个需要实测调优的参数。设得太小比如每次64字节那么每条写命令的固定开销指令本身、等待提示符、回OK相对数据量占比就很高。假设固定开销相当于40字节的传输时间写64字节数据的效率只有64/104≈62%实际吞吐掉到5KB/s。设得太大比如一次1MB主控这边得准备1MB的缓冲区对RAM只有几十KB的小MCU根本不现实同时单次传输时间过长中间出个误码整块都要重传风险窗口也大。实践中比较好用的区间是512字节到4096字节。512是U盘的一个扇区和底层刷写单位对齐避免固件内部再做拆分1024和2048是比较平衡的选择固定开销占比降到5%以下缓冲区占用也在大多数MCU能承受的范围内。如果你的主控RAM充裕4096会更划算一些。我一般会做一个三档实测分别用512、1024、4096写同一个1MB的数据块记录总耗时选拐点。缓冲区还有一个容易忽略的问题DMA和中断的配合。如果你的主控用DMA发串口要注意在等提示符的时候不能启动DMA因为提示符只有一个字节DMA搬运动辄几百字节会把后面的响应一起吞掉。正确做法是先用中断方式逐字节收到再切换到DMA发送数据块发完切回中断等OK。这个切换逻辑如果写错症状是“大部分时候正常偶尔命令超时”因为提示符和数据流的边界没对齐。4.3 日志类场景的落盘策略什么时候写、写多少、怎么防丢把U盘当日志载体是这套方案最高频的用法。这类场景的设计重点不是吞吐而是在掉电和拔盘的风险下尽量少丢数据。我推荐的策略是“内存环形缓冲 分级落盘”。主控开一块几KB的RAM做环形缓冲业务代码只管往缓冲里塞日志不直接碰U盘。然后设两个触发条件一是缓冲水位超过阈值比如70%时触发一次落盘二是定时器每隔固定时间比如30秒触发一次落盘哪怕缓冲没满。前者保证大量日志时不会溢出后者保证低频日志不会在内存里待到天荒地老。落盘时不要每次都开关文件。更好的做法是按文件大小滚动当前文件写到比如256KB就关闭新建一个带序号或时间戳的文件。这样单文件的危险窗口被限制在256KB以内而且文件不会无限增长导致列目录变慢。文件名用log_0001.txt这种定长序号方便按顺序遍历也避免中文和特殊字符带来的编码问题。具体到写入动作我习惯一次落盘分两步先FSWRITE把整块数据推过去等OK再FSCLOSE等OK。虽然每次开关文件有开销但它把“数据真正落盘”这件事变成了一个明确的、可确认的同步点。如果连续写多个块再关中途断电就会丢掉整段。当然如果你的日志频率很高比如每秒好几条每次都开关文件的代价太大那就改成“积累到4KB再写一次、每写10次关一次”用稍微大一点的风险换吞吐具体比例看你的业务能接受丢多少。还有一个技巧值得提在文件头写一段元信息比如设备号、固件版本、文件创建时间、上一条日志的序号。这样即使文件损坏了也能从文件头判断这是哪个设备的、属于哪个时间段的数据对售后分析帮助极大。这段头信息在写的时候要单独一次写入并关闭确保它是最早落盘的部分。4.4 目录组织与文件名命名为后续的自动处理留好路U盘最终是要给人用的也可能是给上位机软件自动解析的。所以目录和命名的规范最好在项目一开始就定下来别等到数据攒了几千个文件再想重构。我的一般做法是两级结构根目录下按设备序列号建一级目录比如/SN0001/每个设备一个互不干扰设备目录下再按日期建二级目录格式20240518定长、纯数字、可按字符串排序等价于按时间排序。文件放在日期目录下命名带上时分秒和序号。这样的结构有两个好处一是同一批U盘收回来之后可以直接按目录批量处理不需要在几千个文件里猜哪个属于谁二是单个目录下的文件数可控避免单纯为了列目录就花掉好几秒。文件名里绝对不要出现空格、中文、以及* ? : |这些字符。不是说固件一定不支持而是很多固件的实现只覆盖了ASCII的一个子集你在测试机上能建换个批次或者升个固件版本就建不出来了。用纯小写字母、数字和下划线长度控制在8.3规范的范围内是最保险的选择——即使固件不支持长文件名短名也能正常工作。最后提一个实际会遇到的问题时间从哪来。如果模组没有RTC也没有网络对时那目录名和文件名里的时间就是假的。这时候有两个方案一是有网络的时候从服务器取一次时间存在模组里做基准靠内部计时器推算精度差一点但够用二是干脆不用时间改用“开机序号运行秒数”命名比如boot003_004512.log表示第3次开机后的第4512秒。后者虽然不直观但绝对不会乱而且在没有可靠时钟的场景下反而更可信。我偏向后者因为它不依赖任何外部条件。5. 和SD卡、SPI Flash、外挂主控方案怎么摆在一起看5.1 四个维度的横向对比容量、易用性、可靠性和成本做技术选型最怕的就是“只看自己熟悉的那一个”。U盘、SD卡、SPI Flash、外挂主控管U盘这四条路各有各的适用面我按几个实际会决定成败的维度摆在一起看。维度AT指令读写U盘SD卡SPI/SDIO板载SPI Flash外挂MCU管U盘用户可自行导出可以插电脑即读需要读卡器不可以需拆机可以单次容量上限受文件系统限制FAT32单文件4GB同上通常几MB到几十MB同上接口占用串口已复用几乎零成本需4~6根专用IO需4根IO需额外串口电源现场可靠性中受供电和拔盘影响中触点易氧化高焊接固定中物料成本低U盘由用户提供中低高多一颗MCU开发工作量低调几条AT指令中需移植文件系统低但需自己做磨损均衡高两套固件吞吐瓶颈串口带宽SPI/SDIO带宽SPI带宽取决于级间接口看这张表能得出几个明确结论。如果你的核心诉求是“让用户能把数据带走”那U盘和SD卡是唯二选项SPI Flash直接出局——它天生就不是给人插拔的。如果板子上串口资源紧张、IO又富余SD卡可能更合适因为它不占用你已经用来做业务通信的那路串口。如果你的产品对可靠性要求极高、数据量又不大比如只存几百条配置和校准参数SPI Flash才是正解焊死在板子上没有触点、没有插拔、没有供电浪涌谁也弄不坏。至于“外挂一颗MCU专门管U盘”我通常不推荐除非你的主控实在太弱比如8位机、RAM只有1KB、连AT指令的字符串解析都吃力。多一颗MCU意味着多一套固件要维护、多一个升级入口、多一处可能出问题的地方而且两颗MCU之间的通信本身又要定义一套协议工作量并不比直接发AT指令少。只有在主控资源真的捉襟见肘或者需要U盘和主业务完全隔离比如主业务跑在实时操作系统上不能被打断的时候这个方案才值得考虑。5.2 什么情况下U盘是唯一正确的答案有些场景绕开U盘就是给自己找麻烦。第一类是售后数据回收。设备卖到现场出了故障你需要拿到故障前后的运行日志。如果日志在SPI Flash里你得派人去拆机、接线、读出来一次成本几百上千。如果在U盘里你只需要在电话里告诉客户“把U盘插上按一下这个键等灯灭了拔下来寄给我们”。这个差异在规模化之后是数量级的成本区别。第二类是离线配置下发。产线或者现场没有网络需要给设备灌一批参数、证书、白名单。最土但最有效的办法就是把文件放U盘里插上去自动读取、校验、应用、然后删除源文件。这套流程不需要任何上位机软件不需要装驱动一个U盘能搞定一批设备。第三类是用户自助取数。比如某种采集设备用户想把自己设备里的历史数据导出来做分析。让他拆机取SD卡显然不现实让他装个APP连蓝牙又增加了使用门槛。插U盘、按导出、等提示、拔走这个交互是所有年龄段的用户都能完成的。反过来说如果数据量在百MB级别、或者要求写入过程绝对不能中断比如连续高速采集那U盘就不是好选择应该考虑板载大容量存储加网络回传或者干脆做成可插拔的固态存储模块。判断标准很简单数据是“给人带走的”还是“给机器处理的”。前者选U盘后者选别的。6. 几个我在实际项目里攒下来的经验第一个经验是关于测试顺序的。我现在做这类功能验证流程固定成五步小文本写读比对、二进制含特殊字节写读比对、非512整数倍长度写读比对、反复插拔五十次看是否每次都能挂载、写入过程中强制断电十次看文件系统能否自恢复。这五步全过我才敢往产品里集成。前两步五分钟能做完后三步要花半天但这半天能省掉后面几个月的现场问题。第二个经验是关于指令超时的。几乎所有AT指令的默认超时都偏短尤其是ATUDISKMOUNT和ATFSCLOSE这两条前者要扫FAT表后者要刷缓存遇上大U盘或者慢速盘两秒根本不够。我的做法是给这两条单独设5秒超时其他命令保持2秒。超时后不要立刻重发因为重发可能导致重复挂载或者句柄状态混乱正确做法是先查一次状态再决定。第三个经验是我吃过最大的一次亏某批次的U盘在低温下零下10度左右启动电流明显变大实验室常温测试全部通过到了北方现场就出现偶发的不识别。后来加了外部供电才解决。这件事之后凡是带U盘功能的产品我都会在环境试验里加一条低温插拔测试常温测一百次不如低温测十次。第四个是文档层面的把U盘的格式要求、容量建议、目录结构、拔盘规范写成一页纸的说明随设备一起发给客户。这一页纸能挡掉至少一半的售后电话。别指望客户会自己去看厚厚的用户手册一页纸、配两张图、写清楚“只能用FAT32、建议32GB以内、拔之前先按停止键”就够了。最后说一个还没被完全解决的问题目前这套方案在多文件并发写入时的表现取决于固件内部的锁粒度。如果你的业务同时有日志写入和配置更新建议在应用层加一把软件锁串行化所有文件操作别指望底层帮你处理并发。我试过在两个不同固件上并发写两个文件一个表现正常另一个直接把FAT表写乱了。从那以后无论什么固件我都在上层排队。