이번에는 제목 그대로 Eclipse ADT를 이용하여 실제 Android App을 만들어 BegaleBone Black(BBB)의 GPIO를 컨트롤 하려고 한다.
지난번과 동일하게 Header P9의 핀11(P9.11)과 핀13(P9.13)을 각각 Mode7 설정으로 GPIO30과 GPIO31로 사용할 예정이다.
GPIO를 Control 하기위해서는 PacktHAL(muxed GPIO)을 안드로이드앱에 포함시키는 작업을 해야한다. 그러기위해서는 PacktHAL은 공유된 라이브러리로 .apk 파일 안에 앱과 함께 넣어져야 하며, 공유된 라이브러리로 PacktHAL을 만들려면 java code와는 별도로 분리하여 build를 실행해야 한다.
즉, PacktHAL code는 C native code로 구현됐기에, Android NDK 내부에 제공된 특정 hardware architecture(ARM) Tool chain을 이용하여 build 된다.
참고로, 이렇게 build된 C native code는 Java Native Interface(JNI)를 통해 앱의 Java code에 의해 호출이된다. JNI는 C 데이터 타입을 Java 데이터 타입으로 또는 그 반대로 번역을 해주는 역할을 한다.
Android NDK 다운로드
PacktHAL code를 컴파일 하기 전에, Android NDK를 다음 링크를 이용하여 Download 받아야 한다.
SPI에 대한 Header 파일을 NDK가 깔려있는 위치에서(본인은 'D:\02_Dev_Tools\01_Android\android-ndk-r15c' 이다) 서브 디렉토리인 다음과 같은 경로로 옮기면 된다.
NDK가 있는 폴더\android-19\arch-arm\usr\include\linux
참고로, android-19를 사용하는 이유는 BBB에 올라가 있는 Android version이 Kitkat이고 그에 대한 API Level이 19이기 때문이고, arch-arm인 이유는 BBB의 CPU core가 ARM이기 때문이다.
정상적으로 잘 따라 했다면, linux 폴더에 spi 폴더가 생성이되고, spi 폴더 안에 spidev.h 파일이 있을 것이다.
PacktHAL 컴파일
자, 이제 PacktHAL code를 컴파일 하고, 그리고 나서 라이브러리 형태로 앱에 포함하는 것을 연습해 보겠다.
1. eclipse를 열어 'File → New → Android Application Project'를 선택하여 새로운 프로젝트를 하나 만들고, 그 프로젝트 경로를 잘 숙지한다. 본인은 경우는 그 경로는 'D:\02_Dev_Tools\01_Android\eclipse_workspace\myapp\jni'이다.
2. PacktHAL 폴더 안에 jni 폴더를 복사하여 #1에서 만든 프로젝트 경로에 붙여 넣기 한다. 참고로 jni 폴더는 첨부 파일로 넣어 두었으니 참고하면 되겠다. 또 참고로, jini 폴더 안에 있는 파일은 하드웨어를 access하기 위해 만든 c파일들이다.
3. Window에서 CMD 창을 열고 #1에서의 프로젝트 경로로 이동 한후, #2에서 복사한 jni 폴더로 이동을 한다.
4. 해당 디렉토리에서 Andorid NDK를 이용하여 PacktHAL을 빌드한다. 빌드하는 방법은 Android NDK 경로에 있는 ndk-build를 호출하면 된다. 따라서 본인의 경우는 ndk-build가 있는 경로가 'D:\02_Dev_Tools\01_Android\android-ndk-r15c\ndk-build"이므로, 하기와 같이 입력을 하였다.
이제 컴파일이 제대로 되었는지 확인을 해보자.
안드로이드 프로젝트를 생성한 폴더에서 'libs' 폴더를 들어가 보면 여러 개의 폴더가 생성된 것을 알수가 있다. 눈치가 빠른 사람이라면 우리가 jni를 NDK로 컴파일 할때 나온 메세지들과 관련된 폴더들이라는 것을 알 수 있을 것이다.
우리 Target board인 BBB에 해당 되는 TArget은 'ameabi'이므로, 그 폴더에 들어가서 'libpacktHAL.so' 파일이 하기와 같이 정상적으로 생성되었는지를 확인하면 된다.
이 라이브러리를 Android Project에 넣어 사용하면, 실제 안드로이드 앱에서도 라이브러리 안에 jni 폴더의 c 파일들을 이용하여 하드웨어를 제어 할 수 있게된다.
안드로이드 커널은 전형적인 리눅스 커널에서 찾을 수 없는 몇 가지 추가 기능을 포함하고 있다. 그것은 Binder IPC와 low-memory keller이다. 그러나 이것을 제외하고는 안드로이드 커널은 여전히 리눅스 커널이라고 말할 수 있다.
안드로이드 커널이 위의 몇 가지 기능을 제외하고 리눅스 커널과 같다는 것은 커다란 이점이 있다. 그것은 리눅스 커널에 이미 특정 리눅스 드라이버가 존재 한다면, 안드로이드 드라이버가 있다는 것과 동일한 말이다.
카메라, 오디오, 비디오, 버튼 그리고 터치스크린 등등... 이미 존재하는 리눅스 드라이버들을 가져다 이용하는 것은 안드로이드 지원을 더욱 쉽게 만들어 준다.
그러나 전형적인 리눅스 배포판이 어플리케이션들에 많은 다른 디바이스 파일들(/dev filesystem 안에 직접 파일 열기로) direct access를 허용하는 것과는 다르게, 안드로이드는 하드웨어를 직접 접근하는 것을 제한한다.
예를 들어 서로 다른 안드로이드 앱들이 음악 재생 이나 녹음을 위해 오디오 기능을 사용한다면, 안드로이드 아래에 리눅스 커널은 Advanced Linux Sound Archtecture(ALSA) 오디오 드라이버를 통해 이 오디오 기능을 제공한다. 대부분의 경우 한번에 하나의 프로세스만 ALSA 드라이버 자원을 열고 컨트롤 할 수 있다. 만약 각각의 앱들이 ALSA 드라이버 리소스에 접근을 하고 사용을 한다면, 문제가 발생할 것이다. 그 중 하나의 앱이 쉽게 ALSA 드라이버 리소스를 갖을 수 있다면, 그리고 다른 앱들의 접근을 막는다면... 문제가 커질것이다. 이 문제를 해결하기 위해 안드로이드는 managers를 사용 한다.
Android managers
매니져들은 모든 app들을 대신 해서 하드웨어 디바이스들을 컨트롤 하는 시스템의 구성 요소이다. 매니져들은 각각의 오디오/비디오/통신 등등의 리소스들과의 인터페이스와 할당을 책임지고, 앱이 그 리소스를 사용할 권한이 있는지를 정의 한다.
리소스를 사용하기 위해서, 입은 반드시 android.content.Context class의 getSystemService() 매써드를 통해 알맞은 매니져를 참조 생성해야 한다.
// Create a reference to the system "location" manager
LocationManager locationManager = (LocationManager)
mContext.getSystemService(LOCATION_SERVICE);
그리고 나서, 이 매니져 레퍼런스를 통해 정보를 만들고 요청들을 컨트롤한다.
// Query the location manager to determine if GPS is enabled
isGPSEnabled = locationManager.
isProviderEnabled(LocationManager.GPS_PROVIDER);
앱들은 Java Android API를 이용해서 매니져들과 상호작용을 한다.
그리고 매니져들은 이런 Java 매써드에 응답하는 동안에, 하드웨어와 직접적으로 상호작용을 하는 native code를 호출하기 위해 결국은 Java native interface(JNI)를 사용해야만 한다. 여기서, 안드로이드 API와 native code를 호출하는 것 사이의 다리는 hardware abstraction layer(HAL)로 알려져 있다.
Device Tree(DT) 그리고 Device Tree Overlay(DTO)는 하나의 시스템에서 하드웨어를 설명하는 하나의 방법이다. 이에 대한 예는 그 시스템이 UART와 어떻게 인터페이스 하는지, 그 핀들이 어떻게 Mux 되는지, 어떻게 그 디바이스를 enable하는지 그리고 어떻게 그 드라이버를 사용하는지를 설명하는 것이다.
참고로, 원래 BeagleBone은 DT를 사용하지 않았지만, 그 이후 출시된 BeagleBone Black(이하 BBB)이 Linux Kernel 3.8을 사용하면서 DT를 사용하게 되었다.
다음 내용으로 부터 그 개념들을 분석 하려고 시도할 것이고, 어떻게 그리고 왜 우리가 DT를 사용하기 원하는지에 대한 예제들을 보여 줄 것이다.
Device Tree Background
ARM component들을 둘러싼 리눅스 커널 안에서 과거 몇년 동안리눅스를 사용한 ARM 시스템에서는 많은 혼동과 갈등이 있었고 이는 ARM 보드 파일들을 대체하는 평면 Device Tree를 사용하는 새로운 ARM 보드를 이끌어 냈다.
DT와 관련해 밝혀진 하나의 이슈는 DT가 run-time 동안 그 시스템(muxing pins, enabling devices 등등)을 수정이 필요한 Open embedded system으로 디자인 되지 않았다는 것이다. 그래서 Pantelis Antoniu는 하나의 솔루션을 구현 했는데, 이것은 device tree overlay들과 cape manager를 사용하는 것이다. 그 이후, Grant Likely는 user-space로 부터 run-time 동안 DT의 수정을 허용하는 것 "존재하는 dtb data format으로 부터 직접 확장"이었던 새로운 device tree overlay format에 대해 허용하는 시스템을 제안했다.
/*
* Copyright (C) 2013 CircuitCo
*
* Virtual cape for UART1 on connector pins P9.24 P9.26
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
/dts-v1/;
/plugin/;
/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
/* identification */
part-number = "BB-UART1";
version = "00A0";
/* state the resources this cape uses */
exclusive-use =
/* the pin header uses */
"P9.24", /* uart1_txd */
"P9.26", /* uart1_rxd */
/* the hardware ip uses */
"uart1";
fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {
bb_uart1_pins: pinmux_bb_uart1_pins {
pinctrl-single,pins = <
0x184 0x20 /* P9.24 uart1_txd.uart1_txd MODE0 OUTPUT (TX) */
0x180 0x20 /* P9.26 uart1_rxd.uart1_rxd MODE0 INPUT (RX) */
>;
};
};
};
fragment@1 {
target = <&uart2>; /* really uart1 */
__overlay__ {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&bb_uart1_pins>;
};
};
};
위에 표시된 overlay는 "tree structure of nodes and properties"이다.
이제 위의 oevlay를 하나씩 세분화하여 분석해본다.
첫 번째 섹션은 단지 옵션인 코멘드이지만, 주로 copyright/license 정보에 대한 그리고 이 코드가 무엇을 제안하는지를 이해하기 쉽게 하는 부분이다.
/*
* Copyright (C) 2013 CircuitCo
*
* Virtual cape for UART1 on connector pins P9.24 P9.26
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
그 다음 두개 라인들은 dts 파일의 버젼과 그것을 플러그인을 설명해 준다.
/dts-v1/;
/plugin/;
그 다음 라인은 DT의 root node의 시작을 설명해 준다.
/ {
"compatible" 라인이 설명하는 것은 호환성이 가장 낮은 것 부터 시작하는, 함께 작업하기 위해 디자인된 DT overlay이다. 여기에 언급되지 않은 어떤 플랫폼들은 로드가 실패할 것이기 때문에, 우리가 지원하고 싶은 모든 플랫폼의 이름을 여기에 기입하는 것은 중요하다.
다음 섹션인, part-number와 version은 알맞은 DT overlay가 로드 될 수 있게 보장하는 추가 안전 장치이다.
/* identification */
part-number = "BB-UART1";
version = "00A0";
exclusive-use 속성은 우리가 필요로 하는 자원들과 다른 어떤 overlay들이 그런 자원들을 사용하는 것을 피하기위해 기입을 하는 것이다. 이 경우, 우리는 P9.24과 P9.26을 UART1 디바이스로 사용하고 있다.
/* state the resources this cape uses */
exclusive-use =
/* the pin header uses */
"P9.24", /* uart1_txd */
"P9.26", /* uart1_rxd */
/* the hardware ip uses */
"uart1";
그 다음으로는 device tree fragment들이다. 이것들은 overlay할 타겟을 설명하고 그리고 나서 각각의 fragment는 mux pin들 이거나 또는 enable device들로 사용자 지정 할 것이다. 아래 fragment는 복잡해 보이지만 그렇게 나쁘진 않다. 첫 번째는 이 fragment의 Target이 overlay 될 예정이라는 것을 우리가 설정하고 있다는 것이다. 이 경우, pinctrl-single 드라이버와 호환되는 am33x_pinmux 이다. 어떻게 이 드라이버를 사용하지에 대한 예제들은 pinctrl-single documentation page에서 찾을 수 있다.
그 다음 라인은 __overlay__ node 그 자신이다. 해당 노드 내부에 그 첫 번째 속성은 다음 fragment(bb_uart1_pins)에 사용 될 것이고, pinctrl-single 드라이버에 의해 조정되는그 핀들 muxing에 대한 정의를 포함한다. 우리는 그 documentation page의 설명을 통해 어떻게 설정 할지를 알 수 있다.
pinctrl-single에 대한 pin configuration node들은 pinctrl register offset과 pinctrl-single,pins에 사용되는 value 쌍으로서 지정된다. 오직 pinctrl-single,function-mask에 지정된 비트들만이 업데이트 된다. 예를 들어, 디바이스 하나에 대한 핀 한개 설정은 pinctrl-single,pins=<0xdc 0x118>;로 완료될 것이다.여기서 0xdc는 그 디바이스 pinctrl register에 대한 pinctrl register base address로부터의 offset이고, 0x118은 pinctrl register의 희망하는 값을 포함한다.
pinctrl-single, pins 값 블럭 내부에서, 값들의 두 행은 UART1 디바이스를 위해 그 핀들을 설정하고 있다. 이 경우, MODE0로써 P9_24는 OUTPUT(Tx)가 될 것이다. 마찬가지로 MODE0로써 P_26은 INPUT(RX)가 될 것이다. 그 pin reference for BoneScript croos-referencing에 의해 P9_24를 0x184로 설정 할 필요가 있다고 말할 수 있다.
마지막 fragment는 그 uart device를 활성화 한다. overlay에 대한 그 target은 uart2(실제로 uart1으로 주석처리 됨)이다. 또한 이전 프래그먼트 속성 (bb_uart1_pins)을 참조하여 pinctrl 드라이버로 활성화 된 핀을 uart 장치에 매핑합니다.
이것은 매우 압도적이며 실제로 모호한 것처럼 보일 수 있다. 원하는 작업에 대한 새 오버레이를 만드는 가장 쉬운 방법은 이미 수행하려는 작업에 가까운 오버레이로 시작하는 것이다. 이것을 찾기 위한 가장 좋은 장소는 /lib/firmware (Angstrom)이며, 사용을 위해 이미 만들어진 오버레이를 잘 살펴보면 된다.
Exporting and Unexporting an Overlay
다음의 예제는 디폴트 Angstrom distribution을 사용한 데모이다.
먼저, 디폴트로 이용 가능한 모든 device tree를 보기위해 /lib/firmware를 확인해라.
root@beaglebone:~# cd /lib/firmware
root@beaglebone:/lib/firmware# ls -ltr
total 888
...
여기서 몇몇의 이용 가능한 overlay들을 볼 수 있다. 그 소스(dts) 그리고 컴파일된 파일(dtbo)는 해당 디렉토릭 안에 있다.
그 내용을 보기 위해 소스파일들 중에 하나를 열어 본다. 그 overlay 그들 자신은 잘 묘사되어 있고 잘 설명되어 있다.
자 이제 이전 페이지를 통해 살펴 봤던 BB-UART1-00A0.dts 파일을 사용한다.
우리는 .dts 파일을 볼 수 있었지만, 우리는 그것이 포함한 것을 이미 알고 있다. 그곳에 우리가 이용 가능한 이미 컴파일된 .dtbo 파일이 있다는 그 사실의 이점을 이용해 보자. 미래 섹션에서 우리가 소유한 것 중 하나를 빌드하고 컴파일 할 것이다.
자, bone cape manager에 의해 활성화 된 overlay들을 볼 수 있는 곳으로 이동하자.
root@beaglebone:/lib/firmware# cd /sys/devices/bone_capemgr.*
우리가 그 숫자가 무엇인지 알 수 없으므로 위의 *가 필요하다. 그 것은 부팅 순서에 의존한다. /sys/devices/bone_capemgr.8/slots뿐만 아니라 /sys/devices/bone_capemgr.9/slots 경로를 본적이 있다. 특정 경로가 무엇인지 확인해야 한다.
BeagleBone docementaion에 의하면 최초 3 슬롯들은 그 cape들 위에서 EEPROM ID들로 할당되었다. 그 다음 2개는 boot시 로드되는 overlay들이다. 숫자 4는 Angstrom 배포판으로 부터 부팅할 가능성이 높게 빌트된 EMMC memory이다. 그 다섯번째 overlay는 HDMI component 활성화에 대한 것이다.
우리의 선호하는 UART1의 overlay처럼, 이제 또 다른 overlay를 내보낸다면, 숫자 6과 같이 리스트된 새로운 옵션을 볼 수 있을 것이다. 그 UART1 dtbo 파일 내보내기를 시도해 보자.
우리는 6번째로 리스트된 옵션을 가졌고, 그 이전에 '-'를 입력한다. 그리고 그 slots 파일에 쓴다.
한 가지 알아 두어야 할 것은 Angstrom의 6-20-2013 릴리즈에서 다양한 overlay들의 언로딩은 커널 패닉을 야기할 수 있고, capemgr를 예상할 수 없게 만들면서 ssh 세션을 잃는 것을 야기 한다. 이 문제가 해결 될때 까지 overlay들을 unload하기 위해 system을 재시동하는 것을 권장한다.
이제 우리는 시스템 재시동은 overlay들을 unload하는 것을 야기할 것이라는 걸 알고있다. 시스템이 부트 업될때, 어떻게 하면 우리는 overlay들을 로드할 수 있을까?
이건 정말 간단한 문제이다. 우리가 필요로 하는 모든 작업은 BBB에 작은 FAT 파티션 안에 uEnv.txt에서 overlay들을 참조하는 것이다.
다음 과정은 UART1 overlay에 대해 이것을 어떻게 진행하는지 보여준다.
mkdir /mnt/boot
mount /dev/mmcblk0p1 /mnt/boot
nano /mnt/boot/uEnv.txt
#append this to the end of the single line of uEnv.txt (not on a new line):
capemgr.enable_partno=BB-UART1
Compiling an Overlay
이제 우리는 메뉴얼로 하나의 overlay를 활성화했다. SPI0 디바이스와 버스를 활성화하기에 대한 Adafruit BBIO 파이썬 라이브러리 안에 사용된 그리고 생성된 하나의 overlay를 취해보자. the Adafruit Github repository for Adafruit_BBIO에서 이 overlay의 최신 복사본을 찾을 수 있다.
위의 오버레이를 빠르게 살펴보면, UART1에 대한 오버레이와 같이, 동일한 패턴을 따르는 것을 볼 수 있다. 그곳에는 두 개의 fragment들이 있으며 첫 번째것은 pinctrl-single 드라이버를 사용하여 핀을 mux합니다. 우리는 SPI0 핀 중 4 개를 사용하고 모든 것을 Mode 0으로 설정한다. 그런 다음 fragment@1은 적절한 핀들로 spi0 device를 대상으로하며 그리고 'spi-max-frequency'와 같은 spi device를 사용하는 것에 특수한 다양한 parameter들을 설정한다.spi-bus documentation에서 사용 가능한 옵션을 볼 수 있다.
Home 디렉토리로 이동하고 복사 그리고 새로운 파일을 붙여 넣기 하기 위해 nano를 연다. 아래와 이름과 마찬가지로 정확하게 저장해야 한다.
root@beaglebone:/tmp# cd ~
root@beaglebone:~# nano ADAFRUIT-SPI0-00A0.dts
다음으로, 우리는 device tree overlay 컴파일된 포맷(.dtdo)안에 이 파일을 컴파일 하기 위해 명령어를 실행한다.
간단한 Java 파일을 만들어 컴파일을 하려고 하는데, Error가 발생한다. 그 회피 방법을 구글링 끝에 찾아내어 이렇게 글을 써 본다.
우선, 내가 했던 작업은 다음과 같다.
Project를 하나 생성하고, app→java→com.example.myapplication 내부에 VariableAndType이라는 Java class를 만들었다.
그 다음 다음과 같이 간단한 코드를 입력하고 나서, 오른쪽 버튼 클릭 후 Run을 실행한다.
그랬더니 Error가 다음과 같이 발생한다.
오후 12:14:00: Executing task 'VariableAndType.main()'...
Executing tasks: [VariableAndType.main()] in project D:\01_MS_Work\99_Personal\01_Study\FastCampus\Java\Chapt4
FAILURE: Build failed with an exception.
* Where:
Initialization script 'C:\Users\MSKIM~1\AppData\Local\Temp\VariableAndType_main__.gradle' line: 20
* What went wrong:
A problem occurred configuring project ':app'.
> Could not create task ':app:VariableAndType.main()'.
> SourceSet with name 'main' not found.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
Deprecated Gradle features were used in this build, making it incompatible with Gradle 6.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/5.4.1/userguide/command_line_interface.html#sec:command_line_warnings
BUILD FAILED in 0s
오후 12:14:01: Task execution finished 'VariableAndType.main()'.
"SourceSet with name 'main' not found." 라는 키워드로 구글링을 하다 보니 다음 글을 찾을 수 있었다. 물론 번역을 해서 봐야한다. 유럽 국가 언어인거 같은데 자세히는 모르겠음...
