Embedded Software 개발 : `schematic to source code` - 1 편에 이어서...
Embedded Software 개발 : `schematic to source code` - 1
일이 일이다 보니 회로도를 열어 볼 일이 종종 있는데, 가끔 뉴비분들과 이야기해보면 본적이 없어 모르시는 경우가 있다. 어찌보면 당연하기도 하다. IT가 대세인지 오래고 임베디드/제조는 기
chlrbgh0.tistory.com
beaglebone kernel repo 를 찾아 다운로드를 받으며 이어서 작성한다.
해당 보드는 TI 사의 AM3358 Chipset 을 탑재하여 해당 datasheet 를 참조 필요하다.
https://www.ti.com/product/AM3358
여튼저튼 이어서 GPIO 관련 내용을 살펴보면, GPIO1_16은 GPMC_A0 Pin 에 의해 config 가능하도록 구성되어 있는 듯하다.
AP Datasheet 에서도 마찬가지로 여러가지를 배울 수 있다.
(1) PAD/BALL NUMBER : R13 이라고 기술되어 있는데, AP/CPU 등은 ball 이 임베디드 보드 제작시 PCB 상 패턴에 mount 된다. R13 PAD/BALL 이 정상적으로 연결되어야 해당 pin/ball 을 이용한 SW 설정이 가능해진다. 이 당연한 소리를 설명하는 이유는 개발 과정에서 이런 일이 정상적으로 제작되지 않는 경우가 발생하기 때문이다.
(2) MODE : PIN NAME 은 GPMC_A0 이며, Mode 에 따라 signal 유형이 바뀐다고 보면 된다. 각 signal 유형이 어떤 기능인지 구체적으로 알기 어려우나, IO Type 이 I(Input)O(Output)으로 구분되어 있는 것으로 보아 각각이 다른 목적을 갖는 기능이고 이에 대하여 필요에 따라 설정을 진행한다고 생각하는 게 옳은 판단일 것이다.
(3) PULL UP/DOWN : GPMC_A0 pin 이 원하는 Signal/타입으로 config 되었을 때 해당 pin 이 회로 내에서 어떤 형태로 연결되어야 하는지를 기술한다. 예를 들어 reset pin 과 같은 case가 앞서 설명한 것처럼 pull up 을 걸어 해당 동작이 원활하도록 설정하는 것과 같은 맥락이다.
* 노트북에서 소스 압축이 풀리지가 않아 github 내에서 코드를 찾아 보았다(여기서도 쎄빠질줄이야ㅜㅠㅜㅠ)
* 드디어 이제 source code 가 시작 되었다.
* 어느 날에선가 부터 ARM linux 의 machine 관련 코드가 device tree 로 바뀌었다. 기억으로 power pc 에서 지원하던 dts 를 linaro 에서 upstream 하기 시작했는데 느낌상 Android 가 eco 를 꾸리며 arm machine 이 늘어나서 dts 기반으로 변경하지 않았나라고 기억난다.
source(dts 는 엄밀히 말하면 script 이지만 여튼,,,) 에서도 마찬가지로 여러가지를 배울 수 있다.
(1) 앞서 살펴본 내용이 dts 내에 기술 되는데, P9_15 로 define 하여 R13/GPMC_A0/GPIO1_16을 config 한다고 보면 될듯. 이런 자세한 주석이 정말 고맙다.
(2) BONE_PIN : Macro 함수를 만들어서 쓰고있는데, 모든 PIN 에 대하여 모든 case 를 code 로 만들기 번거롭고 사이즈가 커지니 일괄 처리 가능토록 만들었다. 아래와 같은 형태인데, 참 잘 짰다. 가능한 여러 타입의 pin define 을 만들고 board 환경에 따라 필요한 타입의 enable 여부만 결정하면 되는 것이니, 남이 만들어 둔것으로 보면 당연하게 느껴지지만 이러한 구조를 직접 만드려면 저런 퀄리티로 바로 나올까...라는 쫄리는 그런 맘...
/* macro: BONE_PIN( <pin>, <mode_name>, <register_value_macro(s)> */
#define BONE_PIN(XX,ZZ,QQ) \
XX##_##ZZ##_pin: pinmux_##XX##_##ZZ##_pin { pinctrl-single,pins = < QQ >; };
(3)/(4) P9_15 config : IO TYPE, PULL UP/DOWN TYPE, MUXCONFIG,
AP datasheet 에 확인된 내용들이다. 해당 pad 의 io type pull up/down config 및 signal type 에 대한 define 들이다. 하나의 pad 에 대하여 여러 config 가 공존하는 이유는 필요한 것만 선택하여 enable 하면 되니까...이겠지?. file name 에 common-univ 인 걸로 봐서 아마 맞겠거니...싶다.
이러면 나가린데... ㅜㅜ
그럼 보드를 구해서 command line 으로 gpio contorl 만 하면 끝나버리는 상황이 벌어질 듯 하다.
여튼 저튼 이런 느낌으로 하나씩 개발하면 되는 거긴한데... 뭔가 참으로 찜찜하네...
댓글