JP5250042B2

JP5250042B2 - ワイヤレス送受信機用インターフェース・プロトコルおよびａｐｉ

Info

Publication number: JP5250042B2
Application number: JP2010536058A
Authority: JP
Inventors: ルッソ，デーヴィッド・ダブリュー; スミス，グレゴリー・レイ; パケンドルフ，ウウェ; ガムリチ，デニー
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2007-11-27
Filing date: 2008-11-14
Publication date: 2013-07-31
Anticipated expiration: 2028-11-14
Also published as: IL204935A; IL229029A; WO2009070460A2; EP2215551B1; IL204935A0; CA2702466C; EP2215551A2; US8230150B2; US20120017223A1; CA2702466A1; JP2011505755A; US8060681B2; CN101874241A; IL229029A0; US20090138638A1; WO2009070460A3; US20090137318A1; EP2215551A4

Description

ここに開示する主題は、計算および電子分野に関し、更に特定すれば、娯楽用コンソールのような分野に関するが、これらは単なる例に過ぎず、分野に限定はない。

ビデオ・ゲームおよび娯楽システムは、増々ワイヤレス機構(feature)やアクセサリを組み込みつつある。ワイヤレス無線(wireless radio)および必要なドライバの開発には、多大な設計の手間が必要となる。一方、ワイヤレス・インターフェースを制御および管理するために必要とされるコマンドやプロトコルは、複雑化する可能性があり、ワイヤレス・システムのソフトウェアおよびハードウェア・アクセサリの開発者のために多大な開発資源が必要となる。更に、ワイヤレス技術および関連規格は周波数毎に変化するため、開発者は新しいインターフェース要件に適合させることを強いられる。このため、個々のワイヤレス・インターフェースに合わせた製品を開発する際の開発者の投資は、インターフェースやプロトコルが頻繁に変化するのでは、回収できない場合もある。

しかしながら、既存の標準的インターフェース開発ワイヤレス機構およびアクセサリを利用できれば有利であろう。業界において広く用いられ多数の製品によってサポートされているインターフェース規格は、通例、コストを引き下げ、このような市販の構成機器を組み込むことは、製品開発のコストを低減するには望ましいことである。更に、ワイヤレス送受信機の場合、プロセッサー間の通信をサポートするために必要とされるＩＣピンの本数を制限しつつ、同時に十分なデーター帯域幅を提供することが、通例望ましいこととされる。したがって、ワイヤレス・アーキテクチャには簡単なシリアル・インターフェースを選択するとよい。このような従来技術において慣例的に用いられている周知の標準的なインターフェースの１つに、シリアル・ペリフェラル・インターフェース（ＳＰＩ）がある。ＳＰＩインターフェースの欠点の１つは、データー転送が一度に８ビットに制限されることである。多くの用途ではこれまで以上のコマンドおよびデーター転送能力を要求する可能性があるので、シリアル・インターフェースを利用するプロトコルには、一層高いレベルが必要とされる。更に、開発者がワイヤレス機構を利用するために用いることができるインターフェースを提供するものの、当該インターフェースの物理的詳細およびトランスポートの詳細には関与しなくてもよければ有利であろう。

本明細書では、シリアル・ペリフェラル・インターフェース（ＳＰＩ）のようなシリアル・インターフェースを用いてビデオ・ゲームおよび娯楽システムのための新たなワイヤレス・アクセサリの開発をサポートするプラットフォームを提供するために、種々のシステム、方法、およびコンピューター読み取り可能命令について開示する。本開示の例示的な非限定的形態の１つでは、スマート・トランシーバー・デバイスが、ワイヤレス・プロトコル・スタックの物理（ＰＨＹ）およびメディア・アクセス制御（ＭＡＣ）レイヤ全体を内蔵することができ、ワイヤレス・プロトコル機能を１つのデバイスに割り当てる(partition)。

種々の実施形態では、スマート・トランシーバー・デバイスの制御を行い、このスマート・トランシーバー・デバイスに対する双方向のデーター転送に備えるために用いることができるプロトコルを開示する。即ち、プロトコル、コマンド、および応答に合わせたフォーマットの一例を開示する。

更に別の実施形態では、開発者が、ハードウェアに依存しない１組のサービスを提供するためのインターフェースを提供するアプリケーション・プログラミング・インターフェース（ＡＰＩ）を開示する。このようなＡＰＩは、システムおよびスマート・トランシーバー・デバイスへのデーターならびにシステムおよびスマート・トランシーバー・デバイスからのデーターを確定し、維持し、伝達するために用いることができる。サービスは、ＡＰＩが所望するのに応じて呼び出すことができる。即ち、一例であって限定ではないサービス、関数コール、コンフィギュレーション設定方法、イベント、およびパラメータの集合を開示する。

尚、この摘要は、詳細な説明において以下で更に説明する概念から選択したものを、簡略化した形態で紹介するために設けたことを注記しておく。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのでなければ、特許請求する主題の範囲を判断する際に補助として用いられることを意図するのでもない。

以上の摘要、および以下の詳細な説明は、添付図面と合わせて読むと、一層深く理解できよう。本開示を例示するために、本開示の種々の形態を例示する。しかしながら、この開示は、図示する具体的な形態に限定されるのではない。以下の図面が含まれる。

図１は、本明細書において論ずる主題に合わせたコンソールの一例を示す。

図２は、本明細書において論ずる主題に合わせた計算環境の一例を示す。

図３は、本明細書において論ずる主題に合わせたネットワーキング環境の一例を示す。

図４は、本明細書において開示するプロトコルの一実施形態を用いたデーター転送の一例を示す。

図５は、本明細書において開示するプロトコルの一実施形態を用いたデーター転送の一例を示す。

図６は、本明細書において開示するプロトコルの一実施形態を用いたバス転送を図示するタイミング図の一例を示す。

図７は、本明細書において開示するプロトコルの一実施形態を用いるバス転送を図示するタイミング図の一例を示す。

図８は、本明細書において開示するプロトコルの一実施形態を用いるバス転送を図示するタイミング図の一例を示す。

図９は、本明細書において開示する一実施形態を用いたバス転送を図示するタイミング図の一例である。

図１０は、本明細書において開示する一実施形態を用いたバス転送を図示するタイミング図の一例である。

図１１は、本明細書において開示する一実施形態を用いたバス転送を図示するタイミング図の一例である。

図１２は、本明細書において開示するスマート・トランシーバーの一実施形態における起動シグナリングおよびメッセージングの一例を示す図である。

図１３は、本明細書において開示するプロトコルの一実施形態を用いるのに適したシステムの一例を示す。

図１４は、本明細書において開示するプロトコルの一実施形態を用いるサービス・プリミティブ(service primitive)を用いるデーター通信サービスを示す。

図１５は、本明細書において開示するプロトコルの一実施形態を用いるＡＰＩパラメータおよびコンフィギュレーション値を示す。

図１６は、本明細書において開示するプロトコルの一実施形態の簡略化した状態遷移図を示す。

図１７は、本明細書において開示するＡＰＩの一実施形態の構造例を示す。

ゲーム・コンソール、ＰＣ、およびネットワーキングの形態例
本開示のこの章では、一例であり非限定的なゲーム・コンソールの総合的な形態について紹介する。これより図１を参照すると、ブロック図がマルチメディア・コンソールの一例を示す。マルチメディア・コンソール１００は、中央処理ユニット（ＣＰＵ）１０１を有する。ＣＰＵ１０１は、レベル１（Ｌ１）キャッシュ１０２、レベル２（Ｌ２）キャッシュ１０４、およびフラッシュＲＯＭ（リード・オンリー・メモリー）１０６を有する。レベル１キャッシュ１０２およびレベル２キャッシュ１０４は、一時的にデーターを格納し、したがってメモリー・アクセス・サイクル回数を減らすことによって、処理速度およびスループットを向上させる。フラッシュＲＯＭ１０６は、実行可能コードを格納することができる。実行可能コードは、マルチメディア・コンソール１００に電力を投入するときのブート・プロセスの初期フェーズの間にロードされる。あるいは、初期ブート・フェーズの間にロードされる実行可能コードをフラッシュ・メモリー・デバイス（図示せず）に格納してもよい。更に、ＲＯＭ１０６は、ＣＰＵ１０１とは別個に配置してもよい。

グラフィクス処理ユニット（ＧＰＵ）１０８およびビデオ・エンコーダー／ビデオ・コデック（コーダー／デコーダー）１１４は、高速および高分解能グラフィクス処理のためのビデオ処理パイプラインを形成する。データーは、グラフィクス処理ユニット１０８からビデオ・エンコーダー／ビデオ・コデック１１４に、バスを通じて搬送される。ビデオ処理パイプラインは、テレビジョンまたはその他のディスプレイへの送信のために、データーをＡ／Ｖ（オーディオ／ビデオ）ポート１４０に出力する。メモリー・コントローラー１１０がＧＰＵ１０８およびＣＰＵ１０１に接続されており、限定ではないが、ＲＡＭ（ランダム・アクセス・メモリー）のような、種々の形式のメモリー１１２へのプロセッサーのアクセスをし易くする。

マルチメディア・コンソール１００は、Ｉ／Ｏコントローラー１２０、システム管理コントローラー１２２、オーディオ処理ユニット１２３、ネットワーク・インターフェース・コントローラー１２４、第１ＵＳＢホスト・コントローラー１２６、第２ＵＳＢコントローラー１２８、および好ましくはモジュール１１８上に実行するフロント・パネルＩ／Ｏサブアセンブリ１３０を含む。ＵＳＢコントローラー１２６および１２８は、ペリフェラル・コントローラー１４２（１）〜１４２（２）、ワイヤレス・アダプタ１４８、および外部メモリー・ユニット１４６（例えば、フラッシュ・メモリー、外部ＣＤ／ＤＶＤＲＯＭドライブ、リムーバブル・メディア等）のホストとしての役割を果たす。ネットワーク・インターフェース１２４および／またはワイヤレス・アダプタ１４８は、ネットワーク（例えば、インターネット、ホーム・ネットワーク等）へのアクセスを与え、イーサネット(登録商標)・カード、モデム、Bluetoothモジュール、ケーブル・モデム等を含む、多種多様の様々な有線またはワイヤレス・インターフェース・コンポーネントのうち任意のものでよい。

システム・メモリー１４３は、ブート・プロセスの間にロードされるアプリケーション・データーを格納するために設けられている。メディア・ドライブ１４４が設けられており、ＤＶＤ／ＣＤドライブ、ハード・ドライブ、またはその他のリムーバブル・メディア・ドライブ等を含むことができる。メディア・ドライブ１４４は、マルチメディア・コンソール１００の内部でも外部でもよい。アプリケーション・データーは、マルチメディア・コンソール１００による実行、プレーバック(playback)等のために、メディア・ドライブ１４４を通じてアクセスすることができる。メディア・ドライブ１４４は、シリアルＡＴＡバスまたはその他の高速接続（例えば、ＩＥＥＥ１３９４）のようなバスを通じて、Ｉ／Ｏコントローラー１２０に接続されている。

システム管理コントローラー１２２は、マルチメディア・コンソール１００の可用性を確保することに関する種々のサービス機能を提供する。オーディオ処理ユニット１２３およびオーディオ・コデック１３２は、先に記載した本開示の形態にしたがって、高信頼度、３Ｄ、サラウンド、およびステレオ・オーディオ処理による、対応するオーディオ処理パイプラインを形成する。オーディオ・データーは、オーディオ処理ユニット１２３とオーディオ・コデック１２６との間において、通信リンクを通じて搬送される。オーディオ処理パイプラインは、外部オーディオ・プレーヤまたはオーディオ能力を有するデバイスによる再生のために、Ａ／Ｖポート１４０にデーターを出力する。

フロント・パネルＩ／Ｏサブアセンブリ１３０は、電力ボタン１５０およびイジェクト・ボタン１４２の機能をサポートし、更にマルチメディア・コンソール１００の外面上に露出する任意のＬＥＤ（発光ダイオード）またはその他のインディケータの機能もサポートする。システム電源モジュール１３６は、電力をマルチメディア・コンソール１００のコンポーネントに供給する。ファン１３８は、マルチメディア・コンソール１００内部にある回路を冷却する。

ＣＰＵ１０１、ＧＰＵ１０８、メモリー・コントローラー１１０、およびマルチメディア・コンソール１００内部にある種々のその他のコンポーネントは、１系統以上のバスによって相互接続されている。これらのバスには、シリアルおよびパラレル・バス、メモリー・バス、ペリフェラル・バス、ならびに種々のバス・アーキテクチャのうち任意のものを用いたプロセッサーバースまたはローカル・バスが含まれる。

マルチメディア・コンソール１００に電力を投入するか、またはリブートすると、アプリケーション・データーをシステム・メモリー１４３からメモリー１２２および／またはキャッシュ１０２、１０４にロードすることができ、ＣＰＵ１０１において実行することができる。アプリケーションは、マルチメディア・コンソール１００において利用可能な異なるメディア・タイプにナビゲートするときに、一貫性のあるユーザ体験を提供するグラフィカル・ユーザ・インターフェースを提示することができる。動作において、アプリケーションおよび／またはメディア・ドライブ１４４内に収蔵されているその他のメディアをメディア・ドライブ１４４から起動(launch)または再生(play)して、追加の機能をマルチメディア・コンソール１００に提供することもできる。

マルチメディア・コンソール１００は、単に単体システムをテレビジョンまたはその他のディスプレイに接続することによって、その単体システムとして動作させることができる。この単体モードでは、マルチメディア・コンソール１００は、１人以上のユーザがシステムと相互作用すること、ムービーを見ること、音楽を聞くこと等を可能にすることができる。しかしながら、ネットワーク・インターフェース１２４またはワイヤレス・アダプタ１４８を通じて利用可能なブロードバンド接続の統合により、マルチメディア・コンソール１００は、更に、それよりも大きなネットワーク共同体における参加者として動作することができる。この後者の想定場面では、コンソール１００は、例えば、ネットワークを通じてサーバーに接続することもできる。

次に、これより図２に移ると、先に開示した主題の実現と共に用いるのに適していると考えられる計算機の一例を表すブロック図が示されている。本開示の多数の実施形態は、コンピューターにおいて実行することができる。例えば、ゲーム・コンソールにおいてＰＣ体験を提供するプロセスおよび方法を実行するコンピューター実行可能命令は、図１に示すような計算環境に常駐すること、および／またはそこで実行することができる。計算システム環境２２０は、適した計算環境の一例に過ぎず、ここに開示する主題の使用範囲や機能について限定を示唆する意図は全くない。また、計算機環境２２０は、動作環境例２２０に示す構成要素のいずれの１つまたは組み合わせに関しても、何らかの依存性や必須要件を有するという解釈は行わないこととする。実施形態によって、図示する種々の計算エレメントが、本開示の特定の形態をインスタンス化するように構成されている回路を含むこともあり得る。例えば、本開示において用いられる回路という用語は、ファームウェアまたはスイッチによって機能（１つ又は複数）を実行するように構成されている特殊ハードウェア・コンポを含むことができる。別の実施形態例では、回路という用語は、機能（１つ又は複数）を実行するために動作可能なロジックを具現化するソフトウェア命令によって構成される汎用処理ユニット、メモリー等を含むことができる。回路がハードウェアおよびソフトウェアの組み合わせを含む実施形態例では、実装者(implementer)は、ロジックを具現化するソース・コードを書くことができ、ソース・コードを機械読み取り可能コードにコンパイルすることができ、この機械読み取り可能コードを汎用処理ユニットによって処理することができる。技術的現状では、ハードウェア、ソフトウェア、またはハードウェア／ソフトウェアの組み合わせの間には殆ど差がないというところまで発展していることを当業者は認めることができるので、特定の機能を実行するためにハードウェアまたはソフトウェアのどちらを選択するかということは、実装者に委ねられた設計選択事項である。更に具体的には、ソフトウェア・プロセスを等価のハードウェア構造に変換することができ、更にハードウェア構造自体を等価のソフトウェア・プロセスに変換することができることを、当業者は認めることができる。つまり、ハードウェアの実現例およびソフトウェアの実現例のどちらを選択するかということは、実装者に委ねられた設計選択事項の１つである。

コンピューター２４１は、通例、種々のコンピューター読み取り可能媒体を含む。コンピューター読み取り可能媒体は、コンピューター２４１がアクセス可能な入手可能な媒体であればいずれでも可能であり、揮発性および不揮発性の双方、リムーバブル、および非リムーバブル媒体を含む。システム・メモリー２２２は、リード・オンリー・メモリー（ＲＯＭ）２２３およびランダム・アクセス・メモリー（ＲＡＭ）２６０のような揮発性および／または不揮発性メモリーの形態で、コンピューター記憶媒体を含む。基本入出力システム２２４（ＢＩＯＳ）は、起動中のように、コンピューター２４１内のエレメント間におけるデーター転送を補助する基本的なルーティンを含み、通例ＲＯＭ２２３内に格納されている。ＲＡＭ２６０は、通例、処理ユニット２５９が直ちにアクセス可能であるデーターおよび／またはプログラム・モジュール、または現在これによって処理されているデーターおよび／またはプログラム・モジュールを収容する。一例として、そして限定ではなく、図２は、オペレーティング・システム２２５、アプリケーション・プログラム２２６、その他のプログラム・モジュール２２７、およびプログラム・データー２２８を示す。

また、コンピューター２４１は、その他のリムーバブル／非リムーバブル揮発性／不揮発性コンピューター記憶媒体も含むことができる。一例にすぎないが、図２は、非リムーバブル不揮発性磁気媒体からの読み取りおよびこれへの書き込みを行なうハード・ディスク・ドライブ２３８、リムーバブル不揮発性磁気ディスク２５４からの読み取りおよびこれへの書き込みを行なう磁気ディスク・ドライブ２３９、ならびにＣＤＲＯＭまたはその他の光媒体のようなリムーバブル不揮発性光ディスク２５３からの読み取りおよびこれへの書き込みを行なう光ディスク・ドライブ２４０を示す。動作環境の一例において使用可能なその他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピューター記憶媒体には、限定する訳ではないが、磁気テープ・カセット、フラッシュ・メモリー・カード、ディジタル・バーサタイル・ディスク、ディジタル・ビデオ・テープ、ソリッド・ステートＲＡＭ、ソリッド・ステートＲＯＭ等が含まれる。ハード・ディスク・ドライブ２３８は、通例、インターフェース２３４のような非リムーバブル・メモリー・インターフェースを介してシステム・バス２２１に接続され、磁気ディスク・ドライブ２３９および光ディスク・ドライブ２４０は、通例、インターフェース２３５のようなリムーバブル・メモリー・インターフェースによって、システム・バス２２１に接続する。

先に論じ図２に示すドライブおよびそれらと連動するコンピューター記憶媒体は、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、およびコンピューター２４１のその他のデーターを格納する。図２では、例えば、ハード・ディスク・ドライブ２３８は、オペレーティング・システム２５８、アプリケーション・プログラム２５７、その他のプログラム・モジュール２５６、およびプログラム・データー２５５を格納するように示されている。尚、これらの構成要素は、オペレーティング・システム２２５、アプリケーション・プログラム２２６、その他のプログラム・モジュール２２７、およびプログラム・データー２２８と同じでも異なっていても可能であることを注記しておく。オペレーティング・システム２５８、アプリケーション・プログラム２５７、その他のプログラム・モジュール２５６、およびプログラム・データー２５５は、ここで、少なくともこれらが異なるコピーであることを示すために、異なる番号が与えられている。ユーザは、キーボード２５１、および一般にマウス、トラックボールまたはタッチ・パッドと呼ばれているポインティング・デバイス２５２によって、コマンドおよび情報をコンピューター２４１に入力することができる。他の入力デバイス（図示せず）には、マイクロフォン、ジョイスティック、ゲーム・パッド、衛星ディッシュ、スキャナ等を含むことができる。これらおよびその他の入力デバイスは、多くの場合、ユーザ入力インターフェース２３６を介して、処理ユニット２５９に接続されている。ユーザ入力インターフェース２３６は、システム・バスに結合されているが、パラレル・ポート、ゲーム・ポート、またはユニバーサル・シリアル・バス（ＵＳＢ）によって接続することも可能である。モニタ２４２またはその他の形式の表示装置も、ビデオ・インターフェース２３２のようなインターフェースを介して、システム・バス２２１に接続されている。モニタに加えて、コンピューターは、スピーカ２４４およびプリンタ２４３のような、その他の周辺出力装置も含むことができ、これらは出力周辺インターフェース２３３を通じて接続することができる。

コンピューター２４１は、リモート・コンピューター２４６のような１つ以上のリモート・コンピューターへの論理接続を用いて、ネットワーク環境において動作することも可能である。リモート・コンピューター２４６は、パーソナル・コンピューター、サーバー、ルータ、ネットワークＰＣ、ピア・デバイス、またはその他の共通ネットワーク・ノードとすることができ、通例、コンピューター２４１に関して先に説明したエレメントの多くまたは全てを含むが、図２にはメモリー記憶装置２４７のみを示す。図２に示す論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）２４５およびワイド・エリア・ネットワーク（ＷＡＮ）２４９を含むが、他のネットワークも含むことができる。このようなネットワーク環境は、事務所、企業規模のコンピューター・ネットワーク、イントラネットおよびインターネットにおいては、一般的である。

ＬＡＮネットワーク環境で用いる場合、コンピューター２４１は、ネットワーク・インターフェースまたはアダプタ２３７を介してＬＡＮ２４５に接続する。ＷＡＮネットワーク環境で用いる場合、コンピューター２４１は、通例、モデム２５０、またはインターネットのようなＷＡＮ２４９を通じて通信を確立するその他の手段を含む。モデム２５０は、内蔵でも外付けでもよく、ユーザ入力インターフェース２３６またはその他の適切な機構を介してシステム・バス２２１に接続することができる。ネットワーク環境では、コンピューター２４１に関係付けて図示したプログラム・モジュール、またはその一部は、リモート・メモリー記憶装置に格納することもできる。一例として、そして限定ではなく、図２は、リモート・アプリケーション・プログラム２４８がメモリー・デバイス２４７上に常駐するものとして示している。尚、図示のネットワーク接続は一例であり、コンピューター間で通信リンクを確立する他の手段も使用可能であることは認められよう。

図３は、ネットワーク型または分散型計算環境の一例の模式図を示す。この環境は、計算機１５３、１５６、および１５７、ならびにオブジェクト１５５およびデーターベース１５８を備えている。これらのエンティティ１５３、１５５、１５６、１５７、および１５８は、プログラム、方法、データー・ストア、プログラマブル・ロジック等を備えること、またはこれらを利用することができる。エンティティ１５３、１５５、１５６、１５７、および１５８は、ＰＤＡ、オーディオ／ビデオ・デバイス、ＭＰ３プレーヤ、スマート・フォン、ＤＶＤプレーヤ、ケーブル・ボックス・チューナのような同一デバイスまたは異なるデバイスの部分に跨ることや、あるいはサーバーＰＣによって提供される遠隔供給コンテンツ(remoted content)に対応可能な任意の計算機の周囲に及ぶこともある。各エンティティ１５３、１５５、１５６、１５７、および１５８は、別のエンティティ１５３、１５５、１５６、１５７、および１５８と、通信ネットワーク１５４を通じて通信することができる。これに関して、データーベース１５８またはその他の記憶エレメントの維持および更新には、任意のエンティティが担当すればよい。

このネットワーク１５４自体は、図３のシステムにサービスを提供する別の計算エンティティを備えることができ、それ自体が複数の相互接続されたネットワークを表すこともできる。ここに開示する本主題の一形態によれば、各エンティティ１５３、１５５、１５６、１５７、および１５８は、別個の機能プログラム・モジュールを内蔵することができ、これらのモジュールは、ＡＰＩ、あるいはその他のオブジェクト、ソフトウェア、ファームウェア、および／またはハードウェアを利用して、他のエンティティ１５３、１５５、１５６、１５７、および１５８の１つ以上のサービスを要求することもできる。

また、１５５のようなオブジェクトを別の計算機にホストしてもよいことは認めることができる。つまり、図示した物理的環境は、接続されているデバイスをコンピューターのように示すことができるが、このような図は単なる一例であり、物理的環境は、代わりに、ＰＤＡ、テレビジョン、ＭＰ３プレーヤ等のような種々のディジタル・デバイス、インターフェース、ＣＯＭオブジェクト等のようなソフトウェア・オブジェクトを備えることとして図示または記載することもできる。

分散型計算環境をサポートする種々のシステム、コンポーネント、およびネットワーク構成がある。例えば、複数の計算システム同士を、有線システムまたはワイヤレス・システムによって、複数のローカル・ネットワークによって、または広く分散した複数のネットワークによって、互いに接続することができる。現在、多くのネットワークはインターネットに結合されており、インターネットは、広く分散する計算のためにインフラストラクチャを提供し、多くの異なるネットワークを包含する。このようなインフラストラクチャはいずれも、インターネットに結合されているか否かには拘わらず、提供する本システムおよび方法と共に用いることができる。

ネットワーク・インフラストラクチャは、クライアント／サーバー、ピア・ツー・ピア、または混成アーキテクチャのような、ネットワーク・トポロジのホストを可能にすることができる。「クライアント」とは、別のクラスのサービスを用いるクラスまたはグループの構成員、またはそれには関係ないグループの構成員である。計算においては、クライアントがプロセスであり、即ち、大まかに命令またはタスクの集合であり、別のプログラムが提供するサービスを必要とする。クライアント・プロセスは、要求されたサービスを利用するが、他のプログラムやサービス自体に関する作業詳細について全く「知る」必要がない。クライアント／サーバー・アーキテクチャ、特に、ネットワーク型システムでは、クライアントは、常に、別のコンピューター、例えば、サーバーが提供する共有ネットワーク資源にアクセスするコンピューターである。図３の例では、任意のエンティティ１５３、１５５、１５６、１５７、および１５８を、状況に応じて、クライアント、サーバー、または双方と見なすことができる。そして、更に、娯楽コンソールに関しては、これはサーバーに対するクライアントとすることができる。

サーバーは、インターネットのようなリモートまたはローカル・ネットワークを通じてアクセス可能なリモート・コンピューター・システムであるのが通例であるが、必ずしもそうとは限らない。クライアント・プロセスは、第１コンピューター・システムにおいてアクティブであることができ、サーバー・プロセスは第２コンピューター・システムにおいてアクティブであることができ、通信媒体を通じて互いに通信し、こうして分散型機能を提供し、複数のクライアントがサーバーの情報収集能力を利用することを可能にする。複数の計算機またはオブジェクトにまたがって、任意のソフトウェア・オブジェクトを分散することもできる。

クライアント（１つ又は複数）およびサーバー（１つ又は複数）は、プロトコル・レイヤ（１つ又は複数）が提供する機能を利用して、互いに通信する。例えば、ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）は、ワールド・ワイド・ウェブ（ＷＷＷ）即ち「ウェブ」と共に用いられる慣例的なプロトコルである。通例、インターネット・プロトコル（ＩＰ）アドレスのようなコンピューター・ネットワーク・アドレス、またはユニバーサル・リソース・ロケータ（ＵＲＬ）のようなその他の基準を用いて、サーバーまたはクライアント・コンピューターを互いに識別することができる。ネットワーク・アドレスをＵＲＬアドレスと呼ぶこともできる。通信は、通信媒体を通じて提供することができ、例えば、高容量通信のために、クライアント（１つ又は複数）およびサーバー（１つ又は複数）を互いにＴＣＰ／ＩＰ接続（１つ又は複数）を通じて結合することもできる。

図３において提示した一般的なフレームワークにしたがって構築することができる多様な計算環境、および図３のようなネットワーク環境における計算において生ずる可能性がある多様性に関して、本明細書において提供するシステムおよび方法を、特定の計算アーキテクチャまたはオペレーティング・システムに限定されるように解釈することは全くできない。逆に、ここに開示する主題は、いずれの１つの実施形態にも限定されず、むしろ、添付した特許請求の範囲にしたがってその広さや範囲を解釈してしかるべきである。つまり、例えば、ゲーム・コンソールおよびサーバーＰＣについて論じているが、スマート・フォンには入手できないデーターや機能にアクセスする手段として、同じような容易さで、完全なデスクトップをスマート・フォンに遠隔接続することもできる。

最後に、本明細書において記載する種々の技法は、ハードウェアまたはソフトウェアと共に実現することができ、しかるべき場合には双方の組み合わせで実現することもできることも、注記してしかるべきであろう。つまり、ここに開示する主題の方法、コンピューター読み取り可能媒体、およびシステム、あるいはそのある種の形態または一部は、フロッピ・ディスク、ＣＤ−ＲＯＭ、ハード・ドライブ、または他の任意の機械読み取り可能記憶媒体のような有形媒体に具現化したプログラム・コード（即ち、命令）の形態をなすことができ、このプログラム・コードを、コンピューターのような機械にロードして実行すると、この機械が本主題を実施する装置となる。

プログラマブル・コンピューターにおけるプログラム・コードの実行という場合では、計算機は概略的にプロセッサー、当該プロセッサー（揮発性および不揮発性メモリーおよび／または記憶エレメントを含む）によって読み取り可能な記憶媒体、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスを含むことができる。例えば、データー処理ＡＰＩ等の使用によって、本開示のドメイン特有プログラミング・モデルの形態の作成および／または実現例を利用することができる１つ以上のプログラムは、好ましくは、コンピューター・システムと通信するために、上位手続き言語またはオブジェクト指向プログラミング言語で実現することが好ましい。しかしながら、プログラム（１つ又は複数）は、望ましければ、アセンブリまたは機械語で実現することもできる。いずれの場合でも、言語は、コンパイラ言語またはインタプリタ言語でもよく、ハードウェアの実現例と組み合わせることができる。
ＳＰＩプロトコルおよびコマンド構造

本明細書では、ビデオ・ゲームおよび娯楽システムに合わせた新たなワイヤレス・アクセサリの開発をサポートするプラットフォームを提供するために、種々のシステム、方法、およびコンピューター読み取り可能命令を開示する。プロセッサー間通信をサポートするのに必要なＩＣピンの数を制限するために、単純なシリアル・インターフェースを用いるとよい。即ち、できるだけ多くの市販のＣＰＵ部品との共通インターフェースを設け、必要なデーター・トラフィックをサポートするために、シリアル・ペリフェラル・インターフェース（ＳＰＩ）に基づく設計を実現するとよい。

ＳＰＩは、マスター・デバイスとスレーブ・デバイスとの間におけるデーターのシリアル交換を可能にするインターフェースである。ＳＰＩは、通例、同期プロトコルを用い、送信および受信は、マスター・マイクロコントローラーが発生するクロック信号によって誘導される。ＳＰＩインターフェースは、数台のＳＰＩデバイスの接続を可能にし、一方マスターは、ＣＳ（チップ選択）信号によって各デバイスを選択する。
ＳＰＩは、通例、４本の信号ワイヤを備えている。
マスター出力スレーブ入力（ＭＯＳＩ）
マスター入力スレーブ出力（ＭＩＳＯ）
シリアル・クロック（ＳＣＬＫまたはＳＣＫ）
チップ選択（ＳＣ）

ＳＰＩは、同期シリアル・データー・リンクの標準である。デバイスは、マスター／スレーブ・モードで通信し、マスター・デバイスがデーター・フレームを開始する。複数のスレーブ・デバイスは、個別のチップ選択線を有することが許される。

各ＳＰＩクロック・サイクルの間、全二重データー送信が行われ、その中で、マスターはＭＯＳＩ線において１ビットを送り、スレーブはそのビットをその同じ線から読み取り、このスレーブは１ビットをＭＩＳＯ線において送り、マスターはそれをその同じ線から読み取る。送信には、通例、８ビットというような、所与のワード・サイズのシフト・レジスタを２つ伴い、１つがマスター内に、そしてもう１つがスレーブ内にある。これらのシフト・レジスタは、環状に接続されている。データーは、通例、最上位ビットが最初に押し出され、一方新たな最下位ビットが同じレジスタ内に押し込まれる。レジスタから押し出した後、マスターおよびスレーブは、レジスタ値を交換したことになる。次いで、必要に応じて、このプロセスを繰り返すことができる。

この開示の例示的な非限定的形態の１つでは、スマート・トランシーバー・デバイスを設けて、ゲーム・プラットフォームに合わせた新たなワイヤレス・アクセサリの迅速な開発をサポートすることができる。一実施形態では、スマート・トランシーバーは、物理およびリンク・ワイヤレス通信レイヤの受信および送信機能を備えることができる。即ち、ワイヤレス・プロトコル・スタックのＰＨＹおよびリンク・レイヤ、ならびにこのようなデバイスに合わせたワイヤレス・プロトコル機能を、ワイヤレス・アプリケーション特有集積回路（ＡＳＩＣ）に実装することができる。一実施形態では、スマート・トランシーバーがＳＰＩバスのスレーブとなることができ、マスター制御アプリケーションがＳＰＩバスのマスターとなることができる。

一実施形態では、ワイヤレス通信は、ワイヤレス・アクセサリ毎に時分割多元接続（ＴＤＭＡ）無線時間を付与する、周波数ホッピング・ディジタル無線プロトコルを用いて提供することができる。無免許の世界規模２．４ＧＨｚ工業化学医療（ＩＳＭ）無線帯域を利用することができる。世界規模の規制要件に準拠する完全な周波数ホッピング・スペクトル拡散（ＦＨＳＳ）２．４ＧＨｚＩＳＭ帯域ディジタル無線トランシーバーを実現するために必要な外部コンポーネントは、最小限で済ますことができる。

標準的なＳＰＩインターフェースの欠点は、データー転送が一度に８ビットに制限されていることである。多くの用途ではそれよりも高いコマンドおよびデーター転送能力を必要とすることがあり得るので、シリアル・インターフェースの利点を残しつつも、一層高いレベルのプロトコルが求められている。全二重データー転送によるＳＰＩバスを通じた効率的な制御／データー伝達方法を考慮して、種々の実施形態では、フレームに基づくＳＰＩプロトコルを開示する。これは、制御およびデーター転送をスマート・トランシーバー・デバイスに対して双方向に行うために用いることができる。即ち、このプロトコル、コマンド、および応答に合わせたフォーマット例を開示する。一実施形態では、各フレームは、ペイロード長が可変の、２バイトのヘッダーを含むことができる。ヘッダーは、２つの部分、即ち、コマンド・バイトおよび長サーバーイトを備えることができる。ペイロードの長さは、個々のコマンドによって異なってもよく、最も長いパケットは、転送の長さを定めることができる。図４は、典型的なデーター転送の例示的な図を示す。

開示するプロトコルは、全二重インターフェースを備えているので、あるデバイスが転送する情報を有していない場合、そのデバイスはアイドル・コマンドを送ることができる。開示するプロトコルは、マスター／スレーブ構造を維持することができ、マスター制御アプリケーションが通例全てのトランザクションを制御し、マスター制御アプリケーションが送信する用意ができているメッセージを有するときにはいつもで、データーを転送する。スマート・トランシーバーは、スレーブ・デバイスとして機能する(act)ことができ、回答を返送することができる。回答は、要求の結果、コマンドに対する遵守、または以前の要求からのイベントの発生の指示を示す。スマート・トランシーバーは、更に、マスター制御アプリケーションに割り込みを発生し、マスターがメッセージを読む準備ができていることを示すことができる。

開示するプロトコルは、更に、フレーム・トランザクションに適用する以下の規則も備えることができる。第１に、チップ選択は、アクティブ状態にあることができる。第２に、ヘッダーは常にリンクの両端において最初に送信することができる。一方の端部が送信すべき有効なメッセージを有していない場合、コマンド・フィールドを０ｘ００に設定することができる。第３に、転送の長さを定めるために、最も長いフレーム（マスターからスレーブに、またはスレーブからマスターに）を用いることができる。第４に、一方側が１つよりも多い送るべきパケットを有する場合、同じフレームの中に、独立したメッセージを一緒に添付することができる。

以下の表に表した事例は、全て例示的な有効転送である。

図５から図１１は、上の表において概要を示した想定場面についてのバス転送を示すタイミング図の例である。図５は、マスターが送信するデーターを有し、スレーブが送信するコマンドを有するがデーターを有していない場合を示す。図６は、マスターが送信するコマンドを有するがデーターを有しておらず、スレーブは送信するデーターを有していない場合を示す。図７は、マスターが送信するデーターを有し、スレーブも送信するデーターを有する場合を示す。図８は、マスターが送信するコマンドを有するがデーターを有しておらず、スレーブがデーターを有する場合を示す。図９は、マスターが複数のデーター・パケットを有し、スレーブも複数のデーター・パケットを有する場合を示す。図１０は、マスターが多数のデーター・パケットを有し、スレーブが送信する１つのデーター・パケットを有する場合を示す。最後に、図１１は、マスターが送信するデーターを有しておらず、スレーブが複数のデーター・パケットを有する場合を示す。

フレーム・ヘッダーの後には、ガード・タイムを不要とすることもできる。ＣＳ＃のローからハイへの遷移を、フレーム同期に用いることができる。ＳＰＩ多重スレーブ・アプリケーションをサポートするために、データー転送を終了した後（ＣＳ＃によってトリガされる）、ＭＩＳＯパッドを三状態(tristate)に設定することができる。データー・バイトは、長サーバーイトによって定められたデーター・バイト数が送信された後「ドント・ケア」に設定することができる。

一実施形態では、スマート・トランシーバーの機能は、起動時に選択することができる。スマート・トランシーバーの機能は、所望の用途に応じて異なってもよい。更に、機能は、スマート・トランシーバーを用いる製品の種類によっても異なる場合もある。例えば、音声専用デバイスにおいてＩＣが用いられている場合、ＩＣは、その製品がゲーム・コントローラー・デバイスである場合とは異なる動作をすることもあり得る。ＳＰＩコマンド構造は、スマート・トランシーバーのコンフィギュレーションを設定する対象となる用途の種類に応じて変更することもできる。

スマート・トランシーバー・デバイスは、４つまでのデーターおよび音声アクセサリ、あるいは４つのデーター専用および４音声専用アクセサリ、あるいはこれらの間における任意の組み合わせを同時にサポートするように設計することができる。スマート・トランシーバーは、ワイヤレス・アクセサリに実装する場合、ワイヤレス・ビデオ・ゲーム・コンソールまたはワイヤレス対応パーソナル・コンピューター、あるいは同様のスマート・トランシーバーを装備しているその他の計算機と通信することができる。

スマート・トランシーバーは、種々の製品コンフィギュレーションをサポートするために用いることができるプラットフォームとするとよい。スマート・トランシーバー内にあるファームウェアは、チップのハードウェアを変更することなく、種々の製品バージョンをサポートするように調節することができる。ビデオ・ゲーム・システムでは、スマート・トランシーバーは、ビデオ・コンソール製品、ゲーム・コントローラー製品、および種々のペリフェラル製品をサポートするために用いることができる。

図１２は、スマート・トランシーバーの一実施形態における起動シグナリングおよびメッセージングの一例を示す図である。この図を参照すると、スマート・トランシーバーは、スマート・トランシーバー起動メッセージを送ることができる（６１０）。次いで、マスター制御アプリケーションが起動コンフィギュレーション・メッセージ６１５をスマート・トランシーバーに送ることができる。起動コンフィギュレーション・メッセージは、スマート・トランシーバーに、概略的な設定に関する情報を提供することができる。概略的な設定には、用いられるＳＰＩプロトコル、必要とされる出力クロック、ＥＥＰＲＯＭストレージの種類、およびマスター制御アプリケーションによって用いられるＥＥＰＲＯＭの長さが含まれる。

スマート・トランシーバーは、起動コンフィギュレーション応答によって応答することができる（６２０）。マスター制御アプリケーションは、ＥＥＰＲＯＭデーターを検索してアプリケーションのコンフィギュレーションを得るためのコマンドを送ることができる（６２５）。送信されると、マスター制御アプリケーションはこのコマンドを送り、スマート・トランシーバー６３０からの応答を待つことができる。

マスター制御アプリケーションは、アプリケーション・コンフィギュレーション・コマンド６３５を送ることができる。アプリケーション・コンフィギュレーション・コマンドは、スマート・トランシーバー・チップを、マスター制御アプリケーションが必要とするモードに設定することができる。スマート・トランシーバーは、アプリケーション・コンフィギュレーション応答で応答することができる（６４０）。

マスター制御アプリケーションは、アプリケーションをアクティブに設定するコマンドを送ることができる（６４５）。スマート・トランシーバーは、次いで、「アプリケーション・アクティブ」の現行モードで応答することができる（６５０）。

コンフィギュレーション・スタンバイ状態では、限られたＳＰＩコマンドしかマスター制御アプリケーションに許可されないようにするとよい。通例、スマート・トランシーバーは、この時点において任意の機能を実行するのに十分な情報を有しておらず、マスター制御アプリケーションにもっと多くのデーターを供給することを要求する。通例、この状態において許可することができるコマンドは、モード制御（即ち、給電、リセット）および起動コンフィギュレーション・メッセージングだけである。

アプリケーション未定状態(pre-application state)には、マスター制御アプリケーションが有効な起動コンフィギュレーション・メッセージを送った後に入ることができる。この状態は、より多くのＳＰＩコマンドを許可することができるが、アプリケーションが確定していないので、個数を制限するとよい。許可されるコマンドの主要な機能は、通例、コンフィギュレーション読み出し、コンフィギュレーション設定、およびモード制御である。スマート・トランシーバーは、マスター制御アプリケーションがそれを別の状態に変えるまで、この状態に残留することができる。

アプリケーション・スタンバイ状態には、マスター制御アプリケーションがアプリケーション・コンフィギュレーションを設定した後に入ることができる。通例、アプリケーションは、マスター制御アプリケーションが状態をアクティブに設定するまで開始しない。

アプリケーション・アクティブ状態には、マスター制御アプリケーションがモードをアクティブに設定した後に、アプリケーション・スタンバイ状態から入ることができる。アプリケーション・アクティブ状態は、通例、デバイスの正常動作モードである。マスター制御アプリケーションは、アプリケーションによって許可されたコマンドを発行し続けることができる。

以下に、スマート・トランシーバーの機能をサポートするメッセージ・リストの一例を示す。コマンドは、２つの集合に分けて示す。第１の集合は、アプリケーションに独立することができるコマンドである。第２の集合は、アプリケーション特有コマンドの例を示す。通例、これらのコマンド集合は、もっと大きな完全なコマンド集合の部分集合である場合もある。

以下の表は、アプリケーションとは独立したコマンドの例をリストにして示す。コマンドの詳細（具体的なフォーマットおよびフィールドの意味）については、補足資料Ａにおいて規定する。

ゲームパッド・アプリケーションは、ゲームパッド・ハンドリング(gamepad handling)と関連のあるワイヤレス・プロトコルを用いることができる。ゲームパッド・アプリケーションの音声部は、ゲームパッド規則を用いて、音声チャネルを取得することができる。以下の表は、ゲームパッド・アプリケーションが用いることができるＳＰＩメッセージを示す。

音声デバイス・アプリケーションは、音声デバイスと関連のあるワイヤレス・プロトコルを用いることができる。ワイヤレス・アプリケーションの音声部は、音声規則を用いて、音声チャネルを取得することができる。以下の表は、音声アプリケーションが用いるＳＰＩメッセージの一例を示す。

アプリケーション・プログラミング・インターフェース（ＡＰＩ）

次に、ＡＰＩについて説明する。一実施形態では、スレーブ・デバイスは、アプリケーション・プロセッサー（ＡＰ）と、ワイヤレス・プロトコル・プロセッサーとしてのスマート・トランシーバーとで構成することができる。ＡＰＩは、アプリケーション・プロセッサーの中に配置することができる。これら２つのプロセッサーは、シリアル・ペリフェラル・インターフェース（ＳＰＩ）によって接続することができる。

図１３に示すように、実際のハードウェアおよびソフトウェア環境とは独立してサービスを提供することもできるが、一実施形態では、ＡＰＩが、別個のアプリケーション・プロセッサー（マスター制御アプリケーション・プロセッサー）がシリアル・インターフェースを通じてスマート・トランシーバーと通信することを保証することができる。更に、別の実施形態では、ＡＰＩは、包括的ＧＰＩＯアプリケーションによって用いることもできる。

一実施形態では、ＡＰＩは、物理無線チャネルへのアクセスおよびスマート・トランシーバー・ピンへのアクセスを扱うことができる。更に、ＡＰＩは以下のタスクも担当することができる。
１．ＳＰＩドライバを用いた、ＳＰＩを通じたスマート・トランシーバーとの通信。
２．スマート・トランシーバーの設定の簡略化。
３．アプリケーションとスマート・トランシーバーとの間における電力モードおよび機能状態の同期化。
４．アプリケーションのワイヤレス・データーおよび音声送信機能に対するフレームワークの提供。
５．アプリケーションのスマート・トランシーバーとの通信のデバッグのサポート。

ＡＰＩサービスには５つのグループを考慮することができる。
１．ワイヤレス・リンクを通じて固定サイズのデーター・パケットを送信および受信するデーター・サービス。
２．ワイヤレス・リンクを通じて音声パケットを送信および受信する音声サービス。このサービスの等時性をサポートするため、そして音声サンプルの符号化および復号をサポートするために特殊なメカニズムを含むこともできる。
３．他のサービスのパラメータを構成するためのレイヤ管理サービス。
４．スマート・トランシーバーの何らかの予備ピンにおいてビット指向ＩＯを実行するためのＧＰＩＯサービス。
５．スマート・トランシーバー生産検査インターフェースへのアクセスをアプリケーションに与えるための生産検査サービス。

データー通信サービスは、図１４に例示するようなサービス・プリミティブ(service primitives)に関して定めることができる。サービス・プリミティブとは、サービス提供レイヤと任意のサービス・ユーザ（タスク、レイヤ等）との間における抽象的な相互作用である。したがって、これは、ソフトウェア実現例の詳細とは独立していることができる。サービスは、目標システムに合わせて、適宜関数コールまたはオペレーティング・システムのメッセージとして実現することができる。

図１５に示すように、情報ベース（ＩＢ）はＡＰＩパラメータおよびコンフィギュレーション値を収蔵することができる。サービス・プリミティブは、４つの包括的タイプのうちの１つとすることができる。
・要求：要求プリミティブは、サービスをＡＰＩによって開始することを要求するためにレイヤを用いてサービスから下方に受け渡すことができる。
・指示：指示プリミティブは、ＡＰＩから上方に受け渡すことができる。このイベントは、論理的にリモート・サービス要求と関係付けることができ、あるいは内部ＡＰＩイベントによって起こる場合もある。
・確認：確認プリミティブは、ＡＰＩからアプリケーション／ネットワーク・レイヤに受け渡し、１つ以上の関連する以前のサービス要求の結果を伝えることができる。
・応答：応答プリミティブは、サービス使用レイヤからＡＰＩに受け渡し、指示プリミティブによって以前に呼び出された手順を完了することができる。

以下の取り決めをプリミティブに用いることができる。＜プリミティブ名＞＜プリミティブ・タイプ＞。＜プリミティブ・タイプ＞は、要求、指示、確認、または応答のうちの１つとすることができる。

サービス・プリミティブは、以下の機能を設けることができる。
...Data...：種々の固定サイズを有するデーター・パケットの送信。
...Connect...：接続の確立
...Disconnect...：接続の解放

上流データー・サービスのパケット・タイプのリストの一例を以下に示す。全てのタイプは任意のシーケンスで用いることができる。最大上流スループットは、フレーム当たり４８バイト（これに、１６ビットまでがヘッダーに追加される）として与えることができる。フレーム期間は、８ｍｓとすることができる。総合要求スループットは、通例、この最大値を超過しない。純粋なワイヤレス音声デバイス（例えば、ヘッドセット）では、...DATA_VOICE...パケット・タイプを用いることができる。

殆どの上流パケット・タイプおよび対応するデーター（サブ−）サービスは、無線リンクにおいてはパケット整列もフロー制御も全く提供しない。これらのデーター・パケットは、再書き込み可能であると想定されている。再書き込み可能なパケットが、実現可能なスループットによって許容されるよりも速く送られると、後に送られるパケットが、先に送られたパケットを上書きする可能性がある。再書き込み可能パケットは、通例、何らかの状態情報を周期的に送信するために用いられる。

下流データー・サービスのパケット・タイプのリストの一例を以下に示す。全てのタイプは任意のシーケンスで用いることができる。最大下流スループットは、フレーム当たり８バイト（これに、１６ビットまでがヘッダーに追加される）として与えることができる。フレーム期間は、８ｍｓとすることができる。総合下流スループットは、通例、この最大値を超過しない。純粋なワイヤレス音声デバイス（例えば、ヘッドセット）では、...DATA_VOICE...パケット・タイプを用いることができる。

音声サービスでは、サービス・プリミティブは以下の機能を設ける。
...TxRx...：ＰＣＭ音声パケットの送信タイミングを示す。実際の音声パケットは、特殊機能GetVoiceBufferによって交換される。
...Connect...：接続の確立
...Disconnect...：接続の解放
...SampleRate...：上流サンプル・レートの変更を示す。

ＰＣＭデーターは、したがって、スマート・トランシーバーによって、スループット制約を満たすように符号化することができる。ＰＣＭ音声サンプルは、サンプル当たり１６ビットで送信することができる（左揃え、２の補数、リトル・エンディアン・フォーマット）。

サンプル・レートは、いつでもマスター・デバイスによって変更することができる。サンプル・レートの指示を与えると、この場合では、オーディオ・ハンドラーにＡＤ変換パラメータをしかるべく変更するきっかけとなることができる。

上流音声パケット・サイズ（属性IB_VOICE_PACKET_SIZE）および初期上流符号化タイプ（属性IB_UPSTREAM_VOICE_ENCODING_TYPE）は、ＩＢヘッダー・ファイルにおいて設定することができる。

管理サービスは、データーや音声送信サービスには直接関係しないプリミティブ、およびレイヤ・コンフィギュレーションを情報ベース（ＩＢ）を通じて組み合わせることができる。典型的なアプリケーション環境では、ＩＢ属性は固定値を有し、アプリケーション実行の最中に変更する必要はない。

管理サービス・プリミティブは、以下の機能を設けることができる。
...Init...：ＡＰＩソフトウェア初期化。
...Start...：スマート・トランシーバーとの通信の開始。
...Reset...：ＡＰＩおよびスマート・トランシーバーのリセット。
...PowerDown...：スマート・トランシーバーの電源遮断。
...Bind...：マスター／スレーブ・バインディング（接続のためには欠くことができないが、必要とされるのは１回だけである）。
...StopBind...：バインディングの停止。
...Read...：スマート・トランシーバーのＥＥＰＲＯＭの読み出し。
...Write...：スマート・トランシーバーのＥＥＰＲＯＭの書き込み。

また、ＩＢ属性は、更なる拡張のためのオプションとして、対応するプリミティブ（ゲットおよびセット(get and set)）によってアクセスすることもできる。すると、ＩＢアクセス・プリミティブは別個の確認プリミティブを有することができる。何故なら、殆どの場合、スマート・トランシーバーとの通信が関与するからである。

スマート・トランシーバーは、予備のＧＰＩＯピンを有することができ、これらは入力または出力のいずれにも用いることができる。コンフィギュレーション設定は、ＩＢ属性を通じて行うことができる。

サービス・プリミティブは、１６ＩＯピンまでセットまたはクリアすることができ、あるいは１６ＩＯピンまでの現在の状態を、要求に応じて（確認プリミティブによって）または要請なしに（指示プリミティブによって）伝えることができる。

図１６は、ＡＰＩプロトコルの一実施形態について、簡略化した状態遷移図を示す。ＡＰＩ状態は、次のように定めることができる。
INITIALIZED（初期化済み）：ＡＰＩを用いる準備ができている。
STARTED（開始）：スマート・トランシーバーとの通信が確立され、構成されている。
CONNECTED（接続）：データーおよび／または音声接続が確立され、データーおよび／または音声を送るまたは受信することができる。状態図を簡略化するために、音声接続状態および遷移は示されていないが、別個の独立したインスタンスとして存在することができる。
BINDING（結束）：これは、マスター・デバイスに結束する間における過渡的状態である。通常では、CONNECTED状態に到達するためにだけ結束を行う必要はない。スレーブ・デバイスの寿命の間に１回だけしか起こらない可能性が高い。

ＡＰＩの基本的構造の一例を図１７に示す。図に示すのは、状態機械であり、アプリケーションによる要求を扱い、スマート・トランシーバーによって受信されたＳＰＩメッセージおよび内部状態に応じてアプリケーションに対してイベントを発生することができる。マスター制御アプリケーション・コントローラーとスマート・トランシーバーとの間でデーターおよび音声を転送するためのバッファ機能を、ＡＰＩに統合することもできる。アプリケーション・レイヤは、要求を送出するために、プリミティブ関数コールに関して、ＡＰＩと通信することができる。加えて、一実施形態では、ＡＰＩからのイベント・メッセージを扱うために、２つの関数GetEvent(...)およびReadEventDetails(...)がある。音声の扱いには、２つの関数PutVoiceBuffer(...)およびGetVoiceBuffer(...)を実装することができる。ＳＰＩドライバは、ＡＰＩバッファを処理するための４つの関数を用いて、ＡＰＩにインターフェースすることができる。

要求には２つのタイプを考えることができる。
１．対応する確認を有さないかもしれない要求。要求された動作の成果は、通例、関数コールの戻りの後でなければ分からない。
２．対応する確認を有する可能性がある要求。これらのタイプの要求には、動作を扱うために２つの異なる方法、同期および非同期があるとよい。同期実現例では、関数コールの成果は、当該関数コールの戻りの後でないと分からないが、関数は確認を待つことができ、関数が戻るまでコール・タスクを阻止することができる。対照的に、非同期の実現例は、直ちに戻る関数コールを有することができるが、動作の成果を別個に処理することができる。

指示および確認は、アプリケーションによってイベント（イベント識別子、および受信したプリミティブ・エレメントに対するポインタのリスト）として受信することができる。関数コールは、イベントを取込、イベントの詳細を読み取るために利用できる場合がある。音声処理タスクを最適化するために、音声サンプルのバッファ管理は、イベントの代わりに、別個の関数コールによって扱うとよい。基礎となるオペレーティング・システムでは、これは、タスクまたはスレッドによって受信されるメッセージによって実現することができる。

指示および確認の受信にイベント・ループを有する代わりに、コール・バック機能をＡＰＩに登録することもできる。各指示または確認が受信されると、対応する関数をコールすることができる。

以下の表は、ユーザおよびサード・パーティのアプリケーションに利用可能なＳＰＩコマンドを、本明細書において論じているプリミティブと相互引用したものである。１つのプリミティブが１回よりも多くリストに現れる場合、プリミティブ・パラメータ（例えば、Xair_MdDataReq）または内部ドライバ状態（例えば、Xair_MmStartReq）にしたがって該当するコマンドを選択する。ＦＦＳという印が付いているコマンドは、現在本明細書には含まれていないが、望ましければ追加することができる。

補足資料Ｂは、ＡＰＩサービスによって提供される種々の機能の詳細を示す。

最後に、本開示は、種々の図に示したような好ましい形態に関して説明したが、他の同様の形態も用いることができ、本開示から逸脱せずに、本開示の同じ機能を実行するために、変更や追加を、記載した形態に行ってもよいことは言うまでもない。例えば、本開示の種々の形態では、プロトコルおよびＡＰＩを開示した。しかしながら、これらの記載した形態と等価の別のメカニズムも、本開示における教示によって想起される。したがって、本開示はいずれの１つの形態にも限定されず、むしろ添付した特許請求の範囲にしたがって広さおよび範囲を解釈するものとする。
補足資料Ａ
スマート・トランシーバー起動メッセージ

スマート・トランシーバーが最初に起動して、ＳＰＩモードが検出され、ＳＰＩ転送の準備ができている場合、起動メッセージをＳＰＩ出力ＦＩＦＯにロードし、「D_AVAIL#」ラインをアサートすることができる。このメッセージは、通例、コンフィギュレーション・メッセージとして用いられ、マスター制御アプリケーションに、チップのタイプおよびそのコンフィギュレーションを知らせる。スマート・トランシーバーが自動的にこのメッセージを起動時に送ることができるが、マスター制御アプリケーションは、スマート・トランシーバー起動メッセージ要求を用いて、いつでもそれを要求することができる。
スマート・トランシーバーからマスター制御アプリケーション

マスター制御アプリケーションからマスター・トランシーバー

起動コンフィギュレーション

マスター制御アプリケーションがスマート・トランシーバー起動メッセージを受信した後、起動コンフィギュレーション・メッセージをスマート・トランシーバー・チップに送ることができる。このメッセージは、スマート・トランシーバーに、それが用いているＳＰＩプロトコル・バージョンは何かと、それが望む出力クロック速度とを知らせることができる。応答メッセージは、デバッギング・チェックのために送られたコンフィギュレーション・データーを収蔵することができる。長さが０のコマンド（ペイロードがない）をマスター制御アプリケーションが送ることによって、現在の起動コンフィギュレーションをポールすることができる。
マスター制御アプリケーションからスマート・トランシーバー

スマート・トランシーバーからマスター制御アプリケーション

応答は、起動コマンドが正しく受信されたときにその確認として、起動コマンドと共に送られたデーターを収蔵することに注意すること。

ＳＰＩドライバが用いるＳＰＩプロトコルのバージョンが、チップがサポートするバージョンとは異なる場合、チップは、要求されたバージョンではなく、それがサポートするバージョンを返すことができる。チップが動作することができるバージョンを用いるのは、ドライバの責務である。
モード制御

マスター制御アプリケーションは、スマート・トランシーバーの動作に対して究極的な制御を行う。モード・コマンドは、マスター制御アプリケーションが、スマート・トランシーバーのモードを変更することを可能にする。異なるリセット・モードは、既知の状態から開始できるように、スマート・トランシーバー・チップをリセットする。電力モードは、スマート・トランシーバーの電源を切るか、またはそれを別の電力モードにする。モード変更メッセージは、モード変更が行われる前に、スマート・トランシーバーによって承認することができる。

モード制御ポールは、マスター制御アプリケーションに対するキープ・アライブ」メッセージを、スマート・トランシーバーが未だ異なるモードで正しく動作していると判断するため用いるための、正しい選択肢である。
マスター制御アプリケーションからスマート・トランシーバー

マスター制御アプリケーションは、このコマンドをスマート・トランシーバーに送って、モードを変更することまたは現行のモードを要求することができる。ノー・レングス(no length)が送られた場合、要求を現モードのポールと見なすことができる。

スマート・トランシーバーからマスター制御アプリケーション

モード制御応答メッセージは、ＳＰＩインターフェースにおいて、モード制御要求の受信の１ｍ秒以内に得ることができる。
メッセージ・バッファ警告

通例、マスター制御アプリケーションは、スマート・トランシーバーが扱うことができない程速くメッセージを送ることはできない。しかしながら、スマート・トランシーバー・バッファが埋まり始めた場合、エラー・メッセージが定められる。バッファが殆ど満杯になったことをマスター制御アプリケーションに警告するためのメッセージが１つある。バッファ・タイプについての警告を解消するための別のメッセージがある。加えて、最後のメッセージが拒否されたことをスマート・トランシーバーがマスター制御アプリケーションに通知するためのメッセージがある。拒否メッセージは、マスター制御アプリケーションがバッファ警告を無視し、そのバッファにデーターをあらゆる方法で送ったときにのみ送られ、あるいは現在のアプリケーションまたは状態にとってメッセージが間違っているときに送られる。
スマート・トランシーバーからマスター制御アプリケーションへのバッファ警告

このメッセージは、１つまたは複数のバッファが殆どいっぱいになったときにスマート・トランシーバーによって送ることができる。スマート・トランシーバーのファームウェアは、少なくとも１つ以上のメッセージ（現在受信中のものは含まない）の余裕が未だあるときに警告を送ることができるように書き込むことができる。このメッセージが送られるといつでも、警告ステータスにある全てのバッファの完全なリストを送ることができる。マスター制御アプリケーションがバッファ警告を受け取ると、この警告が解消されるまで、そのタイプのバッファをもはや送ってはならない。

スマート・トランシーバーからマスター制御アプリケーションへのバッファ警告の解消

このメッセージは、警告中のバッファが十分に消去されてより多くのメッセージが許容されるようになったときに送ることができる。ペイロードは、消去されているバッファ・タイプの各々をリストに纏めることができる。これは、以前に警告タイプが設定されたことがあり、今では書き込んでも安全なバッファだけをリストに纏めることができる。

スマート・トランシーバーからマスター制御アプリーションへのメッセージ不達(message fail)

マスター制御アプリケーションの符号化(coding)が正しければ、このメッセージが送られることはないはずであるが、マスター制御アプリケーションがバッファ警告メッセージを無視し、スマート・トランシーバーが受け入れることができないバッファを送った場合、または現在のアプリケーションまたは状態にはメッセージが誤りである場合には、このメッセージが送られることがある。

ＥＥＰＲＯＭコマンド

マスター制御アプリケーションは、データーをＥＥＰＲＯＭに書き込むこと、またはデーターをＥＥＰＲＯＭから読み出すことを要求することができる。メッセージは、３２バイトのデーターに制限されており、一度に１つのメッセージしか保留していることができない（１つのＥＥＰＲＯＭ読み出しまたは１つの書き込みメッセージ）。
ＥＥＰＲＯＭ読み出し

マスター制御アプリケーションは、ＥＥＰＲＯＭからのデーターを要求することができる。これは、読み出し要求によって行われる。その後のある時点で、スマート・トランシーバー・チップがＥＥＰＲＯＭを読み出し終えたとき、ＥＥＰＲＯＭ読み出し応答メッセージと共にこのデーターをＳＰＩを通じて戻すことができる。双方のメッセージは、ＥＥＰＲＯＭオフセットおよび読み出し長を収蔵しており、これによって、マスター制御アプリケーションは、その保留中の読み出し要求を応答と同期させることが可能になる。エラーがある場合、スマート・トランシーバーは、ＥＥＰＲＯＭデーターを読み出さずに、要求を返すことができる。このメッセージングによって、マスター制御アプリケーションのプロセッサーは、返送すべきメッセージにコンテキストを入れることが可能になる。これは、マスター制御アプリケーション・プロセッサーが望む任意の方法で用いることができる。例えば、これは、応答メッセージが受信されるときに再開するタスク番号とすることができる。
マスター制御アプリケーションからスマート・トランシーバーへのＥＥＰＲＯＭ読み出し要求

スマート・トランシーバーからマスター制御アプリケーションへのＥＥＰＲＯＭ読み出し応答

ＥＥＰＲＯＭ書き込み

マスター制御アプリケーションは、不揮発性データーをＥＥＰＲＯＭにセーブすることができる。これは、書き込み要求によって行われる。その後のある時点で、スマート・トランシーバー・チップがＥＥＰＲＯＭにデーターを書き込みその妥当性を判断した後、ＳＰＩチャネルを通じて応答メッセージを返送して、マスター制御アプリケーションに、それが行われたことを知らせることができる。双方のメッセージは、ＥＥＰＲＯＭオフセットおよび読み出した長さを収蔵しており、マスター制御アプリケーションは、その保留中の書き込み要求を応答と同期させることが可能になる。エラーがある場合、スマート・トランシーバーはエラー・ステータスと共に要求を戻すことができる。このメッセージングによって、マスター制御アプリケーション・プロセッサーは、返送すべきメッセージにコンテキストを入れることが可能になる。これは、マスター制御アプリケーション・プロセッサーが望む任意の方法で用いることができる。例えば、これは、応答メッセージが受信されるときに再開するタスク番号とすることができる。書き込まれたデーターは、応答の中で戻すことができるので、マスター制御アプリケーションは、正しいデーターが書き込まれたことを検証することができる。
マスター制御アプリケーションからスマート・トランシーバーへのＥＥＰＲＯＭ書き込み要求

スマート・トランシーバーからマスター制御アプリケーションへのＥＥＰＲＯＭ書き込み応答

スマート・トランシーバーのファームウェアには、現在の音声タイプがわかると良い２つの部分がある。
１．リンク・レイヤは、どのタイプのデーターが上流に送られているのか知らなければならない場合がある。
２．スマート・トランシーバーのハードウェアが音声符号化／復号を行う場合、アプリケーションは符号化に用いるコーディング・タイプ(coding type)がわかるとよい。

このコメントが送信されると、スマート・トランシーバーは、必要であれば、上流経路のＨＷ符号化タイプを変更し、更に、上流音声データーにこのタイプを添付する(tag)ことができる。ペイロードなしでこのコマンドを送った場合、スマート・トランシーバーは現在のタイプを送ることができる。
マスター制御アプリケーションからスマート・トランシーバーへの音声符号化タイプ設定

スマート・トランシーバーからマスター制御アプリケーションへの音声符号化タイプ応答

ＧＰＩＯ制御

スマート・トランシーバーのＩＣは、予備のＧＰＩＯピンを有しており、これらのピンはマスター制御アプリケーション・チップが入力または出力のために用いることができる。スマート・トランシーバーの初期化の時点において、予備用ＧＰＩＯの全てを入力として構成することができ、それらのステータスは、スマート・トランシーバー起動メッセージの一部として送ることができる。メッセージによって、マスター制御アプリケーションはＧＰＩＯを構成すること、そしてＧＰＩＯに対して読み出しまたは書き込みを行うことが可能になる。入力を構成する場合、マスター制御アプリケーションは、要求された入力が変化したときはいつでも、ＧＰＩＯステータス・メッセージを送るように要求することができる。これらのメッセージは、整列させて、４ｍ秒以内にマスター制御アプリケーションに送るように準備することができる。ＧＰＩＯステータス・メッセージは、バッファおよびモード・メッセージよりも優先順位が低い。

全てのＧＰＩＯコマンドにおいて、ビット０はＧＰＩＯ０にマッピングし、ビット１はＧＰＩＯ１にマッピングする等となる。
マスター制御アプリケーションからスマート・トランスレートシーバへのＧＰＩＯ設定

マスター制御アプリケーションがスマート・トランシーバーのＧＰＩＯを用いたい場合、これらを正しく設定しなければならない。入力および出力を決定するために、別個のビット・マップがある。

スマート・トランシーバーからマスター制御アプリケーションへのＧＰＩＯ設定応答

マスター制御アプリケーションからマスター・トランシーバーへのＧＰＩＯ読み出し／書き込み

スマート・トランシーバーからマスター制御アプリケーションへのＧＰＩＯステータス／応答

ワイヤレス・フレーム同期

アプリケーションは、フレーム同期メッセージをフレームにおける任意の位置になるように設定することができる。デフォルトでは、フレーム同期メッセージをオフにすることができる。イネーブルされると、フレーム同期メッセージをＳＰＩバッファにロードし、フレーム・ビット・クロックがトリガ値に達したときに、準備を整えることができる。
マスター制御アプリケーションからスマート・トランシーバーへのフレーム同期設定要求

スマート・トランシーバーからマスター制御アプリケーションへのフレーム同期設定応答

スマート・トランシーバーからマスター制御アプリケーションへのフレーム同期メッセージ

ワイヤレス音声同期

ＳＰＩポートを通過する際のスループットを向上させるために、上流および下流の音声データーを同期させて、双方のパケット・タイプが同時に全二重接続を通じて転送されるようにすることが可能である。

音声同期設定要求メッセージは、この機構(feature)をイネーブルするために用いることができる。
マスター制御アプリケーションからスマート・トランシーバーへの音声同期設定要求

デフォルトでは、このメッセージをイネーブルすると、フレーム同期メッセージをディスエーブルすることができる。このメッセージをディスエーブルすると、フレーム同期メッセージをイネーブルすることができる。

スマート・トランシーバーからマスター制御アプリケーションへの音声同期設定応答

スマート・トランシーバーからマスター制御アプリケーションへの音声同期メッセージ

マスター制御アプリケーションは、このメッセージを用いて、ＳＰＩインターフェースを通る全二重トランスポートを開始することができる。

コンフィギュレーション・メッセージング

コンフィギュレーション・メッセージは、マスター制御アプリケーションがスマート・トランシーバー・チップを、その特定のオプションを有する正しいアプリケーションに設定することを可能にする。
アプリケーションおよびオプションの設定

このメカニズムは、マスター制御アプリケーションが正しいアプリケーションおよびそのための種々のオプションを選択することを可能にする。
マスター制御アプリケーションからスマート・トランシーバー・アプリケーションへのコンフィギュレーション設定−サード・パーティ

無効のオプション・フラグまたは音声パケット・サイズ・フィールドがスマート・トランシーバーによって検出された場合、有効なアプリケーション・コンフィギュレーション・コマンドを受信するまで、アプリケーション未定状態にい続ければよい。
ホスト接続

一旦マスター制御アプリケーションの準備が整うと、ホストへの接続開始を試すことができる。ゲームパッド・アプリケーションでは、データー接続を最初に確立することができ、一旦これが行われると、ヘッドセットが差し込まれていれば、音声接続の確立を試すことができる。一旦接続が確立されると、次の３つの異なるインスタンス(instance)のために、これらを落とす(drop)ことができる。
１．マスター制御アプリケーションがリンク・ドロップを要求する。この場合、リンクを落とし、無線(radio)をオフに切り換えることができる。マスター制御アプリケーションは、無線をオンに切り替えて新たなリンクを再確立するためには、新たな接続要求を発行することができる。
２．ホストがリンク・ドロップを要求する。この場合、リンクを落とすことができ、無線をオフに切り換えることができる。マスター制御アプリケーションには、接続が落ちたことおよび無線がオフになったことを通知することができる。マスター制御アプリケーションは、無線をオンに切り換えて、新たなリンクを再確立するためには新たな接続要求を発行することができる。
３．ホストとの同期が失われる。この場合、リンクを落とすことができ、無線をオフに切り換えることができる。マスター制御アプリケーションには、接続が落ちたことおよび無線がオフになったことを通知することができる。マスター制御アプリケーションは、無線をオンに切り換えて、新たなリンクを再確立するためには新たな接続要求を発行しなければならない場合がある。
データー接続要求

一旦アプリケーションがアップして実行すると、スマート・トランシーバーにホストに接続するように依頼することができる。スマート・トランシーバー・チップは、プロトコル規則を用いてホストを選択し、ワイヤレス・スロットを選択することができる。接続プロセスが開始すると直ぐに、ホストは接続要求応答を返すことができる。一旦スロットが得られると、接続ステータス報告を送ることができる。マスター制御アプリケーションが接続を落としたい場合、アクション(Action)を「接続を落とす」に設定し、このメッセージを送ることができる。スマート・トランシーバーは接続を落とし、無線をオフに切り換えることができる。「接続ドロップ」応答を返すことができる。加えて、リンク・ステータス・メッセージを、「マスター制御アプリケーション要求毎に落とされたスロット」というリンク・ステータスと共に送り、次いで「無線オフ」のリンク・ステータスを送ることができる。

マスター制御アプリケーションは、リンクを獲得したことを示すリンク・ステータス・メッセージを受信する前に、転送すべきいかなるデーターも送ってはならない。そうした場合、データーは流出して(flush)、送られなくなる場合もある。
マスター制御アプリケーションからスマート・トランシーバーへのデーター接続要求

このコマンドは初期報告のためのフィールドを含むことを注記しておく。

スマート・トランシーバーからマスター制御アプリケーションへのデーター接続応答

音声接続要求

一旦アプリケーションがアップして実行し、ヘッドセットを差し込んで、データー接続が得られたなら、マスター制御アプリケーションはスマート・トランシーバーに音声接続を依頼することができる。スマート・トランシーバー・チップは、ゲームパッド音声プロトコル規則を用いて、ワイヤレス・スロットを選択することができる。接続プロセスが開始すると直ぐに、ホストは接続要求応答を返送することができる。一旦スロットが得られると、接続ステータス報告を送ることができる。
マスター制御アプリケーションからスマート・トランシーバーへの音声接続要求

スマート・トランシーバーからマスター制御アプリケーションへの音声接続応答

リンク・ステータス

マスター制御アプリケーションは、リンク・ステータスを問い合わせたい場合がある。加えて、スマート・トランシーバー・アプリケーションは、リンク・ステータスが変化したときに、メッセージを送りたい場合もある。
音声スロット可用性
マスター制御アプリケーションからスマート・トランシーバーへのリンク・ステータス要求

スマート・トランシーバーからマスター制御アプリケーションへのリンク・ステータス

コントローラー・バッファ転送

一旦アプリケーションがアップして実行し、無線リンクが得られると、転送の殆どは、送るベきデーターおよび受信したデーターのためのバッファ転送となる。プロトコルにおいて定められている各データー・タイプは、それ自体の１組のバッファを有する。上流メッセージにおいて、マスター制御アプリケーションがバッファを送ることができるのは、それらを有するからである。特定のデーター・タイプに対するバッファの割り当てが少ない場合、スマート・トランシーバー・チップは、少ないバッファ・タイプの警告を送ることができる。マスター制御アプリケーションは、「警告クリア」を得るまでは、そのタイプのバッファを１つだけ多くしか送ることができない（同時に転送されている可能性があるものも含む）。実際には、警告が決して発生しないだけの十分なバッファがあると想定する。スマート・トランシーバーがワイヤレス・チャネルからメッセージを受信すると、正しいデーター・タイプ・メッセージを用いてこれらのメッセージをマスター制御アプリケーションに送ることができる。
マスター制御アプリケーションからスマート・トラシーバ（上流）へのバッファ
コントローラー・ヘッダー報告

コントローラー・ヘッダー報告は、ワイヤレス・ヘッダーを通じて送られるステータス報告である。これらの一例は、デバイス・タイプ報告である。

コントローラー・データー

コントローラー・トランスポート

包括的報告バッファ

このバッファ・タイプは、専用のバッファ・メッセージを有していない全てのバッファ・タイプのためとすることができる。

スマート・トランシーバーからマスター制御アプリケーションへの（下流）バッファ
コントローラー・ヘッダー要求

コントローラー・データー

コントローラー・トランスポート

包括的要求バッファ

このバッファ・タイプは、逆のワイヤレス・パケット・タイプまたはサポートされていないワイヤレス・パケット・タイプの全てを扱うことができる。

音声バッファ転送

音声バッファは、規則的に１回のメッセージにおいて送ることができる最も長いデーターとすることができる。全二重バスのより良い使用を許可するために、マスター制御アプリケーションは、音声バッファを小さい断片に分割するように構成することができる。この構成は、起動時にセットすることができ、実行中にはセットすることができない。パケット０は基本タイプと見なすことができ、音声を分割しない場合、それは転送される唯一の音声パケット・タイプとなることができる。マスター制御アプリケーション・プロセッサーは、正しいデーター・タイプを音声ヘッダーに入れることができるように、スマート・トランシーバー・チップに、どのタイプのコーディングが用いられているのか知らせることができる。スマート・トランシーバーが音声符号化を実行している場合、マスター制御アプリケーションが既にセットしてあるタイプを用いることができる。スマート・トランシーバーは、ＳＰＩを通じて受信する音声パケットを追跡し、分割パケットが用いられている場合、ワイヤレス・チャネルを通じて完全なバッファが送られる前に全てのパケットが受信されたことを確認する必要がある場合もある。マスター制御アプリケーションは、それがスマート・トランシーバーから受信するデーターに対して、同様の機能を備えなければならない場合もある。
マスター制御アプリケーションからスマート・トランシーバーへの（上流）バッファ
音声ヘッダー報告

音声トランスポート

ＰＣＭ音声パケット０〜７

マスター制御アプリケーションが、音声復号および符号化を備えるように当該アプリケーションを構成した場合、これらのパケット・タイプはバッファを満たすために用いることができる。コンフィギュレーション・オプション「上流音声パケット・カウント」を用いて、どのパケットを送るのか制御することができる。コマンド・コードが異なるパケットを用いて、スマート・トランシーバーが、正しいバッファ位置を指し示すように、そのＤＭＡを設定できるようにすることができる。表４３は、ＰＣＭパケットに用いられる最大パケット・サイズを示す。

全てのＰＣＭサンプルは、１６ビット、２の補数、リトル・エンディアン・フォーマットとすることができる。これが意味するのは、最初のバイトが最初のサンプルのロー・バイトであり、２番目のバイトが最初のサンプルのハイ・バイトである等ということである。加えて、１６ビット未満のＡＤＣを用いる場合、サンプルを左に揃えるとよい。

スマート・トランシーバーからマスター制御アプリケーション（下流）バッファ
音声ヘッダー要求

音声トランスポート

ＰＣＭ音声パケット０〜７

マスター制御アプリケーションが、音声復号および符号化を備えるように当該アプリケーションを構成した場合、これらのパケット・タイプを送ることができる。コンフィギュレーション・オプション「下流音声パケット・カウント」を用いて、パケットをいくつ送るか制御することができる。表４７は、ＰＣＭパケットに用いられる最大パケット・サイズを示す。尚、パケットは、マスター制御アプリケーション・プロセッサーに、データーＣＲＣの有効性が確認できたか否か知らせるために、ステータスのために余分なバイトを収蔵することができることを注記しておく。マスター制御アプリケーションがそのためにスマート・トランシーバーを構成した場合、「悪い」データーだけを送ることもできる。

コンフィギュレーション・メッセージング

コンフィギュレーション・メッセージは、マスター制御アプリケーションに、スマート・トランシーバー・チップを、その特定のオプションを有する正しいアプリケーションに設定することを可能にする
アプリケーションおよびオプションの設定

このメカニズムは、マスター制御アプリケーションが正しいアプリケーションおよびそのための種々のオプションを選択することを可能にする。
マスター制御アプリケーションからスマート・トランシーバー・アプリケーションへのコンフィギュレーション設定−サード・パーティ

スマート・トランシーバーからマスター制御アプリケーションへのアプリケーション・コンフィギュレーション応答

ホスト接続

一旦マスター制御アプリケーションの準備が整うと、ホストへの接続開始を試すことができる。音声デバイス・アプリケーションでは、最初にホストを検索しこれと同期を取り、次いで音声デバイス・プロトコルを用いて音声スロット接続を確立することができる。一旦接続が確立されると、次の３つの異なるインスタンス(instance)のために、これらを落とす(drop)ことができる。
１．マスター制御アプリケーションがリンク・ドロップまたは無線オフを要求する。この場合、リンクを落とすことができる。マスター制御アプリケーションが、無線オフおよびホストとの同期を要求した場合も、リンクを落とすことができ、無線をオフに切り換えることができる。いずれの場合でも、マスター制御アプリケーションは、新たなリンクを再確立するためには、新たな接続要求を発行しなければならない。
２．ホストがリンク・ドロップを要求する。この場合、リンクを落とすことができ、マスター制御アプリケーションに通知することができるが、ホストとの同期は維持することができる。これによって、ホストを検索する必要なく、今後接続を実行することが可能になる。この想定場面では、スマート・トランシーバーは、接続を試行して再確立し、そうした場合、マスター制御アプリケーションに知らせることができる。
３．ホストとの同期が失われる。この場合、スマート・トランシーバーはホストとの同期を取ろうとして、失われた接続を再確立することができる。マスター制御アプリケーションにはその推移を知らせることができるが、接続メッセージを再度送る必要はない。
音声接続要求

一旦アプリケーションがアップして実行すると、マスター制御アプリケーションはスマート・トランシーバーに音声接続を依頼することができる。スマート・トランシーバー・チップは、音声デバイス・プロトコル規則を用いてワイヤレス・スロットを選択することができる。接続プロセスが開始すると直ぐに、ホストは接続要求応答を返すことができる。一旦スロットが得られると、接続ステータス報告を送ることができる。バインディング情報がない場合、スマート・トランシーバーはエラー接続応答を返すことができる。
マスター制御アプリケーションからスマート・トランシーバーへの音声接続要求

スマート・トランシーバーからマスター制御アプリケーションへの音声接続応答

リンク・ステータス

マスター制御アプリケーションは、リンク・ステータスに照会したい場合がある。加えて、スマート・トランシーバー・アプリケーションは、リンク・ステータスが変化したときに、メッセージを送りたい場合もある。
音声スロット可用性
マスター制御アプリケーションからスマート・トランシーバーへのリンク・ステータス要求

スマート・トランシーバーからマスター制御アプリケーションへのリンク・ステータス

音声バッファ転送

音声バッファは、規則的に１回のメッセージにおいて送ることができる最も長いデーターである。全二重バスのより良い使用を許可するために、マスター制御アプリケーションは、音声バッファを小さい断片に分割するように構成することができる。この構成は、起動時にセットすることができ、実行中にはセットすることができない。パケット０は基本タイプと見なすことができ、音声を分割しない場合、それは転送される唯一の音声パケット・タイプとなることができる。マスター制御アプリケーション・プロセッサーは、正しいデーター・タイプを音声ヘッダーに入れることができるように、スマート・トランシーバー・チップに、どのタイプのコーディングが用いられているのか知らせることができる。スマート・トランシーバーが音声符号化を実行している場合、マスター制御アプリケーションが既にセットしてあるタイプを用いることができる。スマート・トランシーバーは、ＳＰＩを通じて受信する音声パケットを追跡し、分割パケットが用いられている場合、ワイヤレス・チャネルを通じて完全なバッファが送られる前に全てのパケットが受信されたことを確認する必要がある場合もある。マスター制御アプリケーションは、それがスマート・トランシーバーから受信したデーターに対して同様の機能を設ける必要がある場合もある。
マスター制御アプリケーションからスマート・トランシーバーへの（上流）バッファ
音声ヘッダー報告

音声トランスポート

音声トランスポートは、音声デバイスにおいて、コマンドの要求およびステータスの報告に用いられる。

ＰＣＭ音声パケット０〜７

全てのＰＣＭサンプルは、１６ビット、２の補数、リトル・エンディアン・フォーマットとすることができる。これが意味するのは、最初のバイトが最初のサンプルのロー・バイトであり、２番目のバイトが最初のサンプルのハイ・バイトである等ということである。加えて、１６ビット未満のＡＤＣを用いる場合、サンプルを左に揃えるとよい。

スマート・トランシーバーからマスター制御アプリケーションへの（下流）バッファ
音声ヘッダー要求

音声トランスポート

音声デバイスにおいて、コマンド要求およびステータス報告のために、音声トランスポートを用いることができる。

ＰＣＭ音声パケット０〜７

マスター制御アプリケーションが、音声復号および符号化を備えるように当該アプリケーションを構成した場合、これらのパケット・タイプが送られる。コンフィギュレーション・オプション「下流音声パケット・カウント」を用いて、パケットをいくつ送るか制御することができる。表４７は、ＰＣＭパケットに用いられる最大パケット・サイズを示す。尚、パケットは、マスター制御アプリケーション・プロセッサーに、データーＣＲＣの有効性が確認できたか否か知らせるために、ステータスのために余分なバイトを収蔵することができることを注記しておく。

補足資料Ｂ
データー・サービスの要求機能

ＡＰＩ要求関数は、ＡＰＩレベルでの通信スタックにおけるアクションを開始するために、アプリケーションからコールすることができる。ＡＰＩ機能の前および後ろに_reqを付けることができる。

Xair_MdDataReq

Xair_MdConnectReq

Xair_MdDisconnectReq

データー・サービスについてのイベント
Xair_MdDatalnd

Xair_MdConnectConf

Xair_MdDisconnectConf

Xair_MdDisconnectlnd

Xair音声サービスのための要求機能
Xair_MvConnectReq

Xair_MvDisconnectReq

Xair音声サービスについてのイベント
Xair_MvTxRxInd

Xair_MvConnectConf

Xair_MvDisconnectConf

Xair_MvDisconnectlnd

Xair_MvSampleRatelnd

Xair管理サービスのための要求機能
Xair_MmInitReq

Xair_MmStartReq

Xair_MmResetReq

Xair_MmPowerDownReq

Xair_MmBindReq

Xair_MmstopBindReq

Xair_MmReadReq

Xair_MmWriteReq

Xair管理サービスについてのイベント
Xair_Mmsmart TransceiverComReadyInd

Xair_MmStartConf

Xair_MmRResetInd

Xair_MmBindConf

Xair_MmStopBindConf

Xair_MmReadConf

Xair_MmWriteConf

Xair_MmSyncInd

Xair GPIOサービスのための要求機能
Xair_MgIoReq

Xair GPIOサービスについてのイベント
Xair_MgIoConf

Xair_MgIoInd

Xair_MpSendRawSpiDataReq

イベントおよびバッファ処理機能
Xair_GetEvent

Xair_ReadEventDetails

Xair_PutVoiceBuffer

Xair_GetVoiceBuffer

ＡＰＩのコンフィギュレーションおよび設計
ＡＰＩの全てのコンフィギュレーションは、"xair_api_xib.h" ヘッダー・ファイルにおける定義によって行うことができる。ここでは、完全なＡＰＩは、マスター制御アプリケーション・システムにおいて利用可能な資源に関して調節可能とすることができる。
ＲＸ／ＴＸデーターを整列させるためのバッファの数は、XIB_TX_DATA_QUEUE_SIZE、XIB_EVENT_QUEUE_SIZE、XIB_RX_DATA_QUEUE_SIZE によって調節可能である。したがって、マスター制御アプリケーション・システムの利用可能なメモリー空間に関して、用いられるキュー・サイズを調節することができる。
用いられるＥＥＰＲＯＭのタイプおよび記憶サイズは、XIB_EEPROM_TYPE、
XIB_PERSISTENT_STORE_SIZE によって構成可能である。
ＳＰＩモードは、XIB_SPI_MODE によってセットされる。
モード０．．．３をセットすることができる。デフォルトは、ＳＰＩモード０である。
スマート・トランシーバー・チップによって供給される出力クロックの周波数は、XIB_PROVIDED_CLOCK_FREQUENCY によってセットすることができる。クロックを１２、２４、または４８ＭＨｚにセットすることができる。デフォルトは１２ＭＨｚである。
作業アプリケーションのタイプは、XIB_APPLICATION_TYPE によってセットされる。データー、音声、または双方をセットすることができる。デフォルトはデーターである。
統合する音声デバイスの能力は、XIB_VOICE_ABILITY によってセットされる。イネーブルまたはディスエーブルにセットすることができる。デフォルトはイネーブルである。
スマート・トランシーバーが発生するフレーム同期メッセージの位置は、XIB_SYNC_EVENT_POSITION によって調節することができる。SYNC_EVENT_OFF、SYNC_EVENT_FRAMESTART、SYNC_EVENT_BROADCAST またはSYNC_EVENT_RX_FINISHEDにセットすることができる。デフォルトは、SYNC_EVENT_FRAMESTARTである。
使用される上流音声符号化タイプは、XIB_UPSTREAM_VOICE_ENCODING_TYPE によってセットする。
音声同期メッセージの発生は、XIB_VOICE_SYNC によって設定することができる。イネーブルまたはディスエーブルにセットすることができる。デフォルトはイネーブルである。
スマート・トランシーバー・チップの初期ＧＰＩＯ設定値は、XIB_GPIO_INPUTSによってセットすることができる。

/**< １６ビット、リトル・エンディアンのクリアされたビットは無視を意味し、セットされたビットは入力を意味する */
- XIB_GPIO_INTERRUPT_MASK
/**< １６ビット、リトル・エンディアンのクリアされたビットは無視を意味し、セットされたビットはXair_MgIoIndイベントが入力において受信されたことを意味する */
- XIB_GPIO_OUTPUTS
/**< １６ビット、リトル・エンディアンのクリアされたビットは無視を意味し、セットされたビットはこのビットが出力であることを意味する */
- XIB_GPIO_OUTPUT_TYPE
/**< １６ビット、リトル・エンディアンのクリアされたビットは、これがプッシュ／プルであることを意味し、セットされたビットはこれがオープン・ドレインであることを意味する */
- XIB_GPIO_OUTPUT_INIT
/**< １６ビット、リトル・エンディアン、初期出力状態*/
- XIB_GPIO_INPUT_TYPE
/**< ３２ビット、ＧＰＩＯ入力ピン構成、フィールドの２ビット対を用いて、各ＧＰＩＯピンを定める */

等しいサイズのデーターおよび音声パケット・バッファは、XIB_VOICE_EQ_DATA_BUFFER によってセットする。
TRUEまたはFALSEにセットすることができる。デフォルトはTRUEである。

Claims

ワイヤレス・プロトコル・プロセッサーを含むゲーミング・システムまたはペリフェラルであって、前記ワイヤレス・プロトコル・プロセッサーが、シリアル・ペリフェラル・インターフェース（ＳＰＩ）リンクを通じて全二重コマンドおよびデーター・メッセージング・プロトコルを提供するように構成された回路を含み、該回路は、ヘッダーと可変長ペイロードとを含むデーター・パケットを形成するように構成され、前記ヘッダーはコマンド・フィールドと長さフィールドとを含み、該長さフィールドは前記可変長ペイロードのサイズを表し、前記長さフィールドは、前記コマンド・フィールドの内容に依存し、前記コマンド・フィールドは、前記ゲーミング・システムまたはペリフェラルにおいて実行する複数のソフトウェア・アプリケーションで動作するように構成された第１組のコマンドと、前記ゲーミング・システムまたはペリフェラルにおいて実行する特定のソフトウェア・アプリケーションのみで動作するように構成された第２組のコマンドと、を示し、前記第１組のコマンドと前記第２組のコマンドとは各々、製品タイプによって決まる機能に関連した、ゲーミング・システムまたはペリフェラル。
請求項１記載のシステムにおいて、前記ＳＰＩリンクを通じたトランザクションは、前記データー・パケットをスレーブ・デバイスに送信するマスター・デバイスによって開始される、システム。
請求項２記載のシステムにおいて、前記回路は、更に、前記スレーブ・デバイスから応答を受信するように構成され、前記応答は、前記マスター・デバイスからの要求の結果、前記コマンドへの遵守、および以前の要求からのイベントの発生の指示のうち少なくとも１つを含む、システム。
請求項１記載のシステムにおいて、前記回路は、更に、前記機能を初期化期間中に選択するように構成された、システム。
請求項１記載のシステムにおいて、前記第１組のコマンドは、
コマンドまたは応答非送出、モード制御、音声同期設定要求、音声コーディング・タイプの設定、リンク・ステータス要求、ＥＥＰＲＯＭ読み出し要求、ＥＥＰＲＯＭ書き込み要求、起動コンフィギュレーション・メッセージ、トランシーバー起動メッセージ要求、ワイヤレス・フレーム同期設定、トランスポート要求の検査、ワイヤレス・スロット・デバッグ・メッセージの要求、ＧＰＩＯ設定、ＧＰＩＯ読み出し／書き込みメッセージ、マスターＥＥＰＲＯＭ読み出し応答、およびマスターＥＥＰＲＯＭ書き込み応答、
のうち少なくとも１つを含む、システム。
請求項１記載のシステムにおいて、前記第１組のコマンドは、
メッセージ失敗、モード制御応答、バッファ警告、バッファ警告解消、音声同期設定応答、音声同期メッセージ、音声コーディング・タイプ応答、リンク・ステータス、ＥＥＰＲＯＭ読み出し応答、ＥＥＰＲＯＭ書き込み応答、起動コンフィギュレーション応答、スマート・トランシーバー起動メッセージ、ワイヤレス・フレーム同期設定応答、ワイヤレス・フレーム同期、検査、
のうち少なくとも１つを含む、システム。
請求項１記載のシステムであって、更に、前記ＳＰＩドライバを通じて前記ワイヤレス・プロトコル・プロセッサーへのアクセスを与えるように構成された回路を含み、前記ワイヤレス・プロトコル・プロセッサーへのアクセスを提供するように構成された前記回路は、ワイヤレス・リンクを通じて固定サイズのデーター・パケットを送信及び受信するデーター・サービスと、前記ワイヤレス・リンクを通じて音声パケットを送信および受信する音声サービスと、他のサービスのパラメータを構成するレイヤ管理サービスと、前記ワイヤレス・プロトコル・プロセッサーの予備ピンにおいてビット指向入力／出力を実行するＧＰＩＯサービスと、前記ワイヤレス・プロトコル・プロセッサーの製品検査インターフェースへのアクセスを与える製品検査サービスとを含む、システム。
シリアル・ペリフェラル・インターフェースを通じて全二重コマンドおよびデーター・メッセージング・プロトコルを提供する方法であって、
ヘッダーと可変長のペイロードとを含む少なくとも１つのデーター・パケットを形成するステップであって、前記ヘッダーはコマンド・フィールドと長さフィールドとを含み、該長さフィールドは前記可変長ペイロードのサイズを表し、前記長さフィールドは、前記コマンド・フィールドの内容に依存し、前記コマンド・フィールドは、ゲーミング・システムまたはペリフェラルにおいて実行する複数のソフトウェア・アプリケーションで動作するように構成された第１組のコマンドと、前記ゲーミング・システムまたはペリフェラルにおいて実行する特定のソフトウェア・アプリケーションのみで動作するように構成された第２組のコマンドと、を示す、ステップと、
前記少なくとも１つのデーター・パケットをスレーブ・デバイスに送信することによって、トランザクションを開始するステップと、
前記少なくとも１つのデーター・パケットに対して応答を送信するステップと、
を含む、方法。
請求項８記載の方法において、トランザクションは、前記データー・パケットを送信するマスター・デバイスによって開始される、方法。
請求項９記載の方法において、前記応答は、前記マスター・デバイスからの要求の結果、前記コマンドへの遵守、および以前の要求からのイベントの発生の指示のうち少なくとも１つを含む、方法。
請求項８記載の方法であって、更に、機能を選択し、コマンド組を前記機能の関数として提供するステップを含む、方法。
請求項１１記載の方法であって、前記機能は初期化期間中に選択され、前記機能は製品タイプによって決定される、方法。
請求項８記載の方法において、前記第１組のコマンドは、
コマンドまたは応答非送出、モード制御、音声同期設定要求、音声コーディング・タイプの設定、リンク・ステータス要求、ＥＥＰＲＯＭ読み出し要求、ＥＥＰＲＯＭ書き込み要求、起動コンフィギュレーション・メッセージ、トランシーバー起動メッセージ要求、ワイヤレス・フレーム同期設定、トランスポート要求の検査、ワイヤレス・スロット・デバッグ・メッセージの要求、ＧＰＩＯ設定、ＧＰＩＯ読み出し／書き込みメッセージ、マスターＥＥＰＲＯＭ読み出し応答、およびマスターＥＥＰＲＯＭ書き込み応答、
のうち少なくとも１つを含む、方法。
請求項８記載の方法において、前記第１組のコマンドは、
メッセージ失敗、モード制御応答、バッファ警告、バッファ警告解消、音声同期設定応答、音声同期メッセージ、音声コーディング・タイプ応答、リンク・ステータス、ＥＥＰＲＯＭ読み出し応答、ＥＥＰＲＯＭ書き込み応答、起動コンフィギュレーション応答、スマート・トランシーバー起動メッセージ、ワイヤレス・フレーム同期設定応答、ワイヤレス・フレーム同期、トランスポート検査応答、ＧＰＩＯ設定応答／ステータス、およびＧＰＩＯステータス／応答メッセージ、
のうち少なくとも１つを含む、方法。
請求項８記載の方法において、前記アプリケーションは、ビデオ・ゲーム・コントローラー・アプリケーション、音声アプリケーション、ビデオ・ゲーム・コンソール・アプリのうちの少なくとも１つを含む、方法。