KR100472908B1

KR100472908B1 - 버스구조를통한데이터전송및버스관리를위한애플리케이션프로그래밍인터페이스

Info

Publication number: KR100472908B1
Application number: KR10-1998-0705954A
Authority: KR
Inventors: 스코트 디. 스마이어스; 브루스 페어맨
Original assignee: 소니 일렉트로닉스 인코포레이티드
Priority date: 1996-02-02
Filing date: 1997-01-29
Publication date: 2005-07-21
Also published as: ATE199987T1; DE69704344T2; US6243783B1; JP2000510659A; DE69723726D1; EP0877983B1; CA2244713C; EP1056016A2; AU1855797A; EP1056016A3; US5991520A; KR19990082226A; DE69704344D1; TW317623B; CA2244713A1; EP0952526A3; EP2284713A3; JP3993893B2; EP2284713A2; WO1997028504A1

Abstract

애플리케이션 프로그래밍 인터페이스는 애플리케이션과 버스 구조 사이에서 등시성 및 비동기 데이터 전송 동작을 실현하고 관리한다. 비동기 전송 도중에, API는, 애플리케이션 내의 하나 또는 그 이상의 로컬 데이터 버퍼와 버스 구조 위의 어드레스 범위 사이에서, 하나 또는 그 이상의 비동기 트랜잭션을 사용하여 임의의 데이터 양을 전송하는 능력을 포함한다. 자동 트랜잭션 생성기는 데이터 전송을 종결하기 위하여 필요한 트랜잭션을 자동으로 생성하기 위하여 사용될 수 있다. API는 또한, 전용 채널 위에서 등시적으로, 애플리케이션과 버스 구조상의 다른 노드 사이의 데이터를 전송하는 능력을 포함한다. 등시성 데이터 전송 도중에, 버퍼 관리 구조는 데이터 버퍼 기술자의 연결된 목록을 관리하기 위하여 사용된다. 이러한 연결된 기술자 목록은 버퍼의 원형 목록을 구성할 수 있고, 각 버퍼를 위하여, 목록 내에서 다음 버퍼에 대한 전방 포인터와, 목록 내에서 이전 버퍼에 대한 후방 포인터를 포함할 수 있다. 연결된 기술자 목록은, 애플리케이션이 부가적인 버퍼를 부가하거나 목록으로부터 현존 버퍼를 제거할 수 있는 선형 목록을 형성할 수도 있다. 데이터의 등시성 전송 도중에, API는, 애플리케이션에 의한 데이터 내의 특정 시점에 대한 재동기화를 허용하는, 데이터의 스트림 내에서 재동기화 이벤트가 실현된다. 데이터 전송 도중의 소정의 시점에 애플리케이션을 호출하는, 목록 내의 각 버퍼를 위한 콜백 루틴이 또한 실현된다.

Description

버스 구조를 통한 데이터 전송 및 버스 관리를 위한 애플리케이션 프로그래밍 인터페이스{APPLICATION PROGRAMMING INTERFACE FOR DATA TRANSFER AND BUS MANAGEMENT OVER A BUS STRUCTURE}

본 발명은 버스 구조를 통해 통신하는 애플리케이션을 위한 인터페이스를 제공하는 분야에 관한 것이다. 특히, 본 발명은 버스 구조를 통해 비동기 및 등시성(isochronous) 포맷 모두로 애플리케이션 사이에서 버스 관리 및 데이터 전송 동작을 제어하는 분야에 판한 것이다.

IEEE 1394 표준("고성능 직렬 버스를 위한 P1394 표준" 초안 8.01vl, 1995년 6월 16일)은, 비동기 및 등시성 포맷의 데이터 전송을 모두 지원하는 값이 비싸지 않은 고속 직렬 버스 구조를 실현하기 위한 국제 표준이다. 등시성 데이터 전송은, 중요한 순간 사이의 시간 간격이 송신 및 수신 애플리케이션 모두에서 동일한 지속 간격을 갖도록, 발생하는 실시간 전송이다. 등시적으로 전송된 데이터의 각 패킷은 자신의 시간 주기 내에서 전송된다. 이상적인 등시적 데이터 전송 애플리케이션의 예는 비디오 레코더로부터 텔레비전 세트로 전송되는 예이다. 비디오 레코더는 영상과 음향을 기록하고, 데이터를 이산적인 덩어리 또는 패킷으로 저장한다. 그 후, 비디오 레코더는, 텔레비전 세트에 의한 디스플레이를 위하여, 제한된 시간 기간에 대해 기록된 영상 및 음향을 나타내는 각 패킷을 상기 시간 기간 동안에 전송한다. IEEE 1394 표준의 버스 구조는 애플리케이션 사이의 등시성 데이터 전송을 위한 다중 채널을 제공한다. 6비트의 채널 번호가 적절한 애플리케이션에 의한 수신을 보장하기 위하여 데이터와 함께 방송된다. 이것은 복수의 애플리케이션이 버스 구조를 통과하여 동시에 등시성 데이터를 전송하도록 허용한다. 비동기 전송은, 가능한 신속하게 발생하고, 소스로부터의 소정량의 데이터를 목적지에 전송하는, 종래의 데이터 전송이다.

IEEE 1394 표준은 디지털 장치들을 상호 접속시키는 고속 직렬버스를 제공하고, 이에 따른 범용 I/O 접속을 제공한다. IEEE 1394 표준은 애플리케이션을 위한 디지털 인터페이스를 한정하고, 이에 의해, 애플리케이션이 디지털 데이터를 버스를 통하여 전송하기 전에 아날로그 데이터로 변환하는 필요성을 제거한다. 상응하게 수신 애플리케이션은 버스로부터 아날로그 아닌 디지털 데이터를 수신할 것이고, 따라서 아날로그 데이터를 디지털 데이터로 변환할 필요가 없다. IEEE 1394 표준에 의해 요구되는 케이블은 이러한 장치를 연결하기 위해 사용되는 부피가 큰 다른 케이블과 비교하여 크기에서 매우 가늘다. 버스가 활성인 동안, 장치는 IEEE 1394 버스로부터 부가되거나 제거될 수 있다. 장치가 이렇게 부가되거나 제거된다면, 버스는 자동적으로 현존하는 노드 사이에서 데이터를 전송하기 위하여 자신을 재구성한다. 노드는 버스 구조상에서 유일한 어드레스를 갖는 논리적인 실체(entity)로 간주된다. 각 노드는 확인 ROM, 제어 레지스터의 표준화된 세트와 자신의 어드레스 공간을 제공한다.

IEEE 1394 표준은 도 1에 도시된 바와 같이 프로토콜을 한정한다. 이러한 프로토콜은 트랜잭션 층(12), 연결(link) 층(14) 및 물리 층(16)에 연결된 직렬 버스 관리 블록(10)을 포함한다. 물리 층(16)은 장치 또는 애플리케이션과 IEEE 1394 케이블 사이의 전기적 및 기계적인 접속을 제공한다. 물리 층(16)은 또한, IEEE 1394 버스에 접속된 모든 장치가 실제 데이터 전송 및 수신과 버스에 억세스하는 것을 보장하기 위한 중재(arbitration)를 제공한다. 연결 층(14)은 비동기 및 등시성 데이터 패킷 운송 모두를 위한 데이터 패킷 전달 서비스를 제공한다. 이것은, 승인 프로토콜을 사용하는 비동기 데이터 운송과, 정시(just-in-time) 데이터 전송을 위한 실시간 보장된 대역폭 프로토콜을 제공하는 등시성 데이터 운송 모두를 지원한다. 트랜잭션 층(12)은 판독, 기록 및 로크(lock)를 포함하는 비동기 데이터 전송을 완결시키기 위해 필요한 명령을 지원한다. 직렬 버스 관리 블록(10)은 등시성 데이터 전송을 관리하기 위한 등시성 소스 관리자를 포함한다. 직렬 버스 관리 블록(10)은 또한, 중재 타이밍을 최적화하는 형태로 직렬 버스의 전체적인 구성 제어와, 버스 상의 모든 장치를 위한 적절한 전기적인 출력의 보장과, 사이클 마스터의 할당과, 등시성 채널과 대역폭 소스의 할당, 및 에러의 기본적인 통지를 제공한다.

IEEE 1394 표준의 직렬 버스를 사용하는 애플리케이션을 위한 애플리케이션 프로그래밍 인터페이스(API)는, 애플리케이션이 데이터 전송을 위해 IEEE 1394 버스를 사용할 수 있도록 하기 위하여, 스킵스톤(Skipstone) 사에 의해 개발되어 있다. 이들 API에 대해, 미국, 텍사스 78759, 오스틴, # 425, 웨스트 브레이커 레인 3925에 소재하는 스킵스톤 사로부터 취득 가능한 "직렬 소프트 IEEE 1394 디벨로 퍼 툴키트" 라는 명칭의 소책자를 포함한다. 스킵스톤은 이들의 API를, IEEE 1394 버스 상에서 장치에 기록되거나 또는 이로부터 얻어지는 데이터를 관리하기 위한 애플리케이션에 의해 사용되려 하는 프로그래밍 호출의 집합으로서 한정한다. 등시성 전송을 초기화하기 위하여, 몇 가지 비동기 데이터 전송이 애플리케이션을 구성하고, 데이터 전송을 위해 사용될 특정 채널을 결정하는데 요구될 수 있다. 일단 채널이 결정되면, 데이터를 보내기 전에 데이터를 저장하는 전송 애플리케이션과, 처리되기 전에 데이터를 저장하는 수신 애플리케이션에서 버퍼가 사용된다. 전송 애플리케이션에 있어서, 스킵스톤 API는, 적절한 시간 기간 도중에, 능동적으로 버스 구조상에서 적절한 버퍼의 적절한 부분으로부터의 데이터의 전송을 관리한다. 수신 애플리케이션에 있어서, 스킵스톤 API는 능동적으로, 적절한 버퍼의 적절한 부분에 데이터를 저장하는 버스 구조로부터 데이터의 수신과, 적절한 시간 기간에서 데이터의 처리를 관리한다.

비동기 데이터 전송 도중에, 스킵스톤 API는 능동적으로 데이터 전송을 완결시키기 위해 요청되는 트랜잭션을 관리한다. 비동기 인입 기록 트랜잭션 도중에, 애플리케이션은, 1394 버스 어드레스 공간의 특정 영역에 맵핑된(mapped) 버퍼를 API에 제공한다. 기록 트랜잭션이 API에 도달함에 따라, 이들의 데이터는 버퍼에 저장된다. 비동기 인입 판독 트랜잭션 도중에, 애플리케이션은 버퍼가 유효한 정보를 포함하는 것을 보장할 책임이 있다. 그후 1394 버스 드라이버는, 판독 트랜잭 션이 도달할 때, 요청된 어드레스에서의 버퍼로부터 데이터를 판독한다. 기록 및 판독 트랜잭션 모두를 위해, 스킵스톤 API는 능동적으로 필요한 각 트랜잭션을 관리하고 생성한다. 예컨대, 데이터의 한 블록이 다중 트랜잭션을 요청하는 크기로 애플리케이션에 전달되고 있다면, 스킵스톤 API는 상기 애플리케이션으로 하여금 데이터의 상기 블록의 전달을 완결하기 위하여 필요한 각 1394 트랜잭션을 기술하도록 요구한다. 이것은, 비동기 데이터 전송 동작 도중에, API에 대한 최대한의 주의를 요할 뿐만 아니라 상기 애플리케이션의 프로세서에 의한 상당한 오버헤드(overhead)가 소비하게 한다.

스킵스톤 API는 유사한 방법으로 등시성 데이터 전송 동작을 지원한다. 특히, 상기 애플리케이션은 각 등시성 패킷을 스킵스톤 API에 기술하여만 한다. 그 후 스킵스톤 API는 각 패킷을 적절한 시간에 전달한다. 이것은 상당한 프로세서 오버헤드를 필요로 하고, 이에 의해 상기 애플리케이션에 의한 등시성 데이터의 효율적인 처리를 방해한다.

API에 의한 통제와 애플리케이션의 프로세서를 필요로 함이 없이, 데이터 전송을 완결하기 위해 필요한 트랜잭션의 자동화된 생성을 제공하는 API가 필요하다. 애플리케이션에 의해 필요하다면, 높은 정도의 하드웨어 자동화를 허용하면서, IEEE 1394 표준 버스 구조의 등시성 전송 특성을 매우 효율적으로 실현하는 API가 추가로 필요하다.

도 1은 IEEE 1394 표준에 의해 한정된 프로토콜을 도시하는 도면.

도 2는 버스 구조를 포함하는 시스템 내에서 API의 블록도 구조를 도시하는 도면.

도 3은 입/출력(I/O)버스(56 및 58)에 의해 함께 연결된 비디오 카메라(50), 비디오카세트 레코더(52) 및 컴퓨터(54)를 포함하는 시스템을 도시하는 도면.

도 4는 본 발명의 API를 실현하기 위하여, 각 시스템 내에서 존재하는 하드웨어 시스템의 블록도.

도 5는 애플리케이션에 의해 API(20)에 할당된 버퍼에 대응하는 버퍼 기술자의 목록을 도시하는 도면.

도 6은 등시성 전송 및 수신 동작을 위한 API 버퍼 처리를 도시하는 흐름도.

애플리케이션 프로그래밍 인터페이스는, 애플리케이션과 버스 구조 사이에서 등시성 및 비동기 데이터 전송 동작을 실현하고 관리한다. 비동기 전송 도중에, API는 하나 이상의 비동기 트랜잭션을 사용하여, 애플리케이션 내의 하나 이상의 로컬 데이터 버퍼와 버스 구조 위의 어드레스의 범위 사이에서 임의의 양의 데이터를 전달하는 능력을 포함한다. 자동 트랜잭션 생성기는, 애플리케이션 프로그래밍 인터페이스에 의한 직접 프로세서 제어 또는 통제 없이, 데이터 전송을 완결하기 위하여 필요한 트랜잭션을 자동적으로 생성하는데 사용될 수 있다. API는 또한, 전용 채널을 통하여 등시적으로, 애플리케이션과 버스 구조상에서의 다른 노드 사이에서 데이터를 전달하는 능력을 포함한다. 등시성 데이터 전송 도중에, 버퍼 관리구조는 애플리케이션에 의해 제공된 데이터 버퍼 기술자(descriptors)의 연결된 목록을 관리하는데 사용된다. 버퍼 기술자의 연결된 목록은, 등시성 데이터의 연속 스트림의 중단되지 않는 흐름을 보장하기 위하여, API에 의해 유지된다. 이러한 연결된 기술자 목록은 버퍼의 원형 목록을 구성할 수 있고, 각 버퍼를 위하여 목록 내에서 다음 버퍼에 대한 전방(forward) 포인터와, 목록 내에서 이전 버퍼에 대한 후방(backward) 포인터를 포함할 수 있다. 연결된 기술자 목록은, 애플리케이션이 부가적인 버퍼를 부가하거나 목록으로부터 현존 버퍼를 제거할 수 있는, 선형 목록을 구성할 수도 있다. 데이터의 등시성 전달 도중에, API는 데이터 내의 특정 시점에 대한 애플리케이션의 재동기화를 허용하는, 데이터 스트림 내의 재동기화 이벤트(event)의 실현을 제공한다. 실현은 또한, 데이터의 전다 도중에 소정의 시점에 상기 애플리케이션을 호출하는, 목록 내의 각 버퍼를 위한 콜백(callback) 루틴을 제공한다.

도 3은 입/출력(I/O)버스(56 및 58)에 의해 함께 연결된 비디오 카메라(50), 비디오카세트 레코더(52) 및 컴퓨터(54)를 포함하는 시스템을 도시한다. I/O 버스(56)는 비디오 카메라(50)를 비디오카세트 레코더(52)에 접속시켜, 비디오 카메라(50)가 기록을 위하여 데이터를 비디오카세트 레코더(52)로 보내도록 허용한다. I/O 버스(58)는 비디오카세트 레코더(52)를 컴퓨터(54)에 접속시켜, 비디오카세트 레코더(52)가 디스플레이를 위해 데이터를 컴퓨터(54)로 보내도록 허용한다.

본 발명에 따른 애플리케이션 프로그래밍 인터페이스(API)는, 버스 구조(56 및 58)를 가로질러 통신되는 데이터 전송 동작을 제어하기 위하여, 비디오 카메라(50), 비디오카세트 레코더(52) 또는 컴퓨터(54)를 포함하는 연결된 서브시스템의 임의의 하나 또는 모두에서 실현될 수 있다. 본 발명의 양호한 실시예에 있어서, 버스 구조(56 및 58)는 IEEE 1394 표준 케이블이다.

본 발명의 애플리케이션 프로그래밍 인터페이스를 실현하기 위해 각 시스템 내에 존재하는 하드웨어 시스템의 블록도는 도 4에 도시되었다. 도 4에 도시된 하드웨어 시스템에 있어서, 인쇄 회로 기판(60)은 사용자 인터페이스(70)에 접속된다. 인쇄 회로 기판(60)은 시스템 버스(68)에 의해 시스템 메모리(64)와 I/O 버스 인터페이스(66)에 접속된 중앙 처리 유니트(CPU)(62)를 포함한다. 사용자 인터페이스(70)는 또한 시스템 버스(68)에 접속된다. 사용자 인터페이스(70)는 서브시스템 마다 다르지만(subsystem specific), 서브시스템의 사용자와 통신하기 위한 키보드, 디스플레이 또는 다른 I/O 장치를 포함할 수 있다.

비디오 카메라(50), 비디오카세트 레코더(52) 및 컴퓨터(54)를 포함하는 각 서브 시스템은, 본 발명의 애플리케이션 프로그래밍 인터페이스를 실현하기 위하여, 도 4에 도시된 시스템과 같은 하드웨어 시스템을 포함할 것이다. 이들 각 장치 내의 CPU(62)는 애플리케이션 프로그램 지령을 실행하기 위해 사용된다. 따라서 본 발명의 API는, 적절한 하나의 버스(56 또는 58)를 통해, 상주 서브시스템과 다른 서브시스템 중 하나 사이에서 등시성 및 비동기 데이터 전송 동작을 관리할 것이다.

본 발명에 따른 애플리케이션 프로그래밍 인터페이스는, 버스 구조 통하여 애플리케이션을 향하는 및 애플리케이션으로부터 나오는 등시성 및 비동기 데이터 전송을 실현한다. 여기에서 사용된 애플리케이션은 애플리케이션 드라이버 또는 장치 드라이버라고 언급된다. 데이터 전송 동작이 완결되는 버스 구조는 IEEE 1394 표준 버스 구조인 것이 바람직하다. 그러나, 당업자에게는 명백한 바와 같이, 본 발명의 애플리케이션 프로그래밍 인터페이스는 또한 다른 형태의 버스 구조를 통하는 데이터 전송을 관리하는 용도로 적용될 수 있다. 애플리케이션 프로그래밍 인터페이스는, 하나 이상의 비동기 트랜잭션을 사용하는 버스 구조를 통하여, 애플리케이션에 의해 제공된 로컬 데이터 버퍼와 어드레스 범위 사이에서 임의의 양의 데이터를 전달하는 능력을 포함한다. 데이터 블록의 비동기 전송이 시작될 때, 애플리케이션 프로그래밍 인터페이스는 자동 트랜잭션 생성기에 명령을 보낸다. 그 후 자동 트랜잭션 생성기는, 직접적인 프로세서 제어가 없이, 또는 애플리케이션 프로그래밍 인터페이스에 의한 통제를 요구함이 없이, 완전한 데이터 블록을 비동기적으로 전달하기 위하여 필요한 판독 또는 기록 트랜잭션을 자동적으로 생성한다.

애플리케이션 프로그래밍 인터페이스는 또한, 전용 채널을 통하여, 애플리케이션과 버스 구조상의 다른 노드 사이에서 데이터를 등시적으로 전달하는 능력을 포함한다. 등시성 데이터 전송 도중에, 버퍼 관리 구조는 애플리케이션 내의 데이터 버퍼를 관리하는데 사용된다. 애플리케이션은 전달될 데이터의 형태와 양에 따라, 버퍼의 하나, 하나 이상 또는 연결된 목록을 사용할 수 있다. 버퍼를 지시하는 버퍼 기술자의 연결된 목록은, 등시성 데이터의 연속 스트림의 중단되지 않는 흐름을 보장하기 위하여, API에 의해 유지된다. 이러한 연결된 기술자 목록은 버퍼의 선형 또는 원형 목록을 실현할 수 있고, 각 버퍼를 위하여 목록 내에서 다음 버퍼에 대한 기술자를 위한 전방 포인터와 목록 내에서 이전 버퍼에 대한 기술자를 위한 후방 포인터를 포함할 수 있다. 선형 목록이 실현될 때, 애플리케이션은 데이터의 처리를 위해 필요에 따라, 다이내믹하게 버퍼를 목록에 추가하거나, 목록으로부터 현존 버퍼를 제거할 수 있다.

데이터의 등시성 전달 도중에, 본 발명의 애플리케이션 프로그래밍 인터페이스는, 데이터 내에서의 특정 시점에 대한 재동기화를 허용하는 데이터 스트림 내에서 재동기화 이벤트의 실현을 제공한다. 실현은 또한, 데이터 전송 동작 도중에 소정의 특정 시점에서 애플리케이션을 호출하는, 각 버퍼를 위한 콜백 루틴을 제공된다. 재동기화 이벤트와 콜백 루틴 모두 IEEE 1394 표준에 의해 지원된다.

본 발명의 애플리케이션 프로그래밍 인터페이스는 또한 버스 구조를 통하여 필요에 따라 버스 관리 동작을 수행하는 능력을 포함한다. 이러한 버스 관리 동작은 필요에 따라 등시성 채널 번호를 할당 및 할당해제하는 것, 및 등시성 대역폭을 할당 및 할당해제하는 것을 포함한다. 버스 구조가 IEEE 1394 표준 버스 구조라면, 애플리케이션 프로그래밍 인터페이스는 IEEE 1394 표준에 의해 요청되는 다른 버스 관리 동작을 수행하기도 한다.

버스 구조를 포함하는 시스템 내의 본 발명에 따른 애플리케이션 프로그래밍 인터페이스의 블록도 구조는 도 2에 도시되었다. API(20)는 애플리케이션(22 및 24)과 버스 구조(28) 사이의 인터페이스로 작용하여, 버스 구조(28)와 애플리케이션(22 및 24) 사이의 데이터 전송을 관리한다. 도 2에 도시된 바와 같이, 단일 API(20)은 복수의 애플리케이션과 버스 구조(28) 사이의 인터페이스로서 작용할 수 있다. 예컨대, 도 3에 도시된 컴퓨터 시스템(54) 내에서, 단일의 API(20)는 컴퓨터 시스템(54)에 의해 구동되는 하나 이상의 애플리케이션 사이에서의 인터페이스로 작용할 수 있다.

하드웨어 및 물리적인 인터페이스(26)는 API(20)와 버스 구조(28) 사이에 포함된다. 하드웨어 및 물리적인 인터페이스(26)는, 하나의 애플리케이션(22 또는 24)과 버스 구조(28)상의 다른 노드 사이의 비동기 데이터 전송의 완결을 위해 필요한 트랜잭션을 자동적으로 생성하기 위하여 자동 트랜잭션 생성기(38)를 포함한다. 하드웨어 및 물리적인 인터페이스(26)는 또한, 버스 구조(28)를 향한 및 이로부터의 데이터의 흐름을 감시하고 관리하기 위한 버스 인터페이스(40)를 포함한다. 하드웨어 및 물리적인 인터페이스(26)는, API(20)에 의해 제어되는, 한 세트의 메모리 버퍼(30)에 접속된 것으로 도시되었다. 한 세트의 메모리 버퍼(30)에는 메모리 버퍼(32, 34 및 36)가 포함된다. 이하에서 설명되는 바와 같이, 메모리 버퍼(32, 34 및 36)는 애플리케이션(22)에 그리고 애플리케이션(22)으로부터의 등시성 데이터 전송을 지속하는 용도를 위하여 애플리케이션(22)에 의해 API(20)에 제공된다.

등시성 데이터 전송

등시성 데이터 전송 동작을 개시하기 위하여, 애플리케이션은 먼저 API(20)로부터 등시성 채널을 요청한다. 애플리케이션은 특정 채널 번호 또는 임의의 현재 유효한 채널 번호를 요청할 수 있다. API(20)는 그 후 IEEE 1394 표준의 요건에 따라 등시성 전달을 위한 채널을 얻는다. IEEE 1394 표준은 버스 구조(28)를 가로질러 데이터 스트림과 함께 방송되는 6 비트의 채널 번호를 지원한다. 애플리케이션과 버스 구조(28)상의 다른 노드 사이의 등시성 데이터 전송을 위해 일단 한 채널이 할당되면, 어떠한 다른 노드도 상기 특정 채널 번호를 사용할 수 없다. 채널이 할당된 후, 데이터 버퍼는 애플리케이션에 의해 데이터 전송을 위해 사용될 API(20)에 할당되어야만 한다. API(20)는 상기 애플리케이션이 데이터의 버퍼 중 하나, 하나 이상 또는 목록을 데이터의 등시성 스트림을 수신하거나 전송하는 용도에 할당하는 것을 허용한다. API(20)에 할당된 각 버퍼는 연속적(contiguous)이거나 또는 단편적(fragmented)일 수 있고, 논리적이거나 물리적일 수 있다. 데이터 버퍼의 목록은 원형 또는 선형일 수 있다. 데이터 버퍼의 선형 목록이 API(20)에 할당되면, 애플리케이션(22)은 데이터를 처리하기 위하여 필요에 따라 부가적인 버퍼를 부가하거나, 목록으로부터 버퍼를 제거할 수 있다.

도 2에 도시된 시스템에 있어서, 등시성 데이터 전송을 위하여 애플리케이션(22)은 버퍼(32, 34 및 36)를 포함하는 세 개의 버퍼(30)를 API(20)에 할당한다. 상기 애플리케이션은 또한 세 개의 버퍼 기술자의 연결된 목록을 API에 할당하는데, 버퍼(32, 34 및 36) 각각에 대해 하나씩 할당한다. API(20)는 연결된 목록 내에서 각 버퍼를 위하여 버퍼 기술자를 유지하고, 애플리케이션, 할당된 버퍼 및 버스 구조(28) 사이에서 등시성 데이터의 흐름을 관리한다. API(20)에 의해 관리되는 기술자 목록 내에서, 각 버퍼는 버퍼 기술자에 의해 표시되는데, 상기 버퍼 기술자는 목록 내에서 다음 버퍼를 위한 기술자에 대한 전방 포인터와 목록 내에서 이전 버퍼를 위한 기술자에 대한 후방 포인터를 포함한다. 애플리케이션에 의해 API(20)에 할당된 버퍼에 대응하는 버퍼 기술자의 목록은 도 5에 도시되었다. 각 버퍼 기술자(1-n)는 메모리 버퍼(1-n)에 대응한다. 특히, 버퍼 기술자(80)는 메모리 버퍼(84)에 대응하고, 버퍼 기술자(82)는 메모리 버퍼(86)에 대응한다.

버퍼 기술자 각각은 대응하는 버퍼의 어드레스와 길이를 포함한다. 버퍼 기술자는 또한, 현재 데이터 전송 동작의 방향에 따라, 버퍼가 채워지거나 비워진 후 호출하기 위한 콜백 완결 루틴을 포함한다. 버퍼 기술자는, 애플리케이션에 의해 프로그램되며, 버퍼가 특정 이벤트 또는 시간에 어떻게 동기화되는 지에 대한 선택적인 동기화 이벤트 필드를 더 포함한다. 특히, 메모리 버퍼(84)에 대응하는 버퍼 기술자(80)는 메모리 버퍼(84)를 위한 어드레스(80a)와 길이(80b)를 포함한다. 필요하다면, 완결(즉, 종결) 루틴(80c)과 동기화 이벤트(80d)가 역시 포함된다.

버퍼 기술자와 메모리 버퍼의 이러한 용도는 본 발명의 API를 사용하는 애플리케이션에 큰 유연성을 허용하는데, 왜냐하면 기술자, 버퍼, 완결 루틴 및 동기화 이벤트 모두가 특정 필요에 따른 애플리케이션에 의해 설정되기 때문이다. 한 예로서, 디지털 비디오 모니터에 데이터를 등시적으로 전달하는 디지털 비디오 카메라 내에서 동작중인 애플리케이션에 대해, 데이터는 API가 버퍼 기술자를 유지하는 메모리 버퍼 내에 로드된다. 그 후 API는 버퍼로부터 비디오 모니터로의 각 데이터 패킷의 전달을 관리한다. 비디오 카메라는 기술자 쌍이 동일한 메모리 버퍼를 지시하도록 함으로써, 수직 범위에서 두 배(2x)의 압축 특성을 실현할 수 있다. 즉, 기술자(1 및 2)는 메모리 버퍼(1)를 지시할 것이고, 기술자(3 및 4)는 메모리 버퍼(2)를 지시할 것이며, 이후도 이처럼 된다. 각 쌍의 제 2 기술자에서 완결 루틴은 메모리 버퍼 내의 데이터가 판독될 준비가 되었음을 비디오 모니터에 알린다. 이것은, 비디오 카메라가 제 1 및 제 2 주사 라인 데이터를 출력함에 따라, 제 2 주사 라인 데이터가 메모리 버퍼 내에서 제 1 주사 라인 데이터 위에 제 2 주사 라인 데이터로 덮어 기록하는 것을 의미한다. 비디오 모니터는, 제 2 주사 라인이 기록되후 모니터가 제 1 주사 라인 데이터를 볼 수 없을 때까지, 메모리 버퍼를 판독하지 않는다. 이러한 방법에 있어서, 모든 다른 주사 라인은 스킵된다(skipped).

기술자는 목록이 사실상 원형이 되도록 허용하여, 버퍼(32, 34 및 36)로 또는 이로부터 연속적인 데이터 스트림을 유지한다. 버스 구조(28)를 따라 애플리케이션(22)으로부터 다른 노드로의 등시성 데이터 전송 도중에, 애플리케이션(22)은 버퍼(32, 34 및 36)를 차례로 데이터로 채운다. 그 후, API(20)는 적절한 시간 기간 동안에 적절한 버퍼로부터 버스 구조(28)로의 데이터의 전달을 관리한다. 하드웨어 및 물리적인 인터페이스(26) 내의 버스 인터페이스(40)는 버퍼(32, 34 및 36)로부터 버스 구조(28)상으로의 데이터 전송을 제어한다. 다른 노드로부터 버스 구조(28)를 따라 애플리케이션(22)으로의 등시성 데이터 전송 도중에, API(20)는 버스 구조(28)로부터 버스 인터페이스(40)를 통해 적절한 버퍼(32, 34 및 36)로의 데이터 전송을 관리한다. 할당된 하나의 버퍼가 채워짐에 따라, 데이터는 연결된 목록 내의 다음 버퍼에 저장된다. 그 후 애플리케이션(22)은 적절한 시간 기간 도중에 적절한 하나의 버퍼(32, 34 및 36)로부터 데이터를 판독한다. 일단 애플리케이션(22)이 버퍼로부터 데이터 판독을 종료하면, 상기 버퍼는 API(20)에 다시 제공되고, 애플리케이션(22)은 다음 버퍼로부터의 데이터를 처리한다.

버퍼 기술자는 또한, 데이터 전송 동작을 완결하는데 필요한대로, 애플리케이션으로 하여금 API(20)로부터 버퍼를 제거하거나 또는 API(20)에 버퍼를 할당하는 것을 허용하는 버퍼의 선형 목록을 실현할 것이다. 예컨대, 등시성 수신 동작 도중에, 상기 애플리케이션이 각 버퍼의 처리를 종료함에 따라, 더 많은 데이터를 수신하도록 각 버퍼를 API에 다시 할당할 수 있다. 상응하게, 데이터 전송 동작을 완결하기 위하여 추가의 버퍼가 필요하다면, 상기 애플리케이션은 더 많은 버퍼를 API에 할당할 수 있다.

API(20)는, 애플리케이션(22)에 의해 요청된다면, 등시성 데이터의 전달 도중에 재동기화 이벤트 및/또는 콜백 루틴을 실행할 것이다. 재동기화 이벤트는, 전달 도중의 데이터 내에서, 시간상의 소정의 특정 시점에 대해 애플리케이션에 의한 재동기화를 허용한다. 데이터가 등시적으로 전달되기 때문에, 이러한 재동기화 이벤트는 또한 데이터 흐름에 대한 시간 내의 적절한 시점에 대해 애플리케이션을 동기화시킬 것이다. 비디오 데이터의 전달은 재동기화 이벤트의 실현에 대한 이상적인 예를 제공한다. 비디오 레코더와 같은 애플리케이션으로부터의 비디오 데이터의 전달 도중에, 데이터는, 하나의 수평 라인을 모니터 또는 텔레비전에 디스플레이하기 위해 필요한 데이터를 나타내는, 블록으로 전달된다. 각 수평 라인의 디스플레이 이후, 모니터는 다음 수평 라인을 디스플레이를 준비하기 위해 그 자체를 리세트하여야만 한다. 재동기화 이벤트는 각 수평 라인에 대한 데이터의 끝에서 모니터에 의해 채용될 수 있어, 모니터로 하여금 그 자체를 다음 수평 라인의 시작에 재동기화 시키는 것을 허용한다.

본 발명의 API의 양호한 실시예에 있어서, 특정 값이 등시성 데이터 블록 패킷 헤더에 출현할 때, 또는 등시성 데이터가 개시 동작을 위한 버스의 특정 채널 상에서 출현하거나 또는 정지 동작을 위한 버스의 특정 채널 상에서 종료될 때, 등시성 동작은 특정 버스 시간에 즉시 수행될 수 있도록 동기화 또는 예정될 수 있다.

API(20)에 할당된 각 버퍼는 재동기화 이벤트 및 콜백 루틴을 구비할 수 있다. 콜백 루틴은 한 프레임을 나타내는 데이터 한 블록의 전달 종료시의 비디오 데이터의 전달 도중에 채용될 수 있다. 모니터 또는 텔레비전은 수평 라인을 한 프레임으로 그룹 지우고, 각 프레임의 종료 시, 다음 프레임의 시작을 준비하도록 스크린의 상부에 그 자체를 리세트시킨다. 콜백 루틴은 각 프레임을 나타내는 데이터 스트림의 종료 시에 사용될 수 있다. 이러한 구조는 버퍼가 버스 구조(28)에 접속된 소스로부터 비디오 프레임을 나타내는 데이터로 채워지는 것을 허용한다. 비디오 프레임을 나타내는 데이터가 전달된 후, 콜백 루틴은, 다음 프레임을 나타내는 데이터가 전달되었고 처리를 위해 유효한 것을 애플리케이션에 통지하기 위하여 사용될 수 있다. 그 후 상기 애플리케이션은, 다음 프레임을 위한 데이터가 다음 버퍼에 로드되는 동안, 데이터의 이러한 프레임을 위한 데이터를 처리할 수 있다.

등시성 송신 및 수신 동작을 위해 API 버퍼 처리를 도시하는 흐름도가 도 6에 도시되었다. 등시성 수신 동작의 시작(102)에서 애플리케이션은 버퍼/기술자, 완결 루틴 호출 및 동기화 이벤트를 설정하는 것으로 간주한다. 흐름도(100)는 버스 시스템에서의 처리를 필요로 하는 각 등시성 스트림을 위하여 단계(102)에서 시작된다. API(20)은 인입 데이터를 처리하기 위한 현재 기술자를 유지한다. 즉, API는 다음 버퍼에 대한 포인터와, 데이터가 저장될 수 있는 다음 버퍼 내의 위치를 유지한다.

단계(104)에서 다음 버퍼 기술자는 연결된 목록으로부터 얻어진다. 단계(106)에서 더 이상의 임의의 기술자가 연결된 목록 내에 포함되는 지를 결정하기 위한 검사가 이루어진다. 더 이상의 기술자가 연결된 목록 내에 존재하지 않는다면, 처리는 단계(108)에서 종료된다. 부가적인 기술자가 존재한다면, 루틴은 현재 버퍼를 위한 동기화 이벤트가 도착할 때가지 대기하는 단계(112)로 이동한다. 동기화 이벤트가 일단 도착하면, 단계(114)에서 현재 버퍼는 수신 동작을 위한 인입 데이터로 채워지거나 또는, 버퍼로부터의 데이터가 송신 동작을 위해 전송된다. 버퍼가 처리된 후, 단계(116)에서 콜백 루틴이 이러한 버퍼를 위해 포함되었는지의 여부가 결정된다. 만약 콜백 루틴이 포함되었다면, 단계(118)에서 콜백 루틴이 호출된다. 그렇지 않을 경우, 루틴은 단계(104)로 복귀하고, 다음 기술자를 얻는다. 콜백 루틴이 제공되었는지의 여부에 따라, API와 하드웨어 서브시스템(26)은 다음 버퍼 기술자가 등시성 데이터가 손실되지 않게 얻어지는 것을 보장한다.

흐름도(100)의 단계는, 도 3 및 4와 관련하여 상술한 바와 같이, 통상적인 개인용 컴퓨터(PC), 삽입된 처리 시스템 등에서 볼 수 있는 것과 같은 CPU와 관련 서브시스템에 의해 수행될 수 있다. 일반적으로, 본 명세서에서 나타낸 흐름도의 단계는 "C", 파스칼, 포트란, 베이직, 어셈블리 언어 등과 같은 임의의 적합한 프로그래밍 언어로, 또는 이러한 언어의 조합으로 실현될 수 있다. 임의의 적합한 컴퓨터 프로그래밍 기술이, 절차적인 또는 객체 지향 프로그래밍, 병렬 또는 분산 처리, 인터럽트 구동 또는 폴링 이벤트(polled event) 처리, 등과 같이, 단계를 실현하기 위한 소프트웨어 설계를 위하여 사용될 수 있다. 본 명세서에서 설명되고 청구범위에서 청구된 방법의 단계 및 장치 요소를 여전히 달성하면서, 단계는 흐름도에 도시된 것에 변형되거나, 첨가 또는 제거될 수 있다. 단일 단계에서의 처리는 두 개 이상의 단계로 분할될 수 있다. 또한 일부 실시예에 있어서, 두 개 이상의 단계는 동일한 시간에 달성될 수도 있고, 이들의 임무가 뒤섞일 수 있다. 단계의 순서 또는 경로도 변경될 수 있다. 각 흐름도는 본 발명의 양호한 실시예에서 한 기능을 달성하기 위해 사용된 논리의 원시적인 한 예의 오직 한 경우에 불과하다.

논의의 목적을 위하여, 흐름도의 누적 단계는, 이들이 두 개 이상의 루틴, 프로그램, 처리 등으로 실현될 수 있다 할지라도, 단일의 "루틴" 또는 프로그램을 구성하는 것으로 언급된다. 흐름도의 단계는 동일하거나 다른 장치에 상주하는 프로세서 사이에 분산될 수도 있다.

등시성 데이터 전송 동작의 한 예로서, 만약 애플리케이션(22)이 버스 구조(28)에 접속된 노드에서 비디오 레코더로부터 데이터를 등시적으로 수신하는 비디오 모니터라면, API(20)는 버스 구조로부터, 각각이 연결된 목록에서 버퍼 기술자에 의해 표시되는 버퍼(32, 34 및 36)로의 데이터의 흐름을 관리할 것이다. 제 1 버퍼(32)는 비디오 레코더로부터 수신된 데이터로 채워진다. 제 1 버퍼(32)가 채워지면, 연결 목록 내의 다음 버퍼(34)가 채워지는 동안, 비디오 모니터(22)에 의해 처리되고 디스플레이된다. 만약 제 1 버퍼(32)가 한 프레임에 대한 데이터의 종료 시에 콜백 루틴을 포함하였다면, 상기 콜백 루틴은, 제 1 프레임을 나타내는, 제 1 버퍼(32)에서의 데이터를 처리할 수 있음을 비디오 모니터(22)에 통지하기 위하여 사용될 수 있다. 비디오 모니터(22)가 제 1 버퍼(32) 내의 데이터의 처리를 종료할 때, 버스 구조(28)로부터 수신된 추가 데이터를 저장하기 위하여 버퍼(32)를 API(20)에 다시 제공할 수 있다.

애플리케이션(22)이 버스 구조에 접속된 다른 노드에 등시성 데이터를 전달하는 비디오 레코더라면, 상기 애플리케이션은 버퍼(32, 34 및 36)를 차례로 데이터로 로드시킨다. 그 후, API(20)는 적절한 시간에 적절한 채널 번호를 가지고, 버퍼(32, 34 및 36)로부터 버스 구조(28)상으로의 데이터의 전달을 관리한다. 이러한 방법에 있어서, 본 발명의 API(20)는 애플리케이션(22)에 또는 이로부터의 등시성 데이터 전송을 관리한다.

비동기 데이터 전송

애플리케이션(24)과, 버스 구조(28)에 접속된 다른 노드 사이의 비동기 데이터 전송 동작을 실행하기 위하여, API(20)은, 전달을 완결하기 위해 필요한 요청을 자동적으로 생성하는 하드웨어 자동화 레벨을 사용하고, 애플리케이션과 API(20)가 데이터 전송 동작이 완결되는 동안 다른 기능을 수행하도록 허용하는, 직접 메모리 억세스(DMA) 모델을 필수적으로 한정한다. API(20)는 비동기 데이터 전송을 위하여 메모리-맵핑된 인터페이스를 애플리케이션에 제공한다. 비동기 데이터 전송을 시작하기 위하여, 애플리케이션(24)은 기술자를 API(20)에 전달하는데, 상기 기술자는 애플리케이션의 어드레스 공간 내의 버퍼의 어드레스와, 전달이 발생하는 버스 구조의 어드레스 공간 내의 시작 어드레스와, 전달될 데이터의 블록의 길이와, 전달이 판독 또는 기록 동작일 지를 나타내는 코드를 포함한다. API(20)는 필요한 데이터를 하드웨어 자동 전달 생성기(38)에 제공하고, 상기 생성기는 이후 버스 구조(28)를 가로질러 데이터의 전체 블록의 전달을 완결하는데 필요한 하나 이상의 트랜잭션을 생성한다. 자동 전달 생성기(38)는 그 후 버스 구조(28)를 가로질러 애플리케이션(24)에 의해 할당된 버퍼와 적절한 어드레스 사이에서 데이터의 전달을 완결하기 위하여 필요한 판독 또는 기록 트랜잭션을 생성한다. 이러한 자동화는 비동기 데이터 전송 동작을 완결하는데, API(20) 또는 애플리케이션(24)의 주의를 필요로 하지 않는다. 본 발명의 양호한 실시예에서 자동 트랜잭션 생성기(38)가 하드웨어로 실현되지만, 자동 트랜잭션 생성기가 API(20) 내의 소프트웨어로 실현될 수도 있다는 것은 당업자에게는 자명하다. 애플리케이션이 하드웨어 자동화의 이러한 레벨을 필요로 하지 않는다면, API(20)는, 자동 트랜잭션 생성기(38)를 사용함이 없이, 데이터 전송 동작을 완결하기 위하여 필요한 트랜잭션을 생성할 수도 있다.

당업자에게 알려져 있는 바와 같이, 각 판독 또는 기록 트랜잭션은, 시스템과 버스 구조(28)의 성능에 따라, 데이터의 특정 양을 전달하기만 할 수 있다. 그러므로, 데이터의 블록을 전달하기 위하여, 복수의 판독 또는 기록 트랜잭션을 생성하는 것이 필요할 수 있다. 종래 기술의 시스템과는 대조적으로, 본 발명의 API(20)는 단일 명령을 자동 트랜잭션 생성기 블록(38)에 보낸다. 그 후 자동 트랜잭션 생성기 블록(38)은, API(20)에 의한 추가의 주의를 필요로 함이 없이, 버스 구조(28)를 통해 데이터의 완전한 블록을 전달하는데 필요한 판독 또는 기록 트랜잭션을 생성한다. 이것은, API(20)와 애플리케이션(24)이 전달이 발생하는 동안 다른 과제를 수행할 수 있음에 따라, 시스템이 보다 더 효율적이 되게 허용한다. 전달이 비동기이기 때문에, 데이터의 전체 블록의 전달이 일단 종료되면, API(20)는 애플리케이션(24)에 통지한다.

상술한 바와 같이, 본 발명의 양호한 실시예에 있어서, 버스 구조(28)는 IEEE 1394 표준 버스 구조이다. 그러므로 비동기 데이터 전송에 대해 버스 구조(28)는 64비트 어드레스 공간을 제공한다. 자동 트랜잭션 생성기(38)에 제공된 기술자 내에서, 데이터 전송이 발생하려 하는 원격 어드레스는 64비트 어드레스에 의해 지정된다.

비동기 판독 동작을 개시하기 위하여, 애플리케이션(24)은 API(20)에 기술자를 전달하는데, 상기 기술자는 데이터가 전달되려 하는 애플리케이션의 어드레스 공간 내의 버퍼의 어드레스와, 데이터가 판독되려는 버스 구조(28)의 어드레스 공간 내의 64비트 개시 어드레스와, 전달되려는 데이터 블록의 길이와, 전달이 판독 동작임을 나타내는 코드를 포함한다. 그 후 API(20)는 필요한 정보를 자동 트랜잭션 생성기(38)에 전달한다. 그 후 자동 트랜잭션 생성기(38)는, 버스 구조(28) 상에서 적절한 노드로부터 애플리케이션 버퍼에 데이터를 전달하기 위해 필요한, 판독 명령을 생성한다. 애플리케이션은, 판독 트랜잭션이 생성되기 전에 특정 버퍼가 유효한 것을 보장할 책임이 있다. 그 후 데이터는 알려진 방법으로 자동 트랜잭션 생성기(38)에 의해 생성된 트랜잭션에 따라 판독된다.

비동기 기록 동작을 개시하기 위하여, 애플리케이션(24)은 API(20)에 기술자를 전달하는데, 상기 기술자는 데이터가 전달되려 하는 애플리케이션의 어드레스 공간 내의 버퍼의 어드레스와, 데이터가 기록되려는 버스 구조(28)의 어드레스 공간 내의 64비트 개시 어드레스와, 전달되려는 데이터 블록의 길이와, 전달이 기록 동작임을 나타내는 코드를 포함한다. 그 후 API(20)는 필요한 정보를 자동 트랜잭션 생성기(38)에 전달한다. 그 후 자동 트랜잭션 생성기(38)는, 애플리케이션 버퍼로부터 버스 구조(28) 상에서의 적절한 노드에 데이터를 전달하기 위해 필요한, 기록 명령을 생성한다. 그 후 데이터는 알려진 방법으로 자동 트랜잭션 생성기(38)에 의해 생성된 트랜잭션에 따라 애플리케이션 버퍼로부터 전달된다. 버퍼가 전달될 때, 애플리케이션(24)에 통지된다.

API 약정 및 버스 관리 동작

애플리케이션은 API(20) 내의 루틴을 동기적으로 또는 비동기적으로 호출한다. 만약 애플리케이션이 루틴을 동기적으로 호출한다면, 루틴이 애플리케이션으로 복귀하는 시간에, API는 요청된 동작을 완결하거나, 또는 API는 선택된 요청이 완결될 수 없음을 나타내는 완결 상태를 복귀시킨다. 선택적으로, 만약 애플리케이션이 루틴을 비동기적으로 호출한다면, 요구된 동작은, 루틴이 제어를 클라이언트(client)에 복귀시키는 시간에, 거의 완결되지 않을 것이다. 루틴을 비동기적으로 호출하기 위하여, 애플리케이션은 완결 콜백 루틴을 제공한다. API는 원래의 호출로부터 복귀되기 전에 이러한 완결 루틴을 호출할 수 있다. 그러나, 대부분의 경우, API는 동작을 개시시킨 원래의 호출로부터 복귀된 후 요청된 동작을 완결하고, 이후 동작이 이루어졌음을 나타내기 위하여 애플리케이션의 완결 루틴을 호출한다.

API에 의해 제공된 임의의 서비스를 사용하기 전에, 애플리케이션은 먼저 API를 초기화시켜야만 한다. 각 애플리케이션은 API를 별도로 초기화시켜야만 한다. 애플리케이션은 ActivateSonyAPI 서브루틴을 호출함으로써 API를 초기화시킨다. 이러한 서브루틴은 API와 애플리케이션 사이의 접속을 구성한다. ActivateSonyAPI를 호출할 때, 애플리케이션은 버스 리세트 또는 다른 버스 이벤트가 발생할 때 API가 호출하는 지시 루틴을 지정할 수 있다. ActivateSonyAPI 서브루틴은 하나의 값을 애플리케이션에 복귀시키는데, 상기 애플리케이션은 이후 API의 루틴에 대한 후속하는 호출 시 이 값을 사용한다.

동작의 경과 도중에 큰 수의 지시를 기대하는 애플리케이션은, 배타적인 사용을 위한 부가적인 지시 버퍼를 API에 전달하기 위하여, AddIndBufffers 루틴을 호출할 수 있다. 클라이언트는, API가 현재 소유하는 버퍼의 수를 검사하기 위하여, 먼저 CountIndBuffers 루틴을 호출할 수 있다. API를 비활성화시키는 것에 선행하여, 애플리케이션은 RelIndBuffers 루틴을 호출함으로써 API에 이전에 제공된 지시 버퍼를 해제할 수 있다.

애플리케이션이 API의 사용을 끝마칠 때, DeactivateSonyAPI 루틴을 호출한다. 이러한 루틴은 애플리케이션과 API 사이의 접속을 깨뜨리고, 애플리케이션을 대신하여 API에 의해 사용중인 임의의 지시 버퍼 또는 다른 소스를 해제시킨다. 일부 애플리케이션의 버퍼가 현재 API에 의해 사용중이라면, API는 주어진 애플리케이션으로부터 곧바로 분리될 수 없음을 주목해야 한다. 주어진 애플리케이션을 위해 API가 활동중인 시간 동안, 애플리케이션은 API가 제공하는 모든 서비스에 억세스한다.

API를 초기화한 후, IEEE 1394 표준의 8절에서 한정되고, 이하에서 설명되는 바와 같이, 애플리케이션은 다양한 IEEE 1394 버스 관리 기능을 수행할 수 있다. 애플리케이션은, MGMTAllocateChannel과 MGMTDeAllocateChannel 루틴을 각각 사용하여, 현재 활성중인 등시성 소스 관리자로부터 등시성 채널 번호를 할당 및 할당해제할 수 있다. 이들 애플리케이션을 사용하여, 애플리케이션은 유효하다면 특정 채널 번호를 할당하도록 요구할 수 있다. 선택적으로, 애플리케이션은 현재 유효한 임의의 채널 번호를 할당하도록 요청할 수 있다. 이들 API 루틴은, 등시성 채널 번호를 할당 및 할당해제하는 것에 대해 IEEE 1394 표준의 요구를 따른다. 등시성 채널 번호를 사용할 때, 애플리케이션은 IEEE 1394 표준 또는 임의의 다른 통제 프로토콜(governing protocol) 서류에 적용될 수 있는 임의의 다른 요건을 따를 책임이 있다.

애플리케이션은, MGMTAllocateBandwidth와 MGMTDeAllocateBandwidth 루틴을 각각 사용하여, 현재 활성중인 등시성 소스 관리자로부터 등시성 대역폭을 할당 및 할당해제할 수 있다. 이들 API 루틴은 등시성 대역폭을 할당 및 할당해제하는 것에 대해 IEEE 1394 표준의 요구를 따른다. 이들 루틴을 사용할 때, 애플리케이션은 필요한 등시성 대역폭의 정확한 양을 계산하고, 정확하게 그만큼을 할당하는 것에 대한 책임이 있다. 애플리케이션은 또한, 임의의 등시성 대역폭을 할당, 할당해제 또는 소유하는 것에 대해, IEEE 1394 표준 및 다른 임의의 통제 프로토콜 서류에 문서화된 적용 가능한 규칙을 따라야 하는 책임이 있다.

애플리케이션이 API를 비활성화시킬 때, API는 애플리케이션이 이전에 할당된 임의의 버스 소스를 할당해제하려고 시도하지 않는다. IEC AV 프로토콜 표준에서 요구되는 바와 같이, 이것은 애플리케이션이 이들 소스의 소유권을 쉽게 포기하도록 허용한다. 그러나, 등시성 버스 소스를 할당 및 할당해제할 때, 이것은 통제 프로토콜을 따르는 완전한 책임을 애플리케이션에 부여한다.

애플리케이션은, 활동 버스 관리자로부터 현재 토폴로지 맵 및 속도 맵 정보를 검색할 수 있고, 만약 존재한다면, MGMTBusInfo 루틴을 사용하여 임의의 다른 유효한 버스 정보를 검색할 수 있다. 애플리케이션이 실행 중인 노드가 활성 버스 관리자인지 여부에 관계없이, 이러한 루틴은 버스 관리자로부터 최신의 정보를 검색한다. 현재 활성인 버스 관리자가 없다면, 이러한 루틴은 실패할 것이라는 점을 주목해야 한다. IEEE 1394 표준의 8절은 토폴로지 맵 및 속도 맵의 포맷과, 버스 관리자가 존재하거나 존재하지 않는 조건을 한정한다.

API를 초기화한 후, 애플리케이션은 IEEE 1394 직렬 버스 상에서 비동기 데이터 전송 요청을 개시시키기 위하여 ASYNDataRequest 루틴을 호출할 수 있다. 애플리케이션은, IEEE 1394 표준에서 한정된 임의의 비동기 트랜잭션을 개시시키기 위하여, 이러한 루틴을 사용할 수 있는데, 상기 트랜잭션은 데이터 블록 판독 또는 기록 요청, 쿼드렛 판독(quadlet read) 또는 기록 요청, 또는 임의의 로크 요청을 포함한다. 애플리케이션이 ASYNDataReqest 루틴을 호출할 때, 상기 루틴은 애플리케이션 어드레스 공간 내의 버퍼를 위한 기술자, 64 비트 IEEE 1394 어드레스 공간 내의 개시 어드레스, 데이터 전송 길이 및 트랜잭션 코드를 전달한다. 그 후 ASYNDataRequest 루틴은 상기 요청을 충족시키기 위하여 하나 이상의 IEEE 1394 트랜잭션을 생성한다. API가 요청된 데이터 전송 동작을 종료할 때, 또는 에러에 직면할 때, 애플리케이션이 이러한 루틴을 동기적으로 또는 비동기적으로 호출했는 지에 따라, API는 애플리케이션으로 복귀하거나, 또는 애플리케이션의 콜백 루틴을 호출한다.

IEEE 1394 직렬 버스를 통하여 로크 트랜잭션을 수행하기 위하여, 애플리케이션은 ASYNDataRequest 루틴을 호출하고, 인수(argument)의 값, 데이터 값 및 로크 동작 코드를 전달한다. API는, 예컨대 동기적 또는 비동기적인 호출 형태에 의해 결정된 바와 같이, 요청된 로크 동작을 생성하고 애플리케이션으로 복귀하거나 또는 애플리케이션의 콜백 루틴을 호출한다.

API를 초기화한 후, 애플리케이션은 IEEE 1394 직렬 버스 상의 등시성 데이터의 채널의 출처를 밝히거나 또는 밝히지 않을 수 있다. 등시성 데이터를 전달하기 전에, 애플리케이션은 ISOCHOpen 루틴을 사용하여 등시성 포트를 먼저 개방하여야만 한다. 이러한 루틴을 호출할 때, 상기 애플리케이션은, 애플리케이션이 전달하려는 등시성 데이터의 스트림에 대한 방향 및 다른 정보를 지정한다. ISOCHOpen 루틴은 필요한 시스템 소스가 유효한 지를 결정하고, 그럴 경우 애플리케이션으로 복귀한다. 이러한 루틴이 성공적으로 완결되면, 상기 애플리케이션은 등시성 데이터의 스트림을 전달하기 위한 배타적인 용도를 위하여 예약된 모든 필요한 시스템 소스를 구비한다.

애플리케이션이 등시성 채널 상에서 통신하거나 청취할 때, 호스트 시스템 내에서 등시성 데이터의 소스 또는 목적지는 애플리케이션에 의해 소유되고 데이터 구조에서 기술된 하나 이상의 데이터 버퍼이다. 애플리케이션은 이들 버퍼를 ISOCHAttach 루틴을 호출함으로써 API에 전달한다. 이러한 루틴은, 애플리케이션 데이터를 이들 버퍼에 또는 이로부터 전달에 대비하여 애플리케이션 버퍼를 등시성 스트림에 "부속(attach)"시킨다. API가 이들로 종료되기 전에, 애플리케이션이 그 버퍼를 다시 요청하기를 희망한다면, 애플리케이션은, 애플리케이션이 다시 요청하기를 희망하는 이들 버퍼를 지정하는 ISOCHDetach 루틴을 호출할 수 있다.

API는 등시성 데이터 버퍼를 기술하기 위하여 애플리케이션이 사용하는 버퍼 기술자를 한정하는데, 상기 등시성 데이터 버퍼는 애플리케이션으로 하여금 등시성 데이터의 수신 또는 전달을 위해 사용하기 위한 데이터의 버퍼 중 하나 또는 하나 이상 또는 목록을 지정하도록 허용한다. 각 버퍼는 연속적이거나 또는 단편적, 논리적 또는 물리적일 수 있고, 애플리케이션은 하나의 버퍼씩 차례로(a buffer by buffer basis) 콜백 루틴을 지정할 수 있다. 이것은 애플리케이션을 대신하여 API 내의 극도로 유연한 버퍼 취급을 허용하여, 넓은 범위의 애플리케이션 요청사항을 지원한다.

애플리케이션이 등시성 포트를 개방하고, 버퍼를 이러한 포트에 부착시킬 때, 애플리케이션은 등시성 데이터의 스트림을 제어할 수 있다. ISOCHControl 루틴을 호출함으로써 이러한 것을 실행한다. 이러한 루틴은 애플리케이션으로 하여금 등시성 스트림을 애플리케이션 버퍼에 또는 이로부터 개시하거나 또는 정지시키도록 허용한다. 이러한 루틴을 호출할 때, 애플리케이션은, 예컨대 특정 등시성 주기 또는 다른 이벤트 시점에서 즉시, 스트림을 개시시키거나 또는 정지시키는 이벤트를 지정할 수 있다. 애플리케이션이 등시성 데이터의 스트림을 전달하는 것을 종료할 때, ISOCHClose 루틴을 호출함으로써 개방 포트에 관련된 시스템 소스를 해제한다.

ActivateSonyAPI 및 DeactivateSonyApi 루틴은, 호출하는 애플리케이션(the calling application)에 유효한 API에 의해 제공되는 IEEE 1394 특정 서비스를 구성하는 초기화 메커니즘을 제공한다. ActivateSonyAPI 루틴은 API에 의해 제공된 서비스에 대한 접속을 설정한다. DeactivateSonyAPI 루틴은 API에 의해 제공된 서비스에 대한 특정 접속을 제거한다. 활성화의 결과는 유효한 activateReq 구조이다. 호출하는 애플리케이션은 포인터를 API에 대한 후속하는 모든 호출의 부분으로서 이러한 구조에 전달한다. 애플리케이션을 위한 API를 활성화시키는 일부로서, 애플리케이션은 원격 노드로부터 버스 리세트 또는 요청 지시와 같은 지시 루틴을 제공할 수 있는데, API는 관련된 IEEE 1394 버스 상에서 무언가 발생했음을 호출자에 알리기 위하여 상기 지시 루틴을 사용한다. 비활성화의 결과는, 존재하는 경우, 활성화 시간에 등록된 지시 루틴이 등록 해제된다는 것이다. 비활성화에 뒤이어, 호출자는 API가 먼저 재활성화 되지 않는다면, 임의의 API 서비스를 사용할 수 없다.

다음의 기능은 미래의 동작을 위하여 API를 활성화시킨다.

STATUS ActivateSonyAPI(ActivateReqPtr activateReq);

이러한 루틴은 하나의 파라메터를 취하고, 상태값을 복귀시킨다. 호출자는 이하에서 설명하는 바와 같이, activateReq 데이터 구조를 채우고, 포인터를 ActivateSonyAPI 루틴에 전달한다. 이러한 루틴이 GOOD 상태로 복귀된 후, 호출자는 결과의 activateReq 데이터 구조를 저장한다. 이러한 데이터 구조는 애플리케이션과 API 사이의 접속을 나타낸다. 이러한 접속을 확인하기 위하여, 호출자는 포인터를 API에 대한 후속하는 호출 상에서 activateReq 데이터 구조에 전달한다. 가능한 상태 복귀값은, API가 이제 활성이고 activateReq 데이터 구조가 미래의 동작을 위해 유효한 것을 나타내는 GOOD, API가 요청을 받아들였지만 이 시간에 활성화되지 않는 것을 나타내는 PENDING, 및 API를 활성화시키려고 시도하는 동안 예기치 않는 에러가 발생했다는 것과 API가 활성화되지 않았음을 나타내는 UNDEFINEDERROR이다. PENDING 값이 복귀된 후, API는 활성화 요청이 완결될 때, API는 AsyncCompletion 루틴을 호출한다. 이 때, 요청 상태 필드는 활성 요청을 위한 완결 상태를 포함한다.

단일의 파라메터는 activatReq 데이터 구조의 어드레스를 포함한다. 이러한 데이터 구조는 아래의 표 1에서 한정되는 바와 같이 API를 활성화시키기 위해 필요한 정보를 제공한다.

파일된(filed) BusResetHandler가 0과 같지 않을 때, 버스 리세트 이벤트를 수신시에 호출하기 위한 루틴의 어드레스를 포함한다. 버스 리세트가 IEEE 1394 버스 상에서 발생할 때, API는 버스 리세트 정보를 포함하는 데이터 구조의 어드레스를 전달하는 BusResetHandler 루틴을 호출한다. IndicationHandler 필드가 0과 같지 않을 때, API에 의해 처리되지 않는 지시가 발생할 때 호출하기 위한 루틴의 어드레스를 포함한다. API가 원격 노드로부터 요청 부-동작(subaction)을 수신할 때, 요청을 기술하는 데이터 구조의 어드레스를 전달하는 IndicationHandler 루틴을 호출한다. API는 활성화 처리의 부분으로서 SonyAPIPrivate 필드를 채운다. API는 후속하는 호출 시에 이러한 필드 내의 값을 사용한다. 호출하는 애플리케이션은 이러한 필드 내의 값을 변경하지 않을 것이다. AsyncCompletion 필드가 0과 같지 않을 때, API가 활성이고 애플리케이션을 호출하는 것에 의한 용도를 위해 유효할 때 호출하기 위한 루틴의 어드레스를 포함한다. 애플리케이션을 호출하는 것은 완결 루틴에 요청이 비동기 또는 동기인 지를 지정할 수 있다. UserPtr 필드는 호출하는 애플리케이션의 완결 루틴에 의한 용도를 위해 유효하다. API는 이러한 필드를 변경하지 않는다. Status 필드는 활성화 요청 상태를 포함한다.

다음 기능은 요구에 의해 표시된 API의 인스턴스 생성(instantiation)을 종료시킨다.

status DeactivateSonyAPI(ActivateReqPtr request);

이러한 기능에 대한 가능한 상태 복귀 값은, API가 이제 비활성화되었고, activateReq 데이터 구조가 미래의 동작을 위한 용도에 유효하지 않다는 것을 나타내는 GOOD, INVALIDCONNECTION, API가 비활성화 요청을 받아들였지만 이 시간까지 여전히 활성화인 것을 나타내는 PENDING, 및 API를 비활성화 시키려고 시도하는 동안 예기치 않은 에러가 발생하였음과 API가 활성일 수 있음을 나타내는 UNDEFINEDERROR이다. PENDING 값이 복귀된 후, API는 비활성화 요청이 완결될 때 AsyncCompletion 루틴을 호출한다. 이 때, 요청 상태 필드는 활성 요청을 위한 완결 상태를 포함한다.

단일의 파라메터는 API를 이전에 활성화시키기 위해 사용된 activateReq 데이터 구조의 어드레스를 포함한다. 상기 절은 이러한 데이터 구조를 한정하고, 그 필드를 기술한다. 비활성화시킬 때, 호출자는 이전에 API를 활성화시키기 위해 사용된 동일한 데이터 구조를 사용하여야만 한다. 호출자는 AsyncCompletion 필드 및 UserPtr 필드 내의 값을 변경할 수 있다. 호출자는, DeactivateSonyAPI 루틴에 대한 호출에 선행하여 ActivateSonyAPI 루틴에 대한 초기 호출을 따르는 activateReq 데이터 구조 내의 임의의 다른 필드를 변경하지 않아야 한다. 특정 애플리케이션을 위해 API를 비활성화시키는 것에 덧붙여, 이러한 루틴은 또한 애플리케이션이 이전에 API에 전달한 임의의 표시 버퍼를 해제시킨다. 애플리케이션에 의해 소유된 현저한 표시 버퍼가 존재하고, 애플리케이션이 이러한 루틴을 동기적으로 호출하려고 시도한다면, 이러한 루틴은 에러를 복귀시킨다. 이러한 것이 발생하면, 애플리케이션은 완결 루틴을 지정하는 이러한 루틴을 다시 호출할 수 있다. API는, 모든 애플리케이션의 표시 버퍼가 해제될 때, 비활성화 요청을 완결할 것이고, 애플리케이션의 표시 루틴을 호출할 것이다.

API는 표시 처리 루틴, BusResetHandler 및 IndicationHandler를 비동기적으로 호출하고, 이들은 이들에 유효한 제한된 시스템 서비스를 가질 수 있다. 환경과 가능한 일부 다른 상황에 따라, API는 인터럽트 레벨에서 이들 루틴을 호출할 수 있다. BusResetHandler 루틴에 있어서, 조정기(handler)는 포인터를 버스 리세트 정보에 전달한다. IndicationHandler 루틴에 있어서, 조정기는 포인터를 표시 정보에 전달한다. 애플리케이션은 이들 표시 루틴의 하나 또는 모두의 어드레스를, API를 활성화시키는 시간에, API에 전달한다. 애플리케이션은 이들 조정기 중 하나 또는 두 조정기를 제공하거나 또는 조정기 루틴을 전혀 제공하지 않을 수도 있다.

버스 리세트 처리 루틴은 다음의 호출 약정을 구비한다.

void BusResetHandler(BusResetBlockPtr busResetBlock);

busResetBlock 데이터 구조는, 다음의 표 2에서 한정되는 바와 같이, 버스 리세트 이벤트를 기술하는 데이터 구조의 어드레스를 포함한다.

API는, 버스 리세트 조정기 루틴을 제공하는 애플리케이션을 위해 API가 활성인 동안 IEEE 1394 버스 상에서 버스 리세트가 발생하는 임의의 시간에, 버스 리세트 처리 루틴을 호출한다. 버스 접속 및 접속 해제의 물리적인 특성으로 인해 리세트의 한 클러스터(cluster)가 발생할 때, 조정기는 한 번 호출될 것이다. 조정기는 재 입력되지 않을 것이지만, 연속적으로 몇 차례 호출될 수 있다. 버스 리세트의 결과로서, 버스 리세트의 시간에서 계류중인 모든 비동기 트랜잭션은 에러 상태와 함께 완결될 것이다. 등시성 통신량(traffic)은 IEEE 1394 규격에 따라 다시 시작될 것이고, 버스 리세트 조정기의 실행 도중에 표시를 생성할 수 있다.

비동기 트랜잭션 요청 표시 루틴은 다음의 호출 약정을 구비한다.

void IndicationHandler(IndicationBlockPtr indicationBlockPtr)

IndicationBlockPtr 데이터 구조는 다음의 표 3에서 한정된 표시 블록의 어드레스를 포함한다.

API는, API 자체에 의해 또는 IEEE 1394 인터페이스 하드웨어에 의해 처리되지 않는 비동기 요청 부-동작을 수신할 때, 표시 루틴을 호출한다. 이러한 각 이벤트에 대해, API는, API를 활성화시키고 표시 조정자를 제공하기 위하여 제 1 애플리케이션으로 시작하는, 각 애플리케이션의 표시 루틴을 호출한다. 각 표시 조정기는, 표시를 처리하였는 지 여부를 나타내기 위한 값을 API에 되돌린다. API가 표시를 처리하였음을 나타내는 표시 루틴으로부터 상태를 수신할 때, API는 이러한 표시를 위하여 어떠한 다른 표시 루틴도 호출하지 않는다.

API는 일부 요청 부-동작 자체를 처리한다. 이들 트랜잭션을 위하여, API는 어떠한 표시 조정기 루틴도 호출하지 않는다. API는, API를 통해 응답 부-동작을 생성하기 위하여, 표시 조정기 루틴을 위해 필요한 부가적인 정보와 표시를 초래하는 모든 IEEE 1394 트랜잭션 정보를 전달한다.

애플리케이션은 버퍼를 표시 조정기에 제공할 수 있다. 이러한 기능은 애플리케이션으로 하여금 애플리케이션의 특정한 요건을 수용하기 위하여 표시 버퍼의 디폴트 설정을 확장하도록 허용한다. 표시 버퍼의 더 큰 설정은, IEEE 1394 인터페이스에서 비지 승인 신호(a busy ack signal)를 초래함이 없이 보다 더 현저한 표시를 허용한다. 애플리케이션은, API로부터 표시를 수신할 때, 소속된 버퍼를 수신하도록 보장받지 않는다. 더욱이, API는, 표시를 보고할 때 필요하다면, 애플리케이션 표시 버퍼를 다른 애플리케이션에 전달할 수 있다.

현재의 표시 버퍼 카운트 기능은 표시 버퍼 풀(pool)에서 표시 버퍼의 전체 카운트값을 복귀시킨다. 복귀된 값은 표시 버퍼의 현재의 카운트값이다.

첨가 표시 버퍼 기능은 버퍼를 표시 버퍼 풀에 제공한다. 버퍼 요소는 로컬버퍼(LocalBuffer)로서 기술된다. 이러한 기능의 호출자는 이러한 요청에 의해 표시된 저장의 소유권을 API에 양도하고, 저장의 처리에 앞서 소유권을 다시 얻어야만 한다.

STATUS AddIndBuffers(ActivateReqPtr context, BufMgmtBlockPtr bufBlock);

AddIndBuffers 기능에 대한 가능한 상태 복귀 값은 API가 요청을 받아들였고 이후의 시간에 완결할 것임을 나타내는 GOOD, INVALIDCONNECTION, API가 비활성화 요청을 받아들였음을 나타내는 PENDING, 버퍼가 이러한 플랫폼(platform)상에 덧붙여질 수 없음을 나타내는 UNSUPPORTEDOP, 및 일부 데이터가 전달되었을 지라도, 요청을 받아들이려고 시도하는 동안 예기치 않은 에러가 발생하였음을 나타내는 UNDEFINEDERROR이다. 계류중인(pending) 값이 복귀될 때, API는 요청이 완결될 때 AsyncCompletion 완결 루틴을 호출한다. 이 때, BufMgmtBlock의 상태 필드는 요청을 위한 완결 상태를 포함할 것이다.

AddIndBuffers 기능의 제 1 파라메터는 유효 ActivateReq 데이터 구조의 어드레스를 포함한다. 제 2 파라메터는 BufMgmtBlock 데이터 구조의 어드레스를 포함한다. 이러한 데이터 구조는 이하의 표 4에서와 같이 버퍼를 기술한다.

APIprivate 필드는 요청을 관리하기 위한 전용(private) 데이터를 포함한다. LocalBufferPtr 필드는 제공할 버퍼를 위한 기술자를 포함한다. 이들 버퍼는 임의의 크기가 될 수 있다. API는 임의로 제공된 버퍼의 모두 또는 일부를 사용할 수 있거나 또는 전혀 사용하지 않을 수 있다. AsyncCompletioin 필드가 0이 아닐 때, 이 필드는 동작을 완결할 시에 호출할 루틴의 어드레스를 포함한다. UserPtr 필드는 호출하는 완결 루틴에 의한 용도를 위하여 유효하다. API는 이러한 필드를 변경하지 않는다. Status 필드는 요구된 데이터 전송 동작의 상태를 포함한다. 상태 필드는 비동기 동작이 완결될 때까지 "계류" ("pending") 상태를 포함한다. 완결 루틴이 호출되면, Status 필드는 완결 상태를 포함할 것이다.

해제 표시 버퍼 기능은 이전에 덧붙여진 표시 버퍼를 호출기(invoker)에 복귀시킨다. 버퍼 요소는 LocalBuffer로서 기술된다. 이러한 기능의 호출기는, AddIndBuffers 기능 요청에 의해 부가된 버퍼의 서브세트(subset)를 지정할 수 있다. 요청된 모든 버퍼가 해제될 때, 완결 루틴이 호출된다.

STATUS RelIndBuffers(ActivateReqPtr context, BufMgmtBlockPtr bufBlock); RelIndBuffer 기능에 대한 가능한 상태 복귀값은, API가 요청을 수용하였고, 이를 이후의 시간에 완결할 것임을 나타내는 PENDING, INVALIDCONNECTION, 버퍼가 이러한 플랫폼에 첨가될 수 없음을 나타내는 UNSUPPORTEDOP, 및 일부 데이터가 전달되었다 할지라도, 요청을 받아들이려고 시도하는 동안 예기치 않은 에러가 발생하였음을 나타내는 UNDEFINEDERROR이다.

해제 표시 버퍼의 제 1 파라메터는 유효한 activateReq 데이터 구조의 어드레스를 포함한다. 제 2 파라메터는 BufMgmtPtr 데이터 구조의 어드레스를 포함한다. 이러한 데이터 구조는, 위에서 한정한 바와 같이, 버퍼를 기술한다. 애플리케이션이 API로 하여금 버퍼를 해제하도록 요청할 때, 버퍼가 첫 번째로 API에 제공된 때와 동일한 설명을 사용하여 상기 버퍼를 기술하여야만 한다.

버스 관리 루틴은 IEEE 1394 버스 관리 기능을 수행한다. 이들 기능은 등시성 버스 소스를 할당 및 할당해제하는 것과, IEEE 1394 버스의 토폴로지 또는 구성에 대한 정보를 검색하는 것을 포함한다.

MGMTAllocateChannel 루틴은 단일의 등시성 채널 번호를 할당하기 위하여 IEEE 1394 표준의 8절에 한정된 프로토콜을 사용한다. 약정을 호출하는 MGMTAllocateChannel 루틴은 다음과 같다.

status MGMTAllocatChannel(ActivateReqPtr context, MGMTAllocateChBlockPTr allocateChBlock);

MGMTAllocateChannel 루틴을 위해 가능한 상태 복귀값은, 채널이 성공적으로 할당되었음을 나타내는 GOOD, 문맥(context) 파라메터가 API에 대한 현재의 활성 연결의 어드레스를 포함하지 않음을 나타내는 INVALIDCONNECTION, API가 요청을 수용하였음을 나타내는 PENDING, 요청된 채널 번호가 현재 유효하지 않음을 나타내는 CHUNAVAILABLE, 예기치 않은 에러가 발생하였음을 나타내는 UNDEFINEDERROR이다. 계류중인(pending) 값이 복귀되면, 할당 요청이 완결될 때 API는 MGMTCompletion 루틴을 호출하고, 그 시간에 상태 필드는 이러한 요청을 위한 완결 상태를 포함할 것이다.

MGMTAllocateChannel 루틴의 제 1 호출 파라메터는 활성 ActivateReq 데이터 구조의 어드레스이다. 제 2 파라메터는 이하의 표 5에서 한정된 데이터 구조의 어드레스를 포함한다.

채널 필드는 할당할 채널 번호를 포함한다. 채널 번호가 0과 63을 포함하여 0 내지 63의 범위 내에 있다면, 상기 루틴은 지정된 채널 번호를 할당하려고 시도한다. 채널 번호가 모두 1과 같다면, 상기 루틴은 할당할 채널 번호를 선택한다. 채널 필드가 임의의 다른 값을 포함한다면, 상기 루틴은 chAvailable 필드를 채우고, chUnavailable 상태를 복귀시킨다. 이것은 현재 활성인 등시성 소스 관리자로부터 유효 채널의 비트 마스크(channels available bit mask)의 현재 값을 결정하는데 사용될 수 있음을 주목해야 한다. allocatedCh 필드는 실제 할당된 채널 번호로 채워지거나, 또는 이러한 루틴을 호출한 결과로서 채널이 할당되지 않았다면, 모두 1로 채워진다. chAvailable 필드는 등시성 소스 관리자에서 유효_채널(channels_available) CSR의 현재 값으로 채워진다. CSR 내에서의 값은 어느 때라도 변화될 수 있어, 이러한 필드 내의 값은 스냅샷(snapshot)일 뿐이고, 후속하는 호출시에는 다른 값이 될 수 있다. MGMTCompletion 필드 내의 값이 NULL(0)과 같지 않다면, 이러한 필드는 완결 시에 호출할 루틴의 어드레스를 포함한다. UserPtr 필드는 애플리케이션의 완결 루틴에 의한 사용을 위해 유효하다. API는 이러한 필드를 변경하지 않는다. 상태 필드는 이러한 호출을 위한 완결 상태를 포함한다. 애플리케이션이 이러한 루틴을 비동기적으로 호출한다면, 이러한 필드는 완결 루틴이 호출될 때까지 PENDING 상태를 포함한다.

MGMTAllocateBandwidth 루틴은 등시성 대역폭을 할당하기 위하여 IEEE 1394 표준의 8절에서 한정된 프로토콜을 사용한다. MGMTAllocateBandwidth 루틴의 호출 약정은 다음과 같다.

status MGMTAllocateBandwidth(ActivateReqPtr context, MGMTAllocateCh- BlockPtr allocateChBlock);

MGMTAllocateBandwidth 루틴의 가능한 상태 복귀 값은, 대역폭이 성공적으로 할당되었음을 나타내는 GOOD, 문맥 파라메터가 API에 대한 현재 활성 연결의 어드레스를 포함하지 않음을 나타내는 INVALIDCONNECTION, API가 요청을 수용하였음을 나타내는 PENDING, 요청된 대역폭이 현재 유효하지 않음을 나타내는 BWUNAVAILABLE, 및 예기치 않은 에러가 발생하였음을 나타내는 UNDEFINEDERROR이다. 계류중인 값이 복귀되면, API는 할당 요청이 완결될 때 MGMTCompletion 루틴을 호출하고, 이때 상태 필드는 이러한 요청을 위한 완결 상태를 포함할 것이다.

MGMTAllocateBandwidth 루틴의 제 1 호출 파라메터는 활성 ActivateReq 데이터 구조의 어드레스이다. 제 2 파라메터는 이하의 표 6에서 한정된 바와 같이 데이터 구조의 어드레스를 포함한다.

대역폭 필드는 할당할 대역폭의 양을 포함한다. 이러한 수가 모두 1인 값과 동일하다면, 루틴은 bwAvailable 필드를 채우고, BWUNAVAILABLE 상태를 복귀시킨다. 이것은, 현재 활성인 등시성 소스 관리자로부터 bwAvailable 필드의 현재 값을 결정하기 위해 사용될 수 있음을 주목해야 한다. bwAvailable 필드는 등시성 소스 관리자에서 대역폭/유효 CSR의 현재 값으로 채워진다. CSR 내의 값은 어느 때라도 변화될 수 있어, 이러한 필드 내의 값은 스냅샷일 뿐이고, 후속하는 호출시에는 다른 값이 될 수 있다. MGMTCompletion 필드 내의 값이 NULL(0)과 같지 않다면, 완결시에 호출할 루틴의 어드레스를 포함한다. UserPtr 필드는 애플리케이션의 완결 루틴에 의한 사용을 위해 유효하다. API는 이러한 필드를 변경하지 않는다. 상태 필드는 이러한 호출을 위한 완결 상태를 포함한다. 애플리케이션이 이러한 루틴을 비동기적으로 호출한다면, 이러한 필드는 완결 루틴이 호출될 때까지 PENDING 상태를 포함한다.

MGMTDeAllocateChannel 루틴은 단일의 등시성 채널 번호를 할당해제하기 위하여 IEEE 1394 표준의 8절에 한정된 프로토콜을 사용한다. MGMTDeAllocateChannel 루틴의 호출 약정은 다음과 같다.

status MGMTDeAllocateChannel(ActivateReqPtr context, MGMTAllocateCh- BlockPtr allocateChBlock);

상기 루틴은 두 개의 파라메터를 취하고, 상태 값을 복귀시킨다. MGMTDeAllocateChannel에 대한 가능한 상태 복귀 값은, 채널이 성공적으로 할당해제되었음을 나타내는 GOOD, 문맥 파라메터가 API에 대한 현재 활성 연결의 어드레스를 포함하지 않음을 나타내는 INVALIDCONNECTION, API가 요청을 수용하였음을 나타내는 PENDING, 요청된 채널 번호가 할당되지 않았음을 나타내는 CHUNAVAILABLE, 및 예기치 않은 에러가 발생하였음을 나타내는 UNDEFINEDERROR이다. 계류중인 값이 복귀되면, API는 할당 요청이 완결될 때 MGMTCompletion 루틴을 호출하고, 이때 상태 필드는 이러한 요청을 위한 완결 상태를 포함할 것이다.

MGMTDeAllocateChannel 루틴의 제 1 호출 파라메터는 활성 ActivateReq 데이터 구조의 어드레스이다. 제 2 파라메터는 MGMTAllocateChBlock 데이터 구조의 어드레스를 포함한다. 이러한 루틴은 상기 데이터 구조의 채널 필드 내에서 지정된 채널을 할당해제하고, chAvailable 필드를 현재 활성인 등시성 소스 관리자로부터 채널 유효 비트 마스크의 현재 값으로 채운다.

MGMTDeAllocateBandwidth 루틴은 등시성 대역폭을 할당해제하기 위하여 IEEE 1394 표준의 8절에서 한정된 프로토콜을 사용한다. MGMTDeAllocateBandwidth 루틴의 호출 약정은 다음과 같다.

status MGMTDeAllocateBandwidth(ActivateReqPtr context, MGMTAllocateCh- BlockPtr allocateChBlock);

상기 루틴은 두 개의 파라메터를 취하고, 상태 값을 복귀시킨다. MGMTDeAllocateBandwidth 루틴을 위한 가능한 상태 복귀 값은, 대역폭이 성공적으로 할당해제되었음을 나타내는 GOOD, 문맥 파라메터가 API에 대한 현재 활성 연결의 어드레스를 포함하지 않음을 나타내는 INVALIDCONNECTION, API가 요청을 수용하였음을 나타내는 PENDING, 이러한 요청을 완결하는 것은 등시성 소스 관리자 내의 대역폭_유효 레지스터가 유효하지 않게 하고, 어떠한 동작도 일어나지 않았음을 나타내는 BWUNAVAILABLE, 및 예기치 않은 에러가 발생하였음을 나타내는 UNDEFINEDERROR이다. 계류중인 값이 복귀되면, API는 할당 요청이 완결될 때 MGMTCompletion 루틴을 호출하고, 이때 상태 필드는 이러한 요청을 위한 완결 상태를 포함할 것이다.

MGMTDeAllocateBandwidth 루틴의 제 1 호출 파라메터는 활성 ActivateReq 데이터 구조의 어드레스이다. 제 2 파라메터는 MGMTAllocateBWBlock 데이터 구조의 어드레스를 포함한다. 이러한 루틴은 대역폭 필드 내에 포함된 대역폭을 할당해제하고, bwAvailable 필드를 현재 활성인 등시성 소스 관리자 내에서 대역폭_유효 레지스터의 현재 값으로 채운다.

MGMTBusInfo 루틴은; 애플리케이션이 동작 중인 노드와 연결된 IEEE 1394 버스에 대한 정보를 복귀시킨다. 이러한 정보는 IEEE 1394 표준에서 한정된 바와 같이, PHY 갭 카운터의 현재 설정값, 연결된 IEEE 1394 버스 상의 노드의 수, 버스 토폴로지 맵에 대한 포인터, 및 버스 속도 맵에 대한 포인터를 포함한다.

ASYNDataRequest 루틴은, 64 비트 IEEE 1394 어드레스 공간 내에서 어드레스의 선형 범위와 애플리케이션의 데이터 버퍼 사이에서 데이터를 전달하기 위하여, 하나 이상의 IEEE 1394 비동기 판독 또는 기록 트랜잭션을 생성한다. ASYNDataRequest 루틴은 다음의 호출 약정을 갖는다.

STATUS ASYNDataRequest(ActivateReqPtr request, asyncTransportPtr xfrBlock);

ASYNDataRequest 루틴에 대한 가능한 상태 복귀 값은, API가 데이터 전송 요청을 성공적으로 완결하였음을 나타내는 GOOD, API가 요청을 수용하였고 이후의 시간에 이를 완결할 것임을 나타내는 PENDING, flags.opCode 필드에 알지 못하는 코드가 존재함을 나타내는 INVALIDOPCODE, activateReqPtr 필드가 활성 연결을 나타내지 않음을 나타내는 INVALIDCONNECTION, 및 일부 데이터가 전달되었을 지라도, 요청을 받아들이려고 시도하는 동안 예기치 않은 에러가 발생하였음을 나타내는 UNDEFINEDERROR이다.

ASYNDataRequest 루틴의 제 1 파라메터는 유효 activateReq 데이터 구조의 어드레스를 포함한다. 제 2 파라메터는 asyncTransport 데이터 구조의 어드레스를 포함한다. 이러한 데이터 구조는 이하의 표 7에서 한정되는 바와 같이 요청된 데이터 전송 동작을 기술한다.

ASYdata 필드는 요청을 관리하기 위한 전용 데이터를 포함한다. OpCode 필드는, 요청된 동작을 기술하고, asyncOpCodes enum 내에서 한정된 값 중 하나가 되어야만 하는, 코드를 포함한다. NonIncr 필드는, 1로 설정될 때 루틴으로 하여금 remoteBufPtr 필드에 포함된 동일한 IEEE 1394 어드레스에 모든 데이터를 전달하게 하고, 0으로 설정될 때 루틴으로 하여금, remoteBufPtr 필드 내에 포함된 어드레스와 함께 시작하는, IEEE 1394 어드레스의 증분 범위에 데이터를 전달하게 한다. BlockSize 필드는, 모든 블록의 판독 또는 기록 요청 부-동작을 위해 사용하기 위하여, 최대 크기를 바이트 형태로 포함한다. 0의 값은 선택된 버스 속도에 대해 최대 요청 크기를 사용하는 것을 의미한다. APPLBufPtr 필드는 애플리케이션 데이터 버퍼를 위한 기술자를 포함한다. RemoteBufPtr 필드는 원격 IEEE 1394 노드에서 데이터 버퍼의 64비트 어드레스를 포함한다. 길이 필드는 전달할 바이트의 수를 포함하는데, 상기 바이트 수는 애플리케이션 데이터 버퍼의 길이와 같거나 이보다 적을 것이다. AsyncCompletion 필드가 0과 같지 않을 때, 데이터 전송을 완결할 시에 호출할 루틴의 어드레스를 포함한다. UserPtr 필드는 애플리케이션 완결 루틴을 호출하는 것에 의한 사용을 위해 유효하고, API에 의해 변경되지 않는다. 상태 필드는 요청된 데이터 전송 동작의 상태를 포함한다. 이러한 필드는 비동기 동작이 완결될 때까지 "계류중" (" pending") 상태를 포함한다. 완결 루틴이 호출될 때, 이러한 필드는 완결 상태를 포함할 것이다.

ASYNLockRequest 루틴은 IEEE 1394 버스 상에서 하나의 로크 트랜잭션을 생성한다. ASYNLockRequest 루틴은 다음의 호출 약정을 갖는다.

STATUS ASYNLockRequest (ActivateReqPtr request, AsyncLockBlockPtr lockBlock);

ASYNLockRequest 루틴에 대한 가능한 상태 복귀 값은, API가 로크 트랜잭션을 성공적으로 수행하였고, 그 결과가 AsyncLockBlock에 포함되었음을 나타내는 GOOD, API가 요청을 수용하였고 이후의 시간에 이를 완결할 것임을 나타내는 PENDING, AsyncLockBlock 데이터 구조의 OpCode 필드에 알지 못하는 코드가 존재함을 나타내는 INVALIDOPCODE, activateReqPtr 필드가 활성 연결을 나타내지 않음을 나타내는 INVALIDCONNECTION, 및 일부 데이터가 전달되었을 지라도, 요청을 받아들이려고 시도하는 동안 예기치 않은 에러가 발생하였음을 나타내는 UNDEFINEDERROR이다.

ASYNLockRequest 루틴의 제 1 파라메터는 유효 activateReq 데이터 구조의 어드레스를 포함한다. 제 2 파라메터는 AsyncLockBlock 데이터 구조의 어드레스를 포함한다. 이러한 데이터 구조는 이하의 표 8에서 한정된 바와 같이 요청된 데이터 전송 동작을 기술한다.

APIPrivate 필드는 요청을 관리하기 위한 전용 데이터를 포함한다. OpCode 필드는, 요청된 동작을 기술하고, asyncOpCodes enum 내에서 한정된 값 중 하나이어야만 하는, 코드를 포함한다. ArgData struct 필드는 이러한 로크 트랜잭션을 위한 인수 및 데이터를 포함한다. remoteBufPtr 필드는 IEEE 1394 버스 상의 64비트 목적지 어드레스를 포함한다. AsyncCompletion 필드가 0과 같지 않을 때, 로크 트랜잭션을 완결할 때 호출할 루틴의 어드레스를 포함한다. UserPtr 필드는 애플리케이션 완결 루틴을 호출하는 것에 의한 사용을 위해 유효하고, API에 의해 변경되지 않는다. 상태 필드는 요청된 데이터 전송 동작의 상태를 포함한다. 이러한 필드는 비동기 동작이 완결될 때까지 " 계류중"(" pending") 상태를 포함한다. 완결 루틴이 호출될 때, 이러한 필드는 완결 상태를 포함할 것이다.

등시성 소스 관리 루틴은 IEEE 1394 인터페이스를 통해 애플리케이션 데이터 버퍼에 또는 이로부터 등시성 데이터를 전달하기 위하여 필요한 시스템 소스를 할당 및 할당해제한다. 할당 및 할당해제는 시스템 내에서 등시성 데이터의 복수의 잠재적 애플리케이션 사이에서 충돌을 피하기 위하여 필요하다. 등시성 데이터가 IEEE 1394 버스를 통해 흐를 때면 언제나, 필요한 버스 소스 즉, 채널 번호 및 대역폭을 소유하는 실체가 IEEE 1394 버스 상에 존재하게 된다. 등시성 데이터를 사용하는 각 애플리케이션은, 이들 소스를 누가, 언제 할당 및 할당해제해야만 지에 대한 규칙의 세트를 구비한다. API 내의 버스 관리 루틴은 애플리케이션으로 하여금 IEEE 1394 표준의 요구 사항에 따라 이들 소스를 할당하도록 허용한다. 이러한 부분 내의 루틴은 IEEE 1394 버스 소스를 할당하지 않고, 이들 루틴은 애플리케이션 데이터 버퍼에 또는 이로부터 등시성 데이터를 전달하는데 필요한 시스템 레벨 소스만을 할당할 뿐인 것을 주목해야 한다. 이들 소스는, 낮은 레벨의 인터럽트 조정기 및 디스패처(dispatcher)와 같은, DMA 채널과 이를 유지하기 위한 상기 시스템 소스를 포함한다.

ISOCHOpen 루틴은 등시성 포트를 개방하고 초기화시킨다. 등시성 포트는, API의 애플리케이션과 API가 동작하는 로컬 노드 내에서의 하드웨어와 소프트웨어 소스의 집합이다. 소스의 이러한 집합은, 상기 노드에 또는 이로부터 등시성 데이터의 단일 스트림을 전달하는데 요구되는, 로컬 노드 내의 모든 것을 구성한다. 소스의 이러한 집합은, IEEE 1394 표준의 8절에 한정된 버스 관리 규칙, 통제 애플리케이션 규칙 및 요건에 따라 애플리케이션이 개별적으로 할당하여야만 하는 IEEE 1394 버스 소스를 포함하지 않는다. API의 애플리케이션이 IEEE 1394 버스 소스를 할당 및 할당해제할 수 있도록 하는 상기 루틴은 위에서 기술되었다.

포트 개방 루틴은 다음의 호출 약정을 갖는다.

status ISOCHOpen(ActivateReqPtr connectionPtr, ISOCHOpenBlockPtr openBlock);

포트 개방 루틴의 제 1 파라메터는 유효 activateReq 데이터 구조의 어드레스를 포함한다. 제 2 파라메터는 ISOCHOpenBlock 데이터 구조의 어드레스를 포함한다. 이러한 루틴의 성공적인 완결 시에, 이러한 포트에 영향을 미치는 API에 대한 미래의 호출 시에 이러한 개방된 등시성 포트를 참조하기 위하여, 애플리케이션은 이러한 ISOCHOpenBlock 데이터 구조를 사용한다.

포트 개방 루틴에 대한 가능한 상태 복귀 값은, 개방 요청이 성공적으로 완결되었음을 나타내는 GOOD, API가 요청을 수용하였고 이후의 시간에 이를 완결할 것임을 나타내는 PENDING, 등시성 포트 또는 다른 필요한 소스가 현재 유효하지 않고 요청이 거부되었음을 나타내는 NORESOURCES, 요청된 버스 속도가 지원되지 않음을 나타내는 INVALIDREQUEST, ActivateReqPtr 필드가 활성 API 연결을 나타내지 않음을 나타내는 INVALIDCONNECTION, 및 요청이 받아들여질 수 없지만, 에러가 확인될 수 없음을 나타내는 UNDEFINEDERROR이다.

포트 개방 루틴의 호출 파라메터는 ISOCHOpenBlock 데이터 구조의 어드레스를 포함한다. 이러한 데이터 구조는 이하의 표 9에서 한정된 바와 같이 요청을 기술한다.

방향 필드는 등시성 데이터 전송의 방향을 나타낸다. AsyncCompletion 필드가 0과 같지 않을 때, 완결 시에 호출할 루틴의 어드레스를 포함한다. UserPtr 필드는 호출하는 애플리케이션의 완결 루틴에 의한 사용을 위해 유효하고, API에 의해 변경되지 않는다. 상태 필드는 요청된 데이터 전송 동작의 상태를 포함한다. 이러한 필드는 비동기 데이터 전송 동작이 완결될 때까지 " 계류중" (" pending" )인 상태를 포함한다. 완결 루틴이 불려질 때, 이러한 필드는 완결 상태를 포함한다. 애플리케이션이 등시성 포트로 종료될 때, isochPortPtr를 ISOCHClose 루틴에 전달한다.

ISOCHClose 루틴은, ISOCHOpen 루틴을 사용하여 이전에 개방된 등시성 포트를 닫는다. 이러한 루틴은 다음과 같은 호출 약정을 갖는다.

STATUS ISOCHClose (ActivateReqPtr connectionPtr, ISOCHOpenBlockPtr OpenBlock);

이러한 루틴은 단일의 파라메터를 취하고 상태 값을 복귀시킨다. 이러한 루틴은 비동기적으로 실행하고, 완결 시에 ISOCHOpenBlock에서 한정된 완결 루틴을 불러낸다. ISOCHClose 루틴에 대한 가능한 상태 복귀 값은, 동작이 성공적으로 완결되었음을 나타내는 GOOD, API가 요청을 수용하였고 이후의 시간에 이를 완결할 것임을 나타내는 PENDING, connectionPtr이 활성 API 연결을 나타내지 않거나 또는 openBlock이 현재 개방된 등시성 포트를 나타내지 않음을 나타내는 INVALIDCONNECTION, 및 요청이 받아들여질 수 없지만, 에러가 확인될 수 없음을 나타내는 UNDEFINEDERROR이다.

ISOCHClose 루틴의 제 1 호출 파라메터는 유효 activateReq 데이터 구조의 어드레스이다. 제 2 호출 파라메터는 ISOCHOpen 루틴으로 포트를 개방시키기 위해 사용되는 ISOCHOpenBlock의 어드레스이다.

등시성 데이터 제어 루틴은 애플리케이션 데이터 버퍼로의 또는 이로부터의 등시성 데이터 스트림을 제어한다. 등시성 데이터를 청취하는 애플리케이션에 대하여, 이들 제어 루틴은 시스템으로의 등시성 데이터의 흐름에 영향을 미칠 뿐이고, IEEE 1394 버스 자체 상의 등시성 데이터에는 영향을 미치지 않는다. 애플리케이션 데이터 버퍼로부터 등시성 데이터를 전달하는 애플리케이션에 대하여, 이들 제어 루틴은 또한 IEEE 1394 버스 상의 등시성 데이터의 흐름에 영향을 미친다.

ISOCHControl 루틴은 다음의 호출 약정을 갖는다.

STATUS ISOCHControl(ISOCHOpenBlockPtr openBlockPtr, ISOCHCtlBlockPtr ctlReqPtr);

ISOCHControl 루틴에 대한 가능한 상태 복귀 값은, 동작이 성공적으로 완결되었음을 나타내는 GOOD, openBlock 필드가 활성 등시성 포트를 나타내지 않음을 나타내는 INVALIDCONNECTION, 동작이 현재 계류중임을 나타내는 PENDING, ISOCHControlBlock의 opCode 필드가 불법적인 값을 포함하였음을 나타내는 INVALIDOPCODE, 동작이 IEEE 1394 인터페이스 하드웨어의 제한 또는 소프트웨어 또는 동작 환경의 제한으로 인해 지원되지 않음을 나타내는 UNSUPPORTEDOP, 및 동작이 수행될 수 없지만, 에러가 확인될 수 없음을 나타내는 UNDEFINEDERROR이다. 계류중인 값이 복귀된다면, 콜백 루틴이 호출되는 시간에, ISOCHControlBlock 내의 상태 필드는 제어 요청의 완결 상태를 포함할 것이다.

ISOCHControl 루틴의 제 1 파라메터는 유효 ISOCHOpenBlock 데이터 구조의 어드레스를 포함한다. 제 2 파라메터는 ISOCHCtlBlock 데이터 구조의 어드레스를 포함한다. 이러한 데이터 구조는 다음의 표 10에서 한정된 바와 같이 요청된 제어 동작을 기술한다.

APIPrivate 필드는 이러한 요청을 관리하기 위하여 API에 의해 사용된 전용 저장 값을 포함한다. IsoOpCode 필드는, 요청된 제어 동작을 설명하는 IsoOpCode enum으로부터 한 값을 포함한다. IsoEvent 필드는, 요청된 동작을 수행하는 트리거 이벤트를 지정한다. IsoEvent 필드가 "SYFIELD" 값을 포함한다면, Sy 필드는 등시성 채널이 시작하거나 정지하도록 야기하는, sy 필드 내의 값을 포함한다. IsoOpCode 필드가 " 개시" (" START") 값을 포함한다면, 태그(Tag) 필드로부터의 값은 등시성 데이터 블록의 패킷 헤더 내의 태그(Tag)값을 위하여 사용된다. IsoOpCode 필드가 "개시" 값을 포함한다면, 채널 필드로부터의 값은 등시성 데이터 블록의 패킷 헤더 내의 채널 값을 위하여 사용된다. IsoEvent 필드가 " 시간" (" TIME") 값을 포함한다면, 시간 필드는 요청된 동작이 발생하려 하는 버스 시간을 포함한다. AysncCompletion 필드가 0과 같지 않을 때, 데이터 전송 완결 시에 호출하려는 루틴의 어드레스를 포함한다. UserPtr 필드는 호출하는 애플리케이션의 완결 루틴에 의한 사용을 위해 유효하다. API는 이러한 필드를 변경하지 않는다. 상태 필드는 요청된 데이터 전송 동작의 상태를 포함한다. 이러한 필드는 비동기 데이터 전송 동작이 완결될 때까지 " 계류중"(" pending")인 상태를 포함한다. 완결 루틴이 호출될 때, 이러한 필드는 완결 상태를 포함한다.

등시성 부속 루틴은 애플리케이션 데이터 버퍼 기술자를 API 소프트웨어에 전달한다. 애플리케이션은 버퍼를, IEEE 1394 인터페이스 하드웨어와, 소프트웨어의 관련 하부 층에 유효하도록 하기 위하여, 어느 때라도 이러한 루틴을 호출할 수 있다. 이러한 루틴을 위한 호출 약정은 다음과 같다.

status ISOCHAttach(ISOCHOpenBlockPtr openBlock, ISOCHAppendBlockPtr append);

등시성 부속 루틴에 대한 가능한 상태 복귀 값은, 동작이 완결되었고 애플리케이션 데이터 버퍼가 수용되었음을 나타내는 GOOD, openBlock 필드가 활성 등시성 포트를 나타내지 않음을 나타내는 INVALIDCONNECTION, 하드웨어 실행, 소프트웨어 실행 또는 다른 시스템 환경의 제한으로 인해 기인할 수 있는, 버퍼 기술자 내에서 지정된 재동기화 이벤트가 지원되지 않음을 나타내는 UNSUPPORTEDOP, 등시성 데이터가 흐르는 동안 애플리케이션 데이터 버퍼의 원형 목록을 추가하거나, 또는 등시성 데이터가 흐르는 동안 현존 원형 목록에 새로운 버퍼를 추가하려는 시도를 나타내는 INVALIDREQUEST, 및 동작이 수행될 수 없지만, 실제 에러가 확인될 수 없음을 나타내는 UNDEFINEDERROR이다.

ISOCHAttach 루틴의 제 1 파라메터는 유효 ISOCHOpenBlock 데이터 구조의 어드레스를 포함한다. 제 2 파라메터는 ISOCHAppendBlock 데이터 구조의 어드레스를 포함한다. 이러한 데이터 구조는 다음의 표 11에서 한정된 바와 같이 애플리케이션 데이터 버퍼 목록을 기술한다.

APIPrivate 필드는 요청을 관리하기 위하여 API에 의해 사용된 전용 저장 값을 포함한다. IsochBuffList 필드는, 지정된 포트에 부가하기 위한 목록의 제 1 등시성 버퍼의 어드레스를 포함한다. 현재의 버퍼 목록 또는 부가하려는 버퍼 목록이 원형이라면, 동작은 포트가 정지될 때에만 수행될 수 있고, 부가된 동작은 이전에 부가된 어떠한 버퍼라도 교체할 것이다. 버퍼의 원형이 아닌 목록은 버퍼의 현존 원형이 아닌 목록에 어느 때라도 부가될 수 있다. AysncCompletion 필드가 0과 같지 않을 때, 완결 시에 호출하려는 루틴의 어드레스를 포함한다. UserPtr 필드는 호출하는 애플리케이션의 완결 루틴에 의한 사용을 위해 유효하고, API에 의해 변경되지 않는다. 상태 필드는 요청된 동작의 상태를 포함한다. 이러한 필드는 비동기 데이터 동작이 완결될 때까지 " 계류중" (" PENDING")인 상태를 포함한다. 완결 루틴이 불려질 때, 이러한 필드는 완결 상태를 포함할 것이다.

IsochBuffList 필드는 isochBuffer의 어드레스를 포함한다. isochBuffer 데이터 구조는 단일의 애플리케이션 데이터 버퍼를 기술한다. 전형적으로, isochBuffer 데이터 구조는 이중으로 링크된 목록으로 존재한다. 이러한 데이터 구조는 다음의 표 12에서 한정된다.

다음 필드는 목록 내의 다음 버퍼의 어드레스를 포함한다. 이전 필드는 목록 내의 이전 버퍼의 어드레스를 포함한다. 원형 필드는 버퍼의 완결 세트가 원형임을 나타낸다. ResynchEvent 필드는 선택적인 재동기화 이벤트를 포함한다. 이러한 필드 내의 IMMEDIATE 값은 재동기화 없음을 나타낸다. ResynchEvent 필드가 " SY 필드" (" SYFIELD")의 값을 포함할 때, Sy 필드는 이러한 애플리케이션 데이터 버퍼에 또는 이로부터 데이터를 전달하기 전에 잠시 정지시키기 위한 sy 값을 포함한다. ResynchEvent 필드가 " 시간" (" TIME") 값을 포함할 때, 시간 필드는 이러한 애플리케이션의 데이터 버퍼에 또는 이로부터 데이터를 전달하기 전에 대기하는 버스 시간을 포함한다. ApplBufPtr 필드는 애플리케이션 데이터 버퍼의 어드레스를 포함한다. 이러한 어드레스는, 동작 환경의 성능에 따라, 논리적, 물리적, 분산된 또는 연속하는 것이 될 수 있다. IsochCompletion 필드는 완결 루틴의 어드레스를 포함한다. 이러한 필드 내의 값이 0이 아니라면, 이러한 루틴은, 이러한 버퍼를 위한 데이터 전송이 완결될 때, 호출된다. UserPtr 필드는 호출하는 애플리케이션의 완결 루틴에 의한 용도에 유효하고, API에 의해 변형되지 않는다.

ISOCHDetach 루틴은 API로부터 애플리케이션 데이터 버퍼를 검색하고, 애플리케이션으로 소유권을 복귀시킨다. IEEE 1394 인터페이스 하드웨어로부터와, 소프트웨어의 관련 하부 층으로부터 버퍼를 분리하게 위하여, 애플리케이션은 이러한 루틴을 언제라도 호출할 수 있다. 요청된 버퍼는 완결 루틴이 불려질 때 분리된다. 이러한 루틴을 위한 호출 약정은 다음과 같다.

status ISOCHDetach(ISOCHOpenBlockPtr openBlock, ISOCHAppendBlockPtr unhook);

ISOCHDetach 루틴에 대한 가능한 상태 복귀 값은, 동작이 완결되었고, 이제 애플리케이션 데이터 버퍼가 분리되었음을 나타내는 GOOD, 동작이 현재 계류중임을 나타내는 PENDING, openBlock 필드가 활성 등시성 포트를 나타내지 않음을 나타내는 INVALIDCONNECTION, ISOCHAppendBlock 내에서 기술된 버퍼가 발견되지 않았거나, 또는 이들이 ISOCHOpenBlock 구조 내에서 기술된 등시성 포트에 의해 소유되지 않음을 나타내는 INVALIDREQUEST, 및 동작이 수행될 수 없지만, 실제 에러가 확인될 수 없음을 나타내는 UNDEFINEDERROR이다. 계류중인 값이 복귀된다면, 콜백 루틴이 호출되는 시간에, ISOCHAppendBlock 내의 상태 필드는 분리 동작의 완결 상태를 포함할 것이다.

ISOCHDetach 루틴의 제 1 파라메터는 유효 ISOCHOpenBlock 데이터 구조의 어드레스를 포함한다. 제 2 파라메터는 ISOCHAppendBlock 데이터 구조의 어드레스를 포함한다. 이러한 데이터 구조는 상술한 바와 같은 애플리케이션 데이터 버퍼 목록을 기술한다.

본 발명의 애플리케이션 프로그래밍 인터페이스는 애플리케이션에 인터페이스를 제공하고, 애플리케이션으로 하여금 버스 구조를 통해 등시성 및 비동기 데이터 포맷으로 데이터를 전달하도록 허용한다. 애플리케이션 프로그래밍 인터페이스는 등시성 데이터 전송 도중에 버스 구조(28)를 통한 비동기 데이터의 전달을 지원한다. 등시성 데이터가 버스 구조(28)를 통하여 전달되는 동안, 비동기 데이터는 간격(gaps)을 채우기 위해 사용될 수 있다. IEEE 1394 표준은 등시성 데이터에 대한 최악의 경우의 지터(jitter)를 규정하여, 등시성 데이터의 한 패킷에 대한 제한된 잠재성을 지정한다. 그러므로 API(20)는 등시성 데이터의 패킷이 적절한 시간 기간 동안 전달되는 것을 보장한다. 그러나, 등시성 데이터의 패킷 사이의 간격 내에서, 데이터의 등시성 패킷이 전달된다.

종래 기술의 시스템과는 대조적으로, 본 발명의 API는 자동 트랜잭션 생성기(38)를 제어함으로써 비동기 데이터의 전달을 자동화할 수 있는데, 상기 생성기(38)는 메모리 맵핑된 버스 구조(28)를 통한 비동기 데이터 전송을 완결하는데 필요한 트랜잭션을 자동적으로 생성한다. 등시성 데이터 전송 도중에, 각각이 대응하는 버퍼를 나타내는 버퍼 기술자들의 연결된 목록은 버스 구조(28)를 통해서 애플리케이션을 향한 또는 애플리케이션으로부터 나오는 데이터 전송을 위하여 유지된다. 각 버퍼는 콜백 루틴과 재동기화 이벤트를 포함할 수 있다.

본 발명은, 본 발명의 구성 및 동작 원리의 이해를 쉽게 하기 위한 상세 사항을 병합한 특정 실시예의 관점에서 설명되었다. 특정 실시예와 이들의 상세 사항에 대한 이러한 참조는 이하에 첨부된 청구 범위의 범주를 제한하려는 것은 아니다. 설명을 위하여 선택된 실시예에서 본 발명의 사상과 범주를 벗어남이 없이 변형이 이루어질 수 있다는 것은 당업자에게는 자명할 것이다.

상술한 바와 같이, 본 발명은, 버스 구조를 통하여 통신하기 위한 애플리케이션을 위한 인터페이스를 제공하는 분야에 이용되며, 특히, 비동기 및 등시성(isochronous) 포맷 모두로 버스 구조를 통하여 애플리케이션 사이에서 버스 관리 및 데이터 전송 동작을 제어하는 분야에 이용된다.

Claims

버스 구조(28)를 통하여 애플리케이션(application)을 향한 또는 애플리케이션으로부터의 데이터 전송을 제어하기 위한, 애플리케이션과 상기 버스 구조(28) 사이의 인터페이스에 있어서,

a. 상기 애플리케이션(24)에 메모리 맵핑된(memory-mapped) 인터페이스를 제공하기 위하여, 상기 애플리케이션(24)과 상기 버스 구조(28) 사이에서의 비동기 데이터 전송을 제어하기 위한 수단으로서, 상기 버스 구조(28)를 통과하는 데이터의 비동기 전송을 완결하기 위하여 필요한 요청을 직접적인 프로세서 제어 없이 자동으로 생성하는, 비동기 데이터 전송을 제어하기 위한 수단과,

b. 버퍼의 연결된 목록을 포함하는, 애플리케이션(22)과 상기 버스 구조(28) 사이에서 등시성(isochronous) 데이터 전송을 제어하기 위한 수단을

포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 1항에 있어서, 비동기 데이터 전송을 제어하기 위한 상기 수단은 상기 버스 구조(28)로/로부터의 데이터를 패킷(packet)으로 전달 또는 수신하는데, 상기 패킷 각각은 목적지 확인자, 어드레스 및 길이 값을 포함하는 헤더를 구비하는 것을 특징으로 하는, 애플리케이션과 상기 버스 구조 사이의 인터페이스.
제 2항에 있어서, 비동기 데이터 전송을 제어하기 위한 상기 수단은, 상기 버스 구조(28)를 가로질러 데이터의 비동기 전송을 완결하기 위하여 필요한 요청을 자동적으로 생성하기 위한 자동화된 하드웨어 인터페이스를 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 3항에 있어서, 상기 버스 구조(28)는 IEEE 1394 표준 버스 구조인 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 1항에 있어서, 상기 연결된 버퍼 각각은 전방 포인터(forward pointer)와 후방 포인터(backward pointer)를 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 5항에 있어서, 상기 연결된 버퍼 각각은, 데이터 전송 동작 도중의 소정의 시점에 상기 애플리케이션을 호출하기 위한 콜백(callback) 루틴을 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 6항에 있어서, 상기 연결된 버퍼 각각은, 상기 애플리케이션을 상기 데이터 전송에 재동기화시키기 위한 재동기화 이벤트(a resynchronization event)를 더 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 7항에 있어서, 버퍼를 상기 연결된 목록에 부가하기 위한 수단을 더 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 8항에 있어서, 상기 연결된 목록으로부터 버퍼를 제거하기 위한 수단을 더 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
애플리케이션과 버스 구조(28) 사이에서의 데이터 전송 동작을 제어하기 위한, 상기 애플리케이션과 상기 버스 구조(28) 사이의 인터페이스에 있어서,

a. 상기 애플리케이션과 통신하고, 상기 애플리케이션으로부터 요청을 수신하고, 상기 애플리케이션에 지령을 보내기 위한 애플리케이션 인터페이스(20)와,

b. 상기 애플리케이션(24)에 의해 할당된 버퍼와 상기 버스 구조(28) 상의 노드 사이에서 비동기 데이터 전송 동작을 직접적인 프로세서 제어 없이 완결하기 위하여 필요한 트랜잭션을 자동적으로 생성하기 위한 자동 트랜잭션 생성기(38)와,

c. 등시성 데이터 전송이 완결될 예정인 상기 애플리케이션(22)에 의해 제공된 버퍼의 연결된 목록을 포함하는, 상기 등시성 데이터 전송을 제어하기 위한 수단과,

d. 상기 버스 구조(28)에 물리적인 인터페이스(26)를 제공하고, 상기 버스 구조(28)를 통하여 데이터 패킷을 송신하고 수신하기 위한 버스 인터페이스를

포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 10항에 있어서, 버퍼의 상기 연결된 목록은 각 버퍼를 위한 전방 포인터와 후방 포인터를 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 11항에 있어서, 각 버퍼는, 데이터 전송 동작 도중의 소정의 시점에 상기 애플리케이션을 호출하기 위해 활성화되는 콜백 루틴을 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 12항에 있어서, 각 버퍼는, 상기 애플리케이션을 데이터 전송 동작 도중의 소정의 시점에 재동기화시키기 위해 활성화되는 재동기화 이벤트를 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 13항에 있어서, 버퍼를 상기 연결된 목록에 부가하기 위한 수단을 더 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 14항에 있어서, 상기 연결된 목록으로부터 버퍼를 제거하기 위한 수단을 더 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 10항에 있어서, 상기 자동 트랜잭션 생성기(38)는 하드웨어 논리 회로로 실현되는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 10항에 있어서, 상기 자동 트랜잭션 생성기(38)는 소프트웨어로 실현되는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
메모리 맵핑된 인터페이스를 애플리케이션(24)에 제공하고, 상기 애플리케이션(24)과 버스 구조(28) 사이에서 비동기 데이터 전송 동작을 관리하기 위한 방법에 있어서,

a. 상기 애플리케이션(24)으로부터 데이터 전송 동작을 위한 요청을 받아들이는 단계와,

b. 상기 버스 구조(28)를 통한 상기 데이터 전송 동작을 완결하는데 필요한 트랜잭션을 직접적인 프로세서 제어 없이 자동으로 생성하기 위한 자동 트랜잭션 생성기(38)에 지령을 제공하는 단계와,

c. 상기 애플리케이션(24)에 상기 데이터 전송 동작이 완결되는 때를 통지하는 단계를

포함하는 것을 특징으로 하는, 메모리 맵핑된 인터페이스를 제공하고 비동기 데이터 전송 동작을 관리하는 방법.
제 18항에 있어서, 상기 요청은 애플리케이션 버퍼를 위한 어드레스, 상기 버스 구조(28)의 어드레스 공간 내의 시작 어드레스, 전달될 데이터의 길이 및 상기 전달의 방향을 포함하는 것을 특징으로 하는, 메모리 맵핑된 인터페이스를 제공하고 비동기 데이터 전송 동작을 관리하는 방법.
제 19항에 있어서, 상기 시작 어드레스는 64 비트 어드레스인 것을 특징으로 하는, 메모리 맵핑된 인터페이스를 제공하고 비동기 데이터 전송 동작을 관리하는 방법.
제 20항에 있어서, 상기 버스 구조는 IEEE 1394 표준 버스 구조인 것을 특징으로 하는, 메모리 맵핑된 인터페이스를 제공하고 비동기 데이터 전송 동작을 관리하는 방법.
제 18항에 있어서, 상기 자동 트랜잭션 생성기(38)는 하드웨어 논리 회로로 실현되는 것을 특징으로 하는, 메모리 맵핑된 인터페이스를 제공하고 비동기 데이터 전송 동작을 관리하는 방법.
제 18항에 있어서, 상기 자동 트랜잭션 생성기(38)는 소프트웨어로 실현되는 것을 특징으로 하는, 메모리 맵핑된 인터페이스를 제공하고 비동기 데이터 전송 동작을 관리하는 방법.
애플리케이션(24)과 버스 구조(28) 사이의 데이터 전송 동작을 관리하기 위한, 상기 애플리케이션(24)과 상기 버스 구조(28) 사이의 인터페이스에 있어서,

a. 상기 애플리케이션으로부터 요청을 수신하고 상기 애플리케이션에 지령을 보내기 위하여, 상기 애플리케이션(24)과 통신하는 수단과,

b. 상기 애플리케이션(24)의 버퍼와 상기 버스 구조(28)상의 노드 사이에서 비동기 데이터 전송 동작을 완결하기 위하여 필요한 트랜잭션을 직접적인 프로세서 제어 없이 자동으로 생성하기 위한 자동 트랜잭션 생성기(38)와,

c. 상기 버스 구조(28)에 데이터 패킷을 보내고 상기 버스 구조(28)로부터 데이터 패킷을 수신하기 위하여, 상기 버스 구조(28)를 통하여 감시하고 통신하기 위한 수단을

포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 24항에 있어서, 데이터 전송 동작은, 상기 애플리케이션이 통신하기 위한 상기 수단에 요청을 보낼 때, 시작되는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 25항에 있어서, 상기 요청은 상기 애플리케이션의 상기 버퍼를 위한 어드레스, 상기 버스 구조를 가로지르는 시작 어드레스, 전달될 데이터의 길이, 및 상기 전달의 방향을 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 26항에 있어서, 상기 버스 구조(28)는 IEEE 1394 표준 버스 구조인 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 24항에 있어서, 상기 애플리케이션(22)과 상기 버스 구조(28) 사이에서 등시성 데이터 전송 동작을 제어하기 위한 수단을 더 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 28항에 있어서, 등시성 데이터 전송 동작을 제어하기 위한 상기 수단은, 상기 데이터 전송이 완결되려 하는 상기 애플리케이션(22)에 의해 제공된 버퍼의 연결 목록을 유지하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 29항에 있어서, 상기 연결된 목록은 상기 목록 내의 각 버퍼를 위한 전방 포인터와 후방 포인터를 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 29항에 있어서, 상기 목록 내에 포함된 각 버퍼는, 데이터 전송 동작 도중의 소정의 시점에 애플리케이션(22)을 호출하기 위해 활성화되는 콜백 루틴을 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 31항에 있어서, 상기 목록 내에 포함된 각 버퍼는, 상기 애플리케이션(22)을 데이터 전송 동작 도중의 소정의 시점에 재동기화시키기 위해 활성화되는 재동기화 이벤트를 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
애플리케이션(24)과 IEEE 1394 표준 버스 구조(28) 사이에서 데이터 전송 동작을 관리하기 위한, 상기 애플리케이션(24)과 IEEE 1394 표준 버스 구조(28) 사이의 인터페이스에 있어서,

a. 상기 애플리케이션(24)과 통신하고, 상기 애플리케이션(24)으로부터 요청을 수신하고, 상기 애플리케이션(24)에 지령을 보내기 위한 애플리케이션 인터페이스(20)와,

b. 상기 애플리케이션(24)에 의해 할당된 버퍼와 상기 버스 구조(28)상의 노드 사이에서 비동기 데이터 전송 동작을 직접적인 프로세서 제어 없이 완결하기 위하여 필요한 트랜잭션을 자동적으로 생성하기 위한 자동 트랜잭션 생성기(38)와,

c. 상기 버스 구조(28)를 통하여 데이터 패킷을 보내고 수신하기 위하여, 상기 버스 구조(28)에 물리적인 인터페이스(26)를 제공하기 위한 버스 인터페이스 회로를

포함하는 것을 특징으로 하는, 애플리케이션과 IEEE 1394 표준 버스 구조 사이의 인터페이스.
제 33항에 있어서, 데이터 전송 동작은, 상기 애플리케이션(24)이 요청을 상기 애플리케이션 인터페이스(20)에 보낼 때, 시작되는 것을 특징으로 하는, 애플리케이션과 IEEE 1394 표준 버스 구조 사이의 인터페이스.
제 34항에 있어서, 상기 요청은 상기 애플리케이션(24)의 상기 버퍼를 위한 어드레스, 상기 버스 구조(28)를 가로지르는 시작 어드레스, 전달될 데이터의 길이, 및 상기 전달의 방향을 포함하는 것을 특징으로 하는, 애플리케이션과 IEEE 1394 표준 버스 구조 사이의 인터페이스.
제 33항에 있어서, 상기 자동 트랜잭션 생성기(38)는 하드웨어 논리 회로로 실현되는 것을 특징으로 하는, 애플리케이션과 IEEE 1394 표준 버스 구조 사이의 인터페이스.
제 33항에 있어서, 상기 자동 트랜잭션 생성기(38)는 소프트웨어로 실현되는 것을 특징으로 하는, 애플리케이션과 IEEE 1394 표준 버스 구조 사이의 인터페이스.
인터페이스를 애플리케이션(22)에 제공하고, 상기 애플리케이션(22)과 버스 구조(28) 사이에서 등시성 데이터 전송 동작을 관리하기 위한 방법에 있어서,

a. 상기 애플리케이션(22)으로부터 데이터 전송 동작을 위한 요청을 수신하는 단계와,

b. 상기 데이터 전송 동작을 완결하기 위하여, 각각이 상기 애플리케이션(22)에 의해 제공된 버퍼에 대응하는, 버퍼 기술자들(descriptors)의 연결된 목록을 관리하는 단계로서, 데이터는 하나의 버퍼와 상기 버스 구조(28) 사이에서, 상기 애플리케이션이 다른 버퍼를 처리하는 도중에 전달되는, 버퍼 기술자의 연결된 목록을 관리하는 단계를

포함하는 것을 특징으로 하는, 인터페이스를 제공하고 등시성 데이터 전송 동작을 관리하는 방법.
제 38항에 있어서, 등시성 전달 동작 도중에 상기 애플리케이션(22)은 데이터를 버퍼에 로딩함으로써 버퍼를 처리하는 것을 특징으로 하는, 인터페이스를 제공하고 등시성 데이터 전송 동작을 관리하는 방법.
제 38항에 있어서, 등시성 수신 동작 도중에, 상기 애플리케이션(22)은 버퍼로부터 데이터를 얻음으로써 버퍼를 처리하는 것을 특징으로 하는, 인터페이스를 제공하고 등시성 데이터 전송 동작을 관리하는 방법.
제 38항에 있어서, 상기 연결된 목록은, 상기 연결된 목록 내의 각 버퍼를 위한 전방 포인터와 후방 포인터를 포함하는 것을 특징으로 하는, 인터페이스를 제공하고 등시성 데이터 전송 동작을 관리하는 방법.
제 38항에 있어서, 상기 연결된 목록 내의 각 버퍼는, 데이터 전송 동작 도중의 소정의 시점에 상기 애플리케이션(22)을 호출하기 위해 활성화되는 콜백 루틴을 위한 성능을 포함하는 것을 특징으로 하는, 인터페이스를 제공하고 등시성 데이터 전송 동작을 관리하는 방법.
제 38항에 있어서, 상기 목록 내에 포함된 각 버퍼는, 상기 애플리케이션(22)을 데이터 전송 동작 도중의 소정의 시점에 재동기화시키기 위해 활성화되는 재동기화 이벤트를 위한 성능을 포함하는 것을 특징으로 하는, 인터페이스를 제공하고 등시성 데이터 전송 동작을 관리하는 방법.
제 41항에 있어서, 상기 연결된 목록에 버퍼 기술자를 부가하기 위한 수단을 더 포함하는 것을 특징으로 하는, 인터페이스를 제공하고 등시성 데이터 전송 동작을 관리하는 방법.
제 44항에 있어서, 상기 연결된 목록으로부터 버퍼 기술자를 제거하기 위한 수단을 더 포함하는 것을 특징으로 하는, 인터페이스를 제공하고 등시성 데이터 전송 동작을 관리하는 방법.
애플리케이션(22)과 버스 구조(28) 사이의 데이터 전송 동작을 관리하기 위한, 상기 애플리케이션(22)과 상기 버스 구조(28) 사이의 인터페이스에 있어서,

a. 상기 애플리케이션(22)으로부터 요청을 수신하고 상기 애플리케이션(22)에 지령을 보내기 위하여, 상기 애플리케이션(22)과 통신하는 수단과,

b. 각각이 버퍼에 대응하고 버퍼를 나타내는 버퍼 기술자의 연결된 목록의 관리를 포함하는, 상기 애플리케이션(22)과 상기 버스 구조(28) 사이의 등시성 데이터 전송 동작을 제어하기 위한 수단과,

c. 상기 버스 구조(28)로부터 데이터 패킷을 수신하고 데이터 패킷을 보내기 위하여, 상기 버스 구조(28)를 통하여 감시하고 통신하기 위한 수단을

포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 46항에 있어서, 상기 버퍼의 상기 애플리케이션(22)에 의해 제공되는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 47항에 있어서, 상기 연결된 목록은, 상기 연결된 목록 내의 각 버퍼를 위한 전방 포인터를 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 48항에 있어서, 상기 연결된 목록은, 상기 연결된 목록 내의 각 버퍼를 위한 후방 포인터를 더 포함하여, 연결된 목록을 원형으로 구성하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 46항에 있어서, 상기 연결된 목록 내의 각 버퍼 기술자는, 데이터 전송 동작 도중의 소정의 시점에 상기 애플리케이션(22)을 호출하기 위해 활성화되는 콜백 루틴을 위한 성능을 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 46항에 있어서, 상기 목록에 포함된 각 버퍼 기술자는, 상기 애플리케이션(22)을 데이터 전송 동작 도중의 소정의 시점에 재동기화시키기 위해 활성화되는 재동기화 이벤트를 위한 성능을 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 46항에 있어서, 애플리케이션(24)에 의해 할당된 버퍼와 상기 버스 구조 (28) 사이에서 비동기 데이터 전송 동작을 완결하기 위해 필요한 트랜잭션을 자동으로 생성하기 위한 자동 트랜잭션 생성기(38)를 더 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 52항에 있어서, 상기 버스 구조(28)는 IEEE 1394 표준 버스 구조인 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 47항에 있어서, 상기 연결된 목록은, 상기 연결된 목록 내의 각 버퍼를 위한 전방 포인터와 후방 포인터를 포함하여, 상기 연결된 목록을 선형으로 구성하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 54항에 있어서, 상기 연결된 목록에 버퍼를 부가하기 위한 수단을 더 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
제 55항에 있어서, 상기 연결된 목록으로부터 버퍼를 제거하기 위한 수단을 더 포함하는 것을 특징으로 하는, 애플리케이션과 버스 구조 사이의 인터페이스.
애플리케이션(22)과 IEEE 1394 표준 버스 구조(28) 사이에서 데이터 전송 동작을 관리하기 위한, 상기 애플리케이션(22)과 IEEE 1394 표준 버스 구조(28) 사이의 인터페이스에 있어서,

d. 상기 애플리케이션(22)과 통신하고, 상기 애플리케이션(22)으로부터 요청을 수신하고, 상기 애플리케이션(22)에 지령을 보내기 위한 애플리케이션 인터페이스(20)와,

e. 상기 애플리케이션(22)에 의해 제공된 버퍼의 연결된 목록을 포함하는, 상기 애플리케이션(22)과 상기 버스 구조(28) 사이에서 등시성 데이터 전송 동작을 제어하기 위한 수단과,

f. 상기 버스 구조(28)을 통하여 데이터 패킷을 보내고 수신하기 위하여, 상기 버스 구조(28)에 물리적인 인터페이스(26)를 제공하기 위한 버스 인터페이스 회로를

포함하는 것을 특징으로 하는, 애플리케이션과 IEEE 1394 표준 버스 구조 사이의 인터페이스.
제 57항에 있어서, 상기 연결된 목록은, 상기 연결된 목록 내의 각 버퍼를 위한 전방 포인터와 후방 포인터를 포함하여, 상기 연결된 목록을 원형으로 구성하는 것을 특징으로 하는, 애플리케이션과 IEEE 1394 표준 버스 구조 사이의 인터페이스.
제 58항에 있어서, 상기 연결된 목록 내의 각 버퍼는, 데이터 전송 동작 도중의 소정의 시점에 상기 애플리케이션(22)을 호출하기 위해 활성화되는 콜백 루틴을 위한 성능을 포함하는 것을 특징으로 하는, 애플리케이션과 IEEE 1394 표준 버스 구조 사이의 인터페이스.
제 59항에 있어서, 상기 목록 내에 포함된 각 버퍼는, 상기 애플리케이션(22)을 데이터 전송 동작 도중의 소정의 시점에 재동기화시키기 위해 활성화되는 재동기화 이벤트를 위한 성능을 포함하는 것을 특징으로 하는, 애플리케이션과 IEEE 1394 표준 버스 구조 사이의 인터페이스.
제 57항에 있어서, 상기 연결된 목록은, 상기 연결된 목록 내의 각 버퍼를 위한 전방 포인터와 후방 포인터를 포함하여, 상기 목록을 선형으로 구성하는 것을 특징으로 하는, 애플리케이션과 IEEE 1394 표준 버스 구조 사이의 인터페이스.
제 61항에 있어서, 상기 연결된 목록에 버퍼를 부가하기 위한 수단을 더 포함하는 것을 특징으로 하는, 애플리케이션과 IEEE 1394 표준 버스 구조 사이의 인터페이스.
제 62항에 있어서, 상기 연결된 목록으로부터 버퍼를 제거하기 위한 수단을 더 포함하는 것을 특징으로 하는, 애플리케이션과 IEEE 1394 표준 버스 구조 사이의 인터페이스.