NiZ のアプリケーションは Windows 向けしかない。プロトコルが気になったので、とりあえず打鍵回数を読み出すところをまでをやってみた。環境は macOS で hid_api gem を使い、Ruby で書いた。

できたもの

実行するとこういう出力をする。最後の数字がキーに対応するカウント。

key=  1 hwcode=   1             ESC: 35
key=  2 hwcode=  15               1: 66
key=  3 hwcode=  16               2: 92
key=  4 hwcode=  17               3: 114
key=  5 hwcode=  18               4: 119
key=  6 hwcode=  19               5: 53
key=  7 hwcode=  20               6: 99
key=  8 hwcode=  21               7: 18
key=  9 hwcode=  22               8: 115
key= 10 hwcode=  23               9: 76
key= 11 hwcode=  24               0: 171
key= 12 hwcode=  25               -: 307
key= 13 hwcode=  26               =: 78
key= 14 hwcode=  41               \: 38
key= 15 hwcode=  14               `: 33
key= 16 hwcode=  28             TAB: 575
key= 17 hwcode=  29               Q: 253
key= 18 hwcode=  30               W: 627
key= 19 hwcode=  31               E: 1461
key= 20 hwcode=  32               R: 911
key= 21 hwcode=  33               T: 1137
key= 22 hwcode=  34               Y: 616
key= 23 hwcode=  35               U: 1317
key= 24 hwcode=  36               I: 1662
key= 25 hwcode=  37               O: 1536
key= 26 hwcode=  38               P: 549
key= 27 hwcode=  39               [: 584
key= 28 hwcode=  40               ]: 41
key= 29 hwcode=  27              BS: 1662
key= 30 hwcode=  67          L-CTRL: 18
key= 31 hwcode=  43               A: 1794
key= 32 hwcode=  44               S: 914
key= 33 hwcode=  45               D: 853
key= 34 hwcode=  46               F: 249
key= 35 hwcode=  47               G: 520
key= 36 hwcode=  48               H: 828
key= 37 hwcode=  49               J: 671
key= 38 hwcode=  50               K: 1424
key= 39 hwcode=  51               L: 696
key= 40 hwcode=  52               ;: 452
key= 41 hwcode=  53               ': 155
key= 42 hwcode=  54             RET: 1281
key= 43 hwcode=  55         L-Shift: 1610
key= 44 hwcode=  56               Z: 177
key= 45 hwcode=  57               X: 128
key= 46 hwcode=  58               C: 459
key= 47 hwcode=  59               V: 253
key= 48 hwcode=  60               B: 384
key= 49 hwcode=  61               N: 1352
key= 50 hwcode=  62               M: 482
key= 51 hwcode=  63               ,: 383
key= 52 hwcode=  64               .: 255
key= 53 hwcode=  65               /: 161
key= 54 hwcode=  66         R-Shift: 850
key= 55 hwcode= 156            R-Fn: 135
key= 56 hwcode=  67          L-CTRL: 1653
key= 57 hwcode= 166            L-Fn: 6
key= 58 hwcode=  69           L-Alt: 35
key= 59 hwcode=  68           Super: 703
key= 60 hwcode=  70           Space: 2037
key= 61 hwcode=  68           Super: 7
key= 62 hwcode=  71           R-Alt: 5
key= 63 hwcode=  74          R-Ctrl: 5
key= 64 hwcode=  88      Left Arrow: 24
key= 65 hwcode=  89      Down Arrow: 19
key= 66 hwcode=  90     Right Arrow: 34
key= 67 hwcode=   0                : 0
key= 68 hwcode=   0                : 0
key= 69 hwcode=   0                : 0
key= 70 hwcode=   0                : 0
key= 71 hwcode=   0                : 0
key= 72 hwcode=   0                : 0
key= 73 hwcode=   0                : 0
key= 74 hwcode=   0                : 0
key= 75 hwcode=   0                : 0

プロトコルの概要

すべて HID 上で行われる。64bytes 固定で read/write する。

日本語で説明するよりソースコード読んだほうが早いので説明するのをやめる。

カウントを得るためにすること

キーマップを得る

NiZ キーボード側から、現在のキーマップを取得する。66キーのモデルなので、66キー × 3レイヤー (ノーマル・左Fn・右Fn) で 198 個の論理キー定義がある。

これによって、キーID (1〜66) と、割当られているキーコード (.pro ファイルの HWCODE) のマッピングを得られる。

カウント一覧を得る

カウントは66個の数値の配列のようなものが得られる。インデックスがそれぞれキーIDに対応していると思われる。

インデックスからキーマップを得てカウントと共に表示すればおわり。

備考

macOS だからか、実装が悪いのか、どこが悪いのかわからないが、挙動が不安定

  • HidApi.open がしばしば失敗する
  • read に失敗する (タイムアウト)

何回か繰替えすと成功する。

hid_api

hid_api は timeout のメソッドがあるにも関わらず timeout の処理が抜けているので、モンキーパッチを書いてる。PR 作ろうかと思ったけど結構放置されてそうでめんどい。

macOS でもキーマップを書きかえたいんだけど???

read した形式で書き戻せばいいだけだと思う。

どうやって解析したか?

Windows に USBPcap を入れて、公式のアプリケーションを操作しながらログをとった。

あとは気合

ソースコード

https://github.com/cho45/niz-tools-ruby github にうつしました

>

  1. トップ
  2. tech
  3. NiZ Keyboard PLUM からキーマップや打鍵回数を読み出す

(この写真のキー配列はデフォルトのものではなく、既にカスタマイズ済みです。mac 用のキーキャップが付属しており、HHKB を基準にできるだけキーキャップもあわせています)

3行で

  • 信頼性のあるキーボードがほしいなら買わないほうが良い
  • 打鍵感は十分に良い
  • これにしかない魅力はある

NiZ というキーボード

https://www.nizkeyboard.com/ が公式っぽい。中華製の静電容量無接点キーボード (HHKBやRealforceなどと同じ分類)。

HHKB と比べると以下のような特徴がある

  • 35g / 45g を選べる。35g モデルでも 10g 増やすバネで、特定のキー(ホームポジションとか)だけ荷重を増やせる
    • HHKB は 45g キーストローク 4mm
  • キー数のバリエーションが多い
  • 完全にキーマップをカスタマイズ可能 (ファームウェアレベルで行う)
  • Type-C コネクタ (mini-B よりも機械的に丈夫なコネクタ)
  • Bluetooth 接続対応・バッテリー内蔵
  • 価格は若干安い

価格が安いだけなら買うつもりはなかったけど、キーが HHKB よりも軽くて Bluetooth 接続が可能で、Type-C 接続な点で気になった。66キー(HHKBとほぼ同じ大きさ) 35g のモデルを買ってみた。スペック通りなら HHKB 信者を止めることになる。

初期設定とハマったところ

デフォルトだと「Office モード」というモードらしく、キーのリマップが効かないモードになっている。 Fn+M キーを同時に2秒押して Program モードというモードにしなくてはいけない。

専用アプリを使ってのキーカスタマイズはこのモードでしか適用されない。

キーが効きにくい……

試しうちしてすぐ気付いたが、左 Ctrl (というか位置的には Caps-Lock)、スペース、RET、Shift が叩くように入力しないと反応しない、または普通に使っていて入力をとりこぼすことがわかった。

https://www.nizkeyboard.com/2019/07/07/some-keys-doesnt-work-look-at-this/ 公式にこういうエントリがあるぐらいなので頻出問題みたい。手順では F2 F10 を押しながらキャリブレーションすると書いてあるけど、単に基準となるキーが変わるだけで、どのキーを押しながらでもキャリブレーションできる。自分の場合は左 Shift + スペースを軽く押しながらキャリブレーションすることで、気になる範囲の取りこぼしはなくなった気がする。

キーボードの信頼性

市販のキーボードは「普通に動く」けれど、それはもうそれだけですごいのだ、ということに気付く。キーボードの信頼性というのはそこで、普段意識するようなことはない。最低限ちゃんと思った通りに入力できなければならない。

NiZ は(自分の場合は)キャリブレーションなしには全く使いものにならないものだった。普通に考えたら初期不良だし、キーボードをキャリブレーションしたらなおるとか思いもしないだろう。そういう初期調整も含めての安価な値段だと思う。

NiZの良い点

良い点は冒頭でもほとんど記したけど

  • 打鍵が軽い
  • スコスコしたスムーズな打鍵感
  • 打鍵音が静か (HHKB と比べると雲泥の差)
  • カスタマイズ性
  • Bluetooth

とかいろいろある。このキーボードにしかない特徴があるので、うまくキャリブレーションするか、あたり個体を掴めれば良い選択かもしれない。

とりあえず普段遣いできる感じのキャリブレーションはすることができたので、しばらく使ってみるつもり。

細かいメモ

USB デバイスとしては `ID 0483:512a STMicroelectronics 66EC-S ` で認識されている。STM32 っぽい……と言いたいところだけど、中華デバイスは STM32 互換の MCU に STM32 のツールで作ったファームウェアを書いていたりするので、これだけでは判断できない。

  1. トップ
  2. tech
  3. NiZ Keyboard PLUM という静電容量無接点キーボード

デバッグ機能の分類

  • デバッグ制御インターフェイス : CPU制御を行う。ブレークポイントやプログラムカウンタの増加(実行)など
  • トレース機能: 実行履歴を出力する機能。デバッガではいちいち実行を止めるため、実際の速度で動かしたときのタイミング問題などを検出するのは難しい。そこでトレース機能が必要になる。

デバッグ制御インターフェイス

  • ICE: in-circuit emulator CPU の代わりに回路中のCPUをエミュレーションするもの。元々は専用の IC だったが、最近のMCUはオンチップエミュレータとなっている。
  • JTAG デバッグ制御インターフェイス。元々はデバッグ用ではなく検査用。5線で通信する。各ピンの状態がわかる (バウンダリスキャン)、というのが本来の用途。
  • JTAG エミュレータ: JTAG をデバッグ制御として、オンチップエミュレータを操作する形のICE
  • SWD デバッグ制御インターフェイス 2線ですむ。ARM MCU はこれが主流。デバッグ専用で、検査ポートとしては使えない (バウンダリスキャンはできない)。プロトコルは32bit値のR/Wに特化している。

JTAG も SWD も CPU 内部のレジスタを読み書きすることで、CPU 側にある任意の機能を呼び出している。なので、デバッグプロトコルは JTAGとSWDの上に乗っており、CPU によって異る。

トレース機能

  • ETM: Embedded Trace Macrocell 分岐のたびにPC情報を得ることでトレースする。
  • SWV: Serial Wire Viewer PCをサンプリングすることでトレースする。(サンプリングなので抜けが発生しうる)

(高級な print デバッグを想像するとよい。が、自分は使ったことがないのでわからない)

ARM 関連

  • CMSIS-DAP: Cortex Microcontroller Software Interface. Standard - CoreSight Debug Access Port . ARM が定義した USB と SWD/JTAG インターフェイスのプロトコル
  • ARM CoreSight: ARM Core 内のデバッグ用コンポーネント

USB から CMSIS-DAP を使って JTAG/SWD を操作し、CPU 内部の CoreSight に接続する、という感じ。

USB デバッガ

  • SEGGER J-Link: JTAG/SWD を USB 経由で扱うインターフェイス
  • ST-Link: STM8/STM32 専用の JTAG/SWD を USB 経由で扱うインターフェイス
  • LPC-Link2: CMSIS-DAPデバッガにしたり SEGGER J-Link にしたり Redlink にしたりできるボード。

このへんややこしいが、「SERGGER J-Link」はデバッガハードウェアの名称でもあり、USB 接続時のプロトコルでもある。

ST-Link も同様で、ST-Link2 ST-Link3 というデバッガハードウェアもあるし、USB 接続時のプロトコルでもある。

LPC-Link2 は USB 接続時のプロトコルとして SEGGER J-Link / CMSIS-DAP / Redlink (nxp の独自プロトコル) を切り替えられるボード。

結局どのプロトコルでも、同じCPUならできることは一緒。だが、ホスト側のドライバの関係でパフォーマンスに違いがでることがある。

  1. トップ
  2. tech
  3. JTAG/SWD 関係の用語