调试小记3

在实验新东西时往往遇到这样的情况，你一点点地增加功能，添加代码。但在添加某一个新东西时，突然发现原来已经稳定的内容又不行了，真是不进反退。这时往往不是新的东西有问题，而是新的东西和已有内容混合造成的影响。甚至可以理解为已有内容中存在的bug，只是没有表现出来，新的东西一混合进来，一切都乱套了。这种bug不好调试，因为你退回去，系统又正常了，进一步，系统就紊乱了。你只能把这一步拆成许多小步，或者从各个角度去猜测测试修改，以期找到答案。

在大多数情况下，我们是抱着严谨认真的态度来调试问题的，调试的目的不仅是清除故障，而且是要找出错误原因，分析为什么会出现这样的错误。但立场不是绝对的。当问题过于复杂，自身知识不足，时间过于紧迫的时候，调试的要求就会逐渐降低，可以是修复故障的代码，或者使问题不在出现，或者对问题进行容错。要知道，对于程序和系统而言，正确的道路只有一条，错误的道路有无数条，我们的根本要求是让系统走向正确的道路，而不是抓住某条错误的道路死死不放。如果发现错误的情况千奇百怪，无法理解，这很正常，仅仅是一个堆栈溢出或者时序错误或者配置参数失误，都可能造成严重的影响。只不过，如果错误情况过于混乱，我们就很难抓住头绪，不知该去修改哪里是好。

在很多书中，曾经谈到直觉的存在。虽然我认为这部分原因是为了安慰老同志，但也确实可以依靠直觉对系统进行排查。直觉的话，用通俗的说法，就是程序员觉得代码哪里不爽，不够完美，还可以做地更健壮一些，就去修改哪里好了。或者是编译器觉得哪个地方不太符合标准，即使不太明白它在说什么，有想法的话也可以进行修改。当然，我觉得这里的修改，不是在功能上的增加，而是在安全性，检测手段，稳定性，容错性，冗余性上的提升。这么做也可以理解为希望是瞎猫碰上死耗子。

不过，也不是完全相信直觉。因为如果你直觉的认为某个地方可能有问题，你或许一开始就不会给它发生问题的机会，所以很可能哪怕之后再像过筛子一样反复检查那个地方，也很可能一无所获。真正的问题往往是我们忽视的地方，认为绝对正确的地方，或者不怎么懂的地方。事实上，我几乎从来没有在一开始就猜对过问题的所在。即使对某个地方有绝对的信心，如果有替换的方案，不妨尝试一下，或许替换后问题就没有了或者改变了。我在做一个单片机读取fpga内容的实验时，开始在放内容到数据线上使用的是组合逻辑，我觉得这样才够快，但编译器对此有不满（我不清楚它的不满是什么），然后在读写fpga时有很奇怪的问题（奇怪的问题就是在正常情况下是正常的，只在特殊情况下出现异常）。虽然我找不到问题所在，但将放内容到数据线上的方式改为时序电路，问题就基本消失了。

在嵌入式系统中，有人说过一个原则：越简单越有效，越复杂越稳定。虽然还不太理解，但觉得很有道理。可能是说，解决问题的手段要简单而有效，但在实现系统时要复杂稳定。系统终归要达到两者的某种平衡。

 

在嵌入式方向的时间越长，越发现自己的浅薄，很多东西都是瞎凑上去的，真要长时间稳定正确运行，还有很多欠缺。希望今后能更加谦虚谨慎，艰苦奋斗！