归档

版本: V1.0 数据流：信号从哪来，经过哪些中断、任务、缓冲区，输出到什么硬件、存了什么，时序和掉电是否安全 用户体验: 实时、可靠、低功耗、可诊断、可维护、断电可恢复 抽象概念：硬件隔离是否正确，并发模型是否匹配，状态机是否清晰，组件是否可替换且开销可接受 概念展开 数据如何在系统中流动 数据大

目前我负责一款物联网的设备的开发与维护，在联网层面上有一个错误的弹窗提醒； 当客户把拍摄照片发给我，让我来判断错误原因的时候，我突然意识到一个问题，那就是一位工程师如果面对一个黑盒产品，我曾经自豪于我构建的日志模块，每当问题发生的时候，我总是会快速的定位问题，甚至于依赖这套框架解决了不少棘手的偶发性

干憔悴了, 由于硬件改版, 主要也就是添加了 XIP 功能, 增加USB模块, 由于M7的内核, 涉及到eDMA和cache缓存, 光RAM分区都有ITCM,　DTCM , OCRAM, 现在的情况是某个eDMA通道做搬运的时候总是挂掉, 然后再一路踩死其他通道, TCD直接被踩烂了, 写了个eDM

本文通过乐器MIDI控制端重构的实战经历，揭示了适配器模式并非书本上的教条，而是在“零算力损耗”预计算、快照防撕裂、引擎纯净化等实际痛点中自然涌现的解决方案——当理论落地于高频实时系统的性能与安全约束时，设计模式便从抽象概念转化为工程直觉，印证了经典模式唯有扎根实践，才能真正焕发其价值。

配合的硬件工程师不顶用，实在是太tm坑软件了呀，真遭不住了，天天给底层填坑，玛德真痛苦，还不是我专业领域，他娘的，把问题甩出去 2026-8-17更新 问题找到了，模拟电路输入端的一个分支由于线过长，导致引入了额外的寄生电容，进而影响了输出端的电压。改版前没有把问题考虑和排查清楚，打板后对电压也没有

对于等待某个标志判断的情景，必须带超时检验，不要因为这段死等的代码导致CPU指针卡死在这里，从而导致整个系统崩溃 断言！断言！断言！对函数的入参进行校验非常重要，对开发阶段非常具有帮助，尤其是在C语言的环境下，你往往不知道同伴做了哪些令人窒息的操作，当参数传到你负责的模块里的时候，可能内容值根本不是

待更新。。。

待更新。。。