(7)M5Stack BasicとM5Stamp Pico 、UIFlowでダイソー「ピンポンブザー」を早押し対応にする - 早押し順を保持
※本記事は、ダイソー製品に関する改造記事です。本記事を参考にして同様の改造を行い、何が起こったとしても責任はとれませんので、もし参考にする場合は、自己責任でお願いします。予めご了承の上、お読みください。なお、該当製品の「使用上の注意」には、「分解や改造をしないでください。」とありますので、(株)大創産業の想定していない使用方法であることを付記しておきます。完全自己責任です。
前回はこちら
親機の修正
最初の解答者が間違えた場合、次の解答者に解答権が移るようなルールがある場合があります。今回は、このような機能を実現していきたいと思います。
この機能を実現するためには、早押し順を保持する必要があります。早押し順は「Push」データを送ってきた子機の順番にMacアドレスをリストに追加していくような動作で保持することにします。
リスト関係のブロックは、「リスト」にまとめられています。
親機に設定した「次に送る」ボタンを押すことで、リストの先頭を削除して（解答権を剥奪して）リストの次を先頭にもってきます。
実際にやってみましょう。
まず、「早押し順List」という変数を用意し、初期化処理の中で、空のリストで埋めておきます。
親機の本体のEspNow受信部分を修正します。
まず、子機からPushデータが送られてきたら、変数「早押し順List」の最後尾にPushデータを送ってきた子機のMacアドレスを追加します。また、変数Push（一番早かった子機の表示用）を書き換える条件を「早押し順Listの長さが１だったら」に変更します。この部分は、一番最初に親機が受信した、子機のMacアドレスを表示する部分です。「recieve callback」は全体が「もしdata="Push"」に覆われているので、ここの部分は、EspNowでPushが送られてきたときにしか動きませんから、原理的には、「空のリスト」→「長さ１のリスト」になったときにしかここの条件分岐は動きません。ブロックの最初で、早押し順Listの最後に値を追加し、次にその判定が来てますから、結果的として「早押し順Listが空のときに初めて値が送られてきた」ときだけ実行することになります。
実は、ここのもしブロックは条件を変更しなくても動きます。違いは一番早かった子機表示用ラベルの値を条件にするのか、早押し順Listの長さを条件にするのかという違いでしか有りません。ただ、ロジック的には表示用ラベルの値を条件にするというのは、あんまり美しくないんです。本質的には「子機が一番最初にPushを送信してきた」ときに処理をしてほしいので、そこの条件がそれとは直接関係ない（間接的には関係してますが）ラベルの値というのはちょっと美しくない。なにせ、「ラベルの値が０」になるのは、初期化処理でラベルを０にしているのと、リセット時に０にしている時ですから、動くには動きますが、「そうしているからそうなっている」状態です。一方「早押し順Listの長さ」は、設計にもよりますが、早押し順Listの長さが１のときには、必ずその子機が一番早かったことになります。
リセット時にきちんとラベルを０に戻す処理を忘れなければどっちでもいいといえばいいですが、原理的に正確なのはこちらの方です。
伝わるかなぁ、この違い。
まぁ変更したくない人はどうぞ。最終的には動きゃいいんです。
あと、EEPROMから読むkeyを早押し順リストの最初にしておきます。このブロックが実行されるときにはrecieve callbackのdataも同じ値のはずですが、一応、ロジックを揃えておきます。（dataを直接よりもEEPROMから読んだほうが、少し動作が遅くなるかもしれません）
こっちもお好みで。
これで、早押し順Listにボタンが早く押された順が保存されるようになったので、送り機能を実装していきます。
M5Stack Basicの別ボタンに送りボタン機能をもたせます。
押すと、早押し順Listの最初の要素を削除し、長さが0なら表示ラベルを""（空）にして、Reset信号を送ります。それ以外（まだ解答待ちの子機がいる）なら繰り上がった早押し順Listの最初の子機のMacアドレスを表示用ラベルに読み込みます。読み込んだらそれ（次の解答権ありの端末のMacアドレス）を送信します。
子機側の修正
ありません。
今回、子機側の修正はありません。解答権が移ったときには親機側で別の子機のMacアドレスを送信します。したがって、今解答権がある子機も、別のMacアドレスが送られてくるので赤色点灯になりますし、解答権を得た子機も自分のMacアドレスと一致するMacアドレスを受信するので、緑色点灯になります。
子機のプログラムとしての理想形
最終的に子機のM5Stamp Picoは、ピンポンブザーの中に入れてネジ止めしてしまいますので、プログラムを変更するのは手間になってしまいます。
予め基本的な応答動作を予測して書き込んでおくことで、プログラム修正のたびにネジ止めを外して取り出す必要がないようにしておくとよいのです。
できれば、「今は使わないけど、将来の拡張性のために予め仕込んでおく」と中を開ける機会がぐんと減ります。
今はそこまではやっていないので、必要なプログラムをその都度組んでいっています。
また、親機側のプログラムの組み方で、子機のプログラムに修正が必要かどうか決まることも多々あるので、子機のプログラムを変更しなくても済むように親機のプログラムを組む、という感覚も必要だと思います。
それでもどうしても子機のプログラムに修正が必要なら迷わず開けるんですけどね。
さて、これで早押し判定ができるようになり、解答権を順繰りに送る機能もつきました。機能としては十分です。懸念されていた、無線でのボタン検出の遅れや信号の取得漏れなんかもいまのところ大丈夫そうです。
あとは、より使いやすくするための機能を追加するといったところです。必須ではないけれど、あったほうが便利、な機能ですね。
例えば、今早押しに参加している子機はどれなのか、とか、一覧で参加している子機の早押し順が分かる（今は送りボタンを押さないと分からない）とか、基板上にはブー音の生成箇所もありましたので、それをうまく使うとか、いろいろ考えられます。
ここのところ高頻度の更新がつづいていましたが、機能追加も一段落したので、次は、少し頻度を落とそうと思っています。