WINCE下调试i2c矩阵键盘驱动

由于公司接到了一个wince的项目，上周调试了wince下i2c矩阵键盘驱动，i2c驱动代码同事已经基本都从linux中移植完成，没有调试，我需要做的主要有下面几个问题：



1 调试i2c驱动

2 确定i2c矩阵键盘的读写时序 实现获取键值

3 解决gpio中断线一直拉低的问题

4 修改微软键值功能键映射表



公司处理器中断控制器上已经没有了i2c中断线，所以挂在i2c上的设备只能是利用gpio中断通知处理器，再由i2c总线来传输数据。



用示波器测量了一下gpio引脚，一直是低，这样也就排除了中断系统的问题，而是因为gpio引脚被拉低的原因，因为wince下我们设置的是下降沿触发中断。所以一直拉低不会触发中断。起初我怀疑是硬件的问题，所以让硬件工程师去查一下硬件，没有调中断，而是在pmon（公司使用的bios）下利用命令来调试i2c读写键盘的时序。

上面的事情我有一个体会，就是调试很关键的一点就是思维要清晰，把要调试的问题分成几段，挨段来，确定是哪一段问题，这样可以缩小范围。

再有一个就是之前同事跟我说过一句话，调试驱动最好能够站在硬件的角度去看问题。这句话我觉得很不错，特别是总线设备，首先要明白他们的传输协议，再看代码有很多原来不知道为什么这么写的地方就会豁然开朗。

做任何一点小事都要有心得，我觉得这样提升才是最快的。

利用pmon下的i2cs和d1 m1命令来向i2c设备传输数据，起初不太明白原理，后来看了一下d1和m1 i2cs的原理，才发现这个m1和d1的实现好巧妙。i2cs做的事情只是给出设备地址，然后将内部的syscall1和syscall2 2个函数指针赋值，d1和m1做的事情就是调用这2个函数，默认情况下这2个函数指针是被赋了一个操作内存地址的函数。所以默认d1和m1是对内存地址进行读写。这样就都明白了，并且d1和m1的第一个参数如果执行了i2cs命令就是传的i2c设备寄存器的地址。

这里有一点心得，就是对于外围设备，特别是总线设备，datasheet一定要仔细读，传输时序就在这上面。但是我们写驱动是站在处理器的角度上操纵i2c控制器。而datasheet是直接操作向i2c总线传输数据的时序，这中间是有点差别的。



通过pmon下的命令我确定了通过i2c读写矩阵键盘键值的时序。i2c基本都是slave+寄存器地址+数据的形式传输数据，矩阵键盘读取键值需要确定行列。

pmon下确定后我就开始在wince下编写i2c最底层的传输函数，这个是最核心的函数，然后封装一个函数，实现对矩阵键盘键值的读写。



在这中间有一个插曲，就是找到了gpio一直拉低的原因，起初我一直以为是硬件的问题，但是硬件工程师查了一遍，发现硬件没有问题。仔细一想，gpio是直接接在了设备控制器的int引脚上，gpio一直拉低，极有可能是int引脚由于某种原因一直拉低。于是就开始仔细查看datasheet，发现其中的一段话含义是向设备控制器发送0x00命令，int会变为无效，就是高电平。于是我就在pmon下试了一下，果然如此，原来是硬件的原因，至于为什么上电后会拉低，这个问题一直没有找到原因。于是我在pmon中kbd的初始化中通过i2c向设备发送0x00中断就正常了。



这样的话其实上面所列的4个问题中就有2个已经基本上解决了，就开始起内核调试。这中间真是大费周折，遇到了一个问题，通过示波器和打印信息，发现向设备发送寄存器地址的时候一直收不到ack信号。折腾了2天，但是pmon下却一直好用，这个问题，最后还是利用示波器解决的，是自己犯的一个很二的错误，本来以为是i2c时序不对或者中间间隔时间，但是在pmon下一直好用，应该不出现这个问题，于是利用示波器波型一对比才发现，自己在内核中写的寄存器地址错了！！把寄存器3写成了0x11，现在想想这个问题是在是太可笑了，但是当时怎么查也查不出来，就是钻了牛角尖了。

这里有一点心得就是在调试的过程中示波器还是非常有用的，可以让自己省很多麻烦。



修改了之后就可以获取出键盘的键值了。但是始终发现按键之后出现2个中断，后来才发现也是没仔细看datasheet的原因，首先要明白器件之间的链接顺序。如下：



处理器 《------》 i2c控制器 《---i2c---》 设备控制器 《------》设备



我们操作的是处理器和i2c控制器之间的逻辑，而datasheet写的是i2c和设备控制器之间的逻辑。

datasheet上说出现按键上升沿或者下降沿int引脚会被拉低，所以说，对于处理器来说，他所看到的就是控制器上的int引脚是否被拉低，被拉低，有可能是按键按下也有可能是按键抬起。直接和gpio相连的是int引脚而不是按键。所以按键按下和抬起都会产生中断，这个在上层会处理一下，记录一下。