ESP32とminiUHSを使ってUSBキーボードをBLE HIDキーボードにしてみる(再度更新)

概要

  • USBの日本語(JIS)キーボードをmini USB Host Shield (miniUHS)を使ってESP32に接続する。
  • Arduino core for ESP32を使ってBLE HIDキーボードを構成し、PCやスマホで使ってみる。

ちょっと前に(SparkFun) Pro Micro でやったことをESP32でやってみて、ついでにBLEライブラリを使ってみた、というお話。残念ながら、Bluetoothキーボードとしての実用レベルには達していない。

※ BLEセキュリティ関係の小改造を行ってみましたが、やはり初回接続時のみしかうまくいきませんでした。

※※ その後、リスタート時も再接続できるようになりました。

構成

DOIT DevKit V1を使う

今回は、しばらく前にaliexpress で $5.00くらいで購入した端子の少ないESP32開発ボードを使うことにした。サイトでの商品名が “ESP-32 ESP-32S ESP-WROOM-32 ESP32-S Development Board WiFi Bluetooth Ultra-Low Power 云々“となっていて呼び方に迷うところだが、どうやら深センにあるDOIT社の”DOIT ESP32 DevKit V1“という製品のコピー品らしい。pdf版の回路図はこちら

doit esp32
DOIT DevKit. 端子の少ないESP32開発ボード

あまりきれいな仕上がりではないが、まあ安いので。載っているデバイスを見ると、ESP-WROOM-32、3.3V用の定電圧レギュレータ(AMS1117)、USBシリアル変換デバイス( CP2102 ) など今まで使ってきた秋月電子の開発ボード(DevKitC)と変わらないようだ。

ESP32開発ボード2種

左側がDOIT DevKit V1、右側が秋月電子のESP32-DevKITCで38ピンある。DOITの方には、およそ使わないだろうWROOM-32内蔵フラッシュ用の6端子(GPIO6~GPIO11)がなく、GPIO0とGND(が1つ)省略されているので30ピンで収まっている。

ただ、PCBアンテナがボードからはみ出していないから、ボード自体の大きさはあまり変わらない。DOIT側のWROOM-32のアンテナ部分には、ペイントによるマーキングがあるのだけど、これは何を意味しているのか気になるところ。まあ、いずれもテレックマークが付いているから日本国内でも電波を出せる。

1枚目のDOIT DEVKIT V1の写真を拡大してみると、WROOM-32の左側に並んだチップ抵抗の上下にLEDがあることに気が付いた。回路図を見ると、片方は電源インジケータでもう片方は抵抗を介してGPIO2に接続されているようだ。DevKITC互換ボードをブレッドボードに載せるとき、GPIO2にLEDをつないで使うことがあったのでちょうどいい。
GPIO2はブートモードを左右するストラッピングピンの1つで、ESP32内でプルダウンされている。ダウンロードブート時にはLに保つ必要があるが、その後は自由に使うことができる。

回路図

MAX3421Eのリセットや、USB-Aコネクタ用のVBUSの配線を変更したmini UHSボードと、ESP32ボードを以下のように接続した。miniUHSボードの改造内容についてはこちらを参照。

ESP32_miniUHS_1

いずれも+3.3V動作なので、SPI用の配線はESP32のVSPI用の端子にそのまま接続する。miniUHSのINT端子は、ESP32のGPIO17に接続した。

端子間の接続については、UHSライブラリ(USB Host Shield Library V2.0 ) の、avrpins.h 内にある、Pinout for ESP32 dev module にしたがった。このライブラリは、ESP32での利用も考慮されている。

しょうしょう急いで作ったこともあって、ブレッドボードに載せるとこんな具合にぐちゃぐちゃになってしまった。

ESP32 + mini UHS (コンデンサ入ってなかった)

スケッチ1

まずはESP32でのminiUHSとUHSライブラリの具合を見るため、キーボードが上げてくるコードをシリアルモニタに表示させてみた。

miniUHSのコントロールには、ちょっと前に Pro Micro用に導入したCircuits@Home が公開しているライブラリを使う。導入方法や概要についてはこちらを参照。今回は、このライブラリに付属のスケッチ例(USBHIDBootKbd.ino)をちょっと手直しして使った。とりたててライブラリに手を入れることなくビルドも通り、意図通りに動いた。

KbdRptParser を介して通知されるキーの押下時(OnKeyDown())とリリース(OnKeyUp())時に、キーコード(HID Usage ID)と修飾キーの内容をシリアルモニタに表示する。修飾キー単独の押下/リリースについては OnControlKeysChanged() に通知されるので、キーコードを0として同様に表示するようにした。

修飾キー以外のキーが押下されたときにGPIO2に接続された青いLEDを点灯させ、すべてのキーがリリースされたとき消灯するようにした。

シリアルモニタにはキーボード操作のたびにコードが表示されるのだが、特に画面をとるほどでもないだろう。

DOIT DEVKIT V1への書き込みについて

ビルド結果をマイコンボードに書き込むとき、Arduino IDEで書き込みを開始してもダウンロードが始まらない。そのため、ダウンロードが開始するまでBOOTボタンを押したままにしておき、開始したことが画面で確認できてからBOOTボタンを離すことで、ようやく書き込みできた。
ときによっては、その操作を何度か繰り返さないとダウンロードできないこともあった。回路図を見るとそういう操作無しでもうまくいきそうに見える。改善できるとは思うが、ボタン押せばいいのでとりあえず今回は見送り。

Bluetoothキーボードにしてみる

せっかくESP32を使うので、Arduino Coreに用意されているBLEライブラリを使ってワイヤレスキーボードにできないものかと思って書いてみた。 https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/tests/BLETests/SampleHIDKeyboard.cpp をArduino風に書き替え、USBキーボードから上がってくるコードを渡せるようにした。

メインスケッチ (ESP32_BLE_Kbd_Test2.ino)

メインスケッチでは、UHSライブラリからあがってくるキーの押下/リリース情報を、BLEキーボード用のクラス(BleHidKeyboard)に渡す。

USBでホストデバイスに接続するときにはArduinoのHIDライブラリを利用するクラスに渡してインプットレポートとしていたが、今回はBLEを利用するクラスに渡す。今のところ、HID-USBとHID-BLEのインタフェースを共通化していない。NICOLA(親指シフト)化するなら共通化したいところだが、この実装ではやる気が起きないというか…。

BLE HIDキーボード用のクラス BleHidKeyboard

HIDキーボードとしてホストデバイスから認識され、物理キーボードから上がってくるキーコード(HID Usage ID)を送信できるようにするためのクラス。(BleHidKeyboard.h)

BLE関係の初期化やコールバックがあるので、若干長くなっているが、基本的にはPro Micro用のHIDキーボードの中身と同じになっている。

reportMap (HID Report Description)

HID Usage Page 7 のキーボードとして動作させるため、Pro Micro用に用意したものをコピーしてきた。
ArduinoのHIDライブラリでは、キーボードとマウスのコンポジットデバイスになっているので、レポートID == 2としていたが、こちらはキーボード単独なので1としている。

class BleHidKeyboard

https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/tests/BLETests/SampleHIDKeyboard.cpp の中身を Arduino Core for the ESP32を組み込んだArduino IDEでビルドできるようなクラスにした。そして、物理キーボード側(UHSライブラリ経由)から上がってくるコードを、HIDインプットレポートとして送信するためのメソッドを用意した。

BLE HIDキーボードとするための処理はほとんど init() 内に収めてあるが、これはNeil Kolbanさんのサンプルのまんまである。

もとのサンプルコードは、あらかじめプログラム内に書かれた文字列を繰り返して送信(インプットレポートとして input->setValue())するようになっているが、このクラスではUHSライブラリから上がってくるコードを渡すように変更した( sendReport() )。
また、ホストデバイスと接続しました通知( BLEServerCallbacks::onConnect() )がきたとき、DOIT DEVKIT V1のLED(GPIO2に接続)を点灯するようにした。青色LEDなのでそれらしく見える。BLEServerCallbacks::onDisconnect() がきたら消灯する。

BLECharacteristicCallbacksを派生したBleHidOutputReportは、アウトプットレポートを受信したときに呼ばれる。アウトプットレポートではキーボードLEDの状態がくるのだが、現在使っているキーボードにはLEDがないので、物理キーボードに反映する処理は省略した。なお、hoboNicolaライブラリでは、UHSライブラリのKeyboardReportParserのParse() を上書きすることで、LEDを点灯可能とした。

1本のヘッダファイルにすべて収めたかったので、コールバックを処理するクラスはインナークラスとした。

スマホとの接続

Android 8.0.0 (HUAWEI NOVA LITE)に接続し、ちょっと入力したところを動画にしてみた。

他にBluetoothキーボードを持っていないので比較できないのだけど、デバイスを認識さえしてくれれば、後は早い。

何もせずにいてスマホの画面が消えてしまっても、キーボードを叩くと画面が復活し、空白キーを叩いてPINの入力もできた。

シリアルモニタを見ていると、

けっこう、切れたりつながったりしているようだった。(k = 2c は空白キー)。

使用感は悪い

スマホに接続して「メモを作成」などをすると、ちゃんと文字が入力できるし、半角/全角キーでかなと英数の切り替えもできる。キーボードとして認識されているようである。

ただ、Shift + 英数キーを押してもCaps Lockが掛からないようだった。シリアルモニタには、英数キーの押下に伴ってCAPS LOCK LEDを点灯しろ、というアウトプットレポートが届いているのだが。

k = 39が英数 ( CapsLock )キーを表している。英数キー単独でも、Shiftキーを押しながら( mod = 02 )でもメモ帳には大文字が表示されなかった。Androidのアプリの問題なのかもしれないが。

全般的には、調子よく入力できるときと、そうでないときとがある。具合が悪いときは、なかなかキー入力が入らなかったり、キーを1回押しただけなのに、aaaaaaaaaaとリピートされたりする。BackSpace が余計にリピートされると打った文字が消えてしまって腹立たしいことになる。

でかい

ビルドすると、Arduino IDEには以下のように表示された。

スケッチが1163861バイト 使っている。なんで?

何かが足りない

問題は、ESP32をリセットしたようなとき、いったんホストデバイス側のBluetoothをオフにしてからオンにしないと、キーボード入力ができなくなること。

一度キーボードとして利用できる状況になっていれば、スマホ側から切断された場合でもキーボードは自動的に再接続しその後の入力も支障なく行える。だがESP32をリスタートしてしまうと、自動接続は行われるのだがキー入力の送信が行えない状態になってしまう。

Arduino IDEの、ツール/Core Debug Level をVerboseにしてビルドし直してみると、キーボードからのイベントに対して以下のようなデバッグメッセージが出力されていた。

つまり、インプットレポートのsetValue() が門前払いされている。なお、k = 52は上矢印キーである。

うまくいくときはこんな具合になっている。

この問題はまだ解決できていない。たぶん、何かが足りないのだろう。ESP IDFを使うとうまくいくんだろうか?

きょうのまとめ

ESP32を使うのはしばらくぶりだったので、いろいろ思い出すためにArduino IDEの更新やArduino core for the ESP32 の導入から始めた。今回のスケッチを動かす前に、GPIO2 に接続されているオンボードLEDをチカチカさせたりもしたが、そこは省略。

ESP32のWiFiでキーボード入力を飛ばすとなると、udpでコントロールするリモコン的なものも考えられる。今回はUSBキーボードをつないだが、UHSライブラリがサポートするHIDデバイスならば、ゲームコントローラでもマウスでも構わないわけで。
もっとも、そういう用途ならESP-WROOM-02で十分だろう。

BLEデバイスとしたときのESP32の消費電流がどの程度なのだろう。世の中で安く売っているBluetoothキーボードは、単3や単4の乾電池2本でけっこうな期間使える。それに対して、ESP32で実装した場合はどうなんだろう、という疑問がある。自分のお気に入りのキーボード(ちょっと頑張ればPS/2キーボード)をワイヤレス化できるのだから、モバイルバッテリ必須でもしかたないのかなぁ、とか思ったりするのだが。とりあえず、BLEデバイスのお勉強用に取り組むという感じか。

BluetoothドングルをPCに付けて、PCのキーボードとしても試していたのだけどリスタート問題は同じだった。このドングル、数日使った時点でPCから認識されなくなってしまった(CSRチップの入った国内周辺機器大手B社の製品)。1000円くらいで買って1年間放置してあったので保証もきかないから燃えないゴミにするか。
その後、サンワサプライの、やはり1200円くらいのドングルを購入して使うようになった。こちらは今のところ安定している。

追記(問題解決)

たびたび思いつきを書いていて、何やってるのか分からなくなってきたので整理して書き直しました。

うまくいく場合
  • まず、PCとのペアリングを外してデバイスを削除する。
  • その状態でESP32をリスタートし、新しいデバイスとしてPCとペアリングする。
  • そのまま使い続ける場合、上記のログのようにキーボードからの入力がPCやスマホに表示される。
うまくいかない場合
  • うまく入力できているときに、ESP32をリスタートする。
  • 接続完了のイベントも来るし、PC側からキーボードLED状態の通知(Output Report)も届く。
  • ただキーボードを打つと、上記ログのように notifications disabled; ignoring  となって入力できない。
セキュリティ関係の問題か?

当初は、ホストデバイスとESP32 BLE間の認証がうまくいってないのかと疑った。ただ接続は完了しているし、少なくともOutput Report は正しく届いている。

の部分を以下のように変更したが同じだった。

ESP_IO_CAP_NONEを、ESP_IO_CAP_OUT や ESP_IO_CAP_IOに変えてやると、BLESecurityCallbacksonConfirmPIN() に交換されているキーが表示され、PC側のペアリング画面にも同じ6桁の数字が表示されたりした。ふつう、キーボードはPINを表示できないので、PC側で常にOK することになるが。

また、ペアリングと接続に成功したホストデバイスのアドレスなどの情報は、ESP32のnvsに維持されるホワイトリストに追加されることも分かった。この動作はきー入力できない場合も同様で、どうも認証に失敗しているわけではなさそう。

ホワイトリストに保存されている内容は、

によってフラッシュメモリからnvsエリアを読み出してやれば確認できる。いろいろと書かれている。(–port COM3 はうちのPCにESP32を接続した場合のCOMポートの指定)。

ログの比較

うまくいくときといかないときのverbose なログを比較してみたところ、うまくいく場合にのみ、ハンドル 0x42に対してESP_GATTS_WRITE_EVTが起きて、先頭が0x01、 次が0x00 というデータを書いていることが分かった。

ハンドル0x42というのは、以下のように、BLEHIDDeviceに追加されたデスクリプタ BLE2902(  00002902-0000-1000-8000-00805f9b34fb )の内部ハンドルのようだった。

(リスタートから開始するので、生成されるハンドルの値はいつもだいたい一緒)。

ログを見ていると、このuuid をもつデスクリプタがいつも2つ作られているようで、もう一方はハンドル0x62となっている。そして、以下のログのように0x62に対しても0x01, 0x00 が書かれている。

このあたりは、もう少し追ってみたいところではあるが、当面の問題はキー入力なのでペンディングにした。

input Reportできるようにする

notification disabled; ignore  というログを出しているのは、BLECharacteristic.cppの541行目付近で以下のようになっている。

そして、BLE2092.cppの getNotifications() は、以下のようになっている。

つまり、BLE2902のもつデータの1バイト目のビット0がセットされていれば、この関数はtrue を返し送信が行われる。ログの比較にあった [0100]というデータの書き込みの有無がこのデータに影響していると考えたので、以下のようなコードを用意し、BLESecurityCallbacks の onAuthenticationComplete() で auth_cmpl.success == trueのときに呼び出すようにしてみたら、ESP32をリスタートしてもキー入力が送信できるようになった。

うまくいくときのログを見ると、onAuthenticationComplete() よりも後ろで 0x42や0x62に対する ESP_GATTS_WRITE_EVT が起きているのだが、適当なコールバック関数がなかったのでここで実行することにした。その後正しい値が書かれても問題ないわけで。

ホストデバイス側から通知が来ないことが問題なのではなくて、ペアリングして信頼関係ができた時点での通知データは、その後同じホストと接続する場合、デバイス側で復元すべきものなのかもしれない。正直、ややこしくてよく分からないことが多い。

ようやく安定してキー入力できるようになったので、ちゃんとしたクラスにしてBluetooth版のほぼNICOLAキーボードにする予定です。