针对某项目中QNX驱动的反思

 

  第一次接触驱动层的东西，心里还有点小激动。总感觉自己比没搞之前提高了那么一点点，也不知是真的假的，拉出来遛遛。

 

1．整体思路

 

★驱动层

  先从驱动层说起，他将USB设备通过Resource Manager注册成一个文件，提供 IO服务：

①    ：通过USB控制接口登陆回调函数

②    ：通过USB的回调函数“insertion”，也就是USB插入信号来生成ResourceManager。如果设备已经插入，驱动启动后会立刻受到“insertion”回调。

③    ：通过ResourceManager登陆的各种IO接口，提供IO服务。底层是用usb_io来访问USB设备。

 

★接口层

  接口层通过解释设备中的数据协议，提供数据服务，主要有以下三种：

①    连接控制：通过连接接口控制app的接入，处理资源的获取和释放。

②    应答响应：通过各种操作接口提供数据服务，响应用户的请求。

③    通知处理：通过通知接口及时反映系统的状态。

2．现实

  虽然看起来还不错，但是实际运用的时候惨的一塌糊涂，那个各种不稳定啊，现在想起来心里还堵得慌。

  这次失败在接口层的通知处理上，当时那位神人是这么搞得

  ・1秒一次的数据通知，在通知线程中实现

  ・数据的发送/应答在客户线程中实现

  ・极品的来了，通知处理和应答处理各自访问设备文件。

    应答线程的处理是这样的

         ⇒通知→转发通知→继续收

         ⇒本消息的应答→返回

         ⇒其他消息→无视→继续收

    通知线程的处理是这样的

         ⇒通知→发通知→继续收

         ⇒其他消息→无视→继续收

  问题出来了，只要设备的连接不稳定，那消息是各种丢啊。最后没办法，系统只能频繁的通过重新连接来恢复。

 

3．反思

  再有机会的话要这样：

  ・通知处理与应答处理应该使用共通的IO层。受到的消息到哪里去由IO层决定。这样消息就不会莫名其妙的消息被丢掉了。

  ・应答处理中实现消息堆栈。虽然正常状况下消息是一个一个来得，但总是会有一些意外的，为了能在意外发生时保持正常，就要看看自己到底发了啥，来得是真的错误消息，还是其他消息的应答。