HID的Report Descriptor报告描述符已经不是简简单单的描述某个值对应某个固定意义了,
它已经能够组合出很多种情况,并且需要pc上的HID驱动程序提供parser解释器来对
描述的设备情形进行重新解释,进而组合生成出本HID硬件设备独特的数据流格式,
所以我觉得可以把它理解为--报告描述符脚本语言--HID script,虽然它确实简单了点,但是
我觉得这么称呼报告描述符的这种行为能力,比较爽一些,而且似乎也算是贴切(gliethttp).
用户通过HID script专有脚本描述语言定义的Report Descriptor报告描述符,由usb设备端提供,
之后由pc上的HID专有parser解释器对usb提供的报告描述符进行处理,之后
pc对usb设备将要上传的数据成分会一清二楚.
最后由用户通过Report Descriptor的script专有脚本描述语言,个性定制出来的
将要被usb一次性发送的数据流,会交由pc操作系统指定的HID驱动程序中相应的API函数
(鼠标数据处理函数或者键盘数据处理函数)对数据串中的相应bits们进行解释,
最后影响到pc操作系统(鼠标单击、移动或者键盘数据)
对于HID设备的定义,需要注意:
HID的类码,是定义在接口描述符中的,至于接口描述符中的,子类码,其值不是用来区分mouse
或者keyboard的,因为HID设备形形色色,五花八门,HID协议制订者们,不希望,使用简单的子类码来
区分各种HID设备,而是采用一种更加灵活的方式---"报告描述符",原因很简单:多么好的规定,
随着产品应用中的不断创新和花样翻新,都会最后限定住用户对协议更丰富、更个性、更灵活的需求,
所以使用"报告描述符"专用脚本语言,让用户来自己定义他们的HID设备都有什么数据、以及这些
数据各个bit都有什么意义,之后位于pc上的HID驱动程序将通过parser解释器,对
用户使用HID专用脚本语言描述的数据情形--"报告描述符"，进行数据拼接,
最后pc的HID驱动程序将明确的知道,usb设备上传过来的数据的各个bit位的意义,
进而将相应意义下的bits位们,送到pc上HID驱动程序对应的API接口上进行bits数据处理,
这些API可能是用于mouse的X、Y坐标管理的,也可能是用于keyboard的-LED指示灯管理的.
因为HID"报告描述符"脚本语言的parser解释器代码比较大,所以对于BIOS来说不太现实,
因此需要把HID设备的接口描述符中的子类码值设置为1,
进而能够在BIOS启动时识别并使用你的HID硬件设备,当然前提是,你用HID脚本语言描述的
mouse或者keyboard的数据流格式必须和BIOS固定的格式相符才行,
如果设置为0,HID硬件就不提供BIOS支持,
所以我们的HID硬件设备只有当进入pc操作系统,并且pc操作系统的HID驱动加载完成之后,
才能被识别和使用,不过对于嵌入式系统,尤其我[gliethttp]的at91rm9200板子来说,没有多少意义,
因为这里说的BIOS是PC的BIOS,at91rm9200不提供那么复杂的BIOS,仅仅提供传递信息参数的uboot之类,
所以完全没必要设置成1.
HID设备的接口描述符中的接口协议部分用来宏观定义设备类型,
1--keyboard设备
2--mouse设备
因为HID有了"报告描述符"脚本语言,所以设备的所有具体信息都可以用脚本来描述,
所以从这个角度来说,接口描述符中的接口协议部分也没有存在的意义,
至于需不需要定义,那就看你做的HID设备是否支持BIOS了,
只有当BIOS启动标志位置位1时,接口描述符中的接口协议部分才有意义,因为BIOS中的代码
将使用这个位值,来判断接入到pc主板上的是mouse设备,还是keyboard设备,
进而BIOS将决定,由HID设备送上来的被BIOS限定好格式的数据流,
该交由mouse数据处理程序做,还是交由keyboard数据处理程序做.
HID设备必须具备控制管道--即:端点0,
和至少一个IN管道--用来传递HID设备数据,
至于host主机输出到HID设备中的OUT型数据,可以通过OUT管道专门传送,
也可以间接通过控制管道的OUT通道传输,
所以当我们定义了OUT管道后,枚举之后,pc的HID驱动就会通过该OUT管道
传递,如果我们没有定义OUT管道,那么控制管道的OUT通道就将作为传递
OUT型数据的间接管道. *博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。
发布文章
