2011年12月28日水曜日

「アクア」ってもう発売になったんだね。

トヨタの新しい小型ハイブリッド車「アクア」って、2011年12月26日に発売になったんだね。来年の春頃かと勝手に思ってた。

クルマで通勤するようになって、エコカーにグッと惹き寄せられています。なんてたって燃費の良さ。調べてみると、プリウスなんかでも上手に乗る人だと30km/Lくらい出るそうじゃないですか!以前の2スト原チャリ並み?アクアはカタログスペックでもプリウスを超えているから、そのくらい出ることは期待してもいいんじゃないかな、と思う。

で、どうするか>俺。

現在、毎月のガソリン代が約5万~6万くらいかかってる。できるだけエコ運転を心掛けているとはいえ、3500ccのムラーノ君では現状の12km/Lがせいぜいのところ。どんなに頑張っても13km/Lはいきそうにない。車検がまた来年に迫ってるから、お金もないのに乗り換えた場合のシミュレーションなどを勝手に嫁にナイショでやってみる。

アクアでの実燃費を30km/Lと仮定。今ムラーノで12km/Lで月5万円のガソリン代だから、乗り換えた場合は
 5万円 × (12 ÷ 30) = 2万円
となる可能性あり。つまり、毎月3万円ずつ浮く、という計算皮算用。

アクアの購入費用を考える。どのグレードを選ぶかによって多少変わってくるけど、オプションやら諸費用やらでだいたい200万とする。すると、その200万を毎月3万円の浮いたお金で償還すると・・・

 200 ÷ 3 ≒ 67ヶ月

となる。つまり、5年と7ヶ月で元がとれる、ということになる。更に、自動車税や保険なども安くなることを考え合わせると、もうちょっとくらいは早く元がとれそうだ。ムラーノを下取りも考えると、実際に必要な資金はもっと抑えられる。

う~ん、本当に5年程度で元が取れるなら、もっと前向きに考えてもよいような気がする。

問題は、まだまだ乗れるクルマを手放すことに対する罪悪感(のようなもの)と、ムラーノがそこそこ気に入っていること、この点についてどう気持ちの整理をつけるかだなあ。要は、自分の気持ち次第ってことか・・・。


2011年12月21日水曜日

確か電力が足りなくなるはずじゃ・・・

なかったっけ?>関西電力さん。

12月19日以降の節電を呼びかけをしていましたよね?確か原発が定期点検に入って発電量が落ちるからとかどうだとか。
ウチにも2回に渡ってわざわざ「節電要請」のためだけにDMが送られてきていました。そのDM代も電気料金に跳ね返っているはずだよね~。

で、今日12月21日の状況はというと、確かにほとんどの原発は停止しているようです。唯一稼働しているのは、高浜原発の3号機だけで発電量は定格87万KWに対して107%の出力なので、だいたい93万KWくらいでしょうか。もしこれも止まったらどうなるのか・・・。

というわけで、12月19日を挟んで前後1週間程度の供給量と使用実績を調べてみました。すると・・・

日  使用実績/ピーク時供給能力(単位:万KW)
12日(月) 2236/2724
13日(火) 2200/2653
14日(水) 2150/2686
15日(木) 2175/2674
16日(金) 2316/2800
17日(土) 2079/2686
18日(日) 1990/2529
19日(月) 2265/2782
20日(火) 2275/2777

ん?・・・・

余裕じゃん!

期間中の最大電力使用量が2316万KW。原発定期点検に入ると言われていた19日以降の供給能力も2780万KW程度あるし、現在まだ稼働している高浜原発分を差し引いても2700万KW程度の供給能力はあるようだし。

と、い・う・こ・と・は・・・。

やっぱり原発なくてもやっていけそう!

ということにはならないのかな?

(ならないのだろうな。いろんな利権を持った人たちがいるし・・・。政治家ってのは、そういう利権を持った人たちの顔色をうかがうのではなくて、住民が望むこと、良かれと思うことをやってくれるものだと思うんだけど、ブツブツ)

2011年12月19日月曜日

ブロッキング代入

もとい。
「代入」ではなくて、「購入」。つまり、「ブロッキング購入」。

何のことかと言えば、今朝のコンビニでの出来事。
いつものように昼食用に弁当を買おうとしていたら、店員が弁当を補充していた。私が弁当を探そうと後ろから覗き込んでいたのだけれど、その店員は弁当の補充作業をやめないから、どんな弁当があるのか見えない。私の存在に気づいても作業をやめようとしない。

確かに弁当を補充する作業はあなたの仕事だし、一生懸命やっているのは分かるけど、こういう場合私が弁当を欲しているかどうかを確認していったん場所を空けるなどの配慮をするのが本来のサービスのあり方ではないだろうか?
「このお客さん、弁当を探しているのではないか?商品を選ぶじゃまになっていないかな?」くらいの気を利かせてもらいたいものだ。

そういえば、近くの別の鉄道系コンビニにも似たような店員が居るなぁ。こちらは弁当ではなくて、飲み物。私が飲み物を物色しようとしても知らん顔でずっと飲み物の補充をしている。商品を選ぶまでにそんなに時間はかからない。せいぜい15秒?30秒?そのくらい待ってから、客足が引いたときに補充するとか、そういう機転を利かないものか・・・。
まったく別の地域のコンビニでは、「あっ、すみません!」といってスッとあけてくれたけどなぁ。それとも、このあたりの地域の人間はみんなそんな感じなのだろうか。

まあ買えたし、いいか(当たり前!)。でも会社に到着するのがギリギリになってしまった。

2011年12月12日月曜日

スウェーデンハウスでの初めての冬

いやはや寒くなってきました。今朝はこの冬一番の寒さだったのではないでしょうか?
クルマは前も後ろもガラスが完全に凍っていて、出かける前にぬるま湯を掛けたはずなのに、クルマに乗り込むときにはもう凍っていました。

さて、スウェーデンハウスに引っ越して初めて本格的な冬を迎えています。「夏涼しくて、冬暖かい」と聞いていましたが、実際のところ夏はかなり暑かったです。エアコンの控えすぎケチりすぎかもしれませんが、まだエアコンを有効に使えていないのでしょう(電気代の請求が怖くて・・・)。でも前に住んでいたマンションの方がよっぼど過ごしやすかった。まあ、高層階だし、北から南まで窓を開けっ放しにできるという点では一戸建てと比べるのは酷な気がしますが。

そして、冬はというと、これまたちょっと寒いような気がします。少なくともTシャツ1枚&裸足で・・・とはいきませんね。
でも、リビングにある温度計を見ると低くても17~18℃くらいはあります。夜暖房を切って、朝方でそのくらいです。今朝も出勤中のクルマで温度計を見てみると-1℃の表示だったので深夜から早朝は零下になっていたことは確実ですが、部屋はだいたい18℃くらいでした。これって、スウェーデンハウスの断熱性が効いている、ってことですかね?最近の住宅だったら、どのハウスメーカでも同じくらいなのではないか?と勘ぐったりもしてみますが、比べてみたことはないのでスウェーデンハウスがいいのかどうかは分かりません。他社で建てたお宅ではどんなものなのか、知りたいな~。
(築50年以上で柱も歪んだすきま風だらけの実家なら10℃以下は確実なんだけど、それと比べて勝っててもうれしくないな)

2011年12月2日金曜日

WebSocketについて調査中・・・

いまさらWebSocketの存在を知る。
これだ!まさに求めていたのはこれだった!
これを使えばWEBサーバから高速にデータを吸い上げることができる!

と思ったけど、仕様がまだ完全に固まっていないんだね。ブラウザの実装状況もまだこれからという感じかな。
でも非常に期待できる技術なので、PCをサーバ代わりに仕立てたWebSocketサーバをサクッとC++とWinsockで書いてみた。

まずは、OpenHandshakeがうまくいかない。参考にしたblogはDRAFT76に関する記述だったので最初のハンドシェイク部分が違っているようだ。すくなくともChrome14とは合わない。
調べてみると、Chromeから送られてくるのはSec-WebSocket-Keyヘッダであって、Sec-WebSocket-Key1やSec-WebSocket-Key2というものは無い。どうやらHybi-7あたりでハンドシェイクの仕様が変わったようだな。そうか、Chrome14はHybi-7(Hybi-10)対応なのか・・・。

というわけで、SHA1を使ったKeyのハンドシェイクも実装した。BASE64エンコード処理でちょっとバグったけど、なんとか修正してハンドシェイクが通るようになった。

そして次はPayloadのフレーミングの実装だ。とりあえず送りたいデータはバイナリなので、バイナリフレーム(82h)から始まるデータを送ってみる・・・。Chromeのコンソールに何か出てる!と思ったら、「バイナリフレームはまだ対応していない」とか何とか・・・。うーん、まだ仕様が新しすぎてブラウザの実装がついてきていないんだね。
と思ったけど、ChromeはVer15になっていることに気づいてアップデートしてみると、すんなりバイナリフレームを受信した!onmessageに受信イベントが来るようになったぞ。

ついでに、Firefoxでもやってみる。
まずWebSocketオブジェクトが無いと怒られる。そうだそうだ、セキュリティの関係からWebSocketはMozWebSocketという名前に変えられてしまったんだっけ。
今度こそ!と思ったが、やはりバイナリフレームは来ない。試しにテキストフレームを送ってみると、ちゃんとonmessageにデータが来てる!そうか、Firefox8は、Hybi-10対応みたいだけどバイナリフレームは未実装なのか・・・。

というわけで、まとめ。

Chrome14/15、Firefox8はHybi-10対応している。
しかし、バイナリフレームに対応しているのはChrome15だけ。

ということが分かった。

2011年11月24日木曜日

恐るべき蚋

いま、両足首が非常に腫れて痛い。歩くのも億劫だ。
犯人は「蚋(ぶよ)」。昨日、かねてより気になっていた庭の芝刈りをしたのだけれど、もうこんなに寒いから蚋は出ないと思っていたが甘かった!
もちろん長袖・長ズボン(ジーンズ)で作業していたのだけれど、裾の隙間を狙って咬んでいたようだ。
蚋に特有の症状で、昨日はちょっと痒いな~、くらいだったのが、今は座っていても足首がズキズキ痛むし、目で見ても明らかに腫れている。
歩けないくらいになったら困るな~。寒くなっても侮る無かれ!「蚋」

2011年11月16日水曜日

GCCでCortex-M3開発

やっぱり学習能力がないなぁ>私、orz

この問題は1年半くらい前に引っかかったはずなのに、また今回ハマった!

「GCCでCortex-M3用のコードをはき出させるとHardHalutになる件」

結論から言うと、binutilsのリンカがthumb命令のBLインストラクションをBLXに変換してしまうのが原因。Cortex-M3はthumb2命令に対応してるとはいえ、オフセット値を引数に取るBLX命令はサポートしていないんだよなぁ。GCCやLDで-mcpu=cortex-m3 -mthumbを指定しているにもかかわらず、この変換をしてしまう場合がある。で、(再び)いろいろ調べてみた・・・

時間をかけて調べるといろいろと勉強になる。特に今回はリンカは結構いろんなことをやっていることを実感した。
関数呼び出しなど分岐が発生する部分でGCCがはき出すコードはBL (-1)という命令だけ。その-1のところはLDが各関数のロケーションが決定した段階で適宜埋める、という仕掛け。これは、普通に想像できる範囲でした。
ARMの場合ややこしいのは、ARMモードとTHUMBモードの切り替えが存在するということ。LDはそのモード切替が必要と判断したら、GCCがはき出したBL (-1)の部分をスタブへのブランチ命令に書き換えて、そのブランチ先のスタブでARM<-->THUMBモードの切り替えと、目的の関数へのブランチを行うようになっている。更にBL命令ではPC相対で前後2^24ビットまでの範囲でしかジャンプできないから、もしその範囲を超えるBL命令であった場合もいったんスタブへブランチさせて、その中でBL Rn命令を使って任意のアドレスにジャンプできるようなコードをLD自体が生成する。ELFファイルに含まれるアドレスのアトリビュートはもっとたくさん種類があるのだけれど、おおざっぱに言って、そういうことをやっているようだった。

さて、今回のポイントはCortex-M3でリンクするときにBL命令を勝手にBLX命令に変更させないようにすることだ。調べてみると、binutilsのbfd/elf32-arm.cにusing_thumb_only()という便利そうな関数が用意されている。この関数がTRUEを返すときはCortex-M3用だと(勝手に)思い込ませて、BL->BLX変換やTHUMB->ARMモードへの移行を起こさせないようにパッチを当てる。ついでに、THUMB<-->ARMへ移行するようなスタブの生成も抑制する。

という訳で作ったパッチがこれ。ちょっと強引かな~。Cortex-M3専用ということでご勘弁を。


--- binutils-2.21.1/bfd/elf32-arm.c 2011-05-11 16:29:12.000000000 +0900
+++ binutils-2.21.1patch/bfd/elf32-arm.c 2011-11-16 17:58:46.718879900 +0900
@@ -3138,7 +3138,12 @@
   || (r_type == R_ARM_THM_JUMP24))
       && !use_plt))
  {
-  if (st_type == STT_ARM_TFUNC)
+ if (thumb_only) {
+ stub_type = 
+ (THM_MAX_BWD_BRANCH_OFFSET <= branch_offset && branch_offset <= THM_MAX_FWD_BRANCH_OFFSET) ? 
+ arm_stub_none : arm_stub_long_branch_thumb_only;
+ }
+ else if (st_type == STT_ARM_TFUNC)
     {
       /* Thumb to thumb.  */
       if (!thumb_only)
@@ -7556,7 +7561,8 @@
        the PLT do not require stubs.  */
     if (sym_flags != STT_ARM_TFUNC && sym_flags != STT_SECTION
  && (h == NULL || splt == NULL
-    || h->plt.offset == (bfd_vma) -1))
+    || h->plt.offset == (bfd_vma) -1)
+ && !using_thumb_only(globals))
       {
  if (globals->use_blx && r_type == R_ARM_THM_CALL)
   {

日本の好きなところ

先日コンビニで買い物をしたとき、うっかり飲み物を持って帰るのを忘れてしまったことがある。レジでお金を払った後、何も考えずにそこにある商品の入った袋を持って出る、というルーチンワークになっている人が多いと思うけど、そのとき店員がお茶を袋に入れてくれていなかったようだ。
これに気がついたものの後の祭り。高速道路上のコンビニだったので、気づいたときはもうSAから出ていたし、それに高速も出ていたのもう戻れない。損した!

数日後、同じコンビニに行ったとき、ダメもとで「先週買い物したときお茶を忘れたんですが・・・」と言ってみた。すると、お茶の商品名をきいた店員はそそくさとその商品を取りに行って、それを袋に入れてくれた。よかった、損をせずに済んだ。
でも一瞬思った。確かに持って帰るのを忘れた私が悪いんだけども、こういうときは「申し訳ありません。直ぐに代わりの商品を用意します」というお詫びがあるのが普通だと一瞬は思ったけど、ちょっと待てよ、中国はもちろん、アメリカやヨーロッパなんかでも「そんなの忘れる方が悪いんだ!知るかっ!」と突っぱねられて当然だよな。それを何も言わずに代わりの商品を用意してくれただけで、それはグローバルな目線で見たら非常にありがたいことなんじゃないか、と思った。
日本という国のそういうところが、好きだな~。

閑話休題。

週末に家族で温泉旅行に行こうと計画し、旅館も予約していた。しかし、子供が急に病気になって週末までに直りそうもないので、泣く泣くキャンセルすることに。旅館に電話すると、非常に事務的な感じで「3日前ですからキャンセル料が20%かかります」と言われてしまった。何もサービスを受けていないのにお金を取られるなんてクヤシーッ!!
確かに予約するときにはキャンセル料がかかることは承知している。それがルールだ。でもだからと言って、「キャンセルしたらキャンセル料がかかることはメールに書いてましたよね?」と後ろ盾を持って事務的な言われ方をされたら、やっぱり気分は良くない。当日や前日夜にキャンセルしたのなら料理の仕入れや空いた部屋の損失のことを考えるとキャンセル料も致し方ないと思いますが、まだ3日ある。他のお客さんが入る可能性も高いと思うんだけどな。
プランがなかなか良さそうだったので子供の体調が戻ったら今度こそ同じ旅館で・・・と思っていたけど、いくらこちらがキャンセル料が発生することを承知していたとはいえ、こういう対応ではどうも後味が悪くて、もうその旅館を使うことはないだろう。そういう意味ではこの対応は旅館としては良かったのかどうかと思うところ。
こういうところでちょっとした気遣いができるのが「旅館」というカテゴリに属する施設の暖かいところ
であり、そして日本的で好きなところだったのに、ちょっと残念だな~。

(それにしても、約10000円をただドブに捨てるのはイタイ・・・)

2011年11月4日金曜日

オイル交換で・・・

私は日産のクルマに乗っているんですが、引っ越し先のディーラーとも接点を持っておきたいと思って、半年くらい前にオイル交換を目的に初めてディーラーを訪れたときのこと。

その店は、「○○日産自動車販売」という販社で各都道府県毎にあるような大手のディーラーだった。オイル交換の金額を尋ねると、正確な価格はうろ覚えだけれど8000円いくらかと言われたので高いなーと思った記憶がある。そして矢継ぎ早に、「メンテナンスパックプロに入ってはどうですか?」と訊かれた。メンテナンスパックプロ12だと、2回のオイル交換と半年+6ヶ月点検がついて18900円だから、オイル交換2回分+チョイ足しで2回の点検がついてくる、と聞いて、なるほどお得だなとそのときは思ったので、つい加入してしまった。というか、引越後は通勤で毎日乗るし、走行距離も半端じゃないのでディーラーで診てもらえば安心だな、とも考えていたので、メンテパックプロに加入したこと自体はそれなりに納得している。

そして12ヶ月点検をしてもらうと、ブレーキパッドが残り3mmくらいになっている、と言われた。確かにこのクルマに乗り出してから一度も替えてないので少なくなっていること自体は予想通りなんだけど、ディーラーのセールスもメカニックも「ブレーキパッド替えた方がいいよ~。あといくらもつか分かんないよ~」という間接的なプレッシャーをかけてくる。パッド交換となると更に4万円くらいかかるみたいだし、まあもともと10mmくらいのものが残り3mmもあるならまだまだ乗れると思うので、そのときは丁重にお断りした。

さて、それから半年くらい経ったとき、もうメンテナンスパックのオイル交換チケットは無くなったので、次のオイル交換はどうしようかと。何せ、うろ覚えながらそのディーラーでは8000円いくらだと言われたので、いくら何でもそれは高いんじゃないかと。実際、引越前にいった「日産プリンス○○販売」という別系統のディーラーでは3400円でオイル交換してくれた。この金額差は何なんだ!?
幸い、引っ越し先にも日産プリンス系のディーラーがあるので、電話して確認してみるとオイル交換は3400円だか4900円だかでやってくれるとか。う~ん、前のディーラーではうまく口車に乗せられたのかな~、という疑念がフツフツと沸いてくる。というわけで、今回はちょっとディーラーを代えてオイル交換してみようかと。
確かにこちらのディーラーでは3400円でオイル交換してくれた。カー用品店なんかではもっと安くやってくれるのは知っているけれど、安心感が欲しいので3400円なら納得の範囲だ。ついでに6ヶ月点検もやってもらった。すると、ブレーキパッドの残りは3~4mmくらいだと言われた。んっ?半年前よりもブレーキパッドが増えている!そんなバカな。
ここでもやはり、以前のディーラーには担がれたかな~、という不信感が。しかも、今度のディーラーはこれくらいならあと半年はもつんじゃないかな?的な感じで、「パッドを替えろ~、替えろよ~」というオーラがまるで無い。単に無責任なのか、それとも良心的なのかは分かりませんが、私的にはこの新しいディーラの方がやりやすいかなぁ。パッドの交換時期はある程度は異音で判断できるし、やはり高いものなのでできれば危険が及ばない範囲でできるだけ長く使いたいし。

というわけで、○○日産自動車販売さんとはバイバイして、これからは日産プリンスさんのお世話になろうかな~。

2011年11月1日火曜日

REX-USB60用ドライバ

これを書いているノートPC(Let's note S9)にはシリアルポートがついていません。というか、いまどきシリアルポートがついているPCの方が少なくなってしまったのではないか?と思えるくらいです。特にノートPCでは。人によっては“シリアルポートってなぁに?”という声すら聞こえてきそうですが、やはり組み込みをやってる人種としてはいくら通信速度が遅いといえども捨てがたいインターフェースなのです。

で、USB-シリアル変換器の出番。

今ではあまり気にする必要はないのかもしれませんが、その昔(と言っても数年前ですが)はとりあえず動くもののちょっと動作がおかしかったり、シリアル接続モデム以外の用途で使うと動かないUSB-シリアル変換器がありましたので、そのメーカと品番選定には注意していたものです。そのなかでも、なかなかマジメな作りと安定した品質で好きだったメーカはRATOCシステムさんで、USB-シリアル変換器もREX-USB60というモデルを愛用していました。
しかし、ノートPCをLet's note W2からS9に新調したときにOSがXPからWin7 x64に変えてしまったので、このREX-USB60が使えないという事態が発生していました。どうもRATOCさんは後継モデルのREX-USB60F(おそらくFTDIの石を使っていると思われる)に移行してしまったようで、旧版のF無しREX-USB60用のx64対応ドライバは用意してくれそうになく、この変換器はほとんど死蔵状態でした。

しかし、ひょんなことからblogとかの情報で「REX-USB60はPL2303というチップを使っているらしいので、そのPL2303用のドライバを使い回せる」ということを聞き、さっそくProlificのHPからダウンロードしてinfファイルを書き換えて試してみるも撃沈!infとドライバは読み込んでくれるものの、「ドライバを開始できません(エラー10)」というエラーでドライバが開始されないということになってしまった。HPの情報から総合して考えると、おそらくProlificとは異なるVID/PIDに書き換えられたサードパーティのUSB-シリアル変換器では同じPL2303チップを使っていてもドライバが撥ねてしまうように作っているのだろう。なんて意地悪な・・・。

更に調べてみると、ATENというメーカのUSB-シリアル変換器UC-232AもこのPL2303を使っているらしく、更にすばらしいことに自社で専用ドライバを用意していて、infを書き換えればこれが利用できるというのだ。で、やってみると・・・

なるほど、Win7 x64でもちゃんとドライバが読み込まれた。ありがたいですね~。

ちなみにinfファイル変更のポイントは・・・

[PRO.NT]セクションに“%DeviceDesc% = ComPort, USB\VID_0584&PID_B000”を、

[PRO.NTAMD64]セクションに“%DeviceDesc% = ComPort, USB\VID_0584&PID_B000”を付け加えるだけ。
本当にありがたい。

2011年10月24日月曜日

味覚異変???

今朝起きると、口の中で変な味がする。単に喉が渇いたときの感じではなく、例のアノときの感じと同じ味だった。

人工甘味料・・・

昨日、妻にお任せでコンビニで買ってきてもらったジュースに、案の定、アセスルファムKが使われていた。どうもこの人工甘味料は後味がひどい!酷すぎるぞ。他に人は何も感じないのかな~。

実際のところ、アセスルファムKか、スクラロースか、どの人工甘味料の影響なのかは判別できないんだけど、このテの人工甘味料を使った飲み物では必ずこのイヤな後味がずっと口に残ってしまう。確かに自然由来のブドウ糖系甘味料はカロリーが高いのでこの手の低カロリーな人工甘味料が使われるのは理解できない話ではないのだけれど、この後味は許容範囲を超えていると思うんだけどな。

“不惑”を目前に控えた旧人類である私とは違って、現代っ子は味覚自体が変わってしまったのかとさえ思える。それともカロリー増→体重増となるくらいなら、この程度の味はガマンできる、ということなのだろうか・・・。


2011年9月10日土曜日

ノートPCのパーティション整理

個人で買ったものだけど仕事でも使用しているLetsnote S9、以前SSDに換装したことを書いたけれど、パーティション割りが思うようになっていないままだったので、再度整理してみることにした。

私が考えるベストなパーティションの分割方法は、ずばり「1ドライブ=1パーティション」である。
ネットでは、CドライブはWindowsのシステム+アプリケーション用、Dドライブはデータ用としてパーティションを切ろう、という提案を見かけるが、私はあまり好きではない。というのも、そのように分割していても、使い込んでくると「システム用はガラ空きなのにデータ用は逼迫している」とかその逆に陥ることが多い。特に、システム+アプリケーション用のCドライブが足りなくなってきて、仕方なくDドライブにアプリケーションを入れる必要に迫られたときの、何というか気持ち悪さというか、ある種「罪悪感」にも似た感じがどうもイヤだ。そう、CとDの使用率のバランスはたいがい極端になるものだと思う。

それならいっそのことCもDもなしにして、一つのパーティションにすべてを入れてしまえばよいと思う。
「システム用とデータ用と、それぞれ別々にバックアップしたいから別パーティションした方がいい」という意見も聞くが、そもそもシステム用=OS+アプリケーションは再インストールすれば済む話だし(また、たまにはOSからクリーンインストールした方がPCのもたつきが解消されるし)、一方個人データ部分のバックアップはシステム用と違ってブートレコードだのboot用ファイルだの考えずに、ファイル/フォルダごと適当なところにコピーしておけば済むのだから、あえて別パーティションにする理由はなく、それことWindowsがデフォルトでお仕着せ(笑)てくる「マイドキュメント」以下にでも放り込んでおけば、そのフォルダ以下だけをバックアップすれば済むのだ。
それに、同じ物理ディスク上にパーティションを分けていても、そのディスクがクラッシュすれば全滅するのは自明のこと。安全性を考えてパーティションを分けるというのもちょっとばかり説得力に欠ける。

話はずいぶん脱線したけれど、要はパーティションは基本的に1ドライブに1つだけという風にしたいということです。ただ、過去のデータや管理手法をそのまま踏襲する必要がある関係上、便宜的にEドライブをもうけて、その中にこれまでの資産を置くようにしている。ただ、先に言ったようにCとEドライブにパーティションを分けるのではなく、あくまで実際のディスク上では基本1パーティションとし、XP時代はsubstコマンドを使って仮想ドライブとしてEドライブを作成していた。そのEドライブが実際に参照する先はCドライブのMyDataなる個人用データフォルダとしていた。これで、便宜的にはCドライブ=システム+アプリケーション用、Eドライブ=個人データ用として分けて運用できるけれど、実際にはCドライブもEドライブも同一ドライブなので、どちらかの容量だけが足りなくなるということはない。
Windows7に以降した現在では、substコマンドは使わずにジャンクションを使うようにしている。substコマンドで割り当てたドライブ名でファイルアクセスするとき、Windows7ではアプリケーションによってはうまくファイルにアクセスできないことがあった。これはXPのときには無かった問題だ。そこでWindows7ではジャンクションを使うことにしたのだが、そうすると私の場合ではやはり別パーティションとしてEドライブを作って、そのEドライブのフォルダをCドライブの個人フォルダにジャンクションするようなやり方が必要なわけで、そうなると1ドライブ=2パーティションということになってしまう。しかし、ジャンクションを作るだけのEドライブにはそんなに容量は必要ないので実際には100MByte程度のごく小さいパーティションをつくって、ジャンクションでCドライブにフォルダ単位で飛ばしているという要領だ。これならディスクをうまく全部使い切りたい、という欲求を十分に満たしている。

さて、再び話が大幅に逸れたけれど、いよいよLetsnote S9のパーティションを整理する方法について記録しておきたい。
このS9にはリカバリ用DVDがついてくるのはよいのだけれど、リカバリするとHDDにリカバリ領域をまず作って、そしてWindows7の32bitをインストールする、という流れになるようだ。私のように64bit版を使いたいなら、更にHDD/SSD上のリカバリ領域から起動して再度64bit版をインストールする、という手順が必要になる。DVDから起動して直接HDD/SSDにWindows7 64bitをインストールするという選択肢があったらなぁ。しかも、HDDにはリカバリ時くらいにしか使わないリカバリ領域が居座ってしまい、容量の小さいSSDでは窮屈になってしまう。
という訳でWindows7をインストールするにはどうしても「リカバリ領域」がHDDにできてしまう。そこで問題となるのは、Windows7がインストールされたままの状態で、どうやってそのリカバリ領域を削除して一つの大きなパーティションに切り直すか、という点だ。
Windows7には標準でパーティションサイズを縮小・拡張する機能はついているけれど、ちょっと制約が大きいのが困る。今回の場合、リカバリ領域がディスクの前のほうに居座っているので、これを削除することはできても、現在インストールされているWindowsのシステムパーティションを前の方に移動させることができない。システムを入れたままパーティションを移動させるツールとしては、EASEUS Partition Managerなど便利なツールがあるけれど(実際、これまで何度もお世話になった)、今回は対象がSSDでパーティション先頭を4KiBの倍数に整列させないとパフォーマンスが落ちるというものなので、EASEUSは使えない。このツールはパーティションを操作するときに4KiBではなくシリンダ単位に整列させてしまうからだ。
なんとかSSDのアライメントを狂わさないで、かつ、システムを壊さないままパーティションを変更する方法がないかと調べてみたところ、GPartedというツールがあることを初めて知った。どうもLinux系のツールらしいが、いろんなファイルシステムの移動やコピーにも対応しており、しかも4KiB単位でアライメントしてくれるらしいので早速DLしてやってみた。

USBメモリからGPartedを起動して、ディスク前半のリカバリ領域を削除、その後Windowsのパーティションをディスクの一番前に移動させてApplyボタンを押す。SSDだからかわずか30分くらいで約100GByteのデータを移動完了して、再起動と相成った。しかし・・・
Windowsはブートするもののログインができない。画面右下に、「このWindowsのコピーは正規品ではありません」と出ている。なんでかな?
とりあえず、CTRL+ALT+DELでタスクマネージャが起動できたので、そこからcmd.exeを起動していろいろと探ってみる。それで気づいたことは、パーティション移動後に起動したWindowsは、なぜかEドライブになっていた、ということ。Cドライブは存在していない。更にreg.exeコマンドなどで調べてみると、レジストリHKLM\SYSTEM\MountedDevicesに\DosDevices\C:と\DosDevices\D:が登録されており、そのキー値に何やらよく分からないバイナリ値が設定されている。想像するに、その設定値が意味するドライブ情報と、現在の(パーティション移動後の)システムドライブの情報とが一致しないかなんとかの理由で「正規品ではない」と判定しているのだろうと考えた。であれば、どのレジストリのドライブ情報を正しく書き換えてやるか、あるいは、その\DosDevices\C:キー自体を削除できればCドライブとして居座っている何かよく分からない別ドライブの代わりに、現在のSSDのシステムドライブが登録される(か、Eドライブではなく、Cドライブとして起動する)などして、正規品として認めてくれやしないだろうか?と思った。が、・・・。
reg.exeコマンドでレジストリ値を調べることはできても、書き換えたり削除することがどうしてもできなかった。ACLの問題かと考えて、SubInAcl.exeツールを使ったりしてみたけれど、そのツールでレジストリのアクセス権限を変更できない。おそらく「正規品でない」と判定されている以上、コマンドプロンプト上でいろいろやっているのは、権限が制限された仮ユーザーの状態なのだろう。そのユーザーがアクセス権限を変更できるわけがない。かといって、ユーザーの切り替えをやって正規ユーザー名+パスワードを入力しても「正規品でない」ということでログインさせてもらえないし・・・。

八方塞がりだ。

仕方ないので、取ってあったバックアップからWindowsシステムの復元をして、元の状態(回復パーティションがある状態)に戻した。
今度は、回復パーティションをWindows上から削除した後、Eドライブ用の小さな100MByte程度のパーティションを作った。その後GPartedを起動して、今度は回復パーティションを削除して空いた領域いっぱいまで現在のWindowsのパーティションを拡張することにした。GPartedがパーティションを移動させている間、祈ること約30分、作業が完了して再起動すると・・・。
うん、今度はちゃんとログインできてデスクトップが見えるようになった。いくつかアプリケーションを立ち上げてみるが、ちゃんと起動しているいるようだ。個人用のデータもちゃんと残っている。

よかった、これでようやくほぼ希望するパーティション割りになった。
しかし、やはりOSの入れ替えなどや(今回は入れ替えなかったけれど)、パーティションの操作をやろうとすると、時間がかかるなぁ。かれこれ丸一日くらいかかってる。実際には、大切なファイルのバックアップ関係が半分以上の時間を占めているのだけれど。

2011年9月2日金曜日

Windows7の電卓

今さらですが、Windows7の電卓ってソフトを書く人間にとっては改悪だよな。

ソフト書いたりデバッグしていると、時々10進数を16進数を相互に変換したくなるときがある。そして、変換結果に対して、ちょっとした関数演算(logとかexpとか)をやることがある。
でも、Windows7になると「普通の電卓」「関数電卓」「プログラマ電卓」などと切り替え式になってしまったため、「プログラマ電卓」で16進数→10進数変換したあと、そのまま関数演算ができない!「関数電卓」に切り替える計算結果が0に戻されてしまうので、結果を覚えといてまた入力し直してから計算、ということになる。

このような「モード切替」があるUIって、それぞれのモード毎に機能が整理されて便利だと思う反面、自分が使いたい機能があるのはどのモードだっけ?ということになり、モードの「坊主めくり」状態に陥る危険性もあるわけでどうも好きじゃないな。
まあ、電卓の機能ごときで坊主めくりになってしまうことはないけれど、電卓モード切替がATL+1~4で簡単にできるのだから、せめて計算結果くらいはモード間で保持されていてもよいのでは?と思う。

2011年8月30日火曜日

ワイヤレスマウスの電池交換

仕事で常用しているロジクールのワイヤレスマウスM505の動きがついに怪しくなってきたので電池を交換した。電源をONしてもカーソルが動かないか、数秒~数十秒くらい経つと止まってしまう。
それもそのはず。電池切れの警告が出始めてからもう3ヶ月以上も使い続けているのだから、本当に限界が来たのだろう。

で、用意していた電池に交換。無事に復活。あたりまえだけど。

しかし、本当によく電池がもつなぁ。確かこのM505を購入したのは去年の3月、4月頃だったはず。ということは1年と5ヶ月くらい経ったのか。それから一度も電池交換していないのだから、本当にカタログスペック以上にもったな。しかも交換した古い電池を見てみると、推奨使用期限が2005年7月となっている。たぶん、自宅から持ってきたかなり古い電池だろう。もしかしたら、何かで使っていたお古かも・・・。

1日8時間、年間約250日、毎日仕事で使ってこれだけもつのだから、電池交換の手間やのランニングコストなんて十分無視できるレベルだな。

2011年8月27日土曜日

newlibの構築(自分用メモ)

Code Sourcery G++ Lite(ARM)を使って、newlibをビルドする方法について残しておく。
なお、build環境はcygwin。

Code Sourcery G++ Lite 2011.03-41
newlib-1.19.0
を使用。

まず、configure-inスクリプトにパッチを当てる。パッチを当てないと、makeのときに「コンパイラはそのopコードを解釈できない」といったエラー(うろ覚え)が出てしまう。確か、arm固有のcrt0.oあたりをビルドするときに、アセンブラでかかれたコードの一部をアセンブルできないというものだったはず。これはarmv6-mディレクトリ内のビルドのときだったので、今回はターゲットがcortex-m3限定(thumb/thumb2限定)なのでarm命令用のライブラリは最初からビルドしないようにしよう、というのがパッチの目的。
(ところで、Code sourceryのLite版はthumb/thumb2命令しか吐けない仕様だったかなぁ?)

解凍したnewlibのルートディレクトリにあるconfigure-ml.inスクリプトの210~220行目あたりを以下のように編集。

209| multidirs=
210| for i in `${CC-gcc} --print-multi-lib 2>/dev/null`; do
211|   dir=`echo $i  | sed -e 's/;.*$//'`
212|   if  [ "${dir}" = "." ]; then
213|     true
+++|   else if [ "${dir}" = "armv6-m" ]; then
+++|     true
214|   else
215|     if [ -z "${multidirs]" ]; then
216|       multidirs="${dir}"
217|     else
218|       multidirs="${multidirs} ${dir}"
219|     fi
220|  fi
+++|  fi
221| done

これでarmv6-mなディレクトリとライブラリは無視されるようになる。

いつものように適当なディレクトリを作って、
configure --target=arm-none-eabi --prefix=/usr/local/arm-tools --enable-multilib --enable-interworks
としてコンフィグし、make & make installでOK。

glibc vs newlib on armv7-m

一般的な話として、「glibcはサイズが大きい」「newlibは組み込み用にコンパクトに設計してる」と理解していました。これで間違っていないですよね?

今やってるプロジェクトで、どうもROMサイズが足りなくなる予感がしているので、実行オブジェクトのサイズを小さくする方法を模索中。ターゲットはいつもの(Stellaris/CORTEX-M3)です。
現在使っているコンパイラ&ライブラリはCoresourcery G++ Lite(ARM)なので、これに添付されてくるライブラリはglibcらしいということで、これをnewlibに変更してみてはどうかと。

とりあえずnewlibの最新版newlib-1.19.0をダウンロード。configure+makeだけではビルドできなかったので、ゴニョゴニョして(詳細は別途)とりあえずthumb2対応のnewlib版libc.aを得た。そして、今のプロジェクトでライブラリだけ差し替えてビルド後、arm-none-eabi-sizeでできあがった実行ファイルのサイズを調べてみると・・・

(glibc版ライブラリ)
    text     data       bss       dec      hex filename
247192    5516   79544  332252   511dc ***.elf

(newlib版ライブラリ)

    text     data       bss       dec      hex filename
249496    5516   79544  334556   51adc ***.elf

「なんや!glibcに負けとるやないか!」

というわけでnewlib案はボツに。
結局、実行コードのサイズを下げるという目的は果たせなかった・・・。

Letsnote S9のCPU温度

初代Letsnote S9(Core i5 520M)でちょっとした連続テストを行っているのだけれど、キーボード左からの熱がすごいのでちょっとCPU温度を測ってみました。

CPUの総合負荷率60~70%あたりで連続的に動かしていると、CPU温度は91℃~94℃あたりをウロウロしており、瞬時値ではMAX97℃という数値も!半導体はジャンクション温度(Tj)を超えなければ大丈夫だとはいうけれど、以前作った基板でかなりアッチッチになる三端子レギュレータのまわりは基板の色が変色していたことがあった。このLetsnoteは大丈夫かな~。

買った当時は冬(2月)だったこともあってそんなに熱い!という感じではなかったけれど、やはり夏場は厳しい・・・というところか。実際Core Tempで見ていると、CPUクロックは2.1GHz~2.4GHzあたりを遷移しており、TurboBoostはおろか、定格クロックにも足りていない。おそらく温度90℃あたりを限界値としてクロックの引き下げを行う設計なんだろうな。

と、廃熱はかなり熱いんだけれど、パナの設計でそのあたりの温度を上限に定めているのなら、壊れることはないだろうと信じて、いまだ連続テスト中・・・。

2011年8月17日水曜日

爪でバッテン

蚊に刺されたら、その場所をすぐに爪でバッテンをつけるように押さえつけると痒みが無くなる(引く)ということで実際にやってる人がいるらしい。そう言われてみれば、小中学生の頃だったか、私の周りにもそんなことをしてる人が居たような気が・・・。ネット情報によると、関西でそう信じている人が多いらしいが本当のところどうだろうか。

さて、蚊に刺されたときの痒みは蚊が体内に注入する物質(血液が凝固するのを防ぐためらしい)がアレルギー反応を起こすためだと分かっているから、爪でバッテンしただけで痒みが収まるというのは普通に分別のある大人なら迷信(or都市伝説?)だと分かりそうなものだ。せいぜい、爪で刺激する痛みで痒みがごまかされる程度だと分からないものかな。しかし、大の大人でもそんなことをまじめに信じている人がいるのをこの前のTV番組で知って、ちょっと怖くなった。「本当にこの国は大丈夫か?」と・・・。まぁ、霊の存在や、前世占いなんてのを本気にしてる人もいるくらいだから、そのくらいの迷信、カワイイものだと受け流せばよいのだけど、この考えが暴走するとちょっとコワイかも知れない、と思った。

ある子育て情報番組での話。視聴者から選ばれた夫婦+子供が子育てに関する質問をするコーナーがあるのだけれど、その中である親が「子供(赤ちゃん)が蚊に刺されたら、そこを爪でバッテンしてあげたいのですが、問題ありますか?」と大まじめな顔で質問していたのだ。いや、まあ物言わぬ子供のために必死なのは理解できるけれど、そんな根拠のない行為を親が信じているという事実、そしてそれを全国放送で大まじめに質問している事実に驚くとともに、それを親が信じているからといって物言わぬ子供に押しつけるのはどうかと思った。物言わぬ子供だからこそ、正しい知識で正しい対処を!が必要なのでは?と。というのも、少し前にこんなブログを読んだからだ。

ここに書いてあることはちょっと笑えない。「腐った米のとぎ汁から作る乳酸菌を子供に噴霧すると咳や痰といっしょに放射性物質が放出される」と聞いたのを信じて実行している親がいるというのだから、いやはや情報とは恐ろしいものだ。そして、咳や痰が出ると「効いた、効いた」といって喜んでいるのだから更に恐ろしい。「乳酸菌」などといっているのはとぎ汁が腐った単なるカビや最近で、それを吸わされたことに対する防衛反応に過ぎないのに・・・。

このブログの話を聞いていると、先の「爪でバッテン」夫婦もだんだんエスカレートしていって、事実無根の怪しい情報でも「子供のため」と言われれば何でも信じてしまうのではないかと危惧してならない。「爪でバッテン」くらいなら別に問題にならないけれど、一度、上のブログを読んだ方がよいのでは?と思った。

2011年8月16日火曜日

左右盲・・・

という言葉があるらしい。

どうやら「色盲」から派生した造語のようで、ATOKでは「さゆうもう」から1単語では変換されない。
「左右」の区別が分からないというのではなく、「みぎ」「ひだり」という言葉と実際の左右の対応がとっさに分からない・分かりにくいことを指すようだけれど、google先生で調べてみるとそういう経験を持つ人はかなりの数いるようだ。

そういう自分も30歳過ぎくらいまではそうだったような気がする。視力検査なんかでとっさに「右」と答えておきながら、実際には左のことで「左」と言い直したり、運転していて「次、右折して」といわれると、一瞬考えてからでないと曲がる方向を判断できなかったり。一瞬考えれば正しく判断できることだし、迷うのは「みぎ」「ひだり」という言葉と実際の方向との対応なので、言葉を介さなければ実生活においてたとえ一瞬でも迷うということはなく、そのことで悩んだことはなかったけれど、人によっては「自分はどこか頭がおかしいのではないか?」と悩む人もいるんだなぁ。

私の場合は、左利きが基本の左右利き(矯正経験あり)なので、そのあたりが原因の一つかな?と漠然と考えていたけれど、よくよく考えたらどうして上下は間違わないのに左右は間違えかけるのだろう?というのは不思議な気がする。人間の脳はいったい何をどう処理しているのだろうか。

その辺の仕組みが解明されたらおもしろいと思うけれど、もしかしたらこの左右盲も「高次脳機能障害」の端くれなのかも知れないと思うとちょっとコワイ。以前TVで見た例に「飛んでくるボールは上手に手で受けられるのに、目の前にボールを静止して差し出されるとどうしてもボールを取れない・ボールの場所を把握できない」というような脳障害もあるらしい。本当に、脳というのはいったいどうなっているのだろう?そして、私の脳は・・・。

2011年8月4日木曜日

2011/8/3放送の報道ステーション内での大宅映子氏の発言

には、ちょっとイラッとしたなぁ。何というか、高圧的に感じたのは私個人の感じ方でもあり、また大宅氏の立場上語気を荒げた発言方法も一つの方法として受け入れられないわけではないけれど、なんといっても理論の展開が全然論理的じゃなく、客観性に欠ける。ただ、自分の信じている意見を「こうでしょう」「こうじゃないよね」と押しつけているだけの発言に思える。

番組内での発言内容に関しては、こちらのブログが非常に上手にまとめてあります。

まず最初の大宅氏の発言。「悪いことを口にしたら本当のことになってしまう、という考え方が日本人にはあるから(今回の原発事故に関して)最悪を想定した対策をしてこなかった。」
それは屁理屈じゃないですか?今回の地震・津波対策が不十分だったのは、もちろん未曾有の出来事でそれこそ想定外であった部分もあるとは思うけど、それにしても大量の放射線を扱う施設にしてはあまりにも危険予測が甘かっただけじゃないですかね。軍事に次ぐくらいの巨大産業・国家戦略を担う事業を行うのに、日本人的なそういう迷信的な考えが少しでも働いたのであれば、もう日本という国はダメでしょう。少なくとも危機管理能力という点では。
それに、原因をそのような日本人の迷信的考え方みたいなところに求めるのって、こないだ「B型の九州男児は・・・」と発言して消えていった人と同じような言い訳に聞こえる。全然理論的じゃない。

それに「原発やめたら、経済がダメになる。原発関連で仕事を得ている地元の人が路頭に迷う」みたいな発言も。
ちょっと待て!原発事故で生活を奪われた何万人もの人や、それこそ被爆して後遺症が出たり死んだりしたりする可能性があることは考えないのか?人の命の方が大事だと思うんだけど。確かめた訳じゃないけれど、ある報道では六ヶ所村では使われることの少ない立派なハコものがいっぱい建っていたり、村民の平均年収は1320万とも・・・。何万人もの人の生活を脅かす原発を作り、一部の人にそれだけの巨額のお金をばらまくのがベターな選択だと言うのだろうか?もっと税金の有効な使い道があるのでは?

それから「脱原発というけれど、そうしたら3割の電力を失う。現代人は今の豊かさのレベルを落とせないでしょう?それに太陽光や風力などでまかなわれるとして、今の3倍・5倍の電気料金を払えないでしょう?今の状態のままで、原発だけ止める、なんてことはできない!」と語気を荒げた。
んっ、誰がすべて今の生活レベルのままでないとだめだと言った?大宅氏の勝手な思いこみでは?
確かに人は一度豊かな生活を手にするとそれを落としたくないモノだ。でも多くの人は今の生活が贅沢すぎて、また今回ばかりは個人個人が妥協せざるを得ないことを知っていると思う。その一例が、節電だ。
電力供給が逼迫している、といいながら、今のところもっている。「もっている」どころかまだ少し余裕があるように見える。昨年の同時期よりも電気の使用量は明らかに減っているようだ。みんなそれなりに意識して動けば、それくらいのことはできる。これなら原発なしでもやっていけるかも、と多少なりとも期待してしまうのはオメデタイ発想かな。リーダーシップのある人がもう少し声高にリードすれば、実現可能な気がする。
それと、大宅氏のいう「原発以外の方法で電力をまかなうと、料金が3倍・5倍になる」と発言した件。その根拠は?確かに、試算では原発の発電コストと太陽光や風力などの発電コストの「単価」はそのくらいの差を示しているかもしれないが、それは発電単価の話であって火力・水力のような比較的安価な発電方法の比率も考慮しないといけないでしょう?脱原発による不足分を火力で補うだけで5倍になったりはしないですよね?それに、原発の発電コストに関する試算にはいろいろと原発推進派にだけ都合のいい疑惑が囁かれているし。

最近、「量子ドット型」と呼ばれる太陽光発電素材が注目されているようですね。効率は理論上75%まで可能とか!
原発がこういう事故を起こしてしまって関連地域にお住まいの人は本当に気の毒ですが、こういうときこそチャンスであると考えて大きな舵取りができる人が出ないもんですかね?単に「脱原発!脱原発!」と叫ぶだけの人じゃなくて、思い切って原発関連予算を削減(もちろん事故処理予算は必要ですが)して、その予算をドカンとその新しい太陽光パネル素材の研究・開発に当てるとか。それくらいしないと本当の意味での技術革新は起こらないのでは。
まあ、こういう最先端技術は単に予算があればそれだけ研究が進むというものでもないのだけれど、もしも予算や設備・人材的な都合が原因で研究の妨げになっているものがあるなら、それこそ国家プロジェクトとして大規模にフォローするのが本当の国家戦略なんではないかと。

2011年7月28日木曜日

Stellaris ICDIドライバの更新(裏技)

Stellarisの評価ボードについてくるStellarisWare CDに入っているICD用ドライバはちょっと古いままで更新されていないようだ。


  • windows7/vistaでICDを接続したままスリープすると、復帰したときにICDにアクセスできない・USBデバイスの取り外し・追加ができない
という問題が起きる。

ICDのドライバと言っても、要はFTDIドライバの使い回しなので、ここからダウンロードして適宜infファイルを書き換えてやれば最新版ドライバに更新できるはず、と考えていたけれど・・・。

StellarisのICDではUSBのプロダクトIDが変更されているのでその部分だけinfファイルを書き換えて、catファイルを再生成すればうまくいくだろうと思っていたけれど、なぜか「このドライバは署名されていません」となってしまった。

裏技として、素のままのFTDIデバイス(VID/PIDを書き換えていないもの)があればそれを接続して最新版ドライバをインストール、すると結果としてStellaris ICD側のドライバも更新されるのではないか?という予想のものやってみると、確かにICDでも新しいドライバが使われるようになった。これで、スリープ時の変なハングアップから解放されるなぁ。

(やはり)奥が深いTCP/IP・・・

簡易httpサーバを実装中に勉強になったことを記録しておく。

今回、知ったのは"2MSL待ち"という状態のことだ。

実装中のhttpサーバをテスト中、何度かhttpコマンドのやりとりをしたあと、なぜか急にhttpサーバがウェブブラウザからのアクセスに反応しなくなる。Wiresharkでプロトコルを見てみると、ブラウザからのSYN要求に対してサーバはRSTを返して接続を拒否している。サーバそのものが死んでいる訳ではないようだ。さっきまで動いていたのに、急になぜ?

調べてみると、TCPのステートマシンがTIME_WAIT状態に入っているようだ。この状態では、2MSL時間だけ続くようで、実装によってはそれは4分くらいの時間になることもあるらしい。そもそもこのTIME_WAITステートは何のためにあるのか?

それは、通信相手が最後に送ってくるFINに対して、このサーバがACKを返す期間を設けるためのようだ。TCPはロスの無い通信路を提供するモノだけれど、そのTCP制御パケットを送る下位レイヤー(通常IP)はパケットの到達の正否を保証しないので、相手が送ってくるFINに対するACK応答が正しく相手に伝わったかどうかは分からない。もしACKが伝わっていなければ相手は再度FINを要求してくるかもしれない、そのためにこのTIME_WAITステートにとどまる必要がある、と理解した。そしてTIME_WAITステートにとどまっている時間は、そのポート番号が使えなくなる(使えなくする)というのがTCPの仕様にあるとのこと。そうだったのか、知らなかった・・・。

で、なぜ今回この状態に陥ったのか?httpサーバ側の実装の問題だった。サーバー側からTCPコネクションをアクティブcloseしてはいけない。アクティブcloseすると、上記のWAIT_TIMEステートに入ってしまう。あくまでもブラウザ側からのcloseを待つべし。パッシブcloseであれば、WAIT_TIMEステートを経由せずにソケットはCLOSEステートに戻ることができる。

と思ったけれど、これも事情によるようだ。今回の場合はリソースが限られている組み込み系TCP/IPの話。先日から苦しんでいる(?)TINETの話だ。
GByteサイズのメモリを搭載するPCなら気にする必要もないけれど、組み込み系では扱えるソケットの数を5個とか10個とか極端に制限せざるを得ないことがある。今回の件も「アクティブcloseがいけない」と書いたけれど、実際にはhttpサーバ側からアクティブクローズした場合、それ以降はブラウザは別のポート番号を使って接続してこようとするから手続き上は問題ないと思われる。問題は、やはり制限されたソケットしか取り合え使えない組み込み機器側のTCPスタックの実装によると思われる。

今回の場合、何回もhttpリクエストを実行してその都度ポート番号を使い捨てにしていると、なけなしのソケットすべてがWAIT_TIMEステートの状態になってしまう。この状態で新しい別ポート番号で接続しようとしてももう使えるソケットが残っていないのだ。少なくとも2MSL期間が過ぎるまでは・・・。
その点で限られたリソースの中で動作し、かつ、短時間に次々とコネクションの確立と切断を繰り返す環境の中では、少なくともアクティブcloseは貴重なソケットリソースを長時間占有してしまう。これを回避する方法は・・・・、これから考えます。

2011年7月26日火曜日

toppers/tinetの不具合(と思われる)現象…

症状:tcp_rcv_buf()で受信待ち状態にあるとき、通信相手が切断(FIN)してもtcp_rcv_buf()から戻ってこない。

基本的にtinetの実装では、このような受信待ちのときの相手からの切断にはキチンと対応しようとしているようだ。つまり、tcp_***_***()API呼び出しでブロッキングされているときFINが来たときは、そのブロックを解除して0を返すような配慮がなされている。しかし、うまく機能していない場合があるようだ。

問題のtcp_rcv_buf()呼び出しだけれど、デバッガで追いかけると最終的にはtcp_wait_rwbuf()関数内のtwai_flg(cep->rcv_flgid, TCP_CEP_EVT_RWBUF_READY, ...)でいったんブロックされる。受信データがあるか、FINを受信するとフラグがシグナル状態になってtwai_flg()から抜けてくるのだけれど、その後この関するから抜けるための条件(tinet/netinet/tcp_subr.cの957行目)を満たさないのでreturnしないで、再び上のtwai_flg()で待ちに入ってしまう。さて、これをどうやって修正するか。

整理すると、tcp_wait_rwbuf()関数から抜けられずにループしてしまうのが問題。
修正方針としては、tcp_subr.cの957行目にある条件式に新しい条件を追加、つまり、FINを受信したと思われるとき「も」条件を成立させる式を追加することによって関数から0をreturnするように変更する方法もあるが、条件式に意味が100%完全に把握できているわけではないので、安易な変更はデグレの可能性もある。例えば、追加した(とする)条件によって、FINを受信していないのに0をreturnするようになると、アプリ側は接続が切断されたと勘違いしてしまいかねない。

デバッグで動作を追ってみると、プロトコルスタックはその後tcp_input.cにあるclose_connection()と関数を呼び出していることが分かった。その関数内で、受信端のステートマシンをhalf-closedの状態に遷移させている。このタイミング利用して、twai_flg()で待ちになっているフラグをもう一度set_flg()することにしてはどうだろうか?

具体的には、tcp_input.cの
*********************
*** 1367,5 ****
--- 1367,6 ----
   switch (cep->fsm_state) {

   case TCP_FSM_SYN_RECVD: /* SYN を受信し、SYN 送信済み */
   case TCP_FSM_ESTABLISHED: /* コネクション開設完了 */
      cep->fsm_state = TCP_FSM_CLOSE_WAIT;
+    syscall(set_flg(cep->rcv_flgid, TCP_CEP_EVT_RWBUF_READY));
      break;
*********************

と、やってはどうかと。

とりあえずは期待通りの動作になったっぽいので、これでしばらく様子を見る。

2011年7月20日水曜日

価格.comからなくなったモノ

最近、価格.comのレビュー欄についていた「このレビューが参考になった」というところから「いいえ」のボタンが消えたなぁ。今は「はい」ボタンしか押せない。

確かに「参考にならなかった」という情報は余計なお世話かも知れないけど、レビューの中にはホントに酷いレビューもあるのでそういう人にはダメなレビューであることを教えてあげたい(>というのが、余計なお世話)。

例えば、自己満足をひけらかすだけのレビューなんかは、これからその製品を検討しようと思う人にはあまり参考にならないと思うから、できるだけ中立の立場での発言を期待したいところ(とはいってもある程度のバイアスのかかった意見・レビューになるのは仕方ないが・・・)。
本当によく分からないレビューは、各評価項目にはどれも「すごくイイ」「すばらしい」とかベタ褒めだけどどういうところがいいのか書いてないし、なのに総合評価は「4」になっているとか。そのマイナス1ポイントとなったところが何なのか、読者はソコが知りたいはずなんだけどな~。

2011年7月19日火曜日

ゲド戦記、見た・・・

先日、地上波で放送してたので、ゲド戦記を録画して連休中に見てみた。宮崎吾郎氏の初監督作品で非常に酷評が多いと知りつつ、「腐っても鯛」という言葉があるように、かの宮崎DNAを引いた人だし、そもそも映画は一人で作るものじゃないので周りのスタッフの協力の結集でもあるはずなので、それなりに「見れる」映画になっていると期待していたのだけれど・・・

確かにこりゃ酷いな。「映画」という娯楽というよりは、三流のRPGをプレイしたような感じだった。

ジブリ作品の特徴でもある丁寧に作り込まれた画風というのをさしおいても、ストーリーの構成そのものがなってなくて、感情移入とか没入感がまったくなかった。まあ「ヒマツブシ」くらいにはなったか。

その後、ネットで批評を調べてみると、かの押井守氏が「初監督作品でここまでできたならいいんじゃないか?」的な擁護意見を述べられたようだけど、それはちょっと違う気がする。あれほどの制作費と広告費をかけたプロ作品であり、視聴者からお金を得ているという意味ではその対価に見合った作品でなければ批評・批判が出るのは当然のこと。「初監督だから・・・」という言い訳まったくのお門違いに思える。これが医者なら、初手術だからといって酷い手術をされたんじゃあ、たまったもんじゃない。

2011年7月15日金曜日

また散財・・・

また余計なものを買ってしまった。AS501V2-128GM-C

これまで使っていたOEM版X25-Mの80Gでは容量が残り6GByteと心許なくなっていたので、ここ最近128Gくらいを物色していた。新しいどころではcrutialのm4とか、最新のSF-2281を使ったAS511S3-120GMとかあるのだけれど、値段がAS501V2とは2000円くらい高めだし、そもそもSATA3(6.0G)に対応したハードは持っておらず500MByte/sec超の性能があっても使い切れないので、CrutialのC300のOEM品であるAS501V2にした。

で、使っていたX25-Mの内容を新しいSSDにコピーしてちょっと使ってみたところでは、プラシーボ効果も手伝ってか速くなったなぁ(←つまり「速くなった気がするがあんまり変わってない」の意味)。
そりゃそうだろう、X25-Mだってそこそこ速いし、このレベルではベンチマークに現れるような速度差は現実の使用状態においてはほとんど見えてこないものだし。

とかいいながら、まだパーティションのアライメント調整ができていないので、これをやってみたいと思う。ベンチマークを取ってみると、Write系はネットで見られるようなC300のベンチ結果より少し低いのが気に入らない(やっぱり、ベンチマーク至上主義かな)。
この状態だと、むしろX25-Mよりも落ちているような気もするが、とりあえずは容量が増えたのでヨシとするか。

(元のX25-Mのベンチ結果)



(AS501V2のベンチ結果。ただしアライメント調整はまだ)

2011年7月14日木曜日

toppers/tinet 苦戦中・・・

未だにtoppers/tinetに苦戦中。
とりあえずサンプルはmakeできるんだけど、自分で.cfgを書き換えてmakeすると
  "SEM_xxx_xxx is duplicated"
とか
"TSK_xxx_xxx is duplicated"
とかのエラーが頻発して出る。
makeのどこでエラーが出ているかを調べると、コンフィグレータcfgを呼び出す中でエラーが発生していた。個人的な意見だけれど、どうもこのコンフィグレータの存在がちょっと鬱陶しく感じる。何をやっているかがよく分からないからだ。とにかく、cfgがエラーを出すならcfgのソースを拾ってきて追っかけるしかない。

う~ん、なかなか難しい。最終的に理解したのは以下の通り。


  • 指定された.cfg定義ファイルを、cfg1_out.cというCソースコードに変換する。
  • INCLUDEディレクティブ(Cプリプロセッサの#includeとは関係ない)を処理して、インクルードされた.cfgを連鎖的に読み込む。
  • .cfgファイルにある「キーワード」を引っかけて、uITRONで使用される可能性のあるすべてのオブジェクト名を内部に記憶するとともに、オブジェクトIDの定義をCソースコードとして吐き出す。
  • キーワードに引っかからない行は、そのままcfg1_out.cというソースコードに落とす。特に重要なのは#ifdefや#endifなどのCプリプロセッサディレクティブで、それらはそのままcfg1_out.cに出力する。
  • 「キーワード」は.csvファイルで定義されていて、その定義に従って静的APIとオブジェクト名を区別するのであって、静的APIの名前自体がコンフィグレータ内にハードコーディングされているわけではない。
  • こうして出力されたcfg1_out.cには.cfgファイルで定義されていて使用される可能性のあるすべてのオブジェクトIDが含まれている。
  • cfg1_out.cはGCCでコンパイルされ、その出力からシンボルだけを取り出す。ここで重要なのは、コンパイラのプリプロセッサ機能を借りることで#ifdef~#else~#endifブロックを処理させて、実際に必要とされるオブジェクトIDだけをふるいに掛けることにある。
  • cfg1_out.cをコンパイルして得られたシンボル情報を処理して、target_cfg.hにオブジェクトIDを#defineしたものを書き込んでいく。
だいたいこんな感じかな(勘違いがあればご指摘お願いします>誰か)

この調査の課程で分かったのは、前述の"xxx is duplicated"というエラーが発生する原因は、.cfgファイル(INCLUDEされたものを含む)をスキャンして得られたオブジェクト名のリストと、cfg1_out.cから得られたオブジェクト名のシンボルとに矛盾が生じているからのようだ。それは何故かというと・・・

.cfgファイルを書き換えてmakeを実行しても、cfg1_out.cやシンボルを更新してくれないから!

依存関係を調べて必要なファイルを自動的に更新してくれないのなら、いったい何のためのmakefileなの?と思ってしまう(ちょっと、怒)。

とりあえずの回避策は、.cfgファイルを変更したら、make clean; makeとすること。
こんなしょうもないことで少なくとも丸2日は潰れたな(再び、怒)

2011年7月13日水曜日

それって必要・・・かな?

いつも思うんだけど、
Vista/7でUAC制御の確認ダイアログが表示されるとき、
いちいち画面が一瞬暗くなるのはどうしても必要なんだろうか?
普通にダイアログが表示されるだけではダメ?

BSODかとちょっとビックリすることがよくある。

全然関係ないけれど、Windows95が初めて出たときのジョークを思い出した。

「Windows95で最大のバグは、PCを終了させようとしているのに”スタート”ボタンを押さなければならないこと。」

2011年7月11日月曜日

大相撲中継・・・

久しぶりに大相撲中継をon-timeで観戦した。八百長問題や朝青龍問題でゴタゴタするずっと以前から全然見ていなかった大相撲だけれど、実はその昔、昭和の四横綱時代、千代の富士・北勝海・旭富士・大乃国時代はいまよりもずっと面白くてよく見ていたことがある。相撲=地味というイメージがあるけれど、いまよりももっと個性派が揃っていたように思うのは私だけだろうか?思い当たるだけでも・・・、小錦・霧島・北天佑・寺尾・逆鉾・安芸乃島・大寿山・三杉里・隆三杉などなど。

本題に戻って、久しぶりに大相撲中継を見た感想を。

見ていて何となく「懐かしい」という感覚だけでなく、別の不思議な感覚がよぎった。しばらくはそれが何であるか分からなかったのだが、その感覚というのは「ゆったりした時間の流れ」だったのだろうと思う。
昔よく見ていた頃は、”立ち会いまでの時間がなんでこんなに長いのだろう” ”さっさとやればいいのに”と思ったものだけれど、十数年経ったいま、日々仕事や子育てに追われて過ごす中で忘れかけていたのは「ゆったりした時間の流れを感じる贅沢感」なのだろう。
確かに時間は有限、しかも、かなり早く過ぎていくのを感じずにはいられないのだけれど、ゆったりと時間を過ごすことも大事で、そして大相撲の立ち会いまでの一つ一つの動作や流れはそのゆったりとした時間を長い歴史の中で見事に体現したものなのではないかと思った。そして、勝負の一瞬だけ一気に集中力を高める、そういう静と動の切り替えは、あくせくなりがちな現代社会での生活においても、ゆとりのある贅沢な時間を追求するためにも有用なことなんじゃないかと改めて思った。

だからといって大相撲の一連の不祥事や理事会のあり方を擁護するつもりはないのだけれど、それなりの歴史があり続いてきたものにはそれなりの理由や意義があるように思えた一瞬でした。

2011年7月6日水曜日

TOPPERS/ASP on Stellaris その2・・・

あとから気づいたのだけど、toppersプロジェクトにあるCortex-M3依存部の内容はInterface誌2008年12月の記事と同様のもののようだ。

で、再びおかしな所を発見してしまった!(というか嵌った!)

非タスクコンテキスト用スタックの割り当てがおかしいようだ。場合によっては、他で使っている領域の上にSPが割り当てられるので、カーネル自体の実行や非タスクコンテキストの実行中にメモリをブチ壊すことがあるので要注意だ。

問題の箇所は、arch/arm_m_gcc/prc_config.h内でマクロTOPPERS_ISTKPT#defineしているところだ。


(誤)#define TOPPERS_ISTKPT(istk, istksz) ((STK_T *)((istk) + (istksz)))

(正)#define TOPPERS_ISTKPT(istk, istksz) ((STK_T *)((char_t*)(istk) + (istksz)))

ここは上のように(char_t*)へのキャストが必要だ。
引数istkに渡されるポインタ(スタック領域の先頭アドレス)はSTK_T*型を持つので、そのままスタックサイズ(=istksz:バイト単位)を足すと32bit CPUであるCortex-M3では計算が4倍違ってくる。
このTOPPERS_ISTKPTマクロはシステム起動時のSPの初期設定に使われるから、立ち上がった時点から本来アクセスしてはいけない部分をSPとして使って起動することになる。

ついでに、もひとつ。

target/cq_starm_gcc/target_config.hで定義されているスタックサイズDEFAULT_ISTKSZの#define部分、

(誤)#define DEFAULT_ISTKSZ (0x1000/8U) /* 4KByte */



は、8Uで割る必要はない。ここで指定するのはバイト単位。

 (正)#define DEFAULT_ISTKSZ (0x1000) /* 4KByte */

直前の行で「 デフォルトの非タスクコンテキスト用のスタック領域の定義。8byte単位で取得される」というコメントが入っているが、これも微妙。Cortex-M3では8バイト境界(ダブルワード境界)でSPを設定したほうがよいとなっているので、もう少し厳密にコメントするなら「8byte単位で取得される」ではなく、「8の倍数を設定する」とでもコメントすべきではないか?

ああ、いろんなトラップを仕掛けてくれなぁ・・・。もうヤダ。

TOPPERS/ASP on Stellarisやっと動いた・・・

かなり手こずりました。

結論としては、toppersプロジェクトサイトに置いてあるCortex-M3依存部のコードの問題だった(と思う)。プロジェクトに報告した方が良いのかも知れないけれど、120%の自信がないので自身のブログでゴニョゴニョ・・・と書き連ねておいて、誰かの参考になればと思う。

問題のコードは、Cortex-M3依存部として公開されているarch/arm_m_gcc/prc_support.Sというアセンブラコード。もともとこのコードはカーネルバージョン1.3.*用に作られたもので、今回ポーティングを行ったtoppers/asp バージョン1.7.0とは互換性がないのが原因なのかと思っていたが、そうではなかったようだ。
元のコードで、svc_handlerとラベルのある部分は次のようにコーディングされていた(435行目あたり)。

0435: svc_handler:


0440:    cpsid f                       /* 割込みロック状態へ */
0441:    mrs   r0, psp
0442:    add   r0, #EXC_FRAME_SIZE     /* スタックを捨てる   */
0443:    msr   psp, r0
0444:    mov   r0, #0


このコードは、SVCサービスコール命令によってThreadモードからHandlerモードへ移行したあと、スタックに入れられたレジスタ値を強制的に捨てることを意図したものだけれど、この部分が場合によってはよろしくない。
場合によっては」というその条件は、

  • Cortex-M3の”構成制御レジスタ”にあるSTKALIGNビットが1である
  • SVCサービスコール命令を呼び出すときのSPの値が8バイト境界に並んでいない

というものだった。
もし上記の2条件が成立しているときにSVC命令を実行すると、スタックに保存されるのは通常の[R0-R3,R12,LR,PC,xPSR]という8レジスタの前に1ワードのパッドデータがスタックされるので、都合9ワードがスタックに入ることになる。しかし、上に示したsupport.Sのコードは8ワード固定量のスタックを破棄するだけなのでスタックポインタがずれてしまい、結果として(多くの場合)Usage Faultで落ちる、ということになる。
この問題を回避するには、SVC呼び出しによってスタックに積まれたのが8ワードなのか、それともパッドを含む9ワードなのかを調べて(8バイト境界への調整が行われたかどうかを調べて)、正しい量をスタックから捨てなければならない。
幸いなことに(というか当然だけど)スタックに積まれたxPSRのビット[9]とみると、8バイト境界調整が行われたかどうかが分かるようになっているので、これを利用することにする。というわけで、修正後のコードは、

svc_handler:
cpsid f                       /* 割込みロック状態へ */
mrs   r0, psp
--- add   r0, #EXC_FRAME_SIZE     /* スタックを捨てる   */
+++ add   r0, #(EXC_FRAME_SIZE-4) /* スタックから[R0-R3,R12,LR,PC]を捨てる */
+++ ldmfd r0!, {r1}               /* スタックからxPSRを取り出す            */
+++ tst   r1,#0x200               /* 8byte境界に調整されたか? */
+++ it    ne
+++ addne r0,#4                   /* そうであれば更に1ワード調整する */
msr   psp, r0


とした。

上記のSTKALIGNビットはCortex-M3のコアリセット時には'1'に設定されると言うことなので、この問題に引っかかる可能性は純粋に1/2の確率になると思うんだけれど、世の中の人はこの地雷を踏んでいないのかなぁ。


(2011 7/6 AM11:30 追記)

CQ出版から出ている「ARM Cortex-M3システム開発ガイド」によると、Cortex-M3コアのリビジョンが1の場合は、問題の8ワードの”例外スタックフレーム”はワード境界にも、ダブルワード境界にも配置することができ、その切り替えにSTKALIGNビットがあると書いてある、Cortex-M3コアのリビジョンが2になると、例外スタックフレームはダブルワード境界にしか配置できないようになっているそうなので、今後toppersのこの問題の可能性は1/2よりも大きくなってくるのかも知れないな。
(というか、これまで問題視されてきた経緯がなさそうなのは、toppers+Cortex-M3という組み合わせでの採用実績が少ないのかな?)

2011年7月4日月曜日

JTAG接続不可からの修復成功

Setellaris関連で開発を行うときは、CodeSourcery G++(ARM)OLIMEXのJTAGエミュレータARM-USB-OCDOpenOCDを組み合わせて使っているわけだれど、これまで何機種も開発してきて初めておかしな現象に出くわしたので、ここに記録しておく。

おかしな現象とは、JTAGエミュレータがStellarisにまったく接続できなくなった、ということ。
OpenOCDを起動すると、次のようなメッセージが出た。
Open On-Chip Debugger 0.2.0 (2009-09-02-13:49) Release
$URL: http://svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.2.0/src/openocd
.c $
For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
100 kHz
jtag_nsrst_delay: 100
jtag_ntrst_delay: 100
     TapName            | Enabled |   IdCode      Expected    IrLen IrCap  IrMask Instr
---|--------------------|---------|------------|------------|------|------|------|---------
 0 | sterralis.cpu      |    Y    | 0x00000000 | 0x4ba00477 | 0x04 | 0x01 | 0x0f | 0x0f
    TargetName         Type       Endian TapName            State
--  ------------------ ---------- ------ ------------------ ------------
 0* sterralis.cpu      cortex_m3  little sterralis.cpu      unknown
Info : device: 4
Info : deviceID: 67353818
Info : SerialNumber: 0B010030A
Info : Description: Luminary Micro ICDI Board A
Info : JTAG tap: sterralis.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0
xba00, ver: 0x4)
Info : JTAG Tap/device matched
Warn : Timeout (1000ms) waiting for ACK = OK/FAULT in SWJDP transaction
Warn : Timeout (1000ms) waiting for ACK = OK/FAULT in SWJDP transaction
Warn : Timeout (1000ms) waiting for ACK = OK/FAULT in SWJDP transaction
Warn : Timeout (1000ms) waiting for ACK = OK/FAULT in SWJDP transaction
Warn : Block read error address 0xe000ed00, count 0x1
Warn : Timeout (1000ms) waiting for ACK = OK/FAULT in SWJDP transaction
Warn : Timeout (1000ms) waiting for ACK = OK/FAULT in SWJDP transaction
Warn : Timeout (1000ms) waiting for ACK = OK/FAULT in SWJDP transaction
Warn : Timeout (1000ms) waiting for ACK = OK/FAULT in SWJDP transaction
"Warn : timeout(1000ms) …"と延々と出続けて、何の操作もできなくなってしまっていた。
でもだいたい察しはついていた。というのも、最初はちゃんとJTAGでこのCPUを認識していて、この現象が出始めたのは新規に開発したコードを書き込んでからだったからだ。おそらくJTAG関連のピンがGPIOモードに変更されたか、CPUがスリープモードに落ちてJTAG自体も機能しなくなってしまったかどちらかだろう。

Stellarisの"困ったちゃん"なところは、ハードウェアリセットピンをアサートしているとJTAG機能まで停止していることだ。今回のように間違ったソフトウェアを書き込んでしまうと、リセット解除直後にその間違ったコードを実行してしまいJTAG接続ができなくなる。リセット解除からJTAG機能が落ちてしまう数~数十us以内に強制ブレークさせることができればよいのだが、それは至難の業。困った。

Stellarisのデータシートを読んでみると、"Recovering from a locked microcontroller"という章があるのを発見!更に、最新のOpenOCDには"stellaris recover"というコマンドが追加されていることも知る。これを使えば回復できるかも!と期待して、わざわざOpenOCDの最新ソースをgitリポジトリからDL&コンパイルしてみたが、やはり動かない。というのも、OpenOCDの"stellatis recover"コマンドは"init"コマンド以降でしか使えないようで、現状ではその"init"コマンドの実行中に例のWarningが表示されて止まってしまうのだ。つまり、せっかく「カギ」を見つけたのにそのカギはカギのかかった箱の中にあった、というようなもんだ。

仕方がないので、最終手段としてデータシートで見つけた"Recovering from a locked microcontroller"に書いてある手順を自分でコーディングしてみることにした。幸いにもJTAGデバッガはFT2232MPSSEを使用するようになっているので、簡単なライブラリ呼び出しで実行できるはず。で、サクッと作ってみたら・・・直った!再度、JTAGデバッガ+gdbから書き込みができるようになった。

しかし、ここまでで何時間をムダにしただろう。JTAGデバッグ機能って、デバッグ時の重要な砦なのにそれが使えなくなるようなマイコンの仕様っていったい・・・ブツブツ

2011年6月28日火曜日

「節電対策」という言葉に違和感を感じる・・・

ニュースなどでも当たり前に使われている「節電対策」という言葉にどうも違和感を感じてならない。

「~対策」と使う場合、「~」に入る部分は通常起こって欲しくない、起こっては困るような事柄が入るべきで、それに対する何らかの方策・対応方法という意味で「~対策」と呼ぶのではないか?例えば、「大雨対策」と聞けば、大雨が降って起きうる洪水とか農作物への被害など望ましくない懸念事項に対する方策という意味ですんなり受け入れられる。

一方で「節電対策」と聞くと、「節電」自体が起こって欲しくない事柄であるように感じられてしまうが、、節電はむしろ(できるのであれば)望まれるべきことだと思う。だから「節電対策」というと、「節電」が起こって欲しくない(したくない)ので、節電しないような何か方法をとるという意味になってしまうのではないだろうか?言うならば「(大規模)停電対策」とか「電気の大量消費対策」とかの方が意味としてスッキリする。
ひねくれた見方をすれば、「暑いのはイヤだから節電したくないという気持ちに対抗するための何らかの方策(悪あがき?)」、という意味ととらえることもできるけど、やっぱり「節電対策」という響きはキモチワルイ。

ちなみにWikipediaによると、


  • 現在では、ある問題や相手の態度に対して取られる方策のことをいう。なお、「省エネルギー対策」といった用法だと「省エネをさせないための対策」という意味になるので誤用である。
と書かれているので、(Wikipediaが常に正しいとは限らないけれど)やはり「節電対策」というのは間違いのような気がする。

2011年6月23日木曜日

Inno Setupにハマる

比較的柔軟な動作設定・定義ができるという点で使っているInno Setupだけれども、アンインストール動作で不穏な動作に遭遇した。結論から言えば、Inno Setup自体は問題なかった(仕様どおりの動作)のだけれども、あまり意識していないとハマる可能性があるので備忘録として残しておくことにした。

というのは、公開しているアプリのバージョンアップなどで、古いバージョンをインストールしたまま同じフォルダに上書きインストールしたときはアンインストール動作にも気を配ろう。
具体的に言うと、古いバージョンのときに指定した[UninstallRun]セクションの内容は、上書きインストールした新しいバージョンの[UninstallRun]セクションとともに、アンインストール情報ファイル"unins???.dat"に両方記録されている、という点である。つまり、上書きインストールを行ったアプリのアンインストール動作としては、

  1. 新バージョンで指定した[UninstallRun]セクション
  2. 旧バージョンで指定した[UninstallRun]セクション

の順で実行されるので、新しいバージョンでインストーラ/アンインストーラ関係のファイルを更新したり、動作を変更したりすると、上の2の動作のときにおかしくなる可能性がある。

これを回避する方法としては、


  1. 新旧バージョンでインストーラ/アンインストーラの動作を変更しないこと
  2. アンインストール動作を変更したとしても、旧形式でのアンインストール動作で不具合を起こさないように注意すること
  3. 新バージョンをインストールする際に、旧バージョンをアンインストールしてから新バージョンをインストールするようにユーザに喚起するか、新インストール側でそういう対策を行うこと
という方法が考えられる。

2011年6月17日金曜日

ドアミラーって・・・

車を普通に運転してたら見ますよね?>ドアミラー

  • いや「私の車はフェンダーミラーだから見ない!」という天の邪鬼な返答は置いといて・・・


今日の通勤途中、ドアミラーをたたんだまま走る車を見かけました。しかも高速道路でです!結構飛ばしていましたし(120km/hくらい出てたかも)、いくら交通量が少ないとはいえ車線変更もバンバンやってました。いったい、どうやって安全確認をしているんだろうか?

ルームミラーである程度後方は確認できるけど左右の斜め後ろには明らかに死角があるし、ドアミラーを使ってもかなり死角は広いと思う。仮に、車が来ていないことをずいぶん前から長い時間ルームミラーを使って後方を確認していたとしても、たま~に恐ろしいくらいのスピードであっという間に近づいてくるベンツやセルシオがいることを考えると、その方法も決して安心はできない。

ハッキリ言って、こんな人には車の運転をしてもらいたくない。ちょっと怒り心頭です!
ここでナンバーをババーンと晒してやろうかとも思うけどさすがにちょっと問題がありそうなので一部伏せ字で・・・

横浜 501 ま 5○○1 の 白いシルビア

この車を運転している人!ちゃんとドアミラーも(もちろん目視も)使って左右斜め後ろの安全確認をしてください。

2011年6月10日金曜日

TOPPERSを触ってみる

以前から気になっているTOPPERSプロジェクト。以前にも少し触ってみたことはあるのだけれど、コンフィグレータがどうとか、静的APIがどうとか、初めて触るにはちょっとややこしいor面倒な部分が多くて挫折していた。う~ん、きっとコンフィグレータは後々良さが分かってくるんだろうけど、これまでになかった新しい何かを身につける・・・いや少なくとも乗り越えるにはちょっとしたパワーが要るんだなぁ。その点、FreeRTOSはカーネルソースコードも含めてコンパイル&リンクするだけでOSに必要な機能が使えたから簡単に取り組めたんだけどなぁ。ま、新しいものを素直に受け止められないのはオジサンになった証拠か。

でも今回はごにょごにょ言わずに何とか先に進めてみた。
ターゲットはcortex-m3(stellaris)だ。幸いcortex-m3向けの機種依存部分を提供してくださっている方がいたのでありがたくダウンロードさせていただいて、当面の評価を行おうと思う。

まず、TOPPER/ASPの最新版をダウンロードして展開。更に、cortex-m3依存部分も同じディレクトリに展開。doc/user.txtによると、やはりコンフィグレータcfgが必要らしい。が、ASPのフルパッケージに何故か入っていない。仕方ないので、またHPから探すと、今回はcfgのwindows向けバイナリが置いてあった。ソースも置いてあったけれど、目的はstellarisでtoppersを動かすことであって、コンフィグレータをビルドする方法とかはどうでもいい。で、ダウンロードしたcfg.exeはどこに置けばいいんだ?
とりあえず先に進むことにした。なるほど、他のオープンソース系と同じようにターゲットにあわせたconfigureスクリプトとmakeを行うのか。そして、configureスクリプトの実行はperlだと。そうか、shスクリプトはlinux系ユーザにはおなじみだけど、windowsユーザを考慮してまだ導入しやすいActivePerlなんかで対応できるようにしてるんだな、と勝手な推測。とりあえず、ActivePerlの最新版をダウンロードしてきてインストール、パスを通した後、コマンドプロンプトからperl ..\configure -T lm3s8962_gcc[ENTER]とタイプイン!何っ?エラー?PWDコマンドがないって?そりゃ、Windowsのcmd.exeにはPWDはありませんよ。ということは、ActivePerlはダメってこと?
う~ん、windows<オンリー>ユーザのためにperlを使うわけではないようだ。仕方ないのでActivePerlはソッコー消して、cygwinのbash上からperl/configureスクリプトを実行して事なきを得た。しかし、結局bash系の環境は必要なら何であえてperlを導入したのか分からない。shスクリプトのままじゃダメなの?perlは文字列処理が得意だから?

まぁ、いいや。とりあえずconfigureスクリプトは成功してmakefileができたようだ。そのままbashからおもむろにmake[ENTER]をバシッと。

またエラーですか。

今度はコンフィグレータcfgが無いと言っているようだ。cfgのあるべきパスは、../cfg/cfg/cfgですか。何ですか、そのパスは?まあよい、今回は素直にそのパスにダウンロードしたビルド済みcfg.exeを置いてみる。そして、再びmake[ENTER]をバシッと。

またまたエラーですか。

今度はTSKCTBXという識別子(たぶん構造体定義)が無いとおっしゃる。ハイハイ、どこか探してきますよ。というわけでソースツリーをgrep。しかし、TSKCTBXを定義している箇所が無い。いや、arch/m68k_gccの中に1つだけ発見した。でもなんかおかしいなぁ。名前から想像するに、TSKCTBXはタスク制御ブロックのようだけれど、その定義を発見したのはarch/以下。つまり、機種依存コードの中。こういう場合、タスク制御ブロックの定義って、機種依存ではなく、カーネル本体に含まれるべきなんでは?

困りました。TSKCTBX構造体を自力で定義せにゃならんのですか?と思っていたところ、偶然発見した。「CTBXはTSKCTBXに名前が変更されました。」

なんじゃそりゃ?

でCTBXで検索してみるとありました!やはり、機種依存部分のarch/arm_m_gcc/prc_config.hにありました。勝手にTSKCTBXに書き換えて、今度こそmake[ENTER]でサクッとコンパイル!

出ました。またエラーです。

今度は、hw_ints.hが見つからないと。この名前は見覚えがある。StellarisWareに含まれているヘッダファイルのようだ。includeサーチパスを見ると"LuminaryMicro_Driver"とか含まれてる。LuminaryはTIに買収されちまったよぉ~、StellarisWareに変わってパスも変更されたんだよぉ~。というわけで、makefileからインクルードパスの設定を変更して、などなど・・・。

どうやらダウンロードしたcortex-m3向け機種依存コードは、かなり古いもののようだ。実際、最終更新が2008年となっている。カーネル部分の更新について行けてないのか・・・。あきらめ半分でmake[ENTER]ポチっと。

お約束のエラーです。

今度は、INHINIB構造体にint_entryというメンバは存在しない、EXCINIB構造体にexc_entryというメンバは存在しない、という2つのエラー。INHINIB/EXCINIB構造体の定義を探してみると、いやint_entryとexc_entryはちゃんとFP型で宣言してある。FP型も定義してある。もしかしてこの部分はコンパイル時に読み込まれない(#if~#endifではじかれている?)可能性もあると思って、#errorとか適当なものを埋め込んでみるとちゃんとコンパイル時に#errorが報告されるのでこの定義を通っているようだ。では何故?・・・

分かりました。機種依存コードの中でint_entryとexc_entryを#defineで_kernel_int_entry/_kernel_exc_entryにリネームしてある。そうだ!思い出したゾ。

以前TOPPERSに取り組んでみてイヤになったのは、この#defineによるリネームのせいだ。コイツのせいで今回のようなコンパイルエラーが出て困ったんだった。こういうリネームをやられると、どの名前が本当の名前で、どこで定義されているのが実際に使われる名前なのかがまったく分からなくなる。しかも、int_entryのような単純な名前を入れ替えられると、今回のようにたまたま構造体のなかで使ったメンバに同名のものがあると、それもリネームされたり、されなかったりで、何が本当なのか訳が分からない。
どうしてこういう実装にしたのだろうか?結果的にこれがもっともスマートな解決方法なのかもしれないけど、私のように事情をよく知らない者がメンテなりポーティングする段になると、非常にメンテナンス性が悪くなると思うし、思わぬ不具合をはらみかねないと思うのだが。少なくとも#defineで名前の置き換えがされることを前提にしているシンボルなり関数があるのなら、その名前は置き換えられることがもっと区別しやすいような名前にすべきだと思う。今回のようにint_entryのようなありがちな名前だと、グローバル関数としてのvoid int_entry(void)をリネームしたいのか、INHINIB構造体中のint_entryメンバをリネームしたいのか判断できない。

で、結局この部分をどう解決すべきか?本当に手がかかるなぁ、ブツブツ・・・


[2011/6/10 18:45加筆]

その後の調査で分かったこと。

○#defineによる関数名のリネームは、ユーザが書くアプリケーション側の関数名との競合を避けるためらしい・・・
>>それなら敢えてリネームしなくても、ユーザー側が競合を回避すればいいだけではないか?
>>または、ユーザー側で使いそうな名前の関数をTOPPERS側で使わない方がよいのでは?実際、doc/user.txtにはtoppers_接頭辞を予約していると書いてあるんだから、一目でTOPPERSの「内部関数だな!」と分かる名前をつけることは、ソースコードの可読性を挙げるためにもむしろ有効な手法ではないか?
>>今回の場合は、Stellaris用の機種依存コード側でint_entryという名前をつけたこと自体が失敗だったのではないかと思われる(成果をダウンロードさせてもらっておきながら、なんとも勝手な言い分だろう>私)

で、とりあえず上に書いたint_entryとexc_entryの妙なリネームを回避するとサンプルをビルドすることができた!

2011年5月31日火曜日

イライラするなぁ

どうもStellarisを使っているとイライラする。

○データシートに書いてある内容が不十分
○データシートに書いてある内容どおりに動かない
○StellarisWareは間違いだらけ

確かに、アプリケーションノートやサンプルあること”だけ”をやっている限りはちゃんと動くし、パフォーマンスもそこそこよいと思う。もちろん、CPU以外の機能についても豊富で充実はしている。

しかし、そのCPU以外の周辺機能は、本来想定された正常な動作から外れるともうガタガタだと言わざるを得ない。エラー時の対応・回復処理とか、処理途中でキャンセルするとか、そういうことをやろうとするととたんに不可解な動作をし始める。

例えば、uDMAのキャンセル方法。
データシートによると、DMAENCLRの該当ビットに1を書き込めばDMA動作を停止するとあるが、実際にはちゃんと止まってくれない。いや、確かに“止まっている”のだけれど、uDMAコントローラ内部では転送途中の状態をまだ記憶しているようで、新しい別の転送先/転送元アドレスを指定してDMAENSETのビットをセットしても、新しいアドレスには転送してくれない。
結局、DMAを停止させるために、まずDMAの要求トリガを発生させる機能(UARTやUSBなど)でDMA要求を出させないようにした上で、そのDMAチャンネルにソフトウェアトリガを繰り返し発行してDMA転送を“本当に”完了させる、という方法を採用するしかなかった。

他にも、USBの転送のキャンセル方法についても不具合発見。
USBデバイスとして機能させ、USBデバイス→ホスト方向への転送を途中で止めたくなったとする。つまり、ホストへ転送するためにFIFOに入れておいたパケットの内容を取り消して、ホストからIN-NAKとさせたい訳だけれど、データシートどおりにUSBTXCSRLnのFLUSHに1を書いてみてもFIFOの内容は消えていない(ホストからINトークンでパケットが取れる)し、TXRDYビットがクリアされると書いてあるけれど実際には自分で0を書いて消さなければ消えない。どうやら、FLUSHビットへに書き込みは、FIFO内部のポインタをリセットするだけでFIFOの内容を消したり、USBコントローラに送信可能(TXRDY)であることをキャンセルさせたりはしていないようだ。
しかも、FLUSHでFIFOをクリアすると(正確にはクリアするためにTXRDYに0を書き込むと)割り込みが発生する。その割り込みは要らないだろう。しかも、このデバイスは割り込みを発生させた細かい要因を教えてくれないので、「FIFOクリア直前にホストがINトークンでパケットを転送した」のか、「FLUSHによるキャンセルが要因」なのか区別がつかないじゃないか!バカヤロウ!

全体的に見て、正常な場合の動作しか想定しておらず、「もしもこういうことが起きたら・・・」という異常系での振る舞いについてはほとんど考えられていないのではないだろうか?あるいは、文化的な違いから、青い目の人は「異常が起きたら全部リセットして最初からやり直し、それでいいじゃん?」的な考えなんだろうか。

とまぁ、悪態をついてみたところで、巨大企業であるTIが動いてくれるわけでもなく、せいぜいこんないところを愚痴を書き連ねるのが関の山って所か・・・、orz

2011年5月6日金曜日

Stellarisのバグ?(その2)

UART+uDMAを使った受信において気づいたこと。

例として、10バイトのデータをuDMAを使って受信することを考える。データシートやサンプルに従って設定すれば期待通りに動作した。しかし、不測のデータ受信やエラーリカバリ処理に難儀した。

通信相手が10バイトではなく13バイト送ってきたと仮定する。
uDMAをBASICモードで設定していれば、まず最初の10バイトをDMA受信した時点で割り込みが発生した。これは期待通り。uDMAをBASICモードで設定しているので、この時点でuDMAの動作はSTOPになっている。
問題は、このあと残りの3バイトを受信したときにStellarisがどのように振る舞うかだ。
このときStellarisは残り3バイトについて、通常の(DMAを使わない)ソフトウェア+割り込みを使う方法と同じように、受信割り込みを発生させてしまう。ここで誤ってその3バイトの受信データをソフトウェアで読み出してしまうと話がややこしくなる。

UART自体は、RXDMAEフラグがセットされている以上は受信データが1バイトでも検出されると、そのUART回路内部でDMAリクエストを保持してuDMAコントローラの方に送っているようで、たとえUARTの受信FIFOの内容をすべてソフトウェアで読み取った後でもそのDMAリクエストはUART内部で残り続けている。つまり、余分な3バイトをソフトウェアで読み取ってもうFIFOには受信データが残っていなくても、次回uDMAの受信設定を行うとまだ保持され続けているUARTからのDMAリクエストによって1バイト分の受信データ転送トランザクションが発生してしまう、という誤動作につながるようだ。

これを回避する方法としては、

(A)DMAを使うときはソフトウェアで直接FIFOを読み出すようなことはしないこと。

(B)上記のような3バイトを「余分なデータ」として読み捨てる場合は、ソフトウェアでFIFOを読み出しても良いが、次回DMAを設定する前にUARTからのDMAリクエストをクリアする方法を行うこと。

の2案が考えられる。
上記の例で余分に受信された3バイト分が、本来次に受信されるべき10バイトのうちの先頭3バイトであれば(=すなわち、正常な次のパケットの一部などであれば)、この(A)を採用してそのまま次のDMA受信を設定&開始すれば問題なく(DMAで)受信される。

しかし、受信された3バイトが本来必要ではないゴミデータであればそれを読み捨てる(B)案を採用せざるを得ない。その(B)案を行う具体的な方法としては、

(B-1)Software Reset Control 1レジスタのUARTnビットを使ってUARTそのものをリセットしてしまう方法

(B-2)UART ControlレジスタのUARTENフラグにいったん0を書いて、1に戻すという方法

の2つが有効であるようだ。
(B-1)の方法は、UARTの設定そのものがリセットされてしまうので、再設定を余儀なくされる。
(B-2)の方法は、UARTの設定は保持されるがUARTENに0を設定している瞬間は受信処理が止まるのでその瞬間に受信データが来ると受信し損ねてしまう、という問題が残る。
どちらにしてもUARTの動作は一瞬でも止まるので、データを受信し損ねる可能性は排除できない。

もうちょっとうまいエラーリカバリ方法を用意してくれないものかなぁ。

2011年5月2日月曜日

Visual Studio 2008の「へぇ~」な機能

Windows VISTAや7では、システム関係のファイルの書き換えに関してちょっとした保護機能が追加されている。WINDOWSフォルダやProgram Filesフォルダは、ファイルを変更しようとするといくらadmin権限でも確認ダイアログが出てくるし、アプリケーションでProgram Files以下に自分用の設定ファイルを保存するような(お行儀の悪い)アプリケーションでは、ファイルの保存先をコッソリとすげ替えさせられている。
特にUAC関連では叩かれることの多いMSだけれども、今回はその件をとやかく言うつもりはない。

今回、Visual Studioを使ってちょっとしたインストーラを作っていて気づいたことがありました。インストーラをデバッグ実行してもデバッグできなかった。理由は上のとおりで、Visual Studioから起動されるプロセスはVisual Studio自体のユーザー特権で実行されるから、Program Filesへの書き込みが禁止されているという訳だった。これまでは、ほとんどの開発をXPでやっていたから気づかなかったし、またReleaseビルドのときは親インストーラである”setup.exe"からの子プロセスとして実行されるインストーラだったので、特権レベルが"インストーラ"レベルに昇格されていて問題なく動いていた。が、開発環境を7で、Visual Studioから直接起動するとこの特権問題が露見した、という具合だったようです。

で、回避策として、Debugフォルダにあるデバッグ対象のインストーラ.exe自体を、エクスプローラ上からプロパティ変更して「管理者として実行する」に変更してみた。すると・・・、

Visual Studioはデバッグセッション開始時に、デバッグ対象.exeが「管理者として実行する」ことを要求していることを自動的に検知してダイアログを表示し、デバッグ処理を継続させるとVisual Studio自体が「管理者」権限で再起動した。

残念ながらそのままデバッグは開始しなかったけれど、この段階ではもうVisual Studioは管理者で実行されているので、再度F5でデバッグを開始すると難なくデバッグプロセスが開始され、以降ステップ実行やら変数インスペクションができた。もちろんインストーラとしてProgram Filesフォルダへのアクセスも自由にできている。

なかなか気が利いている、と思った。
しかし、起動している子プロセス(というかexeファイル)が管理者権限での実行を要求している、ということはどうやって検知しているのだろう?

2011年4月23日土曜日

Windows7 SP1・・・もうリリースされてたの?

今になってSP1が出ていることに気がつきました。だって、Windows Updateは教えてくれなかったし・・・。
いや、ネットで調べてみるとWindows UpdateがSP1を自動検出してインストールされるはず、となっているのだけれど、いま使っているこのLet's Note S9では何度Windows UpdateやってもService Pack 1という文字が出てこなかった。なんでだろう?

と思って調べてみると、どうもS9で使っているビデオドライバのバージョンによってはWin7のSP1が検出すらされないらしい。いったいどういう因果関係になっているのかまったく理解不能だけれど、パナソニックのHPの情報によると、ビデオドライバのバージョンが8.15.10.2104あたりだとダメらしく、2011年3月16日に公開された8.15.10.2281を入れるとうまくいくと書いてある。

で、まずこのビデオドライバをインストールしてみた。そしておもむろにWindows Updateすると、あぁ、確かにService Pack 1という文字が出た!

というわけで、いまはそのSP1が入ったLet's Note S9から書いているわけだけれど、こんな重要な情報は教えてくれないなきゃダメでしょう?>パナソニックさん。
というか、ドライバのアップデートなんかは普通は自分で調べてやるかやらないかを決めるモンだとは思いますが、付属している「PC情報ポップアップ」という(妙な)ソフトが入っているのなら、「修理をご依頼されるお客様へのお願い」なんてしょうもないお知らせを流すよりも、こちらの方が重要だと思うんだけどなぁ。「修理をご依頼される~」は、実際に修理をお願いするときに直接お客さんに伝えた方がよっぽど意味があると思う。

2011年4月20日水曜日

Stellarisのバグ?

らしきものを発見!
と言ってももともとエラッタの多いCPUなので驚かないけどちょっとハマったのでメモ。

uDMAをping-pongタイプで使用するときは注意が必要。

もしDMA動作を中断させる場合はDMAENSETの対応ビットをクリアすればよいのだが、再度DMAを開始するときはPrimaryとAlternateをソフトウェアで変更してはダメ!

DMAALTSET/DMAALTCLRというレジスタでソフトウェア的にPrimary側のDMAレジスタを使うか、Alternate側のレジスタを使うかを選択できる訳だけれど、ping-pongモードを使用してこのレジスタを変更した場合、次のDMAリクエストでDMA転送は行われるけれどDMA転送完了時に割り込みが発生しない、という問題が生じている。
具体的に以下の手順。

  1. ping-pongモードでDMA転送を行うよう設定する。
  2. DMAリクエストが発生して、次のDMA転送がAlternate側(DMAALTSETレジスタのビットが'1')となっているときに何らかの理由でDMAを中断させたとする(DMAENACLRに'1'を書く)
  3. 再度DMA転送を開始するために、DMAALTCLRに1を書いてPrimary側を使うよう初期設定し直したのち、Primary側/Alternate側のChannel Control Structureを正しく設定する。
  4. 次にDMAリクエストを発生させると、現在選択されているPrimary側のChannel Control Structureを見ると確かにXFREMODEがping-pong(=3)からstop(=0)になっていることが分かる。しかし、割り込みは発生しない。
  5. このとき、DMAALTSETレジスタはセットされている(ping-pongモードなのでuDMA自身がPrimary/Alternateを自動的に切り替える)。引き続き、次のDMAリクエストを発生させると、今度はAlternate側のXFREMODEがSTOPに変わると同時に割り込みも発生する。
このことから、どうやらDMAモジュール内部では割り込み関係に関してPrimary/Alternateを選択する内部レジスタのようなものがあるが、それはDMAALTSET/DMAALTCLRとは連動していないのでソフトウェアから変更したAlternateの選択状態をうまく反映できていないようだ。

回避策としては、ping-pongモードを使う場合、DMAALTSETレジスタが示す現在のPrimary/Alternateの選択状況に応じて、Primary→Alternateの順か、Alternate→Primaryの順のどちらかでDMA転送を行うようChannel Control Structureを使い分けなければ行けない。

2011年4月15日金曜日

Visual Studioでビルドした実行コードが・・・

なんか肥大したなぁ。

元は1800KBytesくらいだったはずだが、少し変更してビルドするだけでいまは3000KByteを超えている!そんなに変更してないんだけどな~。テンプレートを追加したわけでもないし。
心当たりと言えば・・・

もしかして、昨日のWindows Updateですかね?そういえば、Visual Studioの再頒布可能パッケージがどうのこうの出てたっけ?

と思って昨日のMS11-025を調べてみると・・・、ありました!KB2465361ですな。ここには脆弱性の改善だのなんだのとかしか書いてなくて、ライブラリが大きくなったとは書いてないな。でも、ネットでしらべるとWin2Kで動かなくなっただの、実行ファイルが大きくなっただの、そういう書き込みがあるので原因はこれだろう。
ってか、本当にこれが原因かどうか調べたいんだけれど、KB2465361のアンインストールの仕方が書いてない。ちょっと調べようがないな~。TrueImageで2、3日前に戻せば分かるんだろうけど、普通そこまでしないよな~。

というわけで、とりあえず動いているようなのでモーマンタイとする(悪)。というより、MFCのスタティックリンクしている時点で“アウト”なのかも・・・。

2011年4月11日月曜日

初IKEA

IKEAに行くのが初めてってわけではなく、相方(=妻)と話のタネに何度か行ってみたり、何かを買うつもりで行ったりしたこともあるのだけれど、いつも「何となく欲しいものがないな」「ピンとくるものがないな」ということで手ぶらで帰ってくるだけだった。が、今回はどうしてもチェストと本棚を買うつもりで出かけました。

先日の引っ越しでIKEAまでの距離は遠くなったものの、高速道路の接続が良くなったりで1時間かからずに行けるようになったのは良かった。
いつものようにまずはコーディネートされたショールームのような部屋を回りながらイメージを膨らませていくわけだけれど、どれも上手にまとめられていて「いいね」と相方と話すものの「欲しいな」と思うところまではいかない。私たちは「何でも良い」とか口では言うものの、やはり人とは一ひねり違う「何か」が欲しいがための何か物足りなく、でもその「何か」を具体的に説明できるほどの想像力と申しますか、妄想力もなく、お店側としては一番やりにくい客のタイプではないかと。

それはさておき、今回は必要に迫られてきているわけだし、多少満足できないorしっくりこない部分があっても、それはそれで「妥協する」ということも覚えなければいけないわけで。まあ、その点ではスウェーデンハウスを建てるにあたって妥協の連続を克服してきた私たちですから、今回は何とか折り合いをつけられるくらいには成長しているはず。
そして、とりあえずといっては何だが、チェストを2種類と本棚を(何とか時間切れの感もあってか)チョイスすることができて、カートを押して別フロアの商品棚に移動。そう!「初IKEA」というのは、これまで何度か足を運んでおきながら、「初めてIKEAで買い物をする」という意味だったのです。
自分の欲しい商品があの巨大な棚の上の方に置いてあったらどうやって下ろすのだろう、とか思いながら見て回っていましたが、なるほど縦方向はすべて同じ商品で上部の棚は在庫分なのだと、今更ながら納得。
で、まずは目的のチェストと同じ番号を発見して、カートに移動させる。がっ、やけに重いではないか!まあ成人男子としては筋力はない方ではないので、フンッ!と踏ん張ればカートに乗せ替えるのはそんなに大変な訳ではない。そして、もう1種類のチェストも見つけてカートに移動。こちらはさほど重くない。
最後に本棚を探す。売れ筋商品だけあって、色のバリエーションの他、付属品も多く探すのにちょっと時間がかかったが棚の前に到着。この棚は高さが2mちょいあるのである程度重いということは予想していたが、積んである商品の一つをちょっと手前に滑り出させるだけでも一苦労。ここで初めて気がついた。箱の横に重さが書いてある。「なっ、なにぃ~、39Kgぉ~!!」

まさかそんなに重いものとは思っていなかった。だって、IKEAはDIY商品、自分で組み立てるから安く上がるのがウリだと思っていたから、まぁ普通の健康な成人なら持って帰られるくらいのものかと思っていた。39Kgというとちょっと力のある人でも気合いを入れないと持てない重さではないか。まして体力のない人なら男子でもまずムリ!あーなるほど、先ほどすれ違った家族連れが若夫婦だけでなくその父親も連れてきていたのはそういうことか。確かに見回してみると、ベッドを持って帰るのに父と息子らしき男性が二人で必死になって棚からだそうとしているな。
と感心している場合ではない。この39Kg、しかも2mもの長尺の物体をどうやって持って帰るか。妻は成人といえども女性だし、39Kgの片側をかかえることは難しそうだ。まして、今日は乳飲み子をかかえている。。。相談して、今日のところは本棚は諦めることにした。
この本棚、特に気に入ったというほどでもないけれど、値段的には割安だし、新居に本棚が必要だし、それにようやく妥協点を見つけて買うと決心したところなのに、こんな理由で買って帰れないとなると今度はむしろ買えないことが悔しく思えてくるのはなぜだろう?
まあ、今回買って帰るチェストも結構重かったし、私の老体のことも考えて潔く諦めることにしよう。レジの方に向かいつつ、ちなみにこのチェストの重さがいったいどれくらいなのか?と思ってカートの横を見てみると・・・「な、なにぃ~、35Kgですか!」。そりゃ重いはずだ。
というか、私はいつの間にか35Kgものものを運んでいたんだな。しかも2つも!となると、先ほど諦めたばかりの本棚39Kg、ここまで重くなれば4Kgくらいの差は目クソ鼻クソ五十歩百歩ではないかと思えてきた。やっぱり買って帰ろうかといろいろと思考するも、やはり重さだけでなく、2m超という長さも侮れないな~。一人でバランスよく持つことを考えると、チェスト35Kgの1.5倍くらいの重さ=50Kg超のものを持てるくらいの怪力の持ち主でなければ持てないかもしれない。そう思うと、やはり今回は諦めて誰か男手をもう一人つれて来るしかないと、自らを納得させるのであった。

というわけで買い物終了。これだけのものを買って2万円台で済むのだから安いのは安い!しかし、もう身体が痛くなってきた・・・。先日お世話になったばかりだけれど、本当に引っ越し業の方や配送業の方の体力はある意味「特殊技能」だなぁ・・・感謝感謝。

2011年3月30日水曜日

引っ越し完了?

先日、引っ越し完了!前日は深夜まで荷造りしてたのでクタクタ。まだ身体がダルい。

新居は一部のコアなファンの間では人気の高いスウェーデンハウス。
私たち夫婦はもともとスウェーデンハウスにするつもりなんて毛頭無かった、というのが正直なところ。「木の香りのする和風な家がいいね」「縁側とかあったらいいなぁ」なんて言っていたし、実際近所に立ち並んでいるスウェーデンハウスを見るたびに「こんな家が好みの人もいるんだなぁ」「和室とか無さそう、雰囲気に合わなさそう」とか言ってたし、モデルハウスを始めて見たときも「これだっ!」というインスピレーションがあったわけでもないのだけれど、だからといってシェアトップ4社のモデルハウスは可もなく不可もなくという感じで、人とちょっと変わったことが好きな私たち夫婦には訴えかけるものが何もなく、心に引っかかるものが残ったのはスウェーデンハウスだけでした。
もちろん契約をするときには十分納得した上で契約したわけで、実際に竣工した家を見て、そして引っ越してみても「良かった」と素直に思えるということは、スウェーデンハウスだけが気にかかったのはやはり何か漠然とした相性の良さを感じていたんだろうなと思う。

そして結露がないというふれ込みは正しかった。まぁ、最近の家はどこの家も結露なんてしないんだろうけど、前に住んでいたマンションは特にひどかったので、これはありがたいなぁ。

景気が低迷して収入も下がり気味というこの時期に、しかも東日本の震災のことを思うと浮かれてばかりもいられないけれど、人それぞれに事情があり前へ進んでいかなければならないということで自らを納得させつつ・・・。

とにかく、しばらくは積み上げられた段ボールの荷物を整理するのに忙殺されそうだ。

2011年3月1日火曜日

Cortex-M3 + FreeRTOS = 備忘録

最近はRTOSとして、FreeRTOSを使ってみることが多くなった。uITRON系よりも良いとか悪いとか比較する気はないけれど、FreeRTOSの特徴を挙げてみると・・・

  • シンプルで必要最低限の機能なのが○
  • タスク間通信機能はもうちょっとあっても良いのでは?
  • タスクのサスペンドとレジュームが「カウンタ」方式でないのが、たま~に困ることも・・・


こんな感じですが、安定性や移植性も十分合格点に達していると思う。

さて、このFreeRTOSですがCortex-M3と組み合わせて、割り込み関数内からいわゆる"FromISR"系APIを呼び出していると、まれにvListInsert()関数内で無限ループしていることが起こる。動かなくなったのでデバッガで強制breakするといつもこの関数内で足止めをくらっているという感じ。

無限ループしている行は、

for( pxIterator = ( xListItem * ) &( pxList->xListEnd );
pxIterator->pxNext->xItemValue <= xValueOfInsertion;
pxIterator = pxIterator->pxNext )
{
/* There is nothing to do here, we are just iterating to the
wanted insertion position. */
}

という部分なのだけれど、親切にもこの行の直前にコメントがあり、”この部分でクラッシュする可能性があるのは次の4つがある”と原因も列挙されている。
今回ハマったのはこのうちの2番目だったのだけれど、リンク先を見てもちょっと分かりにくい。

かいつまんで結論を書くと、
  • カーネルの割り込み優先レベルと、実機で使用している割り込み優先レベルとの関係が重要で、FreeRTOSの"FromISR"系APIを呼び出す可能性のある割り込みハンドラの割り込み優先度はFreeRTOSConfig.hに定義されている`configKERNEL_INTERRUPT_PRIORITY'~`configMAX_SYSCALL_INTERRUPT_PRIORITY'の間に設定しなければならない。


ということになる。
その上で勘違いしやすいのが、Cortex-M3の場合は優先度=0が最も優先度が高く、優先度=255がもっとも優先度が低い、ということ。先のガイドラインに従うと、

  • configKERNEL_INTERRUPT_PRIORITY'はもっとも優先度を低く設定しなければならないから255を設定
  • configMAX_SYSCALL_INTERRUPT_PRIORITYは適宜設定してよいがこの値よりも大きい(=優先度が低い)優先度の割り込みハンドラからは"FromISR"系APIが呼び出せて、逆にconfigMAX_SYSCALL_INTERRUPT_PRIORITYよりも値が小さい(=優先度が高い)優先度の割り込みハンドラからは"FromISR"系APIが呼び出せない代わりに、カーネルよりも高いリアルタイム性で割り込み処理ができる

ということになる。

余談だけれど更にややこしいことに、Cortex-M3のアーキテクチャとしては割り込み優先度は0~255までの256段階で設定できることになっているけれど、実際の実装(StellarisやSTM32、NXPなど)では8段階とか16段階になっているということがある。割り込み優先度レジスタは8bit幅で用意されていても書き込んだ値の下位nbitは常に0となって読み出されるという具合。

実はこの無限ループの一件でハマったのは今回が2回目だったような・・・。学習能力に問題アリだなぁ。

2011年2月25日金曜日

もしもUndoがなかったら・・・

いまはも当たり前のように使っているUndo/Redo機能だけれど、
もしもこの機能がなかったらどうだろう?などと思ってしまった。

テキストエディタで一文字ずつ打ち込んだりDELしたりする程度なら直ぐに打ち直せるけど
(っていうか、結構typoは多い方だと思うので、しょっちゅうやってる?)
範囲を選択してまとめて削除なんて怖くてできなくなるのでしょうかね。
他にもEXCELでもCAD系ソフトでも何でも、大きな範囲を扱うときは
「本当にいいのか~。やっちゃうと元に戻せないよ~。いや、ファイルを保存しなければいいんだ。でもファイル開いてからかなりいろいろ変更したあとだよ。ゲー、アレを全部やり直すのか~。覚えてるかな~。」
なんてことになるんだろうな。そうなると、自衛手段としてこまめに名前を変えながらファイルセーブとかやってたでしょうか?
そう思うと、今更ながらほとんどすべてのソフトで当たり前のように使えているUndo/Redo機能は非常にありがたいものだな。

でもちょっと思い返してみると、その昔8bitのBASICマシンが憧れの的だった頃、ベーマガとか買ってはソースコードひたすら打ち込んでいたけれど、あのときはどうやっていたのだろうか、もう思い出せない。
Undo/Redoなんて高度な機能はあるはずもなく、Cut&Pasteすらあったかどうか記憶にないな。間違えてもUndoはできないから、BSやカーソルキーをひたすら連打して間違い部分を直していたのだろう。それでも楽しくやっていたものだったな。
というか当時のマシンは記録媒体と言えばテープだったので、今のような気軽に「保存」なんてできない。マシン語の打ち込みしても保存し忘れて実行してしまったらあっけなく暴走、何時間もかけて打ち込んだコードが全部パァ、なんてことも日常茶飯事だったから、画面上でのちょっとした打ち間違えを直すくらいは屁とも思っていなかったのだろう。

そういう意味では良い時代になったものだな・・・(歳がバレるな・・・)

2011年2月22日火曜日

WinUSBを使ったSET_INTERFACEリクエスト

WinUSBを使って、SET_INTERFACEリクエストを発行する方法を調べてみた。

--(ここから)--

// デバイスインターフェース名を使ってUSBデバイスを開く。
HANDLE hFile = CreateFile();


// WinUSBハンドルで開く
WINUSB_INTERFACE_HANDLE hWinUSB;
WinUsb_Initialize(hFile, hWinUSB);

// 特定のインターフェースを指すWinUSBハンドルを得る
WINUSB_INTERFACE_HANDLE hInterface;
WinUsb_GetAssociatedInterface(hWinUSB, インターフェース番号, &hInterface);


// SET_INTERFACEを実行する
WinUsb_SetCurrentAlternateSetting(hInterface, alternate番号);

--(ここまで)--

エラー処理や後始末はすべて省いた。
最後のWinUsb_SetCurrentAlternateSetting()呼び出しで、実際にUSBバス上でSET_INTERFACEリクエストのトランザクションが発生するとは限らない。SET_CONFIGURATIONリクエストを実行した段階で、すべてのインターフェースは最初のオルタネートが選択された状態になっているので、現在と同じオルタネート番号を指定しようとしても実際にはトランザクションは発生せず、関数はTRUEを返すだけのようだ。

ちなみに、WinUsb_ControlTransfer()関数を使って同じようにSET_INTERFACEリクエストを実行してみようとしたが、何故かwIndexに指定したインターフェース番号の下位8ビットが00hに変更されて送信されるのでインターフェース=0以外にはSET_INTERFACEリクエストを送れなかった。

2011年1月29日土曜日

XPにAHCIドライバをインストールする

いまさらながら、基本的にAHCIに対応していないXPにAHCIドライバを入れてNCQを有効にした状態で動作させる、というネタです。
普通にクリーンインストールをするときにAHCIドライブを認識させる、というだけのことならF6インストールをすればいいわけで、WEBで簡単に情報を見つけることができる。今回のポイントは、既にインストールされたXPにクリーンインストールも修復インストールも行わずにAHCIドライバを導入する、という点にある。

しかし、これもまた同様にWEBにはいくつかの情報が転がっていて2chなんかでも議論されているけれど、今回少し違うのはIDEドライバ→AHCIドライバへの変更ではなく、RAIDドライバ→AHCIドライバへの変更を行うという点で、この点ではWEBでは情報は見つからなかったので、今回やった方法をちょっとリークする。ちなみにターゲットとなるチップセットはICH7Rですが、分かる人なら適宜読み替えてICH8やICH9でも応用できるはず。

本題からそれるけれど、そもそも「なぜRAIDドライバをAHCIドライバに変えたいのか?」というと、「IntelのSSD X25-M用のToolboxがSSDを認識しないのはRAID BIOSが噛んでいるからだろう」という推測のもと、「SSDがあればRAID-0の御利益はほとんどないし、AHCIに戻そう」と思ったのが始まりです。

さて、やり方のおおまかな流れとしては、下記のようにやります。ただし、極めてクレイジーなやり方なので、よほどの自信と覚悟がない人にはオススメできない方法です。もし、果敢に(無謀にも?)トライしてみようと思う方は、あくまでも自己責任でお願いします。

  1. 現在RAIDドライバで起動しているシステムに、AHCIドライバを仮インストールする(詳細は後述)。
  2. BIOS設定をAHCIに変更して(RAID BIOSを切って)、再起動する。
  3. 1でうまくインストールできていれば、AHCIでWindowsが起動できると思う。しかし、デバイスマネージャはエラー(サービスの表示名かエントリが既に使われている、と何とか・・・)を出す。が、動いておればまずはOK。
  4. デバイスマネージャでRAIDドライバがもう読み込まれていないことを確認する。その後、レジストリエディタでRAIDドライバ関連のエントリを全部消す。
  5. 1でインストールしたAHCIドライバは仮ドライバなので、本AHCIドライバを入れ直す(実際にはレジストリエントリの書き換え)
  6. 再起動して、デバイスマネージャがエラーを報告しなければOK。
  7. (必要であれば)最新のIntel Rapid Technology Driverをインストールします。


で、具体的な方法は次のようになります。

  1. 現在RAIDドライバで起動しているシステムに、AHCIドライバを仮インストールする。

    IBMが出している資料が非常に参考になりました。要点は、PnPマネージャによるインストールではなく、ドライバサービスエントリとPnPエントリを手動で追加することでドライバをインストールする、という方法です。
    (1)
    Intelのサイトからマトリックスマネージャをダウンロードしてsetupを実行します。インストールの途中でc:\Windows\temp\iifというフォルダが作成されていますので、この中にあるAHCIドライバ本体とinf/catファイルを別ディレクトリにコピーしておきます(x86とx64用があります)。コピーしたらインストーラは中止します。
    (2)
    コピーしたドライバファイルiaStor.sysをiaStor2.sysにリネームして、c:\windows\system32\drivers\フォルダに置きます(iaStor.sysはRAID用ドライバとして既に居座っているので、これを置き換えることはできない)。
    (3)
    次のレジストリエントリを追加する(.regファイルなどに保存して「結合」する)。
    ここでの注意点は、ここにあるデバイスIDはICH7R用のものである(下のリストの'dev_27c1'となっている部分全部)から、お使いのPCにあわせて適宜変更する必要があるということです。サービスエントリが'iaStor'ではなく、'iaStor2'に変更していることもポイント。

    ~ここから~
    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#ven_8086&dev_27c1&cc_0106]
    "Service"="iaStor2"
    "ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}"

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iaStor2]
    "Type"=dword:00000001
    "Start"=dword:00000000
    "Group"="SCSI miniport"
    "ErrorControl"=dword:00000001
    "DisplayName"="Intel AHCI Controller"
    "ImagePath"="system32\\drivers\\iaStor2.sys"
    "Tag"=dword:00000019

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iaStor2\Parameters]
    "queuePriorityEnable"=dword:00000000

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iaStor2\Enum]
    "0"="PCI\\VEN_8086&DEV_27C1&SUBSYS_03451014&REV_01\\3&61aaa01&0&FA"
    "Count"=dword:00000001
    "NextInstance"=dword:00000001

    ~ここまで~
  2. (特に説明なし)
  3. (特に説明なし)
  4. の「その後、レジストリエディタでRAIDドライバ関連のエントリを全部消す。」については、ICH7Rの場合はデバイスIDが'DEV_27c3'となっていたので、これに関連するレジストリエントリはすべて消しました。
  5. 1でインストールしたAHCIドライバは仮ドライバなので、本AHCIドライバを入れ直す。

    これについては、まずドライバ本体を先ほどインストールしたiaStor2.sysからiaStor.sysにリネームします(この段階ではRAID用のiaStor.sysはもう使用されていないので削除できるはず)。
    そして、上の.regファイルで追加したレジストリエントリの'iaStor2'となっている箇所を、'iaStor'にリネームします。具体的には、レジストリエントリ
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iaStor2→iaStorとするのと、
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#ven_8086&dev_27c1&cc_0106キーにある値"Service""iaStor"に、
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iaStorキーの"ImagePath""system32\\drivers\\iaStor.sys" と書き換える。

ポイントとしては以上ですが、(言うまでもありませんが)このような極めてクレイジーな操作が一発でうまくいくとも限らないので、私はTrue Imageでバックアップしてから行いました(ええ、一度はリカバリする羽目になりましたよ)。


....


で、なんとかAHCIに切り替えることはできたわけだけれど、当初の目的であった「SSD Toolboxを使えるように」という目標は叶わなかった。結局、ドライバを変えてもToolboxはSSDを認識してくれずドライブ一覧は空白のまま・・・。なんで?

2011年1月25日火曜日

上棟打ち合わせ

先週末は、上棟打ち合わせだった。

なんか変な気分。自分が家を建てているという事実、そして実際に家が建ってきているという事実が。


上棟打ち合わせの前は・・・

これまでも何回も打ち合わせを重ねてきていたし、もうン千万も支払ってきたというのに、なんとなく実感がなかった。そして、常に「これでいいんだろうか?」という自問自答が繰り返し頭の中を駆けめぐっていた。
地縄確認のときなんかは、実際に土地の上に建物の場所を示す縄が張られていたのを見て、「こんなに狭いのか?」と感じてしまい、「こんなはずではない。。。」「これは現実ではない・・・」とかちょっと現実逃避をしていたのかもしれない。

実際に建った家に入って見たときの第一印象は「やっぱりちょっと狭い?・・・かな」と思ったと同時に、これまでの打ち合わせで何度も何度もイメージしたとおりの間取りだったのであまり違和感というか始めてきた場所のような感じは覚えず、「やはりこれは現実なのか!」と今更ながらに実感するところもアリで、これまた不思議な感覚。

それでも、上棟打ち合わせが終わる頃には、「広さも、まあこんなものかー」と思うくらいになっており、「現物を見たらガックリするかも?」という不安を杞憂に終わったように思う。

とりあえずは、「完成が楽しみになった」という気持ちで終わったという点では、これまでの数々の選択はそんなに間違っていなかったのかな、と思う。

2011年1月24日月曜日

Pavilion Desktop PC HPE-360jp/CT販売終了

現時点で6コアCPU搭載でこの価格はかなりお買い得なのでは?と思って注目していたHPのPavilion Desktop PC HPE-360jp/CT 価格.com限定モデルが急に販売終了となってしまったようだ。


主なスペック
Phenom II X6 1045T(2.7GHz)
DDR3 PC3-10600 4GByte
HDD 500GByte(7200rpm)
光学ドライブ DVD±R/±RW/RAM/±RDL
IEEE1394+光デジタル出力
Windows7 Home Premium


これで\45,150-だった。
まあ特に買う理由は見あたらないしそもそもそんな予算はないのだけれど、お買い得なだけに買えなくなった悔しさがにじみ出るのは何故だろう?


敢えて買う理由をこじつけるなら、職場のメインPCは未だにPen4 3.4Gzという3世代?4世代前くらいのもので、もう5年以上毎日8時間以上使っているので元は取れたので、そろそろ買い換えてもいい時期かと。
景気のいいときなら会社に談判すればサクッと買ってもらえるのだけれど(いや、実際『買ってもいいよ』というお墨付きはもらっているのだけれど)、このご時世ですから無駄遣いせずに自制モードです。

2011年1月22日土曜日

RAID用に使っていたHDDを別のPCにつなぐと。。。

あるPCで3台のHDDを使ってRAID-0を組んで使っていた。1台160GBだったので3台で480GBだった(実容量は447BGくらいだったけど)

このHDDのうち2台で再度RAID-0を構築し直して、残りの1台はRAIDではなく単独で使うことにした。
USB-SATA変換で接続しているときは問題なく160GBのHDD1台と認識していたのに、RAIDを組んでいたPCとはまったく別のWindows7をインストールしたデスクトップPCの内部SATAポートに直結すると、HDD単独の160GBの容量ではなく、RAID構築時の447GBのドライブとして見えている。何故だろう?RAID構築時の情報がHDDのどこかに残っていてそれを誤認しているのだろうか?

このHDD、困ったことにフォーマットどころか、パーティションの作成・解放はおろか、MBR/GPT初期化すら行えないという、非常に困ったことになってしまった。
まずBIOSの設定としてRAIDではなくAHCIを選んでいるので、HDDがRAIDボリュームとして見えることは無いはずだと思う。あとは、IntelのRapid Storage Technologyドライバを入れているので、そのせいでRAIDに関する情報を誤認している可能性があるかも。そうだとしたら何とかしてその情報を消さねばならない。しかし、いまはどのようにアクセスしてもエラーになるので消すための操作すらままならないな。

と思ったら、True Image 2009の起動ディスクで起動すると今度はちゃんと160GBのディスクとして認識した(HDDが物理的・電気的に壊れている訳ではなさそうだ)。やはりWindows(かIntel RSTドライバ)が余計な気を利かせているのだろう。TI2009のcleanse diskで本当にまっさらに戻せば直るのか?と思ってcleanseを始めて見たもののものすごく時間がかかるみたいなので、HDDの先頭部分のみcleanseして(後でdiskをダンプするとMBRとその後ろの部分がキレイさっぱり00hに消えていた!)再度Windows7を起動するとやはり447GBの不明なボリュームとして認識されて、エラーが発生した。
RAIDの識別情報ってHDDの後ろの方にあるのかな~。知っている人がいましたら、教えてください>誰ぞ。


(2011/1/25追記)

解決した。

結局は、RAID BIOSの設定画面からRAIDのメンバ登録を抹消しなければいけないみたいです。
基本中の基本的なことで躓いていたわけですが、今回は

○RAIDを組んでいたPCとは別のPCにつないで再利用としていたこと
○そのPC間ではチップセットが異なること(旧PCは945で新PCは965)
○その新しいPCではRAID BIOSを切っていたこと

などから、まったく新しいHDDと認識されると思っていたのですが・・・。やはり、HDD上のどこかにRAIDのメンバであることを識別する「何か」が書き込まれていて、Windowsさんはそれを(勝手に)探すのですかもね。
後日インテル系チップセットでのRAIDメンバ認識に仕組みについて調べてみることにしよう。