前文《android(linux)控制gpio的方法及實時性分析》主要使用linux shell命令控制gpio，該方法可在除錯過程中快速確定gpio硬體是否有問題，即對應的gpio是否受控。實際專案中，一般需要對gpio做特殊控制，如車載導航系統開機就給gps模組上電，或在daemon程式中控制gpio給乙個脈衝以reset藍芽模組等，就不便用shell 命令來控制，而需要另想辦法。
介紹了如何在c**中匯出gpio、設定方向以及控制gpio，這是完全可以工作的。如果只是需要在系統開機時給gps模組上電，那單獨寫乙個應用或者把相關**放在daemon裡，雖然也行，但稍顯麻煩，可採用如下方法簡便實現。
以msm8996的android6.0為例，修改device/qcom/msm8996/init.target.rc檔案，在on post-fs部分新增如下**，
write /sys/class/gpio/export 62write /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相關的驅動，重新編譯核心就可以了。
android linux 解壓命令
解壓gz00,gz01,gz02,gz03,壓縮包時 cat alps.tar.gz tar zx 例如alps.gb2.mp.v2.21 mtkshanghai75cu 6628 gb2 inhouse.tar.gz00 cat alps.gb2.mp.v2.21 mtkshanghai75cu ...
android linux 解壓命令
解壓gz00,gz01,gz02,gz03,壓縮包時 cat alps.tar.gz tar zx 例如 alps.gb2.mp.v2.21 mtkshanghai75cu 6628 gb2 inhouse.tar.gz00 cat alps.gb2.mp.v2.21 mtkshanghai75cu...
Android Linux 實時監控串列埠資料
之前在做wince車載方案時，曾做過乙個小工具tracemonitor，用於顯示wince系統上應用程式的除錯資訊，特別是在實車除錯時，用於監控和顯示can盒與主機之間的串列埠資料。因為需要搶占市場先機，經常在新車上市前，就得配合can解碼盒廠商同步除錯車機端軟體。這時候，tracemonitor就...