要想使用AI棒,最基本的环境是在插入AI棒是需要在\dev下创建一个指向AI棒(USB设备)的设备文件
最初在AI棒插入到海思3519开发板上时,只显示了一句话意思是识别了一个USB设备,但是发现在\dev下并没有创建出相应的设备文件,但是在\dev\bus\usb\003\下创建了一个文件经过查询发现,该文件实际上就是设备文件,其中189表示主设备号,在文件\proc\devices(如下图 左是主设备号,右是对应设备)里面发现189表示usb_device,276表示次设备号(主设备号代指一类设备,次设备号为这一类设备的某个特定设备,两者均由系统内核根据插入的设备分配)。
但是这个设备节点有个问题,那就是内核并没有给该设备文件规范一个特定格式的文件名,而是一个数字,且该数字会在每次拔插后逐次增加,名字一直在变化程序则无法使用。于是准备通过linux下一个很强大的设备文件管理工具udev来解决。在海思3519开发板上udev所在目录是\etc\udev\,该目录下有两个最主要的文件(文件夹)rules.d和udev.conf。udev.conf是个文件,从名字可以看出该文件设udev的配置文件,配置新创建的设备文件默认路径(\dev)及udev规则目录等东西,没有特殊情况不要随意修改该文件内容。rules.d是个文件夹,里面则存放着上面提到的udev所有的规则。所有的规则文件必须以“.rules”为后缀名。udev 按照规则文件名的字母顺序来查询全部规则文件,然后为匹配规则的设备管理其设备文件或文件链接。在规则文件里,除了以“#”开头的行(注释),所有的非空行都被视为一条规则,但是一条规则不能扩展到多行。规则都是由多个 键值对(key-value pairs)组成,并由逗号隔开,键值对可以分为 条件匹配键值对( 以下简称“匹配键 ”) 和 赋值键值对( 以下简称“赋值键 ”),一条规则可以有多条匹配键和多条赋值键。匹配键是匹配一个设备属性的所有条件,当一个设备的属性匹配了该规则里所有的匹配键,就认为这条规则生效,然后按照赋值键的内容,执行该规则的赋值。
仅当操作符是“==”或者“!=”时,其为匹配键;若为其他操作符时,都是赋值键。
“==”:比较键、值,若等于,则该条件满足;
“!=”: 比较键、值,若不等于,则该条件满足;
“=”: 对一个键赋值;
“+=”:为一个表示多个条目的键赋值。
“:=”:对一个键赋值,并拒绝之后所有对该键的改动。目的是防止后面的规则文件对该键赋值。
ACTION: 事件 (uevent) 的行为,例如:add( 添加设备 )、remove( 删除设备 )。
KERNEL: 内核设备名称,例如:sda, cdrom。
DEVPATH:设备的 devpath 路径。
SUBSYSTEM: 设备的子系统名称,例如:sda 的子系统为 block。
BUS: 设备在 devpath 里的总线名称,例如:usb。
DRIVER: 设备在 devpath 里的设备驱动名称,例如:ide-cdrom。
ID: 设备在 devpath 里的识别号。
SYSFS{filename}: 设备的 devpath 路径下,设备的属性文件“filename”里的内容。
例如:SYSFS{model}==“ST936701SS”表示:如果设备的型号为 ST936701SS,则该设备匹配该 匹配键。
在一条规则中,可以设定最多五条 SYSFS 的 匹配键。
ENV{key}: 环境变量。在一条规则中,可以设定最多五条环境变量的 匹配键。
PROGRAM:调用外部命令。
RESULT: 外部命令 PROGRAM 的返回结果。例如:
1 |
PROGRAM=="/lib/udev/scsi_id -g -s $devpath", RESULT=="35000c50000a7ef67" |
调用外部命令 /lib/udev/scsi_id查询设备的 SCSI ID,如果返回结果为 35000c50000a7ef67,则该设备匹配该 匹配键。
NAME:在 /dev下产生的设备文件名。只有第一次对某个设备的 NAME 的赋值行为生效,之后匹配的规则再对该设备的 NAME 赋值行为将被忽略。如果没有任何规则对设备的 NAME 赋值,udev 将使用内核设备名称来产生设备文件。
SYMLINK:为 /dev/下的设备文件产生符号链接。由于 udev 只能为某个设备产生一个设备文件,所以为了不覆盖系统默认的 udev 规则所产生的文件,推荐使用符号链接。
OWNER, GROUP, MODE:为设备设定权限。
ENV{key}:导入一个环境变量。
在键值对中的键和操作符都介绍完了,最后是值 (value)。Linux 用户可以随意地定制 udev 规则文件的值。例如:my_root_disk, my_printer。同时也可以引用下面的替换操作符:
$kernel, %k:设备的内核设备名称,例如:sda、cdrom。
$number, %n:设备的内核号码,例如:sda3 的内核号码是 3。
$devpath, %p:设备的 devpath路径。
$id, %b:设备在 devpath里的 ID 号。
$sysfs{file}, %s{file}:设备的 sysfs里 file 的内容。其实就是设备的属性值。
例如:$sysfs{size} 表示该设备 ( 磁盘 ) 的大小。
$env{key}, %E{key}:一个环境变量的值。
$major, %M:设备的 major 号。
$minor %m:设备的 minor 号。
$result, %c:PROGRAM 返回的结果。
$parent, %P:父设备的设备文件名。
$root, %r:udev_root的值,默认是 /dev/。
$tempnode, %N:临时设备名。
%%:符号 % 本身。
$$:符号 $ 本身。
说明替换操作符的规则例子
1 2 |
KERNEL=="sd*", PROGRAM="/lib/udev/scsi_id -g -s %p", \ RESULT=="35000c50000a7ef67", SYMLINK="%k_%c" |
该规则的执行:如果有一个内核设备名称以 sd 开头,且 SCSI ID 为 35000c50000a7ef67,则为设备文件产生一个符号链接“sda_35000c50000a7ef67”.
简单说明键值对的例子:
1 |
KERNEL=="sda", NAME="my_root_disk", MODE="0660" |
KERNEL 是匹配键,NAME 和 MODE 是赋值键。这条规则的意思是:如果有一个设备的内核设备名称为 sda,则该条件生效,执行后面的赋值:在 /dev下产生一个名为 my_root_disk的设备文件,并把设备文件的权限设为 0660。
通过学习udev的规则,于是在rules.d目录下创建了第一个自己的规则文件12-ai-usb.rules
内容为 SUBSYSTEM=="usb":表示子系统名为usb,(通过26个字母一个个试出来的)
ATTR{idVendor}=="03e7", ATTR{idProduct}=="2150":分别表示设备ID,高位为03e7,低位为2150,该值通过lsusb查询
SYMLINK+="ai_u":表示满足上面几个条件的设备则创建一个名字为ai_u的链接文件
MODE:="0600":表示上述创建的链接文件的权限为600
新建好上面的规则后再插拔AI棒,则在\dev下创建了一个链接文件于是欣喜若狂,成功了吗,反正至少解决了名字变换的问题。于是将编译好的示例程序run_cpp、libmvnc.a 、libusb-1.0.a等文件放进去,运行run_cpp,果然没成功。不仅没成功,我的设备文件ai_u也没了。闹哪样???
然后又继续上网查找,发现有一个赋值键NAME,这个键是利用匹配到设备的主、次设备号创建一个新的设备文件,也就是一个设备文件将由两个设备文件同时指向同一个设备,于是将前面规则中的SYMLINK+="ai_u"改为NAME="ai_u",再插拔一下,识别到AI棒时多了一句话,意思为创建的设备名字和内核识别的不同,请改为用SYMLINK+=或者修改名字,应该影响不大,然后再跑一下示例程序果然还是不行。创建的设备文件ai_u也没有,最后发现执行lsusb时,发现设备ID变了,由原来的03e7:2150变成了03e7:bf73,嗯???这是为什么?没办法看libusb.a的源码吧,突然灵光一现,我只用来匹配设备ID高为呢,因为低位变了高位并没有变,抱着试试的小心思将规则改成了,再插拔一下,运行run_cpp,成功了!!! 回头再看设备ID,反而没有变。幸福来的太突然了,经过了将近两周的时间,设备AI棒的使用结束。