임베디드 시스템의 변화, 하드웨어의 필요성

임베디드 시스템이란 무엇인가?

 

우리가 흔히 쓰는 대부분의 기기들은 임베디드로 구성되어 있다.

 

전기회로에서 단순한 마이컴을 거쳐 부가기능이 있는 임베디드가 사용되기 까지 우리는 개발환경을 모르지만 너무 익숙하게 누리고 있는 임베디드 시스템,

 

우선 임베디드가 무엇인지 부터 살펴보자. 

 

PC와 임베디드는 개발환경이 다르다!

 

 

---

임베디드 시스템이란 무엇인가? (2편)

---

 

 

32bit 임베디드 개발보드

임베디드 개발자 입문

임베디드 시스템을 좀더 쉽게 이해하기 위해서 생활가전 제품인 밥솥을 예로 들어 임베디드 시스템을 설명하고자한다. 다음은 밥솥의 발전 단계를 나타낸 것이다.

1. 전기 회로로만 구성된 전기밥솥(초기)
2. 간단한 4비트 또는 8비트 마이콤이 내장된 전자밥솥(현재)
3. 일반 PC 같은 기능을 가진 32비트급 프로세서가 내장된 전자밥솥(미래)

(1)은 단순히 히터라는 전기회로를 통해서 열을 가하여 밥을 짓는 장치이다. (1)은 사람이 모든 제어를 수행하며, 독립적인 기능을 수행할 수 없기 때문에 임베디드 시스템이라 할 수 없다. 

(2)와 (3)은 독립적으로 기능을 수행할 수 있기 때문에 임베디드 시스템이라 말할 수 있다. 이렇듯이 임베디드 시스템은 CPU가 내장되어 있어서 시스템의 기능을 제어하는 시스템이라 할 수 있다.

 

(2)와 같은 경우는 사람이 하던 제어 기능을 4비트 또는 8비트의 마이콤이 펌웨어를 통해서 수행하도록 하도록 하였다. 여기서 펌웨어란 OS 없이 동작되는 프로그램을 말하며, 4비트 8비트 마이콤에서 사용된다. 즉 프로세스가 하나라는 의미이다.

 

(3)은 밥을 하는 고유 기능 이외에 외부와 네트워크로 연결되어서 밥을 짓는 정보를 영상이나 음성 정보를 통해서 전달받으며 이를 사용자가 쉽게 사용할 수 있도록 GUI 환경을 제공하는 기능이 추가된 시스템을 말한다. 32비트를 사용하며 여러 개의 프로세스가 존재하기 때문에 펌웨어를 사용할 수 없고, OS 환경 하에 동작하는 애플리케이션이 동작되는 시스템이다. 그리고 통신 기능을 구현하여야 하기 때문에 TCP/IP와 같은 프로토콜이 구현되어 있어야 하며 그래픽 LCD 기반의 GUI 환경이 기본적인 시스템이기 때문에 시스템 규모가 (2)와는 매우 다르다. 마치 PC 하나가 밥솥에 들어가 있는 형태라고 할 수 있다.

 

(3)과 같이 임베디드 시스템은 2000년대로 들어서면서 트렌드의 변화가 오기 시작하였다. (2)와 같이 마이콤에 펌웨어 기반의 고유 기능을 가지고 있는 것이 기존의 임베디드 시스템이었다면 (3)은 고유 기능 이외에 부가 기능을 가지고 있으며, 이러한 부가 기능은 많은 정보량을 요구하기 때문에 단순한 8비트의 구조를 가지고 사용할 수 없으며 32비트 프로세서 기반은 여러 개의 애플리케이션을 운영하기 위한 운영체제를 필요로 하게 된다. 

이러한 임베디드 시스템의 수요는 날로 커져가고 있다. 현재 임베디드 시스템의 특징은 PC가 가지고 있는 기능이 임베디드 시스템에 적용된다는 것이다. 그래서 이를 포스트 PC라고도 하고, 가전에 정보 전달 기능이 강화된 형태를 유지하기 때문에 이를 정보가전이라고도 표현하고 있다.

 

임베디드 시스템의 하드웨어 구조

 

임베디드 개발 과정은 크게 3가지로 나눌 수 있다.

◆ 임베디드 시스템 하드웨어 개발 과정
◆ 임베디드 시스템 교차 개발환경 구축 과정
◆ 임베디드 시스템 소프트웨어 개발 과정

 

 

임베디드 시스템의 개발 과정을 일반 PC 같은 기능을 가진 32비트급 프로세서가 내장된 전자밥솥을 예로 설명하고자 한다. 

 

개발 순서는 먼저 밥솥의 기능을 정하고 그에 맞는 하드웨어와 소프트웨어 기능을 협의한 후 각각의 기능
을 구현하는 것이다. 개략적으로 하드웨어의 32비트 CPU는 XScale 기반 PXA255이고, 운영체제는 임베디드 리눅스를 사용하기로 한다.

 

임베디드 시스템 HW 개발 과정

<그림 3>은 밥솥의 하드웨어 구성을 나타낸 것이다. CPU는 ARM 기반의 인텔에서 제공하는 PXA 255를 사용하였며 메모리는 SDRAM 32MB, 플래시 16MB를 사용하였으며 밥솥의 기능을 수행하기 위해서 히터 로직(Heater Logic)이 있으며 외부에 TCP/IP 기반으로 통신하기 위해서 이더넷 컨트롤러를 달았다. 그리고 사용자 인터페이스를 위하여 3.5인치 TFT LCD를 달았고, 터치스크린을 통하여 사용자로부터 입력을 받을 수 있도록 하였다. 그리고 사운드 로직을 통하여 음향 및 음성 정보를 사용자에 전달할 수 있도록 하드웨어를 설계하였다.

 

여기서 사용되는 PXA 255는 400MHz의 속도를 가진 고성능 CPU이다. 이는 몇 년 전 PC의 CPU 속도와 같은 수준의 CPU인 것이다. 그리고 메모리 또한 PC의 메모리와 비교해도 손색이 없을 정도의 용량이다. 일반 PC는 파일 시스템을 하드디스크에 구현하지만 여기서는 플래시 메모리에 구축하는 것으로 하였다.

 

크로스 개발 환경 구축과정

하드웨어 제작이 끝나면 교차(cross) 개발 환경을 구축하여야 한다. 크로스 개발 환경이란 호스트에 타겟 디바이스용 리눅스를 개발하기 위한 모든 환경을 말한다. 그리고 부트로더를 컴파일하여 해당 코드를 플래시 메모리에 넣어야 한다. 그 다음이 부트로더를 수정하여 원하는 기능을 구현한다. 

 

임베디드 시스템의 개발 환경은 크게 3개 사항을 고려하여야 한다.
◆ 컴파일 환경인 XScale용 크로스 툴 체인(tool chain)
◆ 부트로더를 플래시에 올리기 위한 JTAG fusing 시스템
◆ 부트로더 제작

개발 환경의 설명에 앞서 용어를 정리하고 설명하기로 하자.

 

 

<그림 1>의 임베디드 시스템 환경에서 나오는 용어를 설명하면 다음과 같다.

◆ 타겟 디바이스 : 개발하고자 하는 임베디드 시스템 보드, 여기서는 전자밥솥이 하드웨어이며, 사양은 <그림 3> 과 같다.
◆ 호스트 시스템 : 타겟을 개발하기 위한 환경을 제공하는 시스템으로서 교차 컴파일러, 모니터, 디버거 등을 제공하며, 일반적으로 PC가 호스트가 된다.
◆ 백엔드(backend) : 호스트와 타겟이 통신을 하기 위한 매개체로, <그림 1>에서와 같이 시리얼은 통신 에뮬레이터를 통해 타겟과 통신할 수 있는 통신 채널을 제공한다. 패러럴은 JTAG을 통해서 플래시에 fusing할 수 있는 통신 채널을 제공한다. 이더넷은 zImage, root filesystem image를 호스트에서 타겟으로 다운로드할 수 있는 통신 채널을 제공한다.
◆ 타겟 터미널 : 타겟의 상황을 호스트에 표시해 주는 프로그램, 즉 통신 에뮬레이터를 말한다.

 

컴파일 환경 - XScale용 크로스 툴 체인

먼저 해당 CPU에 맞는 툴 체인 환경을 구축해야 한다. 툴 체인이란 타겟 디바이스의 소프트웨어 개발을 진행하기 위해 필요한 호스트 시스템의 크로스 컴파일 환경을 말한다. 툴 체인은 각종 소스들을 컴파일하고 빌드해 실행 바이너리를 생성하는 데 필요한 각종 유틸리티 및 라이브러리의 모음이다. 기본적으로 어셈블리, 링커, C 컴파일러, C 라이브러리 등으로 구성되어 있다. 여기서는 GNU에서 제공하는 툴 체인을 사용하며 다음과 같다.

 

- GNU gcc compilers for C, C++
- GNU 바이너리 유틸리티(어셈블러, linker various object file utilities)
- GNU C 라이브러리

 

XScale에 사용하기 위한 ARM 툴 체인은 다음과 같은 사항으로 구성되어 있다.
- binutils-arm-2.11.2 : 유틸리티
- gcc-arm-2.95.3 : 컴파일러
- glibc-arm-2.2.3 : 라이브러리

 

부트로더를 플래시에 올리기 위한 fusing 시스템

일반적으로 JTAG(Joint Test Access Group)란 말보다 Boundary-Scan이란 말이 더 많이 사용된다. 그럼 Boundary-Scan이라는 ‘주변을 훑어보다’라고 할 수 있다. 먼저 Boundary-Scan의 역사를 살펴보자.

◆ 1980년대 후반의 JTAG라는 곳에서 연구 중이던 Boundary-scan 설계를 IEEE에서 1990년에 표준화하였고 IEEE std 1149.1가 제정되었다.

<그림 4>와 같이 호스트 시스템으로부터 타겟 보드에 있는 스트라타(strata) 플래시에 부트로더를 쓰기 위해서는 그림과 같은 구성이 필요하다. 먼저 호스트 시스템의 구성부터 살펴보면 호스트 시스템에서 동작하는 jflash라는 프로그램이 필요하다. 이 jflash는 패러럴 포트를 이용하여 타겟 보드에서 필요로 하는 JTAG 신호를 생성한다.

 

호스트 시스템에서 생성된 JTAG 신호는 패러럴 케이블을 통해 동글(dongle)에 전달된다. 동글은 TTL 74HCT541을 사용하여 구현하였으며, 이 기능은 단지 호스트 시스템의 패러럴 포트에서 발생한 5V 전압을 PXA255에 적합한 3.3V 전압 레벨로 변환하는 기능이다.

JTAG을 이용한 플래시 메모리 퓨징

동글을 통해서 전달된 JTAG 신호 중 TMS와 TCLK는 TAP에 전달되어 JTAG의 state 머신을 결정하고, TDO와 TDI는 JTAG의 명령의 상태에 따라 bypass register, boundary scan cell, ID 레지스터 등의 입력과 출력 부분에 연결된다. 

PXA255의 JTAG을 통해서 플래시 메모리가 필요로 하는 버스 타이밍(bus timing)을 발생하여 플래시에 전달한다.
호스트 시스템의 셸(shell)에서 jflash blob을 입력하면 x-boot250의 바이너리 코드가 플래시 메모리의 0번지부터 퓨징(fusing)을 한다. 메모리에 쓰기 전에 기본적으로 쓰고자 하는 0번 블럭을 지우고, blob을 퓨징한 후, 에러 없이 퓨징이 되었는지를 검사하기 위해 검증한 후에 이상이 없으면 x-boot250이 정상적으로 로딩을 완료하게 된다.

이 상태에서 시리얼 통신 환경의 설정에 이상이 없다면 정상적으로 x-boot250이 동작하는 것을 볼 수 있을 것이다.

 

 

부트로더 제작

<그림 5>와 같이 일반적으로 부트로더라 하면 일반 x86 리눅스에서는 LILO를 많이 사용할 것이다. LILO란 Linux Loader로서 DOS나 윈도우 NT, 리눅스 등 다른 OS를 선택적으로 부팅할 수 있도록 하는 기능을 제공한다. LILO는 하드디스크의 MBR에서 동작하는 프로그램으로 OS가 실행할 수 있도록 점프하는 기능을 수행한다.

 

<그림 5> LILO와 X-boot250과 비교

그럼 우리가 사용하는 x-boot250이란 부트로더는 플래시 0 블럭에서 실행되고 여러 가지 다양한 기능들을 수행한다. 먼저 커널이나 램디스크(ramdisk) 등의 데이터를 호스트로부터 SDRAM 영역으로 다운로드할 수 있는 기능이 있고 SDRAM에 있는 데이터를 플래시 영역으로 라이팅할 수도 있다. 그리고 커널이 이미 올라가 있다면 부팅할 수
있는 기능도 같이 제공한다. 부트로더의 기능을 요약해보면 다음과 같다.

 

부트로더 기능

◆ 하드웨어의 초기화 : 부트로더에서 제일 먼저 실행, CPU, 속도, 메모리, 인터럽트, UART 등을 초기화해 준다.
◆ 리눅스 부팅 : 부트로더 상에서 리눅스를 부팅하는 기능이 있다.
◆ 커널 또는 램디스크 다운로드 : 부트로더의 가장 중요한 기능인 커널이나 램디스크 이미지를 다운로드하는 기능이 있다. 호스트 상에서 컴파일된 이미지를 시리얼이나, tftp를 이용해 이더넷을 통해 SDRAM 상으로 다운로드가 가능하다.
◆ 다운로드한 커널 및 램디스크를 플래시에 라이트 : 다운로드한 커널과 램디스크 이미지는 SDRAM 상에 있기 때문에 전원이 꺼지면 다운로드한 이미지는 날라가 버린다. 그러므로 플래시 기능을 통여 SDRAM 상의 커널과 램디스크를 지정된 플래시 주소 영역에 라이팅하는 기능이다.
◆ tftp를 통한 SDRAM에 다운로드 : 시리얼을 통해 커널 등을 다운로드하기에는 속도가 너무 느리다. 그러나 tftp를 이용한 이더넷으로 다운로드할 수 있는 기능을 추가하여 고속으로 커널이나 램디스크를 다운로드할 수 있다.

 

 

 

다음 시간에는 임베디드 시스템 SW개발과정을 알아보자.