上个月给一个小项目加“设备时间显示”的功能手头正好有一块吃灰很久的ESP-01S模块寻思着用AT指令连个网、请求一个时间API、解析JSON再把时间显示到OLED屏上听着也就是半小时的活。结果真跑起来才发现这个只有8个引脚的老模块硬是让我从供电折腾到AT指令再到JSON解析最后折在时区转换上整整踩了一天的坑。事后我把整个调试过程捋了一遍发现每个坑其实都有非常具体的原因只是网上资料太零散很少有人把“AT指令取时间”这条完整链路讲透。这篇就把我实测的完整过程、关键代码、以及排查思路全部记录下来给同样打算用ESP-01S做网络校时、物联网数据采集、离线日志打时间戳的朋友参考尤其是刚接触AT指令的初学者能少走一大半弯路。1. 先把板子喂饱供电、电平和固件这些基础坑很多人拿到ESP-01S第一件事就是插到USB转TTL上打开串口助手发AT。我也一样结果模块要么没反应要么连上WiFi的瞬间直接重启折腾半天连AT回显都看不到。后来才明白ESP-01S的脾气比想象中更大它不是你随便接个3.3V就能稳定工作的模块。1.1 峰值电流与稳压器模块重启的隐形杀手ESP-01S内置的是ESP8266芯片虽然平时待机电流不大但在WiFi射频发射的瞬间峰值电流能冲到300mA到500mA。很多USB转TTL板子上的3.3V引脚是直接从板载LDO引出来的而这类LDO通常只有100mA到200mA的带载能力。当ESP-01S连接路由器发送WiFi帧时电流需求瞬间拉高LDO输出电压跌落模块就直接掉电重启表现就是“AT收到一半没反应”或者“上电能亮灯一连WiFi就反复重启”。我实测用过的几个USB转TTL板子CP2102自带3.3V输出普遍偏弱CH340的板子稍好一点但也不够稳定。最靠谱的方案是给ESP-01S单独供电不要从USB转TTL的3.3V引脚取电。我用的是一块AMS1117-3.3的稳压小板输入接USB的5V输出接ESP-01S的VCC和GND同时在VCC和GND之间并了一个100uF的电解电容和一个0.1uF的陶瓷电容用于吸收瞬态电流波动。这样改完之后模块一连WiFi就重启的现象彻底消失了。注意ESP-01S的CH_PDEN引脚必须拉高也就是直接接到3.3V否则模块不会启动。GPIO0接高电平进入正常的运行模式如果GPIO0被拉低模块会进入烧录模式此时AT指令同样没有任何响应。这是最容易忽略的硬件细节。1.2 电平匹配与串口工具选择另一个隐蔽坑是电平匹配。ESP-01S的串口是3.3V TTL电平但很多USB转TTL模块在5V供电模式下TX引脚输出的是5V电平。5V电平打进ESP-01S的RX引脚短期可能没烧但会导致模块工作异常、串口数据乱码、指令偶发失效。我推荐两种稳定方案一是选用CP2102这类原生3.3V电平的USB转TTL模块也就是板子上的跳线帽或开关拨到3.3V档位二是如果手上只有5V输出的模块在TX到模块RX之间串一个1k电阻做限流分压虽然不如电平转换芯片干净但至少能用。实际项目里如果ESO-01S是挂在STM32、Arduino这类MCU上的这些MCU大多是3.3V供电电平基本匹配需要注意的只是USB调试阶段的工具选择。1.3 固件版本与波特率确认接下来是让所有新手抓狂的“AT无响应”。确认供电和电平都没问题后打开串口助手发送AT如果还是没反应先别怀疑模块坏了八成是波特率不对。ESP-01S出厂固件的默认波特率分两种新版AT固件默认115200老版本固件默认9600。还有极少数模块烧录的是NodeMCU固件或者卖家的测试程序此时发AT同样不会返回OK。正确姿势是先用115200尝试不行就依次试9600、57600、74880。ESP8266在上电时还会在74880波特率输出一段boot日志乱码看到这段乱码反而说明模块硬件没问题。确认模块能响应AT后用ATGMR查看固件版本。我强烈建议把固件升级到官方AT 2.x版本因为老固件在域名解析、TCP连接稳定性上都差不少后面提到的某些坑直接就是固件版本太老导致的。2. AT指令取时间建连、发请求、收响应的完整链路模块正常跑起来之后真正要干的事是联网取时间。这一步需要把WiFi连接、TCP建连、HTTP请求发送、响应接收这四段链路全部打通每一段都有自己的坑缺一个环节都拿不到完整数据。2.1 为什么选HTTPJSON而不是NTP获取网络时间其实有两条路NTP协议和HTTP JSON API。NTP通过UDP协议、123端口报文只有48字节响应极小、效率极高但问题在于它的报文是二进制格式在AT指令模式下会通过IPD,len:data返回数据里可能包含0x00字节MCU端如果用字符串方式处理很容易在\0处截断还得专门写二进制解析逻辑。HTTP JSON方案的数据量更大一些一个完整HTTP响应可能300到600字节但返回内容是纯文本可以直接用字符串函数处理调试时还能用串口助手肉眼查看出问题一眼就能看出来。很多公开时间API会直接返回unixtime字段和ISO8601格式的datetime字符串省去了NTP报文的高精度时间戳换算步骤。所以我最终的选型是HTTP GET一个JSON时间接口取unixtime字段做时区转换。对于AT指令方式来说可调试性比理论效率更重要。2.2 一次完整的时间API请求过程下面是我在串口助手里实际敲通的完整指令序列以请求worldtimeapi.org的UTC时间为示例。先用ATCWMODE1把模块设置为Station模式再用ATCWJAP你的WiFi名称,密码连接路由器等到返回WIFI GOT IP后用ATCIFSR确认模块拿到了IP地址。这里有个看起来不起眼但很重要的坑ATCWJAP返回OK只代表连接成功不代表拿到了IP地址一定要看到WIFI GOT IP的提示才算真正就绪。如果路由器是隐藏SSID或者5G频段模块还会返回连接失败最好用2.4G频段的路由器或者手机热点做调试。WiFi就绪后用ATCIPSTARTTCP,worldtimeapi.org,80建立TCP连接。这个指令有个版本坑老版本固件不支持在CIPSTART里直接填域名只认点分十进制IP填域名会返回ERROR。如果遇到这种情况两个办法升级固件到2.x版本或者先用ATCIPDOMAINworldtimeapi.org解析出IP再把IP填进ATCIPSTART。我建议直接升级固件一劳永逸。TCP连接成功后会返回CONNECT和OK此时发送HTTP请求ATCIPSEND86 GET /api/timezone/Etc/UTC HTTP/1.1 Host: worldtimeapi.org Connection: close模块返回提示符后把上面的HTTP请求完整发送过去注意末尾要有一个空行也就是\r\n\r\n这是HTTP协议要求的Header和Body之间的分隔符。发送完成后模块返回SEND OK然后服务器开始返回数据串口上会出现IPD,长度:数据的格式。2.3 长度计算和CIPSEND的“多发两个字节”问题ATCIPSEND长度里的长度必须和你实际发送的HTTP请求字节数完全一致。常见的坑有两个一是手算HTTP请求长度容易算错比如我上面的例子填86实际请求如果末尾少了一个\r\n服务器就会一直等请求头结束不返回响应二是在串口助手里发完payload后又顺手加了一个回车换行导致实际发送字节数比声明长度多了2个字节这2个多余的\r\n会让服务器解析请求头时卡住或者把下一个AT指令的响应污染。我建议在MCU代码里用sprintf先把完整HTTP请求拼到一个字符串里再用strlen算出真实长度动态拼出ATCIPSENDlen指令然后原样发送这个字符串末尾不要额外加\r\n因为HTTP请求字符串里已经包含了完整的\r\n\r\n结尾。用这种方式彻底避免手工算长度带来的低级错误。3. JSON解析乱码的真凶分帧、截断和误诊拿到的HTTP响应在串口里显示得歪歪扭扭或者JSON字符串看起来断断续续这是这个项目里最让人抓狂的一步。很多人一看到“乱码”就怀疑是编码问题觉得是不是该用GBK、UTF-8转码其实在这个场景下完全不是那么回事。3.1 你以为的“乱码”到底是什么我把实际调试中遇到的“乱码”现象分成了三类每一类的成因完全不同。第一类是串口监视器显示的波特率和实际波特率不匹配比如模块工作在115200串口助手却设成了9600此时看到的就是完全无法辨认的符号。这类乱码最容易被发现换对波特率就好了。第二类是模块或MCU缓冲区太小HTTP响应太长数据被截断导致JSON尾部残缺看起来像“乱码”。实际上字符串本身是干净的ASCII只是不完整。第三类是AT指令的IPD分帧机制导致的。服务器返回的HTTP响应可能超过模块内部接收缓冲区的容量模块会把它拆成多条IPD数据段依次通过串口送出来。如果MCU只处理了第一条IPD或者没有正确拼接后续数据段得到的JSON就是缺胳膊少腿的。在标题所说的“JSON解析乱码”场景里绝大多数情况是第三类数据被分帧而且MCU没有完整接收拼接。3.2 解析IPD分帧的正确姿势AT固件返回数据的标准格式是IPD,数据长度:数据内容多段分帧时串口上会出现多条这样的格式。例如IPD,507:HTTP/1.1 200 OK Content-Type: application/json ... IPD,93:{abbreviation:UTC,unixtime:1735540000,...}MCU端必须按状态机方式处理串口数据流不能依赖一次性读完。我以一个主循环加状态变量的通用C代码来说明核心逻辑#define SERIAL_BUFFER_SIZE 1024 static char serialBuffer[SERIAL_BUFFER_SIZE]; static uint16_t bufferLen 0; static uint16_t expectDataLen 0; static uint16_t receivedDataLen 0; static uint8_t parseState 0; // 0: 找IPD, 1: 读长度 2: 读数据 void process_serial_char(char c) { switch (parseState) { case 0: // 在流中搜索 IPD, if (c ) { // 用一个临时状态去匹配 IPD, // 匹配成功后进入 state 1开始收集数字 } break; case 1: // 收集长度数字直到 : if (c 0 c 9) { expectDataLen expectDataLen * 10 (c - 0); } else if (c :) { receivedDataLen 0; parseState 2; } break; case 2: // 按 expectDataLen 读取数据 if (receivedDataLen expectDataLen bufferLen SERIAL_BUFFER_SIZE - 1) { serialBuffer[bufferLen] c; receivedDataLen; if (receivedDataLen expectDataLen) { // 一段数据接收完毕此时可判断 JSON 是否完整 // 如果不完整重置 expectDataLen 等变量回到 state 0 继续找下一条 IPD } } break; } }实际的判断逻辑可以简化为每一段IPD收完之后在serialBuffer里搜索unixtime字段如果找到了并且后面有完整的数字就认为JSON已经完整否则清空缓冲区继续等待下一条IPD。3.3 从HTTP响应里剥离JSON的实战代码即使完整收到了所有IPD数据段缓冲区里的内容依然不是纯JSON而是HTTP响应头加JSON主体的混合体。HTTP头和JSON主体之间用\r\n\r\n分隔所以先定位这个分隔符再取它后面的部分才是真的JSON字符串。char *find_json_body(char *buf) { char *p strstr(buf, \r\n\r\n); if (p NULL) { return NULL; // 响应还没收全 } return p 4; // 跳过 \r\n\r\n }定位到JSON主体后用strstr查找unixtime字段再读冒号后的数字long extract_unixtime(char *json) { char *p strstr(json, \unixtime\); if (p NULL) { return -1; } p strchr(p, :); if (p NULL) { return -1; } return atol(p 1); }这里有个细节atol会自动跳过前面的空白字符所以冒号后面即使有空格也能正常解析。另外一定要用atol而不是atoi因为现在的Unix时间戳早已超过10位一个16位MCU或32位MCU上int很可能只有16位或32位但long在32位MCU上是32位能稳到2038年之前。3.4 缓冲区与波特率对数据完整性的影响我的实测响应大约是500到600字节如果把serialBuffer开成1024字节一般够用。但如果用的是STM32、Arduino UNO这种单片机要特别注意RAM容量Arduino UNO只有2KB SRAM开1024字节缓冲区已经是极限并且还得省着用这时候可以只保留JSON主体需要的部分或者改用NTP方案减少数据量。波特率对数据完整性的影响也很大。我最初用9600波特率600字节的数据要传0.6秒左右如果MCU主循环不够快新来的串口字符会覆盖旧字符出现数据丢失。把波特率调到115200之后数据能在50毫秒左右传完丢包概率大幅下降。调试阶段的串口助手和最终MCU代码里要保持同一个波特率别因为换环境把波特率也换了。4. 时区处理UTC8不是简单加8小时时间戳解析出来之后又一个看似简单但实际容易出错的环节来了把UTC时间转换成北京时间。如果你只是想着“加8小时就完事”大概率会在跨天边界上翻车。4.1 先从响应里精准提取unixtime就像前面代码里写的提取unixtime字段其实不难难的是确认自己拿到的到底是UTC时间戳还是当前API服务器所在时区的时间戳。我用的worldtimeapi.org/api/timezone/Etc/UTC明确请求的是UTC时区所以返回的unixtime就是标准的UTC时间戳不受服务器所在地影响。换成其他API时务必先在浏览器里请求一下接口看返回的datetime字段末尾有没有00:00这样的时区偏移确认你拿到的是UTC时间。这一步不确认清楚后面所有时区计算都是错的。4.2 时间戳加28800秒后再算年月日UTC时间戳转北京时间最稳妥的是先把时间戳加上8小时的秒数也就是28800秒得到一个“北京时间时间戳”再用这个时间戳去算年月日时分秒。有人会问直接解析datetime字符串偏移不是更直观吗我最初也是这么干的结果遇到了很恶心的进位问题。比如UTC时间是2025-03-01T16:30:0000:00你手动把小时字段加8变成24:30:00然后还得自己处理“小时为24或更大时日期加一天小时减24”的逻辑而这里又牵扯到“3月1日加一天是3月2日”“12月31日加一天是次年1月1日”这种边界条件。做出来的代码又长又容易错。时间戳加28800秒的做法就不一样所有进位问题都交给日期转换算法统一处理代码只有一行加法然后调用同一个转换函数。4.3 时间戳转年月日的自写算法很多MCU上没有标准库的gmtime或者即使有也不敢确定它用的是UTC还是本地时区。我直接贴一个经过验证的日期转换算法来自C标准库的经典实现在32位MCU上跑完全没问题// 根据自1970-01-01以来的天数计算年、月、日 // 输入 days 可为负数1970年之前的日期这里我们只处理正数场景 void civil_from_days(int days, int *year, int *month, int *day) { days 719468; int era days / 146097; int doe days - era * 146097; int yoe (doe - doe / 1460 doe / 36524 - doe / 146096) / 365; int y yoe era * 400; int doy doe - (365 * yoe yoe / 4 - yoe / 100); int mp (5 * doy 2) / 153; *day doy - (153 * mp 2) / 5 1; *month mp 10 ? mp 3 : mp - 9; *year y (*month 2); }配套的时间戳转换函数void unix_to_datetime(long ts, int *year, int *month, int *day, int *hour, int *minute, int *second) { long days ts / 86400; long rem ts % 86400; if (rem 0) { rem 86400; days--; } *hour rem / 3600; *minute (rem % 3600) / 60; *second rem % 60; civil_from_days((int)days, year, month, day); }使用时先提取unixtime加28800秒再传给unix_to_datetimelong utc_ts extract_unixtime(jsonBody); long beijing_ts utc_ts 8 * 3600; int y, mo, d, h, mi, s; unix_to_datetime(beijing_ts, y, mo, d, h, mi, s); printf(%04d-%02d-%02d %02d:%02d:%02d\n, y, mo, d, h, mi, s);4.3 跨天跨月跨年的测试用例代码写完一定要用几个跨边界的用例验证否则你以为是对的实际在零点就错了。我调试时专门用在线时间戳转换工具构造了几个场景UTC时间北京时间测试点2025-03-01 16:30:002025-03-02 00:30:00跨天2025-01-01 00:00:002025-01-01 08:00:00正常加8小时2024-12-31 18:00:002025-01-01 02:00:00跨年2024-02-29 16:30:002024-03-01 00:30:00闰年2月跨月2025-06-15 15:59:592025-06-15 23:59:59临界秒把这些时间戳一个个丢进unix_to_datetime检查输出的年月日时分秒是否和表格一致。我一开始就是没验证跨年结果程序在1月1日零点前后显示的时间差了整整一年。另外温度计之类的设备如果还想显示星期几也可以用civil_from_days算出的days值加一个已知基准日期的星期偏移但大多数场景只显示日期和时间就够了。5. 上线前的稳定性打磨超时、重连和重复获取拿到正确时间只是第一步一个正常的物联网小设备要考虑的是如果WiFi连不上怎么办如果TCP连接失败怎么办如果HTTP响应收一半断了怎么办这些不处理好设备放在角落里几个月时间迟早飘到离谱的地步。5.1 一套简单的AT指令重试状态机我的做法是为“获取时间”这个任务画一个微型状态机每个状态都有明确的超时时间超时后回退到前一个状态或重新尝试。伪代码如下typedef enum { STATE_IDLE, STATE_INIT, STATE_CONNECT_WIFI, STATE_OPEN_TCP, STATE_SEND_REQUEST, STATE_WAIT_RESPONSE, STATE_DONE, STATE_FAIL } state_t; state_t currentState STATE_IDLE; unsigned long timer 0; void loop() { switch (currentState) { case STATE_INIT: // 发送 ATCWMODE1然后进入 CONNECT_WIFI 状态 currentState STATE_CONNECT_WIFI; timer millis(); break; case STATE_CONNECT_WIFI: if (millis() - timer 10000) { // 10秒没连上WiFi重新发送 CWJAP currentState STATE_CONNECT_WIFI; timer millis(); } break; // 其他状态类似每个阶段设置5~10秒超时 } }核心思路是每个状态都有超时时间而不是死等某个返回。如果超时了就重新发起当前步骤连续重试3次还不行就放弃本次校时下次再说。电信运营商对APN连接的容忍度不高尤其在弱信号环境下TCP连接卡住是常态。5.2 断线重连与连接清理WiFi掉了之后ATCWJAP不会自动重连需要主动检测和恢复。检测方式有两种定时发ATCIPSTATUS看返回状态码状态码2代表没有WiFi连接状态码3代表TCP/UDP连接已建立状态码4代表断开连接或者应用层每隔一段时间重新取一次时间如果连续几次失败就强制断开WiFi重连。重连时有个细节重新执行ATCWJAP之前最好先发ATCWQAP主动断开旧连接否则某些固件会报“already connected”之类的异常。TCP层也一样如果上一次连接没有正常关闭下一次ATCIPSTART可能返回ERROR或一直卡住此时先发ATCIPCLOSE清理连接再重新建连。5.3 周期校时与低功耗设计的一点建议获取网络时间这种事没必要每次开机都做。如果设备有独立RTC实时时钟芯片可以只在开机时从网络校一次之后依靠RTC维持时间通过外部晶振误差通常每天几秒十天半个月校一次就行。如果设备没有RTC只能靠MCU的定时器计数那么建议每隔几小时或每天校时一次因为MCU内部RC振荡器受温度影响很大误差可能到每天几十秒。低功耗场景下可以给ESP-01S单独加一个MOS管控制电源校时完成后直接断电只在需要校时的时候上电。实测下来ESP-01S从冷启动到完成一次HTTP时间请求大约需要2到5秒取决于WiFi连接速度功耗虽然谈不上低但比起一直保持WiFi连接的方案省电效果非常明显。5.4 我把完整的AT返回对照表放在这里调试过程中我反复对照这些返回码后来干脆整理成了一张表贴在显示器旁边可以作为你自己的速查卡指令/事件期望返回含义ATOK模块串口通信正常ATCWMODE1OK已切换到Station模式ATCWJAPSSID,pwdWIFI GOT IP / OK连接AP并获取IPATCIFSR192.168.x.x查询模块IP地址ATCIPSTARTTCP,host,80CONNECT / OKTCP连接建立成功ATCIPSEND86模块允许发送数据SEND OK—数据已通过TCP发送IPD, :—接收到TCP数据len为字节数ATCIPCLOSEOK关闭当前连接ATCWQAPOK断开WiFi AP连接这张表看起来简单但实际操作时很容易被“返回了CONNECT但没返回OK”“返回了SEND OK但没收到IPD”这类半成功状态搞晕。我的处理原则是只看完整的状态序列比如建立连接必须同时见到CONNECT和OK才算成功只出现一个就当作失败并清理重试。做完这些稳定性处理之后我的小设备在连续运行的测试中时间显示始终和手机同步没有再出现时间漂移或者卡死的情况。如果你也在用ESP-01S做类似的功能我建议先把重点放在“把串口数据完整收下来”这件事上这是AT指令项目里最容易被低估的一环。调试时不要把模块直接藏进外壳留一个调试串口或者至少飞一根线出来把AT响应原样打印到串口助手你会发现所有问题都比想象中容易定位得多。