3. 动态日志控制：从编译到运行时的全方位掌控
日志系统这东西，说白了就是嵌入式开发者的「黑匣子」。但很多朋友一开始就把日志写死了——编译时决定一切，运行时想改？没门。我早年也踩过这个坑，产品量产了才发现某个模块日志太多，把系统拖慢了，改代码重新编译烧录？那叫一个痛苦。
今天我们就聊聊 NuttX 里怎么把日志控制玩活。从编译时的静态配置，到运行时的动态调整，再到模块级别的精细管控。嗯，这套组合拳打下来，你的调试效率至少翻一倍。
3.1 编译时配置：CONFIG_SYSLOG 的玄机
先说说最基础的。NuttX 的日志系统，根儿上是由 CONFIG_SYSLOG 这个宏决定的。它决定了日志往哪儿写——是串口、RAM、还是文件系统。
我个人习惯，开发阶段用 CONFIG_SYSLOG_CHAR，直接怼到串口上，实时看。但量产阶段，我会切到 CONFIG_SYSLOG_RAMLOG，把日志存到 RAM 里，出问题了再读出来。
核心配置项一览：
| 配置宏 | 作用 | 我常用的场景 |
|---|---|---|
| CONFIG_SYSLOG | 启用 syslog 子系统 | 必开，除非你不需要日志 |
| CONFIG_SYSLOG_CHAR | 日志输出到字符设备（如串口） | 开发调试，实时看 |
| CONFIG_SYSLOG_RAMLOG | 日志输出到 RAM 缓冲区 | 量产阶段，事后分析 |
| CONFIG_SYSLOG_FILE | 日志输出到文件系统 | 需要持久化日志时 |
| CONFIG_SYSLOG_PRIORITY | 编译时日志优先级过滤 | 默认设成 LOG_INFO，够用 |
这里有个坑，我得提醒你：CONFIG_SYSLOG_PRIORITY 是编译时硬编码的。你设成 LOG_WARNING，那所有 LOG_INFO 级别的日志在编译阶段就被砍掉了，运行时再怎么调也出不来。说白了，编译时配置是「能不能有」的问题，运行时配置是「要不要显示」的问题。
CONFIG_SYSLOG_PRIORITY 设成了 LOG_ERR。结果现场出了问题，我想看 LOG_WARNING 级别的日志，发现根本不存在——编译时就没了。后来我学乖了，编译时至少留到 LOG_INFO，运行时再根据情况过滤。
3.2 运行时日志级别调整：syslog_set_priority
好，编译时配置搞定了，接下来是运行时动态调整。NuttX 提供了 syslog_set_priority() 这个 API，让你在系统跑起来之后，随时改变日志的输出级别。
你想想看，产品在现场跑着，突然出了个诡异的问题。你不想重新编译烧录吧？这时候，远程发个命令，把日志级别从 LOG_ERR 调到 LOG_DEBUG，所有细节就都出来了。多爽。
#include <syslog.h>
/* 设置日志级别为 DEBUG，所有日志都输出 */
syslog_set_priority(LOG_DEBUG);
/* 设置日志级别为 ERR，只输出错误 */
syslog_set_priority(LOG_ERR);
/* 获取当前日志级别 */
int current_prio = syslog_get_priority();
这里有个细节：syslog_set_priority() 设置的是全局优先级。也就是说，你调了之后，所有模块的日志输出都会受影响。那如果我只想关掉某个模块的日志呢？别急，下一节就讲。
log_level set debug 这样的命令。底层调用的就是 syslog_set_priority()。这样现场工程师通过串口或者网络就能动态调整，不用动代码。
3.3 模块化日志：syslog_enable/disable 的精细管控
全局调整虽然方便，但有时候太粗了。比如你的系统里有网络模块、传感器模块、显示模块。你只想看网络模块的日志，其他模块的日志太吵了。怎么办？
NuttX 提供了模块化日志控制：syslog_enable() 和 syslog_disable()。你可以针对某个模块，单独开关日志输出。
#include <syslog.h>
/* 只启用网络模块的日志 */
syslog_enable(LOG_NET);
/* 关闭传感器模块的日志 */
syslog_disable(LOG_SENSOR);
/* 检查某个模块是否启用了日志 */
bool is_enabled = syslog_isenabled(LOG_NET);
这些模块 ID 是在 syslog.h 里预定义的，比如 LOG_NET、LOG_FS、LOG_MM 等等。你可以在自己的代码里也注册自定义模块 ID。
我记得有一次，一个同事抱怨系统日志太多，根本找不到关键信息。我让他用 syslog_disable() 把不关心的模块全关了，只留他调试的那个模块。他当时就说：「原来世界可以这么清净。」
模块化日志的核心逻辑：
每个日志消息都带有一个模块 ID 和一个优先级。输出时，系统会检查两关：
- 模块开关：这个模块的日志是否被
syslog_enable/disable启用？ - 优先级过滤：这条消息的优先级是否高于
syslog_get_priority()设定的阈值？
两关都过了，日志才会输出。否则直接丢弃。
你想想看，这种两级过滤机制，是不是很灵活？编译时决定「能不能有」，运行时决定「要不要显示」，模块级决定「哪个模块显示」。三层控制，层层递进。
3.4 知识体系总览
说了这么多，我画了一张图，帮你把整个动态日志控制的知识体系串起来。这样你脑子里就有个清晰的框架了。
这张图把三层控制逻辑画得很清楚了。从上到下，一层比一层精细。编译时是「总闸」，运行时全局优先级是「分闸」，模块级开关是「每个房间的灯开关」。你想想看，这样的设计是不是很优雅？
3.5 实战建议
最后，给你几个我实战中总结的建议：
- 开发阶段：编译时
CONFIG_SYSLOG_PRIORITY设成LOG_DEBUG，运行时用syslog_set_priority()动态调整。这样你随时可以看最详细的日志。 - 量产阶段：编译时
CONFIG_SYSLOG_PRIORITY至少留到LOG_INFO，运行时默认设成LOG_WARNING。出问题时再动态调低。 - 模块化控制：把频繁调试的模块（比如网络、传感器）单独用
syslog_enable/disable控制。这样你可以在不重启系统的情况下，只关注你关心的部分。 - 远程调试：留一个调试接口，通过命令行或网络远程调用
syslog_set_priority()和syslog_enable/disable。现场问题，远程解决。
嗯，动态日志控制这块，说白了就是让你在「信息太多」和「信息太少」之间找到一个平衡点。编译时打好基础，运行时灵活调整，模块级精细管控。这套组合拳打好了，调试效率绝对上一个台阶。
公众号:蓝海资料掘金营，微信deep3321