Repo

kjana00@gmail.com

older <-

2011-04-28 02:33:35

今朝は晴れ。朝ごはんはパンとソーセージとサラダ。トマトが無くなるんだけど明日どうしようかね?

のんびり文書書きかと思ってたところに電話。検証の方でいじってると緊急停止状態に落ちるんだけど、っていう。更にわかってたことだけど完全には同期が取れてないっていう話が。で、後のは複数パケットから成る情報について、その内の一つでも届いたら送り手の外付けモジュールからの今回分の情報は得られたってしてる手抜きのせいなのが明らかなんで、前のやつを先に調べてみることに。見当も付かないからねぇ。

それで調べてたらこんな風に動かそうとすると、って向こうが言ってる手順以前にただ起動しただけでも故障自体は検出してるのがわかったりする。状態遷移させてないから緊急停止状態に落ちないっていうだけ。しばらくあれこれ悩んでみてたらしまいに故障検出が情報を得るのに使ってる関数だけ外付けモジュールを使う場合には不要になるモジュールの情報をそのまま使ってたという落ちが。不要だからメモリ節約のために中身を削った変数だもんで、当然、まともな値は入ってない。……そりゃ、無理よね。故障を検出もするわ。

直してやって、まあこれが原因と見ていいだろうと思ってたところで実際に向こうでやろうとした状態遷移で問題無いことまで確認したいよねっていう話が出る。ICE で動かしてるし、入力も適当だしで結構面倒なことになると思うんですけど……案の定、まともに動かす準備だけで結構な時間を取られた。まあそれで途中まで動かせることを確認出来たからいいって言えばいいんだけど。

ここまでのところでまとめて ROM イメージ作ってメールを送っておいて、それから同期の問題の方に移る。結局複数のパケットから成っているっていうのを真面目に扱えばいいわけで、まあ数えたらいいかな、っていう。単に数えるんだと同じパケットがたまたまタイミング被ったらまずいというのがあって、結局パケット毎のビットフラグを使うことに落ち着いた。

最初はフラグ変数中の 1 を数えてパケット一つ辺りの情報数を掛けて、とやったけど、それだと常に全部埋まってるわけじゃないからやっぱり受信してないパケットがあるまま情報をまとめることになるなと考え直し。個々の外付けモジュールがいくつ情報源を持ってるかはわかってるんで、モジュール毎のビット数 × 情報数に上限を付けて合計しましょうという方向へ。それでとりあえずいいかなと思いつつ動かしてみると、とても謎な動作をしてくれて困ったり。何で同期信号に対応するパケットでだけフラグ立つようにしてるのに、まとめた情報の途中で明らかに前か後のフレームの情報が入ってるかね?

まあパケットを受信してバッファに保存するところまでは割り込みで動いてるから、後で数が揃ったのを確認してからアプリケーション側に情報をまとめてる最中に割り込まれる可能性があるのはわかるんだ、と割り込み禁止にする API を使ってみたけどまだ解消しない。これ、デバッガで見てるとほとんど起こらないからデバッグし難い……もう大丈夫なのかと思った頃にやっぱり再現したりするし。

原因になりそうなところって言うと、同期信号を送るところかなとそっちも割り込み禁止にしてみる。同期信号でフレームを切って、フレーム番号が対応してるパケットを受信したらフラグを立てましょうという方針だから、同期信号に乗ってるフレーム番号と自分が持ってるフレーム番号は一致してないといけないし、フラグのクリアもその時 atomic に実行しておかないといけないはずだから。でも解決しない風。モニタプログラムで見てると保存してるログでは平気でも、途中で止めた時表示上で後のフレームの情報が混ざる。

……というので延々と悩んでみたけど、どうも保存されるログには全然現象が出なくなったよなというのでちょっと思い直す。止めた時の表示って、単にモニタが受信した瞬間の値だよな、っていう。このモニタプログラム、表示する情報をやっぱり複数のパケットで受け取ってるわけで。ログ出力はちゃんと全部集めてからでないと出さないけど、画面表示は受け取ったパケットをすぐ反映するんじゃなかったっけ?

そういうことで出来たことにして色々してメール。またすっかり遅くなった、と思いつつ雨の中帰る。晩ごはんは近所で塩ラーメン。太めのしこしこした麺にさっぱりとしたスープが良いのです。甘くない煮卵もおいしい。それで部屋に戻ったら WWW 見てておしまいな感じ。だいたい大阪駅着いた段階で 0:00 過ぎてるとか大変によろしくないわけで。

older <-

goto

hint can be:

Tags

old

2007-05 -- 2006-12

ゲーム関係の古い記録

before 2005-12