KR20170003541A

KR20170003541A - 임베디드 컨트롤러를 사용하여 클래스 디바이스 인터페이스를 하나의 호스트 인터페이스와 통합하는 방법 및 장치

Info

Publication number: KR20170003541A
Application number: KR1020167030074A
Authority: KR
Inventors: 카빈드라 쿠마르; 자야바산스 베탐아닉캠; 아룬 크리쉬난 문단 빌라캐스
Original assignee: 마이크로칩 테크놀로지 인코포레이티드
Priority date: 2014-05-19
Filing date: 2015-05-18
Publication date: 2017-01-09
Also published as: EP3146437A1; WO2015179296A1; TWI646427B; US9569375B2; CN106462514B; EP3146437B1; US20150331830A1; TW201610684A; CN106462514A; JP6642944B2; JP2017516212A

Abstract

호스트 디바이스와 복수의 주변 디바이스들 사이의 통신을 위한 시스템, 디바이스 및 방법이 제공되는데, 상기 통신은 상기 호스트에 의해 지원되는 단일 인터페이스를 사용한다. 상기 호스트는 복수의 클래스 드라이버들과 미니포트 드라이버들을 포함한다. 상기 클래스 드라이버들의 각각은 상기 복수의 주변 디바이스들 중 하나 이상의 주변 디바이스와 연관된 기능을 구현한다. 각각의 미니포트 드라이버는 인터페이스를 제공하며, 이 인터페이스에 의해 상기 클래스 드라이버들 중 하나 이상의 드라이버는 클래스 프로토콜들을 사용하여 상기 복수의 주변 디바이스들 중 하나 이상의 주변 디바이스와 통신하고, 상기 미니포트 드라이버들은 상기 호스트에 의해 지원되는 단일 호스트 인터페이스를 통해 통신한다. 임베디드 컨트롤러는 상기 주변 디바이스들의 각각의 고유한 버스 프로토콜들을 사용하여 상기 복수의 주변 디바이스들과 인터페이스하고, 여기서 상기 임베디드 컨트롤러는 상기 단일 호스트 인터페이스를 사용하여 상기 복수의 미니포트 드라이버들과 인터페이스한다.

Description

임베디드 컨트롤러를 사용하여 클래스 디바이스 인터페이스를 하나의 호스트 인터페이스와 통합하는 방법 및 장치{UNIFYING CLASS DEVICE INTERFACE WITH ONE HOST INTERFACE BY USING EMBEDDED CONTROLLER}

관련 출원에 대한 상호 참조

본 출원은 2014년 5월 19일 출원된 미국 가출원 번호 62/000,089 호의 이익을 주장하며, 상기 미국 가출원은 그 전체가 본 출원에 통합된다.

기술 분야

본 개시는 단일 호스트 인터페이스를 통한 호스트 디바이스와의 주변 디바이스 통신에 관한 것이다.

퍼스널 컴퓨터의 도래로 인해, 입력을 제공하고 호스트 디바이스에서 실행되는 컴퓨터 프로그램들로부터의 출력을 수신하기 위해 사용자들에게 메커니즘들을 제공하는 다양한 휴먼 인터페이스 디바이스들(HIDs)이 꾸준히 확산되어 왔다. 퍼스널 컴퓨터의 능력이 진보함에 따라, 사용자들에게 이용 가능한 주변 HID들은 다양성과 복잡성을 갖고 있다. 이것은 결과적으로 주변 디바이스들과 호스트 디바이스 사이의 통신을 위한 많은 서로 다른 하드웨어 및 소프트웨어 인터페이스들을 초래했다.

주변 디바이스들과의 통신을 지원하기 위해 호스트 디바이스에 의해 이용되는 한 세트의 소프트웨어 인터페이스들은 전형적으로 인터페이스들의 계층 레이어들로서 구성된다. 계층 내의 각 레이어는 호스트 디바이스에 의한 주변 디바이스의 동작에 필요한 기능성의 특정 양상을 구현하는 소프트웨어 프로그램들로 이루어진다. 계층의 하부 레이어들은, 주변 디바이스들에/디바이스들로부터 신호들을 송신하는데 사용되는 하드웨어 버스들과 호스트 디바이스의 프로세서를 인터페이스하는 소프트웨어 프로그램들이다. 계층의 상부 레이어들은 인터페이스를 제공하는 소프트웨어 프로그램들인데, 이 인터페이스에 의해 사용자들 또는 다른 소프트웨어 프로그램들은 주변 디바이스들을 동작시킬 수 있다.

사용하기 위해 새로운 주변 디바이스가 호스트 디바이스에 의해 설치되어질 때, 그 설치 프로세스들의 일부는 호스트 디바이스의 계층이 상기 새로운 주변 디바이스와 통신하는데 필요한 모든 소프트웨어를 포함하는지를 확인하는 절차를 포함한다. 많은 경우들에서, 이 설치 프로세스가 상기 새로운 주변 디바이스를 완벽하게 활용하는데 필요한 디바이스-특정 소프트웨어를 포함하기 위해서는 소프트웨어 계층에 대한 적어도 일부의 업데이트들을 필요로 한다. 디바이스-특정 소프트웨어의 설치가 항상 모든 호환성 문제를 해결하는 것은 아니다. 호스트 디바이스가 새로운 주변 디바이스와 인터페이스하기 위해서는, 호스트 디바이스가 주변 디바이스에 의해 필요한 저-레벨 버스 통신 프로토콜을 지원해야 한다. 일반적으로 호스트 디바이스에 의한 버스 통신 프로토콜의 지원은 호스트 디바이스가 설계 및 제조될 때 이상적으로 구현되는 하드웨어-레벨 버스 구현을 필요로 한다.

키보드 및 마우스와 같은 디바이스들을 포함한 초기 세대의 주변 HID들은 직렬 포트를 사용하여 호스트 디바이스와 인터페이스하였다. 이들 초기의 직렬 포트 HID들 중 다수는 로우 핀 카운트(Low Pin Count; LPC) 버스를 통해 호스트 디바이스의 프로세서와 통신하였다. LPC 버스의 지원은 전형적으로 호스트 디바이스 프로세서의 전용 핀들에 의해 호스트 디바이스에 구현된다. 다른 버스 프로토콜들이 호스트 디바이스의 하드웨어-레벨에서 유사하게 구현될 수 있다. 호스트 디바이스 제조자들은 하드웨어 레벨에서 어느 버스-프로토콜들을 지원할지를 선택하며, 이것이 호스트 디바이스가 소정 주변 디바이스들과 호환 가능할지를 결정한다(dictate).

새로운 유형들의 주변 HID들이 시장에 진입함에 따라, 주변장치들에 의해 사용된 LPC 버스 직렬 인터페이스는 새로운 주변 디바이스 인터페이스들로 대체되었다(gave way to). 하지만, 결과로서 생기는, 주변 HID들에 의해 사용된 독점 인터페이스들의 수의 증가로 인해, 호스트 디바이스 제조자들이 지원을 유지할 수 없게 되었다. 이러한 곤경에 광범위하게 응답하여, 하드웨어와 소프트웨어 제조자들의 컨소시엄은 호스트 디바이스와 통신하도록 주변 디바이스들에 표준화된 인터페이스를 제공하는 범용 직렬 버스(USB)를 개발하였다. USB는 산업 전반에 걸쳐 빠르게 채택되었고, 또한 주변 HID들의 확산을 촉진하였다.

USB의 인기에도 불구하고, 주변 디바이스들에 의해 사용된 하드웨어 인터페이스들과 버스 프로토콜들은 진화를 계속하였다. 새로운 인터페이스들이 계속 도입되고 있으며, 기존 인터페이스들은 새로운 클래스의 주변장치들에 의한 사용을 위해 개조된다. 일부 경우들에서는 소프트웨어 업데이트들만이 새로운 인터페이스를 지원하는데 필요하다. 예를 들면, 주변 디바이스 통신들을 추가로 표준화하기 위한 노력은, 결과적으로 새로운 주변 디바이스 인터페이스들을 가져왔다. HID-USB 프로토콜은 USB 프로토콜을 사용하여 HID 통신들을 표준화한다. HID-I2C 프로토콜은 I2C 프로토콜을 사용하여 HID 통신들을 유사하게 표준화한다. 호스트 디바이스가 USB 및 I2C 버스 프로토콜들에 대한 하드웨어 지원을 포함하는 한, 호스트 디바이스는 호스트 디바이스의 소프트웨어 계층에 대한 업데이트들을 통해 HID-USB 또는 HID-I2C 프로토콜들을 이용하는 주변 디바이스들을 지원할 수 있다.

다른 경우들에서, 새로운 주변기기 인터페이스들은 호스트 디바이스에 의한 하드웨어 지원을 필요로 할 것이다. 예를 들면, 센서들이 계속 주변 디바이스들의 구성요소들로서 채택됨으로 인해, (I2C와 같은) 새로운 인터페이스들이 이 비교적 새로운 클래스의 주변 디바이스들에 의해 사용되고 있다. eSPI는 임베디드 컨트롤러(EC)에 대한 단일 호스트 인터페이스로서 LPC를 대신하는 새로운 인터페이스이다. 다른 버스 프로토콜들과 마찬가지로, eSPI 버스에 대한 지원은 eSPI 버스 프로토콜을 구현하는데 필요한 소프트웨어를 포함하는 것 이외에 이 eSPI 버스를 구현하기 위해 호스트 디바이스의 프로세서 핀들을 전용화함으로써 이상적으로 구현된다.

호스트 디바이스 제조자들은 새로운 클래스의 주변 디바이스들에 의해 사용되는 새로운 버스 프로토콜들에 대한 하드웨어 지원을 포함시킬 것인지의 여부를 결정하는데 미래 지향성(forward-looking)을 유지해야 한다. 기존(legacy) 주변 디바이스들은 호스트 디바이스 제조자들에게 유사한 압력을 가한다. 인기있는 주변 디바이스들에 대한 지원을 계속 제공하기 위한 필요성으로 인해, 종종 호스트 디바이스 제조자들은 기존 하드웨어 인터페이스들을 계속 지원해야 한다. 따라서, 호스트 디바이스 제조자들은 기존 버스 프로토콜들에 대한 지원을 여전히 유지하면서, 새로운 주변 디바이스들에 의해 사용되는 신흥의(emerging) 버스 프로토콜들에 대한 지원을 포함시켜야 하는 압박에 직면한다. 게다가, 호스트 디바이스 제조자들은 기존 버스 프로토콜들에 업데이트들을 원활하게(seamlessly) 지원하도록 변경될(remain adaptable) 수 있어야 한다. 호스트 디바이스에 의해 사용될 수 있는 소프트웨어 인터페이스들에 대한 업데이트들은, 하드웨어-레벨 인터페이스들에 대한 업데이트들과 비교하면 상대적으로 용이하게 이루어진다. 예를 들면, 새로운 주변 디바이스 기능을 지원하기 위해 클래스 디바이스 드라이버를 업데이트하는 것이, eSPI와 같은 새로운 버스 프로토콜에 대한 지원을 추가하는 것에 비해(versus) 호스트 디바이스가 지원하기에 상대적으로 용이하다. 따라서, 새로운 버스 프로토콜들을 지원하기 위해서는 기존 버스 프로토콜 하드웨어를 사용할 수 있는 호스트 디바이스가 필요하다. 그렇지 않으면 호스트 디바이스에 의한 추가 하드웨어 지원을 필요로 하게 된다.

모든 인기있는 주변 디바이스 인터페이스들에 대한 지원을 제공하는 호스트 디바이스들에 대한 부담을 완화하기 위해서, 주변 디바이스들과 이들의 관련 소프트웨어를 이들 각각의 고유한 통신 프로토콜들을 사용하여 계속 동작시킬 수 있는 동안 내내, 호스트가 단일 프로토콜만을 이용하면서 주변 디바이스와 통신할 수 있는 메커니즘이 필요하다. 새로운 주변 디바이스 프로토콜들에 대한 지원을 추가하도록 구성될 수 있는 이 메커니즘이 또한 필요하다.

실시예들에 따르면, 호스트와 복수의 주변 디바이스들 간에 통신하기 위한 시스템이 제공된다. 상기 호스트는 복수의 클래스 드라이버들과 미니포트 드라이버들을 포함한다. 상기 클래스 드라이버들의 각각은 상기 복수의 주변 디바이스들 중 하나 이상과 연관된 기능을 구현한다. 각각의 미니포트 드라이버는 인터페이스를 제공하고, 상기 인터페이스에 의해 상기 클래스 드라이버들 중 하나 이상이 클래스 프로토콜들을 이용하여 상기 복수의 주변 디바이스들 중 하나 이상과 통신하고, 여기서 상기 미니포트 드라이버들은 상기 호스트에 의해 지원되는 단일 호스트 인터페이스를 통해 통신한다. 임베디드 컨트롤러는 상기 주변 디바이스들의 각각의 고유 버스 프로토콜들을 이용하여 상기 복수의 주변 디바이스들과 인터페이스하고, 여기서 상기 임베디드 컨트롤러는 상기 단일 호스트 인터페이스를 이용하여 상기 복수의 미니포트 드라이버들과 인터페이스한다.

또 하나의 실시예는 상기 호스트 상의 버스 컨트롤러 드라이버; 및 상기 호스트 상의 버스 컨트롤러를 포함하고, 여기서 상기 버스 컨트롤러 드라이버는 상기 단일 호스트 인터페이스의 제 1 부분을 구현하고, 상기 버스 컨트롤러 드라이버는 상기 복수의 주변 디바이스들 중 상기 하나 이상의 상기 각각의 고유 버스 프로토콜들의 선택된 서브세트(a selective subset)를 이용하여 상기 미니포트 드라이버들과 인터페이스하고, 상기 버스 컨트롤러는 상기 단일 호스트 인터페이스의 제 2 부분을 구현하고, 상기 버스 컨트롤러는 상기 단일 호스트 인터페이스를 이용하여 상기 임베디드 컨트롤러와 인터페이스한다. 또 하나의 실시예에서, 상기 버스 컨트롤러 드라이버에 의해 구현된 상기 단일 호스트 인터페이스의 제 1 부분은 상기 단일 호스트 인터페이스를 이용하여 통신하는데 필요한 버스 관리 프로세스들을 구현한다. 또 하나의 실시예에서, 상기 버스 컨트롤러에 의해 구현된 상기 단일 호스트 인터페이스의 제 2 부분은 상기 단일 호스트 인터페이스를 이용하여 통신하는데 필요한 버스 트랜잭션들을 구현한다. 또 하나의 실시예에서, 상기 임베디드 컨트롤러는, 상기 단일 호스트 인터페이스를 구현하고 그리고 상기 버스 컨트롤러와 통신하기 위해 상기 단일 호스트 인터페이스를 이용하는 펌웨어를 포함한다. 또 하나의 실시예에서, 상기 복수의 주변 디바이스들과 상호 동작하도록 상기 호스트에 의해 사용된 정보는 상기 단일 호스트 인터페이스를 이용하여 상기 호스트와 상기 임베디드 컨트롤러 사이에 통신되고, 그리고 여기서 상기 복수의 주변 디바이스들과 상호 동작하도록 상기 호스트에 의해 사용된 상기 정보는 상기 복수의 주변 디바이스들의 상기 각각의 고유 버스 프로토콜들을 이용하여 상기 임베디드 컨트롤러와 상기 복수의 주변 디바이스들 사이에 통신된다. 또 하나의 실시예에서, 상기 단일 호스트 인터페이스는 eSPI(향상된 직렬 주변기기 인터페이스), LPC, 직렬 인터페이스, I2C 인터페이스, USB 인터페이스, SPI 인터페이스, 및 CAN 인터페이스로 이루어진 그룹으로부터 선택된 인터페이스이다.

본 발명은 첨부 도면들을 참조하면 보다 잘 이해될 수 있고, 본 발명의 다양한 목적들, 특징들 및 이점들은 본 기술 분야의 당업자에게 명백할 것이다. 서로 다른 도면들에서 동일한 참조 부호의 사용은 유사하거나 동일한 항목을 가리킨다.
도 1은 한 세트의 주변 디바이스들과의 통신들을 지원하기 위해 종래의 호스트 디바이스에 의해 사용된 소프트웨어 인터페이스들의 계층 세트를 나타낸 블록도이다.
도 2는 한 세트의 주변 디바이스들과의 통신들을 지원하기 위한 호스트 디바이스의 일 실시예에 의해 사용된 소프트웨어 인터페이스들의 계층 세트를 나타낸 블록도이다.
도 3은 단일 호스트 인터페이스를 통한 I2C HID들과의 통신들을 지원하는 실시예에 의해 사용된 소프트웨어 및 펌웨어 계층을 도시한 도면이다.

호스트 디바이스를 사용하는 주변 디바이스의 동작은 주변 디바이스가 호스트 디바이스에 의해 제공된 소프트웨어 및 하드웨어 인터페이스들과의 호환성을 확보하는 것을 필요로 한다. 많은 경우들에서, 하드웨어 호환성을 결정하는 것은 호스트 디바이스가 새로운 주변 디바이스가 필요로 하는 하드웨어 버스의 유형을 지원하는지 여부를 확인하는 일일 뿐이다. 많은 경우들에서, 하드웨어 호환성은 호스트 디바이스와 주변 디바이스가 설계 및 제조될 때 결정된다. 일부 경우들에서, 호스트 디바이스는 새로운 주변 디바이스들을 지원하기 위해 범용 하드웨어를 재구성함으로써 수정될 수 있다. 주변 디바이스가 호스트 디바이스에 의해 제공된 하드웨어 인터페이스와 호환성이 있다고 결정되면, 소프트웨어 호환성이 확인될 수 있다.

소프트웨어 관점에서 호환성은 호스트 디바이스가 주변 디바이스를 동작시키는데 필요한 소프트웨어를 실행하는 것을 필요로 한다. 설명한 바와 같이, 대부분의 호스트 디바이스 시스템들은 전형적으로 인터페이스들의 계층 레이어들(stacked layers)로 이 소프트웨어를 구성한다. 각각의 레이어는 호스트 디바이스와 호환 가능 주변 디바이스들 사이에 지원 통신 경로들을 구현하는데 사용되는 전문화된 서비스들의 세트를 제공한다. 새로운 주변 디바이스들을 지원하는 것은 올바른 소프트웨어 인터페이스들이 계층의 각 레이어에서 사용 가능한지 확인하는 것을 필요로 한다. 일부 경우들에서, 호스트 디바이스에 의해 이미 사용되고 있는 기존 라이브러리들은 새로운 주변 디바이스를 지원하는데 적합하다. 다른 경우들에서는 계층의 하나 이상의 레벨들의 업데이트 소프트웨어 프로그램들이 필요하다.

종래의 시스템들에서, 계층의 최고 레이어는 응용 소프트웨어 프로그램들로 이루어진다. 이 디바이스-특정 프로그램들은 사용자-인터페이스를 포함할 수 있는 인터페이스를 제공하고, 주변 디바이스에 의해 제공된 특징 및 기능은 상기 인터페이스에 의해 동작된다. 응용 소프트웨어에 의해 제공된 특징들을 구현하는 저-레벨 명령어들을 구현하는 디바이스 드라이버 프로그램들은 응용 소프트웨어 아래의 레이어에서 동작한다. 대부분의 시스템들은 특정 유형의 다양한 주변 프로그램들을 동작시키는데 사용될 수 있는 드라이버 프로그램들의 표준화된 라이브러리들을 제공하는 클래스 디바이스 드라이버 프로그램들에 의존한다. 예를 들면, HID 클래스 USB 드라이버는 USB 프로토콜을 이용하여 HID들과 상호 동작하기 위한 공통 기능부를 포함할 것이다. 유사한 HID 클래스 I2C 드라이버는 I2C 프로토콜을 이용하여 동일한 공통 HID 기능을 구현할 수 있다. 주변 디바이스의 소정 디바이스-특정 기능들은 클래스 드라이버들에 의해 지원되지 않을 수 있다. 이 시나리오들은 디바이스-특정 기능을 수행하기 위해 미니클래스 드라이버 프로그램들이 또한 설치되는 것을 필요로 할 수 있다. 미니클래스 드라이버는 클래스 드라이버와 상호 동작하도록 구성되고, 그리고 미니클래스 드라이버는 디바이스-특정 기능을 제공하고 클래스 드라이버는 일반 기능을 제공한다.

클래스 드라이버들 아래에는 통신 프로토콜들을 구현하는 소프트웨어 프로그램들이 있으며, 상기 통신 프로토콜들에 의해 호스트 디바이스는 주변 디바이스와 통신한다. 이러한 보다 낮은 레벨의 레이어들은 버스 프로토콜 드라이버들과 버스 컨트롤러 프로그램들을 포함한다. 각각의 버스 프로토콜 드라이버는 USB 및 I2C와 같은 특정 버스 프로토콜을 통해 주변 디바이스와 통신하기 위한 명령어들을 구현한다. 버스 컨트롤러는 지원 하드웨어 버스들 중 하나의 버스를 따라 실제로 데이터를 송신하기 위한 명령어들을 구현한다. 동시에, 이들 2개의 레이어들은 호스트 디바이스와 주변 디바이스들 사이에 정보를 송신하는데 이용되는 버스 프로토콜들을 구현한다. 종래의 시스템들에서, 호스트 디바이스는 버스 프로토콜을 지원하여 하드웨어 구현을 제공해야 한다. 일부 경우들에서, 이 프로토콜들은 프로토콜에 의해 사용된 버스를 호스트 디바이스 프로세서와 인터페이스하기 위해 전용 핀들을 사용하여 구현된다. 이 버스 프로토콜 구현들이 종종 하드웨어에 의존하기 때문에, 새로운 버스 프로토콜들은 호스트 디바이스에 의해 용이하게 지원될 수 없다.

도 1은 한 세트의 주변 디바이스들(110a-f)과의 통신들을 지원하기 위해 종래의 호스트 디바이스(100)에 사용된 계층 인터페이스들의 전형적인 시스템을 도시한다. 종래의 시스템에서, 잘 팔리는 다양한 주변 디바이스들의 지원은 호스트 디바이스(100)에 상당한 부담을 준다. 호스트 디바이스(100)는 잘 팔리는 다양한 주변 디바이스들과의 강력한 호환성을 제공하기 위해 하드웨어 및 소프트웨어 인터페이스들의 다양한 세트를 지원하도록 설계 및 제조되어야 한다. 설명한 바와 같이, 이 호환성은 호스트 디바이스(100)의 기능들이 주변 시장의 새로운 기술의 채택에 응답하여 업데이트될 수 있도록 미래 지향적(forward-looking)이어야 한다. 상기 호환성은 또한 호스트 디바이스(100)가 인기있는 기존 디바이스들에 대한 지원을 계속 제공하기 위해 과거 지향적이어야 한다.

도 1의 종래 시스템의 최상 레이어에서, 응용 소프트웨어(115a-f)는 주변 디바이스들(110a-f)에 의해 제공된 특징부와 기능부에 인터페이스를 제공한다. 일부 경우들에서, 응용 소프트웨어(115a-f)는 인터페이스를 제공할 수 있는데, 이 인터페이스에 의해 호스트 디바이스(100)는 사용자로 하여금 주변 디바이스들(110a-f)과 상호작용할 수 있게 한다. 다른 경우들에서는, 응용 소프트웨어(115a-f)가 소프트웨어 인터페이스만을 제공할 수 있다. 응용 소프트웨어(115a-f)를 주변 디바이스들(110a-f)에 링크하기 위해 도 1에 도시된 나머지 계층 레이어들이 호스트 디바이스(100)에 의해 사용된다.

도 1의 종래 시스템에 도시된 계층 레이어들에 의해, 호스트 디바이스(100)는 광범위한 통신 프로토콜들을 통해 주변 디바이스들과의 통신들을 지원할 수 있다. 터치스크린 HID(115e)를 지원하는 터치스크린 소프트웨어는 호스트 디바이스의 CPU에서 실행되며, I2C를 통해 주변 터치스크린 HID(110b)와 통신한다. 키보드(115d)의 특징들을 구현하기 위한 소프트웨어는 주변 USB 키보드(110e)로부터 입력들을 수신한다. 호스트 디바이스(100)는 또한, 직렬 포트 인터페이스를 통해 외부 모니터(110a)와 통신하는 외부 디스플레이 소프트웨어(115a)를 실행한다. 호스트 디바이스(100)는 또한, I2C를 통해 외부 배터리(110c)와 인터페이스하는 배터리 모니터 소프트웨어 프로그램(115b)을 실행한다. 호스트 디바이스(100)는 또한, USB 플래시 드라이브(110d)와 인터페이스하는 외부 데이터 저장소(115e)를 지원하는 소프트웨어를 실행한다. 호스트 디바이스(100)는 또한, 직렬 주변기기 인터페이스(SPI)를 통해 주변 비디오 게임패드(110f)와 인터페이스하는 비디오 게임 소프트웨어(115f)를 실행한다.

도 1에 도시된 종래 시스템에서는, 호스트 디바이스(100)가 주변 디바이스들(110a-f)의 각각에 대한 지원을 제공하기 위해, 호스트 디바이스(100)는 또한 클래스 드라이버들(120a-f), 전송 미니드라이버들(135a-b), 버스 프로토콜 드라이버들(125a-d) 및 버스 컨트롤러들(130a-d)과 같은 구성요소들의 레이어들을 사용한다. 이 레이어들의 각각은 주변 디바이스들(110a-f)에 의해 사용되는 저-레벨 통신 프로토콜들의 특징부를 구현한다. 예를 들면, 외부 모니터(110a)와 같은 직렬 포트 주변 디바이스의 지원시, 호스트 디바이스(100)에서 실행되는 외부 디스플레이 소프트웨어(115a)는 외부 디스플레이 소프트웨어(115a)에 고-레벨 직렬 포트 소프트웨어 인터페이스를 제공하는 직렬 포트 클래스 드라이버(120a)와 같은 구성요소를 호출한다(invoke). 이 직렬 포트 클래스 드라이버(120a)는 모니터들에 의해 공통으로 이용되는 직렬 포트 통신 기능들을 구현한다. 직렬 포트 클래스 드라이버(120a)는 이번에는(in turn) 직렬 포트로(via) 직렬 포트 연결 및 데이터의 송신을 관리하기 위해 직렬 포트 드라이버(125a)와 같은 구성요소를 호출한다. 직렬 포트 드라이버(125a)는 직렬 포트 버스 상의 실제 트랜잭션들을 관리하기 위해 직렬 포트 버스 컨트롤러(130a)와 같은 구성요소에 의존하며, 상기 직렬 포트 버스에 의해 데이터가 외부 모니터(110a)로/로부터(to and from) 송신된다.

유사한 방식으로, 도 1의 종래 시스템은 또한 다른 주변기기 인터페이스들에 대한 지원부를 포함한다. I2C 프로토콜을 사용하여 통신하도록 설계된 주변 장치들에 대해, 호스트 디바이스(100)는 호스트 디바이스와 HID 터치스크린(110b) 및 외부 배터리(110c)와 같은 주변 디바이스들 간의 I2C 연결들을 관리하기 위해 I2C 드라이버(125b)와 같은 구성요소에 의존한다. 이 I2C 주변 장치들을 지원하는 것은 추가로 호스트 디바이스(100)가 I2C 버스 상의 데이터 트랜잭션들을 관리하기 위한 I2C 버스 컨트롤러와 같은 구성요소를 포함할 것을 필요로 한다.

호스트 디바이스(100)에서 실행되는 터치 스크린 소프트웨어(115c)는 터치 스크린 소프트웨어(115c)에 고-레벨 HID 클래스 인터페이스를 제공하는 HID 클래스 드라이버(120c)와 같은 구성요소를 호출한다. 이 HID 클래스 드라이버(120c)는 HID 프로토콜 기반 주변 디바이스들에 의해 공통으로 사용되는 HID 프로토콜 통신 기능들을 구현한다. HID 클래스 드라이버(120c)는 이번에는(in turn), I2C 프로토콜을 사용하여 HID 클래스 디바이스들에 의해 이용되는 통신 기능을 구현하는 HID-I2C 전송 미니드라이버(135a)와 같은 구성요소를 호출한다. HID-I2C 전송 미니드라이버(135a)는 이번에는 I2C 버스를 통한 I2C 연결들과 데이터의 송신을 관리하기 위해 I2C 드라이버(125b)를 호출한다.

클래스 드라이버들은 다중 통신 프로토콜들을 사용하여 공통 기능을 구현할 수 있다. 호스트 디바이스(100)는 I2C 드라이버(125b)를 동작시킬 수 있는 다양한 클래스 인터페이스들을 사용한다. 도 1의 시스템에서, 배터리 클래스 드라이버(120b)와 HID 클래스 드라이버(120c)는 I2C 드라이버(125b)를 통해 I2C 프로토콜을 사용할 수 있는 능력을 제공한다. 배터리 클래스 드라이버(120b)는 주변 배터리 디바이스들에 의해 공통으로 이용되는 기능들을 구현한다. HID 클래스 드라이버(120c)는 HID들에 의해 공통으로 사용되는 기능들을 구현하고, HID-I2C와 HID-USB 전송 미니드라이버들(135a-b)을 사용하여 I2C와 USB 통신 프로토콜들을 둘 다 지원한다. 일부 호스트 디바이스들에서는, 2개의 개별 HID 클래스 드라이버들이 사용될 수 있는데, 이들의 각각은 서로 다른 통신 프로토콜을 지원한다.

마찬가지로, 종래의 호스트 디바이스(100)는 USB 플래시 드라이브(110d) 및 USB 키보드(110e)와 같은 USB-인에이블 주변 디바이스들과의 연결들을 관리하기 위해 USB 드라이버(125c)와 같은 구성요소를 포함한다. USB 드라이버(125c)는, USB 프로토콜을 이용하여 HID 클래스 디바이스들에 의해 사용되는 통신 기능들을 구현하는 HID-USB 전송 미니드라이버(135b)에 의존한다. 이 USB 주변 장치들을 지원하는 것은 추가로 호스트 디바이스(100)가 USB 버스 상의 트랜잭션들을 관리하기 위한 USB 버스 컨트롤러(130c)와 같은 구성요소를 포함할 것을 필요로 한다. 호스트 디바이스(100)는 USB 드라이버(125c)를 동작시키기 위해 다양한 클래스 드라이버들을 사용하는데, 이 클래스 드라이버들 각각은 서로 다른 유형의 주변 디바이스들에 의해 사용되는 공통의 USB 기능을 구현한다. 저장 클래스 드라이버(120d)는 주변 저장 디바이스들에 의해 사용되는 공통 기능을 구현하고, HID 클래스 드라이버(120c)는 다양한 유형의 HID들에 의해 사용되는 공통 기능을 구현한다.

종래의 호스트 디바이스(100)는 또한, 비디오 게임패드(110f)와 같은 SPI-인에이블 디바이스들과의 연결들을 관리하기 위해 SPI 드라이버(125d)를 포함한다. 비디오 게임패드(110f)에 대한 지원을 제공하기 위해, 호스트는 고-레벨 SPI 소프트웨어 인터페이스를 제공하는 SPI 클래스 드라이버(120a)와 같은 구성요소를 호출하는 게임패드 소프트웨어(115f)를 실행한다. SPI 클래스 드라이버(120a)는 주변 게임 패드 디바이스들에 의해 사용되는 공통의 SPI 기능을 구현한다. SPI 클래스 드라이버는 SPI-인에이블 디바이스들과의 연결들을 관리하기 위해 SPI 드라이버(125d)와 같은 구성요소에 의존한다. SPI 드라이버(125d)는 SPI 버스 상의 실제 트랜잭션들을 관리하기 위해 SPI 버스 컨트롤러(130d)와 같은 구성요소에 의존한다.

위에 설명한 바와 같이, 이상적인 호스트 디바이스는 인기있는 현재 및 기존 프로토콜들을 둘 다 지원할 수 있고, 또한 미래의 프로토콜들을 포함하도록 변경될 수 있게 유지할 수 있다. 호스트 디바이스에 의해 지원되는 주변 디바이스들의 수가 증가함에 따라, 주변 디바이스들을 지원하는데 사용되는 인터페이스들의 계층 레이어들의 복잡도도 증가한다. 이 계층 레이어들의 복잡도가 증가함에 따라, 계층의 구성요소들에 대한 업데이트들을 효과적으로 관리하는 것은 상기 계층 레이어들 내에서 나타나는(develop) 많은 상호 의존성들로 인해 점점 더 어려워진다. 이러한 요구에 대처하기 위해, 본 발명의 실시예들은 단일 인터페이스를 통해 서로 다른 통신 프로토콜들을 이용하는 광범위한 주변 디바이스들과 인터페이스할 수 있는 능력을 호스트 디바이스에 제공한다.

다양한 실시예들 중 하나가 도 2에 도시되어 있다. 도 2의 실시예에 따르면, 도 1에 대하여 설명된 주변 디바이스들의 각각은 단일 호스트 인터페이스(260)를 통해 호스트 디바이스(200)에 연결된다. 호스트 디바이스(200)는 주변 디바이스들(210a-f)의 각각과 인터페이스하기 위해 임베디드 컨트롤러(EC)(215)에 의존한다. 임베디드 컨트롤러(215)는 각각의 주변 디바이스(210a-f)의 고유 인터페이스를 통해 상기 주변 디바이스들(210a-f)의 각각과 인터페이스하도록 그리고 단일 호스트 인터페이스(260)를 통해 호스트 디바이스(200)와 인터페이스하도록 구성된다. 이 구성에 따라, 주변 디바이스들(210a-f)의 각각과의 버스-레벨 트랜잭션들은 호스트 디바이스(200) 대신 임베디드 컨트롤러(215)에 의해 관리된다. 모든 버스-레벨 트랜잭션들이 호스트 디바이스(200)와 임베디드 컨트롤러(215) 사이의 인터페이스를 통해 집중된(funneled) 상태에서, 호스트 디바이스는 주변 디바이스들(210a-f)을 지원하기 위해 임의의 다른 하드웨어 인터페이스들을 지원할 필요가 없다. 도 2의 실시예에서, 단일 호스트 인터페이스(260)는 LPC 하드웨어 인터페이스를 이용하여 구현된다. 다른 실시예는 다른 하드웨어 인터페이스들을 단일 호스트 인터페이스로(260)서 이용할 수 있다. 예를 들면, 다른 실시예들은 eSPI(향상된 직렬 주변기기 인터페이스 버스), I2C 또는 PCI 하드웨어 인터페이스를 이용하여 단일 호스트 인터페이스를 구현할 수 있다. 일부 실시예들은 단일 호스트 인터페이스로 이용되는 하드웨어 인터페이스를 구성할 수 있는 기능을 제공할 수 있다.

단일 호스트 인터페이스(260)로 이용되는 하드웨어 인터페이스와는 상관없이, 이 선택은 주변 디바이스들(210a-f)에 바로 알려진다. 주변 디바이스들(210a-f)의 각각은 종래의 시스템과 동일한 고유 버스 인터페이스를 이용하여 호스트 디바이스(200)와 통신한다. 예를 들면, 외부 모니터(210a)는 종래의 시스템에서 사용된 동일한 직렬 포트 인터페이스를 이용하여 호스트 디바이스와 여전히 통신한다. 하지만, 호스트 디바이스의 프로세서에 의해 제공된 하드웨어 인터페이스와 직접 인터페이스하는 대신에, 주변 디바이스들(210a-f)은 임베디드 컨트롤러(215)에 의해 제공된 하드웨어 인터페이스와 인터페이스한다. 주변 디바이스들(210a-f)의 각각과 연관된 응용 소프트웨어 프로그램들(205a-f)도 또한 임베디드 컨트롤러(215)에 의한 단일 호스트 인터페이스(260)의 사용에 영향을 받지 않는다. 각각의 응용 소프트웨어 프로그램(205a-f)은 동일한 클래스 드라이버들(220a-c)과, 도 1의 종래 시스템에 사용된 임의의 미니클래스 드라이버들을 사용하여 자신의 해당 주변 디바이스(210a-f)와 통신한다. 결과적으로, 주변 디바이스들(210a-f)에 의해 제공된 기능은 주변 디바이스들(210a-f)과의 저-레벨 버스 트랜잭션들을 브리징(bridging)하는 중간 역할을 하는 임베디드 컨트롤러(215)에 의한 영향을 받지 않는다.

도 1의 종래 시스템에서는, 버스 프로토콜 드라이버들(125a-d)과 버스 컨트롤러들(130a-b)과 같은 소프트웨어 구성요소들을 이용하는 통신 프로토콜들이 구현된다. 버스 프로토콜 드라이버들(125a-d)의 각각은 호스트 디바이스(100)에 의해 지원되는 하드웨어 버스 프로토콜들 중 하나에 대응하는 소프트웨어 인터페이스를 구현한다. 예를 들면, 호스트 디바이스(100)는 소프트웨어 인터페이스를 제공하는 I2C 드라이버(125b)를 실행하며, 상기 소프트웨어 인터페이스에 의해 호스트 디바이스(100)는 외부 배터리(110c) 및 터치스크린(110b)과 같은 I2C 디바이스들과 통신한다. 이 버스 프로토콜 드라이버들(125a-d)은 I2C 주변 디바이스들과 통신하기 위해 호스트 디바이스(100)에 의해 호출되는 I2C 명령어들을 구현한다.

도 1의 종래 시스템의 하드웨어 버스 컨트롤러들(130a-b)은 주변 디바이스들의 지원된 고유 버스 프로토콜에 따라 주변 디바이스들과 통신하는데 필요한 개개의 버스-레벨 트랜잭션들을 구현하기 위해 호스트 디바이스(100)에 의해 사용되는 소프트웨어 프로그램들이다. 이들 버스 컨트롤러 프로그램들은 호스트 디바이스에 의해 지원되는 개개의 버스들 상에 데이터를 실제로 송신하기 위한 명령어들을 제공한다. 버스 컨트롤러 프로그램들은 그 특정 프로토콜을 이용하는 모든 디바이스들에 의해 사용된 버스 트랜잭션들을 구현한다. 예를 들면, I2C 버스 컨트롤러(130b)는 물리적 I2C 버스 상에 데이터를 송신하는데 사용된 저-레벨 소프트웨어를 구현하고, I2C를 통해 호스트 디바이스(100)와 통신하는 모든 주변 디바이스들 대신에 I2C 버스에 대한 액세스를 중재한다(mediate). 도 1의 종래 시스템에서, HID 터치스크린(110b)과 배터리 디바이스(110c) 둘 다는 I2C 버스 컨트롤러(130b)를 통해 호스트 디바이스(100)와 통신한다.

새로운 주변 디바이스가 종래 시스템의 호스트 디바이스(100)에 의해 동작될 수 있는지 여부를 결정하기 위해서는, 상기 새로운 주변 디바이스를 동작시키는데 필요한 소프트웨어 프로그램들의 모두가 설치되고 호스트 디바이스(100)에 액세스 가능함을 확보하는 것이 필요하다. 예를 들면, 개인용 컴퓨터에 의한 사용 용도의 USB 키보드(110e)를 설치할 때에는, 호스트 디바이스(100)에 의해 키보드를 동작시키는데 필요한 모든 소프트웨어가 개인용 컴퓨터에 설치되어야 한다. 키보드의 특징들을 제공하는 디바이스-특정 응용 소프트웨어(115d)가 설치되어야 한다. 키보드 디바이스들을 동작시키기 위한 적절한 클래스 드라이버(120c)가 개인용 컴퓨터의 클래스 드라이버 라이브러리들 내에서 식별되거나, 또는 다른 방법으로 설치되어야 한다. USB 프로토콜을 구현하는 소프트웨어 프로그램들도 또한 설치 혹은 식별되어야 한다. 키보드를 동작시키는데 필요한 USB 통신들을 구현하는 디바이스-특정 USB 드라이버(125c)가 설치되어야 한다. 클래스 드라이버(120c)와 디바이스-특정 USB 드라이버를 인터페이스하기 위한 전송 미니드라이버(135b)도 또한 설치 혹은 식별되어야 한다. 그리고, 범용 USB 버스 컨트롤러(130c)가 식별되어야 하거나 아니면 설치되어야 한다.

도 2의 실시예에서는, 도 1의 종래 시스템에서와 동일한 응용 소프트웨어(205a-f)와 클래스 드라이버들(220a-e)이 사용된다. 따라서, 종래의 시스템을 실시예로 전환하는데 필요한 수정들이 응용 소프트웨어(205a-f)와 클래스 드라이버들(220a-e)에 바로 드러난다(transparent). 주변 디바이스들(210a-f)도 또한 변하지 않는다. 주변 디바이스들(210a-f)과 호스트 디바이스(200)에서 실행되는 응용 소프트웨어(205a-f) 및 클래스 드라이버들(220a-e)의 관점에서는, 이 구성요소들 사이에 통신하는데 사용되고 있는 고유 인터페이스가 종래의 호스트 디바이스로부터 변경되지 않기 때문에 어떠한 변경들도 명백하지 않다. 예를 들면, USB HID 키보드(210e) 및 해당 응용 소프트웨어(205d)와 클래스 드라이버(220c)는 이들 사이에 통신하기 위해 여전히 USB 프로토콜을 호출한다. 하지만, 도 1의 종래 시스템에 있는 전송 미니드라이버들(135a-b), 디바이스-특정 버스 프로토콜 드라이버들(125a-d) 및 버스 컨트롤러들(130a-d)보다는 오히려 실시예들은 단일 호스트 인터페이스를 구현하기 위해 미니포트 드라이버들(240a-d)과 단일 컨트롤러 드라이버(245) 및 단일 버스 컨트롤러(250)를 대신 사용하고, 상기 단일 호스트 인터페이스에 의해 모든 주변 디바이스들은 호스트 디바이스(200)와 통신할 것이다.

실시예들에 따르면, 미니포트 드라이버들(240a-d)과 같은 구성요소들은 클래스 드라이버들(220a-e)과 결합하여 사용된다. 미니포트 드라이버들(240a-d)은 클래스 드라이버들(220a-e)에 의해 이용되는 통신을 구현한다. 미니포트 드라이버들(240a-d)은 디바이스들의 클래스에 의해 이용되는 통신 기능들을 구현하고, 컨트롤러 드라이버(245)에 의해 제공된 버스-레벨 통신 기능들과 상호 동작하도록 구성된다. 예를 들면, 도 2의 실시예에서, HID 미니포트 드라이버(240)는 HID 클래스 디바이스들에 의해 사용되는 통신들을 구현하고, 그리고 컨트롤러 드라이버(245)와 컨트롤러(250)에 의해 구현된 버스 통신 프로토콜을 이용하여 이 통신들을 임베디드 컨트롤러(215)에 포워딩하도록 구성된다. 컨트롤러(250)에 의해 수신된 통신들은 이후에 단일 호스트 인터페이스(260)의 프로토콜로부터 주변 디바이스들(210a-f)에 의해 사용되는 고유 프로토콜로 변환된다(translated). 주변 디바이스들(210a-f)에서 발신하여 응용 소프트웨어(205a-f)로 흐르는 통신들을 위한 이 구성요소들에 의해 유사한 변환들이 이루어진다. 이 방식으로, 미니포트 드라이버들(240a-d)은 호스트 디바이스(200) 상에서 HID-프로토콜과 같은 클래스 특정 프로토콜과, 호스트 디바이스(200)에 의해 구현되는 단일 버스 프로토콜을 통해 주변 디바이스들에 의해 이용된 고유 버스 프로토콜 사이에 브리지로서 기능한다.

도 1의 종래 호스트 디바이스의 버스 프로토콜 드라이버들(125a-d)과 버스 컨트롤러들(130a-d)과 유사하게, 컨트롤러 드라이버(245)와 컨트롤러(250)는 호스트 디바이스(200)에 대한 버스 통신들을 구현한다. 하지만, 호스트 디바이스(200)의 설계자들에 의해 필요하다고 여겨지는 모든 버스 프로토콜들을 구현하기보다는 오히려, 컨트롤러 드라이버(245)와 컨트롤러(250)는 단일 버스 프로토콜을 구현한다. 도 2의 실시예에서, 이 단일 버스 프로토콜은 LPC이지만, 호스트 디바이스(200)와 임베디드 컨트롤러(215)에 의해 지원될 수 있는 임의의 다른 통신 프로토콜일 수도 있다. 실제 구현되는 버스 프로토콜과는 상관없이, 모든 주변 장치들과 통신하기 위해 단일 호스트 인터페이스(260)에 의존할 수 있는 호스트 디바이스(200)의 기능은, 호스트 디바이스(200)가 단일 호스트 인터페이스(260)에 의해 이용된 단일 버스 프로토콜에 대한 하드웨어 지원만을 구현하기를 필요로 함을 의미한다. 일부 실시예들에서는 이 단일 호스트 인터페이스가 구성될 수 있다. 이러한 실시예들은 호스트 디바이스에 의해 지원될 그 세트의 주변 디바이스들에 의해 필요한 대량의(the universe of) 버스 프로토콜들보다는 오히려 한정된 수의 버스 프로토콜만을 지원해야 함으로 여전히 이익을 얻는다.

실시예들은 또한, 주변 장치들과 호스트 디바이스 프로세서 간의 버스 통신의 전체 제어를 유지함으로 이익을 얻는다. 일부 버스 프로토콜들은 버스를 이용하는 구성요소들에 의한 적절한 버스 마스터링(mastering)을 필요로 한다. 주변 장치에 의해 필요한 버스 프로토콜이 호스트 디바이스에 의해 지원되더라도, 버스 마스터링과 같은 버스 통신들의 저레벨 양상들에서의 차이들은 결과적으로 이 통신 링크의 오류 조건 및/또는 비효율적인 동작을 일으킬 수 있다. 종래 시스템의 버스 컨트롤러들(130a-d)과 버스 프로토콜 드라이버들(125a-d)이 다양한 주변 장치들과 잠재적으로 직접 인터페이스하기 때문에, 이 구성요소들에 대한 업데이트는 이전과의 호환성(backwards compatibility)이 유지됨을 확인해야 한다. 따라서, 새로운 주변 디바이스를 수용하기 위해 이루어지는 이 버스 프로토콜 레이어들의 소프트웨어에 대한 업데이트들은 효과적으로 구현되기가 어려울 수 있다. 결과적으로, 호스트 디바이스는 단지 임베디드 컨트롤러와의 버스 통신들을 지원해야 함에 의해 이익을 얻는데, 상기 임베디드 컨트롤러는 서로 다른 주변 디바이스들에 의해 이용될 수 있는 저 레벨 버스 프로토콜 구현에 생기는 임의의 이러한 부적합을 수용하기에 더 적합하다.

호스트 디바이스(200)에 의한 단일 호스트 인터페이스(260)의 사용이 주변 디바이스들(210a-f)에 명백하도록 하기 위해, 호스트 디바이스는 주변 디바이스들(210a-f)과의 버스 트랜잭션들을 브리징하도록 임베디드 컨트롤러(215)에 의존한다. 일부 실시예들에서, 임베디드 컨트롤러는 3개의 주요 구성요소들로 이루어진다. 이 구성요소들 중 하나는 단일 호스트 인터페이스(260)를 위해 선택된 버스 프로토콜을 이용하여 버스 트랜잭션들을 구현하는데 사용되는 펌웨어이다. 도 2의 실시예에서, 임베디드 컨트롤러(215)의 펌웨어는 호스트 디바이스(200) 하드웨어에 지원되는 LPC 버스를 사용하여 호스트 디바이스(200)의 프로세서와 통신한다. 펌웨어는 주변 디바이스들(210a-f)과 호스트 디바이스(200) 사이에 통신들을 송신하지만, 단일 호스트 인터페이스(260)에 의해 사용되는 버스 프로토콜을 이용하여 통신들을 브리징한다.

도 2의 실시예의 임베디드 컨트롤러(215)는 추가로 슈퍼(super) I/O 구성요소로 이루어진다. 이 슈퍼 I/O 구성요소는 디바이스 고유 인터페이스 펌웨어에 의해 사용되는 고유 버스 프로토콜 통신들과 단일 호스트 인터페이스(260)에 의해 사용되는 버스 프로토콜 간에 변환한다(translate). 슈퍼 I/O 구성요소는 호스트와 주변 디바이스 간에 송신되는 실제 정보를 처리할 필요가 없으며, 대신 이 통신들을 송신하는데 이용되는 프로토콜을 변환하기만을 필요로 한다. 일부 실시예들에서, 임베디드 컨트롤러(215)의 슈퍼 I/O 구성요소는 호스트 디바이스(200)의 프로세서에 의해 지원되는 메모리/메일박스 인터페이스를 이용하여 호스트 디바이스(200)와 통신한다.

도 2의 실시예의 임베디드 컨트롤러(215)는 추가로 디바이스 고유 인터페이스 펌웨어로 구성된다. 디바이스 고유 인터페이스 펌웨어는 통신들 고유의 버스 프로토콜에 따라 주변 디바이스들(210a-f)과의 통신들을 구현한다. 이 펌웨어는 호스트 디바이스(200) 대신 지원되는 버스 프로토콜들의 각각에 대한 버스 트랜잭션들을 구현한다. 새로운 버스 프로토콜들은 호스트 디바이스(200)에 영향을 주지 않으면서 이 펌웨어를 업데이트함으로써 지원될 수 있고, 따라서 호스트 디바이스(200)의 하드웨어 인터페이스에 대한 업데이트를 필요로 하지 않는다. 일부 실시예들에서, 임베디드 컨트롤러(215)의 디바이스 고유 인터페이스 펌웨어는 주변 디바이스(210a-f)에 의해 사용된 고유 버스 프로토콜들 내의 버스 트랜잭션들을 지원하도록 구성된 한 세트의 일반 및 디바이스-특정 클래스 드라이버들을 구현할 수 있다.

도 3은, LPC를 단일 호스트 인터페이스로 이용하는 I2C를 사용하는 HID 디바이스들과의 통신들을 지원하는 실시예에서의 소프트웨어 및 펌웨어 계층을 도시한다. 도 3의 실시예에서, 호스트 디바이스(300)는 호스트에 의한 사용 용도의 HID 기능을 구현하는 HID 클래스 드라이버(315)를 실행한다. 일부 실시예들에서, HID 클래스 드라이버(315)는 사용자가 지원 HID 주변 디바이스들(340 및 345)과 상호작용할 수 있게 하는 기능을 구현할 것이다. 다른 실시예들에서, HID 클래스 드라이버(315)는 지원된 HID 주변 디바이스들(340 및 345)과 상호 동작하도록 호스트(300)에 의해 이용되는 기능만을 구현할 것이다.

HID 클래스 드라이버(315)는 주변 HID 디바이스들(340 및 345)과 통신하기 위해 HID-EMI 미니포트 드라이버(320)와 인터페이스한다. HID-EMI 미니포트 드라이버(320)는 HID 디바이스들(340 및 345)에 의해 사용되는 클래스 특정 HID 프로토콜을 이용하여 HID 클래스 드라이버와 통신한다. HID-EMI 미니포트 드라이버(320)는 이 HID 프로토콜 통신들을, 호스트 디바이스(300)에 의해 지원되는 단일 호스트 인터페이스로 이용되는 LPC/EMI 버스 프로토콜(310)로 변환한다. HID-EMI 미니포트 드라이버(320)는 호스트 디바이스(300)에 의해 이용되는 단일 호스트 인터페이스로서 사용된 LPC/EMI 버스 프로토콜(310)을 구현하는 LPC/EMI 버스 드라이버(325)와 인터페이스한다.

임베디드 컨트롤러(305)에서, LPC/EMI 프로토콜은 펌웨어(330) 내에 구현된다. 펌웨어 구성요소(330)는 호스트 디바이스(300)의 LPC/EMI 버스 드라이버(325)와 인터페이스함으로써 호스트와 임베디드 컨트롤러 사이에 상기 변환된 주변 디바이스 통신들을 송신한다. 또한, I2C 펌웨어 드라이버(335)는 임베디드 컨트롤러(305)에서 실행되므로, 고유 I2C 버스 프로토콜로 주변 디바이스들(340 및 345)과 인터페이스한다.

전술한 본 명세서는 특정 실시예들을 설명하지만, 여기에 개시된 실시예들의 세부 사항들에서의 수많은 변화들 및 부가적인 실시예들은 이 설명을 참조하는 이 기술분야에 통상의 기술을 가진 사람들에게 명백할 것이고, 또한 이들에 의해 만들어질 수 있다. 이러한 관계에서, 본 명세서 및 도면은 제한적인 의미라기보다는 오히려 예시적인 의미로 간주되어야 하고, 모든 이러한 변경들은 본 개시의 범위 안에 포함된다. 따라서, 본 개시의 범위는 다음의 청구항들 및 이들의 법적인 균등물들에 의해 결정되어야 한다.

Claims

호스트와 복수의 주변 디바이스들 간에 통신하기 위한 시스템으로서,
상기 호스트 상의 복수의 클래스 드라이버들 - 상기 클래스 드라이버들의 각각은 상기 복수의 주변 디바이스들 중 하나 이상과 연관된 기능을 구현함 -;
상기 호스트 상의 복수의 미니포트 드라이버들 - 각각의 미니포트 드라이버는 인터페이스를 제공하고, 상기 인터페이스에 의해 상기 클래스 드라이버들 중 하나 이상이 클래스 프로토콜들을 이용하여 상기 복수의 주변 디바이스들 중 하나 이상과 통신하고, 상기 미니포트 드라이버들은 상기 호스트에 의해 지원되는 단일 호스트 인터페이스를 통해 통신함 -; 및
상기 주변 디바이스들의 각각의 고유 버스 프로토콜들을 이용하여 상기 복수의 주변 디바이스들과 인터페이스하는 임베디드 컨트롤러를 포함하고,
상기 임베디드 컨트롤러는 상기 단일 호스트 인터페이스를 이용하여 상기 복수의 미니포트 드라이버들과 인터페이스하는, 시스템.
제 1 항에 있어서,
상기 호스트 상의 버스 컨트롤러 드라이버; 및
상기 호스트 상의 버스 컨트롤러를 더 포함하고,
상기 버스 컨트롤러 드라이버는 상기 단일 호스트 인터페이스의 제 1 부분을 구현하고, 상기 버스 컨트롤러 드라이버는 상기 복수의 주변 디바이스들 중 상기 하나 이상의 상기 각각의 고유 버스 프로토콜들의 선택된 서브세트(a selective subset)를 이용하여 상기 미니포트 드라이버들과 인터페이스하고,
상기 버스 컨트롤러는 상기 단일 호스트 인터페이스의 제 2 부분을 구현하고, 상기 버스 컨트롤러는 상기 단일 호스트 인터페이스를 이용하여 상기 임베디드 컨트롤러와 인터페이스하는, 시스템.
제 2 항에 있어서,
상기 버스 컨트롤러 드라이버에 의해 구현된 상기 단일 호스트 인터페이스의 제 1 부분은 상기 단일 호스트 인터페이스를 이용하여 통신하는데 필요한 버스 관리 프로세스들을 구현하는, 시스템.
제 2 항에 있어서,
상기 버스 컨트롤러에 의해 구현된 상기 단일 호스트 인터페이스의 제 2 부분은 상기 단일 호스트 인터페이스를 이용하여 통신하는데 필요한 버스 트랜잭션들을 구현하는, 시스템.
제 2 항에 있어서,
상기 임베디드 컨트롤러는, 상기 단일 호스트 인터페이스를 구현하고 그리고 상기 버스 컨트롤러와 통신하기 위해 상기 단일 호스트 인터페이스를 이용하는 펌웨어를 포함하는, 시스템.
제 1 항에 있어서,
상기 복수의 주변 디바이스들과 상호 동작하도록 상기 호스트에 의해 사용된 정보는 상기 단일 호스트 인터페이스를 이용하여 상기 호스트와 상기 임베디드 컨트롤러 사이에 통신되고, 그리고
상기 복수의 주변 디바이스들과 상호 동작하도록 상기 호스트에 의해 사용된 상기 정보는 상기 복수의 주변 디바이스들의 상기 각각의 고유 버스 프로토콜들을 이용하여 상기 임베디드 컨트롤러와 상기 복수의 주변 디바이스들 사이에 통신되는, 시스템.
제 1 항에 있어서,
상기 단일 호스트 인터페이스는 eSPI(향상된 직렬 주변기기 인터페이스), LPC, 직렬 인터페이스, I2C 인터페이스, USB 인터페이스, SPI 인터페이스, 및 CAN 인터페이스로 이루어진 그룹으로부터 선택된 인터페이스인, 시스템.
복수의 주변 디바이스들과 통신하기 위한 디바이스로서,
복수의 클래스 드라이버들 - 상기 클래스 드라이버들의 각각은 상기 복수의 주변 디바이스들 중 하나 이상의 주변 디바이스들과 연관된 기능을 구현함 -;
복수의 미니포트 드라이버들 - 각각의 미니포트 드라이버는 인터페이스를 제공하고, 상기 인터페이스에 의해 상기 클래스 드라이버들 중 하나 이상은 클래스 프로토콜들을 이용하여 상기 하나 이상의 주변 디바이스들과 통신하고, 상기 미니포트 드라이버들은 상기 호스트에 의해 지원되는 단일 호스트 인터페이스를 통해 통신함 -; 및
상기 주변 디바이스들의 각각의 고유 버스 프로토콜들을 이용하여 상기 복수의 주변 디바이스들과 인터페이스하는 임베디드 컨트롤러를 포함하고,
상기 임베디드 컨트롤러는 단일 호스트 인터페이스를 이용하여 상기 복수의 미니포트 드라이버들과 인터페이스하는, 디바이스.
제 8 항에 있어서,
버스 컨트롤러 드라이버 및 버스 컨트롤러를 더 포함하고,
상기 버스 컨트롤러 드라이버는 상기 단일 호스트 인터페이스의 제 1 부분을 구현하고, 상기 버스 컨트롤러 드라이버는 상기 하나 이상의 주변 디바이스들의 상기 각각의 고유 버스 프로토콜들의 선택된 서브세트를 이용하여 상기 미니포트 드라이버들과 인터페이스하고,
상기 버스 컨트롤러는 상기 단일 호스트 인터페이스의 제 2 부분을 구현하고, 상기 버스 컨트롤러는 상기 단일 호스트 인터페이스를 이용하여 상기 임베디드 컨트롤러와 인터페이스하는, 디바이스.
제 9 항에 있어서,
상기 버스 컨트롤러 드라이버에 의해 구현된 상기 단일 호스트 인터페이스의 제 1 부분은 상기 단일 호스트 인터페이스를 이용하여 통신하는데 필요한 버스 관리 프로세스들을 구현하는, 디바이스.
제 9 항에 있어서,
상기 버스 컨트롤러에 의해 구현된 상기 단일 호스트 인터페이스의 제 2 부분은 상기 단일 호스트 인터페이스를 이용하여 통신하는데 필요한 버스 트랜잭션들을 구현하는, 디바이스.
제 9 항에 있어서,
상기 임베디드 컨트롤러는, 상기 단일 호스트 인터페이스를 구현하고 그리고 상기 버스 컨트롤러와 통신하기 위해 상기 단일 호스트 인터페이스를 이용하는 펌웨어를 포함하는, 디바이스.
제 8 항에 있어서,
상기 단일 호스트 인터페이스는 eSPI(향상된 직렬 주변기기 인터페이스), LPC, 직렬 인터페이스, I2C 인터페이스, USB 인터페이스, SPI 인터페이스, 및 CAN 인터페이스로 이루어진 그룹으로부터 선택된 인터페이스인, 디바이스.
호스트와 복수의 주변 디바이스들 사이에 통신하기 위한 방법으로서,
상기 복수의 주변 디바이스들과 연관된 기능을 제공하는 것 - 상기 기능은 복수의 클래스 드라이버들에 의해 상기 호스트에 제공됨 -;
상기 복수의 클래스 드라이버들과 상기 복수의 주변 디바이스들 사이에 제 1 통신들을 송신하는 것 - 상기 제 1 통신들은 상기 호스트 상의 상기 주변 디바이스 기능을 구현하고, 상기 제 1 통신들은 클래스 프로토콜들을 이용하여 복수의 미니포트 드라이버들에 의해 송신됨 -;
상기 복수의 미니포트 드라이버들과 임베디드 컨트롤러 사이에 제 2 통신들을 송신하는 것 - 상기 제 2 통신들은 단일 호스트 인터페이스를 이용하여 송신됨 -; 그리고
임베디드 컨트롤러와 상기 복수의 주변 디바이스들 사이에 제 3 통신들을 송신하는 것 - 상기 제 3 통신들은 상기 복수의 주변 디바이스들의 각각의 고유 버스 프로토콜들을 이용하여 송신됨 - 을 포함하는, 방법.
제 14 항에 있어서,
상기 제 2 통신들은 상기 단일 호스트 인터페이스의 제 1 부분을 구현하는 버스 컨트롤러 드라이버를 통해, 그리고 상기 단일 호스트 인터페이스의 제 2 부분을 구현하는 버스 컨트롤러를 통해 송신되는, 방법.
제 15 항에 있어서,
상기 버스 컨트롤러 드라이버에 의해 구현된 상기 단일 호스트 인터페이스의 제 1 부분은 상기 단일 호스트 인터페이스를 이용하여 통신하는데 필요한 버스 관리 프로세스들을 구현하는, 방법.
제 15 항에 있어서,
상기 버스 컨트롤러에 의해 구현된 상기 단일 호스트 인터페이스의 제 2 부분은 상기 단일 호스트 인터페이스를 이용하여 통신하는데 필요한 버스 트랜잭션들을 구현하는, 방법.
제 15 항에 있어서,
상기 임베디드 컨트롤러는, 상기 단일 호스트 인터페이스를 구현하고 그리고 상기 버스 컨트롤러와 통신하기 위해 상기 단일 호스트 인터페이스를 이용하는 펌웨어를 포함하는, 방법.
제 14 항에 있어서,
상기 클래스 프로토콜들과 상기 복수의 주변 디바이스들의 상기 각각의 고유 버스 프로토콜들을 이용하는 상기 제 1 통신들과 상기 제 3 통신들을, 상기 단일 호스트 인터페이스를 이용하는 상기 제 3 통신들로 변환하는 것을 더 포함하는 방법.
제 14 항에 있어서,
상기 단일 호스트 인터페이스는 직렬 인터페이스, I2C 인터페이스, USB 인터페이스, SPI 인터페이스, 및 CAN 인터페이스로 이루어진 그룹으로부터 선택되는, 방법.