もしかして・・・失敗？

先日LenovoのThinkPad E430をポチったわけですが、その後いろいろ見て回ると納期遅れがよくあるらしく、１ヶ月くらいはザラにあるような書き込みもあって、ちょっと後悔モードです。

今のところ、7/19日納期というステータスが出てて、それでも「遅いな～」という印象なのに、情報を信じるならば「今月は来ないもの」だと諦めておくくらいの方がイライラしなくて済むと精神的自衛モードでもあります。

しかし、この手の「悪い」情報（というか文句、愚痴）はそういう目に遭った人が書き込んでいるその裏にはちゃんと納期通り（か、遅れても多少で）購入できた人も多いはずで、そういった人の存在をネグってネットにたまたまあがっている情報だけを信じると本当に悪い方にしか考えられなくなる訳であまりよろしくないと思います。
Yahoo BBがキャンペーンを派手にやってシェアを伸ばしたときも、やれ速度が出ないだの、やれ切れやすいだの色々言われていましたし、いまでもamazonなんかも納期遅れが出ただの、商品が入荷しないだのでゴネている人をネットでちらほら見かけます。その人たちの身に起こったことは事実だと思ってますし、キノドクな事だなあと同情もしますが、私自身はYahoo BBを使ってたころ特に問題を感じたことはなかったし、amazonでいろいろ買い物もしてますが、特に納期トラブルが起こったことはないです。

問題が大きく見えているのは、問題が起こっている確率は他の会社でも同じようなものでも（だったとしても）分母が大きい（＝シェアが高い、売り上げ数が大きい）ので、問題の発生件数の絶対数も大きくなっている、という点ではないでしょうか。

他人の不幸を喜ぶ訳ではありませんが、そういう意味では私の注文が大多数の購入者と同じように予定納期通りに進行することを信じたいです。
でも、Lenovoがいまは中国企業だということも考えると、やっぱり「キノドクな人たち」の仲間入りをするんでしょうか＞＞＞私。結果は、またここで報告したいと思います。

また悪い病気が・・・

出てしまったようです。「新しいPCが欲しい欲しい病」。

テスト用にQuadコアのPCが欲しいなぁ、と漠然と思っていたんだけど、LenovoのThinkPad Edge E430ってかなり安くないですか？と思ったら、もう止まらなくなってしまってポチってしまいました。

いま使ってるLet's NoteのS9も速くて軽いし気に入っているんだけど、電車通勤しなくなったらここまでのモバイル性能は必要なくなってしまったし、いまならまだそれなりの値段で売りさばけるので、最新IvyBridgeなPCと事実上“交換”できるレベルであることに気づくと、これはもう買い！だな、と（←勝手な屁理屈）。

Core i7-3612QMでUSB3.0もついてなかなかよいが、本当はちょっとだけ不満なところがある。
まずはサイズ。14インチじゃなくて13インチくらいならベストだったんだけどな。ついでに言わせてもらえば、解像度も1600×900くらい欲しかった。
それから、I/FもUSB3.0があれば十分だということなんだろうけど、できればExpressカードスロットが１つは欲しかったな。
重さは軽ければ軽い方がいいけれど、まあこんなもんでしょう。でもLet'sの倍近くあるから最初は重く感じるだろうな。
メモリは８Gあるから十分だけど、今どきHDDはチョット・・・。速攻SSDに交換することになるでしょう。

早くコイコイ。環境を移行したら、Let'sは早めに売ってしまおう。

GCC ARM備忘録

arm-none-eabiなARMをターゲットとしたgccに関する備忘録（Cortex-M3を想定）

1. gcc(Cortex-M3)において、関数呼び出し後のSPの位置は必ず8byte境界にアライメントされていなければならないようだ。
   
   これまでは4byteでアライメントされていればよいと思っていた。しかし、可変長引数としてfloatやdoubleを渡そうとすると、その値は８byte境界にアライメントされて関数に引き渡されることが判明した。例えば、int型５つとfloat型１つを関数に渡すと仮定すると、int型の最初の４つはレジスタR0、R1、R2、R3に、５つ目のintはスタックにpushされ、次のfloatはdouble型に変換された上でスタックを１つ（＝１ワード＝４バイト）飛ばして、次の8byte境界となるスタック上に8バイト値（double型に変換されているので）がpushされることが分かった。
   そういえば、以前Cortex-M3関係で割り込み動作を調べているとき、ISRは常に８byteアライメントを要求していたような記憶が・・・・。もう、どこで知った情報か忘れてしまったけど。
   
2. 上記のように、可変長引数を持つ関数にfloatを渡そうとすると、doubleに変換された上で8byteにアライメントされてpushされる（レジスタ渡しの場合は[R0,R1］ペアか、[R2,R3]ペアに入る）。ということで、渡すfloat型の引数より前にある引数が奇数個であった場合はレジスタなりスタックにパディングが入る可能性がある点に注意が必要だった。
   なお、va_arg()で引数を一つずつ取り出すとき、コンパイラはdouble型を取り出す場合には自動的にパディングの存在を調べてスタックをずらして読み出すので（va_argで読み出す型と順番が間違っていない限り）問題は出ないようになっているようだ。パディングの存在自体はSPの末尾３bitを調べて調整する方法をとっているようだ。なので、もし万一、関数を呼び出すときのスタックが8byteアライメントになっておらずに４バイトずれていたとしたら、上のような可変長引数を持つ関数＋float/double型引数を持つ呼び出し処理においてはおかしな動作になってしまう。
   
3. 余談だけれど、↑のようなことに気がついたのはたまたま使っていたFreeRTOS v4.9.2に不具合があったからだ。
   FreeRTOSのCortex-M3用portルーチンでタスクの初期化のところに不備があり、タスク関数が呼び出されたときのスタックポインタは８byteアライメントになっておらず、常に＋４バイトずれていた。そのため、そのタスクから呼び出される関数はすべて＋４バイトずれたスタックポインタを持っていて、通常の関数呼び出しでは問題はでないのだけれど、上のようなケースでは問題になることがあった。
   ちなみに、FreeRTOS最新版（v7.1.1）では問題のportルーチンは対策されていた（タスク起動時の初期スタック状態を初期化する際に、余分にパディングワードを挿入するようになっていた）。

ああ、やっぱり組み込みは難しいなぁ。

VisualStudioのデバッグ実行が遅い件

以前から悩んでいた件が解決した。
VisualStudioでデバッグ実行を行うと、実際にアプリが起動して動作するまでにたっぷり30秒以上は待たされる。これではTAT（Turn Around Time）が長くて効率が悪いばかりかイライラしていた。
しかも、Core i5のPCでは30秒以上もかかるのに、Pentium4のPCではスッと起動するから、なおさらイライラして怒りの矛先をVisualStudio2008とMSに向けてしまったものだ。

しかし、原因がようやく分かった！

ブレークポイントの設定が多すぎたんだ！

実際、私のデバッグスタイルでは、

• 新しく作った関数の先頭にブレークポイントを張る
• デバッグ実行してブレークに引っかかったら、ステップ実行で関数の動作を確認し、問題がなければ先頭のブレークポイントを削除する。もし、関数内の分岐条件などでスキップされる処理があれば、そのスキップされる箇所に新しいブレークポイント設定する。
• いろいろな条件で動作を繰り返して、すべてのブレークポイントが消えたら、つまりすべてのコードをステップ実行して動作確認できたらデバッグ完了とりあえずひと安心。

という感じなので、どうしてもブレークポイントが多くなってしまう。

デバッグ実行が遅い件については、suoファイルを削除するという方法がこちらやこちらなどで紹介されているけれど、suoファイルはブレークポイント以外にも「ユーザータスク」に入力した内容なども記録されているので安易に消したくはない。単純にブレークポイント一覧からすべて選択して削除すればいいだけだった。

HV熱は終わったはずだけど・・・

2012年初頭あたりからいま乗っているクルマの車検をにらんで乗り換えを検討していたところに、ちょうどTOYOTAのアクアが出たということで試乗もしてさんざん悩んだんだけれど、結局はこのまま乗り続けることで決着したはず。なのに・・・

これまでは価格が高いし、自分の用途には向いていないということで気にも掛けなかったプリウスPHVが気になり始めている。

基本、長距離通勤（往復100km以上）に使うという点では、ネットでいろいろ言われているように、EV走行できる距離は限られているから長距離ではHVと変わらない、だからPHVは無駄だという意見が見られ、私もそのとおりだと思う。
しかし、HVを試してみたいという思う理由の一つは、エンジン走行では効率の悪い部分（上り坂や追い越し加速）でエンジンの回転数を上げるのではなく、モーターのアシストでカバーするような使い方ができれば燃費が抑えられるのではないか？という期待があるから。でも、アクアを試乗した感じでは緩い上り坂でもエンジンは唸るし、少しきつくなるとブン回さないといけない感じがあった。確かに出だしの加速はモーターのみでいい感じだけど、坂道でのアシストが貧弱なのはちょっといただけない感じだしたのが、アクアを断念した理由の一つ。

その点、プリウスPHVではバッテリーが大きくEV可能距離も長いようだから、上のようにモーターアシストが必要だと思われる部分では思い切ってEVモードに切り替えてその部分をやり過ごし、あとは定則走行＆下り坂＆ブレーキ回生のときに（再）充電してくれればなんと理想的なんだろうと（勝手な）期待をしている。しかし、価格comの口コミ情報から察するに、プリウスPHVは”EV走行してなんぼのもん！””足りなくなったら自宅で充電”というコンセプトが強いようで、回生エネルギーによる充電はするものの、エンジンを使った充電にはあまり積極的な設定ではないそうな（そりゃ、エンジンで充電するより、深夜電力で充電する方が安くなるんだから当然か）。まさに近距離での使用を想定した設定だなあ。

とはいうものの、やはり気になる存在＞プリウスPHV。
というか、実際に自分の乗り方でどうなるかを試してみたい。ディーラーに行けば試乗はさせてもらえるけど、私のような高速を使った超長距離通勤とは全然乗り方が違うのであまり参考にはならないかなぁ。１週間ぐらい連続で試せたらいいのだけれど、まして人気車、そんなこと許してくれるはずもない。あとは、敢えて自腹レンタカー・・・ですか？なんてこれもムリ！

TortoiseSVNのビックリな機能

Subversionのリポジトリに入れておいたexcelのファイルを更新したので、何気にdiffをかけてみた。
おそらくバイナリでの比較になるんだろうと思っていたら・・・。

なんと、

新旧二つの.xlsファイルをEXCELで開いて並べて表示した上に、違いのあるセルが赤く表示されているっ！

ではないですか。
まさかそんなことまでやってくれるなんて・・・。やっぱり、TortoiseSVNにして正解ですね。

"Terra Nova"強制終了？

大物監督＆プロデューサーとリアルな映像を武器に鳴り物入りで始まった海外ドラマ"Terra Nova"が打ち切りになるようだ。

う～ん、確かにこれまで見ていた感想としては「ちょっと間延びした感じ」というところ。
基本的な時代設定・背景設定はいいと思うし、海外ドラマではよくあるいろいろなナゾ/秘密を仕掛けているあたりは、まだ始まったばかりだしこれからの展開に期待してもよいのかな？という感じで見続けていたけど、各回のストーリー自体はなんというか幼稚かつ下世話な気がしていた。

例えば「空を覆う闇」では、結局は翼竜をフェロモンで他の場所に誘導するというチンケな結末だし、最後にジムたちが言った「色気づいた翼竜たちの声といったら聞いちゃいられない・・・」みたいなしょうもない一言のせいで更に台無しに。
先週の記憶をなくす病気の回でも、風邪を引いたジムが病気を発症しないからと言って奥さんの病気を治すのにキスをしたらもう次のシーンでは直ってる、なんていう単純な展開もどうしたものかと。

どうしよう。打ち切りと分かっていて続きを見るべきか止めるべきか。「打ち切り」ということでいきなり話がブチッと終わるのなら消化不良になるだけなのでもう止めるけど、話の結末を急いでとりあえずの終わりがあるならもうちょっと見続けてみようか・・・

WinUSB_ControlTransfer()が動かない理由

結局は自分のしょーもないポカミスなんだけれど、ある掲示板で同じようなことを質問していた人がいたのと、ちょっと気づきにくいミスなので、備忘録の意味も含めて書き留めておく。

WinUSBを使ってUSB通信を行うとき、ベンダspecificなリクエストを送信するコントロール転送を行うのに、
SendVendorSpecificRequest_in()とSendVendorSpecificRequest_out()と名前の関数を用意してこれを呼び出すようにしていた。
問題の始まりはコントロールOUT転送を行うSendVendorSpecificRequest_out()関数の引数の型だった。

これは送信を行う関数になるので、DATAステージのデータをconst void* なポインタで渡すようプロトタイプ宣言していた。つまり、

bool SendVendorSpecificRequest_out(
　　...,
　　const void* dat,　// DATAステージで出力するconstなデータ
　　int len,　　　　　　// DATAステージで出力するデータ長さ
　　...);

という感じ（他の引数は省略）。
こういう関数を用意すると、この関数の呼び出し側では

static const char text_data[] = "hogehoge";


SendVendorSpecificRequest_out(
　　　...,
　　　text_data,
　　　strlen(text_data),
　　　...);

みたいな呼び出しができる訳だけれど、これが間違い。
それはこの関数の中身の実装がこうなっていたから。

BOOL SendVendorSpecificRequest_out(
　　　...,
　　　const void* dat,
　　　int len, ...)
{

　　　WINUSB_SETUP_PACKET setup_pkt;
　　　setup_pkt.RequestType = 0x40 or 0xC0;
　　　setup_pkt.Request = リクエストコード;
　　　setup_pkt.Value = wValueの値;
　　　setup_pkt.Index = wIndexの値;
　　　setup_pkt.Length = len;
　　　ULONG sent;
　　　return WinUsb_ControlTransfer(
　　　　　　　　　　　　　　WinUSBハンドル,
                      setup_pkt,
                      (PUCHAR)dat,
                      len,
　　　　　　　　　　　　　　&sent,
　　　　　　　　　　　　　　NULL);

}

WinUsb_ControlTransfer()の第三引数を無理矢理PUCHARにキャストしているところが間違い。
コントロールOUT転送だからWinUsb_ControlTransfer()関数は第三引数で示されるポインタを使ってreadしか行わないだろう（＝read属性のみのメモリを渡してもキャストしておけば大丈夫）と思っていたら、内部の実装はそうではないようだ。コントロールOUT転送でもここで渡すポインタは必ずread-write可能なメモリのポインタを渡さなければならない。
という訳で回避策は、WinUsb_ControlTransfer()関数に渡す前に別のread-write可能なバッファにコピーしてから呼び出すか、そもそもSendVendorSpecificRequest_out()関数のプロトタイプからconst修飾子自体を取ってしまって、constなポインタは渡せないようにするか・・・。

Intel SSD Toolbox その後・・・

以前の書き込みでIntel SSD ToolboxがX25-Mを認識しないということを書いたあと、その後もう諦めて放置していた。

今日何となくIntelのHPを見に行ったら、新しいToolboxがダウンロードできるようになっていたのでダメ元であまり期待せずにダウンロード＆インストールしてみたらビックリ！UIが大幅に変わっていた。
あまりにも変わり過ぎで直ぐに気づかなかったけれどよく見るとX25-Mが２台とも認識されているではないか！

というわけで、optimizeもできるようになったし、SMARTも詳しく見られるようになったので満足。
ってか、今まで見えなかったのはやっぱりバグなんでしょうかね。何回も再インストールして時間を使っちゃったんですけどぉ。

まさにオカルト・・・

おもしろい記事を見つけた。

http://magazine.kakaku.com/mag/kaden/id=700/

PCに接続して再生するタイプのオーディオ機器について、その音質について何やら理屈っぽいことを書いてありますが、 その中で「PCオーディオへの接続方法はUSB接続だと、演奏の細やかなニュアンスや空間的な拡がりが損なわれる！」とされていて、その原因が

　　「USB接続ではエラー訂正が行われないからだ！」 

と結論付けられている。
何ともこんな理屈がまともにまかり通りと思って書いているんでしょうかね？

「USBでエラー訂正が行われない」というのは、おそらくアイソクロナス転送においてCRCエラーが発生したときにパケットがそのまま捨てられる、バルク転送のように再送はされない、ということを指しているようだけども、
そもそもUSBがもうかなり枯れた技術（SuperSpeedは除く）だし、これまでUSBアナライザを使ってUSB機器を 何種類も開発してきましたけど、USB接続でCRCエラーが発生することはそんなにありませんよ。

まあ、よっぽどひどいケーブルを使うか、延長ケーブルを入れたりしたら起きないわけではありませんが、 普通に売ってるケーブルを使えばエラーが発生する頻度なんて数千万トランザクションに１回あるかないか？くらいで、たかだか数分の曲を聴いている間に１回起きるか起きないかのエラーで「演奏のニュアンス」や「音の拡がり」が損なわれるという理屈はまったくもっておかしな話だ。
せめて、定常的に起こる（１秒間に数回～数十回も起こる）細かいエラーの頻発で音質に微妙に影響している、という論理なら、まだ理解もできるのだが、今度は逆にそんなにエラーが頻発していたらUSB通信自体 崩壊してるでしょ？って話。

それに、USBで送られているデータは通常PCMなんだよね。 仮にPCMストリーム上でランダムに１bitが化けるとしたら、そのビットがPCMデータのMSB側かLSB側かで 出てくる影響は全く違うでしょう。LSB側のデータ化けなら微妙な音質の劣化として聞こえるでしょうが、MSB側が化ける場合も想定しないといけない。
もしMSB側のデータ化けなら、それこそ「バリッ！！」と大音響でノイズが乗るのは目に見えている（いや、耳に聞こえてる。笑）。その点からしても先の記事の理屈は変だ。
まさに、この記事自体が「オカルト」。

実際には、アイソクロナス転送でビット化けが起こったとしたらCRCチェックで引っかかるからそのパケット自体が捨てられる。つまり、本来送られるはずのPCMデータの一部がごっそり抜けて無くなることになる。そうなると、やはり人間が感知できる影響というのは「バリッ」という大きなノイズになるはず。
まあ、USB DAC側で何らかの対策がしてあるとしたら、そういう大きいノイズを避けるために瞬間的にミュートされるかもしれないけど、いずれにしても音の拡がりがどうのこうのいうレベルではない。
「１パケットが失われる」＝「1ms分のPCMデータが失われる」＝「約44サンプル分のPCMデータが失われる（44.1KHz再生の場合）」ということなので、 どんなに優秀なUSB DACでもその失われたPCMデータを補完できるわけもなく、ノイズ発生は避けられまい。
ほんとに「オカルト」な話だな～。