2008-09

2008-08

とりあえず９月にしてみる。†

ここで意味のない質問

Ｑ：２００８.９月(Dark September)の行事は何？
Ａ：次の中から量子力学的に選択。

  • 天変地異（地震）
  • テロ
  • （原油？価格）暴落
  • 間違って（余剰次元の理論がたまたま当たって）ＭＢＨが生成され地球が飲み込まれる。（これはありえないらしい）
  • 当たった場合でも、ＭＢＨの寿命は光速で動いても原子核のサイズより小さいらしいので、一瞬で蒸発するらしい・・・大丈夫、だよね。
  • 当たらない場合は、ＬＨＣが出せる最高出力の（１０の１６乗）倍のエネルギーがない限りＢＨは作れないらしいので・・・大丈夫、だよね。

とりあえず、北京オリンピックは無事開催されたので、ジョン・タイターのいた時間線とは離れたらしい。

あとはアメリカが内線状態にならないならおＫ。

いや、仮にせよ、ＭＢＨが作れたとしよう。

  • どうやって空間に固定すんの？
  • どうやって平衡状態にすんの？

それが出来るなら、ＭＢＨから出るガンマ線放射で半永久発電できるという話だが、かなり眉唾である。

  • 外部からは、適当な物質を投げ込むだけ。
  • ＢＨ蒸発（ホーキング輻射）の放射で発電。
  • 平衡状態が崩れたら地球を飲み込んで成長するかもしれないので、原発よりかなりハイリスクハイリターン。

で、そんな危険なものを使ってタイムトラベルして来たとジョン・タイターは主張していたらしい。

  • ＭＢＨネタのＳＦは、ＪＰホーガンの「星を継ぐもの」３部作にもあった。
  • まあ、チューリアンの文明は進んでいるので、ＭＢＨの制御とか可能なんだろうけど。
  • 今の人類には到底無理無理。
↑

Athlon64 2000+とAtomの比較†

  • これを見る限りではＡＭＤまだまだ元気だぉ。
  • 単体ＣＰＵではなくチップセットまで含めると、ＡＭＤのほうが省電力で高性能って、いったい・・・。
  • ビデオ性能ではＡＭＤ７８０のほうが断然良いよね。
  • ＡＭＤはさっさとＧＰＵ統合してＮｅｔＢｏｏｋ市場でもＡｔｏｍに勝って欲すい。
↑

Ａｔｏｍの事情。†

■元麻布春男の週刊PCホットライン■
Netbookの生きる道

引用ここから

  • 現在、市場にはさまざまなミニノートPC/Netbookが市販されているが、
  • エントリークラスのノートPCとの差別化を図るためIntelは、いくつかの条件を挙げている。
    • ディスプレイを大きくし過ぎないこと、
    • HDDよりも小容量SSDを採用すること、
    • 価格をさらに低く抑えること、
    • Web中心でアプリケーションの追加インストール等はあまり考えないこと、
    • シングルスピンドル(光学ドライブを搭載しないという意味)であること、
  • などだ。手っ取り早くいうと、高性能化を図るより、低価格化を行なえ、という方針らしい。市販の製品の中では、ASUStekのEee PCがIntelの言うNetbookに一番近い存在だ。

ここまで。

  • まあ、こういう縛りがあったわけだな。
  • だから、普通サイズのノートＰＣに（ベンダー側は）使えないというわけか。
  • 性能的にはＰｅｎＭの１Ｇ程度はあるので、充分使えるんだけど。
  • ついでに言うとEee PCはちっちゃくて可愛いのは良いが、発熱が気になるので手を出せない。
  • 店頭の展示品は冷房の効いた店内でも裏面は熱くて長時間触れない。パームレストのところもやや熱い。
  • インテルはほんとにＡｔｏｍの片割れの９４５をなんとか改善して欲しいと切に願う。
↑

ついに出てきた高速ＳＳＤ†

IntelがIDFで1.8/2.5インチの高速SSDを発表

  • http://pc.watch.impress.co.jp/docs/2008/0820/mobile421.htm
  • ２５０ＭＢ/Ｓか。それってＳＡＴＡ２の転送限界に近いじゃん。
  • ＳＡＴＡ１なら１.５Ｇｂｐｓだけど８-１０エンコーディングされてるはずなので１５０ＭＢ/Ｓが理論上の上限だ。
  • 逆に言うと、それ以上速くする必要もない
  • 速くしても対応ＩＦもないし、ＨＯＳＴ側ＰＣが追いつかない。
↑

Ｄｅｂｉａｎ（lｅｎｎｙ ａｍｄ６４）のインストールに失敗。†

  • 原因は今のところ分からない。
  • テキストインストーラー、グラフィックインストーラーのどちらも現象は同じ。
  • ベースパッケージのインストールまでは成功。
  • パッケージの選択で、 
    [＊] デスクトップ 
[　] （中略）
[＊] 標準のシステム
    を実行した後、暫くして赤い画面になり、パッケージセレクトに失敗した旨のメッセージが出る。
  • [ＡＬＴ]＋[Ｆ３かＦ４のどっちか]でエラーメッセージを読もうとしても、字化けして読めない。
  • 上記選択肢をいろいろ変えたけれど駄目。
  • かれこれ５回くらい同じことを繰り返した後に、もう諦めた。
  • 玄箱Ｐｒｏのほうはちゃんと動いているからいいや。
    • 実はちゃんと動いていない。いくつか疑問点があるので、フルセットのＰＣ版を用意したかったのだ。
    • だったらＥｔｃｈのｉ３８６にしとけって？ごもっとも。
    • でもｌｅｎｎｙのＤＶＤ５枚も焼いちゃったし。
  • 疑問点というのは、localeがja_JP.EUC-JPになっているときは、man pageが引けない（invalid charset name）になる、というものだ。
  • わざわざUTF-8に切り替えれば、manは引ける。
  • あと、LANG=C man ls とかやれば、英語で出てくるけど。
  • 追記： この問題は less がeucに対応していないこと、らしい。
  • 回避策としてはlvをインストールして export PAGER=lv だ。

インストールには失敗しているけれど、その後ＧＲＵＢ入れて再起動させれば一応Ｄｅｂｉａｎは最小構成で動いている。

  • まあ、その後に地獄の設定が待っているわけだが。
  • フルパッケージに近い状態まで一撃でインストール出来るようになってないのかな？それともベータだから？
↑

ＩＦ２００８.８付録基板 ちゃんと動いたっ！†

壊れてなかった。

  • この基板どうやら死んでるくさい。はずれくじを引いたか？
  • ＰＣを192.168.1.2に手動設定して、192.168.1.10にPINGを送っても無反応。
  • telnetもwebも無反応。

別環境（スイッチングハブ）にて接続したところ、ちゃんとtelnet接続出来た。

  • 原因はコレ
  • http://kumikomi.typepad.jp/interface_coldfire/2008/08/faq-no5-bd57.html
    • 実は同コントローラには，他にもオート・ネゴシエーション機能にエラッタがあり，
    • オート・ネゴシエーションが正常に動作しません．そのためオート・ネゴシエーション
    • 機能を切り，SilentCでは10Mbpsで，GDBスタブでは100Mbpsで，固定設定としています．

１０Ｍｂｐｓの半二重だってー（ＡＡ略）

  • そりゃ動かんわ。
  • なにせ、以前に試したハブは１００ＢＡＳＥのリピーターハブだ。
  • バッキャロー
↑

jedで漢字を使いたいよー。†

大概のＬｉｎｕｘ上には、jedというEmacs風の軽量エディタが存在する。

  • 自分はviもemacsも使えない人なので、日頃からjedを愛用している。
  • カスタマイズの結果、使い勝手では、昔のＶｚと同じくらいに使えている。（と思っている）

ところが、最近のjed(0.99.18,VineLinux5.0とdebian Etch)では、SJISが使えなくなっているようだ。

  • VineLinux4.2用(0.99.14+J0.6.12)はＯＫだった。
  • ソースを展開してみると、・・・ 
    slang-1.4.9/src/slkanji.c
    が無くなっていた。
  • いや、それだけじゃない。EUCのテキストファイルは開けるのだが、カーソルが全角単位で移動しないので、EUC漢字を２文字のASCIIと勘違いしている。
  • で、UTF-8ならちゃんと編集出来るのかと思ったら、そうでもないようだ。（ＳＪＩＳと同様に激しく字化けする）

日本語パッチされたjedが欲すい・・・

  • というか単にjed単体で良ければ実行ファイルと設定ファイルをコピーというやりかたでＯＫなはずなんだけど、jedはslangに思いっきり依存しているので、slangもデグレードしてやらないといけない。
  • けれど、slangのデグレードはrpmとかのパッケージマネージャーに怒られるんで、どうしよう・・・。
  • よく見たらlibslang1とlibslang2は分離していたので、libslang1だけVineLinuxのソースからビルドして差し替えようか。
  • だけど、UTF-8なテキストがエディット出来ない問題は、棚上げだ。
↑

Ｄｅｂｉａｎ（Ｅｔｃｈ ａｍｄ６４）のインストールはＯＫだった。†

  • もう３枚のＤＶＤ-Ｒを焼いた。
  • しかし、インストールは最初の１枚だけで足りたようだ。
  • パッケージ選択でエラーして赤い画面に行くことも無く、わりとフルインストール（２Ｇ強？）状態になってくれた。
  • ｊｅｄを入れて、ＵＴＦ−８のテキストを編集してみた。
  • おかしなことに、カーソルバック（＾Ｂ）は正しく全角単位にカーソルが動いてくれるが、
  • カーソルフォワード（＾Ｆ）を打つと、常に文書末にジャンプする。
    • キガクルッテルノカ？
  • ＡＳＣＩＩ文字のところはそんなことない。ちゃんと１字づつカーソル移動できる。
  • Ｅｔｃｈは一応最新版なんだけど。
  • ６４ビットだから駄目？そんなぁ・・・・。
  • しかしあれですな。手持ちのＣソース、６４ビット版のｇｃｃだとこけるこける。
  • 大半はポインタをintにコピーしているところ。これ多いんだよな。
↑

ASUSTeK、「Eee PC 900-X」を実売49,800円で国内販売〜実売39,800円の701 SD-Xも†

http://pc.watch.impress.co.jp/docs/2008/0829/asus2.htm

  • 何だ何だ？
  • ついぽちッとな、しそうになるじゃないか。
  • これで英語キーなら、即買っちゃうぞ。
>また、内蔵SSDの容量不足を補うため、30GBの外付けUSB HDDが付属する。

何だってー。

  • 30GのUSB-HDDなんて、実は２台くらい持ってるけど
    • ノートＰＣ壊れる-->修理不能-->部品取り-->９８０円のＨＤＤケースに入れて外付けＵＳＢＨＤＤが増殖するの巻き。
    • おまけだから無くせないけど、もしもそれ無くせばもっと安く出来るわけか。すごいな。

但し、両方ともCele-Mの900MHzなんだな。どういうこと？

  • Ａｔｏｍの供給が追いついてないのか、それとも・・・
↑

こんどはＤｅｂｉａｎ（Ｅｔｃｈ ｉ３８６）をＶＭＷａｒｅ上にインストールしてみた。†

  • でも、jedのバグ
    • カーソルフォワード（＾Ｆ）を打つと、常に文書末にジャンプする。
  • は直っていなかった。orz
  • ちなみに、EtchをデフォルトインストールするとLANG=ja_JP.UTF-8になる。
  • この状態で emacs , jed , vi をデフォルトのまま起動してみたが、
  • UTF-8がまともに表示できるのはjedとviのみ。emacsはutf-8の日本語を正しく表示しない。
  • jedはカーソル右が発狂しているので、どのみち使えない。
  • ところで、lessはUTF-8をちゃんと表示できるようになっていた。（ARM版では出来なかった）

つまり、jedのカーソルバグは６４ビット固有問題ではなかったわけだ。

↑

ＵＴＦ−８の字化けについて、さらに調べてみた。†

  • Debian Lenny (amd64)では、UTF-8の扱いが少し改善されている。

Etch 32bit版の各種テキストエディタの振る舞い（デフォルト状態で）

  • 編集テキスト＝ＵＴＦ８文書
    LANGja_JP.EUC-JPja_JP.UTF-8
    Emacs -nw漢字を表示できない漢字を表示できない
    JedＵＴＦ８の漢字は<82><83>のようにおかしくなる表示はＯＫ、カーソル移動に問題あり（＾Ｆは文書末に行く）
    viＵＴＦ８の漢字は激しく字化けして読めない表示、カーソル移動共に問題なし

Lenny 64bit版の各種テキストエディタの振る舞い（デフォルト状態で）

  • 編集テキスト＝ＵＴＦ８文書
    LANGja_JP.EUC-JPja_JP.UTF-8
    Emacs -nw表示、カーソル移動共に問題なし表示、カーソル移動共に問題なし
    JedＵＴＦ８の漢字は<82><83>のようにおかしくなる表示、カーソル移動共に問題なし（＾Ｆは直っている）
    viＵＴＦ８の漢字は激しく字化けして読めない表示、カーソル移動共に問題なし
  • ちゃんと使うにはエディタ毎のいろいろなＴｉｐｓを覚えなければいけないんだろうけれど。
  • ＥＵＣへの切り替えはコマンドライン上で 
    $ export LANG=ja_JP.EUC-JP
  • とやって、teratermの漢字設定をEUCに切り替えるという方法で試したが、
  • 試し方が間違いなのか？（つまり、エディタ側の初期設定を何か変更する必要あり？？？）
↑

アメリカ大統領選挙の行方†

そんな冗談はさておき、気になっているのはやはり、アメリカの内線状態（ジョンタイターのいた時間線ではそうだ）と、女性大統領誕生のことだ。

  • 共和党と民主党が拮抗していないか？（ブッシュｖｓゴアの選挙のときがほんとうに僅差だった。あのときはゴアが引いたので収まったが）
  • マケインさんは高齢なので、もしかすると女性大統領ということになるのかもしれない。（量子的にどのくらいの確率？）
  • ジョン・タイターが述べた女性大統領という話は、最初はヒラリーか、ライスのことだとばかり思っていたが、今回は伏兵だな。（ヒラリーの線は消えた。ライスもおそらくないだろう）
  • とにかく、世界が各戦争により壊滅する未来を選択するのだけはなんとか回避してほしいと切に願う。
↑

やっぱり９月は暴落かよ†

  • 天変地異（地震）
  • テロ

量子力学的に起こりうる可能性があることはいつか必ず起こってしまうので怖い。

  • 特に地震は、一種のぜんまい仕掛けの時限爆弾だから。
  • 目下の注目点は９.１３前後とされている大地震だ。
  • テロは、まあ大規模なやつは起きないと思うけど・・・どうだろう。

＊米ソ冷戦再発の可能性、地政学的リスクが大きくなる可能性。

で、ロシアは冷戦なのか。

  • 今や協賛主義の国なんてなくなっちゃったので、イデオロギー対立で冷戦なんてありえない。
  • つまり冷戦を演じて、誰か得する奴がいるわけだな。（ロシアとかの裏で糸を引いている奴）
  • つ、武器商人？

最近の流行はロボ対ロボの戦闘になるらしい。

↑

エレキジャックＮｏ８（２００８．９．４発売）はなんとＡＴｔｉｎｙ２３１３を含むマイコンチップが付録に！†

http://www.eleki-jack.com/news/2008/09/no8_1.html

  • マジかよ。
  • 他にはＮＥＣ７８ＦとＨＣＳ０８（６８００系）とＴＩのＭＳＰ４３０もだ。
  • ほんとに今年は基板（電子部品付録）豊作年だ。
  • 来年が不作でなければ良いが。

ＡＴｔｉｎｙ２３１３のＤＩＰ品なら、まだ１０個くらい手持ちがあるから要らない。

  • 糞ＰＩＣが付いていなかったのはとても幸運だった。
  • ７８ＫとＨＣＳ０８は正直要らないなぁ・・・
  • というか、そんなマイコン、何に使うの？教えて！






おそらく、各マイコン用のＦｌａｓｈライターを作らなくちゃ始まらないので、

  • 自分の推理によると、Ｆｌａｓｈライターを作る練習キットなわけですな。
  • それか、各種ＩＣＥデバッガの販促用サンプルチップ詰め合わせ
↑

まだ雑誌を入手してないけど。†

  • ７８Ｋはおそらくトラ技８月号のＮＥＣ製Ｃコンパイラでコードを書けるだろう。
    • 焼き基板も付属しているとのことだ。
  • ＨＣＳ０８は、６８００にスタックポインタ相対アドレスを付加したようなマイコンだ。
  • ＭＳＰ４３０のほうも、１６ｋＢまでの無償コンパイラ（Ｅｃｌｉｐｓｅ３.２ベースらしい）が用意されている。

ふーん。

  • ７８Ｋは８０８５のそっくりさんで、ＨＣＳ０８は６８００にＳＰ相対を足しただけのマイコンなのに。
  • もうアセンブラで書かなくてもいいわけね。
    なんだか、つまんな〜い（マゾかよ。）
  • ７８Ｆ０５０３ＤＡはＦｌａｓｈ３２Ｋ、ＲＡＭ１Ｋ、Ｃｌｏｃｋ２０ＭＨｚらしいけど、これで合ってるのかな？
  • ＨＣＳ０８（ＭＣ９Ｓ０８ＱＧ８）のほうはＦｌａｓｈ８Ｋ、ＲＡＭ５１２Ｂ、２０ＭＨｚだ。
  • でも、６８００といえば、ＩＸが１本しかないわけで、memcpyすらまともに書けなかった（割り込み禁止でＳＰ使うのは無しよ）
  • しょぼいアーキテクチャーなので、Ｃのオブジェクトは目も当てられんものになるだろうことは容易に想像がつく。
  • なんやかんやいって、結局アセンブラ。
    • ゼロページ領域にmemcpyコードを展開しておいて
    • ポインタはＩＸしかないのでもう一つのポインタはＡＢＳアドレッシングのオペランドを直接インクリメントするのだ。
    • memcpyはそれで良いけど、それ以外の関数をいちいち命令書き換えで実装するのは絶対嫌や
  • ＭＳＰ４３０Ｆ２０１３は、７８ＫやＨＣＳ０８よりもはるかにまともなＲＩＳＣアーキだが、
  • Ｆｌａｓｈ２ｋ、ＲＡＭ１２８バイトとなっている。
  • ＡＴｔｉｎｙ２３１３とおんなじ容量かよ。
↑

結論として†

  • 自分にはどのマイコンも、１個１００円のＡＴｔｉｎｙ２３１３以下のように見える。
    • 反論したいなら、ＬｏｗＳｐｅｅｄでいいから、ＳｏｆｔｗａｒｅＵＳＢドライバーを書いて実証してくれ。
    • クロック数的に言うと７８Ｋはアウト。
    • レジスタ数的に言うとＨＣＳ０８もアウチ。
    • というか、どっちもＣコンパイラを使った瞬間に、ありえないコード量と遅さになるだろ。
    • ＭＳＰ４３０がギリギリ境界線だけど、２Ｋじゃあ厳しいねぇ・・・。
    • ドライバーだけで２Ｋ使い切るだろうなぁ。
↑

Ｄｅｂｉａｎ（Ｅｔｃｈ ｉ３８６）のＶＭイメージを作成してウハウハ。†

  • VMWare Toolsまで入れてしまうと、時計はちゃんと合わせてくれるし、カーソル離せばウィンドウフォーカスも自動で変わってくれるので、だいぶ楽。
  • Ｘ-Ｗｉｎｄｏｗのスクリーンサイズも、ＶＭＷａｒｅ窓のリサイズにあわせて自由に変わる。便利。

なのは良いけれど、一つ盲点があった。

  • ＶＭイメージを作ったときのマシンがＡｔｈｌｏｎ６４だったので、Ｐｅｎｔｉｕｍ４のマシンだと起動しねぇ！
    orz。


  • ｉ３８６汎用カーネルに差し替えたｖｍｌｉｎｕｚを入れてｇｒｕｂで選択するしかない。
↑

ＤＥＬＬのミニノート：Inspiron mini 9発表†

http://pc.watch.impress.co.jp/docs/2008/0905/dell1.htm

  • 英語キーボード、キター
  • あともう半年もすれば、ＳＳＤはＨＤＤに比べて圧倒的に速く快適になるはずだ。
  • ＳＡＴＡ２インターフェースで良いので、ＳＳＤを抜き差し可能なスロットに入れて欲しいような気がする。（昔のＮＥＣ９８ノートのＨＤＤみたいな感じで）
  • そうすると、Ｕｂｕｎｔｕの６４ビット版にしたりＸＰに戻したりが楽だ。
  • ＶＭＷａｒｅでも良いんだけれど、ＳＳＤの容量的に両方のＯＳを入れるのは（現時点では）無理。
  • 今のＳＤメモリーカードみたいなフラッシュメモリーインターフェースがＳＡＴＡ並みに速くなるのであれば、ＳＤカードスロットだけ用意して、ＳＳＤレスであっても良いくらいだ。
  • 実際には、そうなることは難しい。なぜならインテルの高速ＳＳＤはインテリジェントな並列コントローラと、複数のＦｌａｓｈモジュールの組み合わせでやっと実現しているからだ。

それから、どうでもいいけどＡｔｏｍの液晶サイズ縛りなんか意味ないんでやめて欲しい。

  • 図書館とかパブリックスペースに置かれるＰＣなんか、全部Ａｔｏｍにしてしまってもいいくらいだ。
  • ついでに９４５の後継（低消費電力化）は絶対必要。
  • mini 9のチップセットはDELLの英語サイトのTech Specsには、965PM/GM Express(GMA950)と書かれていたが、 これって945GMの間違いではないんだろうか？965だとGMA3000になるが、さらに爆熱だ
↑

７８Ｋのアセンブラって存在するの？†

http://john.ccac.rwth-aachen.de:8000/as/

  • 探していたら、こんなサイトに辿り着いた。
  • これって１本のアセンブラでアンティークな全ＣＰＵを網羅しているよね。
  • ＳＣ/ＭＰがあった。感激した。
  • ソースの拡張子はＣなんだけど、最初見たらＰａｓｃａｌかと思った。

http://john.ccac.rwth-aachen.de:8000/alf/

  • ドイツの人らしいです。

とある２ｃｈの会話より

15 ：774ワット発電中さん：05/02/18 16:29:21 ID:K0GntvF8
>>14 
78KのPIC/AVRと比較しての優位点ってなんかある？ 
16 ：774ワット発電中さん：05/02/18 17:20:51 ID:Jb4jtAy/
・PIC/AVRほど語り尽くされていないから面白みがある 
・PICのような変態アーキテクチャではないから気分的に楽 
・レジスタ構成が懐かしい〜A/B/C/D/E/H/L・・・あれ？ 
・ドライバコンフィギュレータ（Applilet：Applilet EZとは別物）が 
　初期化やらライブラリのソースコードを自動生成してくれるのが便利 
・外部発振器不要 
・全品種にA/Dコンバータ内蔵 
・NEC純正Cコンパイラ無料 
・LEDやスイッチ、ボリュームなどを付けたイメージで 
　動作シミュレーションできるシミュレータ（無償） 
http://www.necel.com/micro/product/sc/lowpin/

わろた。

↑

ＤＥＬＬのミニノート：Inspiron mini 9†

  • ファンレスらしい。
  • ＥｅｅＰＣの爆熱っぷりを見ているので、低音やけどとか大丈夫？
  • なんか秘策があるのかな？

とりあえず

  • 英語キーが選べる。
  • ファンレス
    ここまではＯＫ。大変結構。でも
  • 発熱具合ってどうなの？
  • カラーバリエーションはどうなったの？
    • 英語モデルでは白のほうが高いんだけど・・・
  • 電池の持ちが期待したより普通。

インテルのＳＳＤ搭載モデルまで待つか・・・

  • DELLの日本語サイトに仕様詳細が出ていた。
  • チップセットは945GSE Expressとなっている。
  • ちなみに、Atomのチップセットはintelサイトによると
    ネットブックモバイル インテル 945GSE Express チップセット
    ネットトップインテル 945GC Express チップセット
    ということになっている。
↑

エレキジャックＮｏ８を買ってしまった。†

  • ７８Ｋ、ＭＳＰ４３０、ＨＣＳ０８、ＡＶＲとマイコンてんこ盛り
  • だけど作るものがない。
  • しかたがない、ライターでも作るか。

とある２ｃｈの会話より。

40 名前：774ワット発電中さん 投稿日：2008/06/10(火) 00:33:42 ID:epyTo3qj
PIC/AVRを始めることにした。まずはライタを作らないと。 

ライタ作った。さて、何を作ろうか。 

…作りたいモノがない!! しかし、何か作らねば…。 

そうだ、新しいライタを作ろう。

↑丁度今ココ。

  • ちなみに、７８Ｋはシリアル経由でＷｒｉｔｅＥＺ３というツールから書き込み出来るらしい。
  • ＨＣＳ０８を焼いたりデバッグしたりするツールＵＳＢＳＰＩＤＥＲは４２００円くらいで売っている。
  • ＭＳＰ４３０を焼いたりデバッグしたりするツールｅｚ４３０−Ｆ２０１３は３５００円で売っている。
  • ＡＶＲはＣＨａＮさんのシリアルライターで簡単に焼けると思う。（制作済）

わざわざＵＳＢＳＰＩＤＥＲとかを買うまでもないし、買ってもたぶん（ＨＣＳ０８の）使い道がないわけで。

  • やっぱり他のマイコンでＨＣＳ０８かＭＳＰ４３０焼き器を作るまでが遠足だな。
  • 出来てしまったらすることが無くなる。
  • で、出来上がったＨＣＳ０８でＡＶＲライターを書くとか・・・（人生無限ループだ）
↑

ＤＥＬＬのミニノート：Inspiron mini 9 の別の可能性†

  • Ｌｉｎｕｘ（Ｕｂｕｎｔｕ）搭載を前面に出したノートＰＣって、他にあったっけ？
  • これは、市場実験（ユーザーアンケート）のようなもので、
  • モバイルデバイスに必ずしもＷｉｎｄｏｗｓが必要かどうかをユーザーに問うている。

Ｕｂｕｎｔｕでも十分に利用できると分かった時点でどうなるか予想してみよう。

  • Ａｔｏｍいらないじゃん。ｎＶｉｄｉａのＴｅｇｒａ（ＡＲＭとＧＰＵ統合チップ）でもＵｂｕｎｔｕくらいは走る。（ちょっと遅いかもね）
  • だったら、バッテリーの持ちは劇的に伸びるし、爆熱の心配もない。
  • もっと安く出来る。
  • ＷｉｎｄｏｗｓＸＰの供給も止まるので、好都合。
  • 今後糞Ｖｉｓｔａに移行するくらいならＵｂｕｎｔｕのほうが好いよね。

逆に、Ｕｂｕｎｔｕモデルが受け入れられない場合は、Ｔｅｇｒａの線は無しってことで。

↑

Intel、10chアクセスで高速化したSSDを出荷開始†

http://pc.watch.impress.co.jp/docs/2008/0909/intel1.htm
http://japanese.engadget.com/2008/09/09/ssd-x25-m-80gb-595/

  • ８０ＧＢ。千個受注時の単価は65,760円。 
    　主な仕様はほぼ共通で、容量が80GB、インターフェイスはSATA(3Gbps)、
サステインドリードが最大250MB/sec、サステインドライトが最大70MB/sec、
リードレイテンシは85μsec。消費電力はアクティブ時が0.15W、アイドル時が0.06W。
  • 速っ。（まあ、メモリーだからな。）
  • ＮｅｔＢｏｏｋ１台分より高いじゃん。
  • こいつはむしろ、エンタープライズサーバー用だな。
  • Ｏｒａｃｌｅとか動かしている所は、喉から手が出るほど欲しかった速度だろう。
  • ＨＤＤなら、１秒にせいぜい７０回くらいしかランダムリード出来ないが、（秒速高々１２０回転なので）
  • ＳＳＤは、何千回でもＯＫだから。

フラッシュがＭＬＣでこの値段なので、ＳＬＣだと倍額くらい？

  • １６０ＧＢだと、ＶＡＩＯノートが１台買えますな。
↑

ＡＲＭ吼える†

http://pc.watch.impress.co.jp/docs/2008/0910/arm.htm

  • ARM、IntelによるAtom優位の主張に強く反論
  • そりゃまあ、２次キャッシュＯＦＦで計測されたら怒るのも当然だよな。
  • ＡｔｏｍもＡＲＭもシングルスカラーならば同一クロックでほぼ同速度じゃあないかとは思っていた。
    • ＣｏｒｔｅｘＡ８はin-order実行の２イシューなのでＣｌａｓｓｉｃＰｅｎｔｉｕｍ相当だ。
    • まあＡｔｏｍともよく似ていること。
    • レジスタ数の多さで言うとＡＲＭのほうが速いと思うが、ＳＳＥ周りはインテルのほうが何枚も上手だ。
    • ＨｙｐｅｒＴｈｒｅａｄｉｎｇの有無の違いはある。（つまりＨＴ　ＯＮの状態ではＡｔｏｍ有利）
  • 記事によると７６８ＭＨｚのＣｏｒｔｅｘＡ８は１.６ＧのＡｔｏｍより２５％遅いらしい。（まあ用途によるだろうけど）
  • 一番いいのは市場がすべてを決めることだ。
  • まず、ＡｔｏｍはＩＰコアで提供されることはありえないので、今のＡｔｏｍがＡＲＭ市場に殴りこむことは不可能。
  • そのまえにチップセットをなんとかしる。＞インテル
  • 繰り返すようだが、Ａｔｏｍの市場はＷｉｎｄｏｗｓＸＰ搭載のＮｅｔＢｏｏｋ限定なのだから、Ｕｂｕｎｔｕで十分な用途向けにはどんどんＡＲＭ内蔵のＮｅｔＢｏｏｋを作ればよいだけだ。
  • それが市場に受け入れられなかったなら（Ｘ８６互換の）Ａｔｏｍが自動的に勝つ。
↑

ＨＩＤａｓｐ高速化の可能性†

ＨＩＤａｓｐ高速化

↑

インドの少女、欧州での「ビッグバン実験」を恐れ自殺†

LHCで極小ブラックホール生成実験を行っても地球は消滅しない、CERN

そもそもＬＨＣでブラックホールが作れるなんていう「世間の注目を集める」ニュースを流すのが間違いだったのか。

  • 基本的にはＨｉｇｇｓを見つけるための実験施設なのだ。
  • 注目を集めて予算獲得しやすくする効果もあると思うけれど、物理学に詳しくない人たちを無意味に不安がらせるような宣伝もどうかと思う。
  • 深読みすると、それを知ったインドの天才少女が、本当に事故が起きる可能性を計算した結果自殺、だったら凄いけれど。
  • あとね。ＣＥＲＮの施設の写真は、まるで波動砲の発射装置みたいで怖い感じがするんだけどね。たいていあの手の大げさな機器は（生成した素粒子の軌跡や熱量を測る）検出器なんだよね。
  • だから、怖くはないんだぉ。

面白いところでは、こんなニュースもあるし。

↑

ＤｉｒｅｃｔＸでプログラムを書いてみようかと。†

気の迷いからだが。
で、

  • いや、普通にＯｐｅｎＧＬで書くようなことをＤｉｒｅｃｔＸで書くことが出来ないかという。
  • そうすると、Ｃ＋＋とかクラスとか難しいことを覚えなくて良いので。
  • 別にクラスを使うことは難しくないが、たとえば、Ｘファイルの読み込みが 
    D3DXLoadMeshFromX("hoge.x" ...)
    で、描画が 
    for(...)
 pMesh->DrawSubset( i );
  • だなんて言われた日には、まるで「おまえら何も分からんでいいからＶｉｓｕａｌＢａｓｉｃでも使ってろ」と言われているのと同じだ。

じゃあ、自力でＸファイルを読んで、DrawPrimitive()してみろと。

  • というわけでＸファイルの解析を始めたわけだが、
  • なんかだめだめフォーマットなんだなこれが。
  • 特にＸバイナリーなんて、元のテキストをトークン番号に置換しただけのテキスト並びのまんまじゃないか。
  • しかもＤｉｒｅｃｔＸ１０ではＸファイルが扱えなくなっているというし。

すなおにＯｐｅｎＧＬで書いたほうがマシなのはわかっている（つもり）

↑

いろいろ検索していたら２ｃｈに当たってしまった。†

Xファイルを再生するスレ

  • 何に困っているかというと、３Ｄモデルの適当なフォーマットが「存在しない」ことなのだ。
  • モデリングソフト毎に独自のフォーマットが存在するが、それは(面倒なので)扱いきれない。
  • 割とポピュラーなフォーマットとしては
    • DXF(AutoCAD)
    • 3DS(AutoDesk 3D Studio)
    • obj(WaveFront)
    • FBX(AutoDesk)
    • Collada(SCEA)
    • VRML / X3D (Web3D)
    • Xfile / SDKMesh (DirectX)
  • 特定のモデラーを持っているならそれに近いものを使えば良いが、
  • どのモデラーでもサポートされていそうなフォーマットというとかなり限定される。

で、

  • ＸファイルはDirectXで最も知られたフォーマットなので、対応モデラーは多くて良いのだが、
  • 書けるくせに（Ｘファイルを）読めないモデラーが多いのがまた、困り者だ。
  • そのくせ、（Ｘファイル以外での）適当な共通フォーマットがないんだな。
↑

ＨＩＤデバイスのアクセス方法について誤解していた。†

  • また恥をかいてしまった。
  • ＨＩＤデバイスというのは、単にディスクリプタのテーブルが拡張されただけのものかと思っていた。
  • ところがReadFile()やWriteFile()で転送されるのは、生パケットではなく、レポートディスクリプタというやつらしい。
  • 転送サイズは９を指定するのだが、その９バイトバッファの先頭の１バイトはREPORT_IDに割り当てられていて、しかも０ｘ００固定だ。
  • 実際に転送されているパケットは９バイトのうちの後ろ８バイトのようだ。
  • これを長くすることが出来ないと、帯域を稼ぐこともできないっぽい・・・。
  • なんかlibusbと全然違うんだな。
  • HID.DLLにはベンダー独自リクエストを直接送信するような呼び出しはないのかな？
  • ReadFile() WriteFile()はブロックされるので、個別に制御するなら別スレッドにするという話だが、
  • HIDというかUSBのパケットなのに、なんでもReadFile()関数に押し付けるのは強引だと思った。

参考ＵＲＬはこのへん？
すｚのAVR研究

Obtaining HID Reports / HidD_GetFeature

↑

avrspxがWindows2000上でHIDaspを認識してくれない件†

  • avrspxのhidasp_init()内でハングすることが多い。
  • testパケット（pingのようなエコーバックパケット）を４回送り、受信を行っているが、
  • Windows2000上では、２つくらいしか返却されてこない。
  • １回送り、１回受け取るように書くとOK.
    • これはsenshuさんのHIDspx.exeの実装で修正されている。
  • WindowsXP上で同じことをすると、４パケットのうちの最初のパケットだけが欠落する。
    • 但しこの現象はHIDaspをUSBに接続した直後だけに発生する。
    • SnoopyProでデバイスリセットを行った直後にも良く発生することが多い。
  • Windows2000, WindowsXPの両方でSnoopyProを見ながらやってみたのだが、原因を掴むには至っていない。
  • やりにくいのはHID Reportの送受信がReadFile() WriteFile()という Windowsのブロック関数でやらなければならない点だ。
  • これは、rs232cの簡易ターミナルを書いたときも相当いらついた。
    • 非同期リード、ライトにしたければ、CreateFileでFILE_FLAG_OVERLAPモードオープンして、
    • ReadFileの最後の引数にOVERLAPPED構造体を与えてやるとかしないといけない。
  • あと、HID Reportがどのようなパケットなのか本質を理解していないのが問題。
    • マウスならボタン情報、座標などが含まれるようなパケットらしい。
  • SnoopyProで見るとインタラプト転送のように見える。
  • Microsoftのドキュメントではコントロール転送でもいけるというふうな解説が書かれているので混乱している。
  • もしも（ＬｏｗＳｐｅｅｄ）インタラプト転送なら、速度を望むことは絶望的だ。
↑

HIDsphを研究しておくべきだった。†

  • ソースがかなり洗練されている。
  • AVRUSBのAVR Bootloader HID がベースになっているようだ。
  • HID Reportの送受には ReadFile()/WriteFile()ではなく HidD_GetFeature()/HidD_SetFeature()で行われている。
  • やっぱりAVRUSBで紹介されているリファレンス実装は一通り見ておくべきだと思った。どれもレベルが高い。
  • ATmega88は秋月で＠250円なので、もう2313にこだわらなくてもいいかなと。
↑

HIDsphを実際に焼いてみた。†

HIDspxのHidD_SetFeature()改造版を作ってみたもののHidD_SetFeature()が常に失敗するので、 比較対象が欲しかった。

  • テスト基板が普通のAVR-USB接続だったので、PortD,4,3の設定をPortD,3,2に変更。
  • INT1になっていたのでINT0に変更。
  • ATmega8だったのでATtiny2313に。そしてbootloaderのスタートが1800だったのを0に。
  • 同梱exeを使って接続のみ確認。

次にHIDspx-srcのソースのReadFile()/WriteFile()をHidD_GetFeatur()/HidD_SetFeature() に置換したソースで接続を確認。

  • WindowsXPで正しくハンドシェイクされている。
  • USB挿抜直後でも正しくハンドシェイクされていることを確認。

SnoopyProで見ると、HIDaspターゲットに対する挙動とかなり違う。

  • HIDaspターゲットでは、インタラプト転送のような挙動でデバイスから勝手に送られてくる感じ。
  • HIDsphターゲットでは、すべてコントロール転送（クラスリクエスト）になっている。

HIDディスクリプタの内容が双方でかなり違うのでこうなるのだろうか・・・

  • Report IDは1,2以外はダメ。
  • サイズはGetDevCaps()で取得できないのであとで代入しているがその値は7以上でないとダメ。 
    PROGMEM char usbHidReportDescriptor[42] = {
   0x06, 0x00, 0xff,              // USAGE_PAGE (Generic Desktop)
   0x09, 0x01,                    // USAGE (Vendor Usage 1)
   0xa1, 0x01,                    // COLLECTION (Application)
   0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
   0x26, 0xff, 0x00,              //   LOGICAL_MAXIMUM (255)
   0x75, 0x08,                    //   REPORT_SIZE (8)
   0x85, 0x01,                    //   REPORT_ID (1)
   0x95,    6,                    //   REPORT_COUNT (6)
   0x09, 0x00,                    //   USAGE (Undefined)
   0xb2, 0x02, 0x01,              //   FEATURE (Data,Var,Abs,Buf)
   0x85, 0x02,                    //   REPORT_ID (2)
   0x95,    7,                    //   REPORT_COUNT (7)
   0x09, 0x00,                    //   USAGE (Undefined)
   0xb2, 0x02, 0x01,              //   FEATURE (Data,Var,Abs,Buf)
   0x85, 0x03,                    //   REPORT_ID (3)
   0x95,   38,                    //   REPORT_COUNT (38)
   0x09, 0x00,                    //   USAGE (Undefined)
   0xb2, 0x02, 0x01,              //   FEATURE (Data,Var,Abs,Buf)
   0xc0                           // END_COLLECTION
};
  • Report IDの2,3の使い道が良く分からない。
  • 2,3を削除すると無反応になる。
    • （#define USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH 42　は書き換えたつもり）
↑

ＨＩＤａｓｐ高速化†

ここ２日くらい、いろいろ試行錯誤してみた。

  • ＨＩＤ　Ｒｅｐｏｒｔの送り方と受け取り方が分かった。
  • 全てコントロール転送（クラスリクエスト）で実行されているような気がする。
  • ただし、まだよくわかっていないのが、Ｒｅｐｏｒｔ　ＩＤの置き場所についてだ。
    • コントロール転送のDOWNストリームデータ（つまり後続パケット）の先頭にあるのか、
    • それとも、クラスリクエスト内にあるのかが掴みきれていない。
    • デバイスからホストへのＵＰストリームにおいては間違いなく後続パケットの先頭バイトだと思う。
  • それから、ディスクリプタに書かれたＲＥＰＯＲＴ＿ＣＯＵＮＴの値と、ＵＳＢの生パケットのサイズの対応も正しく把握しきれていない。あやふやなのだ。
    • まあ、動いているからいいや、では駄目だ。
  • ＨＩＤはドライバーインストールが不要なので、ユーザーに勧めやすい。
  • オーバヘッドが多少増えるが、libusbでコントロール転送の生パケットをコーディングするよりもある意味楽かもしれない。
  • ふつうのＨＩＤクラス（ＫＢ、マウス、ＪＯＹ等）を書いてみようという気になったのも収穫の一つ。

ATtiny2313の２ｋＢ内でも、思ったよりいろいろ詰め込めそうだ。

↑

ＡＴｔｉｎｙ２３１３のＵＳＩ（ＳＰＩ）†

  • ＡＴＭＥＬのＰＤＦを読む。 
    ｱｾﾝﾌﾞﾘ言語ﾌﾟﾛｸﾞﾗﾑ例
SPIM: OUT USIDR,R16 ;送信ﾃﾞｰﾀを設定
 LDI R16,(1<<USIOIF) ;USIOIFﾋﾞｯﾄのみ1値を取得
 OUT USISR,R16? ;ﾌﾗｸﾞ解除/ｶｳﾝﾀ初期化
 LDI R16,(1<<USIWM0)|(1<<USICS1)|(1<<USICLK)|(1<<USITC) ;3線動作ｸﾛｯｸ生成値を取得
;
SPIM_LP: OUT  USICR,R16  ;SCKｸﾛｯｸ ｴｯｼﾞ発生
 SBIS USISR,USIOIF ;ｵｰﾊﾞｰﾌﾛｰでｽｷｯﾌﾟ
 RJMP SPIM_LP ;ｵｰﾊﾞｰﾌﾛｰまで継続
;
 IN R16,USIDR ;受信ﾃﾞｰﾀを取得
 RET ;呼び出し元へ復帰

2行目と3行目の命令はｶｳﾝﾀ ｵｰﾊﾞｰﾌﾛｰ割り込み要求ﾌﾗｸﾞ(USIOIF)をｸﾘｱ(0)し、USI 4ﾋﾞｯﾄ ｶｳﾝﾀ値をｸﾘｱ(=0)します。 4行目と6行目 の 命令は3線動作、立ち上りｴｯｼﾞ ｼﾌﾄ ﾚｼﾞｽﾀ ｸﾛｯｸ、USITCｽﾄﾛｰﾌﾞ計数、SCK出力交互切り替え(PORTB7)を設定 し ます。このﾙｰﾌ は16回繰り返されます。

次のｺｰﾄﾞは最高速(fclk/2)でのSPIﾏｽﾀとしてのUSI部使用法を実際に示します。
ｱｾﾝﾌﾞﾘ言語ﾌﾟﾛｸﾞﾗﾑ例
SPIM_F:? OUT? USIDR,R16? ;送信ﾃﾞｰﾀを設定
? LDI? R16,(1<<USIWM0)|(0<<USICS0)|(1<<USITC)? ;3線動作初期値を取得
? LDI? R17,(1<<USIWM0)|(0<<USICS0)|(1<<USITC)|(1<<USICLK)? ;3線動作ｸﾛｯｸ生成値を取得
;
? OUT? USICR,R16? ;MSB転送
? OUT? USICR,R17? ;
? OUT? USICR,R16? ;ﾋﾞｯﾄ6転送
? OUT? USICR,R17? ;
? OUT? USICR,R16? ;ﾋﾞｯﾄ5転送
? OUT? USICR,R17? ;
? OUT? USICR,R16? ;ﾋﾞｯﾄ4転送
? OUT? USICR,R17? ;
? OUT? USICR,R16? ;ﾋﾞｯﾄ3転送
? OUT? USICR,R17? ;
? OUT? USICR,R16? ;ﾋﾞｯﾄ2転送
? OUT? USICR,R17? ;
? OUT? USICR,R16? ;ﾋﾞｯﾄ1転送
? OUT? USICR,R17? ;
? OUT? USICR,R16? ;LSB転送
? OUT? USICR,R17? ;
;
? IN? R16,USIDR? ;受信ﾃﾞｰﾀを取得
? RET? ? ;呼び出し元へ復帰
  • なるほど。usi_trans()は、８ビットの転送に１６回ループを回るのだ。
  • しかも１バイトの書き込みにはusi_trans()を４回呼ばなければならない。
    • （シリアルプログラミングのＳＰＩコマンドはすべて４バイト単位）
  • ＡＶＲ書き込み時に与えるＳＣＫのＬＯＷ区間、ＨＩＧＨ区間はＣＰＵ　ＣＬＯＣＫの３クロック時間より長くなければならない（１２ＭＨｚ以上動作のとき）
  • これを満たすためには、（仮にＬＯＷ＝４ＣＬＫ、ＨＩＧＨ＝４ＣＬＫとすると）１２ＭＨｚのＡＶＲを焼くためにはＳＣＫは１.５ＭＨｚ以下でないとだめという感じかな。
  • ということは、上記のループ展開したようなＳＰＩ転送だと６ＭＨｚになるので速すぎる。
  • delay()を外した状態のusi_trans()のｇｃｃコードが丁度上記の最初のコード例になるので、 １２ＭＨｚのＡＶＲを焼く場合の限界速ということになりそうだ。
  • この頃はＡＴｍｅｇａ８８の２０ＭＨｚ基板を焼いているので、なんとか間に合っているようだ。
    • 焼いているというのが、単に焼き速度のベンチマークをしているだけ、というところがむなしいけど。
↑

ＵＳＢの接続変更†

  • ＵＳＢのＤ＋をＰＤ３
  • ＵＳＢのＤ−をＰＤ４
  • に接続するのが流行りらしい。
  • とりあえず、ターゲットボードの配線だけは変えた。
  • usbdrv/を最新と取り替えて、usbconfig.hもＰＤ３，４に合わせた。
  • しかし、コードサイズがあっというまに１００バイト以上溢れ返ってしまった。


何故？
わっかりーませーーん。降参です。

↑

はっはっはっ分かってしまえば簡単だ。†

#define USB_CFG_HAVE_INTRIN_ENDPOINT    1

こいつが１になっていただけだった。これで１００バイトくらい増える。

  • どうやって調べたかって？そりゃ、双方のdisasmを比較したのさっ。 
    avr-objcopy -j .text -j .data -O ihex main.elf main.hex
bash checksize main.elf 2048 128
ROM: 1956 bytes (data=4)
RAM: 93 bytes
  • ↑今ここ。
  • これで、流行に乗り遅れないぞっと。

ちなみに、ＨＩＤ　Ｒｅｐｏｒｔの取得や書き込みは全てコントロール転送で完結しているっぽいので （ＳｎｏｏｐｙＰｒｏで見ただけだけど）クソ遅いインタラプト転送なんて、使わないぞっと。

↑

ＨＩＤａｓｐ高速化改良（方法論のみ）†

  • ＨＩＤｓｐｘ−ｓｒｃに含まれているhidasp.c には、ＨＩＤ　Ｒｅｐｏｒｔのパケットをダンプするデバッグ機能がついている。 
    #define PKTDUMP 0	    // HID Reportパケットをダンプする.
    これを 1 にして作成したＥＸＥで書き込み＆ベリファイを行うと、どのようなＨＩＤパケットが飛び交ったかがコンソールに表示される。
  • 次に、これをＯＦＦにしておいて、ＳｎｏｏｐｙＰｒｏでＵＳＢパケットをキャプチャーする。
  • HIDspx.exeで同じように書き込み＆ベリファイを行ってみる。
  • ＳｎｏｏｐｙＰｒｏのログにはそのパケットが送られた時間が記録される。１ｍＳが１フレームと考える。
  • そして、ａｖｒｓｐｘのソースを見ながら、どのようなことが起こっているのかを想像すればよい。

速くしようと思えば、無駄なパケットを減らすことと、ＨＩＤ　Ｒｅｐｏｒｔを６４バイトにまで拡張することと、usbFunctionWrite()に８バイト来た時点で行動を起こすことだ。

  • usbFunctionWrite()では、８バイト単位で処理を行い、ＳＰＩ経由でデータを送ってしまうことが出来るので、ＲｅｐｏｒｔＢｕｆは長く取る必要がない。最初に来た８バイトのヘッダー部分だけ覚えておけばいいはずだ。
  • アドレスセットとページライト、書き込みまでをその長いパケットに全部含めてしまえばさらに無駄は減るが、ちょっとやりすぎかもしれない。
  • また、読み込みも速くしたければ、ページリードのコマンドは省略してしまい、長いＨＩＤ　Ｒｅｐｏｒｔの要求が来たら、さっさと固定長でページリードを行なってしまえばよい。端数に関してだけ、従来どおりページリードコマンドでサイズを指定して転送してもらうようにする。
  • これも８バイト単位で並列処理させると良いかもしれない。
  • ページリード以外のコマンドは結果が７バイトで足りるので、長いＲｅｐｏｒｔ要求を出すことはないはず。

書き込みターゲットのクロックが遅い場合はどのみち速くすることは出来ないので、高速化の対象は８ＭＨｚ以上で動作しているＡＶＲチップに限定すれば、上記のような戦略が有効だと思う。

  • しかし、上記の手法はやややりすぎの感もある。
  • 手持ちのｍｅｇａ８８に５秒程度で書き込み＆ベリファイが出来るのならそれで充分だし
  • ｔｉｎｙ２３１３に書いていた頃は、昔のままでも遅いと思ったことはなかったのだから。
↑

パソコン起動不可-＞復旧完了。†

  • 今朝からパソコンが起動しなくなった。
  • 立ち上げるといきなりリセット。
  • もう１回たちあげて、１分くらい作業したらまた勝手にリセット。
  • ついに立ち上がらなくなった。メッセージは 
    C:\WINDOWS\SYSTEM32\CONFIG\SYSTEMが壊れているか読めません。
インストールＣＤを入れて立ち上げてＲを押してください。
    みたいなやつ。
  • 最初はメモリーを疑った。ＭＥＭＴＥＳＴ８６に掛けたが７周しても問題なし。
  • 次にＨＤＤを疑った。幸い容量ＵＰの交換前ＨＤＤが残っていたのでそちらで立ち上げて ＣＨＫＤＩＳＫは無問題。
  • やっぱりCONFIG/SYSTEMの問題かと思って、正常起動するほうのSYSTEM（システムレジストリファイル） を上書きしてみたら、こんどは起動するがログイン画面に来ない。
  • はたと思いついて、Windows/repair/SYSTEM という、インストール直後に作成されるシステムレジストリファイルのバックアップを上書きしてみると、幸運にもＯＳが起動するようになった。
  • 但し、起動直後は、まるでインストール直後のような、ドライバー初期状態だったので、適当にドライバーを入れて対処。
  • ユーザーレジストリは無事だったようだ。完全に復旧。

一件落着。

  • Ｗｉｎｄｏｗｓ９８時代は、このようなトラブルが日常だったので、Ｃ：ドライブにはＯＳのみを入れるという癖がついている。
  • さらに、ＯＳのパーティションを３つ同じ容量で切って、Ｗｉｎｄｏｗｓ９８の安定した状態のＣ：のコピーを３個持って運用していた。
  • ブート切り替えはＣｈａＮさん作のＭＢＭというブートローダーだ。
  • これはパーティションの細かな設定やパーティションコピー、ドライブ間コピーなどができる頼もしい奴。
  • もっとも、今ではそのような用途に特化したＬｉｖｅＣＤ Ｌｉｎｕｘがいくつか存在するようだ。

こういうことが年に１回くらいはあるので、ＯＳの起動パーティションは常に３つ切っていて、レスキュー用の仮ＯＳはいつでもインストール可能状態にしている。

  • （もちろんＫｎｏｐｐｉｘとかでも最近はＮＴＦＳをマウントして書き込みまで出来るのだが、壊れたＷｉｎｄｏｗｓの障害状況を見たり、ファイルを比較したりといったことまでやるなら、そっくり同じＯＳを別パーティションに入れるにこしたことはない。）
↑

ＨＩＤａｓｐ：時には諦めも肝心？†

  • 例のusbFunctionRead()に引っ掛けて８バイトづつちまちま転送したらどうなるかテスト.
  • ＨＩＤ　Ｒｅｐｏｒｔ長はついに１２６バイト。（ＳｎｏｏｐｙＰｒｏで確認したから間違いない） 
    bash-2.02$ time ./hidspx.exe -rp >1
Detected device is ATmega88.
Read    Flash: 8192/8192 B
Passed.

real    0m1.712s
user    0m0.015s
sys     0m0.000s
  • ８ｋＢ全読みはＳＰＩ転送を端折ると0.8秒で終わる（ＵＳＢ転送だけだ。つまり１０ｋＢ／Ｓはちゃんと出ている）
  • delay()ループを削除した状態で、上記1.7秒。
  • delayループを入れて'-d0'では2.4秒。（つまり、８バイト単位でインターリーブしたほうが却って遅いという不本意な結果）
  • とするとspi_trans()が入るだけで（ホストから見て）１フレーム後回しにされる遅延になる。
  • spi_trans()がやや遅いと２フレーム後回しにされる遅延になる。
  • ここらへんがソフト処理ＵＳＢの限界だ。
  • プロトコルエンジンが後付けになっているようなＰＩＣ１８Ｆ２５５０とかＮＥＣ７８ＫではＵＳＢ転送はバックグラウンド的に実行されて共有ＲＡＭにパケットが残る仕組みなので、かなわない。
  • というかＬｏｗＳｐｅｅｄの限界を見たような気もする。
  • いろいろ考えたが解法は無い。ＳＰＩクロックをタイマー０から与えるようにしてクロックを上げる（？）
  • 現状１２ＭＨｚ/４Ｃｙｃｌｅ/２（２回叩いて１ＳＣＬ）＝１.５ＭＨｚのＳＰＩクロックなので、これを２ＭＨｚ（８ＭＨｚＣＰＵ焼きの上限いっぱい）まで上げれば・・・たいして変わらない？
  • ここまで来るとパズルだな。ＳＰＩ転送を割り込み駆動にしてバックグラウンド処理すれば良さそうに見えるけど、実はusbFunctionRead()は遅延実行できない関数なので、やるなら１パケット先読みで先回りするしかないだろう。書くほうは先読みの必要はないし（データが来るまで）出来ないから遅延実行するようにして即時復帰だ。
  • そういった処理を書きたいならｍｅｇａ８８を使うしかない。Ｒｅａｄのインターリーブを実装しただけで２ｋＢを使い尽くしてLED,MONITORを外すことまでやった。

と、まあいろいろ考えたけれどここらが２ｋの限界点だ。

↑

Ｗｒｉｔｅ＆Ｖｅｒｉｆｙ：４秒切りました。†

bash-2.02$ time ./hidspx.exe -rp >a.hex
Detected device is ATmega88.
Read    Flash: 8192/8192 B
Passed. 
real    0m1.672s
user    0m0.015s
sys     0m0.000s
bash-2.02$ time ./hidspx.exe a.hex
Detected device is ATmega88.
Erase Flash memory.
Write   Flash: 8192/8192 B
Verify  Flash: 8192/8192 B
Passed.

real    0m3.939s
user    0m0.015s
sys     0m0.000s
  • 例のusi_transの最適化 
    static uint8_t usi_trans(uint8_t data){
	USIDR=data;
	USISR=(1<<USIOIF);
	if(wait==0) {
		uchar CR0=(1<<USIWM0)|(1<<USICS1)|(1<<USITC);
		USICR=CR0;
		uchar CR1=(1<<USIWM0)|(1<<USICS1)|(1<<USITC)|(1<<USICLK);
						USICR=CR1;	asm("nop");
		USICR=CR0;	asm("nop");	USICR=CR1;	asm("nop");
		USICR=CR0;	asm("nop");	USICR=CR1;	asm("nop");
		USICR=CR0;	asm("nop");	USICR=CR1;	asm("nop");
		USICR=CR0;	asm("nop");	USICR=CR1;	asm("nop");
		USICR=CR0;	asm("nop");	USICR=CR1;	asm("nop");
		USICR=CR0;	asm("nop");	USICR=CR1;	asm("nop");
		USICR=CR0;	asm("nop");	USICR=CR1;
	}else{
		do{
			delay(wait);
			USICR=(1<<USIWM0)|(1<<USICS1)|(1<<USICLK)|(1<<USITC);
		} while(!(USISR&(1<<USIOIF)));
	}
	return USIDR;
}
  • と、いろいろデバッグのために入れていたSleep全部取っ払いで、こんな感じです。
  • 変な(?)モニターコマンドとＬＥＤコマンドの両方を入れると、コードが２バイト溢れます。
    • 配線をＩＮＴ０に戻せば２０４８といった感じですが、変なモニターのほうは需要がなさそう なので、外しておきます。
  • d0は最速なのでよいとして、d1〜d5とd6以降の件は、ホスト側のhidasp.cにテーブルを持たせますかね。

REPORT_ID=6(46)は、現在使用していない（バッファが４０バイトしか確保していない）ので削除すると ９バイト空きます。

↑

ＵＳＢａｓｐの実装を見てみることにした。†

  • ＡＴｔｉｎｙ２３１３しか持ってなかったころ（ＡＴｍｅｇａは秋月で取り扱っていなくて、他社だと高価だった）はＡＴｍｅｇａを使用したライターには全く興味がなかった。
  • しかし、速度向上をやるにつれて、他のＡＶＲＵＳＢ利用のライターがどのくらいの性能なのか知りたくなった。
  • ＵＳＢａｓｐのページを見ると、 
    Programming speed is up to 5kBytes/sec. 
SCK option to support targets with low clock speed (< 1,5MHz).
    こんな感じ。
  • firmwareのソースを見る。
  • 普通にlibusbでやっていて、コントロール転送のみ、エンドポイント無し。
  • usbFunctionRead,Writeは存在する。８バイト単位でisp転送を処理。
  • まるでＨＩＤａｓｐと変わらない。ＨＩＤデバイスであるかどうかだけ。
  • ＳＣＬＫは３７５ｋＨｚ（ターゲット１.５ＭＨｚ以上の場合）
  • もしくは８ＫＨｚ（ＳＬＯＷ　ＭＯＤＥ）

なのに５ｋＢ／Ｓ！！！

考察：

  • ＵＳＢの１フレーム（１ｍＳ）に８バイトのＬｏｗＳｐｅｅｄパケットは最大で６個くらい詰め込める。（バルク転送でＯＨＣＩの場合）
  • ということは正味転送時間は１６０μＳ/８バイト程度
  • 残りの時間は８４０μＳ空く。（もちろんそのバス帯域を皆でシェアするわけだが）
  • で、３７５ＫＨｚのusi_trans()（ＳＰＩ転送）を３２回（８バイトのＨＥＸを書きこむ場合の回数）呼ぶ時間を計算すると、 
    ((1/375000) * 8 ) * 32 = 682 μＳ
    時間、足りてるじゃん。
  • libusbだとうまくいくのかな？。

ファームウェアのコードサイズは３.５ｋＢだ。

  • ＡＶＲのコードはポインタ渡しが多いと長くなる。
    • これはポインタに使用できるレジスタがx,y,zしかないので、レジスタ退避のpush,popがばかにならない数入るから。
  • 渡す必要のない決め撃ちバッファばかりの場合は引数なし関数にして参照しまくれば短くなる。
  • そうでなければ、バッファは共通にしてバイトオフセットを渡すとか工夫するとやや短くなる（ソースは汚い）
  • 昔の６５０２のabs,xではabsが渡せないので、そういった感じになっていた。
↑

コントロール転送：訳分からなくなった。†

  • AVRtermを少し改造。usbFunctionReadを使うようにして、１回呼ばれるごとに遅延を入れた。
  • 遅延ループは 60番地に定数を置いている。値１が100uSだ。 
    AVR> e 60 0
AVR> bench 100 32
ctrl write start
ctrl write end 3200 297 s  10774 byte/s  ノーウェイト. 3フレームで完結.
AVR> e 60 1
AVR> bench 100 32
ctrl write start
ctrl write end 3200 500 s  6400 byte/s   100us遅延. 5フレーム.
AVR> e 60 2
AVR> bench 100 32
ctrl write start
ctrl write end 3200 704 s  4545 byte/s   200us遅延. 7フレーム.
AVR> e 60 3
AVR> bench 100 32
ctrl write start
ctrl write end 3200 891 s  3591 byte/s   300us遅延. 9フレーム.
AVR> e 60 4
AVR> bench 100 32
ctrl write start
ctrl write end 3200 1016 s  3149 byte/s  400us遅延. 10フレーム.
  • これを見ると100uSの遅延でも大きく響いている。(平均して２フレームも遅れる)
  • しかし、ＵＳＢａｓｐは680uSの遅延があるはずなのにまったくスループットに影響を与えないのは何故か？

これが解けたら良いんだけどなぁ。ＵＳＢａｓｐ作るかなぁ・・・。

  • ところがこんどは、ＵＳＢハブを外して、パケットを６４バイトで調べると、傾向が変わった。
F:\its\avr\AVRbench\win32>term -iscript
found 3 busses
AVR> e 60 0
AVR> bench 100 64
ctrl write start
ctrl write end 6400 500 s  12800 byte/s
AVR> e 60 1
AVR> bench 100 64
ctrl write start
ctrl write end 6400 906 s  7064 byte/s
AVR> e 60 2
AVR> bench 100 64
ctrl write start
ctrl write end 6400 1297 s  4934 byte/s
AVR> e 60 3
AVR> bench 100 64
ctrl write start
ctrl write end 6400 1703 s  3758 byte/s
AVR> e 60 4
AVR> bench 100 64
ctrl write start
ctrl write end 6400 2235 s  2863 byte/s
AVR> e 60 5
AVR> bench 100 64
ctrl write start
ctrl write end 6400 2500 s  2560 byte/s
AVR> e 60 6
AVR> bench 100 64
ctrl write start
ctrl write end 6400 3297 s  1941 byte/s
AVR> e 60 7
AVR> bench 100 64
ctrl write start
ctrl write end 6400 3500 s  1828 byte/s
AVR> e 60 8
AVR> bench 100 64
ctrl write start
ctrl write end 6400 4094 s  1563 byte/s
AVR> e 60 9
AVR> bench 100 64
ctrl write start
ctrl write end 6400 4407 s  1452 byte/s
AVR> e 60 10
AVR> bench 100 64
ctrl write start
ctrl write end 6400 7500 s  853 byte/s
AVR> exit
Bye.
  • あ、しまった、最後の１０は１６進だった。
  • ＵＳＢハブはオーバーヘッドを持っている？？？
  • この解析、何が複雑かっていうとＯＨＣＩなのにハブを持たせてあるところ。
  • ＵＨＣＩでサンプルを取ってみないと、正しい評価ができないかも。
  • まあしかし、200uSの遅延があっても５ｋＢ/Ｓは出ている。（これもＯＨＣＩ特有の現象かもしれない）

ＴｏＤｏ：

  • ＵＨＣＩでの傾向を調べる。
  • 上記はベンダリクエストでやっているので、これをクラスリクエストに変更して試す。(libusbはそのまま)
  • ＨＩＤ.ＤＬＬのアクセスに変えて試す。

それでも分からなかったらＵＳＢａｓｐを作るしか。

↑

ＵＨＣＩ（インテル互換ＵＳＢホスト）での傾向を手に入れた†

  • 石はインテル純正ｉ８１５（鱈セレＶＡＩＯノート）
  • ハブ無し直結 
    found 2 busses
AVR> e 60 0
AVR> bench 100 64
ctrl write start
ctrl write end 6400 1101 s  5812 byte/s
AVR> e 60 1
AVR> bench 100 64
ctrl write start
ctrl write end 6400 1102 s  5807 byte/s
AVR> e 60 2
AVR> bench 100 64
ctrl write start
ctrl write end 6400 1101 s  5812 byte/s
AVR> e 60 3
AVR> bench 100 64
ctrl write start
ctrl write end 6400 1102 s  5807 byte/s
AVR> e 60 4
AVR> bench 100 64
ctrl write start
ctrl write end 6400 1102 s  5807 byte/s
AVR> e 60 5
AVR> bench 100 64
ctrl write start
ctrl write end 6400 1101 s  5812 byte/s
AVR> e 60 6
AVR> bench 100 64
ctrl write start
ctrl write end 6400 1102 s  5807 byte/s
AVR> e 60 7
AVR> bench 100 64
ctrl write start
ctrl write end 6400 1902 s  3364 byte/s
AVR> e 60 8
AVR> bench 100 64
ctrl write start
ctrl write end 6400 1903 s  3363 byte/s
AVR> e 60 9
AVR> bench 100 64
ctrl write start
ctrl write end 6400 1893 s  3380 byte/s
AVR> e 60 10
AVR> bench 100 64
ctrl write start
ctrl write end 6400 2704 s  2366 byte/s
AVR> exit
Bye.
    うぉーＵＨＣＩすげーーーー
  • 噂は本当だった。
  • ほんとに６００μＳまで時間消費しても常に５ｋＢ/Ｓだ！

高々、鱈セレの９００ＭＨｚなのに感動した。

↑

ＨＩＤａｓｐの高速化は一段落†

  • ＨＩＤａｓｐ高速化に、いろいろ記述。
  • とりあえず、標高２０４８（山頂）に到達したので終了。
  • インターリーブの方向は諦めて、現行のコードにTIMER0 SPI CLOCKを実装しようとしているが、なかなかうまくいかない。
  • 適当なサンプルもない。USBaspのmega88とはＳＰＩ周りのポートがかなり違っている？
  • 頭を冷やすしか。
↑

Ｇｌｉｂに興味。†

  • Ｃ＋＋でなく、Ｃでいろいろやろうとすると、いろいろなコンテナをその場限りでチープに作っては壊し、スクラップ＆ビルドで時間の無駄が多い。
  • Ｇｌｉｂというライブラリがあって、ＳＴＬのようなコンテナっぽいやつとか、スレッド周りとか便利関数がいっぱい詰まっている。
  • これが使いこなせればいいな。
  • ＷｉｎｄｏｗｓとＬｉｎｕｘで共通の書き方が出来るらしい。
  • 元々はＧｔｋのライブラリだそうだ。
  • ＳＴＬが全然読めないので、こっちに逃避。

ここの通りにやってみたら、ちゃんとＭｉｎＧＷでglibが使えるようになった。

  • このライブラリはＬｉｎｕｘでもほぼ同様に使えるので便利。
  • ただし、微妙に libglib-2.0-0.dllみたいなＤＬＬが必要になるのがちょっと痛い。
  • ＬｉｎｕｘではＤＬＬ不要（え？） .soだよね。
↑

ＨＩＤａｓｐ：そろそろやることがなくなってきた。†

  • ので、パケット最適化をやろうと思う。
  • page_writeのset_address後は常にpage_writeなので、これをフュージョンする。
  • page_write後のisp_commandもフュージョンしてみる。
  • page_readはそれほど無駄がないのでそのまま。
  • あと、HIDのパケット長ももうすこし整理してみる？

多少速くなったとぬか喜びしたところ、ＵＨＣＩマザーで試すと全然速くない。

  • 振り出しに戻る。
↑

ＨＩＤａｓｐ：積み残し作業について†

結局振り出しに戻ってしまった。

  • ベンチマークＨＩＤｍｏｎ専用のファームを開発する。
  • usbFunctionWrite()に遅延ループを入れて、遅延を制御しながら、長いＨＩＤ　Ｒｅｐｏｒｔの転送をベンチする。
  • ＵＨＣＩとＯＨＣＩでの傾向を調べる。
  • libusbならＵＳＢａｓｐ相当（５ｋ/秒）の速度が出るはず（予想）
  • しかし、今回はＨＩＤで試みる
↑

ネットブックが、あんなに安い理由†

笠原一輝のユビキタス情報局

  • http://pc.watch.impress.co.jp/docs/2008/0926/ubiq228.htm
  • そうか９４５ＧＳＥは＄２０なのか。
  • ＳＣＨより＄５も安いのに性能が断然上だから。
  • ＳＣＨ搭載モデルが出てこないのはなぜ？
  • と思っていたら、デザインガイドはインテルなんだな。
  • つまり設計料もタダでやってる商売か。
  • だから、似たような構成で各社出してる。
  • ＳＣＨはＰＡＴＡだけのようだ。ＳＡＴＡは繋がらないがＰＣＩ−ＥＸＰＲＥＳＳ×１がある。
  • もういまどきＰＡＴＡはないだろう。ＰＣＩ−ＥＸＰＲＥＳＳ経由でＳＳＤだ。
  • どうやらメモリーが１Ｇまで（最近になってようやく２Ｇ）なので敬遠されている？

しかしまあ、液晶込みで＄３００で作れているのは凄いの一言だ。

  • ＰＳ３よりローコストなのに高性能。（ＲＳＸとＢＤドライブ除く）