シェーキーの体内ネットワークを考える（その２）

ロボット作ろう：シェーキー製作記

ネットワークの物理層は前回決めました。今回はここを流れるメッセージの仕様を決めます。前提条件は↓これです。

■メッセージはアスキーで送受信される（バイナリの転送は行わない）

これはデバッグ時にTeraTermでメッセージを読み書きしたいからです。これができるとデバッグの効率がよくなります。

メッセージの内容は下記の図のとおりです。

メッセージは必ず＠が頭につきます。次の１キャラクタは、そのメッセージのあて先です。IDは１６進で0-Fまでの１６IDが使えるようになっていますが、ASCII文字（@とcr以外）ならいいわけですからもっと増やすことも可能です。

その次の１キャラクタはそのメッセージの送信元のIDで、レスポンスを返す必要がある場合はこれを参照することになります。

その次の任意長の文字列がメッセージの本体です。任意長といっても、バッファサイズや通信路占有の問題があるので、そんなに長くできません。64バイトくらいが上限と考えましょう。

最後にターミネーターとしてｃｒ(0x0D)を付加しメッセージを完了します。

ところで、今回、このような単純なネットワークを自作するのは、PICなどの比較的シンプルな組み込みマイコンに実装できる、自由度が高いネットワークが見当たらないからです。ここでいう「自由度」とは、「ネットワークに接続されたどの機器間でも通信ができる」ことです。

I2Cではだめなの？という声が聞こえてきそうです。今回のシェーキーの企画では、クライアントが１台で他がサーバという位置づけなので、実はI2Cでいけるのですが、たとえば、クライアントが複数で、しかも非同期にサーバにアクセスするとなってくると、マスタ・スレーブモデルのI2Cではちょっと難しいことになってきます。

クライアントが複数とはどんな状況でしょうか。たとえば、ひとつのクライアントはセンササーバからの情報を受けて障害物回避をコントロールし、もうひとつのクライアントはインターネットに接続し、ネット上から走行をコントロールする、なんてことが考えられます。

もっとも、ネットワークの物理層が貧弱ですから、制限は大きいですが。

ネットワークシステムの「模型」を作る気持ちで、気楽にいきましょう。