Repo
kjana00@gmail.com
2012-04-10 00:44:15
今朝は晴れ。朝ごはんはパンとサラダとソーセージ。変な夢を見てわけがわからない気分になったりして。変だったっていうのだけが強く印象に残る。何がどう変なんだったっけ……?
まあとりあえずお仕事ということで。先週末、試しに実装してみたやつ、ちょっと甘いところが残ってたなと直してから試そうかと思ってたけど、直してるうちにこの方法はどうあがいても一定以上の頑健性を得られないなというのに気付いてみたりする。応答以外に非同期のメッセージがあるから、稠密なストリームからメッセージを切り出すっていう感じの実装にしてみていたわけなんだけど、ちょっとどこがでずれが生じたら二度と復帰出来ない可能性がある。たまたまメッセージヘッダのコードとペイロード長に似たシーケンスが出て来たら困るねっていう。後でペイロード長はメッセージヘッダのやつじゃないの使えば大丈夫な気がしたりはしたけど、それも気のせいでやっぱりだめ。間違って受け入れられることが少なくなって廃棄されるようになるだけね。
修正前のコードは一度の read で受信するのはメッセージ境界で区切れたメッセージだっていう想定は変だけど、リクエスト-レスポンスの形の部分だけ見たら修正後のコードよりよっぽど頑健。リクエスト送信前に UART のバッファをハードウェアレベルからクリアしてるから、非同期なメッセージが無い限り受信出来るのはレスポンスのヘッダからになるし、メッセージが壊れてたり余分なバイトが付いてたりしても一つのリクエスト-レスポンス内で閉じる。やっぱり、前にちょっと思った通り、非同期な通知には GPIO 使っておいて、UART 通信はリクエスト-レスポンス型に限定しておいた方が簡単で頑健か。
そういうことで、そっち方面に方針を転換。さすがに部分的に受信した場合や余計なバイトがある場合を全く無視してただ read っていうのはあれだから、送信したリクエストに応じたレスポンス長丁度だけ読むようにして、受信したレスポンスもヘッダぐらいはちゃんと見て正しいレスポンスであることを確認して……というのを付け加えるのが面倒臭くて見通し悪いんで書き直す。二つのスイッチに二つのタイマーで、送信したら受信タイマーキックして、受信が終わるかタイムアウトでレスポンスを処理して送信タイマーキックして、という感じ。
サブマイコン側はそれでいいとして、メインマイコン側はどうしようかなとちょっと考える。検出したエラー毎に GPIO でシグナルするのはいいとして、どうやってやろうかと。一応、複数のエラーが検出される場合があり得るし、そうでなくてもサブマイコンがエラーのレポートをリクエストする前に次のエラーを検出する場合があり得る。じゃあ、キューに入れといて、何か入ってたら GPIO でシグナル、リクエストに応える時にシグナル落すでいいかな……いい気がする。キュー自体は UART 用に用意したやつを使い回せるからそれで良し。前にレポートを直接送信してた関数がキューイングだけするようにして、周期タスクで空じゃなかったらシグナルするようにして出来上がり……だけど大丈夫なんだろうね?
前から全然問題無さそうな修正で壊れるようになったりしてるからな……とびくびくしつつ試してみたところ、どうやら無事、思った通り動いてるらしい。良かった、とほっとしたところで今日はおしまい。帰る途中で、キューに複数のエラーがある場合に前のエラーに対するリクエストを片付けるまで次のエラーの処理は待たなきゃいけないっていうのを思い出したりはしたけど。そのためにキューイングするようにしたんだろうに。とまれ、帰って晩ごはんに冷奴と豚汁うどん。今日は 18℃ だって。極端な。こう気温が乱高下してくれると困るわ。おかげで冷奴はおいしいわけだけど。
後は WWW 見たりゲームしたり。こう派手な負けっぷりだとあきらめも付き易いですわねとか、こんなひどいミスしても勝つ時は勝つけどなとか、えいやで 24 階のランダムクエストに挑戦したらリッチにひどい目にあったとか。全然ダメージは痛くないけど、延々ととどめを刺せない内にテレポートで逃げ回られつつ罠を大量にばらまかれると心が折れそうになるわ……