'Embedded' 카테고리의 다른 글
[MIPS] Assembler 코드 살펴보기 (0) | 2009.12.26 |
---|---|
Fedora 메일서버 세팅 (2) | 2009.12.21 |
MPEG 1/2 Reference Site (0) | 2009.12.13 |
Eclipse + eCOS =?? (0) | 2009.11.23 |
H.264 SVC 참고 사이트 입니다. (0) | 2009.07.04 |
[MIPS] Assembler 코드 살펴보기 (0) | 2009.12.26 |
---|---|
Fedora 메일서버 세팅 (2) | 2009.12.21 |
MPEG 1/2 Reference Site (0) | 2009.12.13 |
Eclipse + eCOS =?? (0) | 2009.11.23 |
H.264 SVC 참고 사이트 입니다. (0) | 2009.07.04 |
Fedora 메일서버 세팅 (2) | 2009.12.21 |
---|---|
[MIPS] Simulator (0) | 2009.12.20 |
Eclipse + eCOS =?? (0) | 2009.11.23 |
H.264 SVC 참고 사이트 입니다. (0) | 2009.07.04 |
DM6467 Develop Board (2) | 2009.06.25 |
[MIPS] Simulator (0) | 2009.12.20 |
---|---|
MPEG 1/2 Reference Site (0) | 2009.12.13 |
H.264 SVC 참고 사이트 입니다. (0) | 2009.07.04 |
DM6467 Develop Board (2) | 2009.06.25 |
FFMPEG /X264를 MAC에서 빌드 (0) | 2009.06.14 |
MPEG 1/2 Reference Site (0) | 2009.12.13 |
---|---|
Eclipse + eCOS =?? (0) | 2009.11.23 |
DM6467 Develop Board (2) | 2009.06.25 |
FFMPEG /X264를 MAC에서 빌드 (0) | 2009.06.14 |
H.264 SVC 다운로드 커맨드 (0) | 2009.06.12 |
Eclipse + eCOS =?? (0) | 2009.11.23 |
---|---|
H.264 SVC 참고 사이트 입니다. (0) | 2009.07.04 |
FFMPEG /X264를 MAC에서 빌드 (0) | 2009.06.14 |
H.264 SVC 다운로드 커맨드 (0) | 2009.06.12 |
LVDS Owner’s Manual [3] (0) | 2009.05.16 |
FFMPEG /X264를 MAC에서 빌드
반드시 맥이 아니더라도 상관은 없을것 같습니다만,
홈페이지는 아래와 같습니다.
다운로드는 SVN으로 합니다.
svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg
그럼 열심히 다운로드가 됩니다.
빌드에 참고가 되는 페이지는 아래와 같습니다.
http://stephenjungels.com/jungels.net/articles/ffmpeg-howto.html
폴더에 들어가서
./configure
make
사용법은 쉽습니다.
./ffmpeg -s 4cif -i ../../TestStream/SOCCER_704x576_30_orig_02.yuv -b 2000k test_2M.avi
주의할 점은..
입력이 YUV이면, 파일에 대한 정보가 하나도 없으므로, 커맨드라인에서 옵션을 줍니다.
이때, 옵션은 입력 파일 이름보다 먼저 나와야 합니다.
이제 x264를 구합니다.
홈페이지는 다음과 같습니다.
http://www.videolan.org/developers/x264.html
다운로드는 다음과 같습니다.
git clone git://git.videolan.org/x264.git
빌드는 다음과 같습니다.
./configure
make
sudo make install
이러면 설치가 됩니다.
이제 ffmpeg으로 264 엔코딩을 수행하기로 합니다.
옵션 할 것도 많기 때문에 makefile로 스크립트를 만들어서 처리하면 쉽습니다.
makefile의 내용은 아래와 같습니다.
-----------------
# Options
# option for highprofile
options_hp=-vcodec libx264 -b 512k -flags +loop+mv4 -cmp 256 \
-partitions +parti4x4+parti8x8+partp4x4+partp8x8+partb8x8 \
-me_method hex -subq 7 -trellis 1 -refs 5 -bf 3 \
-flags2 +bpyramid+wpred+mixed_refs+dct8x8 -coder 1 -me_range 16 \
-g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -qmin 10\
-qmax 51 -qdiff 4
# Option for Baseprofile
options_bp=-vcodec libx264 -b 512k -flags +loop+mv4 -cmp 256 \
-partitions +parti4x4+parti8x8+partp4x4+partp8x8+partb8x8 \
-me_method hex -subq 7 -trellis 1 -refs 5 -bf 0 \
-flags2 +mixed_refs -coder 0 -me_range 16 \
-g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -qmin 10\
-qmax 51 -qdiff 4
# FFMPEG
FFMPEG = ./FFMPEG/ffmpeg/ffmpeg
# OUTPUT
OUTPUT = ./output
# Test Stream
ICE_704x576 = ./TestStream/ICE_704x576_30_orig_02_yuv/ICE_704x576_30_orig_02.yuv
####################################
all : ICE_264_HP ICE_264_BP
ICE_264_HP :
${FFMPEG} -s 4cif -y -i ${ICE_704x576} -an -pass 1 ${options_hp} ${OUTPUT}/ice_hp.h264
ICE_264_BP :
${FFMPEG} -s 4cif -y -i ${ICE_704x576} -an -pass 1 ${options_bp} ${OUTPUT}/ice_bp.h264
ffmpeg_help :
${FFMPEG} -h
-----------------
다만 실행하면 다음과 같은 오류가 발생합니다
Unknown encoder 'libx264'
찾아보면 아래의 페이지에서 해결책이 있습니다.
http://ffmpeg.arrozcru.org/forum/viewtopic.php?f=1&t=870
In order to have H264 encoding support in ffmpeg, should I build it with x264 lib ? (from http://www.videolan.org/developers/x264.html)
./configure --help | grep 264
--enable-libx264 enable H.264 encoding via x264 [default=no]
Is there built-in support for h264 encoding in ffmpeg source tree (just decode) ?
Building with configuration: --enable-shared --disable-static --enable-memalign-hack
요지는 옵션을 넣어서 컴파일을 해야 한다는 점입니다.
다시 ffmpeg을 빌드합니다.
make distclean
./configure --enable-libx264 --enable-shared --disable-static --enable-memalign-hack --enable-gpl
{
ibx264를 쓸려면 gpl을 enable시켜야 합니다. --enable-gpl
}
make
sudo make install
실행하면 다음과 같습니다.
Macintosh:JSVM kevinim$ make ICE_264_HP
./FFMPEG/ffmpeg/ffmpeg -s 4cif -y -i ./TestStream/ICE_704x576_30_orig_02_yuv/ICE_704x576_30_orig_02.yuv -an -pass 1 -vcodec libx264 -b 512k -flags +loop+mv4 -cmp 256 -partitions +parti4x4+parti8x8+partp4x4+partp8x8+partb8x8 -me_method hex -subq 7 -trellis 1 -refs 5 -bf 3 -flags2 +bpyramid+wpred+mixed_refs+dct8x8 -coder 1 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -qmin 10 -qmax 51 -qdiff 4 ice_hp.h264
FFmpeg version SVN-r19185, Copyright (c) 2000-2009 Fabrice Bellard, et al.
configuration: --enable-libx264 --enable-shared --disable-static --enable-memalign-hack --enable-gpl
libavutil 50. 3. 0 / 50. 3. 0
libavcodec 52.31. 2 / 52.31. 2
libavformat 52.34. 0 / 52.34. 0
libavdevice 52. 2. 0 / 52. 2. 0
libswscale 0. 7. 1 / 0. 7. 1
built on Jun 14 2009 08:57:59, gcc: 4.0.1 (Apple Inc. build 5490)
Input #0, rawvideo, from './TestStream/ICE_704x576_30_orig_02_yuv/ICE_704x576_30_orig_02.yuv':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0.0: Video: rawvideo, yuv420p, 704x576, 25 tbr, 25 tbn, 25 tbc
[libx264 @ 0x1805410]using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
[libx264 @ 0x1805410]profile High, level 3.0
Output #0, h264, to 'ice_hp.h264':
Stream #0.0: Video: libx264, yuv420p, 704x576, q=10-51, pass 1, 512 kb/s, 90k tbn, 25 tbc
Stream mapping:
Stream #0.0 -> #0.0
Press [q] to stop encoding
frame= 240 fps= 16 q=-11214781.0 Lsize= 613kB time=9.52 bitrate= 527.1kbits/s
video:613kB audio:0kB global headers:0kB muxing overhead 0.000000%
[libx264 @ 0x1805410]slice I:1 Avg QP:35.73 size: 5288
[libx264 @ 0x1805410]slice P:60 Avg QP:29.56 size: 4813
[libx264 @ 0x1805410]slice B:179 Avg QP:32.34 size: 1858
[libx264 @ 0x1805410]consecutive B-frames: 0.0% 0.0% 1.3% 98.7%
[libx264 @ 0x1805410]mb I I16..4: 33.3% 52.3% 14.5%
[libx264 @ 0x1805410]mb P I16..4: 1.3% 3.8% 2.6% P16..4: 31.2% 7.3% 4.7% 0.2% 0.2% skip:48.8%
[libx264 @ 0x1805410]mb B I16..4: 0.0% 0.2% 0.2% B16..8: 40.0% 1.3% 2.0% direct: 0.9% skip:55.4% L0:44.1% L1:53.4% BI: 2.5%
[libx264 @ 0x1805410]final ratefactor: 27.11
[libx264 @ 0x1805410]8x8 transform intra:50.4% inter:72.3%
[libx264 @ 0x1805410]coded y,uvDC,uvAC intra:48.7% 36.2% 12.9% inter:6.7% 3.0% 0.2%
[libx264 @ 0x1805410]ref P L0 61.8% 16.3% 9.4% 5.3% 7.2%
[libx264 @ 0x1805410]ref B L0 83.4% 10.4% 4.4% 1.8%
[libx264 @ 0x1805410]ref B L1 93.3% 6.7%
[libx264 @ 0x1805410]SSIM Mean Y:0.9466668
[libx264 @ 0x1805410]kb/s:522.2
이상 없이 동작합니다.
결과는 아래와 같습니다.
-끝-
H.264 SVC 참고 사이트 입니다. (0) | 2009.07.04 |
---|---|
DM6467 Develop Board (2) | 2009.06.25 |
H.264 SVC 다운로드 커맨드 (0) | 2009.06.12 |
LVDS Owner’s Manual [3] (0) | 2009.05.16 |
LVDS Owner’s Manual [2] (0) | 2009.05.15 |
cvs -d :pserver:jvtuser:jvt.Amd.2@garcon.ient.rwth-aachen.de:/cvs/jvt login
cvs -d :pserver:jvtuser@garcon.ient.rwth-aachen.de:/cvs/jvt checkout jsvm
DM6467 Develop Board (2) | 2009.06.25 |
---|---|
FFMPEG /X264를 MAC에서 빌드 (0) | 2009.06.14 |
LVDS Owner’s Manual [3] (0) | 2009.05.16 |
LVDS Owner’s Manual [2] (0) | 2009.05.15 |
LVDS Owner’s Manual [1] (0) | 2009.05.14 |
SerDes : 약자는 Serializer , Deserializer 입니다.
당근 병렬을 직렬로, 직렬을 병렬로 전송하거나 수신하는 방식을 말합니다.
SerDes 디바이스는 어플리케이션 용도에 따라서 몇개의 아키텍쳐로 나눌 수 있습니다.
이 방식은 Data-Address Control 등이 병렬로 된 것을 직렬화 시키는데 사용된다. 예를 들면 PCI 버스나,
UTOPIA 같은 병렬 버스 규격을 직렬화 할때 사용한다.
전체 버스를 하나의 멀티 플렉서에서 직렬화시키지 않고 Parallel Clock SerDes 아키텍쳐는 n-to-1 멀티플렉서 구조로 만들어진다.
각각의 멀티플렉서는 적당수의 채널을 받아서 직렬화 시켜서 보내는 것이다.
위의 그림은 7:1 멀티플렉싱을 사용하여 Parallel Clock SerDes로 구성하는 것을 보여주는 그림입니다.
여기서 수신단은 클럭을 이용하여 데이터를 복원해야 하므로 패러럴 포트와 직렬화 구간 및 수신 구간에서 클럭 스큐등에
조심해야 합니다.
클럭을 사용하지 않고 전송 데이터 시그널 선에서 특정 조건을 만족시키는 시그널을 클럭의 시작 기준점으로 보고
동조를 맞추어서 데이터를 얻는 방식입니다.
위의 그림처럼 원래 하나가 1이면 하나가 0이 되는 데이터 전송 방식에서 클럭의 시작/끝 부분에서 두개 모두 동시에 0으로 간후
1로 가면 그 시점을 클럭의 시작 시점으로 잡고 운용하는 방식입니다.
이 방식은 별도의 클럭을 위한 라인이 필요 없다는 점이 장점입니다.
또한가지 장점은 받으시 2:1 혹은 8:1 처럼 정해진 Multiplxer등이 필요 없다는 점입니다.
클럭 구간 안에서 데이터를 전송하기 떄문에 또다른 이름으로는 Start Stop bit SerDes 로 불리운다.
파워가들어오면 Deserializer는 자동적으로, 클럭을 찾아서 동기를 맞추어야 한다. 일단 동기가 맞게 클럭이 세팅되면,
입력 스트림에서 데이터를 꺼낼 수 있다. 이렇게 데이터를 락킹시키는 과정을 lock to random data 라고 부른다.
이러한 방식은 수신기가 시스템의 콘트롤 범위 내에 들어오지 않는 상황일 경우 유용하다.
리시버는 데이터 라인에서 클럭 라인을 동기를 맞추고 세팅을 맞추는 방식이므로 클럭라인과 데이터라인 사이의 지터 등을
고민할 필요가 없고, 트랜스미터에서 이러한 부분을 고려하여 전송할 필요가 없기 때문입니다.
이 방식은 8b의 데이터를 10b의 데이터로 전송하고 그 역으로 받아서 병렬로 8비트의 데이터를 만드는 방식입니다
10b의 코드는 IBM에서 1980년대 초기에 개발한 것이었다. 이것은 거의 매 사이클마다 Transition이 발생되도록 구성된 방식입니다.
이렇게 함으로서 가능한것은 수신단에서 데이터 스트림에서 클럭에 대한 동기를 찾아낼 수 있다는 점입니다.
수신기가 정확한 동기를 맞추기 위해서 트랜스미터는 경계를 표시하는 마커를 보냅니다. 이것을 Comma Character라고 부릅니다.
이것은 일반 데이터에서 절대 나타나지않는 비트 패턴을 가지고 있으습니다.
이 방식은 외부 레퍼런스 클럭을 가지고 있기 떄문에 지터라던가 노이즈에 좀더 신경을 써야 하는 구조입니다.
이 구조는 2가지 단계로 구성됩니다.
FPGA에서 시그널을 느린 몇개의 LVDS로 붙입니다. 그리고 두번째 단계에서 하나의 고속의 LVDS로 만듭니다.
이런 방식이 내셔널에서 제공하는 LVDS 예제 보드인 스파르탄 3에 들어있습니다.
3.6 Application
Parallel Clock SerDes
이것은 전통적인 버스를 시리얼로 바꾸어 보내는 어플리케이션을 의미합니다.
따라서 “Virtual Ribbon Cable”이라고 부르기도 합니다.
저전력, 긴 전달거리, 저가격 , 낮은 노이즈 , EMI 등등의 장점을 제공합니다.
가격대 성능비로 괜찮기 떄문에 많은 데서 사용하고 있습니다.
칩셋에 따라서 21비트 , 28비트, 48 비트 등을 사용합니다.
위의 그림은 RACK에서 RACK으로 연결하는 것에 대한 그림입니다.
이 방식은 RAW 데이터와 컨트롤, 패리티, 프레임 , 싱크 , Status등을 동시에 보낼때 어울리는 방식입니다.
위의 그림은 그에 대한 예제로서 데이터 외에 제어에 필요한 정보 예를들어서 패리티라던가 프레임 정보등을 함께 보내는 방식입니다.
이러한 방식에 8b/10b SerDes를 쓰는 것은 좀더 복잡한 상황이 됩니다. 즉 컨트롤 정보가 8비트 (1 바이이트) 단위로 정렬되지 않을 경우
기다렸다가 채워 보내는 방식으로 구현되는데 이러한 부분이 시간이나 컨트롤을 복잡하게 하는 부분이 될 수 있기 때문이다.
{
그냥 남는 비트 영역은 0을 채워서 보내면 될텐데 굳이 이런 이유를 대는 이유는 명확치가 않네요
}
Embedded clock bits SerDes는 수신기가 자동으로 random data를 Lock 시키는 기능을 가지고 있다는 점이다.
따라서, 수신기의 제어권이 송신기에 있지 않는 경우에 아주 적합한 방식이 된다. 또한 하나의 송신기에서 복수의 수신기로 들어가는 구조에서도 유용하다. 이러한 방식을 Broadcast라고 부르고 이런 경우에 Hot Insertion이라고 하여서 통신중에 새로운 통신 모듈이 버스에 삽입되어서 동작하는 기능을 구현할 수 있다. 즉 송신 블럭은 계속 데이터를 전송하고, 수신 블럭에서 클럭 동기를 맞추어서 데이터를 수신하는데 이때 새로운 수신 블럭이 삽입된다면 보통 송신 블럭이 데이터 송신을 중지하고 새로운 수신 블럭이 완전히 자리 잡은 뒤에 송신을 재개하는데 이럴 필요가 없이 끊김이 없이 계속 송신 블럭이 송신하여도 새로운 수신 블럭은 클럭의 동기를 맞추고 데이터를 가지고 갈 수 있는 기능이되는 것이다.
Embedded clock bits SerDes는 바이트 단위로 끊어지지 않는 어플리케이션에도 잘 어울린다. 이런 방식으로는 raw data + control data를 전송하는 경우가 그에 해당한다.
이 방식은 바이트 단위의 데이터 전송을 하는 것에 잘 들어맞는 방식이다.
이 방식에서 최대 코드 길이는 5비트가 된다. 따라서, 1GHz의 통신방식에서 첫번째 harmonic frequency 는 1G와 1G/5 = 200MHz 이다.
또한 이 방식은 전송하는 0과 1의 총 합이 같게 설계되어 있어서 평균 DC값에 맞추도록 설계되어 있다.
이렇게 DC에 맞추어지는 코딩을 DC-balance coding이라고 하고, 이러한 방식은 광통신이나 AC-coupled 환경에서 신뢰성을 높일 수 있는 방식이다.
이것이 8b/10b SerDes의 최대 이점이다. 게다가 이런 방식은 Inter Symbol Interference를 줄이고, cable drive capability를 높일 수 있는 방식이다.
FPGA와 연결하여서 고속 데이터 전송을 할 경우에 적합한 방식이다.
Deserializer는 드러오는 데이터에서 외부 참조 클럭이나 콤마 캐릭터가 없이도 자동적으로 락을 시킬 수 있다. 이런 기능으로 인해서
SerDes가 비 바이트 단위 시스템에서 잘 어울린다고 볼 수 있다.
각 방식의 비교 테이블은 아래와 같다.
FFMPEG /X264를 MAC에서 빌드 (0) | 2009.06.14 |
---|---|
H.264 SVC 다운로드 커맨드 (0) | 2009.06.12 |
LVDS Owner’s Manual [2] (0) | 2009.05.15 |
LVDS Owner’s Manual [1] (0) | 2009.05.14 |
인텔 컴파일러 최적화 기능 테스트 (0) | 2009.03.23 |
[2] LVDS Owner’s Manual
2장에서는 네트워크 연결 방식에 대해서 정리하고 있습니다.
1. Point-to-Point
제일 기본적인 방식인 1:1 방식입니다.
LVDS, CML , LVPECL등이 이 방식에 기준하여 움직입니다.
2. Multipoint/Multidrop
이 방식은 시그널 라인에 복수개의 드라이버 혹은 리시버를 가지고 있는 방식입니다.
위의 그림은 하나의 트랜시버에 3개의 리시버를 가지고 있는 방식입니다.
또다른 방법은 단방향이 아닌 양방향을 구성하는 것입니다.
즉 하나의 채널에서 상호간에 번갈아 가면서 송신과 수신을 반복하는 역활을 합니다.
이러한 방식의 가장 큰 문제점은 당연히 임피던스가 잘 맞지 않는다는 점입니다.
이를 위해서 LVDS가 멀티포인트 용으로 최적화시킨 것이 바로 BUS-LVDS , Multipoint-LVDS (M-LVDS)등의 규격으로
만들어 놓았습니다.
B-LVDS는 LVDS보다 높은 10mA의 전류를 가지고 구동합니다. 대신에 스위칭 에지에서 전환이 약간 느립니다.
주요 용도는 백플래인과 같은 어플리케이션에 적합하며 최대 32 Load까지 지원합니다.
EDGE-RATE를 컨트롤해서 멀티 드롭 환경에서 reflection을 줄일 수 있도록 해줍니다.
이런 이유로 대개 B-LVDS는 1Gbps 보다 낮은 데이터 전송율을 가집니다. 32 load를 가질 경우 약 250Mbps를 가지게 됩니다.
H.264 SVC 다운로드 커맨드 (0) | 2009.06.12 |
---|---|
LVDS Owner’s Manual [3] (0) | 2009.05.16 |
LVDS Owner’s Manual [1] (0) | 2009.05.14 |
인텔 컴파일러 최적화 기능 테스트 (0) | 2009.03.23 |
EISC 코드를 맥에 컴파일 하기 (2) | 2009.01.16 |
LVDS Owner’s Manual
이것은 national 사에서 만든 문서입니다.
최근에 LVDS를 공부할 필요가 있어서 간략하게 정리하였습니다.
문서의 내용은 LVDS 관련한 여러가지 내용을 10개의 장으로 나누어서 정리하고 있습니다.
표 1.1에서 보는 바와 같이 다양한 고속 Differential Signaling 기술이 존재합니다
여기에서 LVDS와 M-LVDS가 표준으로 정의되어 있고 다른 넘들은 표준으로 정의되어 있지는 않지만
산업계에서 많이 사용하고 있습니다.
이런 방식을 쓰는 이점은
1) 노이즈에 대한 무결성이 강화되고
2) 스위칭에 따른 노이즈 생성이 감소한다.
는 점입니다.
위의 그림은 트랜시버와 리시버 쌍을 보여주고 있습니다.
드라이버에서 3.5mA를 흘리고 이것이 100옴의 저항과 등가의 회로로 흘러가기 때문에 결과적으로는
350mV가 수신단에서 나타납니다.
리시버는 100mV의 threshold전압을 가지고 있고 이것에 의해서 0~2.4V 스윙하는 것에 대해서 감지할 수 있도록
되어 있습니다.
그림 1-2에서 Differential Signaling을 보여주고 있습니다.
이러한 Differential Signaling의 장점은
1. 커런트 소스가 항상 ON되어 있고 다른 방향으로 라우팅되어 있으므로 스위칭시에 발생하는 스파이크와 같은 노이즈를
상쇠 주며, EMI의 주요 문제인 고 전류의 스위칭 흐름에서 발생하는 노이즈를 상쇠하여 줍니다.
2. 두개의 라인에 노이즈가 발생하는 것은 상화같에 같은 노이즈가 발생하므로 노이즈에 대한 무결성이 증가합니다.
위의 표에서 보면 대략적으로 3Gbps (정확히는 3.15Gbps)급까지 전송할 수 있습니다.
거리에 따라서 감소하고 있음을 알 수 있습니다.
최적의 기술을 선택하는 것은
- 요구되는 전송량/대역폭과
- 케이블 거리에 관련된 파라미터들
- 전력에 대한 예산 (가용 전력..)
- 네트웍 구성 방식 (점대점, 점대 다 등등..)
- 직렬이냐 병렬이냐 등등
- 클럭 또는 데이터 분산
- 산업 표준과의 호환성 준수 여부
등등입니다.
전력과 전송 속도의 상관 관계에 따른 그래프입니다.
그냥 눈으로 대충 보고 음.. 하면 알 수 있는 알기 쉬운 그래프입니다.
LVDS Owner’s Manual [3] (0) | 2009.05.16 |
---|---|
LVDS Owner’s Manual [2] (0) | 2009.05.15 |
인텔 컴파일러 최적화 기능 테스트 (0) | 2009.03.23 |
EISC 코드를 맥에 컴파일 하기 (2) | 2009.01.16 |
2008년 10가지 Embedded Design 컬럼 (0) | 2009.01.03 |