上記のような接続でテスト。PCの代わりにUSB HOST shieldをつなげて、飛んでくるデータをウォッチしてみた。本来の回路であるADKではATmega2560からHIDファームを焼きこんだATmega8U2との間をシリアルでウォッチ。
　ADK側のウォッチポイント1はすごく正しくデータが流れていた。

　が、PCの代わりにおいたウォッチポイント2では、キーを打っている間は正しいデータが受信されているものの、しばらくキー入力がないと妙なデータが流れ込んでいた。HIDのレポートのはずなのだがBinaryで50 6F 6C 6C 3A 46 46 0D 0A。
0D 0A がある時点で改行コードかってことはASCIIか？ってことでその前は「Poll:FF」。そもそもHID reportはASCIIコードじゃないし、1レポートは1キーだ(実際は同時押し6キーまではありですが)。図のATmeaga8U2以降でこのデータが追加されている。しかもこのデータの通信は不安定で、場合によってビットがずれたりしている。これをそのままPCに繋ぐとモディファイヤが絡むと非常に厄介な誤動作になる。(実際体験して、速攻でUSBケーブル抜きましたし。)
　とりあえず、おかしなHID Reportになっているから安定しなかったわけで。
　なぜ、時間をおいた時に上流から流れてきていないものが出力されて来ているのかを考えたい。ADK→ArduinoUNOのUSB部分の通信を、ドライバが復活したプロトコル・アナライザLAP-Cで見てみようと思う。あとUSB HOST Shieldのライブラリと読んでるとやたらとSerial.Printが入ってるのが気になる。ATmeaga8U2のHID化ファームは多分白だと思っている。

　なんとなくですが、USB付きのPICを使わなくても片付きそうな気がしてる。でも、USB HOST shieldだけに問題があった場合はハマるかな。

[ちょっと置いて]
　ADKのATmega2560からATmega8U2の間にシリアルを置いてみたら「Poll:FF」やら「Poll:1」をシリアルに流してるのが確認できた。ライブラリを修正すれば治りそうだ。

[さらにあと]
　確かにライブラリ内でデバッグ用にSerial決め打ちでデバッグ文字を出してる部分はあったけども。それだけでなく、純粋にUSBホストとして受け取っているレポートがあった。けど、よくわからん。しばらくキーボードをいじらないと出てくるので接続確認のポーリングなのかしらん。07 00 1dで始まるReport。それ以降の部分は適度に変わるのでなんとも。仮にこの文字列のReportは無視するようにしたら、とりあえず異常動作をすることがなくなっている。一部、CAPS LOCKのランプが逆になる事もあるが、その辺はキーコンビネーションのバリエーション対策で解決できそうだ。もしかしたらこれで行けたのかしらん？
　明日状況を明確にして日本語キーボードのマシンにつなげて安定化できたら、小さい回路で実現する方向を試します。あとは、スイッチでモードを切り替えられるようにして、クロージャーに入れて・・・と。やっと終わりが見えてきたかも。