企业官网建设流程全解析

1. 为什么整定之前，我得先给固件补出一套人机界面

先说个大多数搞嵌入式的人都经历过的场景。你写了一个带PID闭环的控制固件，Kp、Ki、Kd要么拿宏定义写死在代码里，要么放在一个全局结构体里。第一次上电，系统抖得像帕金森，你拿起串口线，改一下宏，重新编译，烧录，断电，上电，看波形。不行，再改，再编译，再烧录。一个下午过去，你大概只试了四组参数，人已经麻了。

我做温控项目的时候就是被这么折腾怕了。当时用的主控是STM32F103C8T6，外挂ESP8266做数据透传，PID跑在一秒一百次的定时中断里。数学上没什么大问题，真正让人崩溃的是参数迭代效率。后来我想明白一件事：在开始所谓“整定”之前，真正应该先做的，不是掏出公式去算临界比例度，也不是把Ziegler-Nichols背得滚瓜烂熟，而是先给固件本身加上一层薄薄的人机界面。

这期连载想讲的，不是怎么做一个漂亮炫酷的触摸屏。我的目标是给固件“长出”一套够用、好用、不占资源的交互层——通过串口命令行、OLED状态屏和参数掉电保存，把“改参数”这件事从“重新烧录”里解放出来。只有先做到这一步，后面的整定才有意义，因为你才敢大胆试错，才能在一个下午之内跑完几十组参数，把控制对象摸透。

很多朋友一提人机界面就想到LCD、LVGL、emWin，觉得工程量大、硬件贵。其实对一个嵌入式固件来说，最有效的界面往往是命令行和极简状态屏的组合——不需要额外硬件，串口就有，调试器就能看。这篇文章就把我这套方案的完整思路、代码骨架和踩过的坑拆开讲，适合正在做PID整定、电机调速、温控、电源闭环这类项目的朋友作参考。

2. 界面设计先想清楚：整定到底需要哪些交互能力

2.1 没有界面时，参数调整的流程到底有多低效

我先用一个具体的时间开销来说明问题。假设你的参数宏长这样：

#define KP_VALUE 2.50f #define KI_VALUE 0.80f #define KD_VALUE 0.05f

每次想测一组新参数，你得经历：编辑源代码、保存、交叉编译、烧录、复位、观察运行效果。如果用的是HAL库的标准工程，一次完整编译大概30秒起步；如果是STM32 + RT-Thread这种稍大的工程，可能得一两分钟。烧录器连上下载，基本又去掉十几秒。这中间还没有算你为了观察动态响应，需要等系统稳定下来再扰动、再记录的时间。

所以改动一次参数，至少两分钟起步，稍微磨蹭一点五分钟就没了。这样的节奏下，你根本没耐心系统地扫描参数空间，因为每一组参数的试错成本太高，于是人就会自然倾向于“猜一组差不多得了”。这就失去了整定的意义——整定的本质是系统地观察对象在不同参数下的响应，找到鲁棒性和快速性都合理的折中。如果你不能在单位时间内获得足够多的实验数据，整定就变成了玄学调参。

2.2 拆解整定过程，需求其实就这么四条

我梳理了自己做过的温控、电机速度环、充电电流环几个项目，发现整定之前的交互需求高度一致，归根结底就四件事：

• 运行中实时修改PID参数，不需要重新编译烧录；
• 实时查看当前反馈值、目标值、输出量和计算出的中间量（比如积分累计值）；
• 把调好的参数固化保存，下次上电自动加载；
• 能通过简单的命令把参数恢复成默认值，避免一次误操作把系统搞乱。

这四件事，本质上就是一个最小可用的人机界面。它不关心按钮漂不漂亮、动画顺不顺滑，它只关心信息传达得是否够快、够准，参数修改是否够直接。

2.3 三种交互载体怎么选：串口CLI、OLED菜单、网页面板

我见过有人一上来就给STM32上LVGL跑触摸屏，结果整定的核心逻辑还没写，先被UI框架的版本兼容问题折磨了两周。成熟的嵌入式工程师会先想清楚一个问题：谁是操作者，操作场景是什么？

如果操作者是你自己，坐在电脑前调试，那串口CLI就是最优解，零成本、信息密度高、可脚本化；如果你在现场，没带电脑，那128x64的OLED加上两三个按键做菜单就足够；如果你做的是需要给最终用户用的设备，才考虑走网页配置面板，让设备自己起一个HTTP服务，手机连上去改参数。

我做这两个项目时选的组合是：串口CLI为主，OLED状态显示为辅。串口负责高频交互，因为调试时电脑在手边；OLED负责脱离电脑时也能看到目标值、反馈值和当前输出。网页面板我放在了后续的规划里，因为就整定这件事而言，CLI已经能覆盖九成需求，而网页面板涉及HTTP协议栈、Flash文件系统、前端资源存储，工作量一下子会大很多。

3. 参数中心模块：人机界面的“数据底座”

3.1 别再写散落的全局变量，用一个参数表管理一切

代码里如果到处是extern float Kp;这种裸全局变量，界面层要访问参数就只能一个个函数去取，命令解析器改参数也要分门别类地处理，代码写起来又臭又长。更麻烦的是，每个参数还要单独写掉电保存逻辑，漏一个就出bug。

我用的模式是建一张参数表，把所有可调参数集中到一个结构体里，用一张描述表记录每个参数的名称、地址、精度和读写权限。

typedef struct { char name[16]; void *addr; uint8_t type; // PARAM_TYPE_FLOAT / PARAM_TYPE_INT float min; float max; float step; uint8_t save_flag; } param_desc_t; static float pid_kp = 2.0f; static float pid_ki = 0.5f; static float pid_kd = 0.02f; static int pid_cycle_ms = 20; const param_desc_t param_table[] = { {"kp", &pid_kp, PARAM_TYPE_FLOAT, 0.0f, 100.0f, 0.1f, 1}, {"ki", &pid_ki, PARAM_TYPE_FLOAT, 0.0f, 100.0f, 0.01f, 1}, {"kd", &pid_kd, PARAM_TYPE_FLOAT, 0.0f, 10.0f, 0.001f, 1}, {"cycle_ms", &pid_cycle_ms, PARAM_TYPE_INT, 1, 1000, 1, 1}, };

这样的好处是，命令解析器、保存逻辑、OLED菜单都可以共用同一张参数表——拿到名字就能定位到地址，拿到地址就能读能写，天然形成了解耦结构。以后再想增加一个可调参数，只需要往结构体里加一个成员，然后在表里添加一行，界面层和存储层不用动任何代码。这对频繁做实验的场景来说非常关键，因为你往往会在半路发现“哦我可能还得看看前馈系数”。

3.2 参数名的使用：要便于输入，而不是便于阅读

参数命名看起来是小事，实际操作起来影响非常大。第一个版本我把参数名起得特别工整：proportional_gain、integral_time、derivative_time，结果调试的时候每次都要敲一长串，输错一个字母就要重来。

吃了几次亏之后我悟了：嵌入式CLI的参数名一定要短，短到单手盲打都能输对。kp、ki、kd就是比proportional_gain好用。你甚至可以加一组语义别名，让p也能映射到Kp，这在现场快速调节时很实用。少敲几个字母，看着无所谓，真到一晚上调四十组参数的时候，你才知道手不酸有多重要。

这种参数表还有一个额外的好处：可以自动生成help信息。命令解析器遍历这张表，把所有参数名、范围、当前值全部打印出来，不用你手写一行行的帮助文本，这张表本身就是最好的文档。

4. 串口命令行：整个界面中最核心的“按键”

4.1 命令协议设计成什么样才不会把自己绕晕

串口CLI最怕两种设计：一种是把协议定得极其复杂，动辄0xAA 0x55 0x01 0x02 0x03 checksum，肉眼根本没法读；另一种是完全没有协议，想到哪写到哪，解析器写了一堆if-else，看到代码就头大。我倾向的方案是文本命令，格式固定为四段：

set kp 2.50 get kp save load reset help

固定格式意味着解析器可以写得很机械。set后面跟参数名，再跟数值，三个字段之间用空格分开。解析的时候用strtok把一行按空格拆开，第一段是命令动词，第二段是参数名，第三段是数值。这样解析器很短，逻辑一目了然，而且天然具有可读性，串口监视器里直接就能看到历史记录，不用写上位机去解码。

整个解析函数核心大概长这样：

void cli_process(char *line) { char *cmd = strtok(line, " "); if (!cmd) return; if (strcmp(cmd, "set") == 0) { char *name = strtok(NULL, " "); char *val = strtok(NULL, " "); if (name && val) { param_set_by_name(name, val); printf("[OK] %s = %s\r\n", name, val); } } else if (strcmp(cmd, "get") == 0) { char *name = strtok(NULL, " "); if (name) { param_print_by_name(name); } } else if (strcmp(cmd, "save") == 0) { param_save_to_flash(); } else if (strcmp(cmd, "load") == 0) { param_load_from_flash(); } else if (strcmp(cmd, "reset") == 0) { param_restore_default(); } else if (strcmp(cmd, "help") == 0) { cli_print_help(); } }

实际工程里我还会加一个status命令，一次性打印所有运行数据，包括当前目标值、反馈值、输出量、P项、I项、D项的单独数值。你可能会问，这些中间量为什么不直接通过get命令去获取？因为手动整定的时候，最需要的是“一眼扫过去全看见”，而不是一条条单独查。单独查适合脚本处理，批量打印适合人类观察，两者用途不同。

4.2 ESP8266 + STM32的组合下，串口数据怎么处理

如果你的项目里正好用到了ESP8266（比如ESP-01S跑AT固件）做网络透传，那么来自网络的命令最终也是从串口进到STM32的。这种情况下，不管命令是从UART1（调试串口）进来，还是从UART2（ESP8266）进来，解析逻辑完全共用一套。我一般维护一个环形缓冲区，中断里接收字节放进缓冲区，主循环里把完整的行取出来丢给解析器。

static uint8_t uart_ring[256]; static uint16_t head = 0, tail = 0; void UART1_IRQHandler(void) { uint8_t ch = USART_ReceiveData(USART1); ring_buf_push(ch); } void cli_poll(void) { static char line[64]; static uint8_t idx = 0; while (ring_buf_pop(&ch)) { if (ch == '\r' || ch == '\n') { if (idx > 0) { line[idx] = '\0'; cli_process(line); idx = 0; } } else if (idx < sizeof(line) - 1) { line[idx++] = ch; } } }

这段代码有一个关键细节：不要把串口命令处理直接丢到中断里去执行。因为set命令会调用参数表更新、save命令会触发Flash写入，这些操作都很耗时，放在中断里会拖垮实时响应。中断只负责把字节塞进缓冲区，主体处理放在主循环的cli_poll()里，这是嵌入式人机界面稳定运行的第一原则。

4.3 输入回显和退格处理，这个细节决定手感

命令行好不好用，回显和退格绝对是大头。你敲了半天的命令，屏幕上什么都没有，或者在按退格时不能删除字符，这就没法正常用了。所以我在串口中断接收里做了最朴素的命令行支持：

• 收到可打印字符时，存入缓冲区，同时往回显；
• 收到\b或0x7F时，删除缓冲区末尾一个字符，同时串口发送\b \b（退格，空格，再退格）把这一个字符从屏幕上抹掉；
• 收到回车时，发送\r\n换行。

这样虽然简单，但整个输入体验跟本地终端基本一致了。而且这种做法占用的资源极少，不需要引入readline那类重型库。你想想看，如果每次输错命令都要重敲一整行，你调参数的热情会迅速归零。这个小细节在我实际测试中，对效率提升的贡献一点不比主解析逻辑小。

5. OLED状态屏：脱离电脑时怎么保持掌控感

5.1 状态屏显示什么内容，才能辅助整定而不是添乱

串口CLI解决了“改参数”的问题，但它有个天然的短板：你没法同时在串口终端上盯着控制系统的实时响应曲线。虽然可以用串口绘图工具（SerialPlot之类）把数据拉成波形，但在现场没有电脑时，你还需要一个常驻显示面板。

我的方案是一块0.96寸128x64的OLED，SSD1306驱动，I2C接口，只需要四根线。刷新率不需要太高，每秒两到三帧就够用，毕竟它显示的是一组数值而不是动画。显示内容我固定为四个区块：

• 第一行：目标值SV和反馈值PV；
• 第二行：输出值OUT，以及当前是否处于限幅状态；
• 第三行：PID系数Kp、Ki、Kd实时值；
• 第四行：内部工作状态，比如“Normal”“Tuning”“Overtemp”。

这个布局基本不占太多思考时间，扫一眼就知道系统处于什么状态。整定的时候，OLED侧边放一个，电脑屏幕上看串口波形，两边对着一对照，那种“这组参数到底行不行”的判断，几秒钟就能出来。

5.2 让OLED配合CLI形成“无感切换”

我的代码设计里，OLED显示模块和CLI模块共用同一个参数表结构体。OLED要显示当前Kp，直接去参数表里找名叫kp的条目读取地址里的值；要显示PV反馈，就直接读全局的current_value变量。这种共享方式避免了在两个模块里各维护一份数据副本，也就不会出现OLED显示的是上一组老参数、实际控制用的却是新参数的尴尬情况。

给OLED的更新写一个简单模板：

void oled_update(void) { char line[24]; sprintf(line, "SV:%05.1f PV:%05.1f", g_setpoint, g_feedback); ssd1306_draw_string(0, 0, line); sprintf(line, "OUT:%05.1f LIM:%s", g_output, g_output_limited ? "ON" : "NO"); ssd1306_draw_string(0, 16, line); sprintf(line, "Kp:%.2f Ki:%.3f", pid_kp, pid_ki); ssd1306_draw_string(0, 32, line); sprintf(line, "Kd:%.4f %s", pid_kd, g_tuning_state); ssd1306_draw_string(0, 48, line); ssd1306_refresh(); }

有人可能会说，OLED显示的刷新过程会不会影响控制时序？实际不会，因为SSD1306的I2C传输只是往显存里搬运数据，控制逻辑跑在定时器中断里，两者的优先级天然分开。你真正要注意的是I2C总线上不要同时挂太多高频率通信的设备，否则可能互相阻塞。

6. 实现串口命令通道的完整实操骨架

6.1 从ESP8266到STM32的引脚连接与初始化要点

这个项目的网络透传部分用的是ESP-01S，跑的是官方AT固件。它在系统里的角色是“远程命令通道”——你可以从电脑端通过网络发命令到ESP8266，ESP8266把数据从串口转发给STM32，STM32执行完命令后把回显再通过ESP8266发回网络终端。这样你在另一个房间也能改参数，整定的时候不用一直蹲在设备旁边。

接线方面，我用的是：

有一个很容易踩的坑：ESP8266模块推荐供电电流要500mA以上，很多调试用的USB转TTL只能提供几十毫安，直接导致ESP8266反复重启。我一开始就栽在这里，模块明明AT指令测试是好的，一接到单片机系统里就不停重启，排查半天才发现是3.3V LDO电流不够。后面我干脆单独用一块AMS1117-3.3，输入接USB 5V，输出专门给ESP8266供电，问题才彻底解决。

6.2 点亮OLED前的SSD1306配置，两个关键坑

SSD1306用I2C模式驱动，初始化序列网上能抄到一堆，但有两个细节特别容易出问题。

第一个是I2C地址。大部分0.96寸OLED模块地址是0x78（7位地址0x3C），但也有些模块是0x7A（7位地址0x3D）。你可以在初始化代码里写一个探测逻辑：依次发送地址，看有没有ACK，然后自动适配。这个逻辑能让你少烧好几根杜邦线。

第二个是屏幕的电荷泵必须显式开启。有些简化版的SSD1306库没有在初始化序列里打开电荷泵，结果屏幕永远是一片黑，怎么调I2C时序都没用。一个完整初始化序列末尾一定要有：

ssd1306_command(0x8D); // charge pump setting ssd1306_command(0x14); // enable charge pump ssd1306_command(0xAF); // display on

这三条命令缺一不可。如果你发现屏幕上电后不亮，别急着怀疑硬件，先把这三条命令确认一遍。

6.3 STM32中断里接收命令行数据时，一定要避开这些雷

串口接收用中断最自然，但中断处理有几个容易让人抓狂的坑。第一个是缓冲区溢出。如果主循环处理不过来，环形缓冲区被填满后新数据会被丢弃，表现就是命令打着打着突然丢失。我一般会把环形缓冲区开到一个256字节以上——这个大小对于交互式命令行已经非常充裕了，因为一条命令撑死几十个字节。

第二个坑是换行符不一致。电脑端串口终端发送回车时，有的发\r，有的发\n，还有的既发\r\n。所以判断一行结束时，\r和\n都要当作终结符处理，否则你从不同的串口工具发命令，有的能识别有的直接没反应。

第三个坑是长命令被截断。我的line数组设成了64字节，如果一条命令超过这个长度，后面的字符会直接被吞掉。这不一定是bug，但你在设计命令规范时心里要有数。比如set kp 3.14159这种长度的命令完全没问题，但如果哪天你想用CLI去设置一个很长的设备名称，就得把缓冲扩大，或者改用动态分配。对调参场景来说，64字节固定缓冲是最省心也最安全的。

7. 参数保存与恢复：别让你的调参成果一夜清零

7.1 Flash写入为什么要做均衡和备份

参数保存这个功能，设计起来容易，写崩也容易。STM32F103C8T6内置Flash是128KB，扇区按1KB划分。如果每保存一次参数就擦写整个扇区，片内Flash的擦写寿命大概一万次，听起来很多，但调试阶段一天保存几十次很正常，几周就造完了。

所以保存逻辑不能上来就擦整个扇区。我的方案是：在Flash里划分两个1KB的区域作为备份区，保存时先写A区，再写B区。读取时检查两个区的校验值，以有效的那份为准。万一写一半断电导致A区数据损坏，还有B区兜底。这样损失的是两倍的Flash空间，换来的是数据可靠性的大幅提升。

7.2 保存的数据结构：版本号比什么都重要

数据结构第一版我写得非常朴素：

typedef struct { float kp; float ki; float kd; int cycle_ms; } param_storage_t;

后来发现一个问题：我往参数表里加了新参数后，老固件保存的数据加载到新固件里，结构体长度对不上，读出来的全是乱的。从那之后，我就在存储结构里加了版本号：

typedef struct { uint32_t magic; uint32_t version; float kp; float ki; float kd; int cycle_ms; uint32_t crc32; } param_storage_t;

magic用来识别这是不是本设备的参数数据，version用来识别数据结构是不是当前固件版本。crc32校验整个结构体的完整性。加载时先查magic，再比version，最后算CRC，任何一个不对都视为默认参数。这相当于给参数存储上了一道保险，以后不管怎么改结构体，不至于把旧的脏数据读出来当成有效参数用。

7.3 保存操作千万不要写在控制中断里

这个看起来像废话，但我身边真有人把param_save_to_flash()直接挂在了定时器中断里，想着“每隔一段时间自动保存一次参数，省得手动敲命令”。结果就是Flash擦写的时候，控制中断被阻塞了几十毫秒，系统直接失控，输出值跳变之后又恢复正常，PID环路被打出了好几个毛刺。

记住一个原则：保存操作只由命令触发，而且只在空闲时执行。你可以设计成一个“请求保存”标志，在主循环里检查到标志后再调用实际保存函数。这样既不阻塞中断，也不会让用户感觉命令没响应。

8. 整定实战：人机界面到底怎么帮我摸清系统脾气

8.1 传统调参流程和人机界面加持后的流程对比

一个典型的二阶对象，比如一个加热器加一个温度传感器，传统流程是这样的：改代码里的Kp，编译烧录，然后手动给一个阶跃，盯着温度曲线看超调量，如果超调太大，再改代码重来一遍。这个过程里真正用于观察系统响应的时间其实很短，大部分时间都花在了编译和烧录上。

有了命令行界面之后，流程变成了：

1. 上电，连串口，发送get kp确认当前参数；
2. 发送set kp 2.0、set ki 0.1、set kd 0.0，命令发完即生效；
3. 给系统一个阶跃扰动，串口观察反馈值的变化或者用SerialPlot画曲线；
4. 根据曲线形态，直接发set kp 2.5调整，看新曲线；
5. 找到合适的参数组合后，发送save，掉电不丢。

整定从“编译—烧录—重启”循环变成了“发命令—看曲线—再发命令”循环，每轮试错时间从几分钟压缩到十几秒。按一个下午调30组参数来算，效率提升是数量级的。

8.2 用状态屏配合阶跃响应，快速判断参数走向

整定的时候，我自己总结了一套粗调的土办法，不一定严谨，但很实用。先只保留比例项，Ki和Kd都设成0。然后从一个小Kp开始，慢慢涨，观察阶跃响应：

• 如果PV到不了SV附近，稳态误差很大，说明Kp不够大；
• 如果PV超调后剧烈振荡、发散，说明Kp过大或者采样周期和对象特性不匹配；
• 如果PV上升太慢，迟迟追不上SV，除了加大Kp外，还需要考虑是不是输出限幅卡住了。

这个阶段我用OLED状态屏盯PV和OUT。PV在SV附近来回晃但没发散，说明Kp接近临界值。那个“来回晃”的幅度就是一个非常有价值的信息：系统在临界点附近的振荡频率，实际上就是后面算Ki、Kd的重要参考。临界增益和临界周期从波形上一目了然，比闭着眼睛猜靠谱得多。

整定进入精细阶段后，发get status看每个分量的贡献，就能快速定位问题。比如PV误差已经很小，但输出还在大幅度波动，那很可能是积分项饱和了；如果误差刚开始减小，输出就已经反向冲出去，说明微分项放得太大，或者在信号噪声比较大的情况下Kd被噪声牵着走。能看到每个分量，调起来完全就是另一个境界。

8.3 输出限幅和抗积分饱和，应该在界面上可见

PID控制器的输出不在界面上显示处理过程细节的话，你很难发现为什么系统有时候“卡住不动”。比如你设了输出限幅0到100，积分项一直在累积，输出到达100并且卡住，这时候阶跃响应当然看起来很“钝”。如果没有输出状态提示，你可能会怀疑Kp不够大，傻乎乎地继续加大比例项，结果系统恢复后反而超调爆炸。

所以我在固件里专门做了一个积分限幅策略，同时把这个状态通过CLI暴露出来。界面上你能看到“OUT:100 LIM:ON”，就能立刻意识到系统进入了限幅状态，得等积分退饱和或者适当调低积分上限。这种从界面直接观察到内部状态的体验，才是人机界面最大的价值——它不只是为了给你一个输入框，更是为了让你看见系统内部在干什么。

9. 常见问题与排查技巧实录

9.1 命令敲下去没反应，先别急着怀疑解析器

我遇到的第一类问题就是串口发命令没反应。排查顺序我一般是这样：先用一个USB转TTL直接接STM32的调试串口，把CLI单独跑起来，确认命令解析逻辑没问题。然后接上ESP8266，通过它的透传去发命令，确认只是网络链路的问题还是整个链路都有问题。这个二分法排查思路，帮我在十分钟内定位过很多“看起来像固件bug”的连线问题。

还有一个高频坑：波特率不对。ESP8266的默认AT固件波特率是115200，很多人建立工程时习惯把串口初始化成9600，两边不一致，数据全是乱码。我第一次接ESP8266时就吃过这个亏，屏幕上全是?，一度以为芯片烧了。

9.2 ESP8266透传模式下数据混乱怎么处理

AT固件有一个模式叫透传模式，发送AT+CIPMODE=1然后AT+CIPSEND进入。透传模式下ESP8266收到的网络数据会直接转发到串口，STM32收到的串口数据也会直接发到网络。这种模式最适合做CLI远程通道，但有个问题：透传模式下没法同时发AT指令。

如果你的固件需要在远程命令通道之外，还要能控制ESP8266重新连接WiFi，那你得仔细设计状态机：进入透传后，用一个特殊的前缀字符（比如三个连续的+++）退出透传，回到AT命令模式，操作完再进透传。STM32的命令解析器里要预留对这个特殊前缀的识别，否则你在远程终端上敲任何命令都只会被当成普通数据转发。

我自己踩过的坑是：透传模式下，ESP8266会把网络对端的换行符原样转发过来。如果对端发的是\n，而CLI解析只认\r，命令就永远不执行。解决方案就是前面说的，把\r和\n都作为行终结符来处理。

9.3 OLED显示乱码或雪花，到底是不是屏幕坏了

OLED显示乱码，百分之八十情况不是屏幕坏了，而是I2C时序或者地址问题。我之前遇到一次，现象是屏幕翻白、内容错乱、闪烁，排查后确认是我把I2C的时钟频率设置得太高，SSD1306跟不上。把I2C时钟从400kHz降到100kHz之后，一切恢复正常。如果你用的是软件模拟I2C，那就要注意延时是否给够了，有些示例代码在快速主控上延时不够，也会导致乱码。

另外还有一个常见现象：屏幕刚开始正常显示，过几分钟就花了。这种多半是I2C总线上有毛刺信号或者供电不稳。OLED模块的VCC和GND要尽量用粗一点的杜邦线，并且靠近模块端加一个10uF左右的电容去耦，能有效减少花屏概率。

9.4 常见问题速查表

10. 最后再分享一个我自己的小习惯

做这套人机界面的时候，我一直提醒自己一件事：界面是给“调参的人”用的，不是给“CPU”用的。所以我把所有命令都设计得符合人的直觉，而不是方便机器解析。set kp 2.5比0x01 0x02 0x00 0x00 0x20 0x41直观太多了。串口命令行存在的意义，就是让控制工程师能像跟同事对话一样跟固件交流。

还有一个小技巧：在CLI里加一个plot命令，每隔一个固定周期输出一行类似SV,PV,OUT三个数值的CSV数据。电脑端用SerialPlot直接选逗号分隔符，就能画出实时的控制波形。这个功能我不需要做曲线绘制，只是把数据吐出去，整个整定过程的可视化问题就全部解决了。这个技巧推荐给所有做控制的朋友，尤其是手头没有逻辑分析仪和示波器的场景。

项目做到后来，我甚至觉得“人机界面”这四个字不应该只理解为屏幕或者按钮，任何让固件状态变得可见、让参数调整变得低成本的通道，都算人机界面。串口命令是，OLED是，哪怕只是一个状态LED，在关键时刻也能救你一把。先把这层交互打通，再谈整定，才是真正高效的嵌入式开发节奏。