'임베디드'에 해당되는 글 4건

  1. 2009.08.14 컴파일에 대한 단상.
  2. 2009.08.14 Little Endian 과 Big Endian (1)
  3. 2008.01.26 임베디드 시스템2 (1)
  4. 2008.01.26 임베디드 시스템1 (1)

출처 : http://recipes.egloos.com/


프로세서는 많은 전기적 스위치로 이루어져 있으며, 어떤 특정한 전기 스위치를 작동 시키기 위해서는
데이터 버스 선을 따라 전압이 "있고 있고 없고 없고 없고 없고 없고 있고 있고"의 상태로 만들어 주면 된다라는 의미

자, 처음으로 Software에 입문하시는 분들은 Compile이라는 단어를 아주 자주 듣게 되는데요, Compile이라는 단어를 영어 사전에서 찾아보면 책을 편집하다, 안내서를 만들다 라는 뜻이에요. 그럼, Computer에게 안내서를 만든다는 것은 무엇을 의미하는 것이죠?

 

프로세서가 해석할 수 있는 것은 단지 명령어로서, 이 명령어는 "기계어"라고 불리 우는 특정 bit pattern을 말합니다. "Processor는 약속되어진 특정한 Bit Pattern에 반응한다."는 의미에서 특정 Bit Pattern을 명령어라고 부를 수 있습니다.

 

쉽게 말해 프로세서는 많은 전기적 스위치로 이루어져 있으며, 어떤 특정한 전기 스위치를 작동 시키기 위해서는 데이터 버스 선을 따라 전압이 "있고 있고 없고 없고 없고 없고 없고 있고 있고"의 상태로 만들어 주면 된다라는 의미와 일맥상통할 수 있을 것입니다.

 

예를 들어, Processor가 "11000001 10100000 101000 111011"라는 bit pattern (즉 16진수로는 C1 A0 28 3B 라는 32bit pattern)을 Register 1과 Register 2를 더해서 Register 1에 결과를 저장하라는 내용으로 약속을 한다면, Processor에게 Register 1과 Register 2를 더해서 Register 1에 결과를 저장하라고 일을 시키고 싶을 때는 11000001 10100000 101000 111011 의 32bit bit열을 Data Bus를 통하여 Processor에게 던져주면 Processor는 그 일을 실행하게 됩니다.  - 막상 이런 pattern을 해석하는 디지털 회로는 Decoder에요 우훗 -

 

 

 
 

프로그램이란 이런 일련의 기계어 명령의 순차적인 집합이며, 예전에는 이런 기계어 명령을 사람이 직접 Processor에게 입력시켜 주었었드랬습니다. 그러다 보니, 사람이 이런 이진수의 나열을 해석하기 쉽지 않으니까 - 이런 기계어 명령을 Native Code라고 부른다고 했었죠. -Assembly라는 개념을 도입하게 되었는데, Native Code(기계어)와 1:1 matching이 되는 그나마 사람이 보기 쉬운 표기 체제를 만들어 냈습니다. 예를 들어 Memory에 Data를 읽어 오는 "LDR R0,= 0xFF"를 bit pattern으로 분석했더니, 0x3CD1FF과 완전히 같은 말이며, 이것은 bit pattern으로는 1111001101000111111111이 되며, 이것들은 서로 완전히 1:1 대응이 되어 Assembly로 표현 되었을 때 사람이 보기에 훨씬 편하게 됩니다.

 

이런 이유로 인간은 bit pattern을 직접 입력하지 않고, Assembly로 coding을 하게 되었으며, 이를 Native Code(기계어)로 바꾸어 주는 것이 compile의 목적이었습니다. 그래서, 예전에는 인간이 직접 code표를 찾아서 기계어로 바꾸어주는 일을 했죠. 예전에 태어나지 않은 것이 천만 다행입니다. Compile을 손으로 직접 하다 보니, 성격을 많이 버리게 된 거죠. 인간은 귀찮은 일은 딱 질색으로 하는 인종인지라, 코드 표를 찾는 일을 대신 해주는 Assembler라는 것을 만들게 되었습니다. 그것이 compiler의 최초 태동입니다. 원래는 LDR R0,=0xFF 이런 명령어는 기계어에 존재치 않고, 1111001101000111111111 만 있었다는 얘기죠.

 

자, 그런데 이 Native Code(기계어), Assembler라는 것이 특정 Processor에만 통한다는 사실!. Processor는 약속 되어 진 특정한 Bit Pattern에 반응한다는 사실 때문에, Processor마다 다른 Assembler를 지원하므로 특정 Processor에 맞추어서 만들어진 프로그램은 다른 종류의 Processor에서는 동작하지 않는다는 문제점이 있었습니다. 흔히들 말하는 Compatibility 호환성에 한계를 드러냈는데, 서로 다른 Processor에 맞는 Assembly를 만들어내는 Compiler가 있었으면 좋겠다는 인간의 귀차니즘이 또 하나의 새로운 entity를 만들어 냅니다.

 

그것이 무엇이냐 하면, C나 C++같은 High Level Language compiler입니다. C같은 High Level Language로 Coding을 하고 나면, 내가 동작시키고자 하는 Processor에 맞는 C compiler를 이용해서 그 Processor에서 동작 가능한 Assembly를 generation하는 Compiler를 만들어 낸 것이지요. 여기에서 또 하나! 보통 사람들이 C가 이식 성이 좋다고 하는데, 이식 성이 좋다고 함은 많은 Processor들에 C Compiler가 제공된다는 말입니다. C 자체가 이식 성이 좋다고 하기는 쫌 그르치요~

 

결국 ARM core를 예를 든다면, C로 coding을 한 후, compile한다는 의미는 C compiler를 이용하여, ARM이 해석 할 수 있는 Assembly를 만들어 낸 후, ARM Assembler를 이용하여, ARM core가 해석할 수 있는 일련의 Bit pattern의 만들어 낸다고 할 수 있겠습니다.

 

이런 bit pattern을 한 덩어리 뭉쳐놓은 것을 흔히들 말하는 Executable binary image라고 합니다.

 

 

 
 

mnemonic : mnemonic은 사람의 기억을 돕기 위하여 사용되는 Symbol을 의미하는데, 결국 assembly는 기계어와 1:1로 matching되므로 Assembly 코드를 mnemonic이라고 불러도 무방합니다.

 

실은 중요한 것은 이렇게 메모리 안에 들어 있는 숫자들이 CPU가 가져다가 실행하면 명령어고, 수정하거나 고치면 데이터라는 사실이죠.

 

흔히들 cross compile 환경이라는 말을 많이 쓰는데, Cross Compile이란 실제 Target에서 돌아갈 binary image를 PC 상에서 compile 할 수 있게 해주는 환경을 말합니다. 흔해 PC에서 컴파일 한 것은 PC에서 실행하는 게 정상인데, embedded system에서는 target자체에서 컴파일을 수행하기에 너무 작은 시스템이며, 불편하기에 이런 환경을 만들어 binary image를 PC상에서 만들어 내는 거죠.

Posted by 행복한 프로그래머 궁금쟁이박

댓글을 달아 주세요


이제 꼼짝없이 임베디드 시스템을 공부해야 하게 되었습니다.

자료 찾기가 쉽지만은 않았는데 히언 님의 블로그에서 좋은 자료를 찾았습니다.

좋은 내용들 퍼다가 공부해야겠습니다.

출처 : http://recipes.egloos.com/

=================================================================================================================================================================


사람은 processor보다 위대한 존재이죠. 그러니까 형 (big)이고요,
processor는 동생 (little)입니다. - 걸리버 여행기 -

 

숫자로 가득 메워진 - 영화 메트릭스의 오프닝에 다다다다 올라가는 듯한 - 기계의 언어 세상에서 그 숫자들을 제대로 해석하려면 한 가지 익혀두어야 하는 법칙이 하나 있습니다. 메모리 영역이나, 기계어 영역의 숫자들을 제대로 이해하려면 꼭 알아둬야 하는 법칙이기도 합니다.

 

아래의 내용은 어디선가 주워 들은 얘기를 다시 한번 재미 삼아 들려 드릴 테니, 잘 들어보세요. 흥미진진합니다.

 

 

 

 

" 같은 일을 하는데 방법이 두 가지가 있다면, 아마도 두 개의 서로 다른 회사는 서로 다른 방법을 채용할 가능성이 다분할 것입니다.  머피의 법칙이기도 한 이런 가능성은 서로 다른 칩디자이너가 메모리에서 데이터를 서열화하는 방법에도 또한 마찬가지로 통용됩니다.  걸리버 여행기에 등장하는 소인국은 매우 작은 나라인데, 그에 걸맞게 사소한 정치적인 문제를 가지고 있었습니다.   Big-Endian당과 Little-Endian당이 격론을 벌이는데, 그 격론의 내용이라는 것이 반숙된 달걀을 깨고자 할 때, 뭉툭한 끝(Big-End)을 먼저 깰 것인가 아니면 뾰족한 끝(Litttle-End)부터 먼저 깰 것인가라는 것 이었습니다. 1980년 4월 1일, 대니 코헨(Danny Cohen)이 지금에서는 유명하게 된 "On Holy Wars and a Plea for Peace"라는 책에서  워드에서의 바이트 오더링(Byte Ordering in Words)에 대해 논하면서 '엔디안'이라는 용어를 이 문제를 지칭하는데 처음 사용했습니다. 그 후 곧바로 이 용어는 고착되었고, 엔디안 이라는 용어는 Byte Ordering을 의미하게 되었습니다.   유닉스 프로그래머는 "NUXI 문제"라고 부르기도 하는데, 바이트 오더링에 착오가 생기면 'UNIX"라는 단어의 입력에 대해 앞뒤가 뒤바뀌어 'NUXI'라는 출력이 나오니까 말입니다. " 재미있죠?


 

이 이야기에서부터 시작하면 모든 processor는 Little Endian 또는 Big Endian중 하나를 사용하게 되는데, 이는 무엇을 의미하는 걸까요? 이것은 processor가 memory에 저장하는 방식을 의미하는데, 저장 방식이 다를 뿐이죠. 이 방식을 이해하지 못하면, 디버깅 시에 오류에 빠질 수가 있으니 꼭 이해해야 하는 부분 임을 이해해 주세요. 당부.

아래 그림을 보면 이해가 확실히 될 것입니다..

자, 그럼 예를 들어 dword 0x12345678, word 0x1234, 또는 byte 0x12를 0x1000번지부터 저장하는 방식을 볼까요? 번지 하나에는 1byte가 들어갑니다요. (dword는 4byte, word는 2byte, byte는 8bit 크기로 다룰께요.)

                                    0x1000   0x1001   0x1002  0x1003
Big Endian     dword       0x12       0x34      0x56     0x78
                      word        0x12       0x34
                      byte         0x12     

Little Endian  dword       0x78       0x56      0x34     0x12
                      word        0x34       0x12
                      byte        0x12
  

자, 그림을 보니 확 느낌이 오죠?  - 라고 말했지만, 중요한 것은 Little Endian은 그 크기만큼 무조건 거꾸로 읽는다 가 힌트입니다. -

자, 그럼 Big Endian과 Littel Endian은 어떤 차이가 있을까요?

   쉽게 말해서 "Little Endian은 상위bit (MSB)를 상위 주소에 저장을 하고 있습니다요"가 힌트입니다. 네 그렇습니다. Little Endian으로 처리를 하게 되면, Processor는 Software에서 정해준 type 크기 만큼 그대로 읽어와서 처리를 하게 되고요,  Big Endian의 경우에는    대신 낮은 주소부터 읽어와서 MSB로 넣어주면 됩니다. (MSB가 LSB쪽으로 정렬되어 있으니까요, MSB와 LSB는 사족에!)
 
   dword type의 0x12345678을 저장하는 것을 다시 그림을 그려서 본다면 아래와 같습니다.

                                0x12345678
                                 MSB      LSB

                      Big Endian                Little Endian
0x1003                0x78                          0x12
0x1002                0x56                          0x34
0x1001                0x34                          0x56
0x1000                0x12                          0x78

   
사실 어느 게 더 좋다고 말하긴 어려우나, ARM의 경우에는 Little Endian을 지원하니, Little Endian의 경우를 잘 알아 두는 것이 좋겠지요?

근데, 또 재미난 사실이 하나 있습니다.
우리가 소프트웨어를 구성할 때 Little Endian이냐 Big Endian이냐를 compile환경에서 설졍 해 줄 수가 있습니다. 물론 ARM 환경의 Embedded system이라면, Little Endian으로 Memory의 내용을 인식하는 것이 Default이니까, Compile할 때는 Little Endian으로 option을 주고 compile해야겠지요?

컴파일 버전 중 사용하는 ads 의 Compile flag들을 에서 확인해 보면, 다음과 같은 구문을 확인할 수 있을 것입니다.

#-------------------------------------------------------------------------------
# Compiler code generation options
#-------------------------------------------------------------------------------

END = -littleend#               # Compile for little endian memory architecture
....... (생략) ..........
CODE = $(END)
....... (생략) .........


자, 어떤가요? 간단하죠? 교훈이 하나 있어요. 뭐냐하면, 다음과 같은 논리입니다. 사람은 processor보다 위대한 존재이죠. 그러니까 형 (big)이고요, processor는 동생 (little)입니다. 그런 의미에서면, 사람이 읽기 편하게 메모리에 저장되면 big endian, 사람이 읽기 불편하면 little endian이라고 기억해 두면 잘 기억되겠죠?

* 사족 : NUXI 문제를 word씩 읽는다고 가정했을 때, Little Endian으로 NUXI으로 저장되어 있다면, Little Endian으로 읽으면 (1 word = 2 bytes) UNIX가 되지만, 그대로 Big Endian으로 읽으면 NUXI가 됩니다. 마치 띄어쓰기를 잘 못해 아버지가 방에 들어가신다와 비슷한 꼴인 듯한 기분인데요. 

 

        

ARM에서는 어떻게 Big Endian/ Little Endian 지원하는가요?

        기왕 Little Endian과 Big Endian 얘기가 또 나왔으니까 하는 말입니다. ARM의 경우, Little, Big Endian을 모두 지원하는데, 이건 어떻게 결정하느냐, ARM core를 채용해서 구현한 chip이 어떻게 생겼느냐에 따라 다릅니다. 보통은 외부에서 pin을 하나 설정해서 Low/ High로 Endain을 다르게 동작하게 만드는 것이 Alternative입니다만, chip에 따라서는 한가지만 지원하도록 아예 SoC를 하는 경우가 많습니다. 이런 설정에 따라서 compile을 할 때, Little, Big Endian을 제대로 setting해서 compile해줘야 합니다. 또는 이렇게 따로 설정하지 않은 경우에는 ARM은 default Little Endian이며, Co processor 레지스터 CP 15를 통해서 Big Endian으로 만들 수 있습니다.

 

 

 LSB와 MSB는 bit를 따질 때 높은 쪽 자리의 숫자이냐, 낮은 쪽 자리의 숫자이냐를 따질 때 쓰는 용어인데, 예를 들어, 8bit의 이진수가 10001000있다고 치면, 이때 맨 왼쪽 자리를 MSB (Most Significant Bit)라고 부르고요, 이 예에서는 1이 되겠죠. 그리고 맨 오른쪽 자리를 LSB (Least Significant Bit)라고 부르고요, 이 예에서는 0이 되겠네요. 그래서 상위 2bit를 지칭 할 때는 MSB 2bit이라고 하고 맨 왼쪽 두 자리 10이 되고요, 하위 3bit를 지칭 할 때는 LSB 3bit라고 부르고, 맨 오른쪽 세자리 000을 의미해요.

 

Posted by 행복한 프로그래머 궁금쟁이박

댓글을 달아 주세요

  1. 2010.05.07 10:28  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

임베디드 시스템에 쓰이는 운영체제 - 2 [INFO]Embedded

저 자 : 송인준



임베디드 시스템의 반대말은 범용 시스템?
임베디드 시스템을 어떤 특화된 목적을 위한 시스템으로 생각해 본다면 그 반대의 개념으로는 범용 시스템을 들 수 있습니다. 그렇다면 그 차이는 무엇일까요? 어떠한 개념을 확립하는데 있어서 그 반대되는 개념과의 차이를 명확히 구분짓는 것이 중요합니다.

시스템과 그 위에서 돌아가는 응용 프로그램의 관계를 설명하면서 두 개념을 풀이하면 범용 시스템은 응용 프로그램 자체가 시스템에게 맞추어 가는 것이고, 그에 반해 임베디드 시스템은 시스템이 응용 프로그램에게 맞추어 가는 것입니다. 이렇게 시스템이 응용 프로그램에게 맞추어가는 것을 Application Specific System이라고 합니다. 즉, 여러 가지 목적을 위한 범용 시스템은 하나의 시스템이 있고 그 위에서 수행될 응용 프로그램이 있고, 임베디드 시스템은 하나의 특화된 목적을 가진 응용 프로그램이 있고 그에 적합하게 시스템은 모습을 갖추는 것이 둘의 차이점이라 할 수 있습니다.

임베디드 시스템의 실시간 시스템적 특성
여러분에게 질문하겠습니다. 과연 임베디드 시스템은 운영체제일까요? 임베디드 운영체제(Embedded OS)는 무엇일까요?

임베디드 시스템은 단지 시스템일 뿐이지 운영체제는 아닙니다. 임베디드 운영체제는 임베디드 시스템을 구동하는 운영체제입니다. 그렇다면 임베디드 운영체제에는 무엇이 있을까요? 특정 시스템에 어떠한 운영체제가 쓰일지를 결정짓는 것은 그 시스템의 활용 의도입니다. 이 시스템이 과연 어느 목적으로 쓰일 것인지가 중요한 것이지요. 임베디드 시스템에도 여러 가지 목적이 있으므로 어떠한 운영체제를 사용할지는 각 시스템에 따라 다릅니다. 하지만 한 가지 공통점이 있는데, 대부분의 임베디드 시스템에서는 실시간 운영체제(Real-Time Operating System)를 주로 쓴다는 점입니다. 왜 실시간 운영체제가 임베디드 시스템에 주로 쓰이게 되는 것일까요.

예를 들어, 휴대폰을 가정해 보죠. 우리가 열심히 휴대폰으로 재밌는 고스톱 게임을 하고 있을 때, 중요한 전화가 왔다면 어떻게 해야할까요. 만약 범용 시스템에서 쓰이는 일반적인 운영체제였다면 전화가 오는 태스크는 프로세스 스케쥴링되어질 것입니다. 그렇다면 타임 퀀텀에 따라 언젠가는 전화가 오는 태스크가 CPU를 잡고 실행하게 될 것입니다. 하지만 이렇게 되면 중요한 전화를 놓치는 일이 빈번히 발생할 테죠. 하지만 실시간 운영체제의 스케쥴링은 타임 퀀텀을 나누는 것이 아니라, 우선순위 기반의 스케쥴링이기 때문에 우선순위가 높은 전화를 위한 프로세스가 CPU를 잡고 실행될 것입니다. 이렇게 대부분의 임베디드 시스템은 외부 반응에 즉각적인 응답을 해야 하는 게 대부분이기 때문에 주로 실시간 운영체제를 사용하는 것입니다. 이렇게 임베디드 시스템에는 실시간적 특성이 있습니다. 그러므로 대개의 임베디드 시스템에서는 실시간 운영체제를 사용합니다. 그렇다면 임베디드 시스템에 주로 사용되는 실시간 운영체제의 기본적인 개념들을 살펴보도록 합시다.

실시간 운영체제의 개념
실시간 운영체제를 정확히 정의하자면, 시간의 제한을 갖고 그 시간 제한 안에 정확한 결과를 내기 위한 시스템을 구동시키고 시스템을 위해 여러 가지 실시간 작업에 대한 스케쥴링 등의 일을 처리해주는 운영체제를 말합니다. 결국 실시간 시스템이 범용 시스템에 비해 충족해야 할 조건은 시간의 제한을 지켜야 한다는 점과 그 데드라인 안에 정확한 결과를 내주어야 한다는 점입니다. 만약 핵 발전소 같은 곳에서 임계온도를 넘어가면 위험한 상황일 때, 이에 대한 처리를 긴급히 또한 정확히 해주어야 겠지요.

잘 알려진 범용 운영체제인 리눅스를 이용하여 실시간 운영체제를 설명해 보겠습니다. 먼저 리눅스는 실시간 운영체제가 아닙니다. 리눅스는 시분할 시스템으로 설계되어 공정성에 기반한 스케쥴링 알고리즘을 사용합니다. 그러나 실시간 운영체제에서는 프로그램마다 우선순위가 고정되어 있으며, 그 우선순위를 기반으로 상대적으로 높은 우선순위의 작업이 실행될 준비가 되었다면 스케쥴러가 현재 수행중인 작업을 중단하고 높은 우선순위의 작업으로 전환될 수 있어야 합니다. 더욱이 리눅스 커널은 사용자 프로세스에 의해서 재진입이 가능하지도 않으며 다른 프로세스가 커널 모드에서 실행되고 있는 것을 끊고 실행되지도 않습니다. 커널의 자원을 이용하고 있는 프로세스가 있다면 그 프로세스가 대기상태로 가거나 종료하지 않는 이상 다른 프로세스들이 실행될 수 없습니다. 즉, 일정한 응답시간을 가져야 할 실시간 작업이 리눅스 커널 하에서 실행된다면, 최악의 경우 커널 내부의 코드를 실행하다가 응답시간을 넘길 수도 있다는 이야기입니다. 이러한 것은 엄격하게 말해 실시간적인 요구사항을 제대로 반영하지 못한다는 것입니다.

이러한 실시간 시스템은 두 가지 종류가 있습니다. 소프트 실시간 시스템(soft realtime system)과 하드 실시간 시스템(hard realtime system)이 있습니다. 전자는 데드라인을 어느 정도 넘겨도 무방한 시스템으로 동영상을 재생하는 시스템의 경우에 사람이 움직임을 인지하기 좋은 프레임인 초당 24 프레임을 지원해야 하지만 어느 정도 시간을 넘겨도 잠시 기분 나쁘고 마는 정도가 되겠죠. 하지만 후자의 경우는 앞서 예를 들었던 핵 발전 제어 시스템과 같이 긴급히 중단 명령을 내렸을 때 1/100초라도 오차가 생기면 안 되는 그러한 시간에 매우 엄격한 시스템을 말합니다. 다음의 <그림 1>은 이 두 가지 시스템과 데드라인의 관계를 보여주고 있습니다.


지금까지 임베디드 시스템의 제한적인 자원과 특화된 목적을 갖고, 실시간적인 특성을 갖는다는 특성을 살펴보았습니다. 그렇다면 이러한 각 특성을 충족시켜주는 운영체제의 디자인 이슈에는 어떠한 것들이 있는지 살펴보도록 하겠습니다.

운영체제의 디자인 이슈
앞에서도 잠깐 언급했던 부분이지만 임베디드 시스템에서 제한된 자원인 배터리, 즉 전력의 사용은 크게 고려하지 않을 수 없는 부분입니다. 같은 배터리를 가지고 어떻게 관리하느냐에 따라서 시스템의 작동 시간에 차이가 생기기 때문입니다. 또한 전력에 의한 발열량도 생각할 수 있는 문제입니다. 전력관리를 위한 지원에는 여러 가지가 있습니다. 먼저 회로적인 수준에서 지원하는 방법과 시스템 수준에서 지원하는 방법이 있습니다. 회로 수준에서 지원하는 방법에는 동적 전압 스케일링(dynamic voltage scaling)과 클럭 게이팅(clock gating) 등이 있으며, 시스템 수준에서 지원하는 방법은 하드웨어, 소프트웨어, 그리고 운영체제를 통해 이루어집니다. 그럼 회로 수준에서는 동적 전압 스케일링 방법, 그리고 시스템 수준에서 운영체제에 의한 방법을 살펴보도록 하겠습니다.

동적 전압 스케일링
동적 전압 스케일링에서는 장치가 활성화된 상태에서 에너지 소비 레벨과 성능 간에 조정을 하는 것입니다. 대부분의 시스템들은 끊임없이 최고 성능을 내도록 고안되어 있습니다. 그러나 이러한 설계는 전력관리에 민감한 임베디드 시스템에서는 에너지의 낭비를 일으키게 됩니다. 동적 전압 스케일링의 핵심은 사용자에게 에너지를 절약하면서 성능을 만족시키도록 하는 것입니다. 다음 두 수식은 에너지와 전압 그리고 프로세서의 클럭 주파수 간의 관계를 보여주는 것입니다.

여기서 Eop는 연산에 필요한 에너지이며 fmax는 프로세서의 최대 클럭 주파수가 되며 V는 연산에 사용되는 전압입니다. 이 수식에서 알 수 있듯이 전압은 에너지와 주파수에 영향을 줍니다. 즉, 어떠한 작업을 수행하는데 소비되는 에너지를 줄이려면 전압을 줄이는 방법을 생각할 수 있으며, 전압을 줄이면 CPU의 클럭 주파수도 감소하게 됩니다.

임베디드 시스템에 사용되는 트랜스메타 크루소나 인텔 StrongARM, XScale과 같은 프로세서들이나 IBM PowerPC 405LP 등의 프로세서들은 동적인 전압과 프로세서 코어의 주파수 스케일링이 가능하여 이러한 에너지 효율적인 전력관리를 지원하고 있습니다.

운영체제에 의한 동적인 전력 관리
동적인 전력 관리(dynamic power management)라는 것은 한마디로 말하면 시스템 컴포넌트들의 전력 상태를 변화시킴으로써 성능 제약조건인 에너지 소비를 낮추는 것입니다. 여기에서 상태 변화는 완전하게 에너지를 사용하는 활성화(active) 상태와 저전력 상태 간에 일어나게 됩니다. 예를 들어 eCos라는 임베디드 시스템에 사용되는 운영체제에는 다음과 같은 상태들이 있습니다.

① active 상태 : 시스템은 완전히 작동가능하며 전력 소비는 높은 수준이 될 것입니다.

② idle 상태 : 짧은 시간 간격 동안 조금 혹은 거의 활동이 없게 됩니다. 짧은 시간 간격이 어떻게 구성되는지를 결정하는 것은 정책 모듈에 달려있습니다만, 보통 1/10초 혹은 몇 초가 될 것입니다. idle 모드에 진입했을 때 가능한 동작은 전압을 조정하여 시스템 클럭 속도를 낮추는 것입니다. 그에 따라서 CPU에 의해 소모되는 전력이 줄어들 것입니다.

③ sleep : 시스템은 대략 수십 초 정도의 큰 시간 간격동안 운휴상태가 됩니다. 스크린 백라이트(screen backlight)와 같은 많은 양의 전력을 소모하는 모든 하드웨어들의 작동을 중단시키는 것이 바람직할 것입니다.

④ off : 시스템은 전력이 중단됩니다. 전력 소비는 최소화가 되어야 할 것입니다. 시스템을 되돌리기 위해서는 몇 가지 특별한 동작이 요구되는데, 그것은 특정 버튼을 누르는 것 등이 될 것입니다.

이렇게 주어지는 상태들을 바꾸도록 명령을 주거나 시스템에서 전력 소비에 관련된 정보들을 수집하는 구성요소로서 전력 관리자(power manager)가 존재합니다. 전력 관리자는 시스템을 관찰하며 실행 시간에 반응하게 되는데, 전력 관리자가 내리는 결정들은 전력 관리 정책에 근거하게 됩니다. 전력 관리 정책은 시스템을 관찰하는 방법과 명령을 내리는 방법들을 제어하는 법률과도 같은 것입니다. 여기서 운영체제가 개입하는 이유는 운영체제는 시스템 상에 이루어지는 작업(task)이 수행 중인지 아니면 대기 상태인지를 알 수 있기 때문에 동적 전력 관리를 위한 정책 결정을 내릴 수 있기 때문입니다. 이러한 동적 전력 관리 기술은 크게 2가지로 나눠볼 수 있습니다. 첫 번째는 예측적인 방법이고 두 번째는 통계적인 제어 방법입니다.

예측적인 방법이란 말 그대로 idle 상태를 예측하여 미리 idle 상태로 바꾸어 상태 전환에 따른 지연시간을 줄이고자 하는 것이며, 주로 예측 정확도가 관건이 됩니다. 예측적인 방법에는 시간 경계 값(타임아웃)을 두어 일정 시간이 지나면 저전력 상태로 바꾸어 버리는 타임아웃에 근거한 방법과 과거 활성 및 비활성 상태의 정보를 기록하여 그것을 근거로 상태 변화를 예측하는 방법 등이 있습니다.

통계적인 제어 방법은 어떠한 사건이 일어나는 것을 정확히 예측하는 것은 본래 불가능하다는 가정 하에서 불확실성을 내포하는 추상화된 시스템 모델을 만들어 확률에 기초한 통계적 결정을 내리게 됩니다. 이러한 방법에는 통계에서 흔히 사용되는 마코프 체인(Markov Chain)을 이용하여 시스템과 시스템의 외부 환경을 모델링하는 CMP(Controlled Markov Process)라는 방법이 있습니다. 모델링을 통해 얻을 수 있는 이점은 전력 소비 함수를 최소화하고 성능 제약 조건을 충족시킬 수 있는 정책 P를 찾아내는 것입니다.

저장 매체의 한계를 극복한다
임베디드 시스템의 또 다른 특징으로 예를 들었던 저장 매체의 제한은 운영체제의 입장에서 상당히 까다로운 점입니다. 대개의 임베디드 시스템은 크기의 제약으로 하드디스크와 같은 장치를 사용할 수 없습니다. PDA 안에 하드디스크를 넣을 만한 공간이 있다면 크기가 얼마나 커질까요? 물론 플래시 롬과 같은 장치들을 사용할 수 있지만 근본적인 제약을 막지는 못합니다. 따라서 임베디드 시스템을 위한 운영체제는 그 크기도 매우 작을 뿐만 아니라 몇 가지 구조적인 변화를 겪고 있습니다.

메모리 구조의 변화
임베디드 시스템에 사용되는 메모리의 크기는 매우 작습니다. 기존의 PC나 유닉스 서버급에서 사용되던 운영체제는 효율적인 메모리 관리를 위해서 메모리 구조가 상당히 복잡하게 되어 있습니다. 실제 운영체제에서 사용되는 메모리 관리 구조는 세그먼테이션과 페이징을 비롯해서 각 페이지와 세그먼트마다 다른 종류의 프로텍션 모드를 가지고 있고, 이러한 전체 구조가 응용 프로그램마다 따로 관리되고 있습니다. 메모리 가격의 지속적인 인하는 대규모의 메모리를 장착하는 시스템을 만들게 되고 메모리의 제한이 급격하게 줄어들면서 메모리의 효율적인 사용보다는 안정적인 시스템을 구축하는데 더 큰 목적을 두게 된 것이었지요. 물론 이를 지원하기 위한 프로세서의 설계와 디자인도 큰 영향을 미치고 있습니다. 하지만 임베디드 시스템에는 아직까지 메모리를 자유롭게 사용할 만큼 풍부한 메모리 자원이 있지는 않습니다.

임베디드 시스템들은 특성상 여러 가지의 응용 프로그램을 한꺼번에 실행하는 것이 목적이 아닌 경우가 많습니다. 더욱이 임베디드 시스템에 사용되는 프로세서에서도 메모리 구조를 단순하게 구성하는 경우가 많습니다. 따라서 메모리가 작은 초기 버전의 임베디드 시스템용 운영체제들은 MMU (memory management unit)를 지원하지 않는 프로세서를 위한 메모리 관리를 축소한 형태의 임베디드 운영체제들이 있습니다. 또한 여러 가지 응용 프로그램의 사용을 제한하고, 가상 메모리 시스템을 포기하는 형태의 운영체제도 있습니다. 멀티태스킹이나 프로세싱을 지원하지 않는 운영체제들의 경우 대개가 이러한 형태입니다.

윈도우 시스템과 그래픽 환경
그래픽 환경은 임베디드 시스템에서 크게 필요하지 않다고 생각하기 쉽습니다. 하지만 사용자의 인터페이스 장비로 키보드나 마우스와 같은 장치를 사용하기 힘들고 대개 터치패드의 형태를 가지고 있기 때문에, GUI를 필요로 하는 시스템이 많습니다. 대개 UI를 지원하기 위한 서브 시스템은 라이브러리 형태를 사용하고 있습니다. 마이크로-윈도우라는 라이브러리 등을 사용하여 작은 메모리를 사용하면서도 훌륭한 시각적 효과를 얻을 수 있는 방식을 가지고 있습니다.
Posted by 행복한 프로그래머 궁금쟁이박

댓글을 달아 주세요

  1. BlogIcon gucci sale 2012.08.10 21:54  댓글주소  수정/삭제  댓글쓰기

    떠한 차이가 있는지 알아보기로 하죠떠한 차이가 있는지 알아보기로 하죠

[송인준]임베디드 시스템에 쓰이는 운영체제 - 1 [INFO]Embedded


임베디드 시스템에 쓰이는 운영체제 - 1

저 자 : 송인준



요즘 IT 잡지나 신문에서 많이 볼 수 있는 단어 중 하나가 바로 임베디드 시스템(Embedded System)이라는 말입니다. 과연 이 임베디드 시스템이 무엇인지, 그리고 왜 필요한지, 이러한 컴퓨터 시스템에는 어떠한 운영체제가 필요한지를 이번 연재에서 알아 봅시다.

임베디드 시스템이라는 것을 정의하기에 앞서, 이 임베디드 시스템이 절대로 낯선 존재라고 생각하지 마십시오. 주변의 핸드폰, PDA, 심지어 냉장고와 TV, 콘솔 게임기 등도 임베디드 시스템의 한 종류입니다. 이렇게 말하니 이제 좀 친숙해지는 것 같지요? 그러면 이번 호에는 임베디드 시스템이 무엇인지부터 시작해서, 무엇이 문제인지, 그리고 이런 문제를 해결해나가기 위한 노력들을 살펴보도록 합니다. 또한 이러한 임베디드 시스템을 구동시키는 운영체제를 알아보고 그 디자인을 살펴보도록 하겠습니다. 이번 호에는 지난 연재에 비해 최신의 기술을 다루는 편이네요. 그럼 지금부터 임베디드 시스템과 그것에 쓰이는 운영체제를 공부해 봅시다.

임베디드 시스템의 정의
먼저 무엇이 임베디드 시스템인지, 도대체 어떤 특성이 있고 왜 나왔는지부터 파악해야 합니다. 그렇다면 임베디드(Embedded)라는 말이 무엇을 의미하는 걸까요? 영어사전을 찾아보면 ‘깊숙이 박다. 파묻다. 끼워 넣다’ 등의 의미로 풀이되어 있습니다. 임베디드 시스템이란 간단히 PC가 아닌 어떠한 장치에 끼워 넣은 시스템을 의미합니다. 어떤 독자는 우리말로 ‘내장형 시스템’이라고 표현하기도 합니다. 하지만 우리들이 이번 호에 공부하면서 내장형 시스템이라는 말보다는 임베디드 시스템이라는 말을 쓰도록 하겠습니다. 이 말이 좀더 친숙한 면이 많기 때문이지요.

그렇다면 다시 임베디드 시스템의 정의로 돌아가 보죠. 과연 어떤 장치에 내장한 시스템을 단순히 임베디드 시스템이라고 할까요? 만약 채점을 하면 50점짜리 답안이라고 할 수 있겠네요. 정확한 정의를 내리자면, 임베디드 시스템이란 제한된 자원을 갖고 특정한 목적을 갖는 작업을 처리하기 위한 시스템이라 할 수 있습니다. 제한된 자원이라면 휴대폰을 예로 들어, 크기가 작아야 하고 배터리 수명의 제한 등이 있습니다. 또한 특정한 목적을 갖는 작업이란 휴대폰의 예에서는 전화의 송수신을 담당하는 호(call) 처리가 될 것입니다.

이러한 정의를 두면, 임베디드 시스템이란 우리 주변에서 쉽게 찾아볼 수 있는 시스템이란 것을 알았을 겁니다. 실제로 연간 생산되는 임베디드 시스템은 데스크톱 PC에 비해 훨씬 많은 양을 차지합니다. 오디오, 비디오, TV, 심지어 전자렌지까지 도처에 널려 있습니다. 그렇다면 이제 이러한 임베디드 시스템의 공통적인 특징들을 살펴보도록 하겠습니다.

임베디드 시스템의 공통적인 특징
‘임베디드 시스템은 제한된 자원을 갖는다’
임베디드 시스템의 가장 큰 특징이며 그것을 정의하는 가장 큰 요소는 제한된 자원을 갖는다는 점입니다. 휴대폰이나 PDA, MP3 플레이어 등 주위에서 쉽게 볼 수 있는 임베디드 시스템의 큰 특징은 에너지가 제한적이라는 점입니다. 배터리를 쓰는 것들의 가장 큰 약점이라고 할 수 있죠. 하나의 예로, 휴대폰에서 지금보다 더 화려하고 빠른 게임을 즐기는 것이 불가능한 것은 아닙니다. 이미 CPU의 성능이나 메모리의 성능은 매우 뛰어난 기술을 갖추고 있으니까요. 다만 그것을 구동시키는 에너지원인 배터리의 문제가 더 크다고 할 수 있습니다. CPU의 속도를 빠르게 하려면 배터리 소모가 늘어나게 되는데, 그렇게 하면 아침에 충전한 전화기가 점심 먹을 때에 삑삑 소리를 내며 전원이 꺼질 수도 있겠죠.

배터리의 제한
사실상 가장 큰 문제점이라고 할 수 있습니다. 물론 냉장고나 자동차, 혹은 전자레인지에 들어가는 임베디드 시스템은 그 심각성이 좀 덜한 편이지만, 컴퓨터 개발자들이 흔히 접하게 되는 PDA 같은 경우에는 배터리로 인한 에너지의 제한점이 큰 걸림돌이 되는 경우가 많습니다. 이러한 배터리, 즉 파워의 제한을 해결하는 방안에는 몇 가지가 있습니다.

우선 하드웨어적인 문제로 해결하는 방법입니다. 가장 기본적인 것은 물론 배터리의 용량을 늘리는 방법입니다만, 그것은 기술의 발전 속도상 어려운 일입니다. 또 다른 방법으로는 CPU의 모드를 두는 것입니다. 마냥 빠르게만 작동하는 CPU가 아니라, 그 속도를 늦추거나 하는 일이 없을 때는 잠들어 있는 것입니다. 이렇게 CPU를 제어하는 방법 외에 메모리의 설계를 저전력을 위한 구조로 바꾸는 방법도 있습니다. 이러한 하드웨어 해결책 외에도 소프트웨어 해결책도 있습니다. 운영체제의 구조를 저전력을 위한 구조로 바꾸는 것이 하나인데, 이것은 CPU의 모드를 어떻게 하면 적절하게 변환할지를 운영체제에서 제어하는 것입니다. 또한 임베디드 시스템 위에서 돌아가는 소프트웨어의 구조를 저전력을 위한 형태로 만들기 위해 특화된 컴파일러를 이용하는 것도 하나의 방법입니다. 우리가 공부하는 것은 임베디드 시스템을 위한 운영체제이지만, 이를 공부하기 전에 하드웨어 접근방법에는 무엇이 있는지 간략하게나마 살펴보고 진행하겠습니다.

저전력을 위한 CPU 구조
저전력을 위한 CPU 구조에도 몇 가지의 접근 방식이 있습니다. 그중에서 가장 대표적인 것은 가변적인 전력 기술(variable-voltage mechanism)입니다. 전력 소비를 줄이는 가장 효율적인 방법이 전력을 낮추면 된다는 것은 누구나 아는 사실입니다. 전통적인 시스템에서는 고정적인 전력을 사용하였지만, 최근에는 전력을 동적으로 변하게 하는 방법을 사용합니다. 이렇게 전력을 동적으로 변화시켜서 사용하기 위해서는 언제 얼마큼 전력을 낮추어야 할지 정해야 하는데, 이것을 CPU의 동작이 활발한 때와 활발하지 않은 때로 나누어서 정하는 것입니다. 요즘 PDA 등에 많이 쓰이는 암(ARM) CPU의 경우, 7개의 모드를 갖습니다.

저전력을 위한 메모리 설계
메모리와 CPU의 데이터 전송시에 소비되는 전력 낭비를 줄이기 위한 방안들이 연구되고 있습니다. 이 분야는 전산학을 전공한 개발자들에게 생소하며 전자공학과를 전공한 사람들이 주로 연구하는 분야이지요. 메모리와 CPU 간의 데이터 전송을 줄이기 위해 비트의 수를 줄이는 방법이 있습니다. 또한 성능 향상을 위해 만들어진 캐시의 설계를 전력 소비를 줄이기 위한 설계로 바꾸어 나가는 방향도 있습니다.

저전력을 위한 컴파일러 최적화
하드웨어 접근법을 앞에서 살펴봤습니다. 이외에 소프트웨어 실행시에 전력의 소비를 최소화하려고 노력하는 움직임도 있습니다. 그러기 위해서는 최적화된 컴파일러를 사용해야 하는 것이지요. 물론 이러한 해결책은 하드웨어적인 해결책을 기반으로 행해지는 것이 보통입니다. 이러한 방법은 프로그램 개발자가 코딩할 때와 컴파일할 때에 코드 수준의 최적화라 할 수 있습니다. 앞으로 임베디드 시스템의 응용 프로그램을 개발할 일이 많은 개발자는 이러한 저전력에 대한 개념을 가지고 개발에 임한다면 한 단계 높은 수준의 프로그램을 개발할 수 있을 것입니다.

저전력을 위한 운영체제 구조
저전력을 위한 운영체제의 구조에는 하드웨어를 어떻게 조작할 것인지에 대한 접근방식입니다. CPU의 모드를 어떻게 제어할 것인지가 주를 이루게 됩니다. 즉, CPU의 모드 중 전력을 덜 소비하는 모드를 정하려면 저전력을 위한 프로세스 스케쥴링 등이 필요하게 되는 것이지요.

저장 매체의 제한
임베디드 시스템이 갖는 제한된 자원 중에는 저장 매체에 대한 것도 빼놓을 수 없습니다. PDA나 휴대폰에는 보통 대용량의 하드디스크 대신 플래시 메모리를 장착합니다. 플래시 메모리는 하드디스크에 비해 용량대비 가격이 비쌉니다. 하지만 하드디스크를 달지 못하는 이유는 간단합니다. 그것은 하드디스크의 암을 움직여주는 모터에 있습니다. PDA나 휴대폰에 그러한 모터가 달린다면 약간의 충격이라도 쉽게 파손되고 소음도 심할 수 있습니다.

크기의 제한
임베디드 시스템의 크기를 보면 가전제품에는 영향을 주지 않지만 휴대용 기기에는 크게 작용하는 편입니다. 이동성을 중시하는 휴대용 기기에 큰 덩치를 가진 것이라면 여간 가지고 다니기 어렵습니다. 크기의 제한은 간접적으로 에너지의 제한도 가져옵니다. PDA에 007 가방만한 배터리를 들고 다녀도 상관은 없으나, 크기가 너무 커져 휴대하기 불편할 게 뻔합니다.

이러한 총체적인 문제들, 즉 임베디드 시스템 중 특히 휴대용 기기들이 갖는 제한된 자원이라는 한계점은 앞으로 더욱 발전해야 할 여지들을 남겨주고 있습니다. 지금도 이것들을 해결하기 위해 부단히 노력중이지요. 제한된 자원이라는 임베디드 시스템의 특성 말고 다른 또 하나의 큰 특성으로는 특화된 목적을 갖는다는 점입니다. PDA나 전자수첩의 경우, 개인정보의 관리라는 특화된 목적을 갖고 있습니다. 또한 라우터에 들어가는 시스템의 경우, 데이터 패킷을 최적의 경로로 포워드하기 위한 특화된 목적을 갖는 것이지요. 그렇다면 일반적인 목적을 갖는 범용 시스템과 특화된 목적을 갖는 임베디드 시스템에는 어떠한 차이가 있는지 알아보기로 하죠.
Posted by 행복한 프로그래머 궁금쟁이박

댓글을 달아 주세요

  1. BlogIcon mulberry sale 2012.08.10 21:54  댓글주소  수정/삭제  댓글쓰기

    떠한 차이가 있는지 알아보기로 하죠