I2Cキーパッドきっと（その２）

本格運用でなぜか不安定

　以前、記事にした「I2Cキーパッドきっと」ですか、すでにM5Stackで運用しているシステムに、Groveコネクタで接続して、組み込もうとしたのですが、どういうわけか動作が不安定で困りました。

　Keypad_I2Cライブラリの付属のHelloKeypad_I2Cは問題なく動作するのに、このソースを元に既存のシステムに組み込むと、kpd.pinState_set()で、時々FFFFFFFFを返したり、getKey()の値が返るのに異常に時間がかかるなど、奇妙な症状が発生しました。

　ハードの問題かもしれないと思い、もう一台、キーパッド買ってみて試しましたが、やはり同じ症状が発生しました。もう私のスキルではお手上げになったのですが、このまま諦めるのもなんだか癪なので、別なやり方を考えてみました。

（ロジアナは持っていませんが、やっぱいるかも…）

I2Cを諦めてマトリックス接続を引き出す

　この「I2Cキーパッドきっと」を自作するにしても似たようなデザインになってしまうため、ハードはこのまま使いたいと考えました。

　そこでP0からP7のIOを、M5StackのBUSへ結線し、M5Stack側でキー判別できないかと思いました。せっかくI2C接続で省線化されているのに本末転倒ですが、ここは目をつぶることにします。

　幸いM5StackのBUSは多くのGPIOがあるので助かりました。

ソケット経由だと高さが問題となり直付け

マトリックス接続とは

マトリックス接続

　I2Cキーパッドきっとの回路図をみると、P0～P3が列、P4-P7が行となっています。例えば[1]キーを押すと、P0とP4が短絡した状態になるということです。各GPIOの出力を切り替えながら、他の入力値を見ていけば、どのキーが押されているか判別できます。

Keypadライブラリがそのまま使える

いままでちゃんと意識していませんでしたが、Keypadクラスはマトリックス接続を前提としたクラスでした。Keypad_I2Cクラスは、Keypadクラスが基底クラスとなっています。今回は、この基底のKeypadクラスがそのまま使えます。

ようやくうまくいきました

　またもや（私のC言語のスキル不足で）すったもんだしましたが、最終的に意図した動作をさせることができました。

　今回、このキットを使用したきっかけは、これまで使用してきた電圧式のキーパッドが廃版になってしまったからです。4x4の16キーのキーパッドは持っているのですが、これを3.3vで使おうとすると、正確なキー判別が難しいと判断しました。

　ようやく、このキットが日の目を見ることになったのですが、サクッと終わるはずが、（毎度のことながら）のたうち回る結果となりました。ただこれで、今後のキーパッドをつかった作成物の目途がたちました。