在给客户的定制的一个系统上跑应用程序的时候，那几个摁键总是不怎么灵，干扰很严重。由于用户的应用程序已经完成了，所以只有在驱动中更改。
其实按照我的理解，驱动只是提供一个功能接口，尽可能的实现最基本的功能给上层尽可能多的发挥空间。如果一些控制代码放到驱动中，这样就把上层的一些操作给固化了，上层的发挥的空间就小了很多。
现在是没有办法，只能在驱动中更改。本文的平台是wince4.2+s3c2440，4个摁键的接口分别是SPICLK0（L9），SPIMOSI0（P9），SPIMISO1（K10），SPIMISO0（K9）。在这地方差点被忽悠了，看着这些东西好象是要做spi的驱动，其实在2440的spec中搜一下发现这些口分别对应了GPE13，GPE12，GPG5，GPE11。
这样就好办了，随便写个流驱动对这几个口进行设置。在应用程序readfile的时候，驱动程序就分别查看这几个口的状态寄存器值，如果是1则对应的摁键被摁下，如果为0则相反。在这个地方就出现问题了，由于应用程序开了一个线程一直在readfile（个人猜测），摁键被摁下则做相应处理。由于在按键时有一定的抖动产生干扰，导致按一次键应用程序可能会读到好几个按下的状态。
在这里，消除干扰无非就是用时间来换取。可以多次检测取值比对，这个办法也不是很稳定，因为无法确定该取多少次值。我的办法很土，不过比较有效。在驱动中如果一个寄存器的值为1（即键被按下），则等待300ms并将这个状态返回给应用程序。之所以这么做是因为在不按键时是不会产生干扰的，假如按键了不管有没有干扰总会产生一个1状态，而驱动程序总能捕获到这样一个状态，不管你后面有没有干扰先等着再说。这样应用程序就不知道有干扰的存在（驱动还没有返回值给它，这里所谓的干扰就是0和1之间的不确定跳动），这也必然会影响应用程序的响应速度。根据我们测试的能接受的时间，在驱动中设置100-300ms比较合适。
在这种地方真不应该用轮循的方法，要是中断的话就没有这么多麻烦了。至少在处理一个中断的时候可以将这个中断给屏蔽掉。