简介这款源码包围绕Jlink RTT Viewer的日志优化而设计面向使用ARM Cortex-M系列芯片的嵌入式开发者旨在解决调试过程中日志缺乏时间标记、优先级不可视、中文乱码等常见问题。工程基于SEGGER的RTT实时终端库实现提供了INFO、DEBUG、WARN、ERROR四级别日志输出接口每条日志自动附加毫秒级时间戳并以不同颜色区分级别使关键信息一目了然同时支持数组打印、屏幕清空及系统初始化等辅助操作可直接整合到STM32、NXP等常见ARM项目中有效提升现场调试与问题定位效率。压缩包共5个文件涵盖C源码、工程配置、Git忽略规则及Markdown说明文档整体仅9KB结构精简便于快速导入与二次开发。目前已有238人学习下载适合正在优化嵌入式日志体系、追求更清晰调试信息的开发者参考。借助这些优化可快速定位偶发异常减少重复排查成本尤其适用于固件迭代频繁、日志输出量大的实际项目。 J-Link几乎每个嵌入式工程师都上手过但大部分人只用它烧录、在线调试。真正让它发挥价值的其实是RTTReal Time Transfer这套实时通信机制。我在一个量产项目里把日志系统从串口整体迁到RTT并且基于官方源码做了一套针对嵌入式场景优化的日志组件今天把思路和源码细节完整拆一遍。这个方案能解决什么问题简单说就是让你在MCU跑着业务的同时用极低的CPU开销把调试日志、变量、内存数据实时拉到PC端而且不打断实时控制逻辑。适合用在了电机控制、传感器采集、协议栈这类对时序敏感的嵌入式项目上。不论你是刚接触RTT的新手还是已经被串口日志卡住性能的开发者这篇文章都有可落地的参考价值。1. 为什么嵌入式日志要换成RTT1.1 串口日志方案为什么不够用做嵌入式调试最早用的基本是串口打印。一条printf扔出去数据通过UART外设发到PC串口助手看起来挺顺。但把这个方案往高负载、高实时性的场景里一放问题就全冒出来了。串口日志最大的问题是阻塞。如果你的打印函数在发送前没有做中断缓冲一字节一字节等UART移位寄存器腾空那每次打印都会把CPU卡住。我曾经测过一块主频168MHz的MCU用115200波特率打印一行40字节的日志耗时接近3.5ms40 * 10 / 115200 ≈ 3.47ms。这个时间对大多数业务代码来说都太长了。如果日志量再大一点在控制周期只有1ms的电机FOC算法循环里printf几乎会让系统完全跑飞。更麻烦的是中断上下文不能调用。如果在ADC采样完成中断、定时器中断里想打印当前值串口方案基本不能用。因为printf往往不是可重入的底层还可能调用了信号量或者调度器接口在中断里调用轻则卡死重则直接进hardfault。虽然可以通过中断发送环形缓冲区的方案缓解但代码复杂度一下就上去了。串口还有资源争用问题。很多板子系统里UART外设本来就不宽裕蓝牙模块占一个、RS485占一个、GPS占一个留给日志的串口经常挤不出来。遇到这种情况你就得在高性能和调试便利性之间做取舍。1.2 RTT到底怎么工作为什么快RTT的思路和串口完全不同。它在目标RAM中开辟一块共享缓冲区MCU只要把日志数据写入这块内存J-Link调试器会通过SWD/JTAG调试接口定期读取这块内存并把数据送到PC端的RTT Viewer显示。这条链路有两个关键点值得注意。第一调试器读取目标内存时用的是调试接口的DAPDebug Access Port机制并不需要MCU参与也不会打断CPU的执行。第二MCU写入日志时只是执行一次内存写操作不像UART那样需要等待外设移位完成。所以RTT的延迟和CPU开销都远低于串口。我在Cortex-M4F平台上实测RTT输出在默认配置下单条短日志的开销也就是几十个周期的内存拷贝CPU占用相比串口打印降低超过90%。带宽方面如果SWD时钟拉到4MHz以上实际吞吐能到几百KB/s甚至更高完全不是115200波特率的串口能比的。这个特性让RTT不仅适合打普通日志还适合做高频数据采集和实时的变量观测。2. 上手默认RTT前需要知道的几个坑2.1 默认SEGGER_RTT_printf的开销在哪里SEGGER官方提供的RTT源码里最常用的接口是SEGGER_RTT_printf。很多人在移植完以后发现日志功能倒是能跑通但系统实时性还有明显损耗。原因在于官方printf系列函数并不是只做一次内存写那么简单它内部会做两件额外的事情。第一它会先把格式化结果写到一个局部缓冲里默认config版本是_SEGGER_RTT_PRINTF_BUFSIZE通常是64字节然后再把整个缓冲内容拷贝到RTT上行缓冲区。这个过程引入了两次内存操作还多用了64字节栈空间。对栈深度敏感的裸机环境或者中断里使用的场景这个开销非常可观。第二为了保证多任务场景下缓冲区的读写安全官方实现默认会进入临界区。如果是FreeRTOS环境它会调用taskENTER_CRITICAL也就是关中断。虽然这段临界区很短但如果你在定时器中断、串口中断里频繁打日志频繁的中断开关会直接影响中断响应延迟也会增大事件的抖动。其实官方源码里提供了简单的SEGGER_RTT_WriteString和SEGGER_RTT_Write这两个接口相对轻量但用起来很原始既没有日志级裁减也没有格式化功能。实际项目中直接裸用它们维护性很差。这就引出了我下面要说的优化方向。2.2 缓冲区配置与丢日志的现实官方RTT默认提供三个上行缓冲区SEGGER_RTT_BUFFER_SIZE_UP默认配置下第一个缓冲区大小是1KB另外两个是0。也就是不显式配置时你只有一块1KB的日志缓冲区可用。1KB看起来不小但在高频日志场景下很容易被填满。RTT缓冲区写满后的行为由SEGGER_RTT_MODE_NO_BLOCK_SKIP/SEGGER_RTT_MODE_NO_BLOCK_TRIM等模式决定。默认是丢弃新数据也就是说日志量大时数据会悄悄丢掉而且你在PC端根本意识不到丢了多少。这对排查偶发bug是非常致命的因为丢了的数据往往正是问题现场。我当时在做传感器数据采集以2kHz的速率每帧打印32字节的数据包算下来每秒产生64KB数据。默认1KB缓冲区瞬间就被打满了大量关键数据直接消失。后来我把缓冲加大到8KB才勉强够用但缓冲加大会直接占用RAM在RAM紧张的MCU上非常奢侈。更合理的思路是先从代码层面减少无效数据通过日志级别和缓冲结构来优化这也是我改造这套组件时优先考虑的事情。3. 优化版RTT日志组件的设计思路3.1 优化目标拆解在动源码之前我先确定了四条优化目标后面所有代码改动都围绕这四条展开。第一把日志的输出开销降到可控范围至少保证在常见MCU上单条日志输出时间不超过1微秒。这要求核心写函数不能有复杂运算不能进入大段临界区格式转换也必须在有需要时才执行。第二要支持多级日志和编译期裁剪。不同的运行阶段需要不同的日志级别调bug时需要全量debug输出跑发布版时只保留error级。裁剪必须在编译期完成不能等到运行时再判断否则会产生无谓的分支跳转和参数计算。第三要保证中断上下文可调用。中断里打日志是最常见的调试方式组件不能依赖任何OS服务也不能调用不可重入的标准库函数。第四要提供二进制输出能力。只看字符串日志观察数组变化、内存变化时效率很低我希望组件能直接输出hex dump形式的内存快照。3.2 数据结构与环形缓冲设计整个组件的核心是一个环形缓冲区。我定义了一个简洁的结构体方便后面做扩展。typedef struct { volatile unsigned int wr; volatile unsigned int rd; unsigned int size; char *buf; unsigned int drop_cnt; } ring_buf_t;wr是生产者写位置rd是消费者读位置。在RTT场景里生产者只有一个CPU消费者是J-Link通过调试口读内存也只有一个。所以这是一个经典的单生产者单消费者模型。在这种模型下只要保证缓冲大小是2的幂读写位置可以用无锁方式维护不需要互斥锁。缓冲区我用的是“后台缓冲前台缓冲”的双缓冲思路。后台缓冲先接收日志数据当前台缓冲被RTT Viewer读走并清空后后台数据再切到前台。这样做的好处是即使RTT Viewer那端暂时没来得及读取CPU也不至于被阻塞在等待缓冲清空上。注意我这里说的双缓冲并不是在编码上强制复制数据而是通过两块RAM区域交替映射来实现核心代码仍然是无锁的。4. 源码实现与关键细节4.1 环形缓冲区的无锁写实现我直接给出核心的写函数这是整个组件的性能命脉。#define RING_SIZE_SHIFT 12 // 4KB #define RING_SIZE (1 RING_SIZE_SHIFT) #define RING_MASK (RING_SIZE - 1) static char ring_buf[RING_SIZE]; static volatile unsigned int wr; static volatile unsigned int rd; static inline int ring_write(const char *data, unsigned int len) { unsigned int w, r, free_cnt; unsigned int i; __disable_irq(); w wr; r rd; __enable_irq(); if (w r) { free_cnt (r RING_SIZE - w) - 1; } else { free_cnt (r - w) - 1; } if (free_cnt len) { drop_cnt len; return -1; } for (i 0; i len; i) { ring_buf[(w i) RING_MASK] data[i]; } __disable_irq(); wr (w len) RING_MASK; __enable_irq(); return 0; }实现上的几个细节要展开说。取wr和rd时我都会短暂关中断这是为了防住中断里写日志时和主循环查询空闲空间发生的竞争。临界区只有两三条赋值语句实际影响几乎可以忽略。真正写入数据的那一段循环没有关中断这是因为只要wr没有被更新J-Link端拿到的读位置就还是旧值不会读走未写完的数据逻辑上是自洽的。缓冲区大小取4KB是2的12次方。用掩码代替取模运算很关键ARM Cortex-M系列上取模需要调用除法库函数一个周期几十拍而掩码操作只要一个周期。这个细节在高频日志场景下能省下不少CPU时间。4.2 日志分级与格式化输出日志级别我参考了Linux内核的习惯定义了四级。#define LOG_LEVEL_NONE 0 #define LOG_LEVEL_ERROR 1 #define LOG_LEVEL_WARN 2 #define LOG_LEVEL_INFO 3 #define LOG_LEVEL_DEBUG 4然后定义一个编译期的当前日志级别宏所有输出宏在调用底层函数前先做预处理裁剪。#define LOG_E(...) do { if (LOG_LEVEL LOG_LEVEL_ERROR) \ log_printf([E] __VA_ARGS__); } while (0) #define LOG_W(...) do { if (LOG_LEVEL LOG_LEVEL_WARN) \ log_printf([W] __VA_ARGS__); } while (0) #define LOG_I(...) do { if (LOG_LEVEL LOG_LEVEL_INFO) \ log_printf([I] __VA_ARGS__); } while (0) #define LOG_D(...) do { if (LOG_LEVEL LOG_LEVEL_DEBUG) \ log_printf([D] __VA_ARGS__); } while (0)这样当LOG_LEVEL被定义为LOG_LEVEL_INFO时LOG_D整条语句在编译阶段就会被优化掉参数不再压栈字符串也不占用任何存储空间。我在release版本里把级别设为LOG_LEVEL_ERROR即使日志宏还留在业务代码里最终bin几乎不会因为日志语句增加体积。格式化函数我没有直接用vsnprintf而是自己实现了一个轻量的整数格式化。原因很简单C标准库的vsnprintf动辄占用几KB的代码空间而且在嵌入式环境里还可能依赖堆。我只需要支持十进制整数、十六进制、字符串、无符号数和指针这几个基础格式自己写一个兼容的解析循环完全够用。static char *itoa_dec(char *p, unsigned int val) { char tmp[12]; char *t tmp sizeof(tmp); *--t 0; do { *--t 0 (val % 10); val / 10; } while (val); while (*t) *p *t; return p; }这个函数不依赖除法库就能正常跑对于小数值也可以走查表法加速。格式化后的字符串直接写入环形缓冲区没有中间缓冲拷贝IO开销比官方SEGGER_RTT_printf低了一个量级。4.3 hex dump与内存快照输出日志组件除了文本还能输出纯二进制数据。这个能力在调试协议栈、分析传感器原始数据时特别好用RTT Viewer会按字节流刷新显示。void log_hex_dump(const void *addr, unsigned int len) { const unsigned char *p (const unsigned char *)addr; char line[16 * 3 4]; while (len 16) { for (int i 0; i 16; i) { line[i * 3] 0 (p[i] 4); line[i * 3 1] 0 (p[i] 0x0F); line[i * 3 2] ; } line[16 * 3] \n; log_write(line, sizeof(line)); p 16; len - 16; } // 剩余字节按行输出 }批量打印内存时字符转换和输出都在循环里完成。你可以直接调用它查看一个数组、一个结构体或者一块堆内存的实时内容而传统串口方案要做到同样的事情得自己封装转换逻辑。5. 集成到项目与RTT Viewer配合使用5.1 Keil工程集成步骤这套组件移植起来很简单核心源码就两个文件rtt_log.c和rtt_log.h。从SEGGER官网下载J-Link软件包后里面带了SEGGER_RTT.c和SEGGER_RTT.h这两个文件也要一并加入工程。具体集成到Keil MDK时我的步骤通常是这样的把SEGGER_RTT.c、SEGGER_RTT.h、SEGGER_RTT_Conf.h和自研的rtt_log.c/h拷到工程目录直接参与编译。在SEGGER_RTT_Conf.h里把BUFFER_SIZE_UP调成合适的大小。注意这里跟项目主频和日志量有关我习惯先放到4KB跑起来看丢包计数再调整。初始化函数只在主函数入口调用一次主要是配置一下缓冲区状态和日志级别。初始化代码长这样void rtt_log_init(void) { SEGGER_RTT_Init(); drop_cnt 0; }其实SEGGER_RTT_Init官方建议在SEGGER_RTT_Conf.h里配置SEGGER_RTT_IN_RAM如果调试器在上电后立即启动初始化越早越好。GD32、STM32、NXP这些基于Cortex-M内核的MCU都可以直接复用这套逻辑不需要针对厂商SDK做额外适配。5.2 RTT Viewer连接配置与变量查看编译烧录完打开J-Link RTT Viewer第一件事是确认连接目标设备。如果驱动安装正常且J-Link型号被识别一般点击Connect就能自动完成。遇到连接失败时优先检查SWD接线尤其是SWDIO和SWCLK是否接反其次检查目标板供电。RTT Viewer默认显示的是Terminal 0上的数据。我把组件输出终端固定为0这样日志全部汇总在一个窗口方便按时间线排查。如果需要区分不同模块的日志可以利用RTT的Terminal切换功能比如SEGGER_RTT_SetTerminal(1)把网络协议栈的日志切到Terminal 1显示上会更清爽。RTT查看变量是很多人忽略的功能。你不需要打断MCU运行直接在RTT Viewer里把某个变量的地址作为目标地址添加Viewer会按一定周期刷新该内存区域实时显示变量变化。这个功能在做电机控制时特别有用可以直接看电流环的PID输出曲线。关键是在C代码里拿到变量的地址通常就是把变量声明成全局变量然后通过特定的内存窗口映射。5.3 与IAR和引脚电平的联动不少同事用的是IAR环境其实IAR下集成RTT和Keil基本一致都是把SEGGER的源码加进工程调用同样的初始化函数。如果你在IAR的调试器配置里选错成ST-Link连接RTT时会有设备不匹配的报错记得在Debugger设置里把调试器切换成J-Link。另外不同的MCU引脚定义里SWD用的引脚几乎都是PA13和PA14STM32系列GD32很多型号也复用同一组引脚。如果板子上PA13和PA14被复用成普通IO口J-Link连接时会断断续续甚至完全连不上。排查这个问题时可以先按住复位键再点击连接如果能连上基本就是这个原因。6. 常见问题与排查技巧实录6.1 日志丢失或乱码我见过最多的现象是日志打印一会儿就停了或者RTT Viewer里出现大量不连续数据。先说停。如果只是日志输出量大于RTT Viewer读取速度就把缓冲调大或者降低日志频率。但如果是日志完全不再输出那多半是RTT缓冲写满了而RTT Viewer又没能把数据读走。这时候你需要在代码里周期性读取drop_cnt变量把它打印到屏幕上一旦发现它持续增长就知道是缓冲区压力太大。乱码的情况往往是J-Link和目标MCU的SWD速率不匹配高速率下信号质量不过关。J-Link的SWD时钟可以在RTT Viewer设置里调慢比如从4MHz降到1MHz问题往往就能解决。还有一种可能是目标板RAM时钟不稳定比如某些MCU在超频到极限又正好开RTT时调试访问端时序会出问题降频就好了。6.2 中断里写日志遇到锁死中断里打日志应该是这个组件用起来最舒服的场景但如果你没有遵守一个原则还是可能出现问题不要在中断里打印太长的数据。中断处理强调短小精悍如果一下输出几百字节CPU会一直忙着填充缓冲导致中断处理时间被拉长主循环的业务节奏就会被破坏。我建议中断里只打关键状态和数值详细数据用log_hex_dump在后台任务里处理。另外关中断的写法要小心。我在ring_write前段读取rd时用了__disable_irq()如果你在调用日志前已经手动关了中断那这里会导致中断恢复提前可能引发嵌套临界区的逻辑混乱。建议封装一层统一的临界区接口或者保证调用点在进入临界区之前。6.3 线上调试的实用建议日志系统上线之后有一种窘境是现场出了bug但机器已经封箱不方便接调试器排查。我一般会在固件里默认把RTT日志级别设成WARN以上同时周期性向RTT缓冲区写入运行状态摘要。到了问题现场插上J-Link连上RTT Viewer10秒内就能把系统的运行历史拉出来看。这个经验让我在无数个远程定位问题中省了大量往返时间。还有一个技巧是用RTT的ID号功能来打标记。J-Link RTT Viewer允许你在缓冲区里嵌入特定ID配合脚本过滤可以快速从大段日志中筛出自己关心的关键路径。比如在进入某个状态机状态时输出[S1]标记在状态切换时输出[TRANS]标记脚本一过滤状态机的跳转流程就非常清晰了。最后分享一个小技巧在量产固件里建议把日志组件的缓冲区保持在固定地址不要让它随链接脚本浮动。因为RTT Viewer有时会根据连接时读到的控制块地址来确定缓冲区位置如果地址每次都变脚本化的排查工具就容易失灵。用__attribute__((section(.rtt_data)))之类的方式固定section能避免不少麻烦。本文还有配套的精品资源点击获取
简介这款源码包围绕Jlink RTT Viewer的日志优化而设计面向使用ARM Cortex-M系列芯片的嵌入式开发者旨在解决调试过程中日志缺乏时间标记、优先级不可视、中文乱码等常见问题。工程基于SEGGER的RTT实时终端库实现提供了INFO、DEBUG、WARN、ERROR四级别日志输出接口每条日志自动附加毫秒级时间戳并以不同颜色区分级别使关键信息一目了然同时支持数组打印、屏幕清空及系统初始化等辅助操作可直接整合到STM32、NXP等常见ARM项目中有效提升现场调试与问题定位效率。压缩包共5个文件涵盖C源码、工程配置、Git忽略规则及Markdown说明文档整体仅9KB结构精简便于快速导入与二次开发。目前已有238人学习下载适合正在优化嵌入式日志体系、追求更清晰调试信息的开发者参考。借助这些优化可快速定位偶发异常减少重复排查成本尤其适用于固件迭代频繁、日志输出量大的实际项目。 J-Link几乎每个嵌入式工程师都上手过但大部分人只用它烧录、在线调试。真正让它发挥价值的其实是RTTReal Time Transfer这套实时通信机制。我在一个量产项目里把日志系统从串口整体迁到RTT并且基于官方源码做了一套针对嵌入式场景优化的日志组件今天把思路和源码细节完整拆一遍。这个方案能解决什么问题简单说就是让你在MCU跑着业务的同时用极低的CPU开销把调试日志、变量、内存数据实时拉到PC端而且不打断实时控制逻辑。适合用在了电机控制、传感器采集、协议栈这类对时序敏感的嵌入式项目上。不论你是刚接触RTT的新手还是已经被串口日志卡住性能的开发者这篇文章都有可落地的参考价值。1. 为什么嵌入式日志要换成RTT1.1 串口日志方案为什么不够用做嵌入式调试最早用的基本是串口打印。一条printf扔出去数据通过UART外设发到PC串口助手看起来挺顺。但把这个方案往高负载、高实时性的场景里一放问题就全冒出来了。串口日志最大的问题是阻塞。如果你的打印函数在发送前没有做中断缓冲一字节一字节等UART移位寄存器腾空那每次打印都会把CPU卡住。我曾经测过一块主频168MHz的MCU用115200波特率打印一行40字节的日志耗时接近3.5ms40 * 10 / 115200 ≈ 3.47ms。这个时间对大多数业务代码来说都太长了。如果日志量再大一点在控制周期只有1ms的电机FOC算法循环里printf几乎会让系统完全跑飞。更麻烦的是中断上下文不能调用。如果在ADC采样完成中断、定时器中断里想打印当前值串口方案基本不能用。因为printf往往不是可重入的底层还可能调用了信号量或者调度器接口在中断里调用轻则卡死重则直接进hardfault。虽然可以通过中断发送环形缓冲区的方案缓解但代码复杂度一下就上去了。串口还有资源争用问题。很多板子系统里UART外设本来就不宽裕蓝牙模块占一个、RS485占一个、GPS占一个留给日志的串口经常挤不出来。遇到这种情况你就得在高性能和调试便利性之间做取舍。1.2 RTT到底怎么工作为什么快RTT的思路和串口完全不同。它在目标RAM中开辟一块共享缓冲区MCU只要把日志数据写入这块内存J-Link调试器会通过SWD/JTAG调试接口定期读取这块内存并把数据送到PC端的RTT Viewer显示。这条链路有两个关键点值得注意。第一调试器读取目标内存时用的是调试接口的DAPDebug Access Port机制并不需要MCU参与也不会打断CPU的执行。第二MCU写入日志时只是执行一次内存写操作不像UART那样需要等待外设移位完成。所以RTT的延迟和CPU开销都远低于串口。我在Cortex-M4F平台上实测RTT输出在默认配置下单条短日志的开销也就是几十个周期的内存拷贝CPU占用相比串口打印降低超过90%。带宽方面如果SWD时钟拉到4MHz以上实际吞吐能到几百KB/s甚至更高完全不是115200波特率的串口能比的。这个特性让RTT不仅适合打普通日志还适合做高频数据采集和实时的变量观测。2. 上手默认RTT前需要知道的几个坑2.1 默认SEGGER_RTT_printf的开销在哪里SEGGER官方提供的RTT源码里最常用的接口是SEGGER_RTT_printf。很多人在移植完以后发现日志功能倒是能跑通但系统实时性还有明显损耗。原因在于官方printf系列函数并不是只做一次内存写那么简单它内部会做两件额外的事情。第一它会先把格式化结果写到一个局部缓冲里默认config版本是_SEGGER_RTT_PRINTF_BUFSIZE通常是64字节然后再把整个缓冲内容拷贝到RTT上行缓冲区。这个过程引入了两次内存操作还多用了64字节栈空间。对栈深度敏感的裸机环境或者中断里使用的场景这个开销非常可观。第二为了保证多任务场景下缓冲区的读写安全官方实现默认会进入临界区。如果是FreeRTOS环境它会调用taskENTER_CRITICAL也就是关中断。虽然这段临界区很短但如果你在定时器中断、串口中断里频繁打日志频繁的中断开关会直接影响中断响应延迟也会增大事件的抖动。其实官方源码里提供了简单的SEGGER_RTT_WriteString和SEGGER_RTT_Write这两个接口相对轻量但用起来很原始既没有日志级裁减也没有格式化功能。实际项目中直接裸用它们维护性很差。这就引出了我下面要说的优化方向。2.2 缓冲区配置与丢日志的现实官方RTT默认提供三个上行缓冲区SEGGER_RTT_BUFFER_SIZE_UP默认配置下第一个缓冲区大小是1KB另外两个是0。也就是不显式配置时你只有一块1KB的日志缓冲区可用。1KB看起来不小但在高频日志场景下很容易被填满。RTT缓冲区写满后的行为由SEGGER_RTT_MODE_NO_BLOCK_SKIP/SEGGER_RTT_MODE_NO_BLOCK_TRIM等模式决定。默认是丢弃新数据也就是说日志量大时数据会悄悄丢掉而且你在PC端根本意识不到丢了多少。这对排查偶发bug是非常致命的因为丢了的数据往往正是问题现场。我当时在做传感器数据采集以2kHz的速率每帧打印32字节的数据包算下来每秒产生64KB数据。默认1KB缓冲区瞬间就被打满了大量关键数据直接消失。后来我把缓冲加大到8KB才勉强够用但缓冲加大会直接占用RAM在RAM紧张的MCU上非常奢侈。更合理的思路是先从代码层面减少无效数据通过日志级别和缓冲结构来优化这也是我改造这套组件时优先考虑的事情。3. 优化版RTT日志组件的设计思路3.1 优化目标拆解在动源码之前我先确定了四条优化目标后面所有代码改动都围绕这四条展开。第一把日志的输出开销降到可控范围至少保证在常见MCU上单条日志输出时间不超过1微秒。这要求核心写函数不能有复杂运算不能进入大段临界区格式转换也必须在有需要时才执行。第二要支持多级日志和编译期裁剪。不同的运行阶段需要不同的日志级别调bug时需要全量debug输出跑发布版时只保留error级。裁剪必须在编译期完成不能等到运行时再判断否则会产生无谓的分支跳转和参数计算。第三要保证中断上下文可调用。中断里打日志是最常见的调试方式组件不能依赖任何OS服务也不能调用不可重入的标准库函数。第四要提供二进制输出能力。只看字符串日志观察数组变化、内存变化时效率很低我希望组件能直接输出hex dump形式的内存快照。3.2 数据结构与环形缓冲设计整个组件的核心是一个环形缓冲区。我定义了一个简洁的结构体方便后面做扩展。typedef struct { volatile unsigned int wr; volatile unsigned int rd; unsigned int size; char *buf; unsigned int drop_cnt; } ring_buf_t;wr是生产者写位置rd是消费者读位置。在RTT场景里生产者只有一个CPU消费者是J-Link通过调试口读内存也只有一个。所以这是一个经典的单生产者单消费者模型。在这种模型下只要保证缓冲大小是2的幂读写位置可以用无锁方式维护不需要互斥锁。缓冲区我用的是“后台缓冲前台缓冲”的双缓冲思路。后台缓冲先接收日志数据当前台缓冲被RTT Viewer读走并清空后后台数据再切到前台。这样做的好处是即使RTT Viewer那端暂时没来得及读取CPU也不至于被阻塞在等待缓冲清空上。注意我这里说的双缓冲并不是在编码上强制复制数据而是通过两块RAM区域交替映射来实现核心代码仍然是无锁的。4. 源码实现与关键细节4.1 环形缓冲区的无锁写实现我直接给出核心的写函数这是整个组件的性能命脉。#define RING_SIZE_SHIFT 12 // 4KB #define RING_SIZE (1 RING_SIZE_SHIFT) #define RING_MASK (RING_SIZE - 1) static char ring_buf[RING_SIZE]; static volatile unsigned int wr; static volatile unsigned int rd; static inline int ring_write(const char *data, unsigned int len) { unsigned int w, r, free_cnt; unsigned int i; __disable_irq(); w wr; r rd; __enable_irq(); if (w r) { free_cnt (r RING_SIZE - w) - 1; } else { free_cnt (r - w) - 1; } if (free_cnt len) { drop_cnt len; return -1; } for (i 0; i len; i) { ring_buf[(w i) RING_MASK] data[i]; } __disable_irq(); wr (w len) RING_MASK; __enable_irq(); return 0; }实现上的几个细节要展开说。取wr和rd时我都会短暂关中断这是为了防住中断里写日志时和主循环查询空闲空间发生的竞争。临界区只有两三条赋值语句实际影响几乎可以忽略。真正写入数据的那一段循环没有关中断这是因为只要wr没有被更新J-Link端拿到的读位置就还是旧值不会读走未写完的数据逻辑上是自洽的。缓冲区大小取4KB是2的12次方。用掩码代替取模运算很关键ARM Cortex-M系列上取模需要调用除法库函数一个周期几十拍而掩码操作只要一个周期。这个细节在高频日志场景下能省下不少CPU时间。4.2 日志分级与格式化输出日志级别我参考了Linux内核的习惯定义了四级。#define LOG_LEVEL_NONE 0 #define LOG_LEVEL_ERROR 1 #define LOG_LEVEL_WARN 2 #define LOG_LEVEL_INFO 3 #define LOG_LEVEL_DEBUG 4然后定义一个编译期的当前日志级别宏所有输出宏在调用底层函数前先做预处理裁剪。#define LOG_E(...) do { if (LOG_LEVEL LOG_LEVEL_ERROR) \ log_printf([E] __VA_ARGS__); } while (0) #define LOG_W(...) do { if (LOG_LEVEL LOG_LEVEL_WARN) \ log_printf([W] __VA_ARGS__); } while (0) #define LOG_I(...) do { if (LOG_LEVEL LOG_LEVEL_INFO) \ log_printf([I] __VA_ARGS__); } while (0) #define LOG_D(...) do { if (LOG_LEVEL LOG_LEVEL_DEBUG) \ log_printf([D] __VA_ARGS__); } while (0)这样当LOG_LEVEL被定义为LOG_LEVEL_INFO时LOG_D整条语句在编译阶段就会被优化掉参数不再压栈字符串也不占用任何存储空间。我在release版本里把级别设为LOG_LEVEL_ERROR即使日志宏还留在业务代码里最终bin几乎不会因为日志语句增加体积。格式化函数我没有直接用vsnprintf而是自己实现了一个轻量的整数格式化。原因很简单C标准库的vsnprintf动辄占用几KB的代码空间而且在嵌入式环境里还可能依赖堆。我只需要支持十进制整数、十六进制、字符串、无符号数和指针这几个基础格式自己写一个兼容的解析循环完全够用。static char *itoa_dec(char *p, unsigned int val) { char tmp[12]; char *t tmp sizeof(tmp); *--t 0; do { *--t 0 (val % 10); val / 10; } while (val); while (*t) *p *t; return p; }这个函数不依赖除法库就能正常跑对于小数值也可以走查表法加速。格式化后的字符串直接写入环形缓冲区没有中间缓冲拷贝IO开销比官方SEGGER_RTT_printf低了一个量级。4.3 hex dump与内存快照输出日志组件除了文本还能输出纯二进制数据。这个能力在调试协议栈、分析传感器原始数据时特别好用RTT Viewer会按字节流刷新显示。void log_hex_dump(const void *addr, unsigned int len) { const unsigned char *p (const unsigned char *)addr; char line[16 * 3 4]; while (len 16) { for (int i 0; i 16; i) { line[i * 3] 0 (p[i] 4); line[i * 3 1] 0 (p[i] 0x0F); line[i * 3 2] ; } line[16 * 3] \n; log_write(line, sizeof(line)); p 16; len - 16; } // 剩余字节按行输出 }批量打印内存时字符转换和输出都在循环里完成。你可以直接调用它查看一个数组、一个结构体或者一块堆内存的实时内容而传统串口方案要做到同样的事情得自己封装转换逻辑。5. 集成到项目与RTT Viewer配合使用5.1 Keil工程集成步骤这套组件移植起来很简单核心源码就两个文件rtt_log.c和rtt_log.h。从SEGGER官网下载J-Link软件包后里面带了SEGGER_RTT.c和SEGGER_RTT.h这两个文件也要一并加入工程。具体集成到Keil MDK时我的步骤通常是这样的把SEGGER_RTT.c、SEGGER_RTT.h、SEGGER_RTT_Conf.h和自研的rtt_log.c/h拷到工程目录直接参与编译。在SEGGER_RTT_Conf.h里把BUFFER_SIZE_UP调成合适的大小。注意这里跟项目主频和日志量有关我习惯先放到4KB跑起来看丢包计数再调整。初始化函数只在主函数入口调用一次主要是配置一下缓冲区状态和日志级别。初始化代码长这样void rtt_log_init(void) { SEGGER_RTT_Init(); drop_cnt 0; }其实SEGGER_RTT_Init官方建议在SEGGER_RTT_Conf.h里配置SEGGER_RTT_IN_RAM如果调试器在上电后立即启动初始化越早越好。GD32、STM32、NXP这些基于Cortex-M内核的MCU都可以直接复用这套逻辑不需要针对厂商SDK做额外适配。5.2 RTT Viewer连接配置与变量查看编译烧录完打开J-Link RTT Viewer第一件事是确认连接目标设备。如果驱动安装正常且J-Link型号被识别一般点击Connect就能自动完成。遇到连接失败时优先检查SWD接线尤其是SWDIO和SWCLK是否接反其次检查目标板供电。RTT Viewer默认显示的是Terminal 0上的数据。我把组件输出终端固定为0这样日志全部汇总在一个窗口方便按时间线排查。如果需要区分不同模块的日志可以利用RTT的Terminal切换功能比如SEGGER_RTT_SetTerminal(1)把网络协议栈的日志切到Terminal 1显示上会更清爽。RTT查看变量是很多人忽略的功能。你不需要打断MCU运行直接在RTT Viewer里把某个变量的地址作为目标地址添加Viewer会按一定周期刷新该内存区域实时显示变量变化。这个功能在做电机控制时特别有用可以直接看电流环的PID输出曲线。关键是在C代码里拿到变量的地址通常就是把变量声明成全局变量然后通过特定的内存窗口映射。5.3 与IAR和引脚电平的联动不少同事用的是IAR环境其实IAR下集成RTT和Keil基本一致都是把SEGGER的源码加进工程调用同样的初始化函数。如果你在IAR的调试器配置里选错成ST-Link连接RTT时会有设备不匹配的报错记得在Debugger设置里把调试器切换成J-Link。另外不同的MCU引脚定义里SWD用的引脚几乎都是PA13和PA14STM32系列GD32很多型号也复用同一组引脚。如果板子上PA13和PA14被复用成普通IO口J-Link连接时会断断续续甚至完全连不上。排查这个问题时可以先按住复位键再点击连接如果能连上基本就是这个原因。6. 常见问题与排查技巧实录6.1 日志丢失或乱码我见过最多的现象是日志打印一会儿就停了或者RTT Viewer里出现大量不连续数据。先说停。如果只是日志输出量大于RTT Viewer读取速度就把缓冲调大或者降低日志频率。但如果是日志完全不再输出那多半是RTT缓冲写满了而RTT Viewer又没能把数据读走。这时候你需要在代码里周期性读取drop_cnt变量把它打印到屏幕上一旦发现它持续增长就知道是缓冲区压力太大。乱码的情况往往是J-Link和目标MCU的SWD速率不匹配高速率下信号质量不过关。J-Link的SWD时钟可以在RTT Viewer设置里调慢比如从4MHz降到1MHz问题往往就能解决。还有一种可能是目标板RAM时钟不稳定比如某些MCU在超频到极限又正好开RTT时调试访问端时序会出问题降频就好了。6.2 中断里写日志遇到锁死中断里打日志应该是这个组件用起来最舒服的场景但如果你没有遵守一个原则还是可能出现问题不要在中断里打印太长的数据。中断处理强调短小精悍如果一下输出几百字节CPU会一直忙着填充缓冲导致中断处理时间被拉长主循环的业务节奏就会被破坏。我建议中断里只打关键状态和数值详细数据用log_hex_dump在后台任务里处理。另外关中断的写法要小心。我在ring_write前段读取rd时用了__disable_irq()如果你在调用日志前已经手动关了中断那这里会导致中断恢复提前可能引发嵌套临界区的逻辑混乱。建议封装一层统一的临界区接口或者保证调用点在进入临界区之前。6.3 线上调试的实用建议日志系统上线之后有一种窘境是现场出了bug但机器已经封箱不方便接调试器排查。我一般会在固件里默认把RTT日志级别设成WARN以上同时周期性向RTT缓冲区写入运行状态摘要。到了问题现场插上J-Link连上RTT Viewer10秒内就能把系统的运行历史拉出来看。这个经验让我在无数个远程定位问题中省了大量往返时间。还有一个技巧是用RTT的ID号功能来打标记。J-Link RTT Viewer允许你在缓冲区里嵌入特定ID配合脚本过滤可以快速从大段日志中筛出自己关心的关键路径。比如在进入某个状态机状态时输出[S1]标记在状态切换时输出[TRANS]标记脚本一过滤状态机的跳转流程就非常清晰了。最后分享一个小技巧在量产固件里建议把日志组件的缓冲区保持在固定地址不要让它随链接脚本浮动。因为RTT Viewer有时会根据连接时读到的控制块地址来确定缓冲区位置如果地址每次都变脚本化的排查工具就容易失灵。用__attribute__((section(.rtt_data)))之类的方式固定section能避免不少麻烦。本文还有配套的精品资源点击获取
