KR20020011031A

KR20020011031A - 통신 미디어 메니저를 이용한 디바이스간의 데이터리드/라이트 방법

Info

Publication number: KR20020011031A
Application number: KR1020000044414A
Authority: KR
Inventors: 김성수
Original assignee: 구자홍; 엘지전자주식회사
Priority date: 2000-07-31
Filing date: 2000-07-31
Publication date: 2002-02-07
Also published as: KR100339406B1

Abstract

본 발명은 블록 리드/라이트를 시도하려는 상위 소프트웨어 요소는 상대 디바이스의 블록 리드/라이트 가능성 여부에 상관없이 CMM의 API를 이용하여 원하는 블록 리드/라이트 크기만큼 상위 소프트웨어 요소에게 응답해 주는 API를 제안하기 위한 것으로서, HAVI 디바이스에 파워-온 또는 대기(BusReset)가 발생되면 HAVI 소프트웨어 각 요소들이 자신 및 다른 디바이스의 구성 ROM을 리드/라이트 요청하는 단계와, 요청이 입력되면 1394 통신 미디어 메니저(Communication Media Manager : CMM)는 해당 디바이스에 데이터 리드/라이트 요청을 시행하여 블록 리드/라이트가 지원 가능한지를 판단하는 단계와, 상기 판단결과 해당 디바이스가 블록 리드/라이트를 지원하면 읽은 데이터를 해당 HAVI 소프트웨어 요소에 전달하여 정상적인 동작을 수행하는 단계와, 상기 판단결과 해당 디바이스가 블록 리드/라이트를 지원하지 않으면 에러 응답을 1394 CMM에게 전달하는 단계와, 상기 에러 응답이 입력되면 1394 CMM은 해당 디바이스의 데이터 처리 범위인 데이터 쿼드렛의 길이를 파악하고, 상기 파악된 데이터 쿼드렛의 길이 만큼씩 반복 저장하여 해당되는 블록크기를 모두 읽어내는 단계와, 상기 읽어낸 데이터를 다시 모아서(reassembly) 상위 소프트웨어 요소에 블록단위로 전달하여 정상적인 동작을 수행하는 단계를 포함하여 이루어지는데 있다.

Description

통신 미디어 메니저를 이용한 디바이스간의 데이터 리드/라이트 방법{method for reading/writting data of between device using communication media manager}

본 발명은 홈네트워크 시스템에 관한 것으로, 특히 홈네트워크에서 HAVI 구조를 채용한 디바이스간의 데이터 리드/라이트 방법에 관한 것이다.

홈네트워크 시스템은 말 그대로 가정에서 PC, 주변기기, 휴대폰, 가전제품 등을 하나의 네트워크로 연결하여 통제하는 시스템을 말한다.

즉, 내부에서는 물론 외부에서도 인터넷이나 전화선을 통해 가정 내에 구축된 네트워크에 접속하여 컴퓨터나 디지털 텔레비전, 디지털 비디오 플레이어, 냉/난방기등 모든 디지털 가전제품을 제어할 수 있다.

이와 같은 홈네트워크는 최근 하나의 기기를 통해 가정 내에 있는 모든 기기들을 제어하기 위해 IEEE1394와 IEC61883 규격을 기반으로 한창 개발 진행 중에 있다.

즉, 사용자에 대해, 간단 접속과 간단 조작(hot plug&play)을 할 수 있는 환경을 제공하고, 또 GUI(Graphic User Interface)를 통하게 하여 기기에의 액세스(access)가 아닌, 내용(contents) 그 자체로 액세스하는 듯한 조작성을 제공하여야 한다.

그러기 위해서는, 우선 네트워크 상의 자원(resource)을 관리하는 표준화된미들웨어가 필요하며, 또한 장래의 호환성도 고려하여야 한다.

그 중 하나로 각 기기간의 GUI(Graphic User Interface)를 통한 동작 시나리오를 구성하여 각 기기를 제어하는 HAVI(Home Audio/Video Interoperability) 구조를 들 수 있다.

HAVI(Home Audio/Video interoperability)는 소비자의 가정에 있는 네트워크를 통해 연결된 다양한 벤더(vendor)와 상표의 디지털 오디오와 비디오장치간의 상호기능성을 제공해주는 소비자 전자산업 표준(consumer Electronic industry standard)으로서, IEEE1394와 IEC61883 규격을 기반으로, 가정내의 가전제품들과 PC 등이 홈네트워크를 구성하여 상호작용(interoperability)을 수행하게 하는 미들웨어(middle ware)이다.

한편, IEEE1394 표준(standard)은 디지털 소자들 사이를 연결하여 데이터를 교환할 수 있게 하는 시리얼 버스(serial bus)로 연결하는 것에 관한 규격으로, HAVI 명세서는 하위 계층으로 IEEE1394만을 한정한 것은 아니지만, IEEE1394 표준을 기본으로 제정되었다.

IEEE1394 표준에서는 각 소자끼리의 CSR 저항이나 IEEE1212 구성(Configuration) ROM의 내용을 기록/재생(read/write)하는 요구(request)와 응답(response)을 일련의 처리(transaction)로 규정하고 있다(IEEE1394-1995의 표 6 내지 표 9 참조 ).

상기 규정된 요구 처리는 크게 기록, 재생 그리고 잠금(lock)의 3가지 처리로 나누어 진다.

그리고 기록의 종류로는 데이터 쿼드렛(quadlet)에 대한 기록 요구와 데이터 블록에 대한 기록 요구 2종류가 있다.

또 재생은 데이터 쿼드렛에 대한 재생 요구와 데이터 블록에 대한 재생 요구 2종류가 있다.

마지막으로 잠금은 잠금 요구 1종류가 있다.

즉, 기록/재생은 데이터의 기본 단위가 1 쿼드렛(4byte) 단위이냐, 블록(복수개의 쿼드렛) 단위이냐에 따라 구분될 수 있다.

또한, 요구를 수행한 응답 코드로는 성공했을 경우에는 resp_complete, 지원되지 않는 요구 형식인 경우에는 resp_type error 코드 등이 있다.

이와 같이 HAVI 명세서에는 1394 CMM(communication media manager) 소프트웨어 요소에 CMM1394::Read, CMM1394::Write 그리고 CMM1394::Lock API(application programming interface)가 규정되어 있다.

이중의 한 예로서 CMM1394::Read API는 도 1과 같이 정의되어 있다.

그리고 IEEE1394를 채택한 소자의 내부에는 IEEE1212 구성 ROM이 있어 소자에 관한 기초적인 정보들을 포함하게 된다.

즉, IEEE1212 구성 ROM내에 GUID(Global Unique ID)를 구성하는 Node_vendor_id와 Chip_id, Module_Vendor_id, Model_Directory_Offset 등의 구성요소가 포함되어 있다.

이에 HAVI 명세서에서는 IEEE1212 구성 ROM의 기본 포맷을 호환하면서 SDD(Self Describing Device) 데이터라는 이름으로 확장하여 사용하고 있다.

다음 도 2는 HAVI 명세서에서 사용하는 IEEE1212 구성 ROM(SDD 데이터)의 한 예를 나타내고 있다.

한편, HAVI 디바이스의 HAVI 구조 소프트웨어 요소 구성은 도 3과 같다.

도 3을 보면 가정내의 기기들을 디지털 인터페이스로 연결하는 1394 장치 드라이브(300)와, 상기 1394 장치 드라이브(300)를 통해 전송되는 각 기기들 상호간에 메시지 통신으로 이벤트를 처리하는 HAVI 소프트웨어 모듈(200)과, 외부의 제어신호로 상기 HAVI 소프트웨어 모듈을 제어하는 외부 응용부(100)로 구성된다.

그리고 1394 CMM은 상기 HAVI 소프트웨어 모듈(200)내의 각 API들을 하위의 IEEE1394 장치 드라이브(300)의 처리 계층에서 리드(read), 라이트(write), 락(lock) 처리를 통해서 수행된다.

즉, IEEE1394의 처리가 지원하지 않으면 1394 CMM의 각 API도 지원할 수 없다.

따라서 HAVI의 각 소프트웨어 요소들은 각자의 필요에 의하여 자신 및 다른 디바이스의 데이터나 IEEE1212 구성(configuration) ROM을 1394 CMM의 CMM1394::read API로 읽는다.

또, FAV나 IAV의 DCM등은 자신이 호스트(host)하는 BAV나 LAV 디바이스를 제어할 때도 1394 CMM의 CMM1394::read, CMM1394::write나 CMM1394::lock API를 이용한다.

이와 같이 HAVI 디바이스는 파워-온이나 대기(bus rest)시 최우선적으로 자신 및 네트워크상에 연결된 다른 디바이스의 SDD 데이터(즉, IEEE1212 구성 ROM)를CMM1394:read 명령으로 읽어 자신의 GUID, 제조회사 명, 모델명 등을 알아내고, 네트워크상의 모든 디바이스들간에 필요한 정보를 상호교환하여 공유하게 된다.

실 예로서, 도 3의 DCM 메니저(manager)는 현 네트워크상의 디바이스들 중 DCM 메니저(manager)를 보유한 다른 HAVI 디바이스의 존재를 파악하기 위해 자신 및 다른 디바이스의 IEEE1212 구성 ROM(SDD 데이터)중의 HAVI_Device_Profile_Value(도 2의 0xFFFF F00004F0번지)를 읽어본다.

여기에서 HAVI_Device_Profile_Value가 존재하는 0xFFFF F00004F0번지(이하 0x04F0번지)를 알아내기 위해서는 몇 가지의 단계가 필요하다.

우선 DCM 메니저는 1394 CMM의 CMM1394::Read API를 이용해서 원하는 데이터를 읽는다.

이때 1단계로 0x0414번지에서 데이터 쿼드렛(quadlet) 데이터를 위한 리드 요청(HAVI에서는 CMM1394::Read)을 수행하여 루트(root) 디렉토리 길이를 알아낸다.

도 2에서는 8 쿼드렛(0x00089431)인 경우를 한 예로서 나타내고 있다.

그리고 2단계로 상기 1 단계에서 알아낸 루트 디렉토리 길이를 이용하여 0x0418번지에서부터 루트(root) 디렉토리 길이만큼을 읽어낸다.

읽어내는 방법으로 1 쿼드렛(4 바이트)씩 반복해서 읽어내거나 블록 길이(루트 디렉토리 길이) 만큼 1회에 읽어낼 수도 있다.

이때, DCM 메니저는 CMM1394::Read(데이터 크기 = 32 바이트) API를 8회 반복해서 원하는 데이터를 전부다 읽을 수밖에 없다.

이는 DCM 메니저와 같은 상위 소프트웨어 요소에게는 상당한 부담이 되며 비효율적일 것이다.

이어 상기 2단계에서 읽어낸 데이터를 분석해서 Unit_Directory_Offset(HAVI)값을 알아낸다.

그리고 3단계로 DCM 메니저는 HAVI_Unit_Directory(0x04E0번지)에서 디렉토리 길이를 읽어낸다.

이어 4단계로 상기 3단계에서 읽어낸 디렉토리 길이를 이용하여 0x0E4번지에서부터 디렉토리 길이만큼 읽어낸다.

이때 읽어내는 방법으로 쿼드렛(4 바이트)씩 반복해서 읽어내거나 블록 길이(디렉토리 길이)만큼 1회에 읽어낼 수도 있다.

그리고 5단계로 상기 4단계에서 읽어낸 HAVI_Device_Profile_Value 값을 분석하여 DCM 메니저의 존재 유무를 파악한다.

HAVI 디바이스의 소프트웨어 요소들은 각자 파워-온이나 대기(BusReset)시 초기에 위와 유사한 일을 수행한다.

그러나 이상에서 설명한 종래 기술에 따른 CMM을 이용한 디바이스간의 데이터 리드/라이트 방법은 다음과 같은 문제점이 있다.

첫째, IEEE1394 표준(standard)을 채용한 디바이스 제조사들 중에는 쿼드렛 리드/라이트만 가능하고 블록 리드/라이트는 불가능하게 설계하는 경우가 많아 호환성 및 소프트웨어 요소 설계에서도 문제점을 야기하는 수가 많다.

따라서 다른 디바이스에의 블록 리드/라이트를 시도하려는 소프트웨어 요소들은 시행착오(trial & error)로서 블록 리드/라이트 가능성 여부를 각자 판단할 수밖에 없다.

둘째, 상대 디바이스가 블록 리드/라이트를 지원하지 않으면 HAVI 구조의 각 소프트웨어 요소들은 필요한 데이터의 양만큼 쿼드렛 리드/라이트를 반복해서 블록 리드/라이트를 대용할 수밖에 없다.

이는 CMM의 API를 이용하려는 상위 소프트웨어 요소들에게 많은 부담을 주는 것이므로, HAVI 시스템 전체적으로 비효율적일 것이다.

따라서 본 발명에서는 블록 리드/라이트를 시도하려는 상위 소프트웨어 요소는 상대 디바이스의 블록 리드/라이트 가능성 여부에 상관없이 CMM의 API를 이용하여 원하는 블록 리드/라이트 크기만큼 상위 소프트웨어 요소에게 응답해 주는 API를 제안하는데 그 목적이 있다.

도 1 은 CMM1394::Read API의 한 예를 나타낸 도면

도 2 는 HAVI 명세서에서 사용하는 IEEE1212 구성 ROM(SDD 데이터)의 한 예를 나타낸 도면

도 3 은 HAVI 디바이스의 HAVI 구조 소프트웨어 요소 구성을 나타낸 도면

도 4 는 본 발명에 따른 CMM을 이용한 디바이스간의 데이터 리드/라이트 방법을 나타낸 흐름도

*도면의 주요부분에 대한 부호의 설명

100 : 외부 응용부 110 : 네이티브 응용부

120 : 자바 응용부 200 : HAVI 소프트웨어 모듈

211 : DDI 제어기 212 : 자바 가상 장치

213 : DCM 214 : FCM

215 : DCA 221 : 이벤트 매니저

222 : 레지스트리 223 : 스트림 매니저

224 : 자원 매니저 225 : DCM 매니저

226 : 메시징 시스템 227 : 1394 통신 미디어 매니저

300 : 1394 장치 드라이브

상기와 같은 목적을 달성하기 위한 본 발명에 따른 CMM을 이용한 디바이스간의 데이터 리드/라이트 방법은 HAVI 디바이스에 파워-온 또는 대기(BusReset)가 발생되면 HAVI 소프트웨어 각 요소들이 자신 및 다른 디바이스의 구성 ROM을 리드/라이트 요청하는 단계와, 요청이 입력되면 1394 통신 미디어 메니저(Communication Media Manager : CMM)는 해당 디바이스에 데이터 리드/라이트 요청을 시행하여 블록 리드/라이트가 지원 가능한지를 판단하는 단계와, 상기 판단결과 해당 디바이스가 블록 리드/라이트를 지원하면 읽은 데이터를 해당 HAVI 소프트웨어 요소에 전달하여 정상적인 동작을 수행하는 단계와, 상기 판단결과 해당 디바이스가 블록 리드/라이트를 지원하지 않으면 에러 응답을 1394 CMM에게 전달하는 단계와, 상기 에러 응답이 입력되면 1394 CMM은 해당 디바이스의 데이터 처리 범위인 데이터 쿼드렛의 길이를 파악하고, 상기 파악된 데이터 쿼드렛의 길이 만큼씩 반복 저장하여 해당되는 블록크기를 모두 읽어내는 단계와, 상기 읽어낸 데이터를 다시 모아서(reassembly) 상위 소프트웨어 요소에 블록단위로 전달하여 정상적인 동작을 수행하는 단계를 포함하여 이루어지는데 있다.

본 발명의 다른 목적, 특성 및 이점들은 첨부한 도면을 참조한 실시 예들의 상세한 설명을 통해 명백해질 것이다.

본 발명에 따른 CMM을 이용한 디바이스간의 데이터 리드/라이트 방법의 바람직한 실시 예에 대하여 첨부한 도면을 참조하여 설명하면 다음과 같다.

HAVI 구조의 CMM1394의 API는 CMM1394::read, CMM1394::write나 CMM1394::lock이 있으며, 설명의 간략화를 위해 그 중 CMM1394::Read 한가지 경우만을 예로서 설명하겠다.

그리고 그 외의 CMM1394::write나 CMM1394::lock의 경우도 이하 설명되는 CMM1394::Read와 동일하다.

도 4 는 본 발명에 따른 CMM을 이용한 디바이스간의 데이터 리드/라이트 방법을 나타낸 흐름도이다.

도 4를 참조하여 설명하면 먼저, DTV 등의 HAVI 디바이스에 파워-온이나 대기(BusReset)가 발생하면(S10), HAVI 소프트웨어 요소들은 각자의 필요에 의해 자신 및 다른 디바이스의 구성 ROM을 리드/라이트 요청하게 된다(S20).

이때, 1394 통신 미디어 메니저(Communication Media Manager : CMM)는 1394CMM::Read/Write API를 이용하여, IEEE1394 처리 계층의 도움으로 데이터 리드/라이트를 수행한다.

이때 각 소프트웨어 요소들은 자신 및 상대 드라이브의 블록 리드/라이트 지원여부에 상관없이 원하는 양만큼 CMM1394::Read(데이터 크기 = 원하는 바이트 수) API를 통해 요청한다.

그리고 각 디바이스에서 블록 리드 요청이 들어오면 1394 CMM은 해당 디바이스에 데이터 블록을 위한 데이터 리드/라이트 요청을 시행해 본다(S30).

상기 데이터 리드/라이트 요청을 시행하여 상기 데이터를 리드/라이트하는 디바이스가 블록 리드/라이트를 지원하는지를 판단한다(S40).

상기 판단결과 해당 디바이스가 블록 리드/라이트를 지원하면 읽은 데이터를 해당 HAVI 소프트웨어 요소에 전달하여(S90) 정상적인 동작을 수행한다(S100).

상기 판단결과 해당 디바이스가 블록 리드/라이트를 지원하지 않으면 resp_type_error(IEEE1394-1995의 테이블 6~11 참조)와 같은 형태의 에러 응답을 1394 CMM에게 전달한다(S50).

그리고 상기 resp_type_error의 에러 응답이 오면 1394 CMM은 해당 디바이스의 데이터 처리 범위인 데이터 쿼드렛을 파악한다(S60).

이어 파악된 데이터 쿼드렛의 길이 만큼씩 반복 저장하여 해당되는 블록크기를 모두 읽어낸다(S70).

즉, 상기 데이터 쿼드렛이 4 바이트이고 블록 데이터의 크기가 32 바이트인 경우 1394 CMM은 자체적으로 CMM1394::Read API를 8회 반복해서 해당 블록만큼 읽어낸다.

그리고 8회 반복해서 읽어낸 데이터를 다시 모아서(reassembly) 상위 소프트웨어 요소에 블록단위로 전달한다(S80).

이와 같은 방법으로 종래의 블록단위와 데이터 쿼드렛 단위로 발생되는 에러 코드를 1394 CMM 자체적으로 성공적으로 해결하게 된다(S100).

만약 데이터 쿼드렛을 위한 데이터 요청을 읽는 도중에 에러 응답이 오면 에러 응답의 종류에 따라 적절하게 에러 코드로 응답한다.

이로써 블록 리드/라이트를 시행 착오하는데 소요될 수 있는 불필요한 시간을 줄이고 각 소프트웨어 요소들의 효율을 향상시켜, 결국 시스템의 성능 향상을 도모할 수 있다.

CMM1394::Write나 CMM1394::Lock API도 위와 유사한 과정으로 실현시킬 수 있다.

이상에서 설명한 바와 같은 본 발명에 따른 CMM을 이용한 디바이스간의 데이터 리드/라이트 방법은 HAVI 구조를 채택한 디바이스들에서 다른 디바이스들과의 블록 리드/라이트를 해당 디바이스의 지원여부에 관계없이 CMM이 처리하여 줌으로써, 다른 소프트웨어 요소들의 시행착오를 줄일 수 있고, 그에 따라 전체 HAVI 디바이스의 성능 향상시킬 수 있다.

이상 설명한 내용을 통해 당업자라면 본 발명의 기술 사상을 이탈하지 아니하는 범위에서 다양한 변경 및 수정이 가능함을 알 수 있을 것이다.

따라서, 본 발명의 기술적 범위는 실시 예에 기재된 내용으로 한정되는 것이 아니라 특허 청구의 범위에 의하여 정해져야 한다.

Claims

HAVI 디바이스에 파워-온 또는 대기(BusReset)가 발생되면 HAVI 소프트웨어 각 요소들이 자신 및 다른 디바이스의 구성 ROM을 리드/라이트 요청하는 단계와,

요청이 입력되면 1394 통신 미디어 메니저(Communication Media Manager : CMM)는 해당 디바이스에 데이터 리드/라이트 요청을 시행하여 블록 리드/라이트가 지원 가능한지를 판단하는 단계와,

상기 판단결과 해당 디바이스가 블록 리드/라이트를 지원하면 읽은 데이터를 해당 HAVI 소프트웨어 요소에 전달하여 정상적인 동작을 수행하는 단계와,

상기 판단결과 해당 디바이스가 블록 리드/라이트를 지원하지 않으면 에러 응답을 1394 CMM에게 전달하는 단계와,

상기 에러 응답이 입력되면 1394 CMM은 해당 디바이스의 데이터 처리 범위인 데이터 쿼드렛의 길이를 파악하고, 상기 파악된 데이터 쿼드렛의 길이 만큼씩 반복 저장하여 해당되는 블록크기를 모두 읽어내는 단계와,

상기 읽어낸 데이터를 다시 모아서(reassembly) 상위 소프트웨어 요소에 블록단위로 전달하여 정상적인 동작을 수행하는 단계를 포함하여 이루어지는 것을 특징으로 하는 CMM을 이용한 디바이스간의 데이터 리드/라이트 방법.