Repo
kjana00@gmail.com
2012-05-25 00:53:57
今朝は晴れ。朝ごはんはパンとサラダとソーセージ。やたらと良く眠れてしまうのは何でだろう……気を付けないと、寝過しそうだ。
こっちのに入れ替えて下さいと Office のメディアを渡されて、手抜きして修復インストールで構わなかったりしないかと試してみたけど予想通りだめで、アンインストールしてから再インストールという手順を踏み直すはめになったりして。つまり一回、余分な手間が挟まっただけなのではないだろうかという。
ちまちま環境整備ばかりしてるのも何だからと次に向けてメインマイコンとサブマイコンのやり取りを考えてみる。リクエストとその処理っていうのはもう作ったけど、それをどういうタイミングでサブマイコンから送信しようかと。今、通信に使ってる仕組みは定期的にラウンドロビンで選んだリクエストを送るっていうのを基本に、メインマイコンからの GPIO 通知だのテスト依頼のためだので定期的なリクエスト送信をたまに上書きするっていう方法。しっかりキューイングしてるわけじゃないけど。短時間に定期リクエスト外のリクエストが繰り返されると最後のだけが送られる。
それはそれで構わないって言えば構わないんだけど、複数台での協調動作用状態操作リクエストもその仕組みに乗せるっていうと、操作して結果を確認して操作を進めてっていうことになるんで出力が切り替わるまでに 1 分ぐらいかかるのだよね、多分。ラウンドロビンの周期が 20 秒ぐらいで、今の予定だとそこに切り替えに使う情報収集も乗るから。
それで問題が無いような仕様になるなら気にしなくていい。でももうちょっときびきび動いて欲しいというようなことになると、せめて定期リクエスト外のリクエストは周期と無関係に送りたいなということになる。応答の受信が複数回の read になってもいいように仕組みは作ってあるから、単に送りたい時に送るっていうだけだと何かまずそうな気がする。
で、つらつら考えて、アプリケーションレベルでは送受信がインターリーブしないように出来るから、割り込ませるリクエストがある時はそれを投げて応答待ち、無かったらタイマーを待って定期リクエストを送信して応答待ちっていうことで良さそうだという結論へ。まだ何か穴はありそうだけど。応答待ちの時には busy 返さなきゃならないなとか、返されたら次回に進む的な何かがいるけどどう突っ込もうかなとか。
そんな感じで終わっておいて、帰って晩ごはんにとり汁のそばと枝豆。水菜を食べるためには、で何ですぐに思い付くのがそばなのかは謎。まあ、おいしいしね、そば。
それで後は WWW 見てゲームして、で。とりあえずダークエルフの王以外の 25 階クエストをさくさく片付けるまで。アゾクも柳じじいも割合あっさり倒されてくれて助かった。AC 140 越えると楽ね。それでも喰らうのは喰らうし、下手に普段が余裕なもんだから、うっかり死にそうになるとそのまま死んでしまうというのが今までの経験だったりはするわけだけど。