Repo
kjana00@gmail.com
2012-01-12 01:26:27
今朝は晴れ。朝ごはんはパンとサラダとソーセージ。いつもと同じぐらいに出たらちょっと早めに着いたりする。打刻するのに PC の電源入れて、なんていうのが無い分。相手が打合せ中だからと待たされかけて、ひょっとしてその打合せってこの面談のことじゃないのと確認に行ったら見事にその通りで危なかった……ということで業績マネージメントの中間面談。まあ、仕事の方は大体そんなもんだろうっていう感じなので、ということであちらさんはどんな感じとかいう雑談っぽいので終わったり。
で、出先に出ていつもの仕事。まずはエラー周辺のちょっとした問題を片付けちゃいましょう。現状、通信エラーを検出して通信回復待ちへ移行するっていうのがどの状態でも同じように起こるようになってる。で、緊急停止状態だの外部機器の起動待ちだのでもそっちに落ちるっていうのは問題なんで、通常動作の時だけにしておきたい、と。実現自体は簡単なんだけど、どこにガード入れるのが正しいだろうねという悩み。各状態でエラー検出した場合、ってやってないからねぇ。そういう実装だったらそもそも悩む必要すらないわけだけど、今度は同じ記述があちこちに散ることになる。それはそれで何か嫌だな、と。そういうことでどこでこの状態遷移起こしてるかなっていうのを真面目に調べたら、結局エラーを検出した時にそのハンドラで動かしてるだけだった。んで、そこにガード入れておしまい。
もう一つ、この通信回復待ちの状態だと出力経路のスイッチが閉じるようになってて、それで外部機器の状態がわからなくなってもわかってる入力で出力を維持してるんだけど、通信回復で通常状態で戻る時に状態遷移の初期化ついでにスイッチ切っちゃうんで出力が途切れるっていう問題がある。これはまあ、初期化するんじゃなくて、このスイッチが閉じてる状態から動き出すようにすればいいわけだ。ということでその状態に直接入るようにして出来上がり。実は使ってた方の入力が切れてたっていうんだと外部機器の方に入力が切り替わる。まあ、これもこれでいい、はず。実は二系統の入力が両方とも切れたらマイコンの電源も落ちるから手動での再起動がいるんで考える必要無いっていう説もあったりはするし。
そんなことしてたら、この外部機器ってコントローラに三つモジュールぶら下げて管理してるわけなんだけど、このモジュール番号の指定も無ければ応答に番号が入ってるわけでもないモジュールデータ要求に対する返答って一体何なんでしょうという質問に答が返ってきてたんで確認。全然別の、コントローラに投げると全体情報を返してくる要求を個別のモジュールのアドレスに投げるとそれぞれの情報を返してくれるんですって。……何だそれ。つまり仕様書に書いてあるモジュールデータ要求って全然、意味無いんですね……
とりあえずということで簡単に実験してみたらどうもタイムアウトしちゃってしょうがない。やっぱり違う要求なんじゃないのかと疑ったりしたものの、応答に入ってるペイロードサイズは正しいんだね。マイコン側で小さめに返答を受け取るようにするとちゃんと受け取れる。うーん……ってしばらく悩んでたけど、結局マイコン-外部機器間の応答受信に使ってる DMA バッファ長が足らないから完全な結果を受け取れなくなってたというだけだったりして。これは間抜けが過ぎる……とりあえずの実装ということでサブマイコンからの要求をちょっと増やして割り当ててみた。ad-hoc 過ぎるけど面倒臭いからこれで済ましたい気もする。リクエスト番号の割り当てはともかく。
明日出荷するというからデモ用のプログラムをちょっと書き換えたところで今日はおしまい。何か急に冷えてきたんで晩ごはんはおでん。あったまる。それはおでんじゃなくてちぎり天の煮物ですという意見は聞かないことにする。おいしいからいいじゃないか、と。
後は WWW 見たりゲームしたりちょっと寝たり。35 階まであちこちで降りてレベル 35 になって、また忍者だから使えないアーティファクトをいくつか拾って。チェインメイルもロングソードもだめなんだってば……盲目耐性をようやく得たのが一番の収穫かも。テレパシーが落ちるのがちょっと痛いけど。