개요: PC용 소프트웨어 개발업체는 내장 시스템 개발업체에 비해 수 많은 이점을 누리고 있다. 한 예로, 불과 몇 년 전 수퍼컴퓨터에 버금가는 성능과 메모리를 지닌 시스템의 소프트웨어를 개발했으며 이미 존재하는 시스템의 소프트웨어도 개발하고 있다. 반면 내장 시스템 개발업체의 경우, 보다 작은 시스템을 개발해야 할 뿐만 아니라 이와 같은 시스템을 우선 설계해야 해야 한다.
내장부품에 대한 접근 방식은 문제의 중요성에 따라 선택해야 한다. 사용자 간 상호 작용이 거의 없거나 적은 수의 장치만을 제어하며 설계가 비교적 간단한 경우라면 8051, 68HC11, Atmel, AVR, PIC 유형 같은 8비트 저전력 마이크로컨트롤러를 사용하여 문제를 해결할 수 있다. 이러한 솔루션은 일반적으로 전력과 유연성이 적정 수준인 편이다. 이에 비해, 사용자 간 상호 작용이 많거나 이더넷을 통해 통신해야 하며 디지털 카메라와 같은 복잡한 장치와 통신해야 하는 경우는 대개 PC-104, StrongARM 혹은 다른 유형의 "경제형 PC(one-calorie personal computer)"가 사용된다. 이와 같은 솔루션은 일반적으로 프로세싱 전력이 충분하고 대용량 RAM을 제공하지만 운영 체제가 복잡한 편이다.
이 두 접근 방식 사이에는 명확하지 않은 영역이 존재한다. 예를 들어, Joe's Security Service가 경쟁이 치열한 네트워크 도어록 (door lock) 시장에 진출한다고 가정해보자. 최근의 보안 문제 때문에 회사들은 한 개 이상의 ID 번호로 사용자를 기록하는 도어 록을 설치하려 할 것이다. 또한 사용자가 문을 열려고 할 때마다 얼굴이나 엄지 손가락 지문 사진을 찍는 전자식 도어록도 원하고 있다. 이렇게 찍힌 이미지는 네트워크를 통해 중앙 서버로 전송되어 로그인 또는 이미지 인식 및 검증을 거치게 된다. 이미지가 검증되어 서버가 네트워크 도어록에 응답을 다시 전송할 때 사용자가 문을 열 수 있게 되는 것이다. Joe는 고객이 자체 시설에 이와 같은 문을 많이 설치하길 원하기 때문에 중요한 요소는 비용을 낮추는 것이 된다.
Joe의 경쟁업체 중 하나인 Alex's Security Central은 이더넷 컨트롤러에 연결된 8비트 RISC를 사용한 네트워크 카메라 도어록을 개발 중이다. Joe는 이 솔루션을 저전력으로 간주하여 고려하지 않았다. 이더넷 컨트롤러에 하버드 아키텍처 (Harvard-Architecture) 칩을 연결하는 프로젝트를 여러 번 보아왔기 때문이다. 그러나 이 프로젝트들의 대부분은 초기 개발 단계로 재정 지원을 전혀 받고 있지 못하며 TCP/IP 스택도 아키텍처 자체로 인해 제한된다. 네트워크와 통신 가능하다 하더라도 디지털 카메라와 통신할 수 없게 될 것이다. 적정한 이미지를 위해서는 40 ~ 60KB의 메모리가 필요하다. 그러나 코드 메모리 공간 문제에 부딪히게 된다. Joe가 하버드 아키텍처가 아닌 장치를 사용한다 하더라도 기존의 8비트 마이크로컨트롤러에 작업량과 데이터의 양이 너무 많아져 처리할 수 없게 된다.
Joe의 주 경쟁업체인 Troy's X-Treme Security 의 Troy 또한 솔루션을 개발 중이다. Joe는 Troy가 내장 시스템 설계 장점과 우수성을 인정하지 않는 사실 때문에 Troy를 싫어한다. 여기에 연애적인 요소를 더해 보자. Troy는 Joe의 옛 여자 친구인 Amiga가 현재 사귀고 있다. Amiga는 Joe가 컴퓨터와 너무 많은 시간을 투자한다(내장 시스템 개발업체 사이에서는 "직업적인 위험"이라 알려진)는 이유로 Joe와 헤어졌다. Troy는 Pocket PC를 동작시키는 StrongARM을 사용해 고속 I/O 및 네트워크 기능을 지닌 솔루션을 개발 중이다. Joe는 이 솔루션을 정도가 지나치다고 생각한다. 사진 찍는 것을 빼면 프로세서는 보통 유휴 상태이다. 이상적인 솔루션에는 메모리나 전력이 많이 필요하지 않다. 그러나 내장된 Linux 또는 Pocket PC를 실행하면 단순한 장치에 불필요한 사항들이 증가되고 너무 많은 비용이 들게 된다.
Joe가 원하는 것은 네트워크와 카메라를 처리할 수 있을 만큼 충분히 강력하면서도 32비트 솔루션에 비해 비용이 적게 들고 기능도 적은 마이크로컨트롤러이다. 개발을 쉽게 하기 위해 완전 어셈블리어가 아닌 고급 언어를 지원한다면 Joe에게 더욱 좋을 것이다. 그렇다면, Joe가 Alex의 전력, Troy의 가격을 물리치고 사랑을 되찾을 수 있는 방법은 과연 무엇일까? 해답은 바로 아래 설명되어 있는 TINI®에 있다.
네트워크 브리지
TINI(tiny Internet interface)는 Dallas Semiconductor의 제품이다. TINI 플랫폼은 네트워크 브리지로 동작하도록 설계되어 PC 는 TCP/IP를 통해 TINI와 통신하고, TINI는 센서, 레거시 하드웨어 혹은 기타 장치와 통신한다. TINI는 1-Wire®, 2-wire, RS-232 serial, CAN 및 SPI™ 등의 수 많은 외부 인터페이스를 제공한다. 또한 네트워크 구현 성능이 강력하며 IPv4, IPv6, DNS, DHCP, PPP, Telnet 및 FTP를 지원한다.
2개의 TINI 기준 설계를 사용할 수 있다. 가장 많이 사용되는 DS80C390 기반의 TINIm390 검증 모듈은 512kB 플래시, 512kB 또는 1MB의 배터리 지원 SRAM, 이더넷 컨트롤러, 실시간 클록이 내장된 72핀 SIMM이다. 가장 최신 버전인 DS80C400 기반의 TINIm400은 이더넷 MAC이 DS80C400에 내장된 점을 제외하고는 TINIm390 검증 모듈과 유사한 기능을 가진 144핀 SO DIMM이다.
TINIm390과 TINIm400 모두 8비트 마이크로컨트롤러이다. 실제로 이 두 모듈 모두 기본적으로는 8051 마이크로컨트롤러이지만 원형에서부터 다음과 같이 크게 확장되었다. 첫째, 코어가 표준인 12개의 사이클이 아닌 명령당 4개의 사이클(4 cycles-per-instruction)이다. 이 때문에 동일한 클록 주파수에서 표준인 8051s보다 3배 증가된다. 둘째, 어드레싱 기능이 훨씬 강화되었다. TINIm390는 4MB의 프로그램 메모리 및 4MB의 데이터 메모리를 지원하며, TINIm400은 일정한 16MB 어드레스 공간을 지원한다. 셋째, 더 높은 클록 주파수를 지원한다. TINIm390은 최고 40MHz까지, TINIm400은 최고 75MHz까지 실행시킬 수 있다. 마지막으로, 곱셈 및 나눗셈을 위한 정수 수학 가속기(integer math accelerator)가 내장되어 있다. 이 가속기는 기존의 8비트 마이크로컨트롤러와 16/32비트 마이크로컨트롤로러의 중간에 해당하는 전력을 제공한다.
TINI 플랫폼만의 특징으로는 Dallas에서 개발한 운영 체제를 들 수 있다. 로열티가 없는 이 멀티태스킹, 멀티스레드 운영 체제로 Java™ 런타임 환경을 특징으로 하며 무료로 다운로드 받을 수 있다. 핵심 OS 및 라이브러리는 512kB 플래시에 적합하고 최종 플래시 뱅크의 64kB 애플리케이션에 충분한 공간을 지니고 있다. DS80C400에는 또한 C 및 어셈블리 프로그래밍을 위한 ROM 라이브러리도 포함되어 있다.
네트워크 카메라
네트워크 카메라 문제를 해결할 수 있는 방법을 보여주는 예로 TINI가 스트리밍 웹 카메라를 구현하고 성능을 벤치마킹할 때 사용된다는 것이다. TINIm400 기준 설계보다는 고속의 맞춤형 DS80C400 설계가 사용된다(그림 1). 여기서 설명하는 네트워크 카메라는 원 이미지를 선택한 후 UDP를 통해 PC 호스트에 전송하고 호스트 쪽의 소프트웨어나 HPPT를 통해 서비스를 제공하는 Java 애플릿을 통해 PC와 통신한다.
그림 1. 고속 DS80C400의 설계 다이어그램
선택된 카메라는 M4088 모듈로 OmniVision 5017 CMOS 칩을 사용하며 해상도가 384 x 288 픽셀인 비격행 방식(non-interlaced)의 흑백 디지털 카메라이다. 이 카메라는 8개의 데이터 라인과 4개의 어드레스 라인 및 칩 선택을 노출시켜주므로 메모리 매핑이 쉽다. 또한 이미지를 찍을 때 나타나는 수직 동조 라인과 매 주사 라인에 대해 나타나는 수평 동조 라인 및 픽셀이 전송되는 시기를 픽셀 클록도 노출시킨다. 카메라가 초기화되면 소프트웨어를 사용하여 액세스하는 것이 편리하다. 5017에는 내부 클록 분배기가 있어 프레임 전송률의 프로그램을 제어할 수 있다. 또한 단일 프레임 모드도 있기 때문에 이미지를 찍을 때 호스트 장치를 제어할 수 있다. 이런 설계에서는 카메라의 최고 속도인 초당 50 프레임을 처리할 프로세서 전력이 없으므로 위에 언급한 제어 기능이 유용하다.
카메라의 400 버전은 73MHz(18.4MHz x 4)에서 동작하도록 설계되어 있다. 이 버전은 Ethernet MAC을 내장하고 있지만 Ethernet PHY와 자석이 있어야 한다. 또한 HomePNA, HomePlug PHY와 같은 다른 PHY도 지원한다. 이 예에서 사용되는 Intel LXT972A는 표준 MII 인터페이스를 사용해 직접 400에 연결된다(그림 2). PHY에는 자체적으로 25MHz 클록이 필요하다.
큰 이미지 보기
그림 2. DS80C400은 표준 MUU 인터페이스를 통해 PHY에 연결된다.
카메라를 동작시키려면 12ns 메모리가 있어야 한다. 필요한 액세스 시간을 제공해주는 Hitachi HM62W8511H가 사용된다. 부팅 시, 프로세서는 실행 가능한 이미지를 플래시에서 SRAM으로 복사하는 플래시로부터 부트스트랩 코드를 실행하고, 클록 4배기(quadrupler)가 활성화되도록 플래그하여 TINI 시작 어드레스로 건너뛴다. 고속 SRAM은 너무 빨리 배터리를 소모하기 때문에, TINIm400에서 사용할 수 있는 이 구성의 경우 보드에 배터리 백업이나 비휘발소자(nonvolatizer)가 없다. 즉, TINIOS에 영구적인 파일 시스템이 없다는 뜻이다. 뒤에 다시 설명하겠지만 TINI가 가동 시 파일 시스템을 새로 구축하기 때문에 그리 큰 문제가 되지 않는다.
TINIOS에는 MAC 어드레스 저장을 위한 DS2502가 필요하다. 반드시 필요한 것은 아니지만 I²C™을 통해 연결된 DS1672 실시간 클록도 있다. 이 클록은 TINI에 소프트웨어 클록에 대한 액세스는 물론 추가적인 특별 기능도 제공한다. 부팅 시 실시간 클록이 검출되는 경우, TINIOS는 자동으로 시스템 버스 속도를 계산한 후 이에 따라 직렬 포트 보드율, 타이머 틱(timer tick), 네트워크 타이밍 등을 포함한 내부 타이머를 적당하게 조정한다.
카메라는 A0-A3, D0-D8, 웹 후크를 해당 라인에 연결하는 것과 같이 직접 연결된다. CE4는 카메라를 0 x 800000에 매핑하는 카메라의 CBS 라인에 연결한다. 카메라의 VSYNC 라인은 읽기용 P1.1에, PSEN은 OEB 카레라 라인에 각각 연결한다. HREF 라인은 INT1에 연결하기 전 반전되므로 레벨 트리거 방식의 인터럽트를 사용할 수 있다.
소프트웨어 구현
개발 시 Dallas Semiconductor 웹 사이트에서 무료로 다운로드할 수 있는 TINI SDK가 사용된다. Java 가상 컴퓨터에는 카메라 데이터를 신속하게 포착할 만큼 충분한 전력이 없을 것이라고 생각하는 사람도 있다. 그러나 네이티브 메소드를 이용하면 TINI를 통해 애플리케이션과 통신하는 운영 체제 안에 인터럽트 서비스 경로를 설치할 수 있다. 위의 내용은 TINI 플랫폼의 장점을 설명하는 것으로써 HTTP 같은 높은 레벨의 프로토콜은 순수 Java에서 구현 가능하며, 코드의 고속부는 네이티브 8051 어셈블리를 사용해 구현 가능하다. 많은 측면에서 살펴보았을 때 양쪽의 가장 좋은 점만을 취한 것이다.
TINI는 JDK 1.1의 다음과 같은 패키지를 지원한다.
java.io
java.lang
java.net
java.util
javax.comm
TINI의 JVM과 PC의 JVM는 서로 차이점도 있다. 첫째, TINI가 불필요한 정보 수집 기능(garbage collection)을 지원하지만 종결자(finalizer)는 지원하지 않는다. 다시 말해, 시스템이 자원을 분명하게 종료시키는 대신 프로그래머가 직접 종료시켜야 한다는 것이다. 그러나 이렇게 자원을 관리하면 내장 시스템 개발에 이로운 점을 제공한다. TINI에는 다음과 같은 등급에 대한 크기 제한 사항도 포함되어 있다. 각 등급 파일 크기는 64kB 미만이며 한 메소드의 로컬 수는 최대 63개이며 어레이 길이는 최대 64kB 이상이 될 수 없다. 시스템은 프로세스당 최대 32스레드, 총 8개의 프로세스로 제한된다. 그러나 차이점 모두가 제한 사항이 되는 것이 아니다. 예를 들어, 1.1 JDK는 IPv6를 지원하지 않기 때문에 TINI는 1.4 JDK로 구현된다.
표준 Java 등급 이외에도 TINI는 아래와 같은 패키지를 제공한다.
com.dalsemi.comm
com.dalsemi.fs
com.dalsemi.system
com.dalsemi.tininet
이러한 패키지는 낮은 레벨 시스템 액세스 및 CAN, I²C와 같은 다른 프로토콜에 대한 지원기능을 제공한다. TINI는 또 일부 레벨이 높은 프로토콜도 지원한다. 한 TINI SDK의 예로 경량급(3kB .클래스 파일) HTTP 서버를 들 수 있다.
소프트웨어는 그림 3에 약술된 설계에 따른다. 하단에 있는 레이어는 카메라 인터럽트 서비스 핸들러로 간접 메모리의 카메라 버퍼에 대한 영구 포인터를 보유한다. 카메라는 단일 프레임 모드로 설정되어 있다. 이 모드에서 카메라는 이미지를 전송하기 전에 명령을 기다린다. 플래그가 설정되면, 이미지는 FRCTL 레지스터가 제어하는 속도로 동기 전송된다. 400버전인 카메라의 경우, 초당 10프레임 속도로 설정되어 초당 전송 속도 1080kB로 1/10초에 384 x 288 이미지를 전송한다.
그림 3. TINI 스트리밍 카메라 소프트웨어는 낮은 레벨과 높은 레벨의 프로토콜을 모두 지원한다.
8051 어셈블리를 사용하면 상대적으로 카메라와 통신하기 쉬워진다. 이미지의 각 픽셀은 하나의 카메라 레지스터로부터 동기적으로 판독된다. 카메라가 메모리 매핑 처리되어 있기 때문에 해당 레지스터에서 읽거나 쓰는 경우 카메라 어드레스에 데이터 포인터를 지정하여 movx op코드를 실행할 수 있다. 기존 8051 어셈블리의 경우, 하나의 어드레스에서 다른 어드레스로 이동시킬 때 데이터 포인터 로드, 메모리를 누산기(accumulator)에 읽기, 어드레스가 데이터 포인터에 복사되도록 설정, 메모리에 누산기 쓰기 등이 포함된다.
mov R0,#LOW(MEMORY_LOW)
mov R1,#HIGH(MEMORY_HIGH)
camera_loop:
;
; Move the camera address into the data pointer.
;
mov dptr,#CAMERA_ADDRESS
;
; Move the data into the accumulator.
;
movx a,@dptr
;
; Move to the address we will be writing to. Since
; this will increment every time, we will keep
it stored
; in registers. We will also need to move it one
byte at
; a time using the DPL and DPH SFRs.
;
mov dpl,R0
mov dph,R1
;
; Write the accumulator to the address
movx @dptr,a
;
; Increment the data pointer and store back in
R0 and R1.
;
inc dptr
mov R0, dpl
mov R1, dph
; Do the loop again...
DS80C400에는 4개의 데이터 포인터가 있어, 한 어드레스에서 다른 어드레스로 데이터를 고속 복사할 수 있다. 이렇게 하면 모든 어드레스 스와핑이 제거되기 때문에 복사 속도를 보다 빠르게 할 수 있다.
;
; Set up the data pointers. We use the DPS
register to select
; what data pointer we want to use. A data
pointer move allows
; for a 24-bit address to be loaded directly.
;
mov dps,#0
mov dptr,#CAMERA_ADDRESS
mov dps,#1
mov dptr,#MEM_ADDRES
;
; Set data pointer 0 as the current data pointer.
mov dps,#0
camera_loop:
;
; Read from data pointer zero.
;
movx a,@dptr
;
; Switch to the next data pointer. Note that doing
; an inc on this register only affects the data
; pointer-selection bit. This allows one cycle
toggling
; from one data pointer to another.
;
inc dps
;
; Store the data and increment the address.
;
movx @dptr,a
inc dptr
;
; Switch back to the first data pointer.
;
inc dps
;
; Do the loop again...
;
위에서 볼 수 있듯이 어드레스 대부분이 루프 외부에서 처리되기 때문에 루프는 더욱 빨리 실행된다. 메모리 복사의 경우, DS80C400에는 최적화 기능이 있어 더욱 빠르게 복사할 수 있다. 첫째, 모든 데이터 포인터는 단일 사이클에서 증가한다. 자동 증가 (autoincrement) 모드가 활성화되면 읽기 혹은 쓰기가 수행된 후 데이터 포인터의 어드레스를 자동으로 증가시킬 수 있다. 또한 자동 선택 (autoselection) 기능이 활성화되면 읽기 혹은 쓰기 동작이 수행될 때마다 2개의 데이터 포인터 사이에서 토글 (toggle)시킬 수 있다. 결과적으로 메모리 복사를 아주 쉽게 실시할 수 있다.
;
; Set the base address of data pointer zero.
;
mov dps,#0
mov dptr,#ADDRESS1
;
; Set the base address of data pointer one.
mov dps, #1
mov dptr,#ADDRESS2
;
; Enable autoselection and autoincrement.
;
mov dps, #(DPS_AID | DPS_TSL)
memory_loop:
;
; Read from data pointer 0, increment the
; data pointer, and toggle the selection bit
; in one instruction.
;
movx a,@dptr
;
; Write to data pointer 1, increment the data pointer,
; and toggle the selection bit in one instruction.
;
movx @dptr,a
; Loop...
예로 다시 돌아가 보자. 이 예에서 HSYNC 라인은 인터럽트를 생성할 때 사용된다. 카메라가 각 주사 라인마다 HSYNC 라인을 강조 표시하면, ISR이 활성화되어 데이터를 포착하기 시작한다. 성능을 향상시키기 위해 스케줄러를 포함한 기타 다른 인터럽트를 낮은 우선순위로 설정하였다. 이렇게 하면 이미지 화질에 상당한 영향을 준다.
카메라에는 프로그램 가능한 윈도우가 있기 때문에 사용자는 384 x 288 이미지 중 사용할 부분을 구성할 수 있다. 적당한 이미지 크기를 찾는 것은 쉬운 일이 아니다. 이미지가 크면 화질이 향상되지만 전송 시간이 더 길어지며 프레임 전송률이 감소된다. 이 애플리케이션의 경우, Joe는 240 x 180 해상도로 카메라를 설정했다. 이 해상도는 인터넷 비디오의 표준 해상도이며 보다 많은 하드웨어 이점도 지니고 있다. 그림 4를 살펴보면 이미지 전송 시 카메라는 실제로 이미지 어레이의 모든 픽셀을 열거하지만 특정 윈도우 안에 있는 픽셀에 대해서만 HSYNC 라인을 강조 표시한다. 즉, 이미지 포착 시 100ms 동안 CPU의 약 3/5를 소모하는 것이다.
그림 4. HSYNC 라인은 각 개별 주사선에 대해 나타난다. A의 경우 픽셀 윈도우는 최대 384픽셀로 설정된 반면 B의 경우에는 192픽셀로 설정되어, 두 픽셀 윈도우 모두 왼쪽 끝에서부터 동일한 프레임 비율로 설정된다. 표시 1은 카메라에 의해 주사선이 나타난 위치이고 표시 2는 카메라가 주사선으로 종료된 위치이며 표시 3은 카메라가 다음 주사선을 시작하는 시기이다. B의 경우, A의 절반에 해당하는 시간이 소요되긴 했지만 주사선에 따른 시간은 동일하다.
초기화 시, 카메라 소프트웨어는 더블 버퍼링에 사용되는 메모리 매니저에서 95kB의 인접 메모리 블록을 할당한다. Java의 경우, 하나의 스레드가 모든 이미지를 포착하며 다른 스레드는 해당 이미지를 네트워크로 전송한다. 이 때, Java는 필요한 모든 스레딩 및 로킹 메커니즘을 제공하여 이 과정을 간소화한다.
소프트웨어 설계의 ISR 이상인 경우 Java 가상 컴퓨터에 적합한 카메라 드라이버를 제공하는 네이티브 메소드가 있다. TINI 플랫폼은 TINI 네이티브 인터페이스(TNI)를 사용하므로 개발자는 Java에서 전송된 낮은 레벨 코드에 액세스할 수 있다. 네이티브 메소드는 TINIOS 네이티브 API로 호출하기 때문에 개발자는 메모리 매니저, 스케줄러, 기타 운영 체제 내부 장치에 액세스할 수 있다. 이와 같은 장치에는 전송된 매개변수는 물론 기타 Java 방식과 같은 예외 사항도 있다. 또한 TINI 개발자 키트를 사용해 구축할 수 있는 TINI 동적 연계 라이브러리(TLIB)를 통해 실행 가능한 Java에 연결된다.
네이티브 메소드를 사용하면 Java가 카메라에 명령을 전송할 수 있다. 카메라 드라이버 등급의 정의는 다음과 같다.
public static final int IMAGE_BUFFER_0 = 0;
public static final int IMAGE_BUFFER_1 = 1;
/**
takePhoto takes a photograph and stores it in
the memory.
@param buffer Species what image buffer to use.
Use IMAGE_BUFFER_0 or IMAGE_BUFFER_1
*/
static native void takePhoto(int buffer);
/**
getScanlines pulls a fixed number of
scanlines out of the memory buffer. This
allows the Java application
the ability to work with fixed pieces of the
image.
@param start first scanline to copy from.
@param end last scanline to copy from
@param offset offset into the data array to
copy to
@param data array to copy into
@param buffer selects the image buffer to read
from. Useful IMAGE_BUFFER_0 or IMAGE_BUFFER_1
*/
public static native int getScanlines(int
start, int end , int offset, byte []data, int
buffer);
주요 방식인 takePhoto는 하나의 이미지를 이미지 버퍼 형태로 포착한다. 첫째, 이 방식은 인터럽트를 활성화하고 하나의 이미지를 선택하라는 명령을 카메라에 전송한다. 단, 여기에는 약간의 문제가 있다. 이 시점에서 Java 스레드를 대기 상태로 두는 것이 좋다. 하지만 TINIOS 함수가 재진입 함수가 아니어서 ISR에서 깨울 수가 없다. 이 같은 현상을 방지할 수 있도록 개발자는 TINIOS를 통해 시스템이 매 4ms마다 깨우는 폴 루틴(poll routine)을 등록할 수 있다. 폴 루틴은 신속하게 점검하여 사진 완료 여부를 판단하는데 사진이 완료된 경우 스레드를 깨운다. 이 폴 루틴은 스레드가 대기 상태가 되기 직전에 등록된다. 이 스레드는 호출되는 즉시 Java로 되돌아간다. 앞에서 언급했듯이, 카메라는 이중 버퍼 처리되어 있기 때문에 겹쳐쓰기할 버퍼를 지정해야 한다. Java가 기본 이미지 버퍼를 액세스할 수 있도록 스캔 라인 블록을 Java 바이트 어레이로 복사되도록 하는 getScanlines 또한 구현된다.
스토리지 문제도 해결해야 한다. TINI 런타임은 512kB 중 7개의 뱅크를 사용하기 때문에 사용자 애플리케이션에 대한 뱅크 1개만 남게 된다. 앞에서 언급했듯이, 고속 설계에는 비휘발 파일 시스템이 없기 때문에 파일 시스템을 새로 구축해야 한다. HTTP 서버가 웹 브라우저로 서비스를 제공하는 Java 애플릿 등 플래시 뱅크의 파워 업 모드에서 동작하는 데 필요한 모든 사항을 갖추는 것이 좋다. 실행 가능한 프로그램에 애플릿을 포함시키기 위해, 애플릿 바이너리는 어셈블러와 호환되는 형식으로 변환되고 라이브러리의 데이터 세그먼트에 포함된다. 이 애플릿 바이너리를 라이브러리로부터 Java 바이트 어레이로 복사하는 네이티브 메소드가 있다. 가동 시 Java 코드는 애플릿의 크기를 판독하고 어레이를 생성한 후 애플릿을 이 어레이에 복사하여 파일 시스템에 해당되는 내용을 쓴다. 다소 번거로운 과정이긴 하지만 클린 부팅(clean boot)으로 시작할 수 있고 시동 시 필요한 모든 것이 준비된다. 이 작업은 다음과 같은 방법을 통해 실시된다.
/**
Extracts the sample jar file from the native library.
The demo application had a jar file embedded inside
the native library. This allowed the jar file,
the application, and the native library
all to be embedded in flash format.
@param dummy Array to copy jar image into.
Must be of greater size than that specified in
getJarFileSize()
*/
static native void getJarFile(byte []dummy);
/**
Gets the size of the embedded jar file
*/
static native int getJarFileSize();
카메라 드라이버 위에 있는 Java는 훨씬 단순하다. 수 많은 스레드가 실행되고 있으며 이들 대부분은 서로 독립성을 띠고 있다. 먼저 HTTP 서버를 살펴보자. 이 서버에 대한 코드는 TINI SDK가 포함된 HTTP 서버의 예에서 찾을 수 있다. 이 HTTP 서버는 매우 경량으로 서브렛이나 cgi-bin 프로세싱, 기타 기능에 맞게 설계된 서버가 아니다. TINI의 비휘발성 메모리에서 구현된 계층적 파일 시스템인 TINI 파일 시스템에서 파일이 판독된다. 시동 시 플래시 메모리에서 카메라 애플릿이 판독되어 파일 시스템에 쓰여지면 index.html 페이지가 생성된다.
다음은 카메라 이미지 서버이다. 카메라 서버에는 2개의 메인 스레드가 있다. 첫 번째 스레드는 포트 42877의 TCP 서버 소켓을 열고 애플릿으로부터의 연결을 기다린다. 내장 시스템의 경우, 서버 소켓이 열리는 방식은 무엇일까? 실제로 PC에서의 경우와 매우 유사하다.
sockpuppet = new ServerSocket(42877);
서버 소켓은 IPv4와 IPv6 상의 포트에 연결된다는 점에 유의한다. 즉, 카메라가 IPv6를 준수하는 데 필요한 변경 사항이 없다는 것이다. 현재 PC, 셀룰러 폰 및 네트워크상의 기타 다른 장치와 어드레스 할당 문제가 있기 때문에 보다 확장된 IPv6의 어드레스 공간은 앞으로 네트워크 기기에 많은 도움이 될 것이다.
한 프로세스가 연결되면 연결 시엔 'A' 또는 연결 해제 시엔 'D'를 전송한다. 연결 명령의 경우 IP 어드레스가 연결 어드레스의 공유 벡터에 추가되지만 연결 해제 명령의 경우에는 벡터에서 IP 어드레스가 제거된다.
sock = sockpuppet.accept();
ch = (char)sock.getInputStream().read();
switch (ch)
{
case 'A':
cwt.addAddress(sock.getInetAddress());
break;
case 'D':
cwt.removeAddress(sock.getInetAddress());
break;
}
sock.close();
다른 하나의 스레드는 이미지 송신기(transmitter)이다. 카메라 벡터에 어드레스가 있는 경우, 이미지 송신기는 포착한 이미지를 UDP 패킷 형태로 이 어드레스에 전송한다. 카메라 포착과 전송은 최적화되어 병렬로 실행된다. 포착은 이중으로 버퍼 처리되어 있어 한 쪽 버퍼에서 전송이 이루어지는 동안 다른 쪽 버퍼에서 포착된다. 이는 카메라가 전송 작업을 실시하는 동안 약 50%의 CPU만을 사용하기 때문에 가능하다. 비동기식 로킹은 모두 Java로 실시된다.
//
// Notify the camera thread we are ready for
// the next frame.
//
synchronized(stopper)
{
stopper.notify();
}
이미지 압축 하드웨어는 사용하지 않기 때문에 모든 이미지가 원래의 상태로 전송된다. 패킷 레이아웃도 매우 간단하다. 각 패킷에는 2바이트 헤더가 있고, 그 뒤로 5개 주사 라인에 해당하는 데이터가 따른다. 첫 번째 바이트는 프레임 번호로, 프레임이 전송될 때마다 증가하는 롤링 카운터이다. 두 번째 바이트는 수직 오프셋을 5로 나눈 것이다.
마지막으로, 구성 툴이 직렬 포트에서 실행된다. CAmera SHell, 즉 CASH라고도 하는 이 애플리케이션은 메뉴 구동식 유틸리티로, IP 어드레스를 설정하고 연결된 사용자를 알 수 있게 해 준다. 이 기능의 대부분은 TINI SDK와 함께 제공되는 슬러시 셸(slush shell)의 일부이다. 카메라 구성을 위해 사용자는 전원을 켜고 직렬 포트를 통해 카메라와 통신한다. CASH는 IP 어드레스를 설정할 수 있도록 간단한 사용자 인터페이스를 제공한다. 구성이 완료되면 카메라는 네트워크에 상주하며 사용자를 기다린다. 누군가가 웹 브라우저에 접속하면, 카메라는 카메라 서버에 연결하여 이미지를 표시해주는 애플릿 서비스를 제공한다. TINIOS는 한 번에 최대 24개의 개방 소켓을 지원하지만, 속도 때문에 4명의 사용자만 카메라를 사용할 수 있도록 제한한다. 멀티캐스트 기능을 이용하면 이 문제를 어느 정도 해결할 수 있지만 Java 애플릿은 이 기능을 지원하지 않는다.
네트워크 카메라는 초당 200kB 평균 전송률로 초당 4.5프레임을 포착 및 전송한다. 특히 카메라에 연결되는 지원 하드웨어가 거의 없다는 점을 명심해야 한다. 시스템에는 이미지 포착 또는 암호화 하드웨어가 없다. 다시 말하면, DS80C400이 직렬 포트를 통해 이미지 포착, 이미지 전송, 네트워크 트래픽, 웹 서비스 제공 및 사용자 상호작용을 동시에 수행한다.
결론
다시 Joe로 돌아가 보자. 자신의 제품에 TINI가 이상적 솔루션인 것을 알게 된 Joe는 네트워크 도어록 개발에 여념이 없다. 비용이 적게 들며 전력이 우수한 솔루션을 사용하여 Joe는 네트워크 도어록 시장을 점령하게 되었다. Joe는 국제적인 독점 소프트웨어 로고에도 불구하고 값이 너무 비싼 Troy의 솔루션을 쉽게 물리친다. Alex의 솔루션은 카메라 문제는 물론 네트워크 문제도 해결해야 했으므로 상용화되기에는 어려움이 있었다. Amiga는 Troy와 헤어진 후 Joe에게 다시 돌아왔으며 Joe는 다시는 컴퓨터로 인해 두 사람 사이가 멀어지는 일이 없을 것이라고 약속한다. 사업 성공으로 Joe와 Amiga는 은퇴한 후 미네소타주의 한 통나무 집에서 여생을 보낸다. 물론 이 통나무 집의 문에는 모두 네트워크 도어록(door lock)이 장착되어 있다.
내장형 장치는 구체적인 문제를 해결할 수 있도록 설계되어야 한다. 전력과 비용 간 균형을 맞추는 문제이다. 장치에 네트워크 기능을 추가하는 경우 더욱 복잡해진다. 8비트 마이크로컨트롤러를 네트워킹에 사용할 수 있도록 확장하는 것이 한 가지 방법이 될 수 있다. 물론 가능하긴 하지만 시간이 너무 오래 걸린다. 또 다른 방법은 내장형 리눅스, PC-104 또는 Pocket PC 장치를 사용하는 것이다. 신속하고 반응이 있다는 장점이 있지만 불필요하게 부피가 커질 우려가 있다. 소형 32비트 솔루션을 구축하자는 의견도 있을 수 있다. 그러나 이렇게 하려면 운영 체제 및 TCP/IP 스택에 대한 라이센스가 있어야 한다.
TINI가 적용된 DS80C400은 훌륭한 중간 솔루션으로 장 기간에 걸쳐 성능이 강화되고, 강력하며 다기능인 TCP/IP 스택을 내장하고 있다. 또한 멀티 프로세스, Java, 스레딩, 동기화 기능을 지원하는 운영 체제도 포함되어 있다. 프로세서는 중량급 운영 체제의 번거로움 없이 디지털 카메라와 대화하는 등의 부하가 큰 업무를 처리할 수 있다. 보통 사람인 Joe에게 가능한 일이라면, 여러분에게도 가능한 일이 될 것이다.
1-Wire는 Maxim Integrated Products, Inc.의 등록상표이다.
Java는 Sun Microsystems, Inc.의 상표이다.
SPI는 Motorola, Inc.의 상표이다.
TINI는 Maxim Integrated Products, Inc.의 등록상표이다.
의견을 보내주세요!
위 내용이 도움이 되셨나요?
여러분의 의견을 기다립니다 — Maxim은 보내주신 정정이나 제안사항을 반영하고 있습니다.
이 페이지를 평가하고 의견을 보내주십시오.
자동 업데이트
관심있는 분야의 애플리케이션 노트가 나올 때 자동으로 업데이트 받고 싶으세요? 그렇다면 EE-Mail™을 신청하십시오.
| 추가 정보 | |
APP 3170: Jan 11, 2006
|
|
|
|
 다운로드, PDF 형식 (72kB)
AN3170,
AN 3170,
APP3170,
Appnote3170,
Appnote 3170
|
|
