• 本文
• 編集
• 差分

2010-03

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

３月兎†

今月の目標

• 赤外線でビビビ(これも既製品を買ったら敗北だ。)

• 地アナしか映らないブラウン管テレビ（地デジＴＶ購入とともにリサイクル行き）
• の回収時、回収を逃れて放置された赤外線リモコンデバイスがあるので、

そいつに、ＡＶＲチップを注入だ！ <---- 普通にテレビリモコン買ったら１０００円しないのに・・・という突っ込みはなしで。

• 地デジ赤外線解析には、ＰＩＣ(18F2550)を使う予定。

• とりあえず波形観測まではＯＫ。
• この波形はSharpの地デジＴＶのもの。

局地核戦争でも人類は滅亡†

日経サイエンス

• http://www.nikkei-science.com/page/magazine/1004/201004_078.html

  局地核戦争であっても，その煙は太陽光によって暖められて上昇し，
  高層大気中に何年も浮遊して日光を遮断し，地球を冷やし続けることを見いだした。

• つまり、文明の崩壊は近いのか？
  • いや、逆に考えるんだ。これをうまく使えば、地球温暖化を速やかに食い止める手段になる。
  • 印パ紛争で１００発も使われるとやばいな。イスラエルとイランなら大丈夫か？
  • つまり、アメリカが戦争抑止的に使ったとしてもやばいわけだろうから。（すでに日本に対しては使用済み、核兵器）
• なんていうのは全部冗談だ。
• 結論として、核兵器は、「使えない兵器」なのだ。

あるいは文明の「リセットスイッチ」

秋月のＰＩＣマイコン†

知らないあいだに品種が増えている。

• http://akizukidenshi.com/catalog/g/gI-03614/
• SRAMちょっと多い(4096-128byte)18F4550は2048byte
• Flashもちょっと多い(48kB)18F4550は32kB
• USBはない。
• クロックはDC〜40MHzまで。18F4550は48MHzほぼ固定運用。

• 参考価格はたとえば秋月の単価（変動するのであくまで参考用）
• USB付き品種は知っているので省略している。
• 秋月の品揃えもはぬけなんだけど、Microchipの品番の付け方は不規則で分かりづらい。
• そのまえにUSB無し品種の使い道が理解できなかったりする。何に使うんだろう。
• 遅くてコードサイズが膨れてもいいならPIC。そこそこ速くてコードも縮むのでFlashが少なくてもＯＫなのがAVR。
• 前者の条件って、ゆるすぎ。
• PICのほうがFlashが多いと思ったら大間違い。コード量で倍〜４倍くらいPICが無駄食いするし、速度比で最大１０倍ぐらいPICのほうが遅い(AVRは20MHzだがPICは40MHzといっても4分周するので実質10MHzしかもＣ言語向けで無いので効率が1/5）。
• 嘘だと思うなら同じＣソースを動かして試すといい。

• SRAMの実装量が中途半端な値なのは、ＲＡＭ空間が12bit分しか用意されていないためだ。
  • ＲＡＭ空間の最後尾エリア128バイトくらいにはポートやレジスタが割り付けてある。
• これはmovffというメモリーtoメモリー（両方とも12bitアドレス）のコピー命令のソースオペランドフィールドが12bitしか確保出来ないためなので、今更どうしようもない。
• FSR0,1,2というＲＡＭ空間を指すポインタも12bitしかない。これもLFSR命令が持つことの出来る即値フィールドが12bitしかないのでこれも今更どうしようもない。
• FSRのレジスタ自体はＲＡＭ空間に出ているのでそっちに書き込めば16bitあってもよさそうなものだが、movff命令のほうはもうどうしようもないレベル。

単純にチップ価格が「安い」ということと、DIP品や省ピン品種があることと5Vで使えることがPICやAVRのメリットだが、ARMやMIPS32と比べるとアーキテクチャー上のメリットは無い。

• ただ、RAM128byteとかFlashが2kbyteという世界にARMやMIPS32を持ち込むのは明らかに間違っていると言うことは出来る。

では、AVR/PICとARM/MIPS32の境界線を決めようじゃあないか？

• たぶんコード量64kBが分かれ目だと思う。
• Z80が廃れた理由も、BASICやアプリが肥大化してバンク切り替えのおばけ(MSX2とか)になってしまったからだ。
• SRAM容量64kBまではAVRやPIC24でも頑張れないことはないけれど、バランス的にSRAM64KのようなチップだとFlash512kとかになってしまうので、どう考えてもARM(Thumb)の出番だ。
• で、コード量32kB〜64kBまでが、汽水域というか両方活躍できそうな地帯。

• 今の半導体プロセスでは32kくらいのFlashは何ともないのでARM(Thumb)がこの分野にも進出してきたというわけ。

PIC24Fライターが動き始めそうな件†

• DeviceIDの読み出しに成功した。
• ソースは整理中。
• 普通にファームの読み書きが出来るようになってからup予定。
• configビットの読み込みもできるようになった。
• Flashの読み込みも一応作ってみた。
• Flashの先頭のほうだけ書いてみた。今のところ微妙にバグっている。
• eraseもやってみた。消えた。
• WriteとVerifyも出来た。ReadもOK。
• Config系のみ未実装

問題点

• Flash Config WordとDevice Configuration Registerの違いがさっぱり分からない。
• Flash Config WordはFlashROMの最後尾８バイトらしい。（32bit中16bitしかないので、実質４バイト）
• Device Configuration Registerは0xf80000〜0xf8000e に存在するので、PIC18Fで言う所のConfigビットだと思うのだけれど、両者の関係について今のところ不明。

しかし真の問題はPIC24FJ64とdsPIC33がせっかく読み書き出来るようになっても、

• その使い道が全く思い浮かばないところか。
• FFT？ ディジタルフィルター？
• いやいや、ターゲットデバイスにそんな不毛なことさせて何かメリットあるのか？
• 単にFlashが64K、SRAM8Kも乗っている、大容量のPIC。
• 32MHz動作(内蔵8MHzRC発振でx4PLL)で16MIPSらしい。
• AVRでも20MIPSは出る。
• PIC24Fのメリットはgccが使えることと、16bitレジスタが豊富にあること。
• デメリットは、ROM領域にデータを置くと、せっかく64kBあるFlashの2/3しかデータ参照 してくれないこと。（約22kBが無駄になる）
• 理由は、命令長が24bit(3byte)なのに、TBLRDするときは16bitしか取ってこないためだ。

dsPIC33は（１個持ってるけど）サポートしないかもしれない。†

dsPIC33FJ32GP202 450円

• http://akizukidenshi.com/catalog/g/gI-02571/
• PIC24のレジスタに寄生しているDSPという感じ。
• PIC24FJ64とピン配置も似ているので共通基板でいけそうだ。
• ただし、Flash32k,SRAM2kと、PIC24FJ64にくらべてかなり小ぶり。
• （予想だけど）gccがDSPの命令を吐くとは思えない。結局DSPを使うには（インライン）アセンブラを使うしかない？
• 今のところPIC24の使い道は単にFlash大容量なだけのPICだ。dsPIC33はデジタルフィルターとかの用途でもなければ使う場面がない。しかしSRAM2Kは厳しいなぁ・・・。
• dsPICをサポートするのは、何か使い道を思いついたときにしよう。

ＰＩＣ２４ＦＪ６４ＧＡ００２：３５０円

• http://akizukidenshi.com/catalog/g/gI-02000/

PIC24の良いところ

• Vddは3.3Vもしくは2.5Vのどちらも可能。（５Ｖは無理）
• 動作電圧は2.0V〜3.6V（2.0Vのときの最高動作周波数は16MHz/8MIPS）なので電池動作も可能。(AVRでももちろん可能だけど)
• 内部的にはコア2.5Vで動いていて、内部にレギュレータがある。
• 外部的には(デジタルI/Oは)5V入力もＯＫらしい。
• コンパイラはMCHIP純正C30だが、その中身はgccだ。
• コード効率は普通に良いらしい。速度は最大32MHz動作時16MIPSなのでAVRの20MHzと同じくらいのはずだ。

欠点は、

• Flashの構造が１ワード24bitと変態的に特殊。
• エラッタ（設計上の欠陥、一応メーカーから公開されている）が非常に多く、思うとおりに動かないことが予想される。

一応、行きがかり上PIC24ライターは書いてしまおうと思っているけれど

• WSNAK172基板などをATmega328に換装したために大量に余ったATmega88とか168があって、さらにATtiny2313も買い置きが１０個以上あるので、
• PIC24Fを使わないと出来ないような使い道がまったく思い浮かばないんだな。
• USB内蔵でDIP品があるならばさっさとPIC18を捨てようとは思っているけれど。

dsPIC33/PIC24Fの用途†

さっき１つだけ思いついた。

• ＦＭ音源
• けれど、32MHz/16MIPSではちょっときついかな。レジスタが16bitあるので、AVRよりすこし良い程度。
• MCHIP C30を起動させてみた。ほんとにgccだった。シミュレータがsim(GNU binutils)だった。
• gccのクロスビルドはDarwin上で行われているようだ。しかもgccの稼働環境はmingwだった。
• 60日経ったら最適化が-O0になるらしい。
• gccソースも配布されているので、普通にgccをクロスビルド出来たら、制限無しのPIC24用gccが作れるけどいいのか？
• 少なくともLinuxやubuntu上では configure ; make ; でサルでも作れるはずなので、Linuxを(VMWareとかVirtualBox上で)自由に使える人なら-O0の制限は受けないことになる。
• mingwホストのgccクロスビルドはLinux上からでもかなり難易度が高いので、そこを攻略するのは大変だ。

Apple A4 Processor†

Apple A4の秘密を申請特許から解き明かす - ベクトル処理と省電力機構

• http://journal.mycom.co.jp/articles/2010/03/11/apple_a4/
• http://journal.mycom.co.jp/news/2010/03/02/004/

• なんだCortex-A8シングルコアかよ。
• この記事に書かれているようなベクトル化による動的最適化は実際行われていないと思う。（あくまで推測）
• そんなん出来ることが分かっているなら、とうの昔にintel/AMDプロセッサ上で誰かがやっているはずだ。(既存アプリのfloat命令を自動でSSE化出来るなら既にやってるに決まっている)

• ただ、LLVMのバックエンドをうまく使って動的最適化を行う可能性はあるかもしれない。（ARMは遅いので、そうやって少しでも速くしたいというのはある。）

• やるとしても最適化フェーズとしてやるわけで、配布されたアプリが実行中にon the flyするわけじゃない。

• 実行時最適化という点ではMicrosoftのVisual C++でもそういうオプションは付いているし、JITでもみんなやってることだ。（vector化できているかどうかは別として）

PIC24Fライターが手ごわい件†

• なんちゃってBitBangモードを実装したPIC18F14K50から、PIC24FJ64への読み書きはだいたい目処がついた。
• 例によってとても遅いので、ネィティブなコマンドを実装して、PIC18Fから直接PIC24Fへの読み書きができるようにしてみた。

• 速くなったはいいのだけれど、ファームウェアROMの上位8bitの読み出し(TBLRDH.B x 2)がうまく行かない。
• 読み出しても常に０なのだ。
• BitBang操作だと一応読み出せるのに何故？

• WAITとか入れまくったけれど駄目だった。

• 書き込みのほうは出来てるっぽい。

PIC24Fライター出来たどー†

• PIC24FJ64GA002に書き込めるようになった。

read more : pic18spx

• C30でＬチカを作らねば。---> 出来た模様。

PIC18F14K50上でPIC24Fライターが動かなかった理由

• スタックが足りていなかった。
• 32bit整数バリバリのコードをPIC24Fに持ち込んだ場合、相当量のスタック（auto変数と引数）を消費するようだ。
• 8bit４個(実際３個)を32bit整数に置き換える処理は、PC上ではシフト演算が有利（バレルシフタがあるので）
• だが、PIC24F上では超苦手なので、charとlongをパックしたunionを作ってそこに書いて読むという方法を使う。
• そのときの未使用上位byteのゼロクリアを忘れていたのだった。(auto,staticともに必要だったっぽい)

残る課題†

• 赤外線リモコンの解読ツールを書く。 ---済み

read more: pic18spx

• 赤外線でビビビ（AVRチップを使って既製品リモコンを改造）--自分の中では需要がなくなった。
  • 予定では地デジＴＶのREGZAを買って（あれはＴＶのくせに外付けUSB HDDに録画する機能がある）
  • 改造リモコンを使って予約録画をするつもりだったのだが、
  • HDD内蔵のDIGAが安く売ってあったのでそっちにとびついてしまい、改造リモコンは不要になった。

• なんかREGZAを誤解していたようだ。ＴＶのくせに外付けＵＳＢＨＤＤに録画予約出来るらしい。
  • 改造リモコンで時間が来たら録画ボタンを押すような回りくどい処理は最初から不要らしい。

ととと・・・

することがなくなったので、TV-B-Goneでも作ろうか・・・

• /ATMEL_AVR/cgi-bin/note/index.cgi?TV%2dB%2dGone

• しかし、ＴＶの電源スイッチはたいていトグル式なので、ＴＶ消し信号を連続放射するって、いったいどんなコードを垂れ流すのだろう・・・。

• 赤外線リモコンネタとしては、目覚ましの代わりに、朝になったらＴＶをつけるリモコンとか、旅行で留守中にもＴＶをつける偽装留守装置とか、外出先から家電操作とかのネタはあるのだろうなぁ・・・でもニッチ需要だけど。

• 既存の（要らなくなった）赤外線リモコンをＰＣのワイヤレス（テンキー）キーボード扱いにするようなHIDデバイスなら書くことも出来る。（これもニッチだな）
  • そんなことしなくたってBlueToothキーボードを買ってくればいいだけだから。

USBシリアルファームとpic18spxファームの共存について†

• usbシリアル変換 に追記しました。

read more : usbserial

boot <ADDRESS>で割り込みベクターも一緒に切り替えるには？†

• bootloaderのfirmware内に割り込みベクターのリダイレクターを書く必要があります。

vect08_l .equ 0x5c
vect08_h .equ 0x5d
vect18_l .equ 0x5e
vect18_h .equ 0x5f

0x08: movff PCLATH,vect08_h
      movf  vect08_l,W
      movwf PCL

0x18: movff PCLATH,vect18_h
      movf  vect18_l,W
      movwf PCL

• リセット直後に vect08=0x808 vect18=0x818 に設定しておきます。
• たとえば、0x2800に置かれたファームウェアにjump(boot)するときは
• jumpの前に自身の割り込みを全て停止した後 vect08=0x2808 vect18=0x2818 に設定しておきます。

• PCLの書き換えはmovff命令が使えないので、Wレジスタ経由で書き込みしか ないような気がします。
• 上記コードのままではWレジスタが壊れるので、壊さないで任意アドレスにjmpする方法を 考えなくてはなりません。
• たぶん、リターンスタックにvectXXの値をpushした後、returnという手法になると思います。
• ところで、上記コードはWだけでなくPCLATHも破壊するのでNGです。
• つまり、フォアグラウンドで動作しているプログラムのコンテクストに何の影響も与えずに、ジャンプリダイレクタ を書かなければなりません。(少なくともW,STATUS,PCLATHの値が変わってはいけません)

はたして可能なんでしょうか？

• こんな具合に、間接jmpすら満足に出来ないPICです。

『Google TV』で、コンピューター業界がピンチに？†

• http://wiredvision.jp/news/201003/2010031920.html
  
• それ、何ていうネットブック？
• Atom使用。
• （たぶん）Chromium OS , Chrome ブラウザー
• インターネットが閲覧できるＴＶセットトップBOXといえばAppleTVか。（流行ってないけど）
• 普通にネットブックを大画面ＴＶに繋いだのとどこも変わらん。
• ところが、今のN450にはHDMI出力が省かれている。これはintelの嫌がらせだ。
• しかしAtomではＨＤ動画の再生不可なので、皮肉なことにnVidiaのIONのようなアクセラレータが必要だ。

どうやら、使う石はAtomそのものではなくて1.2GHz駆動のAtom入りSoCになるらしい。

• http://journal.mycom.co.jp/news/2009/09/25/067/index.html
• で、一応mpeg4デコーダーはチップセット側が持っている。
• 何故にARMではなくてAtomなのか。
• 単にCE4100の使い道を模索してるだけ、なんだよね。

PIC24Fの使い道†

これだ。　つ・・・?・?・?

• http://www.picfun.com/PIC24F/AP/app24F07.html
• ということはRGB接続のパチンコ液晶ジャンクも頑張ればドライブできるかも。（手持ちが１個あり）
• 考えようによってはPIC１個が昔のＶＤＰ並みの仕事をするわけね。（モノクロだけど）しかも昔のＶＤＰのＶＲＡＭって２ｋＢとか６ｋＢだったからPIC24F内蔵SRAMのほうが多いじゃん。

• やっぱりＳＰＩをシフトレジスタ代わりに使うのね。思ったとおり。

• PIC18FのＳＰＩはひどいエラッタ（送出開始タイミングとクロックフェーズが全然かみ合ってないのでグリッジが出る）があって使えそうにない気がしたのだが

PIC18F:間接分岐のコード†

思いついたのでメモしておく。

vect08_l .equ 0x5c
vect08_h .equ 0x5d
vect18_l .equ 0x5e
vect18_h .equ 0x5f

0x08: rcall 0x0a
0x0a: movff tosh,vect08_h
      movff tosl,vect08_l
      return 0

0x18: rcall 0x1a
0x1a: movff tosh,vect18_h
      movff tosl,vect18_l
      return 0

• と書いたが、実はrcallするよりpushのほうが1cycle節約できる。
• tosuの書き込みは省略。

ただし、これら技法を使うためには0x5c〜0x5f（実はmovffを使うのでここではなくてもどこでも良い） をリザーブしておく（つまり、使用したりゼロクリアしたりしないようにする）必要がある。

PIC18spx:赤外線リモコン解析機能にSONYモードを追加†

• SONYのリモコンをいくつか試してみたけれど、コードの割り当てがかなり投槍というかその場しのぎっぽい。
• まず、ビット長が適当。といういか可変
• 機種別コードのようなものもかなりいい加減。
• 当然のことながらメーカーコードもない。（ソニー一社なので）
• で、なんとエラーチェックのＣＲＣのようなものがない。
• かわりに大量に同じコードを送出しているようなので、おそらく同じコードがいくつ以上来たら正解、みたいな判別をしているに違いないと予測。

• ドキュメントは書いてないけどAHEAとSONYを自動判別してダンプするようにしてみた。

read more : pic18spx

• NECのリモコンは持ってないんだな。たぶんAHEAとの違いは送出バイト数が6->4に減るのと最初のプリアンブルビットの長さが長くなることくらい。（なので改造は簡単）

ジャンク箱に賞味期限切れのＣＰＬＤ/ＦＰＧＡが入っていた。†

両方ともAlteraだった。

DesignWave 2003-1 EPM7256A

DesignWave 2003-10 EP1C3

そろそろ処分しないとヤバい。

• もう一個 Latticeの奴まである。

• そういえばDDT誌の前身はDesignWaveだったか。

• どれだけ放置してるんだか。

こいつらは、メーカー提供の論理合成ツールを使用しない限り、ロジックを焼きこむことは不可能なので ツールが（なるべくなら無償で）提供されているかどうかがゴミになるかどうか分かれ目になる。

とりあえずUSBダウンロードケーブルでも作ってみよう。

（というか本題はUSBダウンロードケーブルを作ることであって、FPGAをどう使うかというのはここでは全く持って考慮されていない）

次世代原子炉†

ビル・ゲイツ、原子炉に興味を持つ - スラッシュドット・ジャパン

• http://slashdot.jp/hardware/article.pl?sid=10/03/23/0225209

• オクロの天然原子炉みたいなやつなのか？

• 革新的原子炉ＣＡＮＤＬＥみたいなやつ？日経サイエンスにも昔記事が出てた。

• どっちにしても出力を細かく制御するのが難しそうだなぁ・・・。

• これって制御棒が（あんまり）ないから炉心緊急冷却とか難しくね？
• 地震国日本ではちょっと難しいかな。それとも地震が来ても運転し続ける？炉が大丈夫だとしてもタービンとかはさすがにダメージ受けるだろうし。

• とにかくウラン燃料の利用効率が大きいのでウラン代が節約できて比較的メンテナンス性は良いのだろう。
• 劣化ウランが使えるといっても、使用済み核燃料から金属のウランに加工しなければならないわけだからそれなりに再処理は要るだろうが、
• 劣化ウランを弾頭なんかに使わずに燃料として燃やせるんだったらいいことづくめじゃないかこれ。

賞味期限切れのＣＰＬＤ/ＦＰＧＡについて†

• kugaさんから教わったとおり、EPM7256Aはほんとに賞味期限切れだった。
• AlteraにしようかLatticeにしようか迷ったけれど、結局LatticeXP2用のispLeverなどをLatticeのＨＰから ダウンロードしてインストールした。
• ライセンスもWeb経由で発行してもらった。メールはすぐ来た。
• あとはUSB Blasterを作成して（というか18F2550基板はあるので、Lattice基板へ繋ぐコネクタ周りの配線などをすればいいだけ）Ｌチカを焼いてみるという手筈。

• jtagケーブルって、なんでこう、メーカーごとにバラバラなんだろうか・・・。
• jtagのプロトコルも、ターゲットごとにまるっきり互換性ないようだし。

さて、どこまで根気が続くだろうか。

↑改造前の18F2550基板：これに3.3VレギュレータとJTAGコネクタを乗せるだけの簡単なお仕事です。

とりあえず今日の釣果

• PIC18F2550基板に3.3Vレギュレータを追加してみた。
• 試しにPICの供給電圧を3.3Vにしてみた。
• 一応ブートローダー経由でsa89a.netさんのUSB Blaster（もどき）のHEXをそのまま書き込むことが出来た。

• USBに挿すとUSB Blasterとして認識するも、ドライバーが無かったので、（Alteraデバイスを繋ぐ予定は無いけれど）QuartusII Standalone Programmerをインストールして、USB Blasterのドライバーを入れてみた。
• QuartusII Programmerソフトを起動して、USB Blasterとして認識されているところまで確認した。
• すばらしい

• あとはjtagコネクターの配線を６本ほど済ませれば終了するんだけれど、ARMの20pin jtagとピン配置がとことん違っているので、やる気を失った。

• 実は、jtagケーブルなんか作る気も無く、5V<->3.3Vレベルコンバータを乗せる気も無く、抵抗すら入れる気も無くFPGAとPICを直結しようとしている。（なんというズボラ配線）

• それで、PIC基板とFPGA基板同士を直接PINヘッダーのオスメス直結にしようと思っているんだけれど、
• ARMと共用に出来なくてただいま憤慨中。
• とか言ってたら、20PINのピンヘッダー（メス）１個だけでLattice/NXP両用の接続が出来るアクロバティックな方法を思いついた。
  • NXP基板のjtag信号のGNDは１本(Latticの７番ピン位置のGND)だけ残してピンを抜く。
  • 抜いたGND部分にはLattice側のTDIとかTMSとかを繋ぐ。
  • NXPのTDIとかTMSはそのまま繋ぐ。
• 基板直結なので、GNDを信号線の間に全部渡す必要もない。

今月の残り作業予定†

• ＦＰＧＡ基板（LatticeXP2）でＬチカ。（これ基本）
• hidmon-2550/hidmon-14kのソース整理。
• hidmon-2550/hidmon-14kのHID転送モードをインタラプト転送に戻す。

毎度のこと思うのだが、Ｃ級出版雑誌付録の基板はＬチカだけしかやってないよなー。

そんなにＬチカしたいなら、自己点滅するＬＥＤを秋月で買ってきて、互換機BIOS時計用のリチウム電池を直結すればいいじゃんとか思ったりする。 --- じゃあ、これからの付録は全部そうなるのか。

こんなのがでたんだけど？

• KORG、6,300円のコンパクトなアナログシンセサイザー「monotron」を発表
• http://slashdot.jp/articles/10/03/25/0719259.shtml
• アナログシンセは高校のとき物理部で２ポリのポリシンセを作ったし。
• 自分でもオペアンプ等でモノシンセを作ったんで、この形状にはものすごいデジャブーがある。
• あの時代は２ポリが限界なんだ。なぜかというと鍵盤ＳＷは抵抗ラダー（全部直列）と検出バー間に配線してあって、２音同時押しすると２つのＳＷによって抵抗がショートされて、（抵抗ラダーには定電流が流してあるので）ラダー全体の電圧がショート長だけ下がる。

GND -*- R -*- R -*- R -*- R -*- R -*- R -*- R -*- R -*---   <--（＋）定電流源
     |     |     |     |     |     |     |     |     |
    SW    SW    SW    SW    SW    SW    SW    SW    SW
     |     |     |     |     |     |     |     |     |
     *-----*-----*-----*-----*-----*-----*-----*-----*--->低いキーの検出電圧.

     高いキーの電圧＝低いキーの検出電圧＋２キー同時押しショートで減った分の電圧。

• そいて、検出バーの電圧と、ラダー全体が下がった分の電圧を足し算すると高いほうの音の電圧が得られるという仕組みだった。

• ３音以上押しても、一番低い音と一番高い音しか出せない。中の音の電圧を検出する手段がないのだ。

LatticeXP2 FPGA基板でＬチカ成功！†

• XP2Writeにて書き込み中

read more : LatticeXP2

arm/OpenOCDのUSB Blaster対応†

http://www.pwv.co.jp/~take/TakeWiki/index.php?arm%2FOpenOCD%E3%81%AEUSB%20Blaster%E5%AF%BE%E5%BF%9C

• というページを発見（いやGoogle先生に尋ねただけ）
• sa89a.netさんのUSB Blaster(もどき)でも行けるのかなぁ・・・
• もし行けるんだったら、ARMのデバッグやROM焼きのためのUSB JTAGケーブルを、わざわざARMを使って作るという愚行をしないで済む。（これも一種の鶏卵問題なので、ブートストラップのためにFT2232Lを使ったJTAGケーブルを用意しなければならない。）

• ていうか、上記USB Blaster（もどき）の20Pin JTAGの残りを配線して、NXP ARM付録基板に挿せば解る事。

配線してみた。

• 結果は敗戦
• QuartusIIのProgrammerを立ち上げて、Device DetectさせるとエラーしてJTAG Debuggerを立ち上げるかどうか聞いてくる。
• JTAG Debuggerで見ると、デタラメなデバイス多数かエラーしか返ってこない。
• LatticeXP2を繋いだときは正しく（というかAlteraではないのでQuartusIIがサポートしないデバイスIDが）１つだけ表示される。
• 配線チェックしてみたが間違ってない。
• ただし、NXPのJTAGにはRESETとTRSTという端子が出ていて、そこには何も繋がなかった。（何を繋げばよいか分からなかった）

http://www.altera.co.jp/literature/ug/ug_usb_blstr_j.pdf

• まず、SPIエラッタ回避のためのTCKの初期化時Hi-Z化を行っているけれど(NXP側がPullUPしている為)それが無効になっている可能性、
• それとNXP ARMのTCKはFOSC/64にすると動くと言うことをkugaさんに教えていただいた。
• Hi-Z問題に関してはTCKプルダウンで、
• SPIクロックについてはFOSC/64(750kHz)のファームを焼いて試してみたところ、数回の試行をすれば、ARMのIDが返ることがある、というところまで確認して力尽きた。
• なんとなく、他の信号線のHi-Zも気になっているし、SPIのエラッタも酷いのでソフトSPIの速度をさらに落とせば動くのかもしれないという予想だけ立てて終了。
• すなおにFT2232LでOpenOCDハードを作ったほうが良いのかもしれない。
  
  
  

interface誌2010-6(4/24発売)￥2,310：こんどのＬチカは凄いぞ！†

• http://www.kumikomi.net/interface/editors/2010/03/interface6sh-2.php
• http://japan.renesas.com/company_info/news_and_events/press_releases/press_release20080512.jsp
• SH-2A
• RAM容量 なんと1MBしかもオンチップ。外付けＤＲＡＭ不要でグラフィック表示も可能。
• クロック144MHz
• 480MbpsのUSB2.0インターフェース内蔵。
• なんとFPU搭載これはＣ級出版業界初？なのか。（違ってるかも）
  • MP3専用デコーダーチップなどに頼らずにmp3デコード可能かも--だけどDACは乗ってないので外付けするかSPDIFのようなもの経由で出す必要あり。
  • FM音源をやらせれば最速（ポリ発音数が他のマイコンを抜いてダントツ）かもしれぬ。
• SH-2AはSH-2の２倍の性能
  • SH-2A CPUは、スーパスカラ方式の採用により、2命令同時実行が可能で、従来のSH-1やSH-2に比べて、飛躍的な性能向上が図られています。
• 「SH7262」「SH7264」はVDPまで内蔵
  • 画像および動画出力用に、最大WQVGAサイズ（480×240画素）のRGB565形式（1色を、R［赤］用5ビット、G［緑］用6ビット、B［青］用5ビットの合計16ビットで表現する形式）のデジタルRGB出力端子を備えています。これらの機能内蔵により、リアビューもしくはサイドビューカメラ表示を行うカー・インフォメーション機器やミッドレンジおよびローエンド版グラフィックダッシュボード機器などの部品点数を削減でき、低価格化が図れます。

• チップだけのサンプル価格は1700円〜。

内蔵RAM 1M バイト （ビデオ表示用、内 32K バイトをデータ保持用と共用）
       64K バイト （高速内蔵メモリ） 
キャッシュメモリ 16K バイト （命令 8K / データ 8K分離、 4ウェイセットアソシアティブ方式） 

ブートモード０： CS0空間に接続されたメモリからブート 
ブートモード１： シリアルフラッシュメモリ（高速通信）からブート 
ブートモード２： NAND フラッシュメモリからブート 
ブートモード３： シリアルフラッシュメモリ（低速通信）からブート 

ブートさせるにはいかなる方法であれ外部に(Flash)ROMが必要らしい。

これだけ、これでもか仕様満載の超高級マイコン。

• これでＬチカだけやるっていうのもすごいテクノロジーの無駄使いのような気がしてきたところ。（基板を開封すらしない人もいると聞くけど。）

今月のまとめ†

• PIC24Fライター--完成
• ＦＰＧＡ基板（LatticeXP2）でＬチカ。--完了
• ＮＸＰ基板でOpenOCD --玉砕
  • USB Blaster(もどき)ではCLKが速すぎるらしい。
  • TCKをFOSC/64(750kHz)に落としたハードSPIは不安定。
  • WAITを入れたソフトSPIも同様に不安定。
  • 別の原因かもしれない。ソフトSPIをさらに遅くしてみる？
• hidmon-2550/hidmon-14kのソース整理。--整理だけはした。
• hidmon-2550/hidmon-14kのHID転送モードをインタラプト転送に戻す。--出来なかった。
  • EP0バッファのサイズを64->8にしたら不明なデバイスになる。
  • Get_Descriptorで返すデータを8byte分割転送する処理で DATA0/DATA1切り替えが出来ていない。
  • 原因は元々のアセンブラかその元のＣソースにあったbugのような気がする。
  • 修正箇所を探し中。時間が掛かるかも。

結果判明†

• DATA0/1をフリップする処理が最初から間違っとるやんけ

usb_sm_ctrl_in_tx
;        USBCtrlTrfTxService();
;        if(short_pkt_status == SHORT_PKT_SENT){
;            // If a short packet has been sent, don't want to send any more,
;            // stall next time if host is still trying to read.
;            ep0Bi.Stat._byte = _USIE|_BSTALL;
;        }else{
;            if(ep0Bi.Stat.DTS == 0)
;                ep0Bi.Stat._byte = _USIE|_DAT1|_DTSEN;
;            else
;                ep0Bi.Stat._byte = _USIE|_DAT0|_DTSEN;
;        }

		; FSR0 must	be pointed to BDT_STAT(ep0Bi)
		rcall	usb_sm_ctrl_tx
		lfsr	FSR0, ep0Bi		;;BDT_STAT(ep0Bi)
		movlw	(_USIE | _DAT1 | _DTSEN)
		btfss	INDF0, DTS		; BDT_STAT(ep0Bi) ＜＝犯人はコイツ
		movlw	(_USIE | _DAT0 | _DTSEN)
		movwf	INDF0			; BDT_STAT(ep0Bi)
		return

• オリジナル版がそもそも間違っている。
  • オリジナルはEP0_BUFF_SIZEを64で使っているので、たまたまDATA0/1のフリップが起きない。
• だからbtfssとかbtfscは嫌いなんだ！

目次†