简介：这份文档是基于STM32的逻辑分析仪设计与实现的完整方案，面向电子工程师、嵌入式爱好者及电气工程专业学生，针对电子产品研发调试中最棘手的逻辑信号分析问题给出高效解决思路。方案采用STM32处理器搭建下位机采集平台，负责各测试点电平的采集，并通过USB接口与上位机通信，最终以图形界面展示多通道波形数据。文中重点剖析了USB2.0协议、HID协议、CDC类协议下STM32 USB外设的配置方法，以及基于VC的图形界面程序设计与Windows XP环境下的USB驱动开发，还总结了STM32应用、USB接口、图形可视化、驱动设计等若干关键知识点。资源包共1个文件，格式为doc，大小1.17MB，包含中英文摘要、目录、绪论、逻辑分析仪简介、方案论证等完整章节，结构清晰。目前已有419人学习下载，非常适合正在开展嵌入式系统、虚拟仪器或数据采集类课题的开发者借鉴参考。 调试一块刚焊好的板子时，UART 波形怎么都不对，示波器只有两个通道，要盯 TX、RX，还要看电源、看复位，实在忙不过来。这种时候，真正的救星是一台逻辑分析仪，能一次抓 8 路、16 路数字信号，还能直接解码协议。但打开购物网站一看，一台入门级逻辑分析仪也要一两百，带协议解码的型号得上千。于是我开始琢磨：手里堆着不少 STM32 芯片，能不能自己拼一台出来？答案是能，而且做出来的东西完全够日常调试用。
这篇博文就把整个"基于 STM32 的逻辑分析仪设计与实现"过程复盘一遍，从方案指标、硬件电路、固件机制到上位机联调和踩坑记录，全部分享出来。适合正在做嵌入式开发、需要调试数字协议的朋友，也适合拿这个题目做毕业设计或课程项目的学生。看完之后你可以照着做一台，也可以理解它背后的原理，以后用任何逻辑分析仪心里都有底。
1. 方案与指标：先想清楚要做一台什么样的逻辑分析仪
1.1 为什么用 STM32 而不是 FPGA 或直接买成品
做逻辑分析仪，方案其实有好几条路：FPGA、CPLD、高速 USB 芯片、普通 MCU，还有直接买成品。FPGA 能做几百 MHz 采样率，但开发门槛高，一块开发板也不便宜；用过采样 USB 芯片如 CY7C68013A 是很多开源逻辑分析仪的做法，但芯片本身不好买，还需要写 USB 固件；而 STM32 的优势在于芯片容易获得、开发环境成熟、片上外设丰富，对大多数调试场景"刚刚好"。
我这里的定位很明确：不做高频示波器，而是做一台能抓 UART、I2C、SPI、DHT11、红外遥控、正交编码器这类低速数字信号的调试工具。STM32F103 主频 72MHz，8 通道做到 10MHz 左右采样率完全可行，而这已经覆盖了绝大多数日常调试场景。另外，自己做的逻辑分析仪可以随意改固件，加上自定义触发逻辑，甚至可以把它集成到自己的测试工装里，这是成品工具做不到的。
1.2 指标怎么定：采样率、通道数、采样深度之间的关系
很多同学一上来就问"能到多少采样率"，但逻辑分析仪真正要综合考虑的是三个指标：采样率、通道数、采样深度。三者互相制约，尤其是 STM32 这种内部资源有限的 MCU，必须一开始就算清楚账。
以 STM32F103C8T6 为例：主频 72MHz，内置 SRAM 官方标称 20KB（实际芯片有 64KB，但按保守设计用 20KB）。如果按"每个采样点 1 字节，低 8 位对应 8 个通道"来存，那么一次触发最多存 20KB / 1B = 20K 个采样点。20K 深度在 1MHz 采样率下只能抓 20 毫秒，而解码一个 9600 波特率的 UART 帧至少需要几十毫秒的窗口，显然不够用。所以设计时必须做取舍：
- 一次性快照模式：触发后存满缓冲区就停，适合抓特定事件前后的波形，深度等于缓冲区大小；
- 流式传输模式：边采样边通过 USB/串口往电脑传，理论上深度不受限，但采样率受通信带宽限制；
- 边沿捕获模式：只记录电平跳变的时刻，大幅压缩数据量，适合长时间监控，但无法还原低于最小脉宽的高频抖动。
| 方案 | 最高采样率（8通道） | 最大采样深度 | 适合场景 |
|---|---|---|---|
| GPIO 轮询 | 约 3~5 MHz | SRAM 限制 | 原理验证 |
| 定时器+DMA 快照 | 约 8~10 MHz | 20K 点（F103） | 触发抓取特定波形 |
| 定时器+DMA+USB 流式 | 约 500k~1M S/s | 受上位机内存限制 | 长时间观察低速协议 |
| 定时器输入捕获 | 分辨率 ≤ 1us | 理论上数千个跳变 | 长时间信号监控 |
我最终选择的是"定时器+DMA 快照+USB 上传"的组合，再辅助一个边沿捕获模式。做毕业设计或项目展示时，这套组合既能跑出漂亮的波形，又能讲清楚原理。
2. 硬件电路：别以为核心板接几根线就能用
2.1 输入通道怎么接：直接怼 GPIO 会出大问题
最省事的接法是把被测信号直接连到 STM32 的 GPIO 上，但这样做在真实调试中会踩坑。第一，被测板电平可能是 5V 甚至 12V，STM32 大部分引脚不兼容 5V，直接接上去运气好是误判，运气不好直接烧引脚。第二，数字信号边沿如果不干净，有振铃或毛刺，直接读 GPIO 会把毛刺当成有效跳变，造成误触发。第三，调试现场经常带电插拔探头，静电和浪涌很容易打坏芯片。
实际项目中我推荐这个链路：探头信号先串一个 100Ω 电阻，进入 74HC14 施密特触发器做波形整形，再输出到 STM32 的 PA0-PA7。74HC14 的输入电压范围宽，VCC 用 3.3V 时输入高电平阈值大约 1.8V 左右，能兼容 3.3V 和 5V 逻辑；施密特触发特性还能消除边沿抖动，让波形变干净。但如果被测信号只有 1.8V 逻辑，74HC14 的阈值可能偏高，这时可以用比较器（如 TLV3501）自己搭一个阈值可调的整形电路。
保护措施方面，我在 74HC14 前端加了 BAT54S 双二极管钳位到 3.3V 和 GND，这样即使误接 12V，电流也会被二极管泄放到电源和地，保住后端芯片。做 PCB 时还要在信号入口放一个 33pF 小电容到地，滤掉高频噪声。注意 74HC14 是反相器，输出逻辑会被取反，我最初没注意这点，导致上位机显示的波形高低电平完全反了，后来在固件里统一做了逻辑取反处理才解决。
2.2 通信接口选型：USB、串口还是无线
逻辑分析仪和上位机之间的通信链路，决定了数据能不能稳定传上来。我第一版用的是普通的 UART 转 USB（CH340），实现最简单，PulseView 的 OLS 驱动也支持串口通信，但波特率一般只能到 115200 或 460800，高速传输时容易丢数据。后来换成了 STM32 自带的 USB 外设做 CDC 虚拟串口，免驱动（Windows 10 以上自动识别），速度快很多，还能顺便给板子供电。
如果你想让逻辑分析仪独立工作，不依赖电脑，也可以用 ESP8266 或 ESP32 通过 Wi-Fi 把波形数据发到手机或电脑，但我个人不建议第一版就上无线，调试链路太多反而难排查问题。还有一个经常被忽略的接口是 SWD 调试口，板子上必须留出来，否则固件下载和调试会很难受。在 PCB 上我把 SWD 的四根线（SWDIO、SWCLK、GND、3.3V）单独做成一个 2.54mm 排针，方便用 ST-Link 连接。
2.3 供电与 PCB 布局的几个细节
电源是最容易被忽视又最容易出问题的地方。USB 的 5V 经过 AMS1117-3.3 稳压到 3.3V，输入输出端都要加 10μF 和 0.1μF 电容搭配去耦，电容靠近芯片引脚放置。74HC14 和 STM32 的电源引脚同样要加 0.1μF 去耦电容，否则信号边沿会产生电源噪声，导致误触发。如果是两层板，地平面尽量完整，信号线走短，尤其是探头输入那段，杜邦线越短越好，长了会引入振铃。
另外提一下，如果目标板和逻辑分析仪不共地，测出来的波形完全是乱的。探头组里 GND 夹子一定要先接好，再夹信号线，这个习惯能避免很多奇怪的干扰问题。
3. 固件实现：核心是"如何高速且稳定地采集数据"
3.1 GPI/O 轮询、定时器+DMA、输入捕获，三种方案怎么选
固件层的核心任务是采集数据。我最初用最简单的 GPIO 轮询：主循环里不停读GPIOA->IDR，把数据存进数组，但实测最高只能到 3~5MHz，而且采样间隔抖动大，波形在 PulseView 里看起来边沿是歪的。这是因为主循环还要处理其他任务，循环跳转、分支判断都影响采样均匀性。
更好的方案是"定时器+DMA 自动采样"：定时器产生固定频率的触发事件，每次触发 DMA 就从 GPIO 的 IDR 寄存器搬一个数据到内存缓冲区。这样采样时序完全由定时器硬件控制，均匀性极好，CPU 几乎不参与，DMA 搬完一整批数据后才产生中断通知 CPU 处理。我按这个方案实测 8 通道采样率能稳定跑到 9MHz 左右。
还有一种方案是"定时器输入捕获"，它不连续采样，而是记录每个电平跳变的时间戳。对于低速信号，一个 10ms 的 UART 帧只需要记录几十个跳变点，数据量比连续采样小几个数量级，甚至可以把采样时长拉长到几秒。缺点是它恢复不了高频抖动细节，而且软件要根据跳变时间重建波形，稍微复杂一些。我最后的固件里保留了这两种模式：正常抓波形用定时器+DMA，长时间监控用输入捕获。
3.2 定时器+DMA 采样的核心代码实现
用标准库写底层逻辑更直接，下面这段是定时器2 触发 DMA1 通道5 从 GPIOC->IDR 采样的核心初始化代码：
DMA_InitTypeDef DMA_InitStructure; TIM_TimeBaseInitTypeDef TIM_InitStructure; // 配置DMA：外设地址固定为GPIOC->IDR，内存地址指向采样缓冲区 DMA_DeInit(DMA1_Channel5); DMA_InitStructure.DMA_PeripheralBaseAddr = (uint32_t)&GPIOC->IDR; DMA_InitStructure.DMA_MemoryBaseAddr = (uint32_t)sample_buf; DMA_InitStructure.DMA_DIR = DMA_DIR_PeripheralSRC; DMA_InitStructure.DMA_BufferSize = SAMPLE_DEPTH; DMA_InitStructure.DMA_PeripheralInc = DMA_PeripheralInc_Disable; DMA_InitStructure.DMA_MemoryInc = DMA_MemoryInc_Enable; DMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Byte; DMA_InitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_Byte; DMA_InitStructure.DMA_Mode = DMA_Mode_Normal; DMA_InitStructure.DMA_Priority = DMA_Priority_VeryHigh; DMA_Init(DMA1_Channel5, &DMA_InitStructure); // 定时器分频，得到采样率：72MHz / (PSC+1) / (ARR+1) TIM_TimeBaseStructure.TIM_Prescaler = 0; TIM_TimeBaseStructure.TIM_Period = 7; // 72MHz / 8 = 9MHz采样率 TIM_TimeBaseStructure.TIM_ClockDivision = TIM_CKD_DIV1; TIM_TimeBaseInit(TIM2, &TIM_TimeBaseStructure); // 先使能DMA，再使能定时器，顺序不能反 DMA_Cmd(DMA1_Channel5, ENABLE); TIM_Cmd(TIM2, ENABLE); // 等待DMA传输完成 while (DMA_GetFlagStatus(DMA1_FLAG_TC5) == RESET);有个很容易踩的坑：DMA 搬运的数据宽度如果设成 32 位，那么读取GPIOC->IDR会整个 32 位都存下来，每个采样点占 4 字节，缓冲区很快就满了。如果只关心 8 个通道，数据宽度用 8 位就够了，但要注意外设地址还是 32 位的 IDR，DMA 会把最低字节搬进内存，所以每个采样点其实对应的是 IDR 的低字节。先使能 DMA 再使能定时器这个顺序也特别重要，如果反过来，定时器先跑起来，DMA 还没准备好，第一批采样数据就会丢失。
3.3 数据上传与 SUMP 协议兼容
上位机软件是另一个大问题。自己写一个上位机太耗时，最省事的办法是让固件兼容现成的开源协议。我做的是兼容 SUMP 协议——这是 OpenBench Logic Sniffer 项目的开放协议，PulseView（sigrok 的上位机）原生支持，只要通过串口发命令、收数据就行。
SUMP 协议的核心交互流程是：上位机发复位命令，设备返回 ID；上位机配置采样率、通道掩码、触发条件；上位机发开始采样命令；设备触发后把缓冲区数据通过串口上传。这个协议的命令格式网上有公开文档，实现起来不复杂。如果不想做 SUMP，也可以用自定义协议，自己写 Python 脚本解析数据，但那样就错过 PulseView 自带的协议解码功能了，所以建议还是做 SUMP 兼容。
固件里还要注意串口帧格式必须和上位机一致，尤其是波特率。如果通过 USB CDC 虚拟串口通信，不需要配置波特率，但需要通过CDC_Receive回调处理上位机发来的命令，并把采集数据通过CDC_Transmit发送。为了避免上位机读取超时，我建议每次上传数据前先发一个固定帧头，再发数据本体，上位机按帧头同步解析，这样即使前面有脏数据也能重新同步。
4. 上位机联调：PulseView 的使用与实测
4.1 环境准备：安装 PulseView 并配置 OLS 驱动
PulseView 是 sigrok 项目的图形前端，支持 Windows、Linux、macOS，安装包在官网直接下载。连上自制的逻辑分析仪后，在 PulseView 的"采集"对话框里选择驱动为"OpenBench Logic Sniffer (ols)"，设置串口号。如果用的是 USB CDC 虚拟串口，在 Windows 设备管理器里能看到一个"COM 端口"设备，选对应 COM 号即可。波特率在 CDC 模式下无所谓，但如果是用外部 USB 转串口模块接的 UART，波特率要设成 115200 或更高，并和固件保持一致。
4.2 实测：抓一段 UART 数据并解码
我在测试板上用 STM32 的 USART1 以 115200 波特率持续发送字符串"STM32 Logic Analyzer"，然后把自制逻辑分析仪的通道 0 接 TX 引脚、通道 1 接 RX 引脚，GND 接 GND。在 PulseView 里设置采样率 2MHz、采样深度 20K，采集后添加"UART"协议解码器，设置波特率为 115200，立即就能看到解码结果正确显示为 ASCII 字符。
这里有个实操经验：采样率至少要设置成信号频率的 5 倍以上。如果 115200 波特率的 UART 用 500kHz 采样，每个位周期只有约 4 个采样点，解码偶尔会出错；用 2MHz 后，每个位有约 17 个采样点，解码非常稳定。所以我在 PulseView 里保存了一个常用的参数预设：UART 115200 用 2MHz、I2C 400kHz 用 4MHz、SPI 1MHz 用 8MHz。这样每次只需选预设，不用每次手动调。
4.3 采样率与采样深度的实战权衡
很多初学者都纠结"采样率越高越好吗"，实际不是。采样率越高，同样深度下能抓的时间越短。20K 深度在 9MHz 采样率下只能抓约 2.2 毫秒，可能还没来得及看到完整的一帧数据缓冲区就满了；而在 500kHz 采样率下能抓 40 毫秒，足够观察好几帧 UART 数据。
我的经验是：先根据"要抓的信号是什么"决定采样率，再算出需要的采样深度。比如调试 I2C，总线上有设备地址、寄存器地址、数据，一帧可能几十个字节，每个字节 9 个位周期，用 2MHz 采样率约需要几百 K 点才能完整抓下。这时要么外扩 SRAM，要么开启流式传输模式。我的解决方案是在固件里支持"连续采样+边采边传"，PulseView 端会不断从串口读取数据，这样采样深度不在受限于 MCU 内存。注意流式传输时采样率受 USB 虚拟串口实际吞吐影响，我实测在 USB FS 模式下，8 通道约能稳定跑到 500k~1M S/s，对低速协议足够了。
| 调试场景 | 建议采样率 | 建议采样深度 | 单次抓取时长（约） |
|---|---|---|---|
| UART 115200 | 2 MHz | 100K 以上 | 50 ms |
| I2C 400kHz | 4 MHz | 500K 以上 | 125 ms |
| SPI 1MHz | 8 MHz | 1M 以上 | 125 ms |
| DHT11 温湿度 | 200 kHz | 20K | 100 ms |
| 正交编码器 | 2 MHz | 100K | 50 ms |
5. 实测过程中遇到的那些坑（附排查速查表）
5.1 烧录失败：stm32 error: no stm32 target found
做完板子第一次接 ST-Link 烧录，就碰到这个经典报错："error: no stm32 target found! if your product embeds debug authentication..."。排查顺序我是这样做的：先量 VDD 是否为 3.3V，再量 SWDIO、SWCLK 对地是否短路，拿万用表量一下接线是否一一对应。如果这些都正常，再看复位电路，某些复位引脚上如果挂了太大的电容，会导致芯片一直处于复位状态，SWD 连接不上。还有一个隐蔽原因是芯片之前被设置了读保护或调试认证，这种情况下需要用 ST-Link Utility 先解除保护，再重新连接。如果是自己画的板子，还要检查 VCAP 引脚（F103 的 VCAP_1/VCAP_2）是否接了合适容值的电容，这个引脚没接好芯片根本跑不起来。
5.2 USB 虚拟串口在 Windows 上出现感叹号
我用 CubeMX 生成的 USB CDC 工程在 Win10 上经常出现"STM32 Virtual COM Port"设备带黄色感叹号。排查发现主要是驱动识别问题：如果电脑上之前装过其他厂家的 CDC 驱动，可能冲突。解决方法是把设备管理器里的设备先卸载，拔掉 USB 线，重新插上让系统自动装驱动。如果还不行，可以用 Zadig 工具把驱动强制替换为系统自带的 usbser.sys。另外 USB 通信对时钟要求很高，F103 需要外接 8MHz 晶振并通过 PLL 倍频到 72MHz，再分频得到 48MHz USB 时钟；如果用了内部 HSI，USB 会枚举失败或频繁掉线。这个坑排查了很久才定位到，拿示波器看晶振波形最好确认。
5.3 采集到的数据错乱、波形乱跳或者丢包
波形乱跳，首先要怀疑的是探头的 GND 线没接好。逻辑分析仪和被测板必须共地，而且 GND 线越短越好。如果接了地还是乱跳，检查目标板电源纹波，电源不稳会导致信号边沿来回抖动，74HC14 整形后依旧会有毛刺。其次检查采样率是否足够，采样率太低会让边沿位置误差变大，看起来像是毛刺。丢包问题则优先检查 USB 传输链路：DMA 传输完毕中断后立刻开始下一次采样，如果上位机来不及读走数据，缓冲区就溢出了。我把 DMA 优先级调到最高，同时把"采集"和"上传"用环形缓冲区解耦，串口传输占用的时间不会影响下一次 DMA 采集，这样丢包率明显下降。
5.4 实战案例：用自制逻辑分析仪调试正交编码器
最后分享一个典型的实战案例。我用一个带正交编码器输出的直流减速电机，A 相和 B 相接逻辑分析仪的通道 0 和通道 1。在 PulseView 里设置采样率 2MHz、采样深度 100K，采集电机启动过程，添加"正交解码器"协议解码，就能清晰看到 A、B 两路 90 度相位差的方波，以及正转、反转时相位关系的切换。这个案例特别适合验证逻辑分析仪本身的可靠性：如果相位关系、脉冲计数都对，说明采样链路没有丢数据，触发也稳定。
当时配合这个验证还发现了一个固件 bug：输入通道的 74HC14 反相导致 A、B 信号同时取反，方向判断反了。后来在固件里把反相标志设为可配置，通过一个小工具函数做通道数据取反，就能在正逻辑和反逻辑之间切换，PulseView 里显示就正常了。这类"通道极性"的问题在调试逻辑分析仪时非常典型，排查时一定要先确认波形高低电平和预期一致。
做完整台逻辑分析仪，我自己调试板子的效率确实高了不少。遇到 I2C 死锁、UART 乱码、SPI 时序不对，第一反应就是拿逻辑分析仪看波形，而不是盲改代码。这个项目最大的价值不是省那几百块钱，而是把定时器、DMA、外部中断、USB 通信、上位机协议解析这些知识点全部串起来了，做完一遍对整个 STM32 系统的理解会提升一个台阶。最后给个建议：第一版先别追求通道多、采样率高，8 通道能抓 UART、I2C、SPI 就够了，先把采样、传输、显示的链路跑通，再考虑加触发、加深存储、加协议解码，一步一步来，成功率会高很多。
本文还有配套的精品资源，点击获取
