2021年の振り返りとRP2040(RPi Pico)を使って分割キーボードの通信をUSBにする話
キーボード #1 Advent Calender 2021 19日目担当のせきごんです。BLE Micro Proなどキーボード関連のモジュールを色々作っています。
このブログ?のタイトルの通り一年に一個くらいしか記事を書かないせいで項目が多くまとまりが無くなってしまったので、本編では一年間をざっくりと振り返ることにして、詳細な項目はおまけとして載せておきます。 興味のある項目があったら読んでみてください。1つピックアップするならタイトルにも盛り込んだラズパイPicoで左右通信をUSBにする話がおすすめです。 一覧と概要は下記のとおりです。
- 目次
- 今年の印象的な出来事
- おまけ
- ECMX20
- 静電容量/メカニカルスイッチ両対応の基板設計
- トラックパッドIC評価用基板
- トラックパッドで遊べるマクロパッド
- Pro Micro Web Writer
- ブラウザからPro Microにファームウェアを書き込む
- Keyboard Quantizer Utility
- アクティブなアプリに応じてレイヤを切り替えたりできる常駐アプリ
- Keyboard Quantizer B
- USBキーボードをQMK対応させて無線化もできるドングル
- Keyboard Quantizer (rev.4)
- メインMCUをRP2040(ラズパイPicoのマイコン)にしたバージョンの開発経緯
- RP2040のQMK対応
- RP2040でQMKを動かすまでの話
- Pico Micro
- RP2040を使ったPro Microサイズ基板
- RP2040を直接実装するキーボードについて
- RP2040を直接実装する場合、atmega32u4とどんな違いがあるか検討
- アニメーションの再生
- OLEDでアニメーションを再生する
- Pico-PIO-USB
- 分割キーボードの左右間通信をUSBにする
- ECMX20
それでは今年を振り返っていきます。キーボードそのものという観点だと今年は昨年設計した Corne ECWL(静電容量完全無線Corne)をほぼ一年中使っていて、新しいキーボードは作りませんでした。
では記事にするネタがないのかというとそんなことはなくて、今年も色々やってました。 新作ハードとしてはトラックパッドIC評価用基板、単4電池昇圧モジュール、静電容量スイッチスキャン用モジュール、ECMX20、Keyboard Quantizer B、Keyboard Quantizer(rev.4)、Pico Micro があります。
今年の印象的な出来事
半導体不足
今年一番印象的だったのは部品の入手難対応です。。。
今年一年でBLE Micro Pro、LPME-IO、トラックボール用レべル変換基板、静電容量スキャンモジュール、単4電池昇圧基板を部品変更、改版しました。写真を撮りなおしてないものも多数あり、画像とちょっと見た目の違うものが届くかもしれませんが機能的には同等なのでご容赦ください。
部品の値上りや在庫不足は来年も続きそうなので引き続き辛そう。。。
Keyboard Quantizerのアップデート
次は昨年から展開しているKeyboard Quantizerシリーズのアップデートです。Keyboard Quantizerについて簡単に説明すると、USBキーボードやマウスの信号を変換してあたかもQMKに対応しているかのように振る舞わせられるデバイスです。自分はもっぱらマウス(トラックボール)と組み合わせて使っています。自作キーボードをお使いの方にはマウスにQMKのレイヤやマクロ機能を追加できるというと何となく便利さが伝わるのではないでしょうか。各マウス専用のソフトに依存せずどこでも使えるのも便利です。
1つ目のアップデートは無線出力対応版のKeyboard Quantizer Bです。無線出力に対応したことで、市販キーボードのQMK対応だけでなく自作キーボードの無線化にも使えるようになりました。
2つ目のアップデートはRP2040(ラズパイPicoに乗っているマイコン)を使用したKeyboard Quantizer(rev.4)です。これはどちらかというとatmega32u4の入手難に対応を迫られた形ですが、結果としてROM容量の増加、USBハブ絡みの動作の改善などを達成できました。
RP2040で遊ぶ
さて、RP2040を載せたKeyboard Quantizerのハードを設計したところで、ファームウェアを用意しなければなりません。 RP2040で動くキーボードファームウェアにはKMKやPRKがありますが、新しいファームウェアの使い方を覚えるよりは簡単そうだったのでQMKが動くようにしました。RP2040上でもQMKが動くことがわかったので、ミッドマウントのUSB-Cコネクタを使用したpro microサイズのボードを設計したり、RP2040ならではの機能を実装してみたりもしました。詳細な内容はオマケにて。
ざっくり今年を振り返るとこんな感じです。来年の計画は特にありません。また面白いテーマを見つけたら手を動かしていこうと思います。
この記事はスマホとCorne ECWLで書きました。明日の担当はびあっこさん (@Biacco42) です。
おまけ
ECMX20
ECMX20 - のぎけす屋 - BOOTH
昨年に引き続き静電容量式キーボードの検討も進めました。静電容量式自作キーボードの課題としてスイッチの種類がメカニカルスイッチに比べて少ないことがあげられます。せっかく自作するのであれば、メカニカル、静電容量含めて多くの選択肢からスイッチを選べるようにしたいところです。同じ配列でメカニカルと静電容量の両方のPCBを設計するという手もありますが、単純に手間が2倍になるので解決策としては微妙です。そこで考案したのが静電容量式ベースのメカニカル/静電容量式両対応スキャン方式です。これは次の回路で実現できます。
この回路の下半分は静電容量式スイッチを示しています。静電容量式スイッチでは円錐ばねの状態による静電容量の変化を読み取ってスイッチの変位を連続的に検出しています。回路の上半分が今回工夫したメカニカルスイッチの読み取り回路を示しています。メカニカルスイッチのON/OFFによってコンデンサの接続状態が変化するため、静電容量式スイッチと同じ方式で静電容量をスキャンすることでスイッチの変化を検出できます。静電容量の変化がコンデンサが 繋がっていない状態 or 繋がっている状態 の2値的であるため、静電容量式とは異なり連続的な変化ではなくON/OFFのみの検出となります。さらに、このコンデンサを外付けの部品ではなくPCBのパターンで実現することで、外付け部品レス(ダイオードレス)のスイッチマトリクスにできます。
実際のパターンはこちらの画像のようになります。
表面 | 裏面 |
静電容量式スイッチ用のパターンの半分の裏側にも同様の電極を用意することで、2つの電極によるコンデンサとします。容量としては6pF程度になります。
静電容量のスキャンには静電容量スキャンモジュールを利用しました。スキャンに必要な部品が一通り実装されているので、列選択のピンとAD変換用のピンを何本か接続するだけでスキャンできます。
スイッチ部の回路図。各SWについているRは実験用なので実際には不要です。静電容量スキャンモジュールを使うことでダイオードレスの回路が簡単に実現できます。 |
この方式を実装したマクロパッドがECMX20です。静電容量式スイッチを使う場合はスイッチのON/OFFを判定する閾値を調整することでAPC(Actuation Point Change)も実現できます。
その他のソフト的な工夫としてレイヤごとにVIA/REMAPからLEDを設定できるようにしたりしました。 キーボードとはあまり関係がないので省きますが、Arduinoのシリアルプロッタのようなものをブラウザ上で実現して静電容量の変化をリアルタイムで表示したりもしました。
スイッチを押下していくのに応じてグラフが変動します。キーボード以外にも使える汎用的なアプリです。 |
単純にダイオードレス・ゴーストレスのスイッチマトリクススキャン方法としても面白いと個人的には思っています。
トラックパッドIC評価用基板
トラックパッドIC(MTCH6102/IQS572)評価用基板 - のぎけす屋 - BOOTH
トラックパッドICを乗せたマクロパッドです。基本的にはそれぞれのIC(シングルタッチ版はmtch6102、マルチタッチ版はiqs572)のデータシートに従ってセンサ基板を作ったものです。
シングルタッチ版のICでは”センサ電極の上に数mmのガラスやアクリルのオーバーレイを設置すること”となっていて、自分のためした範囲では液晶保護フィルムなどでは薄すぎて意図したとおりに動作しませんでした。そこで、センサ電極を基板裏面に配置して、基板(FR-4)をオーバーレイとして基板表面から操作するようにしました。 また、I2Cの信号と電源をスペーサー経由でメイン基板から供給しています。今にして思えば上から止めるねじをプラネジにして表面のスルーホールはレジストで覆っておいたほうがよかったかなと思います。
入荷お知らせメールの登録が溜まっていますが手が回ってません。ごめんなさい。
同じICを使ったキットとして魔王様がToneScraperというキットを販売しています。こちらもどうぞ。
Pro Micro Web Writer
https://sekigon-gonnoc.github.io/promicro-web-updater/index.html
昨年BLE Micro Pro Web Configuratorを作ってみて、ブラウザからマイコンと通信できるといろいろ楽しいことがわかったので作ってみました。
Pro MicroのCaterinaブートローダと通信してWebブラウザからhexファイルを書き込めます。去年設計したGRS-70ECがEE_HANDSを使っているので左右識別のeepromデータを書き込むオプションも用意しました。
名前の通りPro Microにしか対応しておらず、Caterinaブートローダが書き込まれていないElite-Cなどでは使用できません。DFUブートローダへの対応も検討してみましたが、Windowsではzadigでドライバを差し替える必要があってdfu-programmerと排他になってしまい、メリットが感じられなかったので中断しました。
Remapにファームウェア書き込み機能が追加されてから順調にアクセス数が下がってきています。
Keyboard Quantizer Utility
GitHub - sekigon-gonnoc/keyboard-quantizer-utility
Keyboard Quantizerを使ってマウスをカスタマイズしていると、アプリごとにキーマップを変更したくなるシチュエーションが増えてきました。キーボードであれば適当なキーにレイヤ切り替えを割り当てるところですが、マウスはボタンが少ないので簡単にはいきません。
そこで作ってみたのがKeyboard Quantizer Utilityです。これはPC常駐型のアプリで、アクティブになっているウィンドウの名前に応じてキーボードにコマンドを送り、キーボードは受け取ったコマンドをもとにレイヤ切り替えなどの動作を実行できます。Quantizerの名前を冠していますが自作キーボード一般に適用できます。
最初はこれもブラウザから実装できないかと思ったのですが、ブラウザからほかのプロセスを見ることはできないので独立したアプリになっています。アクティブウィンドウの検出にはactive-winというライブラリを使用しました。この記事を書くにあたりライブラリのページを見直してみたら、利用例として active-app-qmk-layer-updaterというものが紹介されていました。考えることはみな同じですね。
キーボード側にはRawHIDで受信したコマンドに応じた動作を実装する必要があります。このあたりの動作をまとめたqmk-rc というライブラリもあるようです。中身をみてみると分かるように、受信したコマンドに応じてswitch文で動作を分岐するだけなので、なにか実現したい動作があれば簡単に追加できます。
Keyboard Quantizer B
Keyboard Quantizer B - のぎけす屋 - BOOTH
QuantizerがPro Microを乗せる形だったころにBLE Micro Proを利用した無線化の検討は完了していたので、Keyboard Quantizer Bは低消費電力の実現を目標にしました。
メインマイコンの消費電力はもともと低かったのでホスト用マイコンの消費電力をいかに減らすかということに苦心し、クロックを落としたりスリープを挟んだりして低消費電力を実現しました。一方で、消費電力が低すぎるとモバイルバッテリなどに接続したときにしばらくするとバッテリの電源がオフになっていまうという問題があったので、わざと電力を消費するためのダミー抵抗の制御を追加しています。
Keyboard Quantizer (rev.4)
Keyboard Quantizer - rev4 (未組立版)
RP2040搭載のKeyboard Quantizerです。開発中はrev.4ではなくRPというリビジョン名でしたが、有線版の正統な進化系ということでrev.4になりました。
発売としてはKeyboard Quantizer Bより後でしたが、実際の開発はこちらが先行していました。atmega32u4が品薄気味になってきていたのでファームウェアもないのに見切り発車で設計しました。初期の設計ではWS2812を搭載していましたが、目に煩かったのでQuantizer Bと同じく単色LEDx2の構成に落ち着きました。
RP2040のQMK対応はこのためにやりました。
RP2040のQMK対応
RP2040対応のQMK(非公式)を動かす - Self-Made Keyboards in Japan
新しいマイコンでQMKが動くようにするのは(マイコン側のライブラリが充実していれば)意外と簡単です。
最低限の動作でいいのであればUSB出力、タイマ、GPIOをQMKの関数/マクロに合わせてラッピングして、makefileをちょっといじると一体型のキーボードとして動くようになります。 さらに分割型として動作させるにはserial系の関数を、via対応するにはeepromエミュレーションを、LEDを光らせるにはws2812のドライバを、OLEDに表示するにはi2cのドライバを、、、とそれぞれ実装していくことになります。
このファームウェアは拙作のKeyboard Quantizer(rev.4)だけでなく3arahtさんのgiabalanaipicoやchromatoneminipicoなどにも採用されており、十分使えるものになっていると思います。
Pico Micro
PICO Micro(プロト版) - のぎけす屋 - BOOTH
せっかくQMKが動くようになったので他の自作キーボードにも載せたいとなると、手っ取り早いのはPro Microの差し替えです。
Pro MicroサイズのRP2040基板は各社から販売されていますが、Pro Microを裏返して実装することも多い自作キーボードを前提に考えるといずれも
- USBコネクタの背が高く2.5mmコンスルーを使って裏返しの状態で差し込むと浮いてしまう
- ブートローダを起動するためのボタンが表面にあって裏返すとアクセスできない
という問題がありました。
この問題を解決するために設計したのがPico Microです。ミッドマウントのコネクタを採用して高さを抑え、BOOTピンをスルーホールにすることで裏返しの状態でもアクセスできるようにしています。ピン配置はsparkfun pro micro RP2040と互換性を持たせています。
RP2040向けQMKではビルド時にオプションをつけることでPro Micro用のファームウェアをPico Micro向けに変換できるようにして、大抵の場合はファームウェアを編集することなく簡単に置き換えができます。
RP2040を直接実装するキーボードについて
RP2040を直接実装する基板を2種類設計した経験をもとに、キーボードに直接実装する場合のatmega32u4とRP2040の差について比較してみます。 RP2040のハードウェアデザインについては公式のドキュメントを参考にしてください。
https://datasheets.raspberrypi.org/rp2040/hardware-design-with-rp2040.pdf
RP2040(raspberry pi pico)のスペックとatmega32u4を比較してみるとまず目を引くのはROM容量の大きさです。RP2040のROMは外付けなので公平な比較ではありませんが、ラインナップとしては小容量の部類である2MB ROMでも数十円程度で入手できますし、それ以上の大きさ(~128MB)にすることもできます。例えばKeyboard Quantizerのデフォルトのファームウェアのサイズが68KBであることを考えると、キーボード向けとしてはかなり大きいと言えるのではないでしょうか。QMKのオプションをたくさん付けても使いきれなさそうです。
GPIOの本数も30本とatmega32u4の26本より若干多く、40%程度の分割キーボードであればピン直結で設計することもできます。 処理能力も高く、OLEDなどのオプションをつけない場合のマトリクススキャン周波数は数十kHzに達します。マルチコアやPIOを活用することで時間にシビアな機能にも対応可能です。 ブートローダは書き換え不可領域にあるため、うっかり文鎮化する危険もありません。ただし、ブートローダを起動するのに操作するピンがResetピンとBootピンの2つあるので、その点は注意が必要です。
一方、設計時には外付け部品の多さがネックになるかもしれません。
先ほどメリットの1つにROMの大きさを挙げましたが、RP2040はユーザーが書き換えられるROMを内蔵しておらず外付けROMが必須です。このROMは(キーボードにおいては)それなりに高い60MHzの信号で動作するので信号線の配線にも気を使う必要があります。マイコンとROMをできるだけ近くに置く必要があるので、部品の配置にも制約が出そうです。
また、3.3V動作なのでVBUSからの降圧回路が必要だったり、電源まわりのパスコンの推奨数もそれなりにあります。atmega32u4と同様に外付けクロックも必要です。sparkfun pro micro RP2040などの画像を見ると普通のpro microに比べて実装密度が高いことが分かると思います。
パッケージもQFNのみなので手半田の難易度が高く、試作のハードルも多少あがります。
とはいえ、一度わかってしまえば設計する上でのatmega32u4との差は大してありません。 自分の作りたいキーボードの要件に応じて使い分ければいいと思いますが、楽しいので一度作ってみると良いのではないでしょうか。
アニメーションの再生
キーボードにディスプレイがついてると嬉しいことの例:Bad Appleが再生できる pic.twitter.com/YpFxfCsCdX
— せきごん (@_gonnoc) November 13, 2021
Pico Microには最低2MBのROMを搭載することにしていますが、QMKで使用する容量はわずか2%程度に過ぎません。せっかくなので余っている容量を活用したいところです。
そこで試してみたのがOLED上でのアニメーションの再生です。電子工作オタクがディスプレイを動かせるようになると再生したがる事で有名なBad Apple!!のPVを再生してみました。 このPVはもともと白黒の影絵なのでデータ量が小さく済みます。とはいっても、何かしらの動画コーデックを使うのではなく全フレームの画像をそのまま格納しているので、32x24@30fpsのフル尺だと612KBになりました。
これでようやくROMの1/3を使えました。まだ2/3も残っているのでいろいろ遊べそうです。
再生用データを含めたファームウェアは配布できないので、動画からデータを生成するためのスクリプトと再生用の関数を置いておきます。
Pico-PIO-USB
まずはこの動画をご覧ください。
RP2040(ラズパイPicoのマイコン)のPIOを活用してUSBホストを実装しました。元々持ってるUSB機能と合わせてホストとデバイスの両方の機能を持たせられます。動画は分割型自作キーボードの左右間通信をUSB化+αのデモです。詳細はこの後のアドカレにて #自作キーボード #raspberrypipico #raspberrypy pic.twitter.com/Og7HSsygvh
— せきごん (@_gonnoc) December 18, 2021
分割型の自作キーボードではTRRS/TRSケーブルを使って通信する構成が大半を占めています。この構成に対して、本来交流のオーディオ信号のための経路に直流電圧やシリアル通信を流すのは問題がある、という指摘があります。私自身はそもそもケーブルいらない派なのですが、うっかり他のデバイスを接続してしまっても問題が起きない構成、というのは興味深い課題です。
市販の分割型キーボードがどうなっているのか調べてみると、最近発売されたMistel BAROCCO MD770では右側のキーボードがホスト用とデバイス用の2つのUSB-Cポートを備えています。左側キーボードのポートと右側キーボードのホスト用ポートをUSB-Cケーブルで接続して通信しているようです。RP2040のUSBはホスト機能にも対応していますが、今回の場合だとUSBはすでにPCへの接続に使ってしまっています。自作キーボードにUSBホスト機能を実装する、というとKeyboard Quantizerが思い浮かびますが、QuantizerではUSBホスト用のICをメインのマイコンとは別に実装しています。分割キーボードの左右間通信のためだけにICを1個追加するというのは割りに合わない気がします。左右のどちらも親機として動くようにしようとしたら両方にICを載せる必要がありますし、その場合、子機側のICは全く利用されません。MD770が片方しか親機になれないのはこういった事情もあるかもしれません。
そこで注目したのがRP2040のPIO(Programmable IO)機能です。PIO機能ではCPUと独立に動作するシンプルなステートマシンを利用してIOを操作します。これによりCPUだけでは実現できない信号を安定したタイミングで生成できます。PIOを利用してUSBの信号を生成した例はまだ見当たらなかったので、自分で実装してみました。
GitHub - sekigon-gonnoc/Pico-PIO-USB
このライブラリはUSB Full-speedのホスト機能(Low-speedには未対応)をPIOを利用して実現しています。ハードウェア的にはコネクタ以外に必須の部品はありませんが、D+/D-に直列抵抗(22Ω)を入れたほうが良いです。USBの規格的には15kΩのプルダウン抵抗も必要ですがRP2040の内部プルアップ抵抗(80kΩ)で十分動作します。
マイコンのリソースとしては全体でROM 10KB, RAMも10KBくらい使用します。RP2040のメモリ容量に比べると十分小さいです。D+/D-としては2つの連続したGPIOピンを選んで使用できます。PIOは2つ必要で、受信用に1個のPIOのプログラムメモリを専有します。送信用のPIOでは22ステップ分のプログラムメモリと1個のステートマシンを利用します。ws2812用信号の生成部くらいなら共存できそうです。 実行時間としては、1msごとに送受信用のハンドラが起動し、送信完了待ち・受信完了待ちの数us~数百usの間CPUを占有します。そのため、サンプルではほかのプログラムの影響を受けない/与えないようにCore1にこれらの処理を割り当てています。
このライブラリを利用してQMKのRawHID(≒VIA)により双方向の左右間通信を実現しました。RawHIDにはマトリクス状態取得コマンドが用意されていて、VIA/REMAPのマトリクス確認機能に利用されています。通信間隔は1コマンド(=64byte)/1msで実用上十分な速度でマトリクスの状態が取得できます。RawHIDのコマンドはraw_hid_receive_kb
に自分で追加できるので、マトリクスの状態だけでなくエンコーダなどの情報が必要になったらこれらの混合コマンドを用意することで実現できます。双方向の通信なのでLEDの同期なども簡単に実現できそうです。
開発にあたって苦労したのはソフトウェアのチューニングです。信号自体はPIOを使うことで安定して送受信できるのですが、プロトコルを実現するソフトウェアのタイミングも意外とシビアで大変でした。上で説明したようにRP2040にはプログラム用ROMが内蔵されておらず、適宜外付けのROMから読み込んでいます。キャッシュに乗っていれば素早く実行されるのですが、なにも制御しないと実行時間が安定せずプロトコルが成立しませんでした。最終的にはUSBの動作に関する部分はすべてRAMに読み込んでから実行するように指定することで実行時間が安定し、所望の動作が実現できました。コンパイラの最適化は最高レベルが必須で、ちょっとした書き方の差により動作が左右される部分もありました。
D+/D-をロジックアナライザで観察した結果。1msごとに通信しているのが分かります。RP2040の処理性能をもってすればこのくらいの占有率の処理ならQMKのメイン処理と同じコアに入れても問題なく動作しそうです。サンプルプログラムではマルチコアの検討もかねて念のためCore1に割り振っています。 |
1周期分の通信を拡大してみた結果。DATA0とラベルされているのがホストからデバイスへのコマンドで、DATA1が前の周期のコマンドに対するデバイスからホストへの応答を示しています。 |
先ほどの動画に出てきたPico-Pico-USBはこの機能の検証用に作ったmeishiサイズのキーボードです。ホスト用のUSB-CポートはPico MicroのGPIOに繋がっています。1つのキーボードに同じ形状のポートが2つ存在するとそれはそれで差し間違いのリスクが生じそうですが、差し間違えたとしても動作しないだけで破損のリスクはないので良しとしましょう。 本当はRP2040を直接実装した基板にしたかったのですが今日の記事に間に合わないのでPico Micro/Pro Micro RP2040を実装する形になりました。
回路図。念のためD+/D-のプルダウン抵抗と直列抵抗を入れられるようになっています。無くても動きます。 | Pico-Pico-USBのPCB |
サンプルプログラムとしてはQMKのsplitを利用したシンプルな実装と、splitを利用せずcustom_matrixの中で通信結果を利用する発展形の2つ用意しました。
https://github.com/sekigon-gonnoc/qmk_firmware/tree/rp2040/keyboards/pico_pico_usb
左右それぞれのキーボードからするとどちらもホストに接続された状態になっているので動作に違いはありません。どちらのキーボードもホスト用ポートから受信したマトリクスの状態を自分のマトリクスに追加して自分のホストに送信します。QMKのsplitを利用する場合はcustom_transportを実装してデータを処理しています。custom_transportのうち実装が必要なのはtransport_mastserだけです。下流側のデバイスに対してVIAのマトリクス取得コマンドを発行し、受け取った結果をslave_matrixに反映させます。下流側のデバイスではVIAが有効になっていればそのままよしなに通信してくれるので、transport_slave
は不要です。
各キーボードは自分の下流側のデバイスから受け取ったデータと自分のデータを統合して上流に流すので、3台以上のキーボードを接続することもできます。ただし、QMKのsplit機能は2分割を前提としていて3台以上の構成に対応できません。この場合はsplitではなくcustom_matrixを利用する必要があります。とはいっても通信部分はPico-PIO-USBとQMKのRaw HIDが利用できるので、意外とシンプルに実装できます。
3台以上繋いだ時のデータの流れ |
マウスなどのデバイスを接続して連動させることも(通信できる条件を満たしていれば)可能です。デモの動画では手元の無線トラックボールがLow-Speedデバイスだったため、Keyboard Quantizerを噛ませてFull-Speedに変換して認識させています。
自分が用意したUSBケーブルの中で最長のものが1.8mで、この長さでも問題なく通信できています。 本来のUSBでは受信部のハードウェアが差動レシーバになっていて、ケーブルが伸びても安定した通信ができるようになっています。しかし、pico-pio-usbでは差動レシーバが存在しないためD+だけを使ってデータを受信しています。そのため、あまりに長いケーブルだと通信が成立しなくなる可能性はありますが、少なくとも1.8mのケーブルでも通信できるのであれば左右間通信用としては実用上十分ではないでしょうか。QKMの独自のシリアル通信プロトコルに比べるとUSBのほうが通信エラーチェックや再送の仕組みも充実しているので、その点でも安心です。
いまのところホスト機能にしか対応していないので、PIO-USBで追加したポートに対して通常のUSBポートを接続する構成しか実現できません。ケーブルの取り回しを考えるとポートの配置に制約ができてしまうので、デバイス機能にも対応させてPIO-USB同士での通信にも対応させたいです。
上側にポートが集中しているデザイン | 違う辺の上にポートを配置した場合 |
そのほか、USBハブやUSB Low-speedへの対応にも挑戦してみようと思っています。
おまけは以上です。