记一次解决问题的掉坑过程
共 1160字，需浏览 3分钟
·
2020-12-12 05:22
这两天在调试一个音频ADC 芯片，也是之前的项目，但是一直调不出来，我发现我总是在这样的问题上纠结很久，以前踩过的坑后面照样会踩，只不过踩完会迅速把脚拉出来继续前进，我经常听到有人说「做嵌入式真的太容易了，来来去去就那点东西」。
不是小瞧，做嵌入式真的就来来去去那点东西，我们前几天调试一个屏幕，刚开始也是怎么点也点不亮，屏幕的分辨率是1920*1200，但是我们把这个分辨率软件设置好烧录开机后，内核崩溃了。
调试驱动不像写应用程序，如果应用程序崩溃了，系统还是活的，系统活着，就可以继续搞事情，继续看系统抛出来的信息调试。驱动不一样，驱动是内核的一部分，而且是内核的很大一部分，如果驱动异常了，很大可能性会影响到内核。
提个题外话「为什么内核下面那么多用不着的驱动代码不直接删除掉？」
再提个问题「为什么明明可以在内核里面找到答案，大家还是习惯百度？google?」
应用是人身体上的衣服，是帽子，是鞋子，但是驱动不一样，它是人身上的手，是脚，是鼻子，是耳朵。
——转回来
针对上面的问题，我们就查呀查，最后发现MTK 的代码里面有问题。
—— 这个问题出现的情况是
如果我们软件设置1920*1080的分辨率的话，内核是不会崩溃的，但是我们写入1920*1200的分辨率的话，内核就崩溃了。
我们想「是不是因为增大了分辨率，但是默认的buff 空间没有那么大，这样使用的虚拟内存就越界了，然后就崩溃了？」
然后我们就找这部分的信息，你们知道，内核代码是一些非常困难的代码，阅读代码的时候，有时候要猜测它的行为，阅读一份完全陌生的代码，而且你还不知道它的行为意图，这是很困难的。
— — 然后怎么办？
然后我们就正向分析了，找到崩溃的位置，然后注释它，对，你看的没有错，我们注释了看不懂的那段代码，就是这个操作让我们的系统正常开机，而且能够正常显示画面。
然后复盘的时候，我们咨询了MTK 的技术开发，他们给出的解释是「出问题的这段代码只是为了在eng 版本调试」，这还没有完，我们虽然知道这样修改可以，但是还是看不懂它的这个函数有什么调试的意义所在。
韦老师好像有一个名言，说20%的时候在写代码，80%的时间在调试代码。调试要花费的功夫确实比写代码多，搞嵌入式，因为涉及硬件，如果有一个东西被卡住了，那时候的感觉，那个焦急的心都快孳出来了，所以搞技术，没有一个好的心态是不行的，毕竟它不是砍树，也不是真的搬水泥或者搬砖。
