SerialPlot：把串口数据画成实时波形，停更一年还能用吗（v0.13.0）

SerialPlot 干的事只有一件：把串口里收到的数值实时画成波形图。它是开源软件，许可证 GPL-3.0，仓库在 hyOzd/serialplot，项目主页挂在 Hackaday.io 上。

本文记录时的最新版本是 v0.13.0，发布于 2025-03-08，此后逾一年没有新版本。这件事要不要紧，后面单开一节讲。具体支持哪些数据格式、界面上有哪些设置项，以官方文档与仓库说明为准，本文不做转述。

一列滚动的数字，人眼读不出趋势

你手上多半已经有一个串口助手了。它把设备发来的东西一行行往下滚，该有的都有。那为什么还要再装一个只会画线的工具？

因为人眼从滚动的数字里几乎读不出趋势。

这不是熟练度问题。数字是离散的、逐个到达的，你要在脑子里同时记住前二十个值、比较它们的相对大小、还要感知变化的快慢——大脑做不到这件事，或者说做得极其吃力。而这几样东西画成一条线之后，是一眼的事：线在往上爬还是在收敛，是平稳还是在抖，抖得有没有规律，有没有某一刻突然跳一下。

具体到几个场合，差别大到不是「方便一点」而是「能做和不能做」：

调 PID。 你要看的是阶跃响应的形状：超调有多大、振荡几个周期才收住、有没有稳态误差、收敛得快不快。这四件事全是曲线的形状特征。盯着数字列表调 PID，等于闭着眼睛拧螺丝——不是慢，是根本判断不了刚才那次改参数是变好了还是变坏了。

看传感器噪声。 一个温度值在 25.1 和 25.3 之间来回跳，看数字你只会觉得「挺稳的，误差 0.2 度而已」。画成波形之后可能完全是另一回事：如果这个抖动是规则的、有固定周期的，那它就不是传感器本身的随机噪声，而是有一个明确的外部来源——工频干扰、电机的 PWM、开关电源的纹波，都会以这种规则波形的样子出现。随机的毛刺和规则的波动，在数字列表里长得一模一样，在波形上是两种截然不同的东西。

验证滤波效果。 加了一阶低通、加了滑动平均，到底有没有用、代价是多大的延迟，把滤波前后两路值同时发出来画在一起，看一眼就知道。用数字对比这件事，做不了。

找偶发的突变。 设备十分钟才抽风一次，你盯着数字流是盯不到的；波形上那个尖峰会自己跳出来。

反过来说也成立：如果你要看的是报文内容、是十六进制字节、是「设备回没回 ACK」，那画波形毫无意义，老老实实用串口助手。这两类工具解决的是完全不同的问题，不存在谁替代谁。

数据是怎么从串口进到图里的

有必要说清中间这一层，因为大部分「画不出来」的问题都出在这里。

串口本身是字节流，没有「一帧」「一个数值」的概念。 它只负责把字节按顺序送过去，至于哪几个字节合起来算一个数、一次采样有几个通道，全靠收发两端事先约定。绘图工具能不能画，取决于你的单片机发出来的东西是不是按某种它能识别的约定组织的。

单片机这一侧最常见的做法是发逗号分隔的数值加换行——一行一次采样，行内用逗号隔开多个通道。这种纯文本格式的好处是你用任何串口助手都能直接读，坏处是同样的数据要占更多字节。想省带宽就发二进制，代价是可读性没了，且要多操心字节序和对齐。具体格式怎么配，看官方文档。

波特率会成为高频采样的硬瓶颈。 这是很多人没算过的一笔账：串口的传输速率是固定的，你每秒采样多少次、每次发多少字节，两者相乘不能超过链路能承载的量。想把采样率往上提，要么压缩每次发送的字节数，要么把波特率提上去，没有第三条路。超了的表现是数据开始堆积、波形明显滞后于实际动作——这时候改绘图工具的设置没有用，瓶颈不在它身上。

图的刷新快慢，受限于数据到达的速率。 绘图工具画的是它收到的东西，设备一秒只发十次，图上就不会有比十次更细的信息。这一条听着像废话，但它能省掉一类无谓的排查：波形看着「不够顺滑」，先回去看发送侧的采样与发送频率，而不是在绘图工具里找设置。

它和 PulseView 不是一类东西

这两个很容易被放在一起比较，但它们看的根本不是同一样东西。

SerialPlot 画的是你的程序主动从串口发出来的数值。 那些数字是 MCU 里算出来的：ADC 转换完的结果、传感器库返回的温度、PID 的输出量。它们已经经过了你的代码——采样、换算、可能还滤过一次。

PulseView 配合逻辑分析仪硬件，抓的是引脚上的真实电平。 它看到的是线上那一刻究竟是高还是低、跳变发生在第几微秒、两个信号之间差了多久。这些是物理事实，和你的代码写得对不对无关。

所以它们的用途正好分在两头：

• 想知道**「我的算法算出来的量对不对、稳不稳」**，用 SerialPlot；
• 想知道**「线上到底有没有发生我以为发生的事」**，用 PulseView 加硬件。

举个最能说明区别的场景：I2C 读传感器读回来一堆异常值。用 SerialPlot 你看到的是一条乱跳的曲线——它告诉你结果不对，但不告诉你为什么。接上逻辑分析仪用 PulseView 看，你可能发现从机根本没回 ACK，或者时钟被拉低了。前者告诉你「有问题」，后者告诉你「问题在哪」。

顺带一提，PulseView 必须配硬件才有意义，SerialPlot 只要一根串口线。成本和门槛差着一档。

停更逾一年，还能不能用

这是选它之前必须自己想明白的一件事，别人的结论不能替你拍板。

事实摆在这：v0.13.0 发布于 2025-03-08，到本文记录时逾一年没有新版本。 仓库还在，能访问，能拿到代码和历史版本。开源项目长时间不发版有很多种可能——作者转向别的事、功能已经够用不需要改、或者攒着改动没有发布——从「没发新版」这一条推不出「项目已经死了」，这里只登记事实，不下判断。

比结论更有用的是判断方法。一个工具停更之后风险有多大，取决于它依赖什么：

核心功能这一侧，风险低。 它做的是读串口、画曲线。串口协议是几十年不变的东西，绘图算法也不会过时。程序昨天能画出正确的波形，明年跑起来一样能画对——没有哪个「新标准」会让串口的字节突然读不出来。

风险落在系统与依赖库这一侧。 桌面软件会随着操作系统升级慢慢出问题：新系统的驱动模型变了、签名策略收紧了、依赖的图形库或运行时不再随系统提供了。这类问题不影响「算得对不对」，但会影响「装不装得上、跑不跑得起来」。它是开源的，卡在编译上时理论上你可以自己改自己编，但那要求你愿意花这个时间。

给一个务实的取舍：它在调试链条里的位置是辅助的，不是生产系统的一环。 你不会把它部署到产线上，它挂了也不会导致任何交付物出问题——大不了换一个工具，或者把数据存下来事后画。这种定位下，停更的代价是可以承受的。反过来，如果你打算把它写进公司的标准调试流程、要求所有人装同一个版本，那你得先想清楚三年后新员工的新电脑装不上时怎么办。

先在你自己的机器上跑通，再决定要不要依赖它。 这句话对任何停更的工具都成立。

它不适合的场合

不要指望它替代串口助手。收发报文、看十六进制、自动应答、按脚本定时发送——这些它不是干这个的，该用串口调试助手就用串口助手。实际工作中常见的组合是两个都开着：一个盯报文，一个盯波形。

不要用它替代示波器或逻辑分析仪。它画的曲线的时间精度，受限于你的采样频率和串口速率，跟硬件测量仪器不是一个量级。要看纳秒级的时序，只能上硬件。

也不要在还没把串口本身调通的时候就先装它。先用串口助手确认参数对了、数据能正常收到、格式和你预想的一致，再谈画图。 参数没对就直接开绘图工具，你只会看到一片空白，然后在一个多出来的工具里排查一个本不属于它的问题。