锋影
e-mail：174176320@qq.com
接触驱动层的东西，心里还有点小激动。总感觉自己比没搞之前提高了那么一点点，也不知是真的假的，拉出来遛遛。
1．整体思路
★驱动层
先从驱动层说起，他将USB设备通过Resource Manager注册成一个文件，提供 IO服务：
① ：通过USB控制接口登陆回调函数
② ：通过USB的回调函数“insertion”，也就是USB插入信号来生成ResourceManager。如果设备已经插入，驱动启动后会立刻受到“insertion”回调。
③ ：通过ResourceManager登陆的各种IO接口，提供IO服务。底层是用usb_io来访问USB设备。
★接口层
接口层通过解释设备中的数据协议，提供数据服务，主要有以下三种：
① 连接控制：通过连接接口控制app的接入，处理资源的获取和释放。
② 应答响应：通过各种操作接口提供数据服务，响应用户的请求。
③ 通知处理：通过通知接口及时反映系统的状态。
2．现实
虽然看起来还不错，但是实际运用的时候惨的一塌糊涂，那个各种不稳定啊，现在想起来心里还堵得慌。
这次失败在接口层的通知处理上，当时那位神人是这么搞得
?1秒一次的数据通知，在通知线程中实现
?数据的发送/应答在客户线程中实现
?极品的来了，通知处理和应答处理各自访问设备文件。
应答线程的处理是这样的
?通知→转发通知→继续收
?本消息的应答→返回
?其他消息→无视→继续收
通知线程的处理是这样的
?通知→发通知→继续收
?其他消息→无视→继续收
问题出来了，只要设备的连接不稳定，那消息是各种丢啊。最后没办法，系统只能频繁的通过重新连接来恢复。
3．反思
再有机会的话要这样：
?通知处理与应答处理应该使用共通的IO层。受到的消息到哪里去由IO层决定。这样消息就不会莫名其妙的消息被丢掉了。
?应答处理中实现消息堆栈。虽然正常状况下消息是一个一个来得，但总是会有一些意外的，为了能在意外发生时保持正常，就要看看自己到底发了啥，来得是真的错误消息，还是其他消息的应答。
