Top
HIDaspx
DownLoad
HIDasp高速化
制作
AVR関係
AVR_Monit
AVR_term
W32_term
HIDmon88
HIDtester
usbRS232
Arduino2313
デジタルテスター
ATmega88生活
KeyBoardマニア
KeyBoardマニアII
Arduino400
PICライター
ARMライター
赤外線リモコン
ARM
STM32ブートローダー
STM8S-Discovery改造
STM8S-OpenOCDライター
LPCXpresso
LPC用ブートローダー
NXP用LPCUSB
NXP用ブートローダー
MARY基板
LPC1114FN28
OpenOCD JTAGアダプター
OpenOCDビルド方法
arm-gccビルド方法
mapleIDEの改造
libmapleで仮想COM
PIC32
PIC32MX
Pinguinoで遊ぼう
ブートローダーを作る
シリアルブートローダー
USB仮想シリアル
USBカスタムデバイス
USB簡易モニター
USBオシロスコープ
USBホスト
PIC32でBluetooth
USBAudio
USBStudy
VGA出力に挑戦
BASICを動かす
WinUSB
勝手に改蔵*PIC32
PIC18F
HIDブートローダー
AVR/PIC両用ライター
ARMライター
usb汎用クラス
usbシリアル変換
usbキーボード変換
sdccを使いこなす
mcc18を使いこなす
HIDmon-2550
HIDmon-14K50
PICmonitor
試行錯誤の記録
UBWを試す
旧HIDboot
PIC18F2550試用記
PIC18F4550試用記
その他マイコン
NEC78K
RX62N
SH2A
H8
FM3
XPからubuntuに乗り換え
Android
Xen-hypervisor
Windows8カスタマイズ
開発日記
2015-04
ノウハウ
AVRUSB_Tips
HIDasp情報
汎用USB-IO
・
リンク
フリースペース
ゲストブック
旧コンテンツ
WinVista
インターフェース考
最新の20件
2022-07-25
2008-10
HIDasp高速化
H8/3048F
AutoTicketLinkName
2021-12-11
FormattingRules
2021-12-08
PukiWiki/1.4/Manual/Plugin/O-R
PukiWiki/1.4/Manual/Plugin/L-N
PukiWiki/1.4/Manual/Plugin/V-Z
PukiWiki/1.4/Manual/Plugin/A-D
PukiWiki/1.4/Manual/Plugin/E-G
PukiWiki/1.4/Manual/Plugin/S-U
PukiWiki/1.4/Manual/Plugin/H-K
2020-02-23
YukiWiki
PHP
PukiWiki
WikiWikiWeb
2018-12-19
SandBox
InterWiki
2015-05-07
2015-04
2015-05-02
MenuBar
編集
差分
2008-09 の編集
-- 雛形とするページ --
(no template pages)
[[2008-08]] *とりあえず9月にしてみる。 [#n3a6c46d] ここで意味のない質問 Q:2008.9月(Dark September)の行事は何?~ A:次の中から量子力学的に選択。 -天変地異(地震) -テロ -(原油?価格)暴落 -間違って(余剰次元の理論がたまたま当たって)MBHが生成され地球が飲み込まれる。(これはありえないらしい) --当たった場合でも、MBHの寿命は光速で動いても原子核のサイズより小さいらしいので、一瞬で蒸発するらしい・・・大丈夫、だよね。 --当たらない場合は、LHCが出せる最高出力の(10の16乗)倍のエネルギーがない限りBHは作れないらしいので・・・大丈夫、だよね。 とりあえず、北京オリンピックは無事開催されたので、ジョン・タイターのいた時間線とは離れたらしい。 あとはアメリカが内線状態にならないならおK。 いや、仮にせよ、MBHが作れたとしよう。 -どうやって空間に固定すんの? -どうやって平衡状態にすんの? それが出来るなら、MBHから出るガンマ線放射で半永久発電できるという話だが、かなり眉唾である。 -外部からは、適当な物質を投げ込むだけ。 -BH蒸発(ホーキング輻射)の放射で発電。 -平衡状態が崩れたら地球を飲み込んで成長するかもしれないので、原発よりかなりハイリスクハイリターン。 で、そんな危険なものを使ってタイムトラベルして来たとジョン・タイターは主張していたらしい。 -MBHネタのSFは、JPホーガンの「星を継ぐもの」3部作にもあった。 -まあ、チューリアンの文明は進んでいるので、MBHの制御とか可能なんだろうけど。 -今の人類には到底無理無理。 ---- *Athlon64 2000+とAtomの比較 [#r20721de] -http://northwood.blog60.fc2.com/blog-entry-2207.html#more -これを見る限りではAMDまだまだ元気だぉ。 -単体CPUではなくチップセットまで含めると、AMDのほうが省電力で高性能って、いったい・・・。 -ビデオ性能ではAMD780のほうが断然良いよね。 -AMDはさっさとGPU統合してNetBook市場でもAtomに勝って欲すい。 ---- *Atomの事情。 [#af08c00e] ■元麻布春男の週刊PCホットライン■~ Netbookの生きる道 -http://pc.watch.impress.co.jp/docs/2008/0823/hot566.htm 引用ここから -現在、市場にはさまざまなミニノートPC/Netbookが市販されているが、 -エントリークラスのノートPCとの差別化を図るためIntelは、いくつかの条件を挙げている。 --ディスプレイを大きくし過ぎないこと、 --HDDよりも小容量SSDを採用すること、 --価格をさらに低く抑えること、 --Web中心でアプリケーションの追加インストール等はあまり考えないこと、 --シングルスピンドル(光学ドライブを搭載しないという意味)であること、 -などだ。手っ取り早くいうと、高性能化を図るより、低価格化を行なえ、という方針らしい。市販の製品の中では、ASUStekのEee PCがIntelの言うNetbookに一番近い存在だ。 ここまで。 -まあ、こういう縛りがあったわけだな。 -だから、普通サイズのノートPCに(ベンダー側は)使えないというわけか。 -性能的にはPenMの1G程度はあるので、充分使えるんだけど。 -ついでに言うとEee PCはちっちゃくて可愛いのは良いが、発熱が気になるので手を出せない。 -店頭の展示品は冷房の効いた店内でも裏面は熱くて長時間触れない。パームレストのところもやや熱い。 -インテルはほんとにAtomの片割れの945をなんとか改善して欲しいと切に願う。 ---- *ついに出てきた高速SSD [#qa4627b8] IntelがIDFで1.8/2.5インチの高速SSDを発表 -http://pc.watch.impress.co.jp/docs/2008/0820/mobile421.htm -250MB/Sか。それってSATA2の転送限界に近いじゃん。 -SATA1なら1.5Gbpsだけど8-10エンコーディングされてるはずなので150MB/Sが理論上の上限だ。 -逆に言うと、それ以上速くする必要もない -速くしても対応IFもないし、HOST側PCが追いつかない。 ---- *Debian(lenny amd64)のインストールに失敗。 [#f4e24142] -原因は今のところ分からない。 -テキストインストーラー、グラフィックインストーラーのどちらも現象は同じ。 -ベースパッケージのインストールまでは成功。 -パッケージの選択で、 [*] デスクトップ [ ] (中略) [*] 標準のシステム を実行した後、暫くして赤い画面になり、パッケージセレクトに失敗した旨のメッセージが出る。 -[ALT]+[F3かF4のどっちか]でエラーメッセージを読もうとしても、字化けして読めない。 -上記選択肢をいろいろ変えたけれど駄目。 -かれこれ5回くらい同じことを繰り返した後に、もう諦めた。 -玄箱Proのほうはちゃんと動いているからいいや。 --実はちゃんと動いていない。いくつか疑問点があるので、フルセットのPC版を用意したかったのだ。 --だったらEtchのi386にしとけって?ごもっとも。 --でもlennyのDVD5枚も焼いちゃったし。 -疑問点というのは、localeがja_JP.EUC-JPになっているときは、man pageが引けない(invalid charset name)になる、というものだ。 -わざわざUTF-8に切り替えれば、manは引ける。 -あと、LANG=C man ls とかやれば、英語で出てくるけど。 --追記: この問題は less がeucに対応していないこと、らしい。 --回避策としてはlvをインストールして export PAGER=lv だ。 インストールには失敗しているけれど、その後GRUB入れて再起動させれば一応Debianは最小構成で動いている。 -まあ、その後に地獄の設定が待っているわけだが。 -フルパッケージに近い状態まで一撃でインストール出来るようになってないのかな?それともベータだから? ---- *IF2008.8付録基板 ちゃんと動いたっ! [#y1898984] 壊れてなかった。 --''この基板どうやら死んでるくさい。''はずれくじを引いたか? --PCを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で,固定設定としています. 10Mbpsの半二重だってー(AA略) -そりゃ動かんわ。 -なにせ、以前に試したハブは''100BASEのリピーターハブ''だ。 -バッキャロー ---- *jedで漢字を使いたいよー。 [#p2cdb9ef] 大概のLinux上には、jedというEmacs風の軽量エディタが存在する。 -自分は[[viもemacsも使えない人:http://psp.dip.jp/web/wiki.html]]なので、日頃からjedを愛用している。 -カスタマイズの結果、使い勝手では、昔のVzと同じくらいに使えている。(と思っている) ところが、最近のjed(0.99.18,VineLinux5.0とdebian Etch)では、SJISが使えなくなっているようだ。 -VineLinux4.2用(0.99.14+J0.6.12)はOKだった。 -ソースを展開してみると、・・・ slang-1.4.9/src/slkanji.c が無くなっていた。 -いや、それだけじゃない。EUCのテキストファイルは開けるのだが、カーソルが全角単位で移動しないので、EUC漢字を2文字のASCIIと勘違いしている。 -で、UTF-8ならちゃんと編集出来るのかと思ったら、そうでもないようだ。(SJISと同様に激しく字化けする) 日本語パッチされたjedが欲すい・・・ -というか単にjed単体で良ければ実行ファイルと設定ファイルをコピーというやりかたでOKなはずなんだけど、jedはslangに思いっきり依存しているので、slangもデグレードしてやらないといけない。 -けれど、slangのデグレードはrpmとかのパッケージマネージャーに怒られるんで、どうしよう・・・。 -よく見たらlibslang1とlibslang2は分離していたので、libslang1だけVineLinuxのソースからビルドして差し替えようか。 -だけど、UTF-8なテキストがエディット出来ない問題は、棚上げだ。 ---- *Debian(Etch amd64)のインストールはOKだった。 [#p4302540] -もう3枚のDVD-Rを焼いた。 -しかし、インストールは最初の1枚だけで足りたようだ。 -パッケージ選択でエラーして赤い画面に行くことも無く、わりとフルインストール(2G強?)状態になってくれた。 -jedを入れて、UTF−8のテキストを編集してみた。 -おかしなことに、カーソルバック(^B)は正しく全角単位にカーソルが動いてくれるが、 -カーソルフォワード(^F)を打つと、常に文書末にジャンプする。 --キガクルッテルノカ? -ASCII文字のところはそんなことない。ちゃんと1字づつカーソル移動できる。 -Etchは一応最新版なんだけど。 -64ビットだから駄目?そんなぁ・・・・。 -しかしあれですな。手持ちのCソース、64ビット版のgccだとこけるこける。 -大半はポインタをintにコピーしているところ。これ多いんだよな。 ---- *ASUSTeK、「Eee PC 900-X」を実売49,800円で国内販売〜実売39,800円の701 SD-Xも [#w04723e7] http://pc.watch.impress.co.jp/docs/2008/0829/asus2.htm -何だ何だ? -つい''ぽちッとな、''しそうになるじゃないか。 -これで英語キーなら、即買っちゃうぞ。 >また、内蔵SSDの容量不足を補うため、30GBの外付けUSB HDDが付属する。 何だってー。 -30GのUSB-HDDなんて、実は2台くらい持ってるけど --ノートPC壊れる-->修理不能-->部品取り-->980円のHDDケースに入れて外付けUSBHDDが増殖するの巻き。 --おまけだから無くせないけど、もしもそれ無くせばもっと安く出来るわけか。すごいな。 但し、両方ともCele-Mの900MHzなんだな。''どういうこと?'' -Atomの供給が追いついてないのか、それとも・・・ ---- *こんどはDebian(Etch i386)をVMWare上にインストールしてみた。 [#ree07741] -でも、jedのバグ --カーソルフォワード(^F)を打つと、常に文書末にジャンプする。 -は直っていなかった。orz -ちなみに、EtchをデフォルトインストールするとLANG=ja_JP.UTF-8になる。 -この状態で emacs , jed , vi をデフォルトのまま起動してみたが、 -UTF-8がまともに表示できるのはjedとviのみ。emacsはutf-8の日本語を正しく表示しない。 -jedはカーソル右が発狂しているので、どのみち使えない。 -ところで、lessはUTF-8をちゃんと表示できるようになっていた。(ARM版では出来なかった) つまり、jedのカーソルバグは64ビット固有問題ではなかったわけだ。 ---- *UTF−8の字化けについて、さらに調べてみた。 [#w8760a15] -Debian Lenny (amd64)では、UTF-8の扱いが少し改善されている。 Etch 32bit版の各種テキストエディタの振る舞い(デフォルト状態で) --編集テキスト=UTF8文書 |LANG|ja_JP.EUC-JP|ja_JP.UTF-8| |Emacs -nw|漢字を表示できない|漢字を表示できない| |Jed|UTF8の漢字は<82><83>のようにおかしくなる|表示はOK、カーソル移動に問題あり(^Fは文書末に行く)| |vi|UTF8の漢字は激しく字化けして読めない|表示、カーソル移動共に問題なし| Lenny 64bit版の各種テキストエディタの振る舞い(デフォルト状態で) --編集テキスト=UTF8文書 |LANG|ja_JP.EUC-JP|ja_JP.UTF-8| |Emacs -nw|表示、カーソル移動共に問題なし|表示、カーソル移動共に問題なし| |Jed|UTF8の漢字は<82><83>のようにおかしくなる|表示、カーソル移動共に問題なし(^Fは直っている)| |vi|UTF8の漢字は激しく字化けして読めない|表示、カーソル移動共に問題なし| -ちゃんと使うにはエディタ毎のいろいろなTipsを覚えなければいけないんだろうけれど。 - -EUCへの切り替えはコマンドライン上で $ export LANG=ja_JP.EUC-JP -とやって、teratermの漢字設定をEUCに切り替えるという方法で試したが、 -試し方が間違いなのか?(つまり、エディタ側の初期設定を何か変更する必要あり???) ---- *アメリカ大統領選挙の行方 [#r92eaea2] -[[セーラ・ペイリンさんが共和党の副大統領候補になった:http://tomtom.iza.ne.jp/blog/entry/698314/]]らしい。 -政治家として若いし、眼鏡っ子萌え〜なLinuxerが間違って投票するのかも。(いやそれはLinuxerへの偏見だ!) そんな冗談はさておき、気になっているのはやはり、アメリカの内線状態(ジョンタイターのいた時間線ではそうだ)と、女性大統領誕生のことだ。 -共和党と民主党が拮抗していないか?(ブッシュvsゴアの選挙のときがほんとうに僅差だった。あのときはゴアが引いたので収まったが) -マケインさんは高齢なので、もしかすると女性大統領ということになるのかもしれない。(量子的にどのくらいの確率?) -ジョン・タイターが述べた女性大統領という話は、最初はヒラリーか、ライスのことだとばかり思っていたが、今回は伏兵だな。(ヒラリーの線は消えた。ライスもおそらくないだろう) -とにかく、世界が各戦争により壊滅する未来を選択するのだけはなんとか回避してほしいと切に願う。 ---- *やっぱり9月は暴落かよ [#ce8428cf] -天変地異(地震) -テロ 量子力学的に起こりうる可能性があることはいつか必ず起こってしまうので怖い。 -特に地震は、一種のぜんまい仕掛けの時限爆弾だから。 -目下の注目点は9.13前後とされている大地震だ。 -テロは、まあ大規模なやつは起きないと思うけど・・・どうだろう。 ''*米ソ冷戦再発の可能性、地政学的リスクが大きくなる可能性。'' で、ロシアは冷戦なのか。 -今や協賛主義の国なんてなくなっちゃったので、イデオロギー対立で冷戦なんてありえない。 -つまり冷戦を演じて、誰か得する奴がいるわけだな。(ロシアとかの裏で糸を引いている奴) -つ、武器商人? 最近の流行は[[ロボ対ロボの戦闘:http://www.technobahn.com/news/2008/200808281840.html]]になるらしい。 ---- *エレキジャックNo8(2008.9.4発売)はなんとATtiny2313を含むマイコンチップが付録に! [#yef42d4c] http://www.eleki-jack.com/news/2008/09/no8_1.html -マジかよ。 -他にはNEC78FとHCS08(6800系)とTIのMSP430もだ。 --http://www.freescale.co.jp/products/8bit/HCS08/9s08qg.html --http://focus.tij.co.jp/jp/paramsearch/docs/parametricsearch.tsp?familyId=912§ionId=95&tabId=1528&family=mcu --http://www.necel.com/micro/ja/product/all_8_general.html -ほんとに今年は基板(電子部品付録)豊作年だ。 -来年が不作でなければ良いが。 ATtiny2313のDIP品なら、まだ10個くらい手持ちがあるから要らない。 -糞PICが付いていなかったのはとても幸運だった。 -78KとHCS08は正直要らないなぁ・・・ -というか、そんなマイコン、何に使うの?''教えて!'' ~ ~ ~ ~ ~ おそらく、各マイコン用のFlashライターを作らなくちゃ始まらないので、~ -自分の推理によると、''Flashライターを作る練習キットなわけですな。'' --それか、各種''ICEデバッガの販促用''サンプルチップ詰め合わせ *まだ雑誌を入手してないけど。 [#r50c5f57] -78Kはおそらくトラ技8月号のNEC製Cコンパイラでコードを書けるだろう。 --焼き基板も付属しているとのことだ。 -HCS08は、6800にスタックポインタ相対アドレスを付加したようなマイコンだ。 --[[CodeWarrier:http://www.freescale.co.jp/products/8bit/dvlp_tool.html]]が対応しているらしい(無償) --焼き方は不明。 -[[MSP430:http://focus.tij.co.jp/jp/docs/toolsw/folders/print/msp-cce430.html]]のほうも、16kBまでの無償コンパイラ(Eclipse3.2ベースらしい)が用意されている。 ふーん。 -78Kは8085のそっくりさんで、HCS08は6800にSP相対を足しただけのマイコンなのに。 -もうアセンブラで書かなくてもいいわけね。~ ''なんだか、つまんな〜い''(マゾかよ。) -78F0503DAはFlash32K、RAM1K、Clock20MHzらしいけど、これで合ってるのかな? -HCS08(MC9S08QG8)のほうはFlash8K、RAM512B、20MHzだ。 -でも、6800といえば、IXが1本しかないわけで、memcpyすらまともに書けなかった(割り込み禁止でSP使うのは無しよ) -しょぼいアーキテクチャーなので、Cのオブジェクトは目も当てられんものになるだろうことは容易に想像がつく。 -なんやかんやいって、結局アセンブラ。 --ゼロページ領域にmemcpyコードを展開しておいて --ポインタはIXしかないのでもう一つのポインタはABSアドレッシングのオペランドを直接インクリメントするのだ。 --memcpyはそれで良いけど、それ以外の関数をいちいち命令書き換えで実装するのは''絶対嫌や'' -MSP430F2013は、78KやHCS08よりもはるかにまともなRISCアーキだが、 -Flash2k、RAM128バイトとなっている。 -''ATtiny2313とおんなじ容量かよ。'' **結論として [#fb1b536d] -自分にはどのマイコンも、''1個100円のATtiny2313以下''のように見える。 --反論したいなら、LowSpeedでいいから、SoftwareUSBドライバーを書いて実証してくれ。 --クロック数的に言うと78Kはアウト。 --レジスタ数的に言うとHCS08もアウチ。 --というか、どっちもCコンパイラを使った瞬間に、ありえないコード量と遅さになるだろ。 --MSP430がギリギリ境界線だけど、2Kじゃあ厳しいねぇ・・・。 --ドライバーだけで2K使い切るだろうなぁ。 ---- *Debian(Etch i386)の[[VMイメージを作成:http://psp.dip.jp/web/cgi-bin/wifky/wifky.cgi?p=VMWarePlayer]]してウハウハ。 [#t4adf137] -VMWare Toolsまで入れてしまうと、時計はちゃんと合わせてくれるし、カーソル離せばウィンドウフォーカスも自動で変わってくれるので、だいぶ楽。 -X-Windowのスクリーンサイズも、VMWare窓のリサイズにあわせて自由に変わる。便利。 なのは良いけれど、一つ盲点があった。 -VMイメージを作ったときのマシンがAthlon64だったので、Pentium4のマシンだと''起動しねぇ!'' ~ SIZE(64){orz}。 ~ ~ ~ -i386汎用カーネルに差し替えたvmlinuzを入れてgrubで選択するしかない。 ---- *DELLのミニノート:Inspiron mini 9発表 [#nc81c162] http://pc.watch.impress.co.jp/docs/2008/0905/dell1.htm -英語キーボード、''キター'' -あともう半年もすれば、SSDはHDDに比べて圧倒的に速く快適になるはずだ。 -SATA2インターフェースで良いので、SSDを抜き差し可能なスロットに入れて欲しいような気がする。(昔のNEC98ノートのHDDみたいな感じで) -そうすると、Ubuntuの64ビット版にしたりXPに戻したりが楽だ。 -VMWareでも良いんだけれど、SSDの容量的に両方のOSを入れるのは(現時点では)無理。 -今のSDメモリーカードみたいなフラッシュメモリーインターフェースがSATA並みに速くなるのであれば、SDカードスロットだけ用意して、SSDレスであっても良いくらいだ。 -実際には、そうなることは難しい。なぜならインテルの高速SSDはインテリジェントな並列コントローラと、複数のFlashモジュールの組み合わせでやっと実現しているからだ。 それから、どうでもいいけどAtomの液晶サイズ縛りなんか意味ないんでやめて欲しい。 -図書館とかパブリックスペースに置かれるPCなんか、全部Atomにしてしまってもいいくらいだ。 -ついでに945の後継(低消費電力化)は絶対必要。 -mini 9のチップセットはDELLの英語サイトのTech Specsには、965PM/GM Express(GMA950)と書かれていたが、 これって945GMの間違いではないんだろうか?965だとGMA3000になるが、''さらに爆熱だ'' ---- *78Kのアセンブラって存在するの? [#p9386a8a] http://john.ccac.rwth-aachen.de:8000/as/ -探していたら、こんなサイトに辿り着いた。 -これって1本のアセンブラでアンティークな全CPUを網羅しているよね。 -SC/MPがあった。感激した。 -ソースの拡張子はCなんだけど、最初見たらPascalかと思った。 http://john.ccac.rwth-aachen.de:8000/alf/ -ドイツの人らしいです。 とある2chの会話より 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/ わろた。 ---- *DELLのミニノート:Inspiron mini 9 [#obb6be41] -ファンレスらしい。 -EeePCの爆熱っぷりを見ているので、低音やけどとか大丈夫? -なんか秘策があるのかな? とりあえず -英語キーが選べる。 -ファンレス~ ここまではOK。大変結構。でも~ -発熱具合ってどうなの? -カラーバリエーションはどうなったの? --英語モデルでは白のほうが高いんだけど・・・ -電池の持ちが期待したより普通。 インテルのSSD搭載モデルまで待つか・・・ ---- -DELLの日本語サイトに仕様詳細が出ていた。 -チップセットは945GSE Expressとなっている。 -ちなみに、Atomのチップセットはintelサイトによると |ネットブック | モバイル インテル 945GSE Express チップセット | |ネットトップ | インテル 945GC Express チップセット | ということになっている。 ---- *エレキジャックNo8を買ってしまった。 [#ude084d5] -78K、MSP430、HCS08、AVRとマイコンてんこ盛り -だけど作るものがない。 -しかたがない、ライターでも作るか。 とある2chの会話より。 40 名前:774ワット発電中さん 投稿日:2008/06/10(火) 00:33:42 ID:epyTo3qj PIC/AVRを始めることにした。まずはライタを作らないと。 ライタ作った。さて、何を作ろうか。 …作りたいモノがない!! しかし、何か作らねば…。 そうだ、新しいライタを作ろう。 ''↑丁度今ココ。'' -ちなみに、78Kはシリアル経由でWriteEZ3というツールから書き込み出来るらしい。 -HCS08を焼いたりデバッグしたりするツールUSBSPIDERは4200円くらいで売っている。 -MSP430を焼いたりデバッグしたりするツールez430−F2013は3500円で売っている。 -AVRはCHaNさんのシリアルライターで簡単に焼けると思う。(制作済) わざわざUSBSPIDERとかを買うまでもないし、買ってもたぶん(HCS08の)使い道がないわけで。 -やっぱり他のマイコンでHCS08かMSP430''焼き器を作るまでが遠足''だな。 -出来てしまったらすることが無くなる。 -で、出来上がったHCS08でAVRライターを書くとか・・・(人生無限ループだ) *DELLのミニノート:Inspiron mini 9 の別の可能性 [#f781fe31] -Linux(Ubuntu)搭載を前面に出したノートPCって、他にあったっけ? -これは、市場実験(ユーザーアンケート)のようなもので、 -モバイルデバイスに必ずしもWindowsが必要かどうかをユーザーに問うている。 ''Ubuntuでも十分に利用できると分かった時点でどうなるか予想してみよう。'' -Atomいらないじゃん。nVidiaのTegra(ARMとGPU統合チップ)でもUbuntuくらいは走る。(ちょっと遅いかもね) -だったら、バッテリーの持ちは劇的に伸びるし、爆熱の心配もない。 -もっと安く出来る。 -WindowsXPの供給も止まるので、好都合。 -今後糞Vistaに移行するくらいならUbuntuのほうが好いよね。 逆に、Ubuntuモデルが受け入れられない場合は、Tegraの線は無しってことで。 ---- *Intel、10chアクセスで高速化したSSDを出荷開始 [#l3e16548] http://pc.watch.impress.co.jp/docs/2008/0909/intel1.htm~ http://japanese.engadget.com/2008/09/09/ssd-x25-m-80gb-595/ -80GB。千個受注時の単価は65,760円。 主な仕様はほぼ共通で、容量が80GB、インターフェイスはSATA(3Gbps)、 サステインドリードが最大250MB/sec、サステインドライトが最大70MB/sec、 リードレイテンシは85μsec。消費電力はアクティブ時が0.15W、アイドル時が0.06W。 -''速っ。''(まあ、メモリーだからな。) -NetBook1台分より高いじゃん。 -こいつはむしろ、エンタープライズサーバー用だな。 -Oracleとか動かしている所は、喉から手が出るほど欲しかった速度だろう。 -HDDなら、1秒にせいぜい70回くらいしかランダムリード出来ないが、(秒速高々120回転なので) -SSDは、何千回でもOKだから。 フラッシュがMLCでこの値段なので、SLCだと倍額くらい? -160GBだと、VAIOノートが1台買えますな。 ---- *ARM吼える [#m2528034] http://pc.watch.impress.co.jp/docs/2008/0910/arm.htm -ARM、IntelによるAtom優位の主張に強く反論 -そりゃまあ、2次キャッシュOFFで計測されたら怒るのも当然だよな。 -AtomもARMもシングルスカラーならば同一クロックでほぼ同速度じゃあないかとは思っていた。 --CortexA8はin-order実行の2イシューなのでClassicPentium相当だ。 --まあAtomともよく似ていること。 --レジスタ数の多さで言うとARMのほうが速いと思うが、SSE周りはインテルのほうが何枚も上手だ。 --HyperThreadingの有無の違いはある。(つまりHT ONの状態ではAtom有利) -記事によると768MHzのCortexA8は1.6GのAtomより25%遅いらしい。(まあ用途によるだろうけど) -一番いいのは市場がすべてを決めることだ。 -まず、AtomはIPコアで提供されることはありえないので、今のAtomがARM市場に殴りこむことは不可能。 -そのまえにチップセットをなんとかしる。>インテル -繰り返すようだが、Atomの市場はWindowsXP搭載のNetBook限定なのだから、Ubuntuで十分な用途向けにはどんどんARM内蔵のNetBookを作ればよいだけだ。 -それが市場に受け入れられなかったなら(X86互換の)Atomが自動的に勝つ。 ---- *HIDasp高速化の可能性 [#t0c28c32] [[HIDasp高速化]] ---- *インドの少女、欧州での「ビッグバン実験」を恐れ自殺 [#r9dd8210] -http://jp.reuters.com/article/oddlyEnoughNews/idJPJAPAN-33702120080911 LHCで極小ブラックホール生成実験を行っても地球は消滅しない、CERN -http://www.afpbb.com/article/environment-science-it/science-technology/2514698/3302185 そもそもLHCでブラックホールが作れるなんていう「世間の注目を集める」ニュースを流すのが間違いだったのか。 -基本的にはHiggsを見つけるための実験施設なのだ。 -注目を集めて予算獲得しやすくする効果もあると思うけれど、物理学に詳しくない人たちを無意味に不安がらせるような宣伝もどうかと思う。 -深読みすると、それを知ったインドの天才少女が、本当に事故が起きる可能性を計算した結果自殺、だったら凄いけれど。 -あとね。CERNの施設の写真は、まるで波動砲の発射装置みたいで怖い感じがするんだけどね。たいていあの手の大げさな機器は(生成した素粒子の軌跡や熱量を測る)検出器なんだよね。 -だから、''怖くはないんだぉ。'' 面白いところでは、こんなニュースもあるし。 -[[LHCでゴードン・フリーマン博士目撃、不測の事態の可能性:http://japanese.engadget.com/2008/09/10/lhc-gordon-freeman-half-life/]] ---- *DirectXでプログラムを書いてみようかと。 [#z231e85d] 気の迷いからだが。~ で、 -いや、普通にOpenGLで書くようなことをDirectXで書くことが出来ないかという。 -そうすると、C++とかクラスとか難しいことを覚えなくて良いので。 -別にクラスを使うことは難しくないが、たとえば、Xファイルの読み込みが D3DXLoadMeshFromX("hoge.x" ...) で、描画が for(...) pMesh->DrawSubset( i ); -だなんて言われた日には、まるで「''おまえら何も分からんでいいからVisualBasicでも使ってろ''」と言われているのと同じだ。 じゃあ、自力でXファイルを読んで、DrawPrimitive()してみろと。 -というわけでXファイルの解析を始めたわけだが、 -なんかだめだめフォーマットなんだなこれが。 -特にXバイナリーなんて、元のテキストをトークン番号に置換しただけのテキスト並びのまんまじゃないか。 -しかもDirectX10ではXファイルが扱えなくなっているというし。 すなおにOpenGLで書いたほうがマシなのはわかっている(つもり) ---- ***いろいろ検索していたら2chに当たってしまった。 [#i4caf365] Xファイルを再生するスレ -http://pc11.2ch.net/test/read.cgi/gamedev/1006624202/ -何に困っているかというと、3Dモデルの適当なフォーマットが「存在しない」ことなのだ。 -モデリングソフト毎に独自のフォーマットが存在するが、それは(面倒なので)扱いきれない。 -割とポピュラーなフォーマットとしては --DXF(AutoCAD) --3DS(AutoDesk 3D Studio) --obj(WaveFront) --FBX(AutoDesk) --Collada(SCEA) --VRML / X3D (Web3D) --Xfile / SDKMesh (DirectX) -特定のモデラーを持っているならそれに近いものを使えば良いが、 -どのモデラーでもサポートされていそうなフォーマットというとかなり限定される。 で、 -XファイルはDirectXで最も知られたフォーマットなので、対応モデラーは多くて良いのだが、 -書けるくせに(Xファイルを)読めないモデラーが多いのがまた、困り者だ。 -そのくせ、(Xファイル以外での)適当な共通フォーマットがないんだな。 ---- *HIDデバイスのアクセス方法について誤解していた。 [#jdb3a2b8] -SIZE(8){また恥をかいてしまった。} -HIDデバイスというのは、単にディスクリプタのテーブルが拡張されただけのものかと思っていた。 -ところがReadFile()やWriteFile()で転送されるのは、生パケットではなく、レポートディスクリプタというやつらしい。 -転送サイズは9を指定するのだが、その9バイトバッファの先頭の1バイトはREPORT_IDに割り当てられていて、しかも0x00固定だ。 -実際に転送されているパケットは9バイトのうちの後ろ8バイトのようだ。 -これを長くすることが出来ないと、帯域を稼ぐこともできないっぽい・・・。 -なんかlibusbと全然違うんだな。 -HID.DLLにはベンダー独自リクエストを直接送信するような呼び出しはないのかな? -ReadFile() WriteFile()はブロックされるので、個別に制御するなら別スレッドにするという話だが、 -HIDというかUSBのパケットなのに、なんでもReadFile()関数に押し付けるのは強引だと思った。 参考URLはこのへん?~ すzのAVR研究 -http://suz-avr.sblo.jp/article/8636190.html Obtaining HID Reports / HidD_GetFeature -http://www.osronline.com/DDKx/intinput/hidclass_6xpj.htm ---- *avrspxがWindows2000上でHIDaspを認識してくれない件 [#bba02831] -avrspxのhidasp_init()内でハングすることが多い。 -testパケット(pingのようなエコーバックパケット)を4回送り、受信を行っているが、 -Windows2000上では、2つくらいしか返却されてこない。 -1回送り、1回受け取るように書くとOK. --これはsenshuさんのHIDspx.exeの実装で修正されている。 -WindowsXP上で同じことをすると、4パケットのうちの最初のパケットだけが欠落する。 --但しこの現象はHIDaspをUSBに接続した直後だけに発生する。 --SnoopyProでデバイスリセットを行った直後にも良く発生することが多い。 -Windows2000, WindowsXPの両方でSnoopyProを見ながらやってみたのだが、原因を掴むには至っていない。 -やりにくいのはHID Reportの送受信がReadFile() WriteFile()という Windowsのブロック関数でやらなければならない点だ。 -これは、rs232cの簡易ターミナルを書いたときも相当いらついた。 --非同期リード、ライトにしたければ、CreateFileでFILE_FLAG_OVERLAPモードオープンして、 --ReadFileの最後の引数にOVERLAPPED構造体を与えてやるとかしないといけない。 -あと、HID Reportがどのようなパケットなのか本質を理解していないのが問題。 --マウスならボタン情報、座標などが含まれるようなパケットらしい。 -SnoopyProで見るとインタラプト転送のように見える。 -Microsoftのドキュメントではコントロール転送でもいけるというふうな解説が書かれているので混乱している。 -もしも(LowSpeed)インタラプト転送なら、速度を望むことは絶望的だ。 ---- *HIDsphを研究しておくべきだった。 [#o06ba269] -ソースがかなり洗練されている。 -AVRUSBのAVR Bootloader HID がベースになっているようだ。 -HID Reportの送受には ReadFile()/WriteFile()ではなく HidD_GetFeature()/HidD_SetFeature()で行われている。 -やっぱり[[AVRUSB:http://www.obdev.at/products/avrusb/index.html]]で紹介されているリファレンス実装は一通り見ておくべきだと思った。どれもレベルが高い。 -ATmega88は秋月で@250円なので、もう2313にこだわらなくてもいいかなと。 ---- *HIDsphを実際に焼いてみた。 [#la187b2c] 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 は書き換えたつもり) ---- *[[HIDasp高速化]] [#mef74a41] ここ2日くらい、いろいろ試行錯誤してみた。 -HID Reportの送り方と受け取り方が分かった。 -全てコントロール転送(クラスリクエスト)で実行されているような気がする。 -ただし、まだよくわかっていないのが、Report IDの置き場所についてだ。 --コントロール転送のDOWNストリームデータ(つまり後続パケット)の先頭にあるのか、 --それとも、クラスリクエスト内にあるのかが掴みきれていない。 --デバイスからホストへのUPストリームにおいては間違いなく後続パケットの先頭バイトだと思う。 -それから、ディスクリプタに書かれたREPORT_COUNTの値と、USBの生パケットのサイズの対応も正しく把握しきれていない。あやふやなのだ。 --まあ、動いているからいいや、では駄目だ。 -HIDはドライバーインストールが不要なので、ユーザーに勧めやすい。 -オーバヘッドが多少増えるが、libusbでコントロール転送の生パケットをコーディングするよりもある意味楽かもしれない。 -ふつうのHIDクラス(KB、マウス、JOY等)を書いてみようという気になったのも収穫の一つ。 ATtiny2313の2kB内でも、思ったよりいろいろ詰め込めそうだ。 ---- *ATtiny2313のUSI(SPI) [#fda3d391] -ATMELのPDFを読む。 アセンブリ言語プログラム例 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()は、8ビットの転送に16回ループを回るのだ。 -しかも1バイトの書き込みにはusi_trans()を4回呼ばなければならない。 --(シリアルプログラミングのSPIコマンドはすべて4バイト単位) - -AVR書き込み時に与えるSCKのLOW区間、HIGH区間はCPU CLOCKの3クロック時間より長くなければならない(12MHz以上動作のとき) -これを満たすためには、(仮にLOW=4CLK、HIGH=4CLKとすると)12MHzのAVRを焼くためにはSCKは1.5MHz以下でないとだめという感じかな。 -ということは、上記のループ展開したようなSPI転送だと6MHzになるので速すぎる。 -delay()を外した状態のusi_trans()のgccコードが丁度上記の最初のコード例になるので、 12MHzのAVRを焼く場合の限界速ということになりそうだ。 -この頃はATmega88の20MHz基板を焼いているので、なんとか間に合っているようだ。 --焼いているというのが、単に''焼き速度のベンチマーク''をしているだけ、というところがむなしいけど。 ---- *USBの接続変更 [#y4528e80] -USBのD+をPD3 -USBのD−をPD4 -に接続するのが流行りらしい。 -とりあえず、ターゲットボードの配線だけは変えた。 -usbdrv/を最新と取り替えて、usbconfig.hもPD3,4に合わせた。 -しかし、コードサイズがあっというまに100バイト以上溢れ返ってしまった。 ~ SIZE(24){何故?} ~ わっかりーませーーん。降参です。 *はっはっはっ分かってしまえば簡単だ。 [#efed7640] #define USB_CFG_HAVE_INTRIN_ENDPOINT 1 こいつが1になっていただけだった。これで100バイトくらい増える。 -どうやって調べたかって?そりゃ、双方の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 -↑今ここ。 -これで、流行に乗り遅れないぞっと。 ちなみに、HID Reportの取得や書き込みは全てコントロール転送で完結しているっぽいので (SnoopyProで見ただけだけど)クソ遅いインタラプト転送なんて、使わないぞっと。 *HIDasp高速化改良(方法論のみ) [#a2afdeca] -HIDspx−srcに含まれているhidasp.c には、HID Reportのパケットをダンプするデバッグ機能がついている。 #define PKTDUMP 0 // HID Reportパケットをダンプする. これを 1 にして作成したEXEで書き込み&ベリファイを行うと、どのようなHIDパケットが飛び交ったかがコンソールに表示される。 -次に、これをOFFにしておいて、[[SnoopyPro:http://sourceforge.net/projects/usbsnoop/]]でUSBパケットをキャプチャーする。 -HIDspx.exeで同じように書き込み&ベリファイを行ってみる。 -SnoopyProのログにはそのパケットが送られた時間が記録される。1mSが1フレームと考える。 -そして、avrspxのソースを見ながら、どのようなことが起こっているのかを想像すればよい。 速くしようと思えば、無駄なパケットを減らすことと、HID Reportを64バイトにまで拡張することと、usbFunctionWrite()に8バイト来た時点で行動を起こすことだ。 -usbFunctionWrite()では、8バイト単位で処理を行い、SPI経由でデータを送ってしまうことが出来るので、ReportBufは長く取る必要がない。最初に来た8バイトのヘッダー部分だけ覚えておけばいいはずだ。 -アドレスセットとページライト、書き込みまでをその長いパケットに全部含めてしまえばさらに無駄は減るが、ちょっとやりすぎかもしれない。 -また、読み込みも速くしたければ、ページリードのコマンドは省略してしまい、長いHID Reportの要求が来たら、さっさと固定長でページリードを行なってしまえばよい。端数に関してだけ、従来どおりページリードコマンドでサイズを指定して転送してもらうようにする。 -これも8バイト単位で並列処理させると良いかもしれない。 -ページリード以外のコマンドは結果が7バイトで足りるので、長いReport要求を出すことはないはず。 書き込みターゲットのクロックが遅い場合はどのみち速くすることは出来ないので、高速化の対象は8MHz以上で動作しているAVRチップに限定すれば、上記のような戦略が有効だと思う。 -しかし、上記の手法はやややりすぎの感もある。 -手持ちのmega88に5秒程度で書き込み&ベリファイが出来るのならそれで充分だし -tiny2313に書いていた頃は、昔のままでも遅いと思ったことはなかったのだから。 *パソコン起動不可->復旧完了。 [#p4857df6] -今朝からパソコンが起動しなくなった。 -立ち上げるといきなりリセット。 -もう1回たちあげて、1分くらい作業したらまた勝手にリセット。 -ついに立ち上がらなくなった。メッセージは C:\WINDOWS\SYSTEM32\CONFIG\SYSTEMが壊れているか読めません。 インストールCDを入れて立ち上げてRを押してください。 みたいなやつ。 -最初はメモリーを疑った。MEMTEST86に掛けたが7周しても問題なし。 -次にHDDを疑った。幸い容量UPの交換前HDDが残っていたのでそちらで立ち上げて CHKDISKは無問題。 -やっぱりCONFIG/SYSTEMの問題かと思って、正常起動するほうのSYSTEM(システムレジストリファイル) を上書きしてみたら、こんどは起動するがログイン画面に来ない。 -はたと思いついて、Windows/repair/SYSTEM という、インストール直後に作成されるシステムレジストリファイルのバックアップを上書きしてみると、幸運にもOSが起動するようになった。 -但し、起動直後は、まるでインストール直後のような、ドライバー初期状態だったので、適当にドライバーを入れて対処。 -ユーザーレジストリは無事だったようだ。完全に復旧。 一件落着。 -Windows98時代は、このようなトラブルが日常だったので、C:ドライブにはOSのみを入れるという癖がついている。 -さらに、OSのパーティションを3つ同じ容量で切って、Windows98の安定した状態のC:のコピーを3個持って運用していた。 -ブート切り替えはChaNさん作のMBMというブートローダーだ。 -これはパーティションの細かな設定やパーティションコピー、ドライブ間コピーなどができる頼もしい奴。 -もっとも、今ではそのような用途に特化したLiveCD Linuxがいくつか存在するようだ。 こういうことが年に1回くらいはあるので、OSの起動パーティションは常に3つ切っていて、レスキュー用の仮OSはいつでもインストール可能状態にしている。 -(もちろんKnoppixとかでも最近はNTFSをマウントして書き込みまで出来るのだが、壊れたWindowsの障害状況を見たり、ファイルを比較したりといったことまでやるなら、そっくり同じOSを別パーティションに入れるにこしたことはない。) *HIDasp:時には諦めも肝心? [#l321b1b1] -例のusbFunctionRead()に引っ掛けて8バイトづつちまちま転送したらどうなるかテスト. -HID Report長はついに126バイト。(SnoopyProで確認したから間違いない) 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 -8kB全読みはSPI転送を端折ると0.8秒で終わる(USB転送だけだ。つまり10kB/Sはちゃんと出ている) -delay()ループを削除した状態で、上記1.7秒。 -delayループを入れて'-d0'では2.4秒。(つまり、8バイト単位でインターリーブしたほうが却って遅いという不本意な結果) -とするとspi_trans()が入るだけで(ホストから見て)1フレーム後回しにされる遅延になる。 -spi_trans()がやや遅いと2フレーム後回しにされる遅延になる。 -ここらへんがソフト処理USBの限界だ。 -プロトコルエンジンが後付けになっているようなPIC18F2550とかNEC78KではUSB転送はバックグラウンド的に実行されて共有RAMにパケットが残る仕組みなので、かなわない。 -というかLowSpeedの限界を見たような気もする。 -いろいろ考えたが解法は無い。SPIクロックをタイマー0から与えるようにしてクロックを上げる(?) -現状12MHz/4Cycle/2(2回叩いて1SCL)=1.5MHzのSPIクロックなので、これを2MHz(8MHzCPU焼きの上限いっぱい)まで上げれば・・・たいして変わらない? -ここまで来るとパズルだな。SPI転送を割り込み駆動にしてバックグラウンド処理すれば良さそうに見えるけど、実はusbFunctionRead()は遅延実行できない関数なので、やるなら1パケット先読みで先回りするしかないだろう。書くほうは先読みの必要はないし(データが来るまで)出来ないから遅延実行するようにして即時復帰だ。 -そういった処理を書きたいならmega88を使うしかない。Readのインターリーブを実装しただけで2kBを使い尽くしてLED,MONITORを外すことまでやった。 と、まあいろいろ考えたけれどここらが2kの限界点だ。 ---- *Write&Verify:4秒切りました。 [#jde93f52] 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全部取っ払いで、こんな感じです。 -変な(?)モニターコマンドとLEDコマンドの両方を入れると、コードが2バイト溢れます。 --配線をINT0に戻せば2048といった感じですが、変なモニターのほうは需要がなさそう なので、外しておきます。 -d0は最速なのでよいとして、d1〜d5とd6以降の件は、ホスト側のhidasp.cにテーブルを持たせますかね。 REPORT_ID=6(46)は、現在使用していない(バッファが40バイトしか確保していない)ので削除すると 9バイト空きます。 ---- *USBaspの実装を見てみることにした。 [#wdf0315a] -ATtiny2313しか持ってなかったころ(ATmegaは秋月で取り扱っていなくて、他社だと高価だった)はATmegaを使用したライターには全く興味がなかった。 -しかし、速度向上をやるにつれて、他のAVRUSB利用のライターがどのくらいの性能なのか知りたくなった。 -USBaspのページを見ると、 Programming speed is up to 5kBytes/sec. SCK option to support targets with low clock speed (< 1,5MHz). こんな感じ。 -firmwareのソースを見る。 -普通にlibusbでやっていて、コントロール転送のみ、エンドポイント無し。 -usbFunctionRead,Writeは存在する。8バイト単位でisp転送を処理。 -''まるでHIDaspと変わらない。HIDデバイスであるかどうかだけ。'' -SCLKは375kHz(ターゲット1.5MHz以上の場合) -もしくは8KHz(SLOW MODE) ''なのに5kB/S!!!'' 考察: -USBの1フレーム(1mS)に8バイトのLowSpeedパケットは最大で6個くらい詰め込める。(バルク転送でOHCIの場合) -ということは正味転送時間は160μS/8バイト程度 -残りの時間は840μS空く。(もちろんそのバス帯域を皆でシェアするわけだが) -で、375KHzのusi_trans()(SPI転送)を32回(8バイトのHEXを書きこむ場合の回数)呼ぶ時間を計算すると、 ((1/375000) * 8 ) * 32 = 682 μS 時間、足りてるじゃん。 -libusbだとうまくいくのかな?。 ファームウェアのコードサイズは3.5kBだ。 -AVRのコードはポインタ渡しが多いと長くなる。 --これはポインタに使用できるレジスタがx,y,zしかないので、レジスタ退避のpush,popがばかにならない数入るから。 -渡す必要のない決め撃ちバッファばかりの場合は引数なし関数にして参照しまくれば短くなる。 -そうでなければ、バッファは共通にしてバイトオフセットを渡すとか工夫するとやや短くなる(ソースは汚い) -昔の6502のabs,xではabsが渡せないので、そういった感じになっていた。 ---- *コントロール転送:訳分からなくなった。 [#o604ba8c] -AVRtermを少し改造。usbFunctionReadを使うようにして、1回呼ばれるごとに遅延を入れた。 -遅延ループは 60番地に定数を置いている。値1が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の遅延でも大きく響いている。(平均して2フレームも遅れる) -しかし、USBaspは680uSの遅延があるはずなのにまったくスループットに影響を与えないのは''何故か?'' これが解けたら良いんだけどなぁ。USBasp作るかなぁ・・・。 -ところがこんどは、USBハブを外して、パケットを64バイトで調べると、傾向が変わった。 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. -あ、しまった、最後の10は16進だった。 -USBハブはオーバーヘッドを持っている??? -この解析、何が複雑かっていうとOHCIなのにハブを持たせてあるところ。 -UHCIでサンプルを取ってみないと、正しい評価ができないかも。 -まあしかし、200uSの遅延があっても5kB/Sは出ている。(これもOHCI特有の現象かもしれない) ToDo: -UHCIでの傾向を調べる。 -上記はベンダリクエストでやっているので、これをクラスリクエストに変更して試す。(libusbはそのまま) -HID.DLLのアクセスに変えて試す。 それでも分からなかったらUSBaspを作るしか。 ---- *UHCI(インテル互換USBホスト)での傾向を手に入れた [#a1c77d35] -石はインテル純正i815(鱈セレVAIOノート) -ハブ無し直結 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. ''うぉーUHCIすげーーーー'' -噂は本当だった。 -ほんとに600μSまで時間消費しても常に5kB/Sだ! 高々、鱈セレの900MHzなのに感動した。 ---- *HIDaspの高速化は一段落 [#kd431081] -[[HIDasp高速化]]に、いろいろ記述。 -とりあえず、標高2048(山頂)に到達したので終了。 -インターリーブの方向は諦めて、現行のコードにTIMER0 SPI CLOCKを実装しようとしているが、なかなかうまくいかない。 -適当なサンプルもない。USBaspのmega88とはSPI周りのポートがかなり違っている? -頭を冷やすしか。 ---- *Glibに興味。 [#qc750e12] -C++でなく、Cでいろいろやろうとすると、いろいろなコンテナをその場限りでチープに作っては壊し、スクラップ&ビルドで時間の無駄が多い。 -Glibというライブラリがあって、STLのようなコンテナっぽいやつとか、スレッド周りとか便利関数がいっぱい詰まっている。 -これが使いこなせればいいな。 -WindowsとLinuxで共通の書き方が出来るらしい。 -元々はGtkのライブラリだそうだ。 -STLが全然読めないので、こっちに逃避。 ここの通りにやってみたら、ちゃんとMinGWでglibが使えるようになった。 -http://alohakun.blog7.fc2.com/blog-entry-587.html -このライブラリはLinuxでもほぼ同様に使えるので便利。 -ただし、微妙に libglib-2.0-0.dllみたいなDLLが必要になるのがちょっと痛い。 -LinuxではDLL不要(え?) .soだよね。 ---- *HIDasp:そろそろやることがなくなってきた。 [#c3678437] -ので、パケット最適化をやろうと思う。 -page_writeのset_address後は常にpage_writeなので、これをフュージョンする。 -page_write後のisp_commandもフュージョンしてみる。 -page_readはそれほど無駄がないのでそのまま。 -あと、HIDのパケット長ももうすこし整理してみる? -いよいよメモリー残量が尽きた。 -結果は[[HIDasp高速化]]と、[[HIDasp速度比較]]。 多少速くなったとぬか喜びしたところ、UHCIマザーで試すと全然速くない。 -振り出しに戻る。 ---- *HIDasp:積み残し作業について [#o4b87cbf] 結局振り出しに戻ってしまった。 -ベンチマークHIDmon専用のファームを開発する。 -usbFunctionWrite()に遅延ループを入れて、遅延を制御しながら、長いHID Reportの転送をベンチする。 -UHCIとOHCIでの傾向を調べる。 -libusbならUSBasp相当(5k/秒)の速度が出るはず(予想) -しかし、今回はHIDで試みる ---- *ネットブックが、あんなに安い理由 [#k201a9b5] 笠原一輝のユビキタス情報局 -http://pc.watch.impress.co.jp/docs/2008/0926/ubiq228.htm -そうか945GSEは$20なのか。 -SCHより$5も安いのに性能が断然上だから。 -SCH搭載モデルが出てこないのはなぜ? -と思っていたら、デザインガイドはインテルなんだな。 -つまり設計料もタダでやってる商売か。 -だから、似たような構成で各社出してる。 -SCHはPATAだけのようだ。SATAは繋がらないがPCI−EXPRESS×1がある。 -もういまどきPATAはないだろう。PCI−EXPRESS経由でSSDだ。 -どうやらメモリーが1Gまで(最近になってようやく2G)なので敬遠されている? しかしまあ、液晶込みで$300で作れているのは凄いの一言だ。 -PS3よりローコストなのに高性能。(RSXとBDドライブ除く) ---- #contents
タイムスタンプを変更しない
[[2008-08]] *とりあえず9月にしてみる。 [#n3a6c46d] ここで意味のない質問 Q:2008.9月(Dark September)の行事は何?~ A:次の中から量子力学的に選択。 -天変地異(地震) -テロ -(原油?価格)暴落 -間違って(余剰次元の理論がたまたま当たって)MBHが生成され地球が飲み込まれる。(これはありえないらしい) --当たった場合でも、MBHの寿命は光速で動いても原子核のサイズより小さいらしいので、一瞬で蒸発するらしい・・・大丈夫、だよね。 --当たらない場合は、LHCが出せる最高出力の(10の16乗)倍のエネルギーがない限りBHは作れないらしいので・・・大丈夫、だよね。 とりあえず、北京オリンピックは無事開催されたので、ジョン・タイターのいた時間線とは離れたらしい。 あとはアメリカが内線状態にならないならおK。 いや、仮にせよ、MBHが作れたとしよう。 -どうやって空間に固定すんの? -どうやって平衡状態にすんの? それが出来るなら、MBHから出るガンマ線放射で半永久発電できるという話だが、かなり眉唾である。 -外部からは、適当な物質を投げ込むだけ。 -BH蒸発(ホーキング輻射)の放射で発電。 -平衡状態が崩れたら地球を飲み込んで成長するかもしれないので、原発よりかなりハイリスクハイリターン。 で、そんな危険なものを使ってタイムトラベルして来たとジョン・タイターは主張していたらしい。 -MBHネタのSFは、JPホーガンの「星を継ぐもの」3部作にもあった。 -まあ、チューリアンの文明は進んでいるので、MBHの制御とか可能なんだろうけど。 -今の人類には到底無理無理。 ---- *Athlon64 2000+とAtomの比較 [#r20721de] -http://northwood.blog60.fc2.com/blog-entry-2207.html#more -これを見る限りではAMDまだまだ元気だぉ。 -単体CPUではなくチップセットまで含めると、AMDのほうが省電力で高性能って、いったい・・・。 -ビデオ性能ではAMD780のほうが断然良いよね。 -AMDはさっさとGPU統合してNetBook市場でもAtomに勝って欲すい。 ---- *Atomの事情。 [#af08c00e] ■元麻布春男の週刊PCホットライン■~ Netbookの生きる道 -http://pc.watch.impress.co.jp/docs/2008/0823/hot566.htm 引用ここから -現在、市場にはさまざまなミニノートPC/Netbookが市販されているが、 -エントリークラスのノートPCとの差別化を図るためIntelは、いくつかの条件を挙げている。 --ディスプレイを大きくし過ぎないこと、 --HDDよりも小容量SSDを採用すること、 --価格をさらに低く抑えること、 --Web中心でアプリケーションの追加インストール等はあまり考えないこと、 --シングルスピンドル(光学ドライブを搭載しないという意味)であること、 -などだ。手っ取り早くいうと、高性能化を図るより、低価格化を行なえ、という方針らしい。市販の製品の中では、ASUStekのEee PCがIntelの言うNetbookに一番近い存在だ。 ここまで。 -まあ、こういう縛りがあったわけだな。 -だから、普通サイズのノートPCに(ベンダー側は)使えないというわけか。 -性能的にはPenMの1G程度はあるので、充分使えるんだけど。 -ついでに言うとEee PCはちっちゃくて可愛いのは良いが、発熱が気になるので手を出せない。 -店頭の展示品は冷房の効いた店内でも裏面は熱くて長時間触れない。パームレストのところもやや熱い。 -インテルはほんとにAtomの片割れの945をなんとか改善して欲しいと切に願う。 ---- *ついに出てきた高速SSD [#qa4627b8] IntelがIDFで1.8/2.5インチの高速SSDを発表 -http://pc.watch.impress.co.jp/docs/2008/0820/mobile421.htm -250MB/Sか。それってSATA2の転送限界に近いじゃん。 -SATA1なら1.5Gbpsだけど8-10エンコーディングされてるはずなので150MB/Sが理論上の上限だ。 -逆に言うと、それ以上速くする必要もない -速くしても対応IFもないし、HOST側PCが追いつかない。 ---- *Debian(lenny amd64)のインストールに失敗。 [#f4e24142] -原因は今のところ分からない。 -テキストインストーラー、グラフィックインストーラーのどちらも現象は同じ。 -ベースパッケージのインストールまでは成功。 -パッケージの選択で、 [*] デスクトップ [ ] (中略) [*] 標準のシステム を実行した後、暫くして赤い画面になり、パッケージセレクトに失敗した旨のメッセージが出る。 -[ALT]+[F3かF4のどっちか]でエラーメッセージを読もうとしても、字化けして読めない。 -上記選択肢をいろいろ変えたけれど駄目。 -かれこれ5回くらい同じことを繰り返した後に、もう諦めた。 -玄箱Proのほうはちゃんと動いているからいいや。 --実はちゃんと動いていない。いくつか疑問点があるので、フルセットのPC版を用意したかったのだ。 --だったらEtchのi386にしとけって?ごもっとも。 --でもlennyのDVD5枚も焼いちゃったし。 -疑問点というのは、localeがja_JP.EUC-JPになっているときは、man pageが引けない(invalid charset name)になる、というものだ。 -わざわざUTF-8に切り替えれば、manは引ける。 -あと、LANG=C man ls とかやれば、英語で出てくるけど。 --追記: この問題は less がeucに対応していないこと、らしい。 --回避策としてはlvをインストールして export PAGER=lv だ。 インストールには失敗しているけれど、その後GRUB入れて再起動させれば一応Debianは最小構成で動いている。 -まあ、その後に地獄の設定が待っているわけだが。 -フルパッケージに近い状態まで一撃でインストール出来るようになってないのかな?それともベータだから? ---- *IF2008.8付録基板 ちゃんと動いたっ! [#y1898984] 壊れてなかった。 --''この基板どうやら死んでるくさい。''はずれくじを引いたか? --PCを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で,固定設定としています. 10Mbpsの半二重だってー(AA略) -そりゃ動かんわ。 -なにせ、以前に試したハブは''100BASEのリピーターハブ''だ。 -バッキャロー ---- *jedで漢字を使いたいよー。 [#p2cdb9ef] 大概のLinux上には、jedというEmacs風の軽量エディタが存在する。 -自分は[[viもemacsも使えない人:http://psp.dip.jp/web/wiki.html]]なので、日頃からjedを愛用している。 -カスタマイズの結果、使い勝手では、昔のVzと同じくらいに使えている。(と思っている) ところが、最近のjed(0.99.18,VineLinux5.0とdebian Etch)では、SJISが使えなくなっているようだ。 -VineLinux4.2用(0.99.14+J0.6.12)はOKだった。 -ソースを展開してみると、・・・ slang-1.4.9/src/slkanji.c が無くなっていた。 -いや、それだけじゃない。EUCのテキストファイルは開けるのだが、カーソルが全角単位で移動しないので、EUC漢字を2文字のASCIIと勘違いしている。 -で、UTF-8ならちゃんと編集出来るのかと思ったら、そうでもないようだ。(SJISと同様に激しく字化けする) 日本語パッチされたjedが欲すい・・・ -というか単にjed単体で良ければ実行ファイルと設定ファイルをコピーというやりかたでOKなはずなんだけど、jedはslangに思いっきり依存しているので、slangもデグレードしてやらないといけない。 -けれど、slangのデグレードはrpmとかのパッケージマネージャーに怒られるんで、どうしよう・・・。 -よく見たらlibslang1とlibslang2は分離していたので、libslang1だけVineLinuxのソースからビルドして差し替えようか。 -だけど、UTF-8なテキストがエディット出来ない問題は、棚上げだ。 ---- *Debian(Etch amd64)のインストールはOKだった。 [#p4302540] -もう3枚のDVD-Rを焼いた。 -しかし、インストールは最初の1枚だけで足りたようだ。 -パッケージ選択でエラーして赤い画面に行くことも無く、わりとフルインストール(2G強?)状態になってくれた。 -jedを入れて、UTF−8のテキストを編集してみた。 -おかしなことに、カーソルバック(^B)は正しく全角単位にカーソルが動いてくれるが、 -カーソルフォワード(^F)を打つと、常に文書末にジャンプする。 --キガクルッテルノカ? -ASCII文字のところはそんなことない。ちゃんと1字づつカーソル移動できる。 -Etchは一応最新版なんだけど。 -64ビットだから駄目?そんなぁ・・・・。 -しかしあれですな。手持ちのCソース、64ビット版のgccだとこけるこける。 -大半はポインタをintにコピーしているところ。これ多いんだよな。 ---- *ASUSTeK、「Eee PC 900-X」を実売49,800円で国内販売〜実売39,800円の701 SD-Xも [#w04723e7] http://pc.watch.impress.co.jp/docs/2008/0829/asus2.htm -何だ何だ? -つい''ぽちッとな、''しそうになるじゃないか。 -これで英語キーなら、即買っちゃうぞ。 >また、内蔵SSDの容量不足を補うため、30GBの外付けUSB HDDが付属する。 何だってー。 -30GのUSB-HDDなんて、実は2台くらい持ってるけど --ノートPC壊れる-->修理不能-->部品取り-->980円のHDDケースに入れて外付けUSBHDDが増殖するの巻き。 --おまけだから無くせないけど、もしもそれ無くせばもっと安く出来るわけか。すごいな。 但し、両方ともCele-Mの900MHzなんだな。''どういうこと?'' -Atomの供給が追いついてないのか、それとも・・・ ---- *こんどはDebian(Etch i386)をVMWare上にインストールしてみた。 [#ree07741] -でも、jedのバグ --カーソルフォワード(^F)を打つと、常に文書末にジャンプする。 -は直っていなかった。orz -ちなみに、EtchをデフォルトインストールするとLANG=ja_JP.UTF-8になる。 -この状態で emacs , jed , vi をデフォルトのまま起動してみたが、 -UTF-8がまともに表示できるのはjedとviのみ。emacsはutf-8の日本語を正しく表示しない。 -jedはカーソル右が発狂しているので、どのみち使えない。 -ところで、lessはUTF-8をちゃんと表示できるようになっていた。(ARM版では出来なかった) つまり、jedのカーソルバグは64ビット固有問題ではなかったわけだ。 ---- *UTF−8の字化けについて、さらに調べてみた。 [#w8760a15] -Debian Lenny (amd64)では、UTF-8の扱いが少し改善されている。 Etch 32bit版の各種テキストエディタの振る舞い(デフォルト状態で) --編集テキスト=UTF8文書 |LANG|ja_JP.EUC-JP|ja_JP.UTF-8| |Emacs -nw|漢字を表示できない|漢字を表示できない| |Jed|UTF8の漢字は<82><83>のようにおかしくなる|表示はOK、カーソル移動に問題あり(^Fは文書末に行く)| |vi|UTF8の漢字は激しく字化けして読めない|表示、カーソル移動共に問題なし| Lenny 64bit版の各種テキストエディタの振る舞い(デフォルト状態で) --編集テキスト=UTF8文書 |LANG|ja_JP.EUC-JP|ja_JP.UTF-8| |Emacs -nw|表示、カーソル移動共に問題なし|表示、カーソル移動共に問題なし| |Jed|UTF8の漢字は<82><83>のようにおかしくなる|表示、カーソル移動共に問題なし(^Fは直っている)| |vi|UTF8の漢字は激しく字化けして読めない|表示、カーソル移動共に問題なし| -ちゃんと使うにはエディタ毎のいろいろなTipsを覚えなければいけないんだろうけれど。 - -EUCへの切り替えはコマンドライン上で $ export LANG=ja_JP.EUC-JP -とやって、teratermの漢字設定をEUCに切り替えるという方法で試したが、 -試し方が間違いなのか?(つまり、エディタ側の初期設定を何か変更する必要あり???) ---- *アメリカ大統領選挙の行方 [#r92eaea2] -[[セーラ・ペイリンさんが共和党の副大統領候補になった:http://tomtom.iza.ne.jp/blog/entry/698314/]]らしい。 -政治家として若いし、眼鏡っ子萌え〜なLinuxerが間違って投票するのかも。(いやそれはLinuxerへの偏見だ!) そんな冗談はさておき、気になっているのはやはり、アメリカの内線状態(ジョンタイターのいた時間線ではそうだ)と、女性大統領誕生のことだ。 -共和党と民主党が拮抗していないか?(ブッシュvsゴアの選挙のときがほんとうに僅差だった。あのときはゴアが引いたので収まったが) -マケインさんは高齢なので、もしかすると女性大統領ということになるのかもしれない。(量子的にどのくらいの確率?) -ジョン・タイターが述べた女性大統領という話は、最初はヒラリーか、ライスのことだとばかり思っていたが、今回は伏兵だな。(ヒラリーの線は消えた。ライスもおそらくないだろう) -とにかく、世界が各戦争により壊滅する未来を選択するのだけはなんとか回避してほしいと切に願う。 ---- *やっぱり9月は暴落かよ [#ce8428cf] -天変地異(地震) -テロ 量子力学的に起こりうる可能性があることはいつか必ず起こってしまうので怖い。 -特に地震は、一種のぜんまい仕掛けの時限爆弾だから。 -目下の注目点は9.13前後とされている大地震だ。 -テロは、まあ大規模なやつは起きないと思うけど・・・どうだろう。 ''*米ソ冷戦再発の可能性、地政学的リスクが大きくなる可能性。'' で、ロシアは冷戦なのか。 -今や協賛主義の国なんてなくなっちゃったので、イデオロギー対立で冷戦なんてありえない。 -つまり冷戦を演じて、誰か得する奴がいるわけだな。(ロシアとかの裏で糸を引いている奴) -つ、武器商人? 最近の流行は[[ロボ対ロボの戦闘:http://www.technobahn.com/news/2008/200808281840.html]]になるらしい。 ---- *エレキジャックNo8(2008.9.4発売)はなんとATtiny2313を含むマイコンチップが付録に! [#yef42d4c] http://www.eleki-jack.com/news/2008/09/no8_1.html -マジかよ。 -他にはNEC78FとHCS08(6800系)とTIのMSP430もだ。 --http://www.freescale.co.jp/products/8bit/HCS08/9s08qg.html --http://focus.tij.co.jp/jp/paramsearch/docs/parametricsearch.tsp?familyId=912§ionId=95&tabId=1528&family=mcu --http://www.necel.com/micro/ja/product/all_8_general.html -ほんとに今年は基板(電子部品付録)豊作年だ。 -来年が不作でなければ良いが。 ATtiny2313のDIP品なら、まだ10個くらい手持ちがあるから要らない。 -糞PICが付いていなかったのはとても幸運だった。 -78KとHCS08は正直要らないなぁ・・・ -というか、そんなマイコン、何に使うの?''教えて!'' ~ ~ ~ ~ ~ おそらく、各マイコン用のFlashライターを作らなくちゃ始まらないので、~ -自分の推理によると、''Flashライターを作る練習キットなわけですな。'' --それか、各種''ICEデバッガの販促用''サンプルチップ詰め合わせ *まだ雑誌を入手してないけど。 [#r50c5f57] -78Kはおそらくトラ技8月号のNEC製Cコンパイラでコードを書けるだろう。 --焼き基板も付属しているとのことだ。 -HCS08は、6800にスタックポインタ相対アドレスを付加したようなマイコンだ。 --[[CodeWarrier:http://www.freescale.co.jp/products/8bit/dvlp_tool.html]]が対応しているらしい(無償) --焼き方は不明。 -[[MSP430:http://focus.tij.co.jp/jp/docs/toolsw/folders/print/msp-cce430.html]]のほうも、16kBまでの無償コンパイラ(Eclipse3.2ベースらしい)が用意されている。 ふーん。 -78Kは8085のそっくりさんで、HCS08は6800にSP相対を足しただけのマイコンなのに。 -もうアセンブラで書かなくてもいいわけね。~ ''なんだか、つまんな〜い''(マゾかよ。) -78F0503DAはFlash32K、RAM1K、Clock20MHzらしいけど、これで合ってるのかな? -HCS08(MC9S08QG8)のほうはFlash8K、RAM512B、20MHzだ。 -でも、6800といえば、IXが1本しかないわけで、memcpyすらまともに書けなかった(割り込み禁止でSP使うのは無しよ) -しょぼいアーキテクチャーなので、Cのオブジェクトは目も当てられんものになるだろうことは容易に想像がつく。 -なんやかんやいって、結局アセンブラ。 --ゼロページ領域にmemcpyコードを展開しておいて --ポインタはIXしかないのでもう一つのポインタはABSアドレッシングのオペランドを直接インクリメントするのだ。 --memcpyはそれで良いけど、それ以外の関数をいちいち命令書き換えで実装するのは''絶対嫌や'' -MSP430F2013は、78KやHCS08よりもはるかにまともなRISCアーキだが、 -Flash2k、RAM128バイトとなっている。 -''ATtiny2313とおんなじ容量かよ。'' **結論として [#fb1b536d] -自分にはどのマイコンも、''1個100円のATtiny2313以下''のように見える。 --反論したいなら、LowSpeedでいいから、SoftwareUSBドライバーを書いて実証してくれ。 --クロック数的に言うと78Kはアウト。 --レジスタ数的に言うとHCS08もアウチ。 --というか、どっちもCコンパイラを使った瞬間に、ありえないコード量と遅さになるだろ。 --MSP430がギリギリ境界線だけど、2Kじゃあ厳しいねぇ・・・。 --ドライバーだけで2K使い切るだろうなぁ。 ---- *Debian(Etch i386)の[[VMイメージを作成:http://psp.dip.jp/web/cgi-bin/wifky/wifky.cgi?p=VMWarePlayer]]してウハウハ。 [#t4adf137] -VMWare Toolsまで入れてしまうと、時計はちゃんと合わせてくれるし、カーソル離せばウィンドウフォーカスも自動で変わってくれるので、だいぶ楽。 -X-Windowのスクリーンサイズも、VMWare窓のリサイズにあわせて自由に変わる。便利。 なのは良いけれど、一つ盲点があった。 -VMイメージを作ったときのマシンがAthlon64だったので、Pentium4のマシンだと''起動しねぇ!'' ~ SIZE(64){orz}。 ~ ~ ~ -i386汎用カーネルに差し替えたvmlinuzを入れてgrubで選択するしかない。 ---- *DELLのミニノート:Inspiron mini 9発表 [#nc81c162] http://pc.watch.impress.co.jp/docs/2008/0905/dell1.htm -英語キーボード、''キター'' -あともう半年もすれば、SSDはHDDに比べて圧倒的に速く快適になるはずだ。 -SATA2インターフェースで良いので、SSDを抜き差し可能なスロットに入れて欲しいような気がする。(昔のNEC98ノートのHDDみたいな感じで) -そうすると、Ubuntuの64ビット版にしたりXPに戻したりが楽だ。 -VMWareでも良いんだけれど、SSDの容量的に両方のOSを入れるのは(現時点では)無理。 -今のSDメモリーカードみたいなフラッシュメモリーインターフェースがSATA並みに速くなるのであれば、SDカードスロットだけ用意して、SSDレスであっても良いくらいだ。 -実際には、そうなることは難しい。なぜならインテルの高速SSDはインテリジェントな並列コントローラと、複数のFlashモジュールの組み合わせでやっと実現しているからだ。 それから、どうでもいいけどAtomの液晶サイズ縛りなんか意味ないんでやめて欲しい。 -図書館とかパブリックスペースに置かれるPCなんか、全部Atomにしてしまってもいいくらいだ。 -ついでに945の後継(低消費電力化)は絶対必要。 -mini 9のチップセットはDELLの英語サイトのTech Specsには、965PM/GM Express(GMA950)と書かれていたが、 これって945GMの間違いではないんだろうか?965だとGMA3000になるが、''さらに爆熱だ'' ---- *78Kのアセンブラって存在するの? [#p9386a8a] http://john.ccac.rwth-aachen.de:8000/as/ -探していたら、こんなサイトに辿り着いた。 -これって1本のアセンブラでアンティークな全CPUを網羅しているよね。 -SC/MPがあった。感激した。 -ソースの拡張子はCなんだけど、最初見たらPascalかと思った。 http://john.ccac.rwth-aachen.de:8000/alf/ -ドイツの人らしいです。 とある2chの会話より 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/ わろた。 ---- *DELLのミニノート:Inspiron mini 9 [#obb6be41] -ファンレスらしい。 -EeePCの爆熱っぷりを見ているので、低音やけどとか大丈夫? -なんか秘策があるのかな? とりあえず -英語キーが選べる。 -ファンレス~ ここまではOK。大変結構。でも~ -発熱具合ってどうなの? -カラーバリエーションはどうなったの? --英語モデルでは白のほうが高いんだけど・・・ -電池の持ちが期待したより普通。 インテルのSSD搭載モデルまで待つか・・・ ---- -DELLの日本語サイトに仕様詳細が出ていた。 -チップセットは945GSE Expressとなっている。 -ちなみに、Atomのチップセットはintelサイトによると |ネットブック | モバイル インテル 945GSE Express チップセット | |ネットトップ | インテル 945GC Express チップセット | ということになっている。 ---- *エレキジャックNo8を買ってしまった。 [#ude084d5] -78K、MSP430、HCS08、AVRとマイコンてんこ盛り -だけど作るものがない。 -しかたがない、ライターでも作るか。 とある2chの会話より。 40 名前:774ワット発電中さん 投稿日:2008/06/10(火) 00:33:42 ID:epyTo3qj PIC/AVRを始めることにした。まずはライタを作らないと。 ライタ作った。さて、何を作ろうか。 …作りたいモノがない!! しかし、何か作らねば…。 そうだ、新しいライタを作ろう。 ''↑丁度今ココ。'' -ちなみに、78Kはシリアル経由でWriteEZ3というツールから書き込み出来るらしい。 -HCS08を焼いたりデバッグしたりするツールUSBSPIDERは4200円くらいで売っている。 -MSP430を焼いたりデバッグしたりするツールez430−F2013は3500円で売っている。 -AVRはCHaNさんのシリアルライターで簡単に焼けると思う。(制作済) わざわざUSBSPIDERとかを買うまでもないし、買ってもたぶん(HCS08の)使い道がないわけで。 -やっぱり他のマイコンでHCS08かMSP430''焼き器を作るまでが遠足''だな。 -出来てしまったらすることが無くなる。 -で、出来上がったHCS08でAVRライターを書くとか・・・(人生無限ループだ) *DELLのミニノート:Inspiron mini 9 の別の可能性 [#f781fe31] -Linux(Ubuntu)搭載を前面に出したノートPCって、他にあったっけ? -これは、市場実験(ユーザーアンケート)のようなもので、 -モバイルデバイスに必ずしもWindowsが必要かどうかをユーザーに問うている。 ''Ubuntuでも十分に利用できると分かった時点でどうなるか予想してみよう。'' -Atomいらないじゃん。nVidiaのTegra(ARMとGPU統合チップ)でもUbuntuくらいは走る。(ちょっと遅いかもね) -だったら、バッテリーの持ちは劇的に伸びるし、爆熱の心配もない。 -もっと安く出来る。 -WindowsXPの供給も止まるので、好都合。 -今後糞Vistaに移行するくらいならUbuntuのほうが好いよね。 逆に、Ubuntuモデルが受け入れられない場合は、Tegraの線は無しってことで。 ---- *Intel、10chアクセスで高速化したSSDを出荷開始 [#l3e16548] http://pc.watch.impress.co.jp/docs/2008/0909/intel1.htm~ http://japanese.engadget.com/2008/09/09/ssd-x25-m-80gb-595/ -80GB。千個受注時の単価は65,760円。 主な仕様はほぼ共通で、容量が80GB、インターフェイスはSATA(3Gbps)、 サステインドリードが最大250MB/sec、サステインドライトが最大70MB/sec、 リードレイテンシは85μsec。消費電力はアクティブ時が0.15W、アイドル時が0.06W。 -''速っ。''(まあ、メモリーだからな。) -NetBook1台分より高いじゃん。 -こいつはむしろ、エンタープライズサーバー用だな。 -Oracleとか動かしている所は、喉から手が出るほど欲しかった速度だろう。 -HDDなら、1秒にせいぜい70回くらいしかランダムリード出来ないが、(秒速高々120回転なので) -SSDは、何千回でもOKだから。 フラッシュがMLCでこの値段なので、SLCだと倍額くらい? -160GBだと、VAIOノートが1台買えますな。 ---- *ARM吼える [#m2528034] http://pc.watch.impress.co.jp/docs/2008/0910/arm.htm -ARM、IntelによるAtom優位の主張に強く反論 -そりゃまあ、2次キャッシュOFFで計測されたら怒るのも当然だよな。 -AtomもARMもシングルスカラーならば同一クロックでほぼ同速度じゃあないかとは思っていた。 --CortexA8はin-order実行の2イシューなのでClassicPentium相当だ。 --まあAtomともよく似ていること。 --レジスタ数の多さで言うとARMのほうが速いと思うが、SSE周りはインテルのほうが何枚も上手だ。 --HyperThreadingの有無の違いはある。(つまりHT ONの状態ではAtom有利) -記事によると768MHzのCortexA8は1.6GのAtomより25%遅いらしい。(まあ用途によるだろうけど) -一番いいのは市場がすべてを決めることだ。 -まず、AtomはIPコアで提供されることはありえないので、今のAtomがARM市場に殴りこむことは不可能。 -そのまえにチップセットをなんとかしる。>インテル -繰り返すようだが、Atomの市場はWindowsXP搭載のNetBook限定なのだから、Ubuntuで十分な用途向けにはどんどんARM内蔵のNetBookを作ればよいだけだ。 -それが市場に受け入れられなかったなら(X86互換の)Atomが自動的に勝つ。 ---- *HIDasp高速化の可能性 [#t0c28c32] [[HIDasp高速化]] ---- *インドの少女、欧州での「ビッグバン実験」を恐れ自殺 [#r9dd8210] -http://jp.reuters.com/article/oddlyEnoughNews/idJPJAPAN-33702120080911 LHCで極小ブラックホール生成実験を行っても地球は消滅しない、CERN -http://www.afpbb.com/article/environment-science-it/science-technology/2514698/3302185 そもそもLHCでブラックホールが作れるなんていう「世間の注目を集める」ニュースを流すのが間違いだったのか。 -基本的にはHiggsを見つけるための実験施設なのだ。 -注目を集めて予算獲得しやすくする効果もあると思うけれど、物理学に詳しくない人たちを無意味に不安がらせるような宣伝もどうかと思う。 -深読みすると、それを知ったインドの天才少女が、本当に事故が起きる可能性を計算した結果自殺、だったら凄いけれど。 -あとね。CERNの施設の写真は、まるで波動砲の発射装置みたいで怖い感じがするんだけどね。たいていあの手の大げさな機器は(生成した素粒子の軌跡や熱量を測る)検出器なんだよね。 -だから、''怖くはないんだぉ。'' 面白いところでは、こんなニュースもあるし。 -[[LHCでゴードン・フリーマン博士目撃、不測の事態の可能性:http://japanese.engadget.com/2008/09/10/lhc-gordon-freeman-half-life/]] ---- *DirectXでプログラムを書いてみようかと。 [#z231e85d] 気の迷いからだが。~ で、 -いや、普通にOpenGLで書くようなことをDirectXで書くことが出来ないかという。 -そうすると、C++とかクラスとか難しいことを覚えなくて良いので。 -別にクラスを使うことは難しくないが、たとえば、Xファイルの読み込みが D3DXLoadMeshFromX("hoge.x" ...) で、描画が for(...) pMesh->DrawSubset( i ); -だなんて言われた日には、まるで「''おまえら何も分からんでいいからVisualBasicでも使ってろ''」と言われているのと同じだ。 じゃあ、自力でXファイルを読んで、DrawPrimitive()してみろと。 -というわけでXファイルの解析を始めたわけだが、 -なんかだめだめフォーマットなんだなこれが。 -特にXバイナリーなんて、元のテキストをトークン番号に置換しただけのテキスト並びのまんまじゃないか。 -しかもDirectX10ではXファイルが扱えなくなっているというし。 すなおにOpenGLで書いたほうがマシなのはわかっている(つもり) ---- ***いろいろ検索していたら2chに当たってしまった。 [#i4caf365] Xファイルを再生するスレ -http://pc11.2ch.net/test/read.cgi/gamedev/1006624202/ -何に困っているかというと、3Dモデルの適当なフォーマットが「存在しない」ことなのだ。 -モデリングソフト毎に独自のフォーマットが存在するが、それは(面倒なので)扱いきれない。 -割とポピュラーなフォーマットとしては --DXF(AutoCAD) --3DS(AutoDesk 3D Studio) --obj(WaveFront) --FBX(AutoDesk) --Collada(SCEA) --VRML / X3D (Web3D) --Xfile / SDKMesh (DirectX) -特定のモデラーを持っているならそれに近いものを使えば良いが、 -どのモデラーでもサポートされていそうなフォーマットというとかなり限定される。 で、 -XファイルはDirectXで最も知られたフォーマットなので、対応モデラーは多くて良いのだが、 -書けるくせに(Xファイルを)読めないモデラーが多いのがまた、困り者だ。 -そのくせ、(Xファイル以外での)適当な共通フォーマットがないんだな。 ---- *HIDデバイスのアクセス方法について誤解していた。 [#jdb3a2b8] -SIZE(8){また恥をかいてしまった。} -HIDデバイスというのは、単にディスクリプタのテーブルが拡張されただけのものかと思っていた。 -ところがReadFile()やWriteFile()で転送されるのは、生パケットではなく、レポートディスクリプタというやつらしい。 -転送サイズは9を指定するのだが、その9バイトバッファの先頭の1バイトはREPORT_IDに割り当てられていて、しかも0x00固定だ。 -実際に転送されているパケットは9バイトのうちの後ろ8バイトのようだ。 -これを長くすることが出来ないと、帯域を稼ぐこともできないっぽい・・・。 -なんかlibusbと全然違うんだな。 -HID.DLLにはベンダー独自リクエストを直接送信するような呼び出しはないのかな? -ReadFile() WriteFile()はブロックされるので、個別に制御するなら別スレッドにするという話だが、 -HIDというかUSBのパケットなのに、なんでもReadFile()関数に押し付けるのは強引だと思った。 参考URLはこのへん?~ すzのAVR研究 -http://suz-avr.sblo.jp/article/8636190.html Obtaining HID Reports / HidD_GetFeature -http://www.osronline.com/DDKx/intinput/hidclass_6xpj.htm ---- *avrspxがWindows2000上でHIDaspを認識してくれない件 [#bba02831] -avrspxのhidasp_init()内でハングすることが多い。 -testパケット(pingのようなエコーバックパケット)を4回送り、受信を行っているが、 -Windows2000上では、2つくらいしか返却されてこない。 -1回送り、1回受け取るように書くとOK. --これはsenshuさんのHIDspx.exeの実装で修正されている。 -WindowsXP上で同じことをすると、4パケットのうちの最初のパケットだけが欠落する。 --但しこの現象はHIDaspをUSBに接続した直後だけに発生する。 --SnoopyProでデバイスリセットを行った直後にも良く発生することが多い。 -Windows2000, WindowsXPの両方でSnoopyProを見ながらやってみたのだが、原因を掴むには至っていない。 -やりにくいのはHID Reportの送受信がReadFile() WriteFile()という Windowsのブロック関数でやらなければならない点だ。 -これは、rs232cの簡易ターミナルを書いたときも相当いらついた。 --非同期リード、ライトにしたければ、CreateFileでFILE_FLAG_OVERLAPモードオープンして、 --ReadFileの最後の引数にOVERLAPPED構造体を与えてやるとかしないといけない。 -あと、HID Reportがどのようなパケットなのか本質を理解していないのが問題。 --マウスならボタン情報、座標などが含まれるようなパケットらしい。 -SnoopyProで見るとインタラプト転送のように見える。 -Microsoftのドキュメントではコントロール転送でもいけるというふうな解説が書かれているので混乱している。 -もしも(LowSpeed)インタラプト転送なら、速度を望むことは絶望的だ。 ---- *HIDsphを研究しておくべきだった。 [#o06ba269] -ソースがかなり洗練されている。 -AVRUSBのAVR Bootloader HID がベースになっているようだ。 -HID Reportの送受には ReadFile()/WriteFile()ではなく HidD_GetFeature()/HidD_SetFeature()で行われている。 -やっぱり[[AVRUSB:http://www.obdev.at/products/avrusb/index.html]]で紹介されているリファレンス実装は一通り見ておくべきだと思った。どれもレベルが高い。 -ATmega88は秋月で@250円なので、もう2313にこだわらなくてもいいかなと。 ---- *HIDsphを実際に焼いてみた。 [#la187b2c] 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 は書き換えたつもり) ---- *[[HIDasp高速化]] [#mef74a41] ここ2日くらい、いろいろ試行錯誤してみた。 -HID Reportの送り方と受け取り方が分かった。 -全てコントロール転送(クラスリクエスト)で実行されているような気がする。 -ただし、まだよくわかっていないのが、Report IDの置き場所についてだ。 --コントロール転送のDOWNストリームデータ(つまり後続パケット)の先頭にあるのか、 --それとも、クラスリクエスト内にあるのかが掴みきれていない。 --デバイスからホストへのUPストリームにおいては間違いなく後続パケットの先頭バイトだと思う。 -それから、ディスクリプタに書かれたREPORT_COUNTの値と、USBの生パケットのサイズの対応も正しく把握しきれていない。あやふやなのだ。 --まあ、動いているからいいや、では駄目だ。 -HIDはドライバーインストールが不要なので、ユーザーに勧めやすい。 -オーバヘッドが多少増えるが、libusbでコントロール転送の生パケットをコーディングするよりもある意味楽かもしれない。 -ふつうのHIDクラス(KB、マウス、JOY等)を書いてみようという気になったのも収穫の一つ。 ATtiny2313の2kB内でも、思ったよりいろいろ詰め込めそうだ。 ---- *ATtiny2313のUSI(SPI) [#fda3d391] -ATMELのPDFを読む。 アセンブリ言語プログラム例 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()は、8ビットの転送に16回ループを回るのだ。 -しかも1バイトの書き込みにはusi_trans()を4回呼ばなければならない。 --(シリアルプログラミングのSPIコマンドはすべて4バイト単位) - -AVR書き込み時に与えるSCKのLOW区間、HIGH区間はCPU CLOCKの3クロック時間より長くなければならない(12MHz以上動作のとき) -これを満たすためには、(仮にLOW=4CLK、HIGH=4CLKとすると)12MHzのAVRを焼くためにはSCKは1.5MHz以下でないとだめという感じかな。 -ということは、上記のループ展開したようなSPI転送だと6MHzになるので速すぎる。 -delay()を外した状態のusi_trans()のgccコードが丁度上記の最初のコード例になるので、 12MHzのAVRを焼く場合の限界速ということになりそうだ。 -この頃はATmega88の20MHz基板を焼いているので、なんとか間に合っているようだ。 --焼いているというのが、単に''焼き速度のベンチマーク''をしているだけ、というところがむなしいけど。 ---- *USBの接続変更 [#y4528e80] -USBのD+をPD3 -USBのD−をPD4 -に接続するのが流行りらしい。 -とりあえず、ターゲットボードの配線だけは変えた。 -usbdrv/を最新と取り替えて、usbconfig.hもPD3,4に合わせた。 -しかし、コードサイズがあっというまに100バイト以上溢れ返ってしまった。 ~ SIZE(24){何故?} ~ わっかりーませーーん。降参です。 *はっはっはっ分かってしまえば簡単だ。 [#efed7640] #define USB_CFG_HAVE_INTRIN_ENDPOINT 1 こいつが1になっていただけだった。これで100バイトくらい増える。 -どうやって調べたかって?そりゃ、双方の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 -↑今ここ。 -これで、流行に乗り遅れないぞっと。 ちなみに、HID Reportの取得や書き込みは全てコントロール転送で完結しているっぽいので (SnoopyProで見ただけだけど)クソ遅いインタラプト転送なんて、使わないぞっと。 *HIDasp高速化改良(方法論のみ) [#a2afdeca] -HIDspx−srcに含まれているhidasp.c には、HID Reportのパケットをダンプするデバッグ機能がついている。 #define PKTDUMP 0 // HID Reportパケットをダンプする. これを 1 にして作成したEXEで書き込み&ベリファイを行うと、どのようなHIDパケットが飛び交ったかがコンソールに表示される。 -次に、これをOFFにしておいて、[[SnoopyPro:http://sourceforge.net/projects/usbsnoop/]]でUSBパケットをキャプチャーする。 -HIDspx.exeで同じように書き込み&ベリファイを行ってみる。 -SnoopyProのログにはそのパケットが送られた時間が記録される。1mSが1フレームと考える。 -そして、avrspxのソースを見ながら、どのようなことが起こっているのかを想像すればよい。 速くしようと思えば、無駄なパケットを減らすことと、HID Reportを64バイトにまで拡張することと、usbFunctionWrite()に8バイト来た時点で行動を起こすことだ。 -usbFunctionWrite()では、8バイト単位で処理を行い、SPI経由でデータを送ってしまうことが出来るので、ReportBufは長く取る必要がない。最初に来た8バイトのヘッダー部分だけ覚えておけばいいはずだ。 -アドレスセットとページライト、書き込みまでをその長いパケットに全部含めてしまえばさらに無駄は減るが、ちょっとやりすぎかもしれない。 -また、読み込みも速くしたければ、ページリードのコマンドは省略してしまい、長いHID Reportの要求が来たら、さっさと固定長でページリードを行なってしまえばよい。端数に関してだけ、従来どおりページリードコマンドでサイズを指定して転送してもらうようにする。 -これも8バイト単位で並列処理させると良いかもしれない。 -ページリード以外のコマンドは結果が7バイトで足りるので、長いReport要求を出すことはないはず。 書き込みターゲットのクロックが遅い場合はどのみち速くすることは出来ないので、高速化の対象は8MHz以上で動作しているAVRチップに限定すれば、上記のような戦略が有効だと思う。 -しかし、上記の手法はやややりすぎの感もある。 -手持ちのmega88に5秒程度で書き込み&ベリファイが出来るのならそれで充分だし -tiny2313に書いていた頃は、昔のままでも遅いと思ったことはなかったのだから。 *パソコン起動不可->復旧完了。 [#p4857df6] -今朝からパソコンが起動しなくなった。 -立ち上げるといきなりリセット。 -もう1回たちあげて、1分くらい作業したらまた勝手にリセット。 -ついに立ち上がらなくなった。メッセージは C:\WINDOWS\SYSTEM32\CONFIG\SYSTEMが壊れているか読めません。 インストールCDを入れて立ち上げてRを押してください。 みたいなやつ。 -最初はメモリーを疑った。MEMTEST86に掛けたが7周しても問題なし。 -次にHDDを疑った。幸い容量UPの交換前HDDが残っていたのでそちらで立ち上げて CHKDISKは無問題。 -やっぱりCONFIG/SYSTEMの問題かと思って、正常起動するほうのSYSTEM(システムレジストリファイル) を上書きしてみたら、こんどは起動するがログイン画面に来ない。 -はたと思いついて、Windows/repair/SYSTEM という、インストール直後に作成されるシステムレジストリファイルのバックアップを上書きしてみると、幸運にもOSが起動するようになった。 -但し、起動直後は、まるでインストール直後のような、ドライバー初期状態だったので、適当にドライバーを入れて対処。 -ユーザーレジストリは無事だったようだ。完全に復旧。 一件落着。 -Windows98時代は、このようなトラブルが日常だったので、C:ドライブにはOSのみを入れるという癖がついている。 -さらに、OSのパーティションを3つ同じ容量で切って、Windows98の安定した状態のC:のコピーを3個持って運用していた。 -ブート切り替えはChaNさん作のMBMというブートローダーだ。 -これはパーティションの細かな設定やパーティションコピー、ドライブ間コピーなどができる頼もしい奴。 -もっとも、今ではそのような用途に特化したLiveCD Linuxがいくつか存在するようだ。 こういうことが年に1回くらいはあるので、OSの起動パーティションは常に3つ切っていて、レスキュー用の仮OSはいつでもインストール可能状態にしている。 -(もちろんKnoppixとかでも最近はNTFSをマウントして書き込みまで出来るのだが、壊れたWindowsの障害状況を見たり、ファイルを比較したりといったことまでやるなら、そっくり同じOSを別パーティションに入れるにこしたことはない。) *HIDasp:時には諦めも肝心? [#l321b1b1] -例のusbFunctionRead()に引っ掛けて8バイトづつちまちま転送したらどうなるかテスト. -HID Report長はついに126バイト。(SnoopyProで確認したから間違いない) 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 -8kB全読みはSPI転送を端折ると0.8秒で終わる(USB転送だけだ。つまり10kB/Sはちゃんと出ている) -delay()ループを削除した状態で、上記1.7秒。 -delayループを入れて'-d0'では2.4秒。(つまり、8バイト単位でインターリーブしたほうが却って遅いという不本意な結果) -とするとspi_trans()が入るだけで(ホストから見て)1フレーム後回しにされる遅延になる。 -spi_trans()がやや遅いと2フレーム後回しにされる遅延になる。 -ここらへんがソフト処理USBの限界だ。 -プロトコルエンジンが後付けになっているようなPIC18F2550とかNEC78KではUSB転送はバックグラウンド的に実行されて共有RAMにパケットが残る仕組みなので、かなわない。 -というかLowSpeedの限界を見たような気もする。 -いろいろ考えたが解法は無い。SPIクロックをタイマー0から与えるようにしてクロックを上げる(?) -現状12MHz/4Cycle/2(2回叩いて1SCL)=1.5MHzのSPIクロックなので、これを2MHz(8MHzCPU焼きの上限いっぱい)まで上げれば・・・たいして変わらない? -ここまで来るとパズルだな。SPI転送を割り込み駆動にしてバックグラウンド処理すれば良さそうに見えるけど、実はusbFunctionRead()は遅延実行できない関数なので、やるなら1パケット先読みで先回りするしかないだろう。書くほうは先読みの必要はないし(データが来るまで)出来ないから遅延実行するようにして即時復帰だ。 -そういった処理を書きたいならmega88を使うしかない。Readのインターリーブを実装しただけで2kBを使い尽くしてLED,MONITORを外すことまでやった。 と、まあいろいろ考えたけれどここらが2kの限界点だ。 ---- *Write&Verify:4秒切りました。 [#jde93f52] 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全部取っ払いで、こんな感じです。 -変な(?)モニターコマンドとLEDコマンドの両方を入れると、コードが2バイト溢れます。 --配線をINT0に戻せば2048といった感じですが、変なモニターのほうは需要がなさそう なので、外しておきます。 -d0は最速なのでよいとして、d1〜d5とd6以降の件は、ホスト側のhidasp.cにテーブルを持たせますかね。 REPORT_ID=6(46)は、現在使用していない(バッファが40バイトしか確保していない)ので削除すると 9バイト空きます。 ---- *USBaspの実装を見てみることにした。 [#wdf0315a] -ATtiny2313しか持ってなかったころ(ATmegaは秋月で取り扱っていなくて、他社だと高価だった)はATmegaを使用したライターには全く興味がなかった。 -しかし、速度向上をやるにつれて、他のAVRUSB利用のライターがどのくらいの性能なのか知りたくなった。 -USBaspのページを見ると、 Programming speed is up to 5kBytes/sec. SCK option to support targets with low clock speed (< 1,5MHz). こんな感じ。 -firmwareのソースを見る。 -普通にlibusbでやっていて、コントロール転送のみ、エンドポイント無し。 -usbFunctionRead,Writeは存在する。8バイト単位でisp転送を処理。 -''まるでHIDaspと変わらない。HIDデバイスであるかどうかだけ。'' -SCLKは375kHz(ターゲット1.5MHz以上の場合) -もしくは8KHz(SLOW MODE) ''なのに5kB/S!!!'' 考察: -USBの1フレーム(1mS)に8バイトのLowSpeedパケットは最大で6個くらい詰め込める。(バルク転送でOHCIの場合) -ということは正味転送時間は160μS/8バイト程度 -残りの時間は840μS空く。(もちろんそのバス帯域を皆でシェアするわけだが) -で、375KHzのusi_trans()(SPI転送)を32回(8バイトのHEXを書きこむ場合の回数)呼ぶ時間を計算すると、 ((1/375000) * 8 ) * 32 = 682 μS 時間、足りてるじゃん。 -libusbだとうまくいくのかな?。 ファームウェアのコードサイズは3.5kBだ。 -AVRのコードはポインタ渡しが多いと長くなる。 --これはポインタに使用できるレジスタがx,y,zしかないので、レジスタ退避のpush,popがばかにならない数入るから。 -渡す必要のない決め撃ちバッファばかりの場合は引数なし関数にして参照しまくれば短くなる。 -そうでなければ、バッファは共通にしてバイトオフセットを渡すとか工夫するとやや短くなる(ソースは汚い) -昔の6502のabs,xではabsが渡せないので、そういった感じになっていた。 ---- *コントロール転送:訳分からなくなった。 [#o604ba8c] -AVRtermを少し改造。usbFunctionReadを使うようにして、1回呼ばれるごとに遅延を入れた。 -遅延ループは 60番地に定数を置いている。値1が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の遅延でも大きく響いている。(平均して2フレームも遅れる) -しかし、USBaspは680uSの遅延があるはずなのにまったくスループットに影響を与えないのは''何故か?'' これが解けたら良いんだけどなぁ。USBasp作るかなぁ・・・。 -ところがこんどは、USBハブを外して、パケットを64バイトで調べると、傾向が変わった。 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. -あ、しまった、最後の10は16進だった。 -USBハブはオーバーヘッドを持っている??? -この解析、何が複雑かっていうとOHCIなのにハブを持たせてあるところ。 -UHCIでサンプルを取ってみないと、正しい評価ができないかも。 -まあしかし、200uSの遅延があっても5kB/Sは出ている。(これもOHCI特有の現象かもしれない) ToDo: -UHCIでの傾向を調べる。 -上記はベンダリクエストでやっているので、これをクラスリクエストに変更して試す。(libusbはそのまま) -HID.DLLのアクセスに変えて試す。 それでも分からなかったらUSBaspを作るしか。 ---- *UHCI(インテル互換USBホスト)での傾向を手に入れた [#a1c77d35] -石はインテル純正i815(鱈セレVAIOノート) -ハブ無し直結 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. ''うぉーUHCIすげーーーー'' -噂は本当だった。 -ほんとに600μSまで時間消費しても常に5kB/Sだ! 高々、鱈セレの900MHzなのに感動した。 ---- *HIDaspの高速化は一段落 [#kd431081] -[[HIDasp高速化]]に、いろいろ記述。 -とりあえず、標高2048(山頂)に到達したので終了。 -インターリーブの方向は諦めて、現行のコードにTIMER0 SPI CLOCKを実装しようとしているが、なかなかうまくいかない。 -適当なサンプルもない。USBaspのmega88とはSPI周りのポートがかなり違っている? -頭を冷やすしか。 ---- *Glibに興味。 [#qc750e12] -C++でなく、Cでいろいろやろうとすると、いろいろなコンテナをその場限りでチープに作っては壊し、スクラップ&ビルドで時間の無駄が多い。 -Glibというライブラリがあって、STLのようなコンテナっぽいやつとか、スレッド周りとか便利関数がいっぱい詰まっている。 -これが使いこなせればいいな。 -WindowsとLinuxで共通の書き方が出来るらしい。 -元々はGtkのライブラリだそうだ。 -STLが全然読めないので、こっちに逃避。 ここの通りにやってみたら、ちゃんとMinGWでglibが使えるようになった。 -http://alohakun.blog7.fc2.com/blog-entry-587.html -このライブラリはLinuxでもほぼ同様に使えるので便利。 -ただし、微妙に libglib-2.0-0.dllみたいなDLLが必要になるのがちょっと痛い。 -LinuxではDLL不要(え?) .soだよね。 ---- *HIDasp:そろそろやることがなくなってきた。 [#c3678437] -ので、パケット最適化をやろうと思う。 -page_writeのset_address後は常にpage_writeなので、これをフュージョンする。 -page_write後のisp_commandもフュージョンしてみる。 -page_readはそれほど無駄がないのでそのまま。 -あと、HIDのパケット長ももうすこし整理してみる? -いよいよメモリー残量が尽きた。 -結果は[[HIDasp高速化]]と、[[HIDasp速度比較]]。 多少速くなったとぬか喜びしたところ、UHCIマザーで試すと全然速くない。 -振り出しに戻る。 ---- *HIDasp:積み残し作業について [#o4b87cbf] 結局振り出しに戻ってしまった。 -ベンチマークHIDmon専用のファームを開発する。 -usbFunctionWrite()に遅延ループを入れて、遅延を制御しながら、長いHID Reportの転送をベンチする。 -UHCIとOHCIでの傾向を調べる。 -libusbならUSBasp相当(5k/秒)の速度が出るはず(予想) -しかし、今回はHIDで試みる ---- *ネットブックが、あんなに安い理由 [#k201a9b5] 笠原一輝のユビキタス情報局 -http://pc.watch.impress.co.jp/docs/2008/0926/ubiq228.htm -そうか945GSEは$20なのか。 -SCHより$5も安いのに性能が断然上だから。 -SCH搭載モデルが出てこないのはなぜ? -と思っていたら、デザインガイドはインテルなんだな。 -つまり設計料もタダでやってる商売か。 -だから、似たような構成で各社出してる。 -SCHはPATAだけのようだ。SATAは繋がらないがPCI−EXPRESS×1がある。 -もういまどきPATAはないだろう。PCI−EXPRESS経由でSSDだ。 -どうやらメモリーが1Gまで(最近になってようやく2G)なので敬遠されている? しかしまあ、液晶込みで$300で作れているのは凄いの一言だ。 -PS3よりローコストなのに高性能。(RSXとBDドライブ除く) ---- #contents
テキスト整形のルールを表示する
ログインまたはアカウント作成