Android(Linux)控制GPIO方法二

　　前文《Android(Linux)控制GPIO的方法及实时性分析》主要使用Linux shell命令控制GPIO，该方法可在调试过程中快速确定GPIO硬件是否有问题，即对应的GPIO是否受控。实际项目中，一般需要对GPIO做特殊控制，如车载导航系统开机就给GPS模块上电，或在daemon程序中控制GPIO给一个脉冲以Reset蓝牙模块等，就不便用shell 命令来控制，而需要另想办法。

　　http://elinux.org/RPi_GPIO_Code_Samples#sysfs介绍了如何在C代码中导出GPIO、设置方向以及控制GPIO，这是完全可以工作的。如果只是需要在系统开机时给GPS模块上电，那单独写一个应用或者把相关代码放在daemon里，虽然也行，但稍显麻烦，可采用如下方法简便实现。

　　以msm8996的Android6.0为例，修改device/qcom/msm8996/init.target.rc文件，在on post-fs部分添加如下代码，

write /sys/class/gpio/export 62
write /sys/class/gpio/gpio62/direction out
chown system system /sys/class/gpio/gpio62/value
chmod 0666 /sys/class/gpio/gpio62/value
write /sys/class/gpio/gpio62/value 1

　　执行make bootimage命令生成boot.img，使用fastboot烧录boot.img，系统重新启动即可实现开机自动给GPS模块上电。类似导出一个GPIO，用于控制蓝牙模块的RESET引脚，就可以在Bluetooth的daemon程序里直接打开/sys/class/gpio/gpio63/value，并对其进行控制，可省去代码中对export和direction的配置。

　　特别说明，如果可通过shell脚本导出GPIO并进行控制，而修改init.target.rc却无反映，则很可能是内核中GPIO的配置有冲突！我在实际调试过程中，就掉到这个坑里了，折腾好久才最终发现问题的根本原因，GPIO62和GPIO63在内核中被用作了CAM_RST和CAM_STANDBY，线索在dmesg的log里，如下，

　　[ 18.590187] msm_camera_request_gpio_table:751 gpio 63:CAM_RESET1 request fails

　　[ 18.590193] msm_camera_request_gpio_table:751 gpio 62:CAM_STANDBY1 request fails

　　后来通过make kernelconfig，去除camera相关的驱动，重新编译内核就可以了。

　　另外，使用chown和chmod命令主要是为了后面Android的APP可访问/sys/class/gpio/gpio62/value，如果只在Linux的daemon里访问，chown和chmod应该可省，一如export和direction可直接write。