Repo
kjana00@gmail.com
2012-06-28 01:12:52
今朝はくもり。朝ごはんはパンとサラダとソーセージ。何か最近からすの人達が騒がしい。京橋でも仕事場の方でも……何かあったかね?
午後にレビュー会やるっていう資料を読んで突っ込み所を考えてみたり、考えた結果としてはまあそんなものかなという気分になったり。前に突っ込んだところは変わってないんだけど。まあ、瑣末事ではあるか。監視ツールなのか管理ツールなのかはっきりしろとか、そんなのだし。
それから昨日の続きを。デバッグ用に EEPROM 読み出せるようにしたんで、実際に読み出すスクリプトを書いて読んでみようと。……読めないね? …… EXCEL ワークシートのだと読めるね。……送ってるリクエスト見るとチェックサムが違うって、そうか、このチェックサム、ペイロードだけで計算するんじゃないのか。計算範囲を合わせたら通って返事が返ってくるようになった。で、これで 1 ブロック読めるようになったから、先頭から最後まで読めば全域読み出せるわけだ……とやってみたら何か刺さったり。
同じループで上限減らして 2 ブロックだけ読むようにしてみたら、最初のリクエストへの返事で 1 ブロックは読み出せるけど 2 ブロック目が読めないという良くわからない結果が。しばらくあれこれいじって、どうにもわからないんでどう返事を受け取ってるのかと確認してみたら、最初のブロック分はいいけど続くリクエストの返事として妙に大きな読み込みをしようとしてる。それは何でかというと、ヘッダ見たらペイロード長がそうなってるように見えたからで、何でそう見えるかというと、チェックサムはヘッダのペイロード長に含まれてなくて、かつペイロードの後に付いてるから、か。返事の読み出しがずれてるわけね。ヘッダの構造解析なんてこんなテストスクリプトでやるわけもなし、とか手抜きしてたから、関係無い値をペイロード長として見てた。1 byte 多く読んで、ファイルに書き出す分ではチェックサム分を削って吐くようにしたらちゃんと終わるようになった。
そうやって吐いたデータを見ると、何か 80 bytes で内容を繰り返してる。リクエストの方を確認してみたけど、ちゃんと送ってるアドレスは進んでいってる。実はこの EEPROM にそういう性質があって……とは考え難いなと見返してて、リクエストから読み出すアドレスを計算するところで間抜けなことをしてるのを発見。unsigned char をそのまま 8 bits 左シフトしてから bitwise OR って、それ単にアドレスの上位側を捨ててるだけです……キャストを追加して無事、まともに。
折角だから書き込む方も作ろうかとさくさくやって、こっちはそう大したトラブルも無く出来上がり。テストしようとしたところで定時のウィルススキャンが走り出して、読み出しの方が壊れたかと悩みかけたりしたぐらい。壊れるわけなくても書き換えると不安になります……それで準備は出来たかなということで、実際の EEPROM 管理周りに手を付けてみる。
こんな感じで導入しようかと方針を決めて、ちょっと書き出したぐらいで時間、ということでレビュー会に移動。それで大きな突っ込み所は無いと言えば無いけど、前の要求仕様レビューの時にした大体こんな感じっていう話からプロトコル案レベルで大きく離れてるところはやっぱり気にする人がいるわねという感じの展開。リテイクになったからあっちは更に遅れるかね。
そんな感じで今日はおしまい。帰ってフルーツパイを半分食べたりしつつのんびり、ぼんやり。果物はいいねぇ……それでちょっと寝た後晩ごはんにお造り三点盛ととろろ昆布のつゆと枝豆。このいかは微妙に今一つな感じ……って、買ってきて食べるまでに常温で置いといた時間が長過ぎたかも。
後は WWW 見たりゲームしたり。ボルドール倒すのに微妙に苦労して、対光対暗の指輪を手に入れた直後に光と影の盾を見つけて現状ならこっちのがいいなと買い込んだりする。それから闘技場でしばらくばたばたして、無理は止めようと思った辺りでお開き。それなりに順調、かな。