あいまいさが生む誤解
エンジニアリングにおける多くの取り組みと同じように、このプロジェクトでもあいまいさから生じる誤解があった。最初にそのような「早合点」が起こった理由は、USB接続用の電気・論理インターフェースがそれぞれ非対称であったからだ。このプロジェクトの目的に合ったUSBチップの供給元を探す際には、機能レベルで何を実証したいのかということだけを話し合った。
今回使用するターゲットボードは、ネットワークへのイーサネット接続をサポートするだけでなく、USBデバイスのホストとしても動作しなくてはならない。そのため、ターゲットボードにはUSBホストポートが搭載されている必要があった。いくつかのチップベンダーとミーティングした結果、USBとイーサネットの両方をサポートするプロセッサと開発ボードが見つかったが、そのチップとボードはまだ最終開発段階にあった。しかし、多少待ったところでプロジェクトのスケジュールにさしたる影響はないように思われたのと、他の選択肢もなかったので、その最新のプロセッサとボードを使うことにした。
そのプロセッサにはARM7が搭載されていた。最新のデバイスとボードを使用するメリットの1つは、小規模なリアルタイムOS（operating system）用のポートがすでに搭載されているため、シンプルなOSアーキテクチャを使用できることだ。OSがあれば基盤となるハードウエアを抽象化できるため、複数のプロジェクトを抱えるアプリケーション開発者の生産性を向上できるが、今回のプロジェクトはアプリケーション開発者が通常行っているより下位レベルの1回限りの取り組みであるため、そのような抽象化に意味はなかった。実際、大規模なOSの場合はインターフェースやアーキテクチャを理解するまでに時間がかかり、プロジェクトを複雑にするだけだ。
チップとボードの開発は計画どおりに進められていたが、ボードの納入直前になって改めてデータシートを見直してみると、早くも大きな勘違いをしていたことに気が付いた。チップは同一機器上でイーサネットとUSBの両方をサポートしているものの、搭載されているのはUSBデバイスポートだけで、USBホストポートはなかった。USBデバイスポートはUSBホストポートに接続できても別のUSBデバイスポートに接続できないのだから、このままでは使えない。我々はすぐ、Atmel社のAT91 RM9200EK評価キットに付属しているARM9搭載プロセッサに乗り換えた。
この変更で数週間の時間が無駄になっただけでなく、プロジェクトも複雑になった。OSがWindows CEかLinuxに限定されたため、OSアーキテクチャが当初予定していたよりも大規模で複雑なものになってしまった。我々はWindows CEを選択した。ツール群が豊富にあることと、デスクトップ部分ではWindowsのUSBサポートを使用するつもりだったからだ。残念ながらこの選択の結果、我々のオフィスがあるカリフォルニアとAtmel社の技術サポートセンターがあるフランスとの時差のせいでトラブルシューティングに時間がかかってしまった。
ARM9プロセッサコア搭載の評価キットが到着し、プロジェクトが再開された。しかし、ボードを組み立てる過程で、あいまいさがいかに間違った推測を生むかということを改めて思い知らされることになった。Windows CE Platform Builder 5.0、ActiveSync 3.7、Embedded Visual C++ 4.0 sp4、AT 91RM9200EK BSP for Platform Builderをデスクトップワークステーションにインストールする必要があった。AT91RM9200EKターゲット用のCEイメージを作成するのは難しくはなかったが、いくつものステップを踏まなくてはならなかった。
Windows CEはプログラムが大きすぎて組み込めないため、3段階のプロセスで評価ボードにロードされる。 第一段階では、ブートローダーがシリアルデータフラッシュからSRAMにロードされ、実行される。シリアル接続経由で確立・構成された後、ブートローダーはイーサネット接続経由でWindows CEイメージをSDRAMにロードして起動する。最後に、Windows CEイメージがSDRAM内で実行される。
まずあいまいだったのは、ブートローダーを格納するシリアルデータフラッシュカードをどこにインストールするかということだった。ボードの説明書には、カードを評価ボードの最下部にあるスロットに挿入し、ボードを起動するように書かれていた。しかし、そうするとシリアルポート上で予期しない動作が発生した。ローダーではなく「C」という文字が繰り返し表示されるのだ。このときのあいまいさは「ボード最下部の」という言葉にあった。説明書にボードの図がまったく載っていなかったのも良くなかった。最終的には、ボードの前面にあるスロットの裏側に別のスロットがあるのを発見した。データカードをボード背面のスロットに挿入することによって、シリアルデバッグセッションを正常に実行することができた。
イーサネットからWindows CEイメージのダウンロードを開始するようにローダーを設定することはできたが、ダウンロードが正しく行われているようには見えなかった。結局、評価ボードに付属していたイーサネットケーブルはクロスケーブルだったのだが、我々は評価ボードをワークステーションに直接接続せずにルーターに接続していた。ケーブルの端に付いていた小さな赤色のシールにもっと早く気付いていれば、あるいはキットにイーサネットケーブルが2本付属していればよかったのだ。ワークステーションをターゲットボードとの通信だけに使用するのならクロスケーブルでも構わないが、今回は1台のワークステーションですべてをまかなおうとネットワークにも接続した。
無駄な時間を費やしたもう一つのトラブルは、USBポートからWindows CE下でActiveSync接続を確立しようとしたときに起こった。ActiveSync接続のトラブルを経験したのはこのプロジェクトが初めてではなかった＊2)。
LAN経由でUSBに接続する
プロジェクトが開始されてから、イーサネットLAN経由でUSBデバイスをMacまたはPCに接続できるようにするUSBサーバー（型式US-4A）が米Keyspan社から提供されているのを知った。この製品には組み込みマイクロコントローラと米Cypress社製USB EZ-Hostチップが搭載されている。USBサーバーを使用することは、このプロジェクトの目的にも適っていた。Keyspan社副社長兼CTO（最高技術責任者）のEric Welch氏は技術面でいろいろとサポートしてくれた。また我々は、Freescale社製プロセッサを使用したUSBデバイスの無線化を試みている米Icron社の存在も知った（別掲記事「ケーブルに代わるもの」を参照）。
ネットワークを介してデスクトップとUSBサーバー間でUSBデータを転送するには、ホストシステムとUSBサーバーに常駐するソフトウエアによってUSB接続の方法を修正する必要がある。その結果USBサーバーがUSBデバイスのホストコントローラとして動作する。混乱を避けるため、我々はKeyspan社にならってデスクトップ上のホストコントローラを「ホストクライアント」と呼ぶことにした。実際に通信している相手がUSBデバイスではなくUSBサーバーだからだ。また、USB規格で定義されているOHCI（open host controller interface）あるいはEHCI（enhanced host controller interface）の代わりに、Keyspan社で使われている「NHCI」（network host controller interface）という言葉を用いた。
ホストクライアント側では、ソフトウエアがUSBサーバーに接続されている機器をあたかもローカルで接続されているかのように並べるため、デバイスマネジャーによって各機器のクラスドライバまたはベンダードライバがロードされる。これらのドライバはMicrosoft USBスタックを利用することが想定されているため、NHCIホストソフトウエアによってこのインターフェースのエミュレーションも行わなければならない。したがって、クライアント側のソフトウエアには、デバイスがいつ接続されたのかをデバイスマネジャーに通知することと、Microsoft USBスタック通信APIのエミュレーションを行うことの2つのタスクがある。
クラスドライバまたはベンダードライバによって、リモート接続しているUSBデバイスの処理が要求されると、NHCIプロトコルはそれらの要求をパッケージ化してTCP/IP経由で送信する。ホストクライアント側のソフトウエアの最後の部分でネットワーク上のUSBサーバーが検知され、ユーザーに通知される。2つのバスエミュレータドライバを使用するなどして、USBスタックのエミュレーションからネットワーク部分を切り離すかどうかは実装次第である。たとえばMicrosoft社のドライバ開発キットには、USBデバイスをデバイスマネジャーに通知して、プラグアンドプレイのすべての電源要求を管理するカーネルのバスエミュレータドライバの記述方法を示した「toast」のサンプルが含まれている。NHCIのホストクライアント側のソフトウエアは、ローカルUSBのエミュレーションは行ってもMicrosoft USBスタックの処理は行わない。むしろ、その代わりを果たすと言える。
ホストクライアント上で動作するUSBスタックに加えて、USBサーバーにはUSBホストスタックの一部が実装されている。ローカルに接続されたデバイスのホストコントローラとなるためである。ローカルのUSBスタックによって、USBサーバーはホストシステムがネットワーク経由で送信する通常のポーリングを実行できる。USBサーバーには、ローカルの帯域幅を管理してダウンストリームデバイスを個別に処理するハブ機能がある。つまり、ダウンストリームデバイスを複数のホストクライアントに接続して共有させることができるのだ。
ホストクライアント上のNHCIソフトウエアでは、USBシステムソフトウエアのもう1つのアスペクトを修正しなくてはならない。USB上のすべての機器に同じバスの帯域幅が使用されるため、ホストコントローラが転送を管理し、各デバイスへの帯域幅の割り当てを行う。しかし、USBサーバーからのデータはネットワーク経由で転送されるため、ローカルUSBとは帯域幅を共有しない。ネットワーク経由ではローカルUSBよりも長い転送遅延が生じる可能性がある。このため、低レベルのドライバでゆとりのあるタイミング要件を設定する必要がある。クラスドライバで厳密な時間が設定されていない限りこの方法は有効だ。もし設定されているなら、ネットワーク経由でUSBデバイスをホスティングすること自体がうまくいかないか、ユーザーが期待するような結果が得られないだろう。ワイヤレス接続の転送遅延問題を考えるときには、低レベルでタイミング要件にゆとりをもたせることがもっと重要になってくる。
脚注
※2…Cravotta, Robert, "Forge ahead?," EDN, March 6, 2003, pg 50.
Copyright © ITmedia, Inc. All Rights Reserved.