1. 调试日志基础：日志级别、格式规范与输出机制
调试日志，说白了就是嵌入式系统的「黑匣子」。系统跑飞了、死机了、数据错了，你第一个想到的肯定是——日志里有没有留下什么线索？我做了十几年嵌入式，见过太多同事在 Bug 面前抓耳挠腮，最后发现只是日志没打对地方，或者级别设错了。
这一章，咱们就把日志的基础打牢。别小看这些基础，它们决定了你后续所有调试工作的效率。
1.1 日志级别定义——不是所有信息都值得打印
日志级别，就是给每条日志贴个「重要性标签」。为什么要分级？你想想看，如果所有信息都往串口里吐，调试时你根本找不到重点。我在项目中遇到过，有人把调试信息全设成 INFO 级别，结果系统崩溃时，关键错误被淹没在几千行无关日志里。
业界通用的日志级别，我建议你直接采用这套标准：
| 级别 | 数值 | 含义 | 典型场景 |
|---|---|---|---|
| FATAL | 0 | 致命错误，系统无法继续运行 | 内存访问越界、看门狗复位前 |
| ERROR | 1 | 错误，但系统可尝试恢复 | 通信超时、传感器读取失败 |
| WARN | 2 | 警告，可能存在问题 | 缓冲区使用率超过80%、任务调度延迟 |
| INFO | 3 | 重要运行信息 | 系统启动、模块初始化完成 |
| DEBUG | 4 | 调试信息，开发阶段使用 | 变量值变化、函数调用流程 |
| TRACE | 5 | 最详细跟踪，通常只在局部使用 | 循环内每次迭代的状态 |
FATAL、ERROR、WARN 和少量 INFO。DEBUG 和 TRACE 在编译时用宏开关直接裁掉，避免影响性能。
1.2 日志格式规范——让机器能解析，让人能看懂
日志格式，是团队协作的「通用语言」。没有统一格式，每个人按自己喜好打日志，那日志分析工具就没法用了。我曾经接手过一个项目，有人用 printf("err=%d\n", err)，有人用 printk("Error code: %d\n", err)，还有人用 UART_SendStr("ERROR: ")……那叫一个乱。
我推荐的标准格式如下：
[时间戳] [级别] [模块/任务名] [文件名:行号] 消息内容举个例子：
[2025-03-15 14:23:45.123] [ERROR] [CAN_DRV] [can.c:256] 接收超时，重试次数: 3每个字段的作用：
- 时间戳：精确到毫秒或微秒，用于时序分析。我习惯用
YYYY-MM-DD HH:MM:SS.mmm格式。 - 级别：一目了然知道严重程度。
- 模块/任务名：快速定位问题出在哪个子系统。
- 文件名:行号：用
__FILE__和__LINE__宏自动生成，省去手动维护的麻烦。 - 消息内容：简洁、结构化，关键变量用
key=value形式。
14:23:45.123 不带日期。结果日志跨天了，分析时根本分不清哪条是哪天的。日期一定要带上！
1.3 日志输出机制——选对路，别堵车
日志输出机制，就是日志从产生到落地的「管道」。嵌入式系统资源有限，选错输出方式，轻则影响性能，重则导致系统崩溃。
常见的输出机制有这几种：
| 输出方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 串口(UART) | 简单、实时、调试方便 | 速度慢、占用CPU、线缆束缚 | 开发阶段、单板调试 |
| 环形缓冲区(Ring Buffer) | 速度快、不阻塞、可事后导出 | 可能丢日志、需要额外存储 | 性能敏感、实时性要求高的系统 |
| 文件系统(Flash/SD卡) | 持久化、容量大、可离线分析 | 写入慢、磨损Flash、需要文件系统支持 | 数据记录、现场日志保存 |
| 网络(UDP/TCP) | 远程查看、集中管理 | 依赖网络、可能丢包 | 分布式系统、远程调试 |
| SEGGER RTT | 极快、不占用额外引脚 | 需要J-Link调试器 | ARM Cortex-M系列MCU |
我个人最常用的组合是：开发阶段用串口+RTT，发布版本用环形缓冲区。环形缓冲区的好处是，日志写入是 O(1) 的，不会阻塞主任务。等系统空闲时，再通过后台任务把缓冲区里的日志刷到 Flash 或通过网络发送出去。
1.4 知识体系总览
下面这张图，把本章的核心逻辑串起来了。你可以把它当作调试日志的「设计蓝图」：
1.5 实战建议：从零搭建日志模块
说了这么多理论，咱们来点实际的。我建议你从今天开始，在自己的项目里搭建一个轻量级日志模块。不用复杂，先做到这三点：
- 定义日志级别宏：用
#define定义LOG_LEVEL_ERROR、LOG_LEVEL_INFO等，并设置一个全局日志级别变量。 - 封装日志输出函数：比如
log_error(fmt, ...)、log_info(fmt, ...)，内部统一格式化时间戳和模块名。 - 选择输出后端：先用串口，等系统稳定了再切换到环形缓冲区。
嗯，这里要注意：日志模块本身也要考虑性能。我见过有人把 sprintf 用在日志函数里，结果一个日志打印耗时几毫秒，直接把中断响应给拖垮了。能用 snprintf 就别用 sprintf，能用整数就别用浮点数。
if (current_level <= LOG_LEVEL) 的判断，这样即使日志调用还在，但级别不满足时，函数几乎不消耗 CPU。这叫「编译期裁剪」的运行时版本。
好了，这一章的内容就到这里。日志基础打好了，后面咱们才能谈怎么用日志定位 Bug、分析性能。记住：好的日志系统，是调试效率的倍增器。