2010-06

2010-05←　→ ＡＶＲ／ＰＩＣ両用ライター　 usbシリアル変換　 usbキーボード　簡易ロジアナ、赤外線リモコン信号観測

６月：†

↑

先月のまとめ†

~~ＳＨ−２Ａでなんかする。~~ --- 何もしなかった。
NXP LPC2388基板でなんかする。 ---何もしなかった。

今月の寝言目標

JTAGケーブル(ライター)に挑戦。（予定）
OpenOCDを使ってみる。

寝言は寝てから言おう。

６月：

先月のまとめ
USB-Blaster互換18F2550が気のせいか動いている何故？
iSlate（改名iPad）
またiSlateネタ。こんどはAsus
Googleが新入社員にWindowsの使用を禁止
Adobe Flashはもういらない
GCC開発者ら、GCCの開発にC++を導入することを決定、利用する機能を制限して複雑さを軽減
SoftBankでJavaScript脆弱性、影響する端末は100種類以上に
インターフェース付録ARM基板でArduino
Teensyの人が面白いことをやっている。
アドビ公認、Flash広告をHTML5に変換してiPhoneに配信する技術
面白ニュース【iPhone 3G のダメダメなところまとめ】
LZH終了のお知らせ。
スイッチサイエンスさんしっかりして。
iPadはとても残念なプロダクト
アメリカの国防費の見直しを求める作業部会は今後１０年間で１兆ドル（約９２兆円）規模の削減を目指す提言書を発表。
MIPSは死んだ枯れてしまったアーキテクチャー
【ESEC 2010】Androidが遅い！
DDR3対応ATOM
Nintendo (3DS) CTR基板
神の粒子
OpenOCDとは何なのか？
LPCXpressoを手に入れた。
USB-Blaster互換（じゃなくてもどき）18F14K50製作中なう。
USB-Blaster互換（じゃなくてもどき）18F14K50いきなり座礁中
CQ-STARM32でVersaloon
USB-Blasterとは何なのか？
Mac Mini Mid 2010 Teardown
HTML5:これは凄い。JavaScriptでレイトレーシングまで。
HTML5:ブラウザー上でのProcessing(Proce55ing)
OpenOCD:この分かりにくさは何なんだろう。
メモ:Linuxカーネルうおっち
WIRED:「アプリの時代」と、Intel社のネットブック戦略
2SC1815:ついにディスコンか？
Intel、Android（froyo）をx86アーキテクチャに移植
OpenOCD:全く実用にならない奴
OpenOCD:全く動いていないわけではない
OpenOCDダメダメ説
- やっぱりftdi_write_data()は何もバッファリングされずに、usb_bulk_write()直結だった。

↑

USB-Blaster互換18F2550が気のせいか動いている何故？†

この一番左側のPIC18F2550基板に20PINのピンヘッダー（メス）を追加しただけという、非常にやる気のないJTAGアダプターを昔こさえていた。（つまり基板同志をピンヘッダーで接続して終わり。JTAGケーブルすら作る気ないやる気なさ）
参考サイトはこちら。
ファームはソフトウェアSPIモードで、さらにARMのJTAG応答が遅いのでウェイトをたんまり入れている。

ほんとは完全に規格外なんだけれど18F2550を3.3V動作させて、無駄な抵抗一切無しにLatticXP2に繋いでコンフィギュレーション出来たところまでは確認していた。
ところが、LPC2388基板に繋いだときだけJTAG認識が非常に不安定でJTAGアダプタとして使用できなかった。

ほんの気まぐれで、今日試してみたら普通にARMをJTAG認識できる。
なんで？
どうして気まぐれに試したかと言うと、PINヘッダーの芋ハンダに気づいたからなんだ。
でも、芋ハンダしていたPINはJTAGのRESET信号で、USB-Blasterでは未配線(未使用)信号なんだけど。
もしかしたら芋ハンダのせいではなくて、ARM側のFlash内容が変わったせい？ARMのJTAGは良く分からない。
USB-Blaster(もどき)がARMに繋がるんならJTAG Key clone作らなくて済むかな。

ラッキーなのかアンラッキーなのか良く分からない。

次作るときはせめて保護抵抗をTDIとかTDOに入れておくことにしよう。（今は入れていないので最悪FPGAやARMを飛ばす可能性がある）

えーっと、書きにくいんだけど

USB-Blaster(もどき)がNXPターゲットのJTAG認識不安定だった原因はどうやら電源のようだ。
NXP基板に5Vを供給しない場合にJTAG認識がたまにしかできない状況を再現出来た。
NXP基板ではJTAGライター側から3.3Vを供給して動作させてはいけないらしい。（普通そうだよね）
LatticeXP2基板ではJTAGライター側から3.3Vを供給してコンフィギュレーションとＬチカ出来たんだけど。

↑

iSlate（改名iPad）†

自分は買わないけれど、見せびらかすヤツ多すぎ。

見て気になったこと。（べっ、別にヒガミじゃないからねっ！）

NetBookより縦長い。(1024x600 → 768x1024)
片手で持って片手で操作すると、落としやすい。→落とすと壊れる→アップルまた儲かる。→アップルウマー。
画面が広すぎてドラッグドロップしにくい。というか指が磨り減りそう。
キーボードが付いてない。というか別売り？高い。→アップルまた儲かる。→アップルウマー。
NetBook（のMac版)は作らないとか言ってたくせに、CPUを劣化(Atom->ARM)させてキーボードも取り外したくせにNetBookより高く売るって・・・阿漕な商売だ。（そもそもiPod Touchの液晶をでかくしただけやないけ。）

電子ブロックアプリと、オシロ・ロジアナアプリ（プローブ付き）があったら自分もたぶん買ってたと思います。（そんなもんないけど）オシロ・ロジアナアプリは外部にワイヤレスプローブの形で実現できるかも。でも液晶落としそうなので嫌。

電子ブロックアプリ？？？Spiceか何かでエミュレーションするの？

↑

またiSlateネタ。こんどはAsus†

http://japanese.engadget.com/2010/05/31/asus-eee-pad-core-2-duo-windows-7-10/

intel税とMicrosoft税が入って、性能比でたぶん３倍以上開きがあるはずなのに価格は一緒ぐらい。
Asusが安すぎるのか、はたまた、Appleがぼったくりすぎているのか・・・。
- A4プロセッサの原価は高々17ドルなんだな。ということはAtomの$60とか$74はモバイルPDA用途としては高すぎだな。

中国製のiPadもどき(中身はAndroid)だと1〜2万円というところなのでやっぱりAppleが高すぎ確定。
iPadもどきは液晶が小さかったり筐体がプラなので比較しちゃあいけないか。

↑

Googleが新入社員にWindowsの使用を禁止†

今年の新入社員から、AppleのMacまたはLinuxをオペレーティングシステムとするPCのどちらかを使わなければならない

http://jp.techcrunch.com/archives/20100531google-windows/
Windowsは駄目なのに、MacOSはいいのか？
つまり、Windowsにはまだまだ見えないセキュリティホールが多数存在しており、攻撃対象になってしまうということなのかな。
それほどまでに中華(など)からの攻撃問題は深刻なのだろう。
逆にChrome OSが仕事に使えるとは到底思えないが・・・。端末として使うにしても。

↑

Adobe Flashはもういらない†

FlashをHTML5に自動変換するSmokescreen、iPadでも動作

http://japanese.engadget.com/2010/05/31/flash-html5-smokescreen-ipad/

デモサイト

http://smokescreen.us/demo/

こうも簡単に（実際簡単ではなかったと思うが）js(HTML5のcanvas)で動いてしまうと、今までのAdobe Flashって、なんだったんだろうと思ってしまう。

Flashはもういらない。Jobsは正しかった。

参考になる：FlashとHTML5比較

http://clockmaker.jp/blog/2010/02/flash-vs-html5/
Flashの場合プラグインがネィティブなんだよねー。
だからWindowsやMac用には用意されても、今流行りのPDA系OSには用意される保証はない。
あと、描画もソフトレンダーなのではないかな。

↑

GCC開発者ら、GCCの開発にC++を導入することを決定、利用する機能を制限して複雑さを軽減†

http://sourceforge.jp/magazine/10/06/02/0331255
意味わかんない。
Ｃ＋＋にするというのは、今の拡張子.c を.cppに置換すること？
そうするとさまざまなコンパイルエラーが出るし、特にtype castで怒られまくること必至。
まさか、.cと.cppの混在ソースにするっていうんじゃないよね。それ最悪。（って、ときどきやるけどね）

たぶん思うにllvmとの共通項を増やそうとしてるんだな。片方の成果を片方が取り込むことができる。

ライセンス上の問題が多発しそうだけど。
gccの弱点はコンパイル速度が遅いことなんだけど、Ｃ＋＋化するとさらに遅くなるよ。STLとか使うとどんどん遅くなる。
まあ、Ｃ＋＋コンパイラなのにＣ＋＋で書いていないという今の状況も不自然といえばそうなんだけど。
ポーティングするときに、これまではＣコンパイラだけ動作すればＯＫだったものが、Ｃ＋＋とＳＴＬまでちゃんと動かないとポーティングできなくなるのだな。

SoftBankでJavaScript脆弱性、影響する端末は100種類以上に†

http://blog.bari-ikutsu.com/entry/20100529_3660.html
ケータイのくせに、知らん間にAjax対応されていたらしい。
で、JavaScriptからHttpHeaderを書き換えることが出来ると、かんたんログイン（パスワード認証せずに端末固有番号だけで認証）でのなりすましが可能になるらしい。
自分の場合は・・・Sharpなんだけど、ホワイトプランなので、パケット通信は殆ど全く使用していない。（緊急時のみ）
そろそろキャリア乗り換え予定を立てるべきか。（SBの場合は２年単位でない契約解除は違約金をたんまり取られる）

↑

インターフェース付録ARM基板でArduino†

NXP基板をArduinoでコントロールしようとしている人発見

http://www.nicozon.net/watch/sm9437224
コンパイラが何なのか気になる
- Cygwin gcc
- WinARM
- CodeSourceeryG++Lite

あと、ブートローダーをどうしてるかだな。

Keilか何かのアップローダーはGUIオンリーだったはずなので
ChaNさんのlpcsp使ったか、
あるいは自作(avrdudeもどき)か。

USBコネクタの結線がCP2102側なのでNXPのシリアルローダーしか使えないはず。

Arduinoみたいな無料お手軽スケッチ環境は賛成。

だけど、AVRみたいに基板側はだれでも作れる、というわけにはいかない。
ＣＱ付録基板(NXP,STM32)は安いけれど雑誌買ってない人は入手困難なので・・・。
そうすると適当な（格安で入手が楽な）ARM基板を選ぶ必要があるし、ライブラリ揃える必要があるし。

でも、

どうせならデバッガ(OpenOCD,Eclipse,...)も欲しいとか、
USBも使いたいとか、
RTOSくらい乗っけてよとか、
収拾が付かなくなることは間違いない。

ＡＲＭだし。

AVRのmega168あたりだと、いろいろ諦めがつくので割り切ったツールで済ませられるというのはある。

↑

Teensyの人が面白いことをやっている。†

USBハブだけで作るＡＶＲライター。

http://www.pjrc.com/hub_isp/
74HC00が要るんだけど。
この発想は無かったなぁ・・・
４ポートHUBでないとだめ。
ミリ秒単位でしかコントロールできないらしい。
ケーブルが４本も要る（切断するかコネクタ４個用意する必要がある）のはどうかと・・・。

まあ、発想だけは柔軟に持ちたいものだ。

↑

アドビ公認、Flash広告をHTML5に変換してiPhoneに配信する技術†

http://japanese.engadget.com/2010/06/09/flash-html5-iphone-ipad/

しかし、一方では、こんな非互換問題も発生

http://builder.japan.zdnet.com/sp/snow-leopard-09/story/0,3800100196,20414715,00.htm

AppleサイトのHTML5はSafariでしか表示できない。
Safari偽装したFirefoxでも表示に問題が出るらしい。

HTML5って、標準技術ではなかったのか。

ないとしたら、現状のJavaScriptと状況は全然変わらない・・・。

スラド

http://slashdot.jp/article.pl?sid=10/06/08/0152215

↑

面白ニュース【iPhone 3G のダメダメなところまとめ】†

もしApple製品iP*が欲しくなってしまったら、以下を読むべし。

http://www.omoshiro-news.net/memo/iPhone3G.html
これで無駄な散財を避けることが可能。

宗教上の理由(Microsoftの社員、または、googleの社員、またはGNU真理教)でApple製品を購入することが出来ない人たちもいるようだ。

自分もその一人（うそ、金欠病だから）

Ｑ．iPhone は、FLASH や JAVA が含まれている WEB サイトは見れますか？
Ａ．見れません。

追記→　アップルがiPhoneをFLASH対応にしないのは、
　　　　　　FLASH対応すると、FLASH単独でアプリが作成できてしまい、
　　　　　　アップルストアを通してアプリを売らなくても良くなってしまうからだそうです。
　　　　　　アップルがアプリ販売で儲けられなくなるからずっとFLASHには
　　　　　　対応しない方針みたいですね。

しかし、これもFlashアプリをHTML5に変換するツールが出てきている今となっては防ぎようがない。
なので、いずれFLASHはenableになるのではないか。
あるいはHTML5自体をApple管理下サイトのみenableにするか。

Ｑ．iPhone でＸＸＸＸできますか？
Ａ．出来ません。
    ただし、JailBreakを使って、XXXXというアプリを・・・

これは明らかに違反行為。蓮紡さんのマジコン使い方教えて発言と同じくらいヤバイレベル。
なので、出来ません、以降は不要。

JailBreakはいずれAppleが穴を塞いだ瞬間から使用不可になる運命。

それから、分かっちゃったんだけど、iP*のメールって、IMAPなんだププー（笑）。
そりゃ、トラフィック多いだろうし、１５分おきに設定されていて当然だよね。
携帯電話の着呼の仕組みを使ってやっとメール着信信号だけは受け取れるようになったけど内容は受け取れないのね。ププー。
そんな仕組みじゃあパケ代たまったもんじゃないよ。
あと、へぼいTwitterクライアントとかも（ＰＣでも）トラフィック負荷が凄いという話聞くので
iP*でつぶやく人たちはパケ代で死亡確定だな。

↑

LZH終了のお知らせ。†

元々終了していたと思っていたが、駄目押しがきた。
vectorから、LZH形式のアーカイブは暫く登録お断りだそうだ。
例のunlha32.dllメンテ終了のお知らせにより、セキュリティホールの問題のほかに、
ウィルスソフトがlzh内をスキャン出来ない（ことがある）というのが理由のようだ。

なんだかなー

だったら、pmaとかで圧縮しておいたらウィルスを温存出来る？わけないか。

↑

スイッチサイエンスさんしっかりして。†

JapaninoのFuseビットがＲＣ発振モードだった件。

http://otonanokagaku.net/japanino/faq/#q30
http://d.hatena.ne.jp/OGURAM/20100609
一応８ＭＨｚのクリスタルは実装されているらしい。
なのにFuseはＲＣ発振だったらしい。
ＡＶＲライターが要るんだけど→FT232RLじゃないのでbitbang出来ません。
クリスタルが１２Ｍとか１６Ｍだったら気づいたんだろうけれど、
何で８ＭＨｚなんだろう。５Ｖ動作させるんだったら低電圧品である必要無いような・・・。

学研マイコン　Japanino ジャパニーノで遊ぶスレ 2

http://science6.2ch.net/test/read.cgi/denki/1275239328/l50

↑

iPadはとても残念なプロダクト†

http://blog.livedoor.jp/kazu_fujisawa/archives/51709027.html

iTunesがイントールされたPCがないとびくりとも動かない

おう、そりゃひどいな。
Jobsは公然と嘘をついていたのだ

「Windowsパソコンはトラック」：ジョブズ氏インタビュー

http://wiredvision.jp/news/201006/2010060320.html

「Windowsパソコンはトラックのようなものだ」とJobs氏は述べた。
農業が盛んだった昔はそういう車が大多数を占めていたが、今では
特定のニーズを持った人々に使われるだけで、市場のわずかな割合
を占めるだけになったというのだ。

嘘つけ。その「トラック」を持ってない人は全員iPadを使えないようにしてあるじゃないか。
iPod/iPhone/iPadのいずれも、iTunesミュージックストアとのコネクションは母艦であるWindows マシンやMacの存在を前提としていて、昔のPalmPDAと同じように、ホストＰＣにsyncする構造だ。

↑

アメリカの国防費の見直しを求める作業部会は今後１０年間で１兆ドル（約９２兆円）規模の削減を目指す提言書を発表。†

http://blog.goo.ne.jp/2005tora/e/319c9fb9c078b3308e72d26d81f632ce
近いうちに沖縄引き払うの分かってたなら、鳩山さん辞めることなかったのにね・・・。
やっぱりあれだよ、兵器は全部無人化（と小型化、インテリジェント化）するんだ。
そしてスカイネット法案可決・・・やばいな。

核兵器廃絶も大事なことだけれど、ロボットを兵器に使わない（使わせない）ようにすることのほうが重要になってくるんじゃないかな。

↑

MIPSは死んだ枯れてしまったアーキテクチャー†

libgmpのソースを読んでいて最近気づいた。
なので、これを採用しているMicroChipの将来は駄目っぽい気が思いっきりした。
ARMと比べて、コード効率が悪すぎる。
Carryフラグを持たないため、多倍長演算が出来ないか出来ても非効率。
Androidなんかを移植する価値はないと思っている。

根は素直だし、コプロセッサは繋ぎやすいのに。

せめてadc命令とsbc命令さえ追加されればだいぶ改善するのに。
命令セットを拡張したり標準規格をメンテナンスするリーダーシップ企業がいないとこうなるのか。

↑

【ESEC 2010】Androidが遅い！†

高速化に挑戦する取り組みに注目

http://eetimes.jp/news/3933
Dalvik VMって、こないだJITに対応したって言ってなかったっけ？（しかも省メモリーで）

ARMに決め撃ちするんだったらVMの仕様をARMっぽいものにすりかえればいいと思うけれど
さすがにそれはあれでなにだな。（x86もあるしな）

ARMのJazelleは使えないのかな（あれはJava VMだけど）
もうCortex-A8などには実装されてないの？

↑

DDR3対応ATOM†

やや古いニュース

http://northwood.blog60.fc2.com/blog-entry-3875.html

このうちネットブック向けのAtom N455とN475については既に出荷されている。
一方のデスクトップ向けのAtom D525とD425は6月21日より利用可能となる。

なのに全然話題にも上らない。（採用ノートブック製品のニュースもない）
intelはまたD525純正マザー出すんだろうな。
DDR2がDDR3になる以外、ほとんど違わないし。
N550に至っては、1.5GHzにクロックダウンされているし。

世間の話題はiPad一色。

NetBookも終わったのか。

影の声）WindowsXPモデルなら、まだ魅力あったんだけどな。

Windows7でメモリー１ＧＢが上限というのは、まるっきりユーザー舐めてるとしか思えない。

↑

Nintendo (3DS) CTR基板†

http://www.siliconera.com/2010/06/06/rumour-3ds-codenamed-nintendo-ctr-not-reliant-on-nvidia-tech/

GPUは日本製？

http://www.dmprof.com/jp/product_graphicsipcore.html

DMPプレスリリース

http://www.dmprof.com/release/20100621_3DS.html

ニンテンドー3DSに使われるGPUは日本産の「PICA200」

http://www.gizmodo.jp/2010/06/3dsgpupica200.html

どうやらnVidia(tegra)との提携話は破談になっていたっぽい。

なんとなく想像するに、
- 忍：NDSやNDSiの過去ゲームも全部動くように出来ない？
- nV：オーマイガ！インポッシブルネ。
- 忍：じゃあチップじゃなくてIP売ってくれ。
- nV：ノー。

みたいな。

まあ、TegraってCPU/GPU統合チップ(さらにVideoDecoderとかAudioDecoderとかてんこ盛り)だから切り売りは無理だよな。

解像度的には（発表資料などで800x240、片目当たりでは400x240）ＮＤＳの320x240の左右に横40ドットづつ地デジの帯が伸びただけ。

なので、フィルレートなんてそんなにいらないし、ポリ数多くしても１ドット以下だとどうせ見えない。

３Ｄの飛び出方がボリュームで調整できるっていうのは超画期的かもしれない。

↑

神の粒子†

“神の粒子”は5種類あるとの新証拠

http://www.nationalgeographic.co.jp/news/news_article.php?file_id=20100617001&expand

ヒッグス粒子と呼ばれる理論上の粒子は、宇宙のすべてに質量を与えると
考えられているため、“神の粒子”という名も持っている。

この命名はおそらく「神がつくった究極の素粒子（上下巻）」レオンレーダーマン著から来ている。

そのヒッグスが５種類あるのではないだろうか説が出てきたわけだ。

物理学の標準模型では説明できない“刺激的”な研究結果が発表された。
“神の粒子”が5種類存在する可能性が加速器実験で示されたという。

↑

OpenOCDとは何なのか？†

以下のサイトの説明が非常に分かりやすかった。

http://www.besttechnology.co.jp/modules/knowledge/?OpenOCD
つまり、ARM用の(TCP/IP接続)GDBデバッグスタブ（デバッグサーバー）なのだ。
なので、当然のごとく、クライアント側ソフト（デバッガー）はgdb（もしくはGUI版のgdbであるGNU Insight）だ。
もっと突っ込んで言えば、「gdbデバッガーと、JTAGケーブルの先に繋がれたARMチップ」を繋ぐためのソフトウェア・ケーブルな訳だ。
- 昔は、gdbとターゲットマイコン間の接続にリアルなRS-232Cケーブルが使われていて、ターゲットマイコン側には、小さなモニタープログラムの一種であるgdbスタブを組み込んでいたわけだ。
- gdbスタブはRS-232Cでgdbデバッガと通信して、プログラムの実行制御やレジスタ内容ダンプなどを行ってくれる。
- ARMチップにはOCD（オンチップデバッガ）と呼ばれる回路が大抵組み込まれていて、gdbスタブのようなプログラムも不要になっている。
- そして、OCDとホストPCの接続方法として、（本来はチップ検査用である）JTAG接続を流用しているわけだ。

GDBスタブとして動作させること以外に、ARMのFlashROMにHEXを書き込む機能を持っている。（コマンドラインにて指定）
```
$ /opt/local/bin/openocd -f openocd.cfg -c "flash_program blink.elf"
```
あれ？hexじゃなくてelfかよ。
しかし、openocd.cfg 内に、flash_programというプロシージャーを定義しておく必要がある。
cfgの書き方はいろいろ難しそうだ。

↑

LPCXpressoを手に入れた。†

しかし、基板が届いただけで、ソフトウェアはインターネットから入手しなくてはならない。
Registrationが必要。
なんかいろいろクローズドな感じがした。
一応サンプルソースらしきものは付いていた。
けれど、あんまりやる気しない。
まあ、安かったからいいけど。（２８００円）
IDEはEclipseみたいな感じがした。
てゆーか、Windowsのアイコン・ショートカットのリンク先って、思いっきり"eclipse.exe"になってるやん。

つまり、IDEはEclipseで、コンパイラはgcc（？） Keilかもしれないけど・・・。
なんとなくHELPをみるとgccって書いてある。
で、なんで128kB制限があるの？

解せぬ、なんでお前には128kB制限があるのだ？

買った後で今頃分かったこと

>The LPC1100 and LPC1300 do not support JTAG for debug. They are both SWD-only.

な、なんだってー（ＡＡ略）

秋月のARM系メーカー販促グッズは（安いけれど）、ぜんぶ外れクジだったのかー。

参考リンク

AudinさんのLPCXpresso探検隊

http://mpu.seesaa.net/article/1334117.html

エレキジャック記事

http://www.eleki-jack.com/arm/2010/02/lpcxpressoled-1.html

気を取り直して、とりあえずやろうと思うことをまとめる。

PIC18F14K50でUSB-Blaster互換ライターを作る。
OpenOCDをインストールして、LPC2388のファーム読み書きを試す。（デバッガ機能は、いらない）
うまくいったら、750円で買ったSTM32基板のファームを書き換えてやろう。

OpenOCDを単なるFlashROMライターとしてしか見ていないことがバレバレ。
気が向いたらport3333でgdbを試してみることにする。（もちろんコマンドライン版のgdbに決まっている。GUIは全て邪道）

にっき

今日はUSB-Blaster互換ライター(JTAGアダプター)の配線を少しだけ行った。
最低限USB接続出来るまでには、あと電源、USB D+,D-、V-USBコンデンサー、水晶(ICの下に実装済み)を配線するのみとなった。
実は基板加工とUSB-Bコネクタ取り付けが一番面倒。それから配置を考えることとか。

PIC18F14K50は配線がシンプルで良い。

作業中にアナログテスターを床に落としてしまった。
テスターは針が半分しか振れなくなり、ゼロポジションに戻らなくなった。もうだめかも。
しかたがないのでデジタルテスターで作業。めっちゃ作業しづらい。

配線量は大したことないし、お手本の基板の配線をなぞるだけなのに電源の配線を間違えていた。
実体配線図を起こすの面倒だなー。でも起こしとかないと、あとで改造するとき思い出すのが大変。

USB-Blaster兼HIDaspx兼PIC18Fライター兼PIC24Fライター兼簡易ロジアナ兼RS232Cアダプターに使えるようにする予定。でも切り替えはブートローダーで３種類のファームを書き換える必要がある。ややいんちき。
あ、そのまえに、sa89a.netさんのファームを14K50に移植しなくては。

↑

USB-Blaster互換（じゃなくてもどき）18F14K50製作中なう。†

例のこいつね。

USB接続成功。pic18boot,pic18spxともに動作確認ＯＫ。
20Pin ARM用JTAGコネクタ、兼LatticXP2用10Pin JTAGコネクタ結線終わり。あーめんど。
なんでJTAGってメーカーごとにコネクタがばらばらなんだろう。
あと、ST-LINK用の7Pin(8Pin)ケーブル用は未配線。

ARMにはRESETがあるようだが、USB-Blasterにはそのような端子が出ていない。
それから、USB-BlasterにはnSTATUSとnCEとnCSがあるけれど、ARM(LPC2388)にはそのような端子が無い。

いまのところ、その辺が疑問。

それから、ファーム書かなきゃ（移植が必要）試せない。

↑

USB-Blaster互換（じゃなくてもどき）18F14K50いきなり座礁中†

なんかPINGPONGバッファが３個以上要るらしい。
14K50では逆立ちしても無理。

配線を全部やっつけたというのに。

どうしよう。

基本このライターはいわゆる安全パイなので速度を求めない。（元々PICは遅い）
なのでPINGPONGなしで実装してみようかとか考えている。
だけど、なぜバッファが３個以上必要なのかを理解できていない。
理解できていないので、何も考えず実装しても動かない可能性大。

FT2232Dは手元にあるけれどレベル変換のゲートがなかったり。

↑

CQ-STARM32でVersaloon†

http://www.koka-in.org/~kensyu/handicraft/diary/20100515.html

なんかあんまりよく理解できていない。
Versaloonの設計が？なのか。
それともSTM32F10x系列の設計が支離滅裂なせいなのか？
ARMアーキテクチャーがタコなのではない。STMicroとNXPが両方タコだったのだ。ちくしょーハズレクジ。

↑

USB-Blasterとは何なのか？†

USB Blasterクローンの製作

http://www.geocities.co.jp/Technopolis/9382/USB_blaster/USB_blaster.html

HuMAN DATAサイトの解説

http://www.hdl.co.jp/altera/tb/maketb1/index.html

元ねた

http://ixo-jtag.sourceforge.net/

本家のマニュアル

http://www.altera.com/literature/ug/ug_usb_blstr.pdf

なんか、FT245RLの先にFPGAが繋がっている構造っぽい。
本家マニュアルではUSB Interface chipとしか書いてない。
なんとなくCypressのFX2LPっぽいようなことも書いてある。

結局USB-Blasterとは何なのか？については、分からなかった。

けれどHuMAN DATAさんの解説によると、FT245の先にFPGA(あるいはCPLD)を付ければ実装できる、ということが書いてあったので、そのような理解でよいのだろう。（ixo-jtag.sourceforge.netのほうではFPGAあるいはCPLDのソースを載せているらしい）

実はFT245がどうなっているか知らないので、結局プロトコルがどうなっているかも不明のままなのだけれど。

USBデバイスの種類はGeneric(ベンダユニーク)デバイス。
エンドポイントはバルクinとバルクoutが１つづつ。
パケットサイズは64byte(最大)

ファーム側の動作

（１）

1byteのデータ(c)を読む
if( cのMSBが立っている ) {
    jtagデータのバイト数=(c & 0x3f);
}else{
    c の下位5bitをJTAG制御線にそのまま反映。
    if(c のbit6が立っている) {
         TDOとnSTATUS制御線を読み取って、キューにためる.
    }else{
         何もしない.
    }
}

（２）

if( jtagデータのバイト数 ) {
    if(c のbit6が立っている) {
        jtagデータを、バイト数分 シリアル転送する.
        と同時に、TDOから受け取ったデータをキューにためる.
    }else{
        jtagデータを、バイト数分 シリアル転送する.
    }
}

こんな感じか。
つまり、最初の１バイトがコマンドで、

BitBangのパケット:

+----+----+----+----+----+----+----+----+
| 0  |READ| -  | TDI| nCS| nCE| TMS| TCK|
+----+----+----+----+----+----+----+----+

JTAGストリームのパケット:

+----+----+----+----+----+----+----+----+
| 1  |READ|  後続するJTAG送信データbytes|   ＋　後続データ[bytes]
+----+----+----+----+----+----+----+----+

ただし、nCS=0のときのJTAGストリームは、ActiveSerialとして処理される。

READ=1のときは、読み取ったデータ(bitbangのときはTDO=bit0とnSTATUS=bit1のみ、JTAGのときはTDOをデシリアライズしたストリームをbytes分)キューに溜めておいて、あとでホストＰＣに返送する。

ActiveSerialとJTAGの違いは、読み取る信号線がnSTATUSかTDOかの違いだけのようだ。
なので、READ=0のときの動作は同じ。

ホストＰＣがキューの内容をすぐに引き取ってくれるならダブルバッファやトリプルバッファは要らない。
ホストＰＣがガンガン（つまり複数パケット分）データを送信してきたら、キューが64byteを溢れて、データストリームが破綻する。

↑

Mac Mini Mid 2010 Teardown†

http://www.ifixit.com/Teardown/Mac-Mini-Mid-2010-Teardown/3094/1
まるでノーパソ用の外付けＤＶＤドライブみたい。
おそらくＤＶＤドライブがなければ、形状はＵＳＢハブみたいに小さくなるんだろうな。

Appleは商売が上手いぜ。

iPad買った。パソコン(iTunes)なければただの液晶。
パソコン要るのか。じゃあどうせならMacで。
Mac Miniがお安いですよ。外付けＤＶＤドライブにもなるし。（いや、ならないけど）

iPadの出現でＰＣは要らなくなると説いておいて、
実際問題ＰＣ（かＭａｃ）がないと起動さえ出来ないデバイスを売りつけて、
（素人に）Macまで売りつけようとするわけだ。

まあ、昔のＤＯＳ/Ｖ機（i486とかの時代）が２０万弱した時代から見れば、iPadとMacMiniを両方買ってもお釣りがくるわけだが。

しかし、こういう情報もある。

http://www.gizmodo.jp/2010/06/iphone_4_10.html
FOXCONNは中国撤退？いやFOXCONNだけでは済まなさそうだ。一波乱起きるか。
まあ、電子機器製造が一国に支配されるのはセキュリティ的に見て非常に危険だ。

↑

HTML5:これは凄い。JavaScriptでレイトレーシングまで。†

http://jsdo.it/
上記サイトは、まるでJavaScriptによるArduino（ちょっと変なたとえだが）。
電子工作とは何の関係もないが、
JavaScriptをブラウザー上のエディタで編集して、すぐに試せるのだ。

なんと画期的な！

これなら、ChromiumOSとかGoogle ChromeだけでＷｅｂ開発が出来るではないか！！！

今までの、秀丸とかEmacs(jedでもいいけど)でJavaScriptやらCGIを書いて、サーバー側にファイルセーブとかアップロードしたあとでWebブラウザーで確認するという作業はもう古いのか。

↑

HTML5:ブラウザー上でのProcessing(Proce55ing)†

例のカヤックのサイトのサンプル作品のひとつ。

http://jsdo.it/MyOuterWorld/Sps1

ソースを見ると、ちょっと見慣れたＣ言語表記（実際にはProcessing）

<script type="text/javascript" src="/lib/processingjs-0.9.4/js"></script> 
 
<script type="text/javascript"> 
window.onload = function() {
  var canvas = document.getElementsByTagName('canvas')[0];
 
  var codeElm = document.getElementById('processing-code');
 
  var code = codeElm.textContent || codeElm.innerText;
  Processing(canvas, code);
};
</script> 
<script id="processing-code" type="application/processing"> 
void setup()
{
  size(440,440);
  fill(255, 99);
  frameRate(30);
 
}
 
float angle;
float cosine;
 
 
void draw()
{
  background(0);
 
  float locx, locy;
  locx = 200;
  locy = 200;
 
  stroke(0,156,255);
  line(locx,locy,mouseX,mouseY);
  noStroke();
  translate(locx, locy);
  float a = atan2(mouseY-locx, mouseX-locy);
  rotate(a - QUARTER_PI + PI);
 
  rectMode(CENTER);
  quad(-10, -10, 20, 2, 5, 5, 2, 20);
}
 
void keyPressed()
{
  if(value == 0) {
    value = 255, 0, 0;
  } else {
    value = 0;
  }
}
 
</script> 
</script>

なんで？
JavaScriptには見えない。
でも、Chrome上で動いてるんだから。

<script type="text/javascript" src="/lib/processingjs-0.9.4/js"></script>

と

<script id="processing-code" type="application/processing">

がその正体なんだろうけれど、なんでHTML上にＣ言語（うそ、Processing）が書けるのか？

謎杉

↑

OpenOCD:この分かりにくさは何なんだろう。†

本家サイトは

http://openocd.berlios.de/

だけどソース管理は

git://openocd.git.sourceforge.net/gitroot/openocd/openocd

現在の最新バージョンをgitで取得してみると0.4.0
だけどググると0.5.0なんてのがあったりする。

例のftdiのライセンスからみでバイナリーは配布されていない。
Windowsでビルドするのは大変。
- http://homepage3.nifty.com/zus/OpenOCD_Build_win32_Flame.html

Linux上のMinGWクロスコンパイラでWin32バイナリーを作るほうがよほど簡単な気がした。
ビルドが面倒そうに思えるのはlibusb-win32ライブラリーとかftdiのライブラリーが必要なことだ。

ベストテクノロジーさんがバイナリーを提供してくれているけれど、

http://www.besttechnology.co.jp/modules/knowledge/?OpenOCD
残念ながらUSB-Blasterが使えないconfigになっている。

いろいろ挫折中

FT2232Lは手持ちがあるけれど74VCT125なんて配線できないよ。
18F14K50はRAM不足で実装困難。
最後の頼みの綱18F2550版はハードだけあるけれど、OpenOCDのバイナリーを作るのが限りなく面倒くさい。

いろいろ浮気

トラ技付録DVDROMにVMWareのARM開発環境が入っていたので試そうとした
- OpenOCDのVersionが0.3.1くらいで、USB-BlasterのBの字もなかった。
しかたないので、ubuntu 10.4 上でgit取得したソースツリーをビルドしようとした。
- ビルドは途中まで通るものの、Docディレクトリでつまづく。
OpenOCD-0.4.0.zip のTar Ballを取得してビルド。
- ビルド成功。 configディレクトリにaltera-usb-blaster.cfgがあった。

ビルドは出来たが動かない。

なんか usb_blasterデバイスがないとか言われる.

configureするときにオプションがいるらしい。

$ mkdir build
$ cd build/
$ ../configure --enable-usb_blaster_libftdi

現在、最新をsourceforgeから落としてビルド中。
- ビルドError。なんか、libftdiをftdiのサイトから落としてこないとだめなんだろう。

挫折確定。

そもそもusb_blasterなんだからftdi関係ないだろ、とか思った。

参考URL:OpenOCDをビルドする

http://www.kimura-lab.net/wiki/index.php/OpenOCD%E3%82%92%E3%83%93%E3%83%AB%E3%83%89%E3%81%99%E3%82%8B

libftdiが必要。

ここで、さらに紛らわしい事実に遭遇する。
FT2232Lなどを叩くには、２つの方法があり、
(1) オープンソースのlibftdiを使用する。
(2) FTDI提供のftd2xxを使用する。

どうもこれらの方法には互換性がないらしい。

そして、libftdiの下位層はlibusbなので、libusb-dev(あるいはdevel)も必須である。
USB_Blasterの構造は以下のように、（実はFTDIなのだ）なっているので

usb_blaster.c

* USB-JTAG, Altera USB-Blaster and compatibles are typically implemented as
* an FTDIChip FT245 followed by a CPLD which handles a two-mode protocol:
*
*            _________
*           |         |
*           | AT93C46 |
*           |_________|
*            __|__________    _________
*           |             |  |         |
*      USB__| FTDI 245BM  |__| EPM7064 |__JTAG (B_TDO,B_TDI,B_TMS,B_TCK)
*           |_____________|  |_________|
*            __|__________    _|___________
*           |             |  |             |
*           | 6 MHz XTAL  |  | 24 MHz Osc. |
*           |_____________|  |_____________|
*

当然ながら、libftdiから叩く構造だ。
こっちはPIC実装しか知らないから、何故FTDIドライバーが要るのか理解できなかったのだ。

さらにビルドを試みる.

libftdiを取得してビルド
libftdiは下位層にlibusbを使用していて、ubuntuの場合、パッケージlibusb-0.1-4および、libusb-devが必要になる。（libusb-1.0のほうではなく0.1-4のほうが必要）
```
# apt-get install libusb-dev
```

libftdiをビルドする。

$ cd libftdi-0.18
$ ./configure
$ make
$ sudo make install

openocdのソースを取得する.

# apt-get install git-core
$ git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd

openocdをビルドする.

$ cd openocd
$ ./bootstrap
$ mkdir build
$ cd build
$ ../configure --enable-usb_blaster_libftdi
$ make
$ sudo make install

ざっとこんな感じ。libtoolとかautoconfとかgccとか基本的なビルドツールはもちろん必須。インストールしたばかりのubuntu には無い場合があるので、あらかじめapt-getで入れておく。

ちなみに上記手順どおりにビルドしても、現状のバージョンではdoc/以下のビルドが通らないようだ。

doc/openocd.texi

@include version.texi

version.texiがない、というエラーを吐いて止まるので、中身が空のversion.texiを作ってしのいだ。

それから、openocdを起動すると libftdi.so.1がない、と言われるので、/usr/local/lib/libftdi.so.1 のシンボリックリンクを/usr/lib/ に置く。
```
# cd /usr/lib
# ln -s /usr/local/lib/libftdi.so.1
```

↑

メモ:Linuxカーネルうおっち†

カーネル界隈で起きている出来事について。

http://www.atmarkit.co.jp/flinux/index/indexfiles/linuxkernelindex.html
読んでて面白い。

そろそろext3のパフォーマンス悪さに辟易しているのでext4に乗り換えようかと思っているところ。
ext4のジャーナルがちょうど１周したときに再起動するとファイルをふっとばすというのはまるでseagateの確変大当たりファームと同じようなバグだなー。（seagateファームの場合は、その後HDDとして認識しなくなるというおまけがついている）

で、ubuntuのカーネルが2.6.32であることを確認したので、早速ext4でrootパーティションを切り直して、mountモードをnoatime,data=writebackにしてみた。

rootパーティションをwritebackにするにはgrubのオプションにもdata=writebackが必要らしい。

心なしか起動が速くなったような気がする。というか、起動完了するまでのディスクのガリガリ音がだいぶ少なくなった。
すでに（十分速い）WindowsXPよりも起動が速いので気持ちが良い。

もちろん、起動が速いのはインストールしたばかりのまっさらな状態だからでもある。
ext4は最初からフラグメントを起こしにくいようになっているうえ、オンライン状態でのバックグラウンド処理によるデフラグ機能まで付いているらしい。

普通の人はwritebackにする必要は無く、journal=ordered（デフォルト）でも十分おっけーらしい。
writebackにすると、停電など不意のリセット後のfsckで最悪書き込み中データが復旧しない場合があるらしい。
まあ、それについてはWindowsでもよく起こることなので気にしない気にしない。(ext2だと思えば、まだ復旧の可能性があるだけましか）

↑

WIRED:「アプリの時代」と、Intel社のネットブック戦略†

http://wiredvision.jp/news/201007/2010070522.html
intelは完全に本末転倒だ。
ネットブックが１台あれば、VMWareを入れてubuntuを動かしたり、デュアルブートにしてubuntuを動かしたり出来る。
完全に自由にプログラミングできるＰＣから自由を奪おうというのだろうか？
まさにそれはChromiumOSがやろうとしていたことそのものなんだけど。
でも普通にＰＣのBIOSROMが入っているのだったら、いつでもWindowsやubuntuを入れなおすことが出来るわけで。

というか単にiPadの二匹目のドジョウを狙っているだけなんだよね。
で、将来改良される予定のAtom使って現在発売中iPadと同程度の電池の持ちとコストを実現できるわけ？ないよね。たぶんむり。残念でした。
Atomはチップセット込みで$65〜もするんで、ARMと比べてコスト高すぎなんだよね。OpenGL2.0もサポートできないし。

↑

2SC1815:ついにディスコンか？†

スラド

http://slashdot.jp/hardware/10/07/05/0834218.shtml

大丈夫。秋月ではまだＡＡＡだ。

思いついたんだけど、チップ部品を小さなカプセルに入れて、そっからディスクリート部品と同じようなリード線を出すようなケースを作ったらいいんじゃないかな。

でもチップ部品って、ロット数多くないと売ってくれないんじゃあ？

とりあえず、今のうちに大人買いしておこう。

チップ部品を小さなカプセルに入れて、

カプセルを電子ブロックのような形状にしておけば、チップ部品による電子ブロックが作れるかも。
もしくは、ブレッドボードに挿しやすい形状のカプセルもありだな。うん。

↑

Intel、Android（froyo）をx86アーキテクチャに移植†

http://www.itmedia.co.jp/news/articles/1006/28/news053.html

Intelはx86でネイティブに動作するバージョンのAndroid 2.2（コードネーム「Froyo」）
を2カ月以内にリリースすると、同社幹部はオンラインマガジンAPCに語った。

VMイメージまだぁ？（ＡＡ略）

同社のジェームズ氏はAPCに、Androidのx86アーキテクチャへの移植は
「非常に難しいというわけではない。当社にはLinuxでの豊富な経験がある」と語っている。
同氏はまた、x86版のコードをAndroid開発者コミュニティーに提供することも明らかにした。

（intelの）moblinはどうするつもりなんだろう。

つまりFroyoの野良ビルドはもうはやらないんでしょうかね。

↑

OpenOCD:全く実用にならない奴†

例の続き
あらすじ：
- PIC18F2550を使った見かけ上USB-Blasterのようなハードウェア（これはFPGAのconfigを行うには充分な性能を持っている）とCQ-FRKのLPC2388基板を繋いでOpenOCDを動かしてみようというプロジェクト。
- VMWare上のubuntu10.4でOpenOCDをビルドするところまではＯＫだった。
これから実行。

root@ubuntu:~/OpenOCD/scripts# openocd -f lpc2378.cfg 
Open On-Chip Debugger 0.5.0-dev-00394-gf97b6b5 (2010-07-02-20:27)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.berlios.de/doc/doxygen/bugs.html
adapter_nsrst_delay: 400
jtag_ntrst_delay: 400
trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain 100 kHz
Error: Translation from khz to jtag_speed not implemented
Error: Translation from khz to jtag_speed not implemented
Error: Translation from jtag_speed to khz not implemented
Error: Translation from khz to jtag_speed not implemented
Info : adapter-specific clock speed value 916799476

ここで約１分、待たされる。

Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
Info : Embedded ICE version 7
Error: EmbeddedICE v7 handling might be broken
Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units

だめじゃん。

port 4444につないでhaltとかやっても応答が返ってこない。
上記の応答があるのはまだいいほうで、大抵は4f1f0f0fが見つからないエラーになる。

AlteraのJTAG Chain Debuggerで見ると、安定して4f1f0f0fが一発で返ってくる。

VMWareからUSBデバイスを見ているのが悪いのか、
それともUSB-Blasterのビルドが間違っているのか。

configの書き方が悪いのか？

configは altera-usb-blaster.cfg と lpc2378.cfg をcat して作成。
そのままだと動かない。
adapter_kHz を 100　くらいに落とさないとまともに動かない。（落とさないとチップ認識すら、しない）

何で？

↑

OpenOCD:全く動いていないわけではない†

$ telnet localhost 4444
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger

> scan_chain
  TapName             Enabled  IdCode     Expected   IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
 0 lpc2388.cpu            Y     0x4f1f0f0f 0x4f1f0f0f     4 0x01  0x0f

> halt
target state: halted
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x600000df pc: 0x00000ba4

> poll
background polling: on
TAP: lpc2388.cpu (enabled)
target state: halted
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x600000df pc: 0x00000ba4

> flash probe 0
flash 'lpc2000' found at 0x00000000

反応がもの凄くにぶい（１つのコマンドを投入してから１０秒以上待たされる）
しかも、telnetなのにエコーバックが返ってくるのに５秒くらい待たされる。

上記ログを見る限り、全く動いていないわけではなさそうだ。

一応JTAGのtckは750kHzでコンパイルしてあるので（これはLPC2388ボードのリセット直後のＣＰＵクロックが４ＭＨｚなため、tck=3MHzだと追いつかない。3MHzの１つ下はPIC18FのSPI TIMERの都合上、750kHzになる。）ファームのせいではなさそう。

だとするとVMWareが悪いのか？

残念なことに、素のubuntuが動く手持ちマシンが無いのだな。うーむ。

↑

OpenOCDダメダメ説†

残念なことに、素のubuntuが動く手持ちマシンが無いのだな。

むりやりでっちあげてみた。

root@user-desktop:~/# openocd -f a.cfg
Open On-Chip Debugger 0.5.0-dev-00401-gdaa02f7 
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.berlios.de/doc/doxygen/bugs.html
3000 kHz
trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
Runtime error, file "a.cfg", line 35:
    invalid command name "jtag"
called at file "embedded:startup.tcl", line 57
in procedure 'script'

んなアホな。

# LPC2000 -> SRST causes TRST
reset_config trst_and_srst srst_pulls_trst
#↓ここでこけている
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID

set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME arm7tdmi -chain-position $_TARGETNAME

しかたなく、古いソースツリーをコピーして再ビルド

Open On-Chip Debugger 0.5.0-dev-00394-gf97b6b5 
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.berlios.de/doc/doxygen/bugs.html
3000 kHz
trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
500 kHz
Error: Translation from khz to jtag_speed not implemented
Error: Translation from khz to jtag_speed not implemented
Error: Translation from jtag_speed to khz not implemented
Error: Translation from khz to jtag_speed not implemented
Info : adapter-specific clock speed value 908611572
Error: ftdi_write_data: usb bulk write failed
Error: ftdi_write_data: usb bulk write failed
Error: ftdi_write_data: usb bulk write failed
Error: ftdi_write_data: usb bulk write failed
Error: ftdi_write_data: usb bulk write failed
Error: ftdi_write_data: usb bulk write failed
Error: ftdi_write_data: usb bulk write failed

usbアクセスが死んでいる。物理ポートはATIとviaの両方で試した。（たしかに両方キワモノではあるが・・・）

結論として、OpenOCDのaltera-usb-blaster(なんちゃってデバイス。実はPIC18F)サポートは全然だめという感じ。

しかたないので、usb_blaster.c のソースを読んでみる

static int usb_blaster_buf_write(
    uint8_t *buf, int size, uint32_t *bytes_written)
{
#if BUILD_USB_BLASTER_FTD2XX == 1
    FT_STATUS status;
    DWORD dw_bytes_written;

#ifdef _DEBUG_JTAG_IO_
    LOG_DEBUG("usb_blaster_buf_write %02X (%d)\n", buf[0], size);
#endif
    status = FT_Write(ftdih, buf, size, &dw_bytes_written);
    if (status != FT_OK)
    {
        *bytes_written = dw_bytes_written;
        LOG_ERROR("FT_Write returned: %lu", status);
        return ERROR_JTAG_DEVICE_ERROR;
    }
    *bytes_written = dw_bytes_written;
    return ERROR_OK;
#elif BUILD_USB_BLASTER_LIBFTDI == 1
    int retval;
#ifdef _DEBUG_JTAG_IO_
    LOG_DEBUG("usb_blaster_buf_write %02X (%d)\n", buf[0], size);
#endif
    retval = ftdi_write_data(&ftdic, buf, size);
    if (retval < 0)
    {
        *bytes_written = 0;
        LOG_ERROR("ftdi_write_data: %s", ftdi_get_error_string(&ftdic));
        return ERROR_JTAG_DEVICE_ERROR;
    }
    *bytes_written = retval;
    return ERROR_OK;
#endif
}

なんか、限りなく手抜きされているような気がした。
いくらなんでも１バイト単位でwriteするわけないだろとか思った。

/* Simple bit banging mode:
 *
 *   Bit 7 (0x80): Must be zero (see byte-shift mode above)
 *   Bit 6 (0x40): If set, you will receive a byte indicating the state of TDO
 *                 in return.
 *   Bit 5 (0x20): Output Enable/LED.
 *   Bit 4 (0x10): TDI Output.
 *   Bit 3 (0x08): nCS Output (not used in JTAG mode).
 *   Bit 2 (0x04): nCE Output (not used in JTAG mode).
 *   Bit 1 (0x02): TMS Output.
 *   Bit 0 (0x01): TCK Output.
 *
 * For transmitting a single data bit, you need to write two bytes. Up to 64
 * bytes can be combined in a single USB packet (but this is not done in the
 * code below). It isn't possible to read a data without transmitting data.
 */

#define TCK         (1 << 0)
#define TMS         (1 << 1)
#define NCE         (1 << 2)
#define NCS         (1 << 3)
#define TDI         (1 << 4)
#define LED         (1 << 5)
#define READ        (1 << 6)
#define SHMODE      (1 << 7)
#define OTHERS      ((1 << 2) | (1 << 3) | (1 << 5))

#define READ_TDO    (1 << 0)

static void usb_blaster_write_data(void)
{
    uint32_t bytes_written;
    usb_blaster_buf_write(&out_value, 1, &bytes_written);
}

推測でものをいうのもなんだから、疑り深い人は上記(usb_blaster.c)ソースを見てね。

たぶん、OpenOCDのaltera-usb-blaster対応は、ひどくやっつけ的。
どこでバッファリングされているか知らないけど、もしされてないならjtagの1bit分の操作単位でUSBパケットが飛んでいるかも。（これについては未確認）

↑

やっぱりftdi_write_data()は何もバッファリングされずに、usb_bulk_write()直結だった。†

libftdi/ftdi.c

/**
   Writes data in chunks (see ftdi_write_data_set_chunksize()) to the chip

   \param ftdi pointer to ftdi_context
   \param buf Buffer with the data
   \param size Size of the buffer

   \retval -666: USB device unavailable
   \retval <0: error code from usb_bulk_write()
   \retval >0: number of bytes written
*/
int ftdi_write_data(struct ftdi_context *ftdi, unsigned char *buf, int size)
{
   int ret;
   int offset = 0;
   int total_written = 0;
   if (ftdi == NULL || ftdi->usb_dev == NULL)
       ftdi_error_return(-666, "USB device unavailable");
   while (offset < size) {
       int write_size = ftdi->writebuffer_chunksize;
       if (offset+write_size > size)
           write_size = size-offset;
       ret = usb_bulk_write(ftdi->usb_dev, ftdi->in_ep, buf+offset, write_size, ftdi->usb_write_timeout);
       if (ret < 0)
           ftdi_error_return(ret, "usb bulk write failed");
       total_written += ret;
       offset += write_size;
   }
   return total_written;
}

それから、せっかくusb_blasterのファーム側に実装されているJTAG_write（純粋にTDIのビットだけをバイト列に詰め込んで送り込むモード）は全く使っていない模様。

こんな実装ならFT232RLのBitBangでも使ってろ（むしろそっちのほうがはるかにまし）的な展開だ。

OpenOCDはFTDI純正のD2XXじゃないとダメっていうオチはないよね。

FT2232Lですか。あー配線めんどくせ。

最新の20件