리눅스 드라이버 작성을 위한 Bottom Half 선택하기

리눅스 드라이버 작성 시 bottom half 처리가 필요할 경우 선택 가능한 몇 가지 방법이 있다. 필요에 따라 적절한 방법을 선택하면 되는데, 이를 위한 일반적(절대적이지는 않지만 대부분의 경우 잘 동작하는...)이고 간편한 선택 방법은 아래와 같다.

1. 해당 작업이 sleep이 가능하거나 sleep이 필요할 경우 : Work Queue
2. 1이 아니며 빠른 처리가 필수적인 경우: Tasklet

tasklet은 빠른 응답이 필요한 경우에 work queue보다 더 적합하지만 interrupt context에서 실행되므로 해당 작업 도중에 sleep이나 선점이 일어날 수 없다. tasklet은 softirq를 사용하여 구현되는데, 디바이스 드라이버 작성시에는 softirq보다 tasklet사용이 권장된다. 하지만 softirq 사용이 필요한 경우가 있을 수도 있다. softirq와 tasklet의 가장 구별되는 특징은 tasklet은 여러 tasklet이 동시에 실행되지 않음이 보장된다는 점이다. 따라서 동기화에 대한 고려가 덜 필요하므로 softirq 보다 쉽게 사용이 가능하다.

tasklet과 softirq와의 관계와 마찬가지로, work queue는 kernel thread를 사용되어 구현되어 있다. work queue는 kernel thread를 직접 사용하는 것 보다 훨씬 쉽게 사용할 수 있도록 구성되어 있을 뿐만 아니라 kernel thread를 직접 만들어서 사용할 때 할 수 있는 거의 모든 일을 work queue를 사용하여 구현할 수 있다. 따라서 디바이스 드라이버 작성자가 굳이 work queue대신 kernel thread를 직접 생성하여 사용할 필요가 없다. work queue는 kernel thread로 구현되었으므로 process context에서 실행되고 따라서 sleep이 가능하다. 대신 동기화에 대해서는 디바이스 드라이버 작성자가 직접 고려해 주어야 하며, process context지만 kernel thread이므로 user space에 대한 접근은 불가능하다.

다양한 serial 통신 이해하기

UART
가장 대중적으로 사용되는 시리얼 통신은 UART device를 사용하는 것으로 보통 RS-232C transceiver와 함께 쓰인다. 하지만 RS-422이나 LIN등 다른 IF도 많이 사용된다. UART는 RX/TX 라인이 별도로 존재하고(full duplex) 별도의 clock라인은 사용하지 않는다. 따라서 양측이 서로 Baud rate를 맞추어야 통신이 가능하다. 즉 Asyn.통신이라는 말씀. 따라서 UART와 함께 사용되는 RS-232C도 동일한 특성을 가진다. 하지만 LIN transceiver를 사용할 경우에는 RX/TX선을 따로 가지는 대신 1개의 선만 사용하므로 full duplex가 아닌 half duplex로 동작하게된다. 또한 RS-232C는 1:1통신용으로만 사용되지만, 다른 IF 사용시 여러 장치간 통신에 사용이 가능하다.

UART에서 transceiver를 별도로 사용하는 이유는 무엇일까? 동일 보드에서 UART를 사용하여 통신할 경우 UART <-->UART 연결을 사용할 수 있지만, 외부 디바이스간의 통신에는 보다 멀리 전송하기 위해서 level shifter등을 사용하여 전압을 승압하는 것이다. 또한 다양한 전송 IF를 사용하여 1:1전송 뿐만 아니라 1:n 전송을 통한 네트워크 구현도 가능하다.

http://blog.naver.com/hjsnyh?Redirect=Log&logNo=80020142147

LIN- Local Interconnect Network
LIN은 자동차 업계에서 많이 사용하는 저속 차량용 네트워크로, UART를 사용한다. LIN transceiver를 통하여 network는 RX/TX구분없이 1 line을 사용하여 통신이 이루어 진다. 즉 RS232C에서는 RX/TX를 별도 라인으로 사용해서 full-duplex로 동작하는데 반하여 LIN 에서는 half-duplex로만 동작하는 Async. 통신방식이며 I2C, USB등과 유사하게 Master 기기가 통신을 시작하는 방식을 사용한다. 보통 20kbps이하의 저속 통신에 사용되며, 최근에는 CAN등에 자리를 내주고 있다. Master라는 것은 seiral통신에서 통신을 시작할 수 있는 권한이 있는 디바이스로, Slave장치는 Master장치가 통신을 요청할 때 까지 어떠한 통신도 시작할 수 없다. 각 serial통신 방법에 따라 Master가 1개만 존재하거나 여러개 존재할 수 있으며, CAN같은 경우 모든 장치가 Master/Slave구별 없이 원하는 시점에 메세지 전송이 가능하다. USB장치의 경우에는 Master/Slave라는 용어 대신 Host/Device라는 용어를 사용한다.

http://blog.naver.com/cybercall?Redirect=Log&logNo=120032068893


SPI - Serial Peripheral Interface Bus
SPI는 또 다른 serial장치로 CS, MISO, MOSI, SCK 4개의 선을 사용한다. RX/TX라인이 별도로 존재하고, CLK이 있으므로 full duplex, Sync.전송 방식이다. SPI는 Master/Slave 장치가 구별되며 Master에서 데이터를 보내는 양 만큼 Slave에서 데이터가 들어오게 된다. 이는 Master/Slave 양쪽에 shift register를 사용하기 때문으로 Master측에서 Tx만 필요한 경우 데이터를 보내는 순간 Slave에서 들어오는 데이터는 무시하면 된다. 반면 슬레이브에서 보내는 데이터를 읽어야 할 경우 Master는 dummy바이트를 보냄으로써 Slave로 부터 데이터를 받을 수 있다.
보통 1:1 통신용으로 많이 사용되지만, 1개의 Master에 여러개의 Slave를 붙일 수도 있다. Master에 CS를 여러개 사용하여 각각을 Slave의 CS로 사용하여 여러개의 Slave를 서로 독립적으로 control하도록 할 수도 있고, Master에 한개의 CS를 모든 Slave에서 공유하면서, 한 Slave의 MISO를 다음 Slave의 MOSI로 연결하여 daisy-chain을 구성하여 여러개의 Slave를 연결하기도 한다.

http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus


I2C- Inter Integrated Circuit
I2C는 2개의 선만을 사용하며 이는 각각 data와 clk에 해당한다. clk이 있으므로 Sync.이며 data를 위한 1라인만 사용하므로 TX/RX를 1선으로 처리해야 하므로 half duplex전송만 가능하다. I2C버스에서는 여러개의 Master와 Slave 장치가 연결될 수 있다. half duplex 특성 상 TX/RX가 동시에 발생할 수 없기 때문에 I2C는 Master가 모든 통신을 시작하며 Slave 장치는 여기에 응답만 가능하다. 이와 같은 통신 특징은 USB에서도 찾을 수 있다. (하지만 USB는 다중 Master를 지원하지 않는데 반하여 I2C는 다중 Master를 지원한다) I2C는 여러개의 Master를 허용하므로 이들이 동시에 메세지를 보내기 시작할 경우 bus는 0을 보낸쪽이 차지하게 되며 1을 보낸 쪽은 전송을 중단한다. 동일한 방법이 CAN bus에서도 사용되나 CAN의 경우 모든 장치가 Master로써 동작한다.(CAN에서는 모든 장치에서 Tx 시작이 가능하므로 Master/Slave를 굳이 구별하지 않는다.) 또한 CAN은 CLK이 없는 Asyc. 통신인 반면 I2C는 CLK을 사용한다. I2C에서는 다중 Master를 지원하지만 일반적으로 1개의 Master를 사용하여 시스템을 구현하는 경우가 많다. I2C는 표준 모드에서 100kbps, 고속 모드에서 400kbps로 동작한다. I2C는 SPI에서와 같은 CS가 존재하지 않으므로 각 장치마다 7bit address를 부여하여 이를 사용하여 target장치를 지정한다.

USB
USB장치도 I2C와 같이 Master(USB에서는 Host라는 용어를 사용)만이 트랜잭션을 시작할 수 있으며 Slave(USB에서는 device라는 용어를 사용)는 여기에 응답만 가능하다. 하지만 USB는 clk을 위한 선이 별도로 없다는 점에서 I2C와 다르게 Asyn. 통신이며 다중 Master(Host)도 허용되지 않는다. USB는 Frame이란 개념을 도입하여 한 Frame안에 여러 슬레이브 장치와 Master간의 통신이 포함될 수 있다. 하지만, Slave간의 통신은 불가능하며 Frame이 주기적으로 보내지지만 CLK이 따로 존재하지는 않기 때문에 Sync.통신은 아니다. 따라서 USB전송모드중 한가지인 isochronous를 사용하여 audio데이터를 전송할 경우, buffer가 충분히 크지 않다면 clock drift등으로 인한 buffer overrun이나 underrun이 발생 할 수 있다.

UART가 외부 전송을 위해 RS-232C나 LIN등을 사용하듯이 USB는 처음부터 외부 전송을 목적으로 만들어졌다. 하지만 최근에는 내부 데이터 버스로도 사용되고 있으며 , 이를 위해서 HSIC라는 I/F가 정의되었다.  HSIC는 USB의 sub spec.으로 high speed 전송만 지원하고 전송 거리가 10cm등으로 제약되어 있다.

I2S
I2S는 오디오 신호 전송용 serial통신으로 TX, RX, CLK, Frame Sync. 4개의 선으로 이루어져 있다. I2S를 통해서 다양한 형식의 PCM 오디오 데이터가 전송될 수 있다. 시스템에서 오디오는 보통 한방향으로만 전송되는 경우가 많으므로 TX/RX 중 하나만 사용하여 3개의 선만 사용하는 경우가 많다.

CAN
CAN은 SWCAN과 DWCAN이 존재한다. SWCAN의 경우 low speed(33.3KBit/s ~ ) 전송용으로 사용되며 1 wire통신이다. DWCAN의 경우에는 고속 전송용으로(~1MBit/s) 사용되며 이를 위해 2 -wire를 사용하며, 두 선은 각각 +- 만 변경된 동일한 신호를 가진다. CAN bus에는 여러개의 모듈이 연결되고 Master/Slave 개념 없이 서로 동등하게 통신이 이루어진다. 이를 위해서 I2C에서 사용한 것과 같은 arbitration란 개념이 필요하다. 즉 두 개 이상의 모듈이 동시에 메세지를 보내기 시작할 경우 메세지 ID가 작은 값을 가진 메세지가 bus를 차지하게 된다. 즉 0과 1이 동시에 bus에 실리면 bus에는 0이 실리게 되고 1을 전송하는 모듈은 전송을 중단하여야 한다. 하지만 I2C와 다르게 모든 장치가 메세지를 보낼 수 있으며 별도의 CLK라이을 사용하지 않는 ASync. 통신이다.

MOST50
차량용 멀티미디어 데이터 전송용 버스로 MOST25/150에서는 광통신을 사용하지만 MOST50에서는 wire를 사용한다. MOST50의 경우 48kHz마다 1 frame - 128 byte데이터가 MOST ring을 통해 전송된다. 이와 같은 frame은 Timing Master기능이 있는 특정 모듈이 만들어 보내며, 차례로 MOST ring에 포함된 모든 장치를 지나가게 된다. 각 장치는 해당 frame의 빈곳에 자신의 데이터를 넣어서 다음 장치로 재전송하게 된다. MOST ring에는 Timing Master이외에 Network Master, Connection Master, Power Master등 다른 Master기능을 가진 장치가 존재한다. 하지만 USB나 I2C와 다르게 Master가능을 가지지 않는 장치들 사이에도 서로 통신이 가능하며 Master의 도움없이 메세지 전송을 시작할 수 있다. 128byte의 MOST frame은 크게 세 부분으로 나뉘는데 각각 control data, Stream data, Packet data 영역이 된다. Control data영역으로 일반적인 용도의 commend나 메세지를 정의해 서로 주고 받을 수 있으며, Packet data영역은 주로 대용량 데이터 전송에 사용된다. 이 영역을 통하여 TCP/IP 데이터등을 전송할 수도 있다. Stream data영역은 DVD나 CD데이터와 같이 Sync.데이터 전송을 위해 사용하며, 사용 전 Connection Master를 통해 Stream data 영역안의 특정 위치를 해당 용도로 미리 할당받도록 되어 있다. 따라서 이후 아무리 다른 영역의 bandwith가 부족해 져도, 미리 할당받은 영역을 통해서 Sync.한 데이터 전송이 가능하다. 하지만, 이 영역은 특성상 에러가 발생하여도 재전송을 할 수는 없다. 기본적으로 MOST ring은 Timing Master가 만들어내는 clk을 모든 장치가 공유하여 사용하므로 Sync.전송이 가능하며 이로 인하여 audio/video등 multi-media데이터 전송시 clock drift문제등을 걱정할 필요가 없다.

NAND flash memory 이해하기.

Block
- NAND flash는 여러개의 Block으로 구성되며, Block단위로만 erase가 가능함.
- 64KByte ~ 512KByte의 크기를 가짐.
Page
- 하나의 Block은 보통 512Byte~8KByte 크기를 가지는 다수의 page들로 구성됨.
- Page는 NAND flash의 읽기 및 쓰기의 기본 단위로, byte 혹은 word 단위로 읽고 쓸수 있는 NOR flash에는 없는 개념이다. 즉 읽기 쓰기가 byte단위로는 불가능하기 때문에 driver에서 이를 고려하여 주어야 한다.

OOB(Out of Band)- Page마다 따라오는 수~수백 바이트 정도 크기의 extra 데이터 영역으로 16의 배수 바이트인 경우가 많다. spare영역이라고도 불린다.
- 이 영역은 사용자에게는 숨겨진 영역으로 아래와 같은 용도로 사용됨

1. Bad Block Marking : 특정 블록이 bad block일 경우 한 Block안의 첫 page 혹은 마지막 page의 OOB에 이를 표시함. 예를들어 최근에 출시되는 삼성 NAND는 공장 출하시부터 존재하는 bad block을 표시하기 위해서 bad block의 마지막 page의 첫 Byte를 Non-FF value로 표시함. 이는 NAND flash별, 제조사별로 다르며 해당 디바이스의 data sheet에서 확인해야 한다.
2. ECC(error correction codes)
3. File System Info.: 특정 file system은 이부분을 사용하여 구현됨.

이 영역은 대부분 r/w가 모두 가능함. 하지만 이 영역에 공장 출하시부터 존재하는 Bad Block Marking 정보가 지워질 경우 이 정보를 다시 살릴 수 있는 방법이 없으므로 절대로 OOB영역의 bad block 정보를 지우지 않도록 주의하여야 함. 필요시 이 정보를 사용하여 BBT를 작성하게 됨.


SLC/MLC- NAND flash의 type에는 SLC/MLC가 있는데 이는 각각 Single Level Cell/Multi Level Cell을 뜻함.
- SLC는 MLC보다 수명이 10배가량 길지만 가격이 비쌈. 따라서 write가 자주 발생하는 데이터용으로 적합.
- MLC에는 고용량이면서 write가 자주 발생하지 않는 데이터에 적합. (ex, MP3, video등 multimedia files)

BBT (Bad Block Table)- BBT는 boot loader나 flash관련 tool을 사용하여 flash를 erase 할 때 OOB를 참조하여 만들 수 있으며, Linux의 경우 kernel과 boot loader간에 BBT생성 규칙과 구조에 대해서 상호 협의가 되어 있음.

- BBT는 flash file system에 따라서 사용하기도, 사용하지 않기도 하므로 필수적으로 필요한 것은 아님.
- BBT를 만들어 놓으면 특정 block의 bad 여부를 빨리 확인할 수 있지만, BAD block 데이터가 OOB의 데이터와 항상 sync.가 되도록 주의하여야 하며, BBT를 기록하려는 block이 BAD block일 경우 어떻게 처리해야 할 지 등도 고려하여야 함.
- BBT는 두 개의 Block을 사용하며 NAND flash내의 마지막 Block에서부터 거꾸로 non-bad block을 찾아, 첫번째 발견된 non-bad block이 primary BBT, 두번째로 발견되 non-bad block이 secondary BBT가 됨.
- BBT에는 한 Block당 2bit를 사용하여 NAND flash 전체의 Block의 상태를 기록하는데, 각각의 Block은 "good", "bad" , "reserved" 세개의 상태로 표현됨.
- File System에서는 "good"으로 표시된 영역만 사용함. BBT가 저장된 Block은 "reserved" 로 표시하여 File System에서 덮어쓰지 못하도록 알려줌.


그 외 특성- NAND flash로 부팅하기 위해서 첫번째 sector에 boot loader가 위치해야 하는데, 첫 sector가 bad block이면 boot loader가 위치할 수 없으므로, 대부분의 제조사는 1st block이 bad block이 아님을 보증함.
- NAND는 NOR와 달리 읽기 횟수에도 제한이 있다. NAND에서는 매번 특정 블럭을 읽을때마다 해당 정보를 저장하는 전하가 약해진다. (물론 정보를 잃은 block은 erase후 다시 사용가능하다) 따라서 읽기 전용 파일이라 하더라도 해당 정보를 너무 여러번 읽어 데이터가 지워지기 전에 다른 곳으로 옮겨서 저장하는것을 고려하여야 한다. 또한 전체 파일 시스템 내에 읽기 전용 블록이 고정되어 있을 경우, 쓰기 가능한 영역에 erase가 집중되어 해당 영역의 수명이 짧아지는 문제도 발생할 수 있다(NOR도 마찬가지). 따라서 NAND용 flash file system은 설계 시 읽기 전용 블록의 읽은 횟수를 count하여 데이터가 유실되기 전에 다른 블록으로 옮겨 줌으로써, 데이터의 유실을 막고 flash erase가 읽기 쓰기 영역에만 집중되는 것을 피하도록 설계되어야 한다.
- NAND flash를 부팅 장치로 사용하는 경우 부트로더와 OS 영역은 일반적으로 file system의 관리를 받지 못하는 영역으로, flash의 읽기 수명이 해당 제품의 예상 수명보다 짧을 경우에는 해당 영역을 주기적으로 지운 후 다시 기록하여 주거나, 부팅 실패시 backup 영역에서 부팅을 재시도하도록 하는 등의 대책을 세워야 한다. 이는 해당 시스템의 NAND controller와 부트로더의 구현에 따라 적절히 설계되어야 한다.
- NAND flash는 NAND controller의 도움을 받아야만 부팅장치로 사용될 수 있다. 만약 NAND controller가 HW적인 ECC를 지원한다면 부팅 속도가 NOR보다 빠를 수도 있다. 최근의 SoC들은 대부분 HW적인 ECC및 부팅기능을 지원하는 NAND flash controller를 가지고 있다.

참조 링크http://wiki.openmoko.org/wiki/NAND_bad_blocks
NAND bad block management by uboot and kernel
NAND 플래시 메모리의 이해
http://www.ibm.com/developerworks/kr/library/l-flash-filesystems/

중소규모 프로젝트를 위한 Makefile 만들기

대규모 프로젝트에서는 재귀적 Makefile을 사용함으로써 다양한 디렉토리 구조에 유연하게 대처할 수 있다. 하지만 중소규모의 프로젝트에서는 매 디렉토리마다 Makefile을 넣는것은 좀 번거로운 일이 아닐수 없다. 이에 아래와 같이 중소규모 프로젝트에 적용가능한 디렉토리 구조 및 Makefile을 만들어 보았다. Makefile은 ./와 ./obj 두군데만 있어 관리하기 용이하도록 하였으며, ./Makefile이 ./obj/Makefile을 호출하는 구조이다.

먼저 디렉토리 구조는 아래와 같다

./
　|---main.c
　|--Makefile

./include
　|--- func1.h
　|--- func1.h

./srcdir1
　|--- func1.c

./srcdir2
　|--- func2.c

./obj
　|--- *.obj files
　|--- Makefile
　|--- depend file

아래와 같이 동작되도록 Makefile을 작성할 것이다.
　- 실행 파일은 ./ 디렉토리에 생성되도록 한다.
　- object파일은 모두 ./obj 디렉토리에 생성되고 make clean시 모두 지워지도록 한다.
　- make depend로 dependency file 설정하여 수정된 파일만 컴파일 되도록 한다.

./Makefile
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 OBJDIR = ./obj
2
3 all:
4 　　cd $(OBJDIR) && make
5
6 clean:
7 　　cd $(OBJDIR) && make clean
8
9 depend:
10 　　cd $(OBJDIR) && make depend

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

./obj/Makefile
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 CC = gcc
2 LD = gcc
3
4 INCDIR = ../include
5 SRCDIR1 = ../srcdir1
6 SRCDIR2 = ../srcdir2
7
8 VPATH = $(SRCDIR1) $(SRCDIR2) ..
9
10 CFLAGS = -O2 -I$(INCDIR)
11
12 TARGET = testapp
13
14 SRCS = $(foreach dir, .. $(SRCDIR1) $(SRCDIR2), $(wildcard $(dir)/*.c))
15 SRCS := $(notdir $(SRCS))
16
17 OBJS = $(SRCS:.c=.o)
18
19 all: $(TARGET)
20
21 $(TARGET) : $(OBJS)
22 　　$(LD) $^ -o$(TARGET) $(LIBS)
23 　　mv $(TARGET) ../
24
25
26 %o:%c
27 　　$(CC) $(CFLAGS) -c $< -o $@
28
29 clean:
30 　　-rm -rf $(OBJS)
31 　　-rm -f ../$(TARGET)
32
33 depend: $(SRCS)
34 　　$(CC) -M $(CFLAGS) $^ > $@
35
36 -include depend

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Line:14　 모든 디렉토리에서 c파일을 골라낸다.
Line:15　 c파일 리스트에서 경로명을 제거한다.
Line:17　 각 c파일에 해당하는 o파일 리스트를 만든다.
Line:22　 $^ 는 현재 타겟의 종속 항목 리스트 전체로 치환된다. 　
Line:26　 $< 는 확장자 규칙에서만 사용되며 사용되며 현재 타겟보다 최근에 변경된 종속 항목 중 하나로 대체된다. 아래에서 makefile 내부 매크로 관련 정보를 더 찾아볼 수 있다. 　 　http://haneul0318.springnote.com/pages/14554?print=1

Line:34　 모든 파일의 의존성리스트를 만든다.
Line:36　depend파일을 include하도록 하였으므로 이 Makefile이 불릴때마다 depend target에 자동으로 실행된다. 이때 obj디렉토리에 depend 파일이 만들어지며, 이 파일은 Makefile의 일부로 간주되게 된다. 이 파일로 인하여, 최근에 수정된 c파일이 자동으로 새로 컴파일 되며, h파일의 경우 해당 h파일을 사용하는 모든 c파일이 다시 컴파일 되게 된다. 하지만 변경되지 않은 파일들은 새로 컴파일 되지 않아 매번 모든 파일을 새로 컴파일하는 수고를 덜 수 있다. 명령문 앞에 "-"를 붙이면 오류발생시 무시하고 나머지 명령을 계속 진행한다. "-"가 없을 경우에는 오류 발생시 make가 중단된다.

아래는 위 메이크 파일 실행시 결과이다.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

dooeui@dooeui-laptop:~/test$ make
cd ./obj && make
make[1]: Entering directory `/home/dooeui/test/obj'
gcc -O2 -I../include -c ../srcdir1/file1.c -o file1.o
gcc -O2 -I../include -c ../srcdir1/main.c -o main.o
gcc -O2 -I../include -c ../srcdir2/file2.c -o file2.o
gcc file1.o main.o file2.o -otestapp
mv testapp ../
make[1]: Leaving directory `/home/dooeui/test/obj'

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Makefile관련 추가 정보는 아래에서 찾을 수 있다.

　　http://wiki.kldp.org/KoreanDoc/html/GNU-Make/GNU-Make.html#toc1

도서 중에서 make에 관련 사용법을 속시원히 설명한 책은 "유닉스-리눅스 프로그래밍 필수 유틸리티"- 한빛 미디어를 추천한다.

안드로이드 시작하기

임베디드 개발 플래폼의 대세가 안드로이드가 될 것임을 너무 늦게 - 모두가 다 알아챈 후에 - 깨닫게 되었다. 늦었지만 지금이라도 시작하지 않으면 곤란해질 것임을 느끼면서, 일단 안드로이드 이미지 빌드부터 시도해 보기로 한다.

1. 리눅스 설치

안드로이드 커널 컴파일을 위해서 노트북에 우분투를 설치하여 시도하기로 한다. 마침 ubuntu 9.10 iso 파일이 있으므로, VirtualBox에 우분투 9.10을 아래와 같이 설치한다. 안드로이드 커널 컴파일에 시간이 오래 걸리고 꽤 많은 용량이 필요하다고 하므로, 메모리와 하드 디스크를 넉넉하게 할당하였다.

호스트 컴퓨터는 Windows7-64bit-Pro 이다.
- Memory : 2G
- HardDisk : 25G

2. 커널 컴파일 따라하기

일단 아는게 없으므로, 인터넷을 찾아본다. 일단은 아래 국내 사이트에서 정보를 조금 얻을 수 있었다.
http://www.kandroid.org/
http://forum.falinux.com/zbxe/
http://www.androidpub.com/

하지만, 빌드는 공식 사이트를 참고한다.
http://source.android.com/download

영어라 편하지는 않지만, 구글이 제공하는 동영상과 슬라이드 자료에서 가장 정확하고 많은 정보를 얻을 수 있었다.
http://source.android.com/documentation

특히 Anatomy & Physiology of an Android 동영상 및 강연 자료가 나의 궁금증을 가장 속 시원히 풀어주었다.

만일 플래폼 빌드보다 안드로이드 어플리케이션에 더 관심이 많다면 아래 사이트를 참조하자.
http://developer.android.com/

아래는 이미지 빌드를 시도하면서 얻은 몇가지 정보 사항이다.
- JDK 5.0 update 12 or higher가 필요하다. 하지만 JDK 6.0은 지원하지 않는다.
- 15G HDD, 512MByte에서도 빌드에 성공하였다.
- .bashrc에 아래와 같이 path를 지정(Repo를 설치한 디렉토리에 대한 path임)
export PATH="~/bin:$PATH"

가장 큰 문제는 apt-get install시 sun-java5-jdk 패키지를 찾지 못하는 것었다.
JDK 5.0을 수동으로 설치할 수도 있겠지만, 아래 사이트에서 쉬운 해결책을 찾을 수 있었다.
http://www.androidpub.com/android_porting_info/38814

간단히 설명하면,
1. /etc/apt/sources.list에 아래 두줄을 추가.
deb http://us.archive.ubuntu.com/ubuntu/ jaunty multiverse
deb http://us.archive.ubuntu.com/ubuntu/ jaunty-updates multiverse
2. sudo apt-get update 실행
3. sudo apt-get sun-java5-jdk 실행

그 외에는 큰 문제 없이 빌드가 성공!!!

일단 첫 발에 의미를...

참고:
만약 java 1.6와 java1.5를 모두 설치하였다면 아래 명령으로 java 1.5를 사용하도록 지정할 수 있다.

sudo update-java-alternatives -s java-1.5.0-sun

Priority Inversion Protection

우선순위가 낮은 테스크가 소유한 자원을 우선순위가 높은 자원이 요청할 경우 대부분의 최신 OS는 우선순위 상속을 사용하여 문제를 해결한다. 우선순위 상속이 발생 시 낮은 우선순위 테스크의 우선순위가 높아지므로, 또다른 우선순위 역전이 발생할 수 있음을 주의해야 한다.

예를들어 flash driver에서 우선순위 상속이 발생하여 flash recalim등과 같이 CPU를 오래 소모하는 작업의 우선순위가 상승할 경우, 예기치 못한 우선순위 역전이 발생할 수 있다. flash reclaim자체는 write 작업에서만 발생하지만, 우선순위가 높은 task에서 요청한 flash read가 낮은 우선순위 task의 flash reclaim으로 지체 될 경우, OS는 priority inheritance로 이를 해결하려 하고, 이 때문에 flash reclaim이 높은 우선순위에서 실행되어, 예기치 못하게 오랜 시간동안 다른 테스크들의 실행을 막을 수 있는 것이다.

이와 같은 경우를 고려하여 우선순위 역전이 발생하지 않도록 appliacation들의 우선순위를 조절하고, flash driver의 서비스 처리 테스크 수를 늘려, 동시 접근에 대한 처리를 가능하도록 하여 문제를 해결할 수 있다.

Shell과 Makefile에서 PATH수정하기

PATH 앞 혹은 뒤쪽에 다른 PATH를 추가하고자 할때 아래와 같이 하면 된다.

Shell에서는...

export PATH=/added_path:$PATH

Makefile에서는...

TEMP=/added_path:$(PATH)
PATH:=$(TEMP)# :=를 사용해서 $(PATH)가 recusive하게 해석되지 않도록 함.
PATH=$(TEMP) # 이렇게 하면 error, $(PATH)가 recusive하게 해석됨.

혹은

PATH=/added_path:$(PATH) #이렇게 해도 상관 없음
PATH:=/added_path:$(PATH)

Makefile에서 매크로를 참조할때는 꼭 괄호를 사용할 것.
Shell에서는 괄호가 없어도 됨.

Ubuntu의 apt-get 명령어 정리

http://blog.outsider.ne.kr/346#

State Patten을 C로 짜려면?

C에서는 상속을 사용하지 못하지만, 그렇다고 State Patten을 구현하지 못하는 것은 아니다. 아래와 같은 구현으로 C에서 State Patten의 장점을 사용할 수 있을 것 같다. C에서는 인터페이스나 상속이 지원되지 않으므로 function table을 사용하여 이벤트 발생시 각 상태별 실행 함수를 지정하도록 하였다. 사실상 이 function table이 구현의 핵심으로, 상태 변경을 발생시키는 이벤트가 추가 할 때마다, 모든 function table의 해당 함수에 대한 함수 포인터 혹은 null function pointer를 추가해야 한다. 바로 이 부분이 상속과 가상 함수를 지원하지 못하는 C에서 State Pattern을 구현할 때 발생하는 불편함이기는 하지만 여전히 State Pattern의 장점을 그대로 누릴 수 있다. 또한 (당연히) 동일 방법을 사용하여 Strategy Pattern 역시 구현 가능하다.

아래 예에서는 구현을 단순화하기 위해서 상태는 ON/OFF두가지 상태만을 가정하였고, 'n' 입력시 ON상태로, 'f' 입력시 OFF상태로 상태 천이를 하도록 하였다.

#include <stdio.h>

/**********************************************************************
*
* 1. Type defination for Power State management
*
**********************************************************************/

typedef enum {ON,OFF} PowerState;

typedef struct
{
　　PowerState currPS;
　　void (*on_received_fptr)(struct PwrState **ps );
　　void (*off_received_fptr)(struct PwrState **ps );
}PwrState;

/**********************************************************************
*
* 2. Function table for each State.
*
**********************************************************************/
//Prefix ON/OFF means current status when these functions are called.
void ON_off_received(PwrState **ps );
void OFF_on_received(PwrState **ps );
void null_func(PwrState **ps);

//C에서는 가상 함수를 사용할 수 없기 때문에, 아래와 같은 각 상태별
//함수 테이블을 별도로 유지해야 한다.
PwrState psON= {ON, 　　null_func, 　　　　　ON_off_received};
PwrState psOFF={OFF, 　OFF_on_received, 　null_func};


void ON_off_received(PwrState **ps)
{
　　printf("Currnt State =%d : 0:ON 1:OFF \n",(int)(*ps)->currPS);
　　printf("%s is called\n",__func__);

　　printf("change curr power state from ON to OFF\n");
　　*ps=&psOFF;
}

void OFF_on_received(PwrState **ps)
{
　　printf("Currnt State =%d : 0:ON 1:OFF \n",(int)(*ps)->currPS);
　　printf("%s is called\n",__func__);

　　printf("change curr power state from OFF to ON\n");
　　*ps=&psON;
}

void null_func(PwrState **ps){}

int main(void)
{
　　char keyin;
　　PwrState *ps=&psOFF;

　　printf("Current power state is OFF\n");
　　printf("type \'n\' to change power state to ON\n");
　　printf("type \'f\' to change power state to OFF\n");

　　while(1)
　　{
　　　　keyin = getchar();

　　　　switch(keyin)
　　　　{
　　　　　　case 'n':// change state to ON
　　　　　　　　ps->on_received_fptr(&ps);
　　　　　　　　break;
　　　　　　case 'f':// change state to OFF
　　　　　　　　ps->off_received_fptr(&ps);
　　　　　　　　break;
　　　　　　default:
　　　　　　　　break;
　　　　}
　　}
}

원하는 폴더에서 마우스 오른쪽 버튼으로 커맨드 창 열기

아래 내용을 filename.reg로 저장한 후 실행하면 레지스트리에 해당 내용이 추가되며, 추가된 이후 실행된 탐색기에서는 특정 폴더에서 마우스 오른쪽 버튼 클릭시 뜨는 팝업 메뉴에 "Dos Prompt(Z)"가 추가된다. &Z는 팝업메뉴에서의 단축키를 Z로 지정한 것이며, "Dos Prompt" 대신 원하는 문자열을 사용할 수 있다.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\shell\OpenNew]@="Dos Prompr t(&Z)"
[HKEY_CLASSES_ROOT\Directory\shell\OpenNew\Command]@="cmd.exe /k"


아래 블로그에서 관련 내용을 포함한 추가 정보를 얻을 수 있습니다.
http://youngsam.kr/