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