USB HID学习:一点开发记录

某天,曾经的前同事找我,说有个USB项目。因为知道我当时离职在找工作,于是转给我,然后介绍客户给我。

了解需求后,我分析了一下,主要是与USB设备通信的上位机,MFC我熟悉,USB找了一个开源的库hidapi,可跨平台运行,下载编码,尝试读取鼠标信息,获取到信息。于是确定可以接,就答应客户。之后深入了解需求。认为难度在于MFC绘图以及HID协议交互。最后决定分阶段实施,当然,费用也是分阶段付。

第一阶段

前期做界面,完成2种版本发给客户,客户选中其中一款。同时寄硬件设备过来。
在板子未到之前,完成主体界面窗口以及主要布局。研究MFC程序开机自动启动,系统托盘等功能。

板子到之后,就开始研究HID通信。客户发来一个工具读取参数的,可与设备正常通信。不过自编写的代码读取不到参数。重新研究HID协议,安装bus hound抓USB包,对照协议分析报文,对HID有一点认识。深入跟踪hidapi库源码,发现打开USB设备时出错,具体来说,枚举阶段,以读的方式打开,其后使用读写方式,但失败,返回ERROR_ACCESS_DENIED(错误码为5L),于是再使用读方式打开,成功。于是怀疑是因为读写方式打开失败的原因。网上说windows10系统不让以读写方式打开HID,切换win7虚拟机,测试,效果一样。在Linux系统用root权限跑同样代码,却正常。一度陷入困境。

研究了几天,实在无法,跟客户反映困难,客户找了份C#的代码,看了里面标记的时间,虽然有些年头了,但也尝试跑,发现可以。即:同样使用windows10系统,是能正常与HID设备通信的(其实先前工具能读取参数亦证明了)。于是分析C#代码,发现在收发feature report的地方有问题。原来feature report对大小有规定,目前知道是32个字符(使用hidapi等代码,必须多加一个ID的字节,共33字节),如果不符合长度要求,会返回错误,错误码为87L(即ERROR_INVALID_PARAMETER)。修改了,一切正常,难题解决。

接着研究通过USB写数据到板子上的flash上,亦遇到问题。通过bus hound分析,发现写的数据有部分与烧写文件二进制对应不上。找了很久,发现代码的偏移量范围有问题。由于feature report只有32字节,一次要写512字节,所以要循环多次,偏移量变量使用uint8,范围只有255,所以512字节都是前面128字节的内容,内容出错了,当然失败。修正后,一切正常。

到此,第一阶段结束,界面布局、语言切换、操作flash,全部完成,从第一天接触至完成,耗时三周。为了给客户一个良好印象,赶了进度,晚上基本搞到1~2点,周末大部分时间也在搞。虽然赋闲在家,但因为要照料小孩,也要煮饭买菜,日常琐事也占用很多时间。还好,客户如期打款,暂时缓解了燃眉之急。

后续阶段

后续阶段基本没有真正的难度,要说耗时的,主要是需求的不确定性,由于对背景及行业知识了解不多,很多时候,客户所述的需求都很多简单,但对我而言并不简单,所以来回多次沟通。
客户提到要支持 windows xp 和 windows 7 系统,由于前期没有确认这点,所以选择 VS 2015 开发,经测试,还是不能在 xp 上运行,于是跟客户反馈,最终确认无须支持 xp 系统。
由于要显示校准的过程,所以需要画光标,并进行闪烁,最大支持9点,约十年前知道了 tslib 库,当在 GitHub 上看到 tslib 的十字形图标时,倍感亲切。于是在 MFC 中实现了一模一样的图案。不知这叫抄袭还是叫致敬。
另一块画图相关的是坐标及柱状图显示,但无论怎样,也找不到根据鼠标缩放的方案,也是由于这个原因,开始学习 Qt,想看看另一套图形开发框架的效果。当然,这是另一话题了。

程序设计

由于个人崇尚简洁,因此原则上最终的程序只有一个exe,不依赖其它文件(当然,有些系统级别的dll,不在此列)。所以将 hidapi 源码文件直接添加到工程项目中,再将其封装为类。接着是中英文的切换,开始考虑使用po来实现语言的翻译,但实施起来过于复杂。既要编写语言文件,又要编译,所以舍弃。最终使用笨方式,在界面设计之时使用中文,然后再在代码中切换。语言切换和开机启动等标志写到注册表中。
此项目中,使用到如下技术:HID 数据读写、USB 设备拔插检测、父子窗口通信、开机启动、系统托盘、注册表读写、控件画图。

问题小结

1、打开HID设备返回 ERROR_ACCESS_DENIED(错误码为5L) 问题。
失败的原因是,Windows认为鼠标、键盘,不应该用读写(实际影响的应该是“写”)方式打开。为安全起见,因此不提供写机制。hidapi 作者在 GitHub 的 issue 中亦提到这点。

打开设备函数为 open_device,如下:

static HANDLE open_device(const char *path, BOOL open_rw)
{
    HANDLE handle;
    DWORD desired_access = (open_rw)? (GENERIC_WRITE | GENERIC_READ): 0;
    DWORD share_mode = FILE_SHARE_READ|FILE_SHARE_WRITE;

    handle = CreateFileA(path,
        desired_access,
        share_mode,
        NULL,
        OPEN_EXISTING,
        FILE_FLAG_OVERLAPPED,/*FILE_ATTRIBUTE_NORMAL,*/
        0);

    return handle;
}

实际使用CreateFileA函数,传入参数有二:路径以及权限(是否读写)。枚举时,不使用读写。即CreateFileA第二个参数dwDesiredAccess为0。在正式打开时,先尝试读写(一般会失败),失败后再用0,此时成功。误入死胡同,以为发送数据一定要读写方式打开,关键语句:

desired_access = (open_rw)? (GENERIC_WRITE | GENERIC_READ): 0;

研究很久,也设置过STANDARD_RIGHTS_READ、STANDARD_RIGHTS_WRITE,但失败。
后找到一篇类似问题的帖子。 里面提到的问题虽然类似,但本质不同。帖子作者是同一USB设备被识别出2个设备,因此可以通过path判断出HID class那一个。但是作者并不成功,鉴于问题表现不同,没细看帖子(英文资料都是跳着看的)。

2、feature report 发送问题。
发送report,出错,在hid_send_feature_report函数,即HidD_SetFeature函数用GetLastError获取错误码,返回87L(即ERROR_INVALID_PARAMETER)。改report报文大小为0x20+1,成功,bus hound可捕获到。(观察bus hound以及网上一些报文分析(长度为0x20),结合ERROR_INVALID_PARAMETER,猜测可能是长度问题,改之,亦成功。)

心得体会

开始之时,先完成主体框架,再慢慢细化,先有大纲,再有细节,做到胸有成竹,不怕花时间修改,否则要等某个前置资源,如果资源不到位,只能等,一切都是空想。另外,整体架构好之后,不一定按需求前后实现,可以切换,即把多个需求错峰实现,这样,利用大脑的潜时间、暗时间帮我们思考问题。通俗地说,当遇到一个坎时,可以先跳过,过几天可能想到解决之法。做其它事也类似,比如写书。

对于结构体、移位或crc计算等,需要限制变量的位数。但是对于长度、返回值、偏移量等,直接用int即可,在PC领域开发,不考虑字节的节省。这个在开发时没有引起足够重视,导致花费一定时间。

关于需求,其实谁也不能保证一开始就十分准确和完整,都是慢慢补充的。有时候,客户也不知道要实现什么样的功能,做成什么样的东西,此时,我们可以引导客户,甚至先按自己想法完成一版,让客户评估。如果我们等客户,客户等我们,这样徒耗时间,于项目无补。如果谁也不提方案,则自行提出,如果谁也不提意见,则按自己的意见。这是我比较喜欢的做事方式。

做这个项目时,汲取了之前的经验,一切从实际问题出发,追求速度,不扩展研究技术。先完成,再慢慢回顾和总结。其实,编程这么多年,在开发时会有自己的一套准则,以目前来看,开发必须要有git版本管理,编码格式和注释,简短的开发手记,如果不做这些,会觉得不安心。

项目小结

说实话,现在回顾,当初的评估是有点冒险的。我只是使用 hidapi 获取了鼠标的信息,但写数据未测试(注:尝试写数据给鼠标,失败)。因此,首次调试硬件时就遇到大问题,一度以为案子会失败。幸好客户给了 C# 代码,幸好有一点点 C# 基础,跟踪调试后最终解决问题。解决过程中到网卡查阅大量资料,还研究了 hidapi 源码。
无论怎样,从开发中的紧张担心到现在的释然,成就感还是有一点的,因为积累了一个方面的开发经验,除了熬夜的不良后果外,其它都是好的。

相关推荐
©️2020 CSDN 皮肤主题: 技术工厂 设计师:CSDN官方博客 返回首页