ZMK薙刀式の可能性

XIAO BLEでKMK薙刀式はどうにも乗り越えられないハードルがあるようなので、ZMKももう少し調査してみた。 ローカルにZMKのビルド環境を構築して、ビルドした結果、17.46%しかRAMを使わないという表示が。 これは行けそうな気がする。

Memory region         Used Size  Region Size  %age Used
           FLASH:      191867 B       788 KB     23.78%
            SRAM:       45776 B       256 KB     17.46%
        IDT_LIST:          0 GB         2 KB      0.00%

ZMKの場合、behaviorという拡張の仕組みがあることがわかった。 behavior_naginataというのを作ればいいのだ、多分。

ZMKの問題はワイヤレスで使うと技適問題が生じること。 こればかりはどうしようもないので、有線でつかうしかない。 仮にZMK薙刀式ができたとしても、有線だ。 来るべき時に備えて、用意しよう。

KMK メモリ使用量

Raspberry Pi Pico + KMK(py)

kmk.keyboard: mem_info used:73984 free:120512

Raspberry Pi Pico + KMK(mpy)

kmk.keyboard: mem_info used:72864 free:121504

Raspberry Pi Pico + KMK(mpy) + Naginata(py)

kmk.keyboard: mem_info used:106272 free:88224

Raspberry Pi Pico + KMK(mpy) + Naginata(mpy)

kmk.keyboard: mem_info used:105840 free:88528

ん、Picoと比べると、XIAOはKMK入れた時点がかなりメモリの空きが少ない。 used + freeもだいぶ少ない。 どういうことだ。

XIAO BLE + KMK(mpy)

kmk.keyboard: mem_info used:108352 free:33088

XIAO BLE + KMK(mpy) + BLE Split(mpy)

kmk.keyboard: mem_info used:119856 free:21584

KMK薙刀式の変換時間

下のログはKMK薙刀式のかな変換時間（キータイプ時間を含む）です。 １キー単打、２キー同時なら問題ないと思いますが、３キー同時で100ms弱、4キー同時（ロールオーバー）だと300ms近くかかっており、 目に見えて遅い。 100ms以下には短縮したいと思っている。

ng_type 1-keys took 12 ms
ng_type 1-keys took 7 ms
ng_type 1-keys took 10 ms
ng_type 2-keys took 35 ms
ng_type 3-keys took 86 ms
ng_type 3-keys took 92 ms
ng_type 2-keys took 52 ms
ng_type 2-keys took 34 ms
ng_type 4-keys took 188 ms
ng_type 4-keys took 272 ms
ng_type 4-keys took 207 ms
ng_type 3-keys took 86 ms

CircutPythonのプリコンパイル

こちらに書かれているが、circuitpythonのpyスクリプトをコンパイルしてmpyに変換にするとサイズが減るらしい。 実行速度も速くなる気がする。 測定していないけど。

supervisor.ticks_ms()で変換時間を測定してみたが、kmkと薙刀式のコードをmpyにしても変換に要する時間に変化はなかった。 バイトコードに変換を事前にやるか、on-the-flyでやるかだけの違い、ということか。

mpyにすると実行時のメモリ使用量は減るようです。

KMK Firmware Tips

KMK薙刀式の進捗

KMKに薙刀式のかな入力部分(編集モードを含まない)を実装できたので、貼っておきます。 すでに、QMK版より完成度は高く、QMK版で発生するバグを潰せている。 開発側にとってはpythonで書けるというのは、早く完成度を上げられるメリットがあるのがはっきりしました。

一方で、実行速度が遅い。

「ATmaga32U4+QMKよりも、RP2040+KMKの方が目にみえて遅い」

これは、予想外でした。 Cで書かれているQMK速いのは当たり前ですが、RP2040ならPythonでも大丈夫と思い込んでいました。 PCのようにはいきませんね。 PC版の言語実装はかなり高速化の最適化も進んでますが、組み込みではそこまでやるリソースはないですし。

5キーの組み合わせを探索させると目に見えて待たされます。 とても実用的ではないと思ったので、4キーの組み合わせまでで、やめました。 入力バッファがあふれた時の処理をちゃんとかけたので、今のところそれでも誤変換なく入力できているので、よしとしています。

今後は、KMK版を母艦として開発し、QMK版へ反映していくのが良いのかと思います。

github.com

KMK薙刀式へ

RP2040なら潤沢なリソースと高級な言語でもっと薙刀式の変換を楽にかけるはずで、ずっとやってみたいと思ってきた。
rubyistなので、PRK firmwareをwatchしてきたが、どうにもとっかかりがなくて、手がつけられていなかった。
ちょっとpythonで書かれているKMK firmwareをのぞいてみたら、必要そうなapiがそろっている。各キーにプレスとリリースごとにハンドラーを登録していく。オブジェクト指向なapi。
簡単に基本的な薙刀式を実装できた。これはQMKを超えられそう。

薙刀式v15 実装

いろんな仕様ができたので、目次を作っておきます。

MacOS用
QMK通常版
QMK新変換ロジック
Keyboard Quantizer Mini用
Keyboard Quantizer B用