这两天在调试一个音频ADC 芯片，也是之前的项目，但是一直调不出来，我发现我总是在这样的问题上纠结很久，以前踩过的坑后面照样会踩，只不过踩完会迅速把脚拉出来继续前进，我经常听到有人说「做嵌入式真的太容易了，来来去去就那点东西」。

不是小瞧，做嵌入式真的就来来去去那点东西，我们前几天调试一个屏幕，刚开始也是怎么点也点不亮，屏幕的分辨率是1920*1200，但是我们把这个分辨率软件设置好烧录开机后，内核崩溃了。

调试驱动不像写应用程序，如果应用程序崩溃了，系统还是活的，系统活着，就可以继续搞事情，继续看系统抛出来的信息调试。驱动不一样，驱动是内核的一部分，而且是内核的很大一部分，如果驱动异常了，很大可能性会影响到内核。

提个题外话「为什么内核下面那么多用不着的驱动代码不直接删除掉？」

再提个问题「为什么明明可以在内核里面找到答案，大家还是习惯百度？google?」

应用是人身体上的衣服，是帽子，是鞋子，但是驱动不一样，它是人身上的手，是脚，是鼻子，是耳朵。

——转回来

针对上面的问题，我们就查呀查，最后发现MTK 的代码里面有问题。

—— 这个问题出现的情况是

如果我们软件设置1920*1080的分辨率的话，内核是不会崩溃的，但是我们写入1920*1200的分辨率的话，内核就崩溃了。

我们想「是不是因为增大了分辨率，但是默认的buff 空间没有那么大，这样使用的虚拟内存就越界了，然后就崩溃了？」

然后我们就找这部分的信息，你们知道，内核代码是一些非常困难的代码，阅读代码的时候，有时候要猜测它的行为，阅读一份完全陌生的代码，而且你还不知道它的行为意图，这是很困难的。

— — 然后怎么办？

然后我们就正向分析了，找到崩溃的位置，然后注释它，对，你看的没有错，我们注释了看不懂的那段代码，就是这个操作让我们的系统正常开机，而且能够正常显示画面。

然后复盘的时候，我们咨询了MTK 的技术开发，他们给出的解释是「出问题的这段代码只是为了在eng 版本调试」，这还没有完，我们虽然知道这样修改可以，但是还是看不懂它的这个函数有什么调试的意义所在。

韦老师好像有一个名言，说20%的时候在写代码，80%的时间在调试代码。调试要花费的功夫确实比写代码多，搞嵌入式，因为涉及硬件，如果有一个东西被卡住了，那时候的感觉，那个焦急的心都快孳出来了，所以搞技术，没有一个好的心态是不行的，毕竟它不是砍树，也不是真的搬水泥或者搬砖。

推荐阅读：

专辑|Linux文章汇总

专辑|程序人生

专辑|C语言

我的知识小密圈