1. 这不是“发短信”而是嵌入式通信链路的闭环验证你手头有一块STM32开发板、一块Air780E 4G模组、一块0.96寸SSD1306 OLED屏还有一颗轻触按键——这三样东西凑在一起表面看是做个“按一下发中文短信”的小功能但实际踩进去会发现它是一条从硬件驱动、协议解析、字符编码、状态反馈到异常容错的完整嵌入式通信链路。我去年在做一款野外环境监测终端时就卡在这个环节整整两周按键能触发AT指令能发出去OLED能亮但短信内容要么乱码、要么根本发不出去、要么发出去后OLED显示“发送中…”就卡死。后来拆开看日志才发现问题不在代码逻辑而在于对Air780E中文短信机制的理解偏差——它不支持UTF-8直接编码也不接受GBK裸字节流必须走PDU模式下的UCS2编码SMSC地址预设TP-DCS字段精准配置这一整套组合拳。很多人以为“ATCMGS”发个字符串就完事其实那只是冰山一角。这个项目真正的价值是帮你把STM32作为主控、Air780E作为通信执行器、OLED作为人机交互窗口这三者之间的协同边界彻底厘清。适合正在做物联网终端、远程告警设备、智能门禁或毕业设计的同学尤其适合已经能点灯、串口收发、OLED显示基础图形但还没真正跑通“带业务语义的无线通信”的开发者。关键词里反复出现的“AT指令”“OLED显示配置命令”“HAL库驱动OLED代码”恰恰说明大家缺的不是单点能力而是把多个模块拧成一股绳的系统级实操经验。2. Air780E中文短信的本质PDU模式下的UCS2编码与SMSC强绑定Air780E这类4G模组发中文短信绝不是简单地往ATCMGS后面拼接汉字字符串。它底层强制走的是PDUProtocol Data Unit编码模式这是GSM规范定义的二进制短信封装格式所有字符必须转换为UCS2即UTF-16BE编码并严格按字节顺序打包进PDU数据段。很多人用ATCMGF1文本模式尝试发中文结果收到的是“”或直接返回ERROR就是因为文本模式下模组内部无法自动完成UCS2转换和PDU结构组装。而PDU模式ATCMGF0虽然复杂却是唯一可靠路径。我们来拆解一条标准中文短信PDU的结构以发送“温度超限”到13800138000为例字段长度内容说明SMSC地址长度2字节07SMSC号码长度含类型字节此处为7字节SMSC地址类型1字节91国际格式86开头91表示TON/NPI组合SMSC号码变长683108200505F08613800138000的BCD编码每两位倒序末尾补F→ 68 31 08 20 05 05 F0协议标识TP-PID1字节00默认值表示普通点对点短信数据编码TP-DCS1字节08关键字段表示UCS2编码08 默认消息类00有效期TP-VP1字节00默认有效期24小时目标号码长度1字节0B11位手机号十六进制为0B目标号码类型1字节81国内格式81目标号码变长313338303031333830303013800138000的BCD编码每两位倒序→ 31 33 38 30 30 31 33 38 30 30 30用户数据长度UDL1字节08UCS2编码后字节数“温度超限”4个汉字×2字节8用户数据UD变长6EAB6ECE8D889659“温度超限”的UCS2编码十六进制提示UCS2编码必须用大端序Big-Endian。例如“温”字Unicode码是U6E29UCS2就是0x6E29但在PDU中需拆为6E 29两个字节“度”是U5EA6 →5E A6。很多初学者直接用UTF-8编码如“温”是E6B8A9三字节导致PDU解析失败。SMSC短消息服务中心地址是另一个隐形门槛。Air780E不会自动获取运营商SMSC必须手动设置。中国移动常用SMSC是8613800250500BCD编码为0791683108200505F0中国联通是86130101125000791683010112500F0。若SMSC未设置或错误ATCMGS会返回CMS ERROR: 302SMSC address unknown。实测中我曾因误将SMSC写成8613800250500F0多了一个F0导致连续17次发送失败日志里只显示ERROR毫无提示。3. STM32侧的三重编码转换GBK→UTF-16→UCS2字节流STM32本身不内置GBK或UCS2编解码库必须手动实现或引入轻量级转换函数。HAL库提供的HAL_UART_Transmit只能发字节流无法处理字符串编码。因此整个流程是用户按键触发 → 读取预存GBK编码的中文字符串如温度超限对应GBK字节C8C2B6C8B3AC → 转换为UTF-16即UCS2 → 拆分为大端序字节 → 拼入PDU结构 → 通过UART发送AT指令。这里的关键是GBK到UCS2的查表转换。由于Flash空间有限不可能加载完整GBK码表约2万字但实际项目中只需覆盖常用告警词如“超限”“故障”“正常”“开启”“关闭”。我采用的方法是在const数组中静态定义高频词的UCS2码点运行时查表。例如// 常用告警词UCS2码点表UTF-16BE const uint16_t gbk_to_ucs2_table[][2] { {0xC8C2, 0x6E29}, // 温 - U6E29 {0xB6C8, 0x5EA6}, // 度 - U5EA6 {0xB3AC, 0x8D88}, // 超 - U8D88 {0xCFDE, 0x9659}, // 限 - U9659 {0xC6F3, 0x6545}, // 故 - U6545 {0xCFCF, 0x969C}, // 障 - U969C };转换函数核心逻辑// 将GBK双字节转为UCS2码点简化版仅支持表中字 uint16_t gbk_to_ucs2(uint8_t high, uint8_t low) { uint16_t gbk_code (high 8) | low; for (int i 0; i sizeof(gbk_to_ucs2_table)/sizeof(gbk_to_ucs2_table[0]); i) { if (gbk_to_ucs2_table[i][0] gbk_code) { return gbk_to_ucs2_table[i][1]; } } return 0xFFFD; // 替换字符 } // 将中文字符串GBK编码转为UCS2字节数组大端序 void str_gbk_to_ucs2_bytes(const uint8_t* gbk_str, uint8_t* ucs2_bytes, uint8_t* len_out) { uint8_t idx 0; uint8_t pos 0; while (gbk_str[idx] ! \0 pos 64) { // 限制长度防溢出 if (gbk_str[idx] 0x81) { // GBK双字节起始范围 uint16_t ucs2 gbk_to_ucs2(gbk_str[idx], gbk_str[idx1]); ucs2_bytes[pos] (ucs2 8) 0xFF; // 高字节先发 ucs2_bytes[pos] ucs2 0xFF; // 低字节后发 idx 2; } else { idx; // ASCII字符跳过本例暂不处理 } } *len_out pos; }注意Air780E PDU模式下用户数据长度字段UDL填的是UCS2字节数不是汉字个数。4个汉字→8字节→UDL08十六进制。若填错如填04模组会截断数据导致短信内容缺失。4. OLED状态显示的实时性与抗干扰设计避免“发送中…”永远不消失OLED显示看似简单但在此场景下极易成为系统瓶颈。常见问题按键按下后OLED立即显示“发送中…”但AT指令发送和模组响应有数百毫秒延迟若此时用户再次按键或电源波动OLED可能卡在旧状态甚至花屏。根源在于OLED刷新与UART通信抢占同一总线资源如I2C或SPI且未做状态机隔离。我采用的方案是将OLED更新完全解耦为独立状态机由全局状态变量驱动而非在AT发送函数中直接调用OLED_ShowString()。具体分三层状态定义层全局enumtypedef enum { OLED_STATE_IDLE, // 空闲显示欢迎页 OLED_STATE_SENDING, // 发送中显示“发送中...” OLED_STATE_SUCCESS, // 发送成功显示“已发送” OLED_STATE_FAILED, // 发送失败显示“发送失败” OLED_STATE_TIMEOUT // 超时显示“网络超时” } oled_display_state_t;状态更新层事件驱动// 按键触发时仅更新状态不操作OLED void key_send_handler(void) { if (oled_state OLED_STATE_IDLE) { oled_state OLED_STATE_SENDING; // 启动发送任务非阻塞 air780e_start_sms_send(); } } // UART接收中断中根据模组返回的CMGS或CMS ERROR更新状态 void uart_rx_callback(uint8_t* data, uint16_t len) { if (strstr((char*)data, CMGS:)) { oled_state OLED_STATE_SUCCESS; } else if (strstr((char*)data, CMS ERROR)) { oled_state OLED_STATE_FAILED; } else if (strstr((char*)data, OK) oled_state OLED_STATE_SENDING) { // 防止OK响应被误判需结合上下文 oled_state OLED_STATE_SUCCESS; } }显示执行层主循环中固定频率刷新// 主循环中每200ms执行一次避免频繁刷屏 void oled_display_task(void) { static uint32_t last_update 0; if (HAL_GetTick() - last_update 200) { last_update HAL_GetTick(); OLED_Clear(); switch(oled_state) { case OLED_STATE_IDLE: OLED_ShowString(0,0,STM32Air780E); OLED_ShowString(0,16,按KEY发短信); break; case OLED_STATE_SENDING: OLED_ShowString(0,0,发送中...); // 添加动态省略号效果 static uint8_t dot_cnt 0; OLED_ShowChar(48,16,. (dot_cnt % 3)); break; case OLED_STATE_SUCCESS: OLED_ShowString(0,0,已发送); OLED_ShowString(0,16,3s后返回); // 3秒后自动切回IDLE if (HAL_GetTick() - success_time 3000) { oled_state OLED_STATE_IDLE; } break; // 其他状态类似... } } }关键经验OLED的I2C通信尤其使用软件模拟I2C时会阻塞CPU若在UART中断中调用OLED函数可能导致AT响应丢失。必须将显示与通信严格分离用状态机定时轮询替代即时渲染。5. AT指令交互的健壮性设计超时、重试与响应解析的黄金法则Air780E的AT指令交互不是“发-等-收”那么简单。实际环境中模组可能因信号弱、SIM卡欠费、SMSC未注册等原因长时间无响应或返回非预期字符串如PBREADY、CPIN: READY等中间状态。若程序没有超时机制会永久阻塞在HAL_UART_Receive上导致整个系统假死。我的AT交互框架包含四个核心模块5.1 指令发送与超时控制// 发送AT指令并等待指定响应 AT_Result_t at_send_command(const char* cmd, const char* expect_resp, uint32_t timeout_ms) { // 清空接收缓冲区 memset(at_rx_buffer, 0, sizeof(at_rx_buffer)); at_rx_len 0; // 发送指令自动添加\r\n HAL_UART_Transmit(huart4, (uint8_t*)cmd, strlen(cmd), 100); HAL_UART_Transmit(huart4, (uint8_t*)\r\n, 2, 100); uint32_t start_tick HAL_GetTick(); while (HAL_GetTick() - start_tick timeout_ms) { if (at_rx_len 0) { if (strstr((char*)at_rx_buffer, expect_resp)) { return AT_OK; } else if (strstr((char*)at_rx_buffer, ERROR) || strstr((char*)at_rx_buffer, CMS ERROR)) { return AT_ERROR; } } HAL_Delay(10); // 避免忙等 } return AT_TIMEOUT; }5.2 响应解析的容错处理Air780E返回的AT响应常夹杂调试信息如ATE0 OK ATCMGF0 OK ATCMGS29 CMGS: 42 OK若用strstr直接找OK可能误匹配到CMGS: 42中的OK。正确做法是按行解析提取每行首尾非空白字符再匹配。我编写了轻量级行解析器// 将接收缓冲区按\n分割为行存入line_bufs uint8_t at_parse_lines(uint8_t* buffer, uint8_t** line_bufs, uint8_t max_lines) { uint8_t line_count 0; uint8_t* p buffer; while (*p ! \0 line_count max_lines) { uint8_t* start p; while (*p ! \n *p ! \r *p ! \0) p; if (p start) { // 去除行首尾空白 while (*start || *start \t) start; uint8_t* end p - 1; while (end start (*end || *end \t || *end \r || *end \n)) end--; if (end start) { uint8_t len end - start 1; memcpy(line_bufs[line_count], start, len); line_bufs[line_count][len] \0; line_count; } } if (*p ! \0) p; } return line_count; }5.3 关键指令序列与重试策略完整短信发送流程及重试逻辑步骤AT指令成功标志最大重试失败处理1ATOK3硬复位模组2ATCGMIManufacturer2检查接线3ATCPIN?CPIN: READY5提示SIM卡问题4ATCSQCSQ: x,y3信号10则等待5ATCMGF0OK2切换文本模式再试6ATCSCAxxxOK1记录SMSC错误7ATCMGS3检查PDU长度8发送PDU数据CMGS: xxx3降重发间隔实测心得第7步ATCMGSxx后模组返回表示准备接收PDU数据此时必须在10秒内发送完整PDU含结尾CtrlZ否则超时返回ERROR。我曾因PDU拼接耗时过长8秒导致连续失败。解决方案PDU预计算——在按键触发前就将常用短信的PDU字符串生成并缓存按键时直接发送确保在2秒内完成。6. 硬件连接与电源管理的隐性陷阱为什么你的OLED总花屏硬件层面三个模块的连接看似直连实则暗藏玄机。最常见的问题是电源噪声导致OLED花屏或Air780E频繁重启。Air780E在发送瞬间峰值电流可达2A而STM32和OLED通常由同一LDO如AMS1117-3.3V供电。当模组发射时电压瞬时跌落至2.5V以下OLED的SSD1306芯片因欠压复位显示乱码STM32也可能因VDD不稳触发POR上电复位。我的布线方案电源分离Air780E使用单独的3.3V LDO如RT9013输入端加470μF电解电容10μF陶瓷电容STM32和OLED共用另一路3.3V如TLV70233输入端加100μF1μF。地线处理Air780E的GND必须用宽铜箔≥2mm单独接到电源地再与STM32地单点连接避免数字噪声串入模拟地。UART电平匹配Air780E是3.3V TTL电平STM32的USART引脚需确认是否5V tolerant。若为普通GPIO必须加电平转换如TXS0102否则长期运行可能损坏IO。OLED接口选择优先用硬件I2CPB6/PB7禁用软件模拟I2C。实测中软件I2C在模组发射时因CPU被抢占导致SCL/SDA时序错乱OLED显示残影。另一陷阱是按键消抖与中断冲突。若按键直接接STM32外部中断且未做硬件RC滤波模组射频辐射可能触发误中断。我的做法按键串联10kΩ电阻对地接100nF电容硬件消抖EXTI中断服务程序中只置位标志位不执行任何耗时操作主循环中检测标志位再启动短信发送任务。最后关于OLED花屏的终极排查表现象可能原因验证方法解决方案开机花屏几秒后正常SSD1306初始化时序不足示波器测I2C SCL频率在OLED_Init()后加HAL_Delay(100)发送短信时花屏电源跌落用示波器测VDD纹波增大Air780E供电电容分离电源地显示文字偏移I2C地址错误用逻辑分析仪抓I2C通信确认OLED模块I2C地址0x78或0x7A部分区域不亮SPI/I2C模式配置错误查阅SSD1306 datasheet检查OLED_Init()中OLED_CMD寄存器设置7. 从“能发”到“可靠发”量产级优化的五个实战技巧当你已经能让“温度超限”成功发送下一步就是让这个功能在野外设备中稳定运行一年。以下是我在多个项目中沉淀的量产级技巧7.1 SIM卡状态自检与热插拔支持Air780E支持SIM卡热插拔但默认不启用。需在初始化时发送ATCSIMSTAT1 // 启用SIM卡状态通知 ATCREG2 // 启用网络注册URC之后模组会主动上报CSIMSTAT: 1 // SIM卡已就绪 CREG: 2,1 // 已注册到网络程序监听这些URC动态更新状态机避免因SIM卡松动导致发送失败。7.2 PDU长度动态计算与缓冲区安全PDU总长度 SMSC部分 固定头 目标号码 UDL UD。其中UD长度取决于汉字数×2。我定义最大短信为20汉字→40字节UD→PDU总长≤160字节。因此pdu_buffer[200]足够但必须校验uint8_t pdu_total_len smsc_len 12 phone_len 1 ucs2_len; if (pdu_total_len sizeof(pdu_buffer) - 10) { // 预留AT指令头尾空间 oled_state OLED_STATE_FAILED; return; }7.3 发送队列与离线缓存若网络临时不可用短信不能丢。我设计了一个3条深度的环形队列typedef struct { uint8_t pdu_data[160]; uint8_t pdu_len; uint32_t timestamp; // 用于超时清理 } sms_queue_t; sms_queue_t sms_queue[3]; uint8_t queue_head 0, queue_tail 0;主循环中若at_send_command(ATCREG?, CREG: 2,1, 5000) AT_OK则从队列取第一条发送否则记录时间30秒后重试。7.4 OLED低功耗模式野外设备需省电。OLED在不显示时可发送关屏指令ATOLED0 // 若模组支持OLED控制部分固件提供或更通用的做法在OLED_STATE_IDLE时调用OLED_DisplayOff()进入睡眠模式功耗从15mA降至0.01mA。7.5 日志分级与远程诊断在Keil中启用printf重定向到UART但生产环境需分级DEBUG仅开发时开启打印PDU原始数据INFO记录发送时间、目标号码、状态ERROR记录AT错误码如CMS ERROR: 302CRITICAL模组重启、SIM卡脱落。通过AT指令ATUARTLOG1开启模组自身日志配合STM32日志可快速定位是模组问题还是MCU问题。8. 完整代码框架与Keil工程配置要点一个可直接编译的最小可行工程需包含以下文件结构Core/ ├── Inc/ │ ├── main.h │ ├── air780e.h // AT指令封装 │ ├── oled.h // SSD1306驱动 │ └── key.h // 按键扫描 ├── Src/ │ ├── main.c │ ├── air780e.c // AT交互、PDU生成 │ ├── oled.c // OLED驱动基于HAL_I2C │ ├── key.c // 按键消抖 │ └── gbk_to_ucs2.c // 编码转换表 Drivers/ ├── STM32F1xx_HAL_Driver/ // 或F4/F7对应版本 Middlewares/ └── Third_Party/ // 无第三方库纯HAL8.1 Keil关键配置Target选项卡勾选Use MicroLIB减小printf体积Output选项卡勾选Create HEX File方便烧录C/C选项卡Define:USE_FULL_LL_DRIVER, __NO_SYSTEM_INIT精简启动Optimization:-O2平衡速度与体积Misc Controls:--cpp11 --gnu支持C11特性Debug选项卡选择ST-Link Debugger勾选Run to main()。8.2 air780e.c核心函数清单// 初始化模组含信号检测 AT_Result_t air780e_init(void); // 设置SMSC AT_Result_t air780e_set_smsc(const char* smsc); // 发送PDU短信传入预生成的PDU字节数组 AT_Result_t air780e_send_pdu(uint8_t* pdu, uint8_t len); // 生成PDU封装了SMSC、号码、UCS2转换 uint8_t air780e_build_pdu(const char* phone, const char* content, uint8_t* pdu_out); // 等待模组URC用于异步事件 AT_Result_t air780e_wait_urc(const char* urc, uint32_t timeout);8.3 主循环逻辑骨架int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_I2C1_Init(); // OLED MX_USART1_Init(); // 调试串口 MX_USART4_Init(); // Air780E OLED_Init(); key_init(); // 模组初始化含超时重试 if (air780e_init() ! AT_OK) { oled_state OLED_STATE_FAILED; } while (1) { key_scan(); // 检测按键 air780e_task(); // 处理AT响应 oled_display_task(); // 更新OLED HAL_Delay(10); } }最后分享一个血泪教训Air780E的固件版本至关重要。我曾用V1.2.1固件ATCMGS在PDU模式下偶发丢包升级到V1.4.3后问题消失。务必从合宙官网下载最新固件并用ATGMR确认版本。固件升级本身也是一门学问——需用USB转串口工具按官方文档进入下载模式稍有不慎就会变砖。所以在量产前务必用同一固件版本的模组做72小时压力测试这才是“能发”和“可靠发”的分水岭。