写Linux driver-血的教训

linux操作系统下编写driver并不是一件非常困难的时情。但是粗心+恋战，绝对是写driver时候制造痛苦的绝代双骄。2005年的十一长假，我计划完成两件事：1.在i386+linux的系统上完成自制红外收发板的接收驱动部分（该平台下的发送驱动已经完成），2.把软件移植到s3c2410+arm linux平台上去。因为软件的体系结构早就已经设计好，并且发送驱动也已经调试成功，所以满怀信心。

然而，在花了头两天写完接收部分驱动之后，后来的四天时间都一直纠缠在一个问题上：为什么不进中断！在原来代码的基础上添加了无数的printk查看接口寄存器的值，得到的总是不可能的结论。当然，在长时间埋头工作的情况下，思路也有点混乱，加之天性粗心，这个时候就更加凸现出来。整个人都要疯掉了。。。其间不时有重头再来的念头，但始终不甘心，不愿意放弃这个找错的机会。但事实证明，我被自己打败了。 休息了一天之后，在万念俱灰的心理状态下，抛开一切，重新设计重写代码，结果异常顺利，开始写了一个简单的串口驱动，中断读，编完的代码第一次运行就搞定，然后重新设置寄存器用DCD引脚驱动中断，除了第一次在中断中死循环以外，第二次顺利通过，至此，技术上的问题迎刃而解，剩下的就是coding的体力活了。突然发现漆黑的（因为日光灯会发出干扰红外线）实验室是多么的明亮！！！

这个没有戏剧性的痛苦经历让我想起了以前软件工程课里面提到的原则：重头再来，而不是纠缠在原来的代码上。想必写这句话的人，也一定经历了和我一样的痛苦。关于这样的经验，具体一点就是：如果调试程序超过编写代码本来的时间，就一定要把这些代码扔掉，重新编写！另一个教训就是：不要为了省事，将那些本应该单独试验的模块第一次就放到完整的软件中去试验，这样做大都会在调试的时候引入更高维度的复杂性，导致工作开销加大。