NETWORK：Under Power 研究所：SSブログ

	ブログをはじめるログイン

W5100のぁゃしぃ動作　 [NETWORK]

例のArduino Ethernetライブラリの評価の為にパケットモニタ（PacMon）を仕掛け、そのままの状態で放置していた時の話。

家のPCのOSはマイクロソフトの最新OSであるWindows2000（笑）なので、このWindows2000は大体6分置きにARPテーブルのエントリーの更新を行います。

図のハイライトされた行の上２つがPCから送られたARP要求ですが、何故かこの時にはW5100は応答していません。

ここでPC側のARPテーブルからW5100のエントリーは無効となったので、次にPC側がTCPで接続する時はブロードキャストでARP要求を掛けて応答を待ちます。（注意！、パケットモニターのフィルターをW5100のMACアドレスに指定しているので、ブロードキャストパケットは画面に表示されていない。）

と、ここでようやくW5100はARP応答を返しています。

なんでしょう？、この動きは。

※追記
うーん、やはり宛先MACアドレスを指定された時のARP要求は無視するようですね。それ程大きな実害は無いですが、バグだね。

とても読むの大変ですが、プロトコルスタックを作成するなら必読です。

詳解TCP/IP〈Vol.1〉プロトコル

作者: W.リチャードスティーヴンス
出版社/メーカー: ピアソンエデュケーション
発売日: 2000/12
メディア: 単行本

マスタリングTCP/IP 入門編第4版

作者: 竹下隆史
出版社/メーカー: オーム社
発売日: 2007/02/24
メディア: 大型本

2009-06-05 23:38 nice!(0) コメント(0) トラックバック(0)

某雑誌の某特設ページでMCF52233の動作範囲が3.3V±0.1Vとなっている件について　 [NETWORK]

http://kumikomi.typepad.jp/interface_coldfire/

ええ！本当ですかそれは。
手元のMCF52235DSではSupply VoltageとしてMin3.0V、MAX3.6Vとなっているのに。
フリスクさん、その3.3V±0.1Vの条件は厳し過ぎですよ。

そもそも”不安定”と言うその状態がどの様な状態であり、どの様にして「電源が3.3V±0.1Vに入っていないから駄目だ！」と言う検証を行ったのだろう？。

個人のblogなら書き放題だが、技術誌が運営しているページでこんな事書いちゃって、本当に大丈夫？。

2008-10-08 17:01 nice!(0) コメント(5) トラックバック(0)

M52233DEMOがやって来た　 [NETWORK]

待っていましたんですよ。

このボードには、既にデモとしてTCP/IPプロトコルスタックと、その上で動作するアプリケーションがインストールされています。このTCP/IPプロトコルスタックは、フリスクのUSのサイトからロハで落す事ができます。但し実際にそれを動かしてみるにはMCF5223xシリーズのマイコンを搭載したネットワークボードを必要としますので、まああの付録基板も有りますが、まだBDMコネクタを作成していませんし、ここはリファレンスボードとしてこのM52233DEMOを購入してみました。

早速実験してみましょう。

	まずは定番のPINGを打ってみましょう。いきなり1パケット最大の1472bytesです。おお！、3ms弱で返信して来ます。パケットモニタでもっと詳しく見ても、やはり3msを切っています。ロハなのに優秀だなぁ。
	1500bytesのサイズとし、IPフラグメントに対応しているかどうかやってみました。対応している様です。ロハなのに優秀だなぁ。
	1949bytesまでIPフラグメントは動いています。ですが、ちょっと安定性に掛けています。1950bytesからは成功しません。この辺が限界でしょうか。
	勿論WEBページも持っています。ドキュメントページには「HTTP Server with Simple Flash File System」とか書かれていますので、ファイルシステムも搭載していると言う事でしょうか。それ以外は、ボード上のLEDの制御とか、加速度センサーを含むアナログ値のサンプリングを、色々手段を変えて見せてくれます。
	Java Scriptが埋め込まれているので、動的なページの表示ができます。※勿論従来とおりのREFRESHによる更新も行っています。 AJAXのページでは、加速度センサーに連動した、文字が上下、左右に動くデモが有ります。これは新しい見せ方だなぁ。
<< ﾊﾟｹｯﾄ 2 >> --- TCPﾍｯﾀﾞ [1229] → [80] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】1229 【発信先ﾎﾟｰﾄ番号】80 (WWW) 【ｼｰｹﾝｽ番号】3413586381 (0xCB7731CD) 【応答番号】0 (0x00000000) 【ﾃﾞｰﾀｵﾌｾｯﾄ】28 (0x1C) 【ﾌﾗｸﾞ】【URG】0【ACK】0【PSH】0【RST】0【SYN】1【FIN】0 【ｳｨﾝﾄﾞｳ】16384 (0x4000) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0xBCEB (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】【ｵﾌﾟｼｮﾝ番号】2 (最大受信ｾｸﾞﾒﾝﾄ長 = 1460 (0x05B4) ﾊﾞｲﾄ) 【ｵﾌﾟｼｮﾝ番号】1 (ｵﾍﾟﾚｰｼｮﾝなし) 【ｵﾌﾟｼｮﾝ番号】1 (ｵﾍﾟﾚｰｼｮﾝなし) 【ｵﾌﾟｼｮﾝ番号】4 (SACK許可) << ﾊﾟｹｯﾄ 3 >> --- TCPﾍｯﾀﾞ [80] → [1229] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】80 (WWW) 【発信先ﾎﾟｰﾄ番号】1229 【ｼｰｹﾝｽ番号】10452701 (0x009F7EDD) 【応答番号】3413586382 (0xCB7731CE) 【ﾃﾞｰﾀｵﾌｾｯﾄ】24 (0x18) 【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】0【RST】0【SYN】1【FIN】0 【ｳｨﾝﾄﾞｳ】7760 (0x1E50) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0x7419 (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】【ｵﾌﾟｼｮﾝ番号】2 (最大受信ｾｸﾞﾒﾝﾄ長 = 1456 (0x05B0) ﾊﾞｲﾄ) << ﾊﾟｹｯﾄ 4 >> --- TCPﾍｯﾀﾞ [1229] → [80] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】1229 【発信先ﾎﾟｰﾄ番号】80 (WWW) 【ｼｰｹﾝｽ番号】3413586382 (0xCB7731CE) 【応答番号】10452702 (0x009F7EDE) 【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14) 【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】0【RST】0【SYN】0【FIN】0 【ｳｨﾝﾄﾞｳ】17472 (0x4440) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0x65E2 (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】なし	それでは恒例のパケットモニタの解析情報を見てみます。まずはコネクションから。ポート番号80がM52233DEMOです。オプションの交換を行っている事が判ります。M52233DEMO側のMSSは1456bytesです。またWindowサイズが7760bytesも有ります。一つのセッションにそれだけ割り当てが可能とは、ロハなのに優秀だなぁ。
<< ﾊﾟｹｯﾄ 5 >> --- TCPﾍｯﾀﾞ [1229] → [80] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】1229 【発信先ﾎﾟｰﾄ番号】80 (WWW) 【ｼｰｹﾝｽ番号】3413586382 (0xCB7731CE) 【応答番号】10452702 (0x009F7EDE) 【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14) 【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】1【RST】0【SYN】0【FIN】0 【ｳｨﾝﾄﾞｳ】17472 (0x4440) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0x9FC9 (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】なし ---【ﾃﾞｰﾀ】388 (0x0184) ﾊﾞｲﾄ --------------------------------- SJIS ------- 0000 47 45 54 20 2F 20 48 54 - 54 50 2F 31 2E 31 0D 0A GET / HTTP/1.1.. << ﾊﾟｹｯﾄ 6 >> --- TCPﾍｯﾀﾞ [80] → [1229] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】80 (WWW) 【発信先ﾎﾟｰﾄ番号】1229 【ｼｰｹﾝｽ番号】10452702 (0x009F7EDE) 【応答番号】3413586770 (0xCB773352) 【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14) 【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】0【RST】0【SYN】0【FIN】0 【ｳｨﾝﾄﾞｳ】6208 (0x1840) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0x905E (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】なし << ﾊﾟｹｯﾄ 7 >> --- TCPﾍｯﾀﾞ [80] → [1229] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】80 (WWW) 【発信先ﾎﾟｰﾄ番号】1229 【ｼｰｹﾝｽ番号】10452702 (0x009F7EDE) 【応答番号】3413586770 (0xCB773352) 【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14) 【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】1【RST】0【SYN】0【FIN】0 【ｳｨﾝﾄﾞｳ】6208 (0x1840) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0xF726 (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】なし ---【ﾃﾞｰﾀ】633 (0x0279) ﾊﾞｲﾄ --------------------------------- SJIS ------- 0000 48 54 54 50 2F 31 2E 31 - 20 32 30 30 20 4F 4B 0D HTTP/1.1 200 OK.	ブラウザからのリクエストに対して、「HTTP 1.1」バージョンでhtmlを返信しています。ですが、Windowサイズが7760bytesから6208bytesに激減しています。ブラウザが実際に送ったサイズは388bytesです。その差1552bytes。これは388bytesの4倍に当たります。バグじゃねえのか？。
<< ﾊﾟｹｯﾄ 8 >> --- TCPﾍｯﾀﾞ [1232] → [80] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】1232 【発信先ﾎﾟｰﾄ番号】80 (WWW) 【ｼｰｹﾝｽ番号】1869299742 (0x6F6B401E) 【応答番号】0 (0x00000000) 【ﾃﾞｰﾀｵﾌｾｯﾄ】28 (0x1C) 【ﾌﾗｸﾞ】【URG】0【ACK】0【PSH】0【RST】0【SYN】1【FIN】0 【ｳｨﾝﾄﾞｳ】16384 (0x4000) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0x0AA4 (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】【ｵﾌﾟｼｮﾝ番号】2 (最大受信ｾｸﾞﾒﾝﾄ長 = 1460 (0x05B4) ﾊﾞｲﾄ) 【ｵﾌﾟｼｮﾝ番号】1 (ｵﾍﾟﾚｰｼｮﾝなし) 【ｵﾌﾟｼｮﾝ番号】1 (ｵﾍﾟﾚｰｼｮﾝなし) 【ｵﾌﾟｼｮﾝ番号】4 (SACK許可) << ﾊﾟｹｯﾄ 9 >> --- TCPﾍｯﾀﾞ [80] → [1232] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】80 (WWW) 【発信先ﾎﾟｰﾄ番号】1232 【ｼｰｹﾝｽ番号】10580955 (0x00A173DB) 【応答番号】1869299743 (0x6F6B401F) 【ﾃﾞｰﾀｵﾌｾｯﾄ】24 (0x18) 【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】0【RST】0【SYN】1【FIN】0 【ｳｨﾝﾄﾞｳ】6208 (0x1840) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0xD2E1 (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】【ｵﾌﾟｼｮﾝ番号】2 (最大受信ｾｸﾞﾒﾝﾄ長 = 1456 (0x05B0) ﾊﾞｲﾄ) << ﾊﾟｹｯﾄ 10 >> --- TCPﾍｯﾀﾞ [1232] → [80] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】1232 【発信先ﾎﾟｰﾄ番号】80 (WWW) 【ｼｰｹﾝｽ番号】1869299743 (0x6F6B401F) 【応答番号】10580956 (0x00A173DC) 【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14) 【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】0【RST】0【SYN】0【FIN】0 【ｳｨﾝﾄﾞｳ】17472 (0x4440) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0xBE9A (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】なし	続いて２つ目のセッションが開始されています。あれ！今度はWindowサイズが6208bytesからだ。どうなっているのかなぁ。
<< ﾊﾟｹｯﾄ 11 >> --- TCPﾍｯﾀﾞ [1232] → [80] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】1232 【発信先ﾎﾟｰﾄ番号】80 (WWW) 【ｼｰｹﾝｽ番号】1869299743 (0x6F6B401F) 【応答番号】10580956 (0x00A173DC) 【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14) 【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】1【RST】0【SYN】0【FIN】0 【ｳｨﾝﾄﾞｳ】17472 (0x4440) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0x6629 (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】なし ---【ﾃﾞｰﾀ】483 (0x01E3) ﾊﾞｲﾄ --------------------------------- SJIS ------- 0000 47 45 54 20 2F 74 6F 70 - 6C 65 76 65 6C 2E 63 73 GET /toplevel.cs << ﾊﾟｹｯﾄ 15 >> --- TCPﾍｯﾀﾞ [80] → [1232] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】80 (WWW) 【発信先ﾎﾟｰﾄ番号】1232 【ｼｰｹﾝｽ番号】10580956 (0x00A173DC) 【応答番号】1869300226 (0x6F6B4202) 【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14) 【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】1【RST】0【SYN】0【FIN】0 【ｳｨﾝﾄﾞｳ】4656 (0x1230) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0x864F (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】なし ---【ﾃﾞｰﾀ】1386 (0x056A) ﾊﾞｲﾄ -------------------------------- SJIS ------- 0000 48 54 54 50 2F 31 2E 31 - 20 32 30 30 20 4F 4B 0D HTTP/1.1 200 OK.	新しいセッションの方のリクエストと応答です。受信データ483bytesに対して、Windowサイズがまた4656bytesに激減しています。今度の差分は483bytesの4倍ではありません。もう何がなんだか判らなくなってきました。私の今まで理解してきた事が間違っているのかなぁ。
<< ﾊﾟｹｯﾄ 33 >> --- TCPﾍｯﾀﾞ [1229] → [80] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】1229 【発信先ﾎﾟｰﾄ番号】80 (WWW) 【ｼｰｹﾝｽ番号】3413586770 (0xCB773352) 【応答番号】10455610 (0x009F8A3A) 【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14) 【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】1【RST】0【SYN】0【FIN】0 【ｳｨﾝﾄﾞｳ】16597 (0x40D5) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0x8F88 (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】なし ---【ﾃﾞｰﾀ】481 (0x01E1) ﾊﾞｲﾄ --------------------------------- SJIS ------- 0000 47 45 54 20 2F 68 65 61 - 64 65 72 2E 67 69 66 20 GET /header.gif << ﾊﾟｹｯﾄ 34 >> --- TCPﾍｯﾀﾞ [80] → [1229] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】80 (WWW) 【発信先ﾎﾟｰﾄ番号】1229 【ｼｰｹﾝｽ番号】10455610 (0x009F8A3A) 【応答番号】3413587251 (0xCB773533) 【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14) 【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】0【RST】0【SYN】0【FIN】0 【ｳｨﾝﾄﾞｳ】6208 (0x1840) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0x8321 (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】なし << ﾊﾟｹｯﾄ 35 >> --- TCPﾍｯﾀﾞ [80] → [1229] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】80 (WWW) 【発信先ﾎﾟｰﾄ番号】1229 【ｼｰｹﾝｽ番号】10455610 (0x009F8A3A) 【応答番号】3413587251 (0xCB773533) 【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14) 【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】1【RST】0【SYN】0【FIN】0 【ｳｨﾝﾄﾞｳ】6208 (0x1840) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0xDA2F (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】なし ---【ﾃﾞｰﾀ】1400 (0x0578) ﾊﾞｲﾄ -------------------------------- SJIS ------- 0000 48 54 54 50 2F 31 2E 31 - 20 32 30 30 20 4F 4B 0D HTTP/1.1 200 OK. << ﾊﾟｹｯﾄ 36 >> --- TCPﾍｯﾀﾞ [1229] → [80] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】1229 【発信先ﾎﾟｰﾄ番号】80 (WWW) 【ｼｰｹﾝｽ番号】3413587251 (0xCB773533) 【応答番号】10457010 (0x009F8FB2) 【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14) 【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】0【RST】0【SYN】0【FIN】0 【ｳｨﾝﾄﾞｳ】17472 (0x4440) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0x51A9 (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】なし	コネクションを切断せずに、次のリクエストが処理されているのが判ります。HTTP 1.1バージョンの本領発揮ですね。またWindowサイズはここには掲載されていませんが、この直前のパケットで4656bytesまで落ち込みましたが、今回は6208bytesまで回復しています。
<< ﾊﾟｹｯﾄ 46 >> --- MAC層 [00BADBAD0102] → [00D059CB1F0D] -------------------------------- 【ｷｬﾌﾟﾁｬ時間】2008/10/02 21:02:30.276878 --- TCPﾍｯﾀﾞ [80] → [1229] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】80 (WWW) 【発信先ﾎﾟｰﾄ番号】1229 【ｼｰｹﾝｽ番号】10460931 (0x009F9F03) 【応答番号】3413587251 (0xCB773533) 【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14) 【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】0【RST】0【SYN】0【FIN】1 【ｳｨﾝﾄﾞｳ】7760 (0x1E50) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0x6847 (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】なし << ﾊﾟｹｯﾄ 47 >> --- MAC層 [00D059CB1F0D] → [00BADBAD0102] -------------------------------- 【ｷｬﾌﾟﾁｬ時間】2008/10/02 21:02:30.276923 --- TCPﾍｯﾀﾞ [1229] → [80] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】1229 【発信先ﾎﾟｰﾄ番号】80 (WWW) 【ｼｰｹﾝｽ番号】3413587251 (0xCB773533) 【応答番号】10460932 (0x009F9F04) 【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14) 【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】0【RST】0【SYN】0【FIN】0 【ｳｨﾝﾄﾞｳ】16351 (0x3FDF) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0x46B8 (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】なし << ﾊﾟｹｯﾄ 48 >> --- MAC層 [00D059CB1F0D] → [00BADBAD0102] -------------------------------- 【ｷｬﾌﾟﾁｬ時間】2008/10/02 21:02:30.388625 --- TCPﾍｯﾀﾞ [1229] → [80] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】1229 【発信先ﾎﾟｰﾄ番号】80 (WWW) 【ｼｰｹﾝｽ番号】3413587251 (0xCB773533) 【応答番号】10460932 (0x009F9F04) 【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14) 【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】0【RST】0【SYN】0【FIN】1 【ｳｨﾝﾄﾞｳ】16351 (0x3FDF) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0x46B7 (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】なし << ﾊﾟｹｯﾄ 49 >> --- MAC層 [00BADBAD0102] → [00D059CB1F0D] -------------------------------- 【ｷｬﾌﾟﾁｬ時間】2008/10/02 21:02:30.388972 --- TCPﾍｯﾀﾞ [80] → [1229] ------------------------------------------------ 【発信元ﾎﾟｰﾄ番号】80 (WWW) 【発信先ﾎﾟｰﾄ番号】1229 【ｼｰｹﾝｽ番号】10460932 (0x009F9F04) 【応答番号】3413587252 (0xCB773534) 【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14) 【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】0【RST】0【SYN】0【FIN】0 【ｳｨﾝﾄﾞｳ】7760 (0x1E50) ﾊﾞｲﾄ【ﾁｪｯｸｻﾑ】0x6846 (OK) 【緊急ﾎﾟｲﾝﾀ】0 【ｵﾌﾟｼｮﾝ】なし	ここまで何度かこのセッションを使い回していましたが、とうとうブラウザ側からのリクエストが無くなり、Keep Alive Timerがタイムアウトしたのか、コネクションの切断に入ります。 M52233DEMOがFINを送信してから110ms程度で切断処理が完了しています。※ブラウザはOpera9.5ね。

まあしかし、全般的にとても期待できそうです。これでロハなんだから。
えーッと、使うにあたってどんな制限が有るのでしたっけ？。

マスタリングTCP/IP 入門編第4版

作者: 竹下隆史
出版社/メーカー: オーム社
発売日: 2007/02/24
メディア: 大型本

マスタリングTCP/IP 応用編

作者: Philip Miller
出版社/メーカー: オーム社
発売日: 1998/05
メディア: 単行本

2008-10-02 23:53 nice!(0) コメント(4) トラックバック(0)

iPod touch 漏れ無くもらえちゃいます。　[NETWORK]

ディジインターナショナルさんでそんなキャンペーンをやっていらっしゃいます。
ディジインターナショナルさんのページ http://www.digi-intl.co.jp/
キャンペーンのページ http://www.digi-intl.co.jp/campaign/ipod/index.html

応募資格は一つ。ディジインターナショナルさんが扱っているDigi製品を使った何かのレポートが、雑誌等の書籍に掲載されること。

あと、これまたお得なセミナーを10月7日に横浜で開催されるみたいです。凄いお得です。一気に5個ノードを集められます。(かもしれない)
http://www.digi-intl.co.jp/news/seminar/2008/081007info.html

前にヤフオクで、「誰か代わりに買って来て！」って出ていました(笑)。

※イヤーン、もうみんな、「もらえる」とか「お得！」って話には反応が早いんだからぁ。

2008-09-05 15:48 nice!(0) コメント(0) トラックバック(0)

Interface誌 2008年9月号のLANコネクタの入手でお困りの方２　 [NETWORK]

YCLのPTC1111-09L1G、解禁？。
http://kumikomi.typepad.jp/interface_coldfire/2008/08/faq-no3-8dc7.html

共立エレショップで販売されております。
http://www.e-netten.jp/eleshop/cgi/search.cgi?syou=RJ45%83R%83l%83N%83

ならSI-60001もねー。
http://hamayan.blog.so-net.ne.jp/2008-07-18

※ちっとは役に立った？。

Interface (インターフェース) 2008年 09月号 [雑誌]

作者:
出版社/メーカー: CQ出版
発売日: 2008/07/25
メディア: 雑誌

2008-08-04 13:13 nice!(0) コメント(7) トラックバック(0)

Interface誌 2008年9月号ちょっと判らない事が、、、　[NETWORK]

さて、Interfaceの特設ページの解説によると、「MACアドレスを設定するまで厚紙は捨てないで下さい」とな。
では捨ててしまった後でリカバリーした時は、MACアドレスは何処か安全な所に退避されているのかな？。
例えばMACアドレスを設定してしまった基板でリカバリーをした場合はどうなるのかな？。

今、手元にInterface誌が無いので、家に帰ってもう一度よく読んでみるか。
http://kumikomi.typepad.jp/interface_coldfire/2008/07/faq-no2-0845.html

Interface (インターフェース) 2008年 09月号 [雑誌]

作者:
出版社/メーカー: CQ出版
発売日: 2008/07/25
メディア: 雑誌

2008-08-01 12:57 nice!(0) コメント(18) トラックバック(0)

Interface誌 2008年9月号のLANコネクタの入手でお困りの方　 [NETWORK]

こんなニュースも流れていました。
http://www.freescale.co.jp/products/32bit/ColdFire/EtherMiconB.html
http://headlines.yahoo.co.jp/hl?a=20080725-00000026-rbb-sci.view-000
http://www.rbbtoday.com/news/20080725/53074.html
参考までにYCLのコネクタを使用しています。

あー、これはフリスクのセミナーで使った基板みたいですね。勿論動いていましたとも。

発売前に結構色々なコネクタを試してみたようです。それともその時点の入手の関係でそうなったのかな？。

※と思ったら！
共立エレショップから抜粋
「在庫切れ【申し訳ございません。次回入荷は未定です。】」、、、なんですと！。
http://www.e-netten.jp/eleshop/cgi/search.cgi?syou=RJ45%83R%83l%83N%83^
役に立てなくてすまん。

※デジットには有るらしい

※共立エレショップで復活中。今だチャンス。

2008-07-26 09:32 nice!(0) コメント(21) トラックバック(0)

Interface誌 2008年9月号付録のあれを動かしてみる　 [NETWORK]

入手したので早速部品を取っ付けて、火を入れてみました。
勿論LANコネクタはDigi-Keyから早々に購入したあれで、基板からはみ出しているところに4本、LED用の足が出たままです。そのうちLEDチカチカでもさせてみますか。

あと電源LED（LED1）が未実装でしたので、実装して置きました。皆さんもそうでしょうけれど、あるべき所にあるべき物が無いと、なにか引っかかった気分ですっきりしない。本当は緑色のLEDが良かったけれど、1608のLEDの手持ちが赤色しかなかったのでとりあえず。

既にプロトコルが実装されており、ならばまず先にPINGを打ってみなければ。
えーと、あれ？。1472byteのPINGが通らない？？？。ではではもっとサイズを減らして512、、、駄目だ！。もっと減らして300、、、駄目だ！。200なら、おお！通った、通った。結局256byteまでは通るけれど、それ以上は通りません。バッファ小さいみたいです。
うーん、何処に問題が有るのか判らないけれどUDPでは十分注意した方が宜しい様で。※~~DNS~~DHCPできるのかなぁ。

※あれ？、でもWWWでは500byte弱のパケットを受け取っているなぁ。何故かコネクションの時にMSSを報告していないので、デフォルトって576byteだっけ？、それ位は受け取る用意は有るのかなぁ。

※動かしてみた方は知っているでしょうけれど、結構チップが熱くなります。放射温度計が無いので詳しくは判りませんがこれが風呂の温度だったら、江戸っ子が顔を真っ赤にして「てやんでぃ」と言いながら我慢しながら入る程度＠10Mbps。熱い風呂が苦手な私はパスと言う事で。100Mbpsの場合はもっと熱くなるらしいです。

※本を読むより先に部品実装して動かしてみたので、今更パラパラと本を読んでいます。
125ページの「いくらまさみ」さんの記事読みましたか？。３つ目の写真の文字、、、やりますね。やはりLCDに最初に表示するのはこれでしょう。ところでHUMANって何？。

※Navajo画像追加

詳解TCP/IP〈Vol.1〉プロトコル

作者: W.リチャードスティーヴンス
出版社/メーカー: ピアソンエデュケーション
発売日: 2000/12
メディア: 単行本

2008-07-26 01:05 nice!(0) コメント(82) トラックバック(1)

Interface誌2008年9月号付録基板で妄想してみよう２妄想目　 [NETWORK]

例えばここでやったGainerもどきですが、
http://hamayan.blog.so-net.ne.jp/2008-04-24

元々FLASHアプリにはシリアルと直接インタフェースする機能が無いらしく、その為gspと言うプロクシを立ててそこでtcp/ipとシリアル間の変換を行っています。この時のFLASHアプリが接続するネットワークパラメータは、IPアドレスは127.0.0.1、ポート番号は2000となっていたように思えます。

じゃあ、じゃあ、gspを経由せずに直接LAN上のデバイスにアクセスできるんじゃない？。

このボードには加速度センサーも搭載されていますし、新しいGainerの形態と言う事でやってみるのも面白そうです。

※きっとmasatoさんが試してみる様な気がします。