不做不明真相的开发者 之驱动与中断

        在为一款TI芯片做知识储备时遇到dsplink，再一次与和驱动，中断，不期而遇。工作三年了，驱动，中断，一直困扰我的一个大问题。或许是浮躁，每每想快速的得到答案，而每次总是更加的困惑。
       工作了三年，乱七八糟的看了许多东西，从最初的wince到vxworks，rt，uc，虽是，乱七八糟，但有根主线在里面，那就是中断，驱动。如果在给我一个操作系统或者开发平台，我的思维惯性应该还是，从系统启动过程，驱动加载过程，中断服务，一步步的走过来，先梳理一遍。在过去的三年，或许我可以在别人的基础之上写出自己的驱动，但总是有很多的为什么拦在那里，虽然，我可以对它视而不见实现自己想要的东西，但每每回头，那几个问号，总是感觉如骾在喉，让人难受，最接近真相的是wince驱动和中断服务函数，为了找到问题的答案，曾经把wince的PB下的platform里面的代码全部打包成一个dsw工程，原因，就是方便用关键词去搜索，找到一个宏定义最终出处。即使是这样，还是一知半解。受其影响，我对其他几个操作系统的理解，都是按照这种方式来，把代码打包，关键词搜索，一步步理清关系。
        因为dsplink的关系，一下子又把那几个问号和如骾在喉的感觉勾起来了。那就再理一次咯，没想到这一次还真的理出来个头绪，积累三年的问题，一下子脉络清楚了，如骾在喉的感觉暂时没有了（或许以后会有更多的问号出现）。
       wince下的问题，基本上清楚了。所有的驱动都是以dll的形式给出，关于dll的信息，要在platfor.reg的注册表里一一注明。系统启动时，通过注册表提供的信息进行加载。这里，困扰我的一个最大的问题，是xxxOpen函数为什么可以返回TRUE呢，creatfile调用xxxOpen，是要返回一个xxxRead的句柄呢，后来读到vxworks ， 底层驱动xxxOpen函数要返回的是设备句柄，而系统操作函数返回的是文件句柄，联想之，应该是wince系统为该i设备分配了一个默认的句柄而已，虽然，我也可以猜到，但找不到根据又不肯让其作为说服自己的结论。关于wince的中断，具体的文件记不得了，但应该在某个文件里定义中断后，然后将该中断与一个事件中断关联起来，当中断发生时，系统首先会调用armint.c中的，OEMInterruptHandler(unsigned int ra)，这里，通过查看中断相关寄存器，将中断号返回给wince核。不同的处理器，有不同的中断判断机制，把接口开放出来，可以做到系统与具体设备的不相关。内核判断，如果不是如果外部定义的设备中断，那么就会触发你在ISR中定义的事件了，当然，在触发你的事件之前，你还需要把这个中断关掉，ISR执行完之后，重新打开中断，这两个操作，需要在wince提供的两个接口函数里实现，就是裸奔中操作中断屏蔽位了。
     RT,vxworks，中没有注册表的概念，那么他们的驱动怎么加载，什么时候加载的呢？这个是从读RT的源码中获得的灵感，因为在RT中，要用户自己实现一个xxx_hw_init,在这个函数里，调用了rt_device_register，向系统注册设备名字，而后在rt_device_init_all中调用xxx_int,函数，而且，xxx_hw_init必须在rt_device_init_all之前运行。vxworks里，也有向系统注册设备名的接口，而vxworks系统启动过程中，在两个地方初始化用户的设备sysHwIni，usrRoot（当然，系统启动必须设备要在此之前另行初始化）。灵感就这样来了，难道是sysHwIni向系统注册设备名的么？晚上下班回家看看，在一个显卡驱动readme里，果然要在sysHwIni添加驱动程序的用户自己的初始化函数，奶奶的，果然是在这里。还有，一直对rt，和vxworks里的intConncet心存疑问，他是怎么在把中断后和中断向量搞在一起的呢？既然前面一个搞通了，那顺便搞搞这个问题吧，ppc403Intr.c里发现蛛丝马迹，sysPpc403IntConnect，_func_intConnectRtn = sysPpc403IntConnect;func_intConnectRtn不正是intConnect的回调函数么？
驱动，ISR，懂了这些，远远不够，还有细致的工作要去做，这条线理清了，才能将珠子穿起来的。
这些问号，花了我很多精力去查资料，而和从事的工作直接关系又不是很大，但那些问号，确实又让人难受，或许上面的理解只是暂时把问号拉直了，或许一转眼，就在日志发表之后，又有新的问号出现了又或许，上面的理解只是些误解，那些拉直的 问号或许一会又慢慢变弯，人生不止，问号不止。