« 2010年7月 | トップページ | 2010年9月 »

2010年8月

2010年8月25日 (水)

帰省

先週の外仕事も、特にこれといったこともなく、無難に終了。
今日から今週いっぱいまで休み。
外仕事のおかげで、あちこちに分散する夏休みを消化する。
というわけで今週は、都内に帰省。

少し予定もあるのだけれど、久しぶりに秋葉原に行ってみようか。
色々仕入れたい物もあるし。

------

マウス用の新規部品は色々到着。

そろそろ、総重量10g前後の時代になってきたようなので、それなりのレイアウトを再構成。
外径7mmのベアリングさえ、重く感じるようになってきた。

stm32ですら、サイズが大きすぎる気もしてきたりとか。
もっと小さくて使いやすい石は無いものか?
この際、BGAパッケージでも...

なんだかんだと言っても、adxrs300だって、皆、実装して走らせていたし、やりゃあナントカなるのかも。

未だにこれだっ、てのは見つけられないのだけれど。

| | コメント (0) | トラックバック (0)

2010年8月12日 (木)

帰省

台風による雨の中、西に自走で帰省。

途中、車のエアコンが、どうにも利かなくなる。
動かなかったり、動いたり。
なんとか帰り着いたので、ちょっと見てもらう。

なんか、リレーが調子悪くて対策品があるとか?
それぞれのリレーを見比べると型番はまったく同じで、マーキングがちょっとついてるだけとか。

おいおい...

まあ、この車は結構走ってるから、どっかしら調子悪くなっても不思議じゃないんだけれど。
これって、設計上の問題だったりしないのかなあ。

| | コメント (0) | トラックバック (0)

2010年8月 8日 (日)

DHCP

週末はDHCPで悩む。分かってしまえば、チェックサムの計算ミスだったのだけれど。

チェックサム計算が、TCPでは正しく動くのだけれど、UDPではうまく計算できてなかった。
Wiresharkは、特にエラーを返してないようだったので、うっかり見落としてしまった。

ちゃんとアドレス取得できるまでには、もうしばらくかかるけれど、とりあえずサーバーからofferは返ってくるようになった。

| | コメント (0) | トラックバック (0)

2010年8月 2日 (月)

或る日のtelnet

telnetが通信途中でこける件について。

分かればなんてこと無い。いつものこと。

リングバッファに複数未処理パケットが有る状態で、割り込みで1個だけ処理して抜けてきてしまったのが原因。
定番のバグを仕込んでしまったようだ。
最初はポーリングで処理していて、ちゃんとバッファが空になるまで回すように作っていたのだけれど。
もしかして、取りこぼしがあるのかも、と思い、割り込みハンドラ内で処理するように変更したときにやらかしたようだ。

今のプログラムのバックグラウンドループは、平均で8usec、ワーストで220usec程度で回っているようだ。
ポーリングで処理しても、まだ問題なさそうに思える。

------

Ethernet MACの処理は、nxpのサンプルコードのまま。
このサンプルコードはよく出来ている。

この場合の、”よく出来ている”というのは、やたら凝ったつくりになっている、とか、ある種の美しさに満ちている、という類の話ではない。
ベタ書きのコードに限りなく近いのだが、ハードウエアの使い方が読み解きやすい、平易なコードになっている。
サンプルコードの役目として期待されるものに沿っていて、好感度高い。

サンプルコードと称して、やたら深い構造体の解析に付き合わされたり、どこまで追っても意味がよく分からない定数やマクロの海に泳がされたりするようなものが多い昨今、ありがたいことだ。

このサンプルコードでは、送受信のバッファサイズが、Ethernetパケットの最大サイズで定義されていて、そのため受信バッファとしては、4つしかブロックが存在しない。
最小サイズ付近のパケットがたくさん飛び交うようなときには、メモリの使用効率が悪くなる。
いや、もちろん、サンプルとしての分かりやすさを求めて、設定されているのだと思うけれど。

------

で、ようやくなんとなく動くようになったtelnet(受信側のみ)だけれど、実際のやり取りをパケットアナライザで観察してみる。

122byteほどのアスキー文字列を、lpc1769側に送信。
転送が終わるまでに、約220msecかかって、86個ほどのパケットが行き交っているようだ。(arpやsync、finとかは除く)
こんなもんかなあ?と思うのだけれど、内容を見ると再送要求だらけで、実際にデータの受け渡しに寄与しているパケットは、全部で8個しかない。半分はackだから、文字列を送っているパケットは4個だけ。

telnetの解説を見ていても、効率悪そう...と思っていたのだけれど、これは予想以上?
lpc側のプログラムをチューニングすれば、もっと良くはなるだろうけど。

まあ、telnetクライアント側が賢くて、もっとたくさんデータを送れば、サーバーの応答を観察して、だんだん効率のよい方法で転送を始めるのかもしれないけれど。

次は、標準出力側かな。
今度は大丈夫でしょう、多分....

| | コメント (0) | トラックバック (0)

« 2010年7月 | トップページ | 2010年9月 »