2018年10月
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

カテゴリー

ブログパーツ

無料ブログはココログ

« シェーキーの体内ネットワークを考える(その1) | トップページ | シェーキーの体内ネットワークを考える(その3) »

2010年2月14日 (日)

シェーキーの体内ネットワークを考える(その2)

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

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

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

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

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

Messageformat

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

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

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

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

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

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

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

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

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

« シェーキーの体内ネットワークを考える(その1) | トップページ | シェーキーの体内ネットワークを考える(その3) »

ロボット作ろう」カテゴリの記事

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/1140145/33378640

この記事へのトラックバック一覧です: シェーキーの体内ネットワークを考える(その2):

« シェーキーの体内ネットワークを考える(その1) | トップページ | シェーキーの体内ネットワークを考える(その3) »