BeepyというRaspberry Pi Zeroにモノクロ液晶とBlackberryのキーボードをつけた端末があって、すごく欲しいんだけど、ファーストバッチは売り切れて、次の入荷を待っている。
とりあえず、同じ液晶は秋月で手に入るので、以下の部品を購入して、Raspberry Pi Zero 2 Wに接続してみたのでメモ。
購入部品
接続するGPIOはBeepyに合わせた。
ドライバーはBeepyのもの。
GitHub - sqfmi/Sharp-Memory-LCD-Kernel-Driver: Linux Kernel Driver for Sharp Memory LCDs
フォントを変えたいときは
sudo dpkg-reconfigure console-setup
日本語表示もできるらしい。
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薙刀式ができたとしても、有線だ。 来るべき時に備えて、用意しよう。
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薙刀式のかな変換時間（キータイプ時間を含む）です。 １キー単打、２キー同時なら問題ないと思いますが、３キー同時で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
KMKに薙刀式のかな入力部分(編集モードを含まない)を実装できたので、貼っておきます。 すでに、QMK版より完成度は高く、QMK版で発生するバグを潰せている。 開発側にとってはpythonで書けるというのは、早く完成度を上げられるメリットがあるのがはっきりしました。
一方で、実行速度が遅い。
「ATmaga32U4+QMKよりも、RP2040+KMKの方が目にみえて遅い」
これは、予想外でした。 Cで書かれているQMK速いのは当たり前ですが、RP2040ならPythonでも大丈夫と思い込んでいました。 PCのようにはいきませんね。 PC版の言語実装はかなり高速化の最適化も進んでますが、組み込みではそこまでやるリソースはないですし。
5キーの組み合わせを探索させると目に見えて待たされます。 とても実用的ではないと思ったので、4キーの組み合わせまでで、やめました。 入力バッファがあふれた時の処理をちゃんとかけたので、今のところそれでも誤変換なく入力できているので、よしとしています。
今後は、KMK版を母艦として開発し、QMK版へ反映していくのが良いのかと思います。