ASkeyboardをUSBの親指シフトキーボードにする その2

概要

ASkeyboard sono1
ASkeyboard sono1
  • ASkeyboard sono1の内部に、Pro Micro(+5V,  16MHz版)とロジックICを載せた手作り基板をセットしハードウェアとして完成させる。
  • キー配列を決める。そして、キースキャンやスキャンコード生成を行うライブラリファイルを作成し、動作を確認する。
  • hoboNicolaライブラリと組み合わせることで、USBケーブルで接続する親指シフトキーボードとして完成させる。

手作り基板

以下の回路をユニバーサル基板を使って作成した。

A_PRO_MICRO_Askeyboard1 (前回掲載したものと同じ)

この基板を、ASkeyboardのキーボード基板にあるi8051用ソケットにそのまま差して使う形態にするのだけれど、キーボード外側のボディ(あるいは上蓋)をかぶせたとき、基板に接触しない程度の厚さに収める必要がある。
そして、大きさとしても以下の写真の絶縁テープが貼ってある領域(25×140mm程度)に収めないと、おそらくボディをかぶせることができない。

ASkeyboard sono1
ASkeyboard sono1

ぎりぎり入る程度の大きさで、以下のような基板を作った。

ASkeyboard用基板
ASkeyboard用基板(裏)

こちらの面がキーボード基板と顔を合わせることになる。40ピンソケットに差すピンヘッダは、秋月電子の細ピンヘッダを使った。しょうしょう電源ライン(特にGND)に不安があったので太目のワイヤを追加している。

ASkeyboard用基板(表)
ASkeyboard用基板(表)

配線側はこんな具合で、細いジュンフロン線を使って配線した。キーボード基板に装着したとき、こちらの面が上を向く。

ユニバーサル基板としては、秋月電子で売っている「0.3mm厚 極薄両面ガラス・ユニバーサル基板」を使った。ユニバーサル基板としては値が張るが、ふつうの両面スルーホール基板の厚みが1.6mmなので1mm以上薄い。

この基板のいいところは、必要な形状にハサミやカッターナイフで切れること。上の写真でわかるように、この基板を装着できる領域の手前(キースイッチ側)はほとんど余裕がないから、2.54mm ピッチのスルーホールの中間線あたりで切断し、端のスルーホールに40ピンソケット用のピンヘッダを立てた。

気を付けるべきところは、基板が薄いのではんだごての熱がすぐに裏側まで伝わってしまうから、ピンヘッダの樹脂部分が熱で溶けピンが斜めになってしまうこと。今回は30Wのコテを使ったが、15Wくらいの方がよさそうである。

装着したところ
ASkeyboard用基板
ASkeyboard用基板

ピンヘッダを40ピンソケットに装着すると、こんな具合になった。なんとか収まる高さになったし、ユニバーサル基板の薄さもよく分かる。ロジックIC用にソケットを使うとキーボード基板に接触してしまうだろから直付けしている。

ASkeyboard用基板
ASkeyboard用基板

上から見てもぎりぎり収まっている。この後ボディをかぶせる前に、配線面全体にアセテート絶縁テープを貼って保護するようにした。

上の写真の右端で、基板から黒いケーブルが出ているが、これはGNDラインの補強用に追加したもの。キーボード基板のLEDや7407が電流を食うせいなのか、40ピンソケットのGNDピンの接触が悪いのか、補強してやらないとPro Microがまともに動かなかった。

この後、Pro MicroのUSBコネクタにUSBケーブルを接続し、もともとあったケーブル孔から引き出すようにした(順序としては、ケーブル孔を通してから接続)。Pro MicroからUSBケーブルを抜くことはないし、妙な力がかかってコネクタがもげても困るので、外側にはテープを貼って補強した。

ASkeyboard sono1
ASkeyboard sono1

これでハードウェアは完成。あとはUSBケーブルをPCにつないで、スケッチを送り込むだけである。

プログラムについて

今回のキーボードに特有の部分は、ASkeyboard用のモジュール(ASkeyboard.*)内で処理し、全体としては今までの実装(USB版やPS/2版)とほとんど同じ構成としたので、hoboNicolaのコア部分(同時打鍵やHIDインタフェースなど)には、若干のメソッドの追加や、同時打鍵ステートマシンのわずかな変更で済んだ。

ASkeyboard用のライブラリを含むソースファイル一式はhoboNicolaライブラリの1.2.1版に収めた。hoboNicolaのページからダウンロードできます。

以下、実装に関する事柄をしょうしょう。

ASkeyboard特有な部分の実装

ふつうのUSBキーボードにはない機能や足りないキー、刻印の異なるキーへの対処について。

DIPスイッチ

キーボード内部のプログラムの動作設定を行うために使う。現在のキーボードでも、Ctrlキーと英数キーを入れ換えるためなどにDIPスイッチをもつものもある。

ASKeyboard sono1
ASKeyboard sono1

3つのポジションをもつDIPスイッチには、以下のような機能を割り当てることにした。

  • 親指Ⅰ
    左親指はHIDキーボードでのF23キー、右親指は同じくF24キーのコード(HID Usage IDで、それぞれ0x72と0x73)を発生するようにする。NicolaKeyboard内の同時打鍵ステートマシンでもこれらのキーを親指キーとして処理できるようにすることで、専用の親指キーとして機能させる。
    F23, F24というキーコードはキーボードからhoboNicolaのコア部分に渡るが、 専用親指キーとして使われるだけで、その先(PCなどのホスト側)には送信されない。
  • 親指Ⅱ
    左親指は無変換(NFER)、右親指は変換(XFER)とし、通常のUSBキーボードと同じ扱いにする。なぜこういう動作モードを付けたのかについては後述する。
  • JIS
    このポジションのときは、同時打鍵処理を行わず通常のUSBキーボードとする。左右の親指キーは親指Ⅰと同様のコードを発生する。こちらの場合、F23, F24のキーコードがホストまで送信される。

DIPスイッチポジションごとに、NicolaKeyboard側に特有の情報を反映するようにした。親指Ⅰのとき変換/無変換を親指キーにしない(専用親指キー)、とか、JISのとき同時打鍵をさせない、などがそれにあたる。

専用の親指キーへの対応

ASkeyboard sono1
ASkeyboard sono1. 存在感のある親指キー。

親指左、親指右と書いておいてほしいところだが、空白と印字されている。

同時打鍵ステートマシンの修正

DIPスイッチが親指Ⅰ(専用親指キー有)のとき、hoboNicolaの同時打鍵ステートマシンの動作を若干変更した。

今回のキーボードでの親指Ⅱポジションや、ふつうのUSBキーボードで親指キーと変換または無変換キーを共用するとき(共用親指キー時)には、親指キーのストロークが単独打鍵と判断されたとき、(本来の機能の)変換や無変換キーのコードをPCなどのホスト側に送信する必要がある。
しかしながら、親指同時打鍵にしか使わない専用のキーならば、単独打鍵時には何も送る必要はない。言い方を変えると、親指キーについては単独打鍵という判定を行う必要がない。そのため、ステートマシン内の親指キー押下中状態 において、タイムアウトとリピートイベントを無視し同じ状態を維持するようにした。
文字キー押下中親指キー押下状態では、次に押すキーの種類によって出力すべき文字が変わってくるが、このあたりは変更していない。親指キー単独での「キーコード出力」が発生したとしても、出力すべきキーコードをセットしていないため余計なコードが送信されることはない。

結果として、専用親指キーを押したまま1分後に文字キーを押下したとしても、親指同時打鍵として判定されるようになる。ただSHIFTキーのような修飾キーではないので、同時打鍵が成立するのはそのときだけ。ふつう、親指キーをずっと押したままにしてから文字を打つようなことはしないのだが、昔さわったOASYSワープロの中には、そういう動作をしているものもあったような気がするので合わせてみた。

このあたりの修正は、先にリンクをあげた同時打鍵ステートマシンの説明にも反映した。

英数入力時の親指キー

もともとのASkeyboardもそうだったと思うのだが、英数字を入力するとき(非NICOLA時)左右の親指キーは空白キーになるようにした。中央にデンと据えられている2つのキーが何も機能しないのはおかしいだろう。今回の実装ではScrLock LEDがオフのとき(つまり、非NICOLAモードのとき)、キースキャン時に親指キーのキースイッチビットを空白キーのそれとマージする。
なおDIPスイッチがJISの場合には空白キーとのマージは行わず、上記の親指キー専用のキーコードを出力する。どうせJISポジションは使わないし、本体側での何かの実験に使えるかもしれないから。

LED

ASKeyboard sono1
ASKeyboard sono1

LEDは以下のような割り当てにした。

  • カナLOCK
    ScrLock LEDにした。このLEDが点灯していてDIPスイッチが親指ポジションのとき、同時打鍵処理やNICOLA配列が有効になる。
  • CAPS LOCK
    そのままCaps Lock LEDにした。
  • CTRL/XFER
    設定モード中に点灯する。設定モードとは、空白キーを親指キーにするとか、NICOLAモード時もリピートするとか、即時出力動作(零遅延モード)にするとかを設定するための機能で、ふつうのUSBキーボードでは左親指+Pauseキーの同時打鍵で開始し、ASkeyboardではFn(ALT) + F6で開始するようにした。
  • NUM LOCK
    そのままNum Lock LEDにした。
  • KB LOCK
    キーボードロック時に点灯するようにした。キーボードロック操作については後述する。

キーボードの配列図

ASkeyboardのキー配列は以下のようになっている。

ASkeyboard layout
ASkeyboard layout

もともとPC9801用のキーボードなので、現代のUSBキーボードと比べると足りなかったり刻印が一致していなかったりするキーがある。とりあえず、以下のように割り当てることにした。

位置 ASkeyboard HIDキーボード 備考
F-00 STOP 半角/全角 押しにくい。思案中。
F-01 COPY Application コンテキストメニューを出すためのキー
A-00 CAPS GUI Windowsキー。Ctrlキーと押し間違えること多数。
A-01 GRPH Alt
A-02 カナ カタカナ/
ひらがな
A-03 TAB Caps Lock /
英数
半角/全角と入れ替えるかもしれない。
X-01 NFER 無変換 Non-Transfer
X-02 XFER 変換 Transfer
A-08 ALT (Fn) 機能拡張用。Fnキーに対応するHIDキーコードはないだろう。
G-01 ROLLUP Pg Up
G-02 ROLLDOWN Pg Down
G-03 HOME Home
G-04 HELP End
G-05 INS Insert
G-06 DEL Delete

最近のふつうのキーボードにあって、ASkeyboardにないキーについては、Fn(ALT)キーを押したときに入力できるようにした。

位置 ASkeyboard HIDキーボード 備考
F-02 Fn + F1 F11
F-03 Fn + F2 F12
F-04 Fn + F3 Print Screen
F-05 Fn + F4 Scroll Lock
F-06 Fn + F5 Pause
F-07 Fn + F6 (無し) 設定モード開始
F-08 Fn + F7 (未定)
F-09 Fn + F8 Num Lock
F-10 Fn + F9 (未定)
F-11 Fn + F10 (無し) キーボードロック

とりあえずこのような割り当てにした。Fnキー押下中の拡張は上記だけにしているが、今後増やしていくかもしれない。

ここに明記していないキーについては、USBキーボードの刻印通り(あるいは似たもの)ということにした。

キーボードロック

ALT + F10を押したとき、キーボードの刻印にしたがってキーボードロックをかけ、KB LOCK LEDを点灯させるようにした。

キーボードロック中も、内部でのキースキャンやホスト側からのLED通知への対応は変わらない(別のキーボードでCapsLockをかけると、CAPS LOCK LEDが点灯)。単純に、キー入力を検出してもHIDインタフェース側に通知しないことで実現した。

テンキー( sono2 )はおざなり
ASKeyboard sono2 (Dbord)
ASKeyboard sono2 (Dbord)

外付けのテンキー(sono2)には、000キー、=キー、カンマ(,)キーなど、PCのキーボードにはないキーが配列されている。HID Usage Table の Keyboard/Keypad ページ(ページ7)を見ると、

Keypad = 0x67
Keypad 000 0xb1
Keypad Comma 0x85

といった定義がある。対応するキーが押されたときとりあえずそれらのコードを出すようにしてみたが、どうやらPCの日本語キーボードでは無効のようで、カンマ、=、000キーを押しても何も表示されなかった。

その他のキーについては、NumLockがオンになっていれば刻印通りの数字や記号、あるいはEnterが入力できる。NumLockオフのときは矢印やHomeあるいはEndといった編集機能キーとして動作するが、キーの刻印に沿ったものではない。

テンキーを使うことはほとんどないだろう、ということで0キーのコードを3回送るとか、フルキーボード側のカンマやイコールのコードを出すとかもしていない。また、CURLOCKキーについても特に処理を入れなかった。今後、何か役に立つ使い方(「お世話になっております。」とか出す?)を思いついたら追加することになるだろう。

記号の配列もちょっと違う
ASkeyboardとUSBキーボード
ASkeyboardとUSBキーボード

上がASkeyboardで下がUSBキーボードだが、@記号があるキーやその上の^記号(ハットマークあるいはサーカムフレックス)のキーのSHIFT側が入れ替わっている。
ASkeyboardの記号配置はかつてのPC9800シリーズに合わせたのだと思う。IBM PCが出てくる前からPC8800シリーズというのもあったから、PC9800はそのあたりからの伝統的な配列を継承したのかもしれない。そういえば、当初のPC9801にはバッククォートあるいはアクサングラヴ(‘)が存在しなかったような記憶もある。

今回の実装では、この部分はまったく気にせず現在のUSBキーボードと同じ記号がでる。

プログラム構成の概略

ソースを読んでもらった方が早いのだが、ざっと説明すると以下のようになっている。

初期設定

キーボードマトリックスのスキャン用、データ読み取り用、LED用など、GPIOポートの設定を行う。そして、Timer1が一定の間隔でオーバーフロー割込みを起こすように設定した。
設定に際しては、Arduino風の pinMode() ではなく、ATmegaのGPIO方向レジスタに直接書き込む形式とした。回路図を見ながら記述するにあたって、その方が分かりやすかったから。

Timer1 オーバーフロー割込み(キースキャン)

ATmega32u4のTimer1オーバーフロー割込みにより、キースキャンを一定の間隔で実行するようにした。
この処理では、キーマトリックスをスキャンし前回のスキャン時から変化のあったキーを抽出する。そして変化のあったキーのスキャンコードを作成しFIFO式のキー入力バッファに格納する。最後に次回割込みのために、TCNT1に定数をセットして終了。

割込みルーチン内でスキャンコードまで生成しているので、上位部分(メインループ、同時打鍵処理その他)から見ると、知らないうちにキー入力がバッファに溜まっていくことになる。メインループでは、そのバッファからキーコードを拾って処理することになり、全体として他の実装と同じような構成とすることができた。

キースキャン時には、キースイッチのバウンス対策を行っているので、30年前に製造されたキーボードなのにチャタリングによる悪影響はほとんど感じられない(皆無とまでは言い切れない)。キースキャンとバウンス対策について後述する。

メインループ

キー入力バッファからスキャンコードを取り出す。それが修飾キーならば修飾キー用のデータを設定し、NicolaKeyboardにその旨を通知する。修飾キー以外ならば、スキャンコードをキーコード(HID Usage ID)に変換し、やはりNicolaKeyboardに通知する。

Arduinoのloop() 関数から、ASkeyboard::task() を呼び出すこと上記のような処理を実行しており、他にHID側からのLEDの点灯通知の反映や、ASkeyboard独自のDIPスイッチポジションに応じた値のセットなども行っている。

NicolaKeyboardおよびBaseKeyboard

通知されたキー情報と、HIDインタフェースを介してホスト(PCなど)から通知されたScrLock LEDの状態に応じて、同時打鍵処理を行ったり、そのままホスト側にキー情報の通知を行うかする。従来のUSB版やPS/2版とほとんど同じだが、ASkeyboard用に若干の追加や修正を加えている。

キースキャンの実際

前回掲載した回路図のように、このキーボードはテンキー部分も含めて8行×15列のキーボードマトリックスで構成されている。マトリックスのスキャンは、2つ並べた74HC138のいずれかの出力ポートをLとすることで列を選択し、8行分のデータを読み取ることを15回繰り返して行う。
読み取った内容は15バイトのバッファに格納し、前回読み取った15バイトと異なるビットがあれば、そのビットに対応したキーが押下またはリリースされたと判断してスキャンコードの生成し、さらにHID Usage ID に変換してホスト側(PC やスマホなど)に送ることになる。

  1. バウンス対策
  2. スキャンの実際

について。

バウンス対策

メカニカルなキースイッチは必ずバウンス(チャタリング)する。
バウンスとはスイッチの押下またはリリースの直後、数msec にわたってスイッチの接点が振動し、状態が安定せずに変化すること。キーボードに使われるような高級なスイッチでも、押下またはリリースから10msec弱までの状態は信用できないということになっている。

SparkFun社のサイトにメカニカルキースイッチとして有名なCherry MXキースイッチの仕様があったのでリンクを貼っておくが、特定の押下条件でのバウンス時間の仕様が5msec以下となっている。まあ10msec弱といっても大げさではないだろう。

キーボードのスイッチを読み取るときにバウンスに配慮しないと、一度しか押していないはずのキーの文字が2回以上続けて入ったりして都合が悪い。

キースキャンとバウンス
キースキャンとバウンス

上図は、キーを押す操作、それに対応したスイッチの状態、単純な読取りと、バウンスを防ぐために改善した読取りの違いを表している。バウンスしている期間は、スイッチ状態がオンまたはオフを繰り返すように表現した。
スイッチ状態の読み取りは、5msec程度の間隔で行っているものとする。

単純な読取り

読み取ったスイッチの状態が前回読取り値から変化しているとき、そのスイッチ(キー)が押された、または、離されたと判定してキー入力を生成する(図では、on または off で表現)。
バウンス期間中の読み取り値は、キーを押したときにも0になったり1になったり不定だから、最初にキーon  を生成しているのに、次の瞬間offを出し、またすぐにon を出している。結果として2回押したのと同じことになっている。キーを離したときも同様。

このやり方でバウンスの影響を少なくするためには、読取り間隔をバウンス期間より長くすることになる。運悪くバウンス期間中に状態を得たとしても、それは前回と同じ値か安定後の次回の値と同じになるはずなので余計な on / offは出ない。
ただ、キーボードを叩いたりして衝撃を与えたとき、スイッチが振動して瞬間的にオンになり、タイミングによってはそれを拾ってしまうことがあるから、予期せぬキー入力の発生は避けられない。

バウンス対策した読取り

読み取ったスイッチの状態が、2回続けて同じ(前回と同じ)場合にのみスイッチ状態を確定する。そして、確定した読み取り値が前回確定値と異なる場合に、キーが押された、または、離されたと判定する。
単純な読取りと比べて、キー入力が確定するまでにかかる時間が長くなるが、スイッチのバウンス期間を10msec弱とすれば5msecごとに3回読めばバウンスしていない期間に2回読み取れていることになり人間が操作するキーボードとしては問題ないと判断した。
物理的な衝撃でスイッチがバウンスして瞬間的にオンになったとしても、その現象が10msec以上持続することは稀だろうから、余計なキー入力が生じることも少ない。

スキャンの実際

15列分の読取りは以下のようにしている。

PORTBのビット1~4に列番号(1~15)を順にあたえて1列を選択する。そして、ちょっと待ってからPINFとPINDに接続されている8キー分のスイッチビットを得る。データを読み取った時点では、押下されているキーに対応するビットが0となっているので、それを反転してtmp_scan[]に格納する。

tmp_scan[] の内容が前回スキャン結果をもつ scan[] と一致していれば、確定データとなる。確定データを前回確定データ(last_scan[])と比較し、変化のあったキーを抽出してスキャンコードを生成する。スキャンコードは、列番号 × 8 + ビット位置 としている(列番号は0~14、ビット位置は1~8)。

そして、put_buffer() によってFIFO式のキー入力バッファに格納する。このとき、リリースされたキーならば0x80をORしている。
バッファからの取出し(get_buffer() )はメインループ側で行う。取り出しが滞ってバッファフルになったら、最後のキーは捨てられることになる。バッファサイズは16バイトとしているが、ふつうの使用状況では16キーも同時に押すことはないだろう。

キースイッチビットのマージについて

DIPスイッチが親指IおよびIIで、英数字入力時には親指キーは空白キーとしているが、本来なら異なるスキャンコードをもつキーを1つのキーに見せるため、コード生成後ではなくキースキャン結果(scan[])を得た時点で処理している。

空白キーを押し次に親指キーを押す。そして親指キーを離すような場合、通常のやり方では最初に押した空白キーが押したままなのに、親指キーを離した時点で空白キーがリリースされた、という通知が行われてしまう。これを防ぐためにキーイベントの通知を行うところで処理しようとすると、関係するキーが押下中かどうかを調べたり、そのための情報を別に維持しておく必要があり面倒である。

キースキャンし確定した時点で、2つの親指キーのキースイッチビットを空白キーのビットにORし、親指キー側のビットをクリアしてやれば、3つのキーの押下情報がマージされ、スキャンコードを生成する段階では1つのキーとして扱うことができるから、いずれかのキーが押下されたままならば空白キーはオンのまま、ということになる。

キースイッチビットのマージは、英数入力時の親指キーと空白キーのほかに、親指II のときの親指キーと変換/無変換キーに対しても行っている(こちらはNICOLAモード時のみ)。

Timer1のOVF割込み

キースキャンは、ATmega32u4のTimer1オーバーフロー割込みを一定の間隔(現在のところ5msec)で発生させ、その割込みサービスルーチン(ISR)内で実施している。AVRマイコンなので、ふつうのArduinoと同様に以下のように設定した。

マイコンの外部クロックは16MHzなので、プリスケーラで64分周することでタイマーユニットのクロックを250KHzとしている。250KHzということは250カウントで1msecなので、それを-5倍した値を定数としておき、TCNT1にセットしている。

Timer1のオーバーフロー割込みは、16ビット長のTCNT1が0xffffから0に繰り上がった時点でかかるから、-250 × 5としてやれば、ほぼ5msec後に割込みがかかることになる。

割込みルーチンの ISR(TIMER1_OVF_vect) { } の最後で、TCNT1に同じ値を書かないと、次の割り込み発生は4usec × 65536で約260msec後になることに注意。

割込みを発生させる間隔は、実際にキーボードを叩いてみてチャタリングの発生度合いを見て変更することになる。いまのところ、5msecで問題なさそうである。

多重割込みを許可

ソースを見ると分かるのだが、この割込み処理はしょうしょう長い(とはいえ1msecかかるようなことはないだろうが)。割込み処理が長いと、フォアグラウンド側の処理が進まなかったり他のリアルタイム性が要求される割込み処理を阻害したりすることになる。今回のハードウェア構成 で、実際に割込み源となる要素は以下の3項目だろう。

  • このTimer1 オーバーフロー割込み(ベクタ21)。
  • Arduinoのwiring.c が設定するTimer0オーバーフロー割込み(ベクタ24)。
  • ATmega32u4の特徴であるUSB関係(ベクタ11と12)。

AVRマイコンには優先順位に基づく多重割込み機構はないので、キースキャンからコードの格納までの処理が終わらなければ、優先順位の高いUSB関係の割込み要因が出現しても処理が行われない。今回は、ISR内で明示的に割り込みを許可してやるために、

と宣言した。この ISR_NOBLOCK と書いてやるとISRの先頭に割り込みを許可するsei 命令が置かれるので、このルーチンの実行中であっても他の割込みが発生すれば処理が移る。

Timer0の割り込みは、Arduinoライブラリの delay() やmillis() などの計時のために約1msec単位に発生するから、やはりキースキャン中に割り込んでくれた方が精度を維持する意味でもいいのかなと思っている。

avr-g++が生成したオブジェクトの中身(リンクされたelfファイル)を avr-objdump -S してやってソースコード付きの逆アセンブルリストを得たところ、TIMER1_OVF_vect ではレジスタが20個ほどpushされていた。32個全部やるのかと思っていたがそうでもなかった。USB関係のベクタ12が23個のpush、Timer0の方は9個だったのでスタック領域の空きが特別に必要、ということもなさそうである。

なお、現状のASkeyboard用プログラムのビルド結果は以下のようになっている。

テキストサイズ、データサイズともに現状のusb版やps/2版よりもコンパクトになった。

使用感

実のところ、ASkeyboard用のプログラムがまともに動くようになってから、ほぼずっとASkeyboardを使ってプログラムを直したり、メールやブログを書いたりしている。その際に感じたことなどをいくつか。

専用の親指キー

ASKeyboard sono1
ASKeyboard sono1

専用の親指キーをもつ親指シフトキーボードを使うのは久しぶりなので、当初はかなり戸惑いがあった。

親指キーが変換や無変換ではない

親指キーと変換/無変換キーが共用型のキーボードを長らく使ってきたせいか、親指キーで変換や無変換の操作ができないのが第一に戸惑ったこと。果たしてどちらがしっくりくるのかということで、DIPスイッチの親指Iは専用、親指Ⅱは共用として実装し使い比べている。

せっかくの専用キーなのでなるべく親指Ⅰを使うようにしているが、当初は変換や無変換操作のつもりで、親指キーをほとんどダブルクリックのように打ってしまっていた。だんだんと慣れて下の段にある無変換キー、変換キーに親指を下すようになってきたのだけど、この親指を一段分動かす運動が余計なように思えることがある。

共用型であるがゆえの誤打鍵(無変換や変換操作が、同時打鍵の一環として認識されてしまうこと)に悩んだ経験は少ないので、実のところ、専用でも共用でもどちらでもいいのかなというのが今のところの実感で、専用の親指キーがあってとてもハッピーという感じでもない。

キーボードに向かう姿勢の問題

写真のように親指キーは他のキーに比べるとかなり背が高い。そのため、キーボードに対して手を浮かせるような姿勢をとらないと、親指キー近傍の文字キーとの同時打鍵がやりにくかった。

ふだん、東プレのRealforceや富士通のUSBキーボードをhoboNicola で使う際には、手はハの字に構えて手の腹をべったりと机につけたまま指を伸ばして撫でるように打鍵しているのだけど、このキーボードを使うときには、ハの字を狭くし手全体を高めに構えた方がいいようだ。必然的に背中も伸びるから、こっちの方が本来あるべき正しい姿勢かもしれないが。

音がちょっとうるさい

ながらく東プレのRealforceを指で撫でるように打ってきたのでほとんど音のない世界だったのだけど、ASkeyboardにはアルプス製の緑軸のメカニカルスイッチが入っており、腰がないからある程度しっかり押し込む(押し込んでしまう)ことになる。
もっとも、音を出す仕組みを持たないスイッチなので軽く押せば摩擦音しかしない(メカニカルスイッチを押したときカチカチ音がするものは、あえてそういう音がでるように作ってあるスイッチだから)。気になるのは親指キーを押したときの音である。

ASkeyboard sono1
ASkeyboard sono1

キートップを外すと、こんな具合にスタビライザーと親指キーの底打ちを防ぐゴムパッドが入っている。スタビライザーは、親指キーや空白キー、SHIFTキーなど長めのキーに用意されており、キートップの端を押したときに傾くことを防ぎ、どこを押してもオン/オフの感覚が変わらない(押し込む深さが変化しない)ようにする目的で配置されている。

その代わり、スタビライザーがカチャカチャいったり黒い鉄板と触れ合う音が聞こえてくる。親指キーを叩く頻度は空白キーやSHIFTキーとはだいぶ違うので、ちょっと気になる。
ただ親指キーの打鍵感は、他のキーと同じスイッチを使っているものの、高さがあるだけ軽いタッチで反応してくれる感覚でちょうどいい具合。

編集機能キーの配列

むかしはCtrlキーを使ったカーソルダイヤモンド操作ばかりやっていたが、このところの編集操作では矢印キーやHome、End、Deleteといった右肩にある編集機能キーに依存している。PC用のコンパクトなキーボードを選ぶ際にも、このあたりの配列が違ったものはなるべく避けている。なので、ASkeyboardでは結構なストレスになってしまう。

編集キーの比較
編集キーの比較

左がASkeyboardで右が東プレRealforce91の編集キー周りで、機能としては過不足ない。矢印キーはどうしようもないので、その上の6つのキーについては以下のように変更したらどうかと思案中。

  • HOME/CLR –> Home
  • INS –> End
  • HELP –> Insert
  • DEL  —> Delete

まあ、好きなようにプログラムを直せばいいだけの話なのだが。

使っているところ

実際に入力しているところを動画にしてみた。キーボードは親指Ⅰモードとして親指キー専用動作になっている。

懐かしの練習問題を打ってみたのだけど、あまり高速な入力はできないし間違えも多い。ただ、少ない手指の動きで軽く入力できることが親指シフト(NICOLA)キーボードのいいところだろう。この練習問題は昔のOASYSワープロに入っていたものだが、「母の愛情、人生を反省」や「 同情と愛情、度胸と愛嬌」といった打ちやすい名文句?が気に入っている。

きょうのまとめ

30年前に製造されたキーボードだが、昔のキーボードは単純かつ頑丈に作ってあるせいか、使用上の問題はまったく感じない。先に書いたように配列の違いによる違和感はあるものの、慣れの問題だろう。

プログラム一式はhoboNicolaライブラリの1.2.1版として、こちらのページからダウンロード可能です。もっとも、このキーボードを持っていて、なおかつ同じように改造する人は皆無だろうから、フルキーボードをスキャンし、なおかつ親指シフトキーボードとするときの一例として見ていただければと思っている。

次はやりかけになっている、ESP32を使ったBluetooth版のhoboNicolaアダプタの話になると思います。