朱天龙 (Armink)
朱天龙 (Armink)
Hi bro. Unfortunately, I haven't actually used PIO before. I think you could troubleshoot this by checking the build system. For example, print out the compilation parameters for main.c to...
是的，确实有必要的，你方便增加一下嘛？
系统异常时，是不是不使用 ulog 打印更好呢？毕竟系统都跑飞了，一些系统状态可能都是不对的，直接用 ulog 导致的连锁反应挺多的，可靠性严重不足。之前的 CMB 日志前端直接用 ulog ，现在看有些草率。 两个小建议： - 如果只是想拿到 ulog 异步缓冲区的未日志，那可以直接造个高可靠的迭代接口给到异常环境去取； - 异常时，如果想存储更多系统信息 - 日志后端一定要选择可靠的，最好都不要用文件系统，直接存储到程序状态依赖少的裸介质（裸 emmc 分区、PSRAM 分区、norflash 分区等），下次开机后再进行文件转存 - 日志前端可以参考 rtdbg.h 造一个精简的给 emergency 专用的接口，和常规 ulog 分开，避免大家混用
> 这个的意思是像如下所示这样,提供一个新的日志打印接口? 是的，总体感觉是要让开发者在使用时，通过 API 接口语义，显性的知道当前哪些接口可以用于系统正常状态或者系统异常状态。 这样，在 ulog 里面不需要考虑一些系统异常的处理，简化 ulog 实现。毕竟 ulog 在设计之初就是考虑了 **超轻量级** 的这个理念。
回归到问题本身： - 1、遇到了什么问题 - 2、希望得到闭环标准是什么样子 如果问题本身是因为 无法存储 异常日志 - 根据我的经验，异常环境下执行存储逻辑越复杂，出现问题就越多，反而导致更多的问题 - 所以从系统可靠性角度出发，要选择更加简单的方式来实现异常日志存储，比如：存储到内存、Flash等逻辑简单的设备，开机再转存。 - 如果要做抽象，存储和转存代码核心的逻辑可以抽象为软件包，还要简化存储接口最好让 HAL 自行实现，甚至脱离 RTOS 才是最安全的
请问这部分优化有做一些对比测试吗？方不方便给出一个优化前后的具体数据呢？
看着 感觉提升不太大呢