- （前回の続き）あるいは、
- こうすればUSB-HID機能をもつマイコンは、今の自分の環境で言うと2台で済むわけだ。なるほど。
- 問題は子マイコンとの通信をどうするかだ。ちゃんとした汎用的な仕組みを作りたいならI2Cを採用して一般的な仮想キーコードをやりとりするべきだろうが、残念ながら（？）その必要はない。なぜなら設計者は自分で、デバイスを作るのも自分なら利用するのも自分だけだからだ。
- 最低限のものならキーコードを扱う必要すらなくて、このピンがHIGHになったらA、このピンがHIGHになったらBとかでもMUX的な仕組みを使えばやれないこともない。でもまあここは武士の情けで（？）ASCIIくらいのコードは扱えるようにしてやろうか。本当にASCIIだけなら7ビットでいいんだけど、ある程度のコントロール（これを押しっぱなしにしろとか？）もやりたいので8ビットにしておこうか。
- 例えばこれをシリアルでやるなら、SPIも魅力的ではあるが二重通信もしないので、クロックとMISO（Master In Slave Out）だけ、しかもどっちもブロードキャストで問題ないのでは？
- ということはだ。上の方で「有効/無効を切り替える」とか書いたけどそれも必要なくて、親マイコンはブロードキャストで流れてくるキーコードを拾ってPCに出力するだけでいいのか？ 複数の子マイコンが同時にキーコードを出力したらめちゃめちゃになるんだが、HIDのボタンを押すのは人間なわけで、ここはそういうことはしないということでどうだろう。ｗ
- そうしたいのは山々だが自動制御することもたまにはあるので親マイコンが発するbusyピンみたいなのを用意しましょうかねえ。どの子マイコンも普段はいつでも開始コード（ののち続けてキーコード）を発して構わないが、開始コードを見た親マイコンはbusyをHIGHにする（終了コードを見たらLOWにする）ので、自動的なトリガを扱ってる奴はbusyがHIGHの間は必ず待つ。人間トリガの奴もピンが余ってるならbusyを見て待っても構わない。複数の子マイコンが開始コードを同時に発してしまった場合は（10Hzとかじゃない限りそんなことはほぼあり得ないので）諦める。
- ASCIIのコントロールコードをそのまま参考にして開始コードを 0b 0000 0001 とするならば、それを送信中（つまり8クロック目を待っている間ずっとLOW）の子マイコンもbusyがHIGHになったのを見たら即座に送信を中止し、待機状態に移行する。busyがLOWになったらまた開始コードを最初から送信（つまり8クロック目になるまでLOWのまま待つ）する……ということで安全を確保できるかな？
- …これって子マイコンもブロードキャストMISOを見てればbusyも不要なのか。キーコードを発信しようとしている子マイコンはブロードキャストMISOを15クロック見て、HIGHを見たら［ここでちょっと待ってもいいし待たなくてもいい］また次の15クロックを見る。15クロックの間何もなければ次のクロックまでにOUTPUTに切り替えて最初の1クロックをHIGHとし、続けてキーコード、最後に終了コード（0b 0000 0100等）を出し、送信を終える。
- 15クロックという待ち時間をふまえて、同期シリアルの速度も検討してみよう。例えば9600bps（つまり9.6kHz）だと15クロックは約0.0016秒、2400bpsだと0.006秒、300bpsでも0.05秒くらいのもんなのか。忙しいことをする予定もないし、自分用のHIDとしてはそんなんでも全然いけるっしょ。これはわざわざ300ボーの音響カプラを自作するしかねーな！！ｗｗｗ
- というドリームを見ました。実際に作れるのかどうかは知らん。クロック同期ってどうやるんだろ。やっぱ割り込みかね。8ビットなら普通にシフトレジスタ使ってもいいんだが、なんか逆に混乱しそうな気がしないでもない。
