2010-03

2010-02← → AVR/PIC両用ライター usbシリアル変換  usbキーボード  簡易ロジアナ、赤外線リモコン信号観測

3月兎


今月の目標

  • 赤外線でビビビ(これも既製品を買ったら敗北だ。)
  • 地アナしか映らないブラウン管テレビ(地デジTV購入とともにリサイクル行き)
  • の回収時、回収を逃れて放置された赤外線リモコンデバイスがあるので、

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

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

http://psp.dip.jp/web/jpg/PIC/infrared3.png

  • とりあえず波形観測まではOK。
  • この波形はSharpの地デジTVのもの。








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

日経サイエンス

  • http://www.nikkei-science.com/page/magazine/1004/201004_078.html
    局地核戦争であっても,その煙は太陽光によって暖められて上昇し,
    高層大気中に何年も浮遊して日光を遮断し,地球を冷やし続けることを見いだした。
  • つまり、文明の崩壊は近いのか?
    • いや、逆に考えるんだ。これをうまく使えば、地球温暖化を速やかに食い止める手段になる。
    • 印パ紛争で100発も使われるとやばいな。イスラエルとイランなら大丈夫か?
    • つまり、アメリカが戦争抑止的に使ったとしてもやばいわけだろうから。(すでに日本に対しては使用済み、核兵器)
  • なんていうのは全部冗談だ。
  • 結論として、核兵器は、「使えない兵器」なのだ。

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








秋月のPICマイコン

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

  • http://akizukidenshi.com/catalog/g/gI-03614/
  • SRAMちょっと多い(4096-128byte)18F4550は2048byte
  • Flashもちょっと多い(48kB)18F4550は32kB
  • USBはない。
  • クロックはDC〜40MHzまで。18F4550は48MHzほぼ固定運用。
品種パッケージFlashSRAMEEPROMCLOCKUSB参考価格(円)
18F452540PIN DIP48kB3968byte1024byte40MHzなし450
18F452040PIN DIP32kB1536byte256byte40MHzなし420
18F45240PIN DIP32k1536byte256byte40MHzなし600
18F262028PIN DIP64kB3968byte1024byte40MHzなし480
18F242028PIN DIP16kB768byte256byte40MHzなし300
18F232028PIN DIP8kB512byte256byte40MHzなし500
18F132018PIN DIP8kB256byte256byte40MHzなし400
18F122018PIN SOIC 1.27mm4kB256byte256byte40MHzなし500
18F24J1028PIN SOIC 1.27mm16kB1024byte0byte40MHzなし250
18F251528PIN Flat 1.27mm48kB3968byte0byte40MHzなし500
18F25828PIN DIP32kB1536byte256byte40MHzなし600
  • 参考価格はたとえば秋月の単価(変動するのであくまで参考用)
  • USB付き品種は知っているので省略している。
  • 秋月の品揃えもはぬけなんだけど、Microchipの品番の付け方は不規則で分かりづらい。
  • そのまえにUSB無し品種の使い道が理解できなかったりする。何に使うんだろう。
  • 遅くてコードサイズが膨れてもいいならPIC。そこそこ速くてコードも縮むのでFlashが少なくてもOKなのがAVR。
  • 前者の条件って、ゆるすぎ。
  • PICのほうがFlashが多いと思ったら大間違い。コード量で倍〜4倍くらいPICが無駄食いするし、速度比で最大10倍ぐらいPICのほうが遅い(AVRは20MHzだがPICは40MHzといっても4分周するので実質10MHzしかもC言語向けで無いので効率が1/5)。
  • 嘘だと思うなら同じCソースを動かして試す?といい。


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

dsPIC33FJ32GP202 450円

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

PIC24FJ64GA002:350円

PIC24の良いところ

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

欠点は、

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


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

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







dsPIC33/PIC24Fの用途

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

  • FM音源
  • けれど、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の秘密を申請特許から解き明かす - ベクトル処理と省電力機構


  • なんだ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)がうまく行かない。
  • 読み出しても常に0なのだ。
  • BitBang操作だと一応読み出せるのに何故?
  • WAITとか入れまくったけれど駄目だった。
  • 書き込みのほうは出来てるっぽい。






PIC24Fライター出来たどー

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

read more : pic18spx

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

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

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






残る課題

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

read more: pic18spx


  • 赤外線でビビビ(AVRチップを使って既製品リモコンを改造)--自分の中では需要がなくなった。
    • 予定では地デジTVのREGZAを買って(あれはTVのくせに外付けUSB HDDに録画する機能がある)
    • 改造リモコンを使って予約録画をするつもりだったのだが、
    • HDD内蔵のDIGAが安く売ってあったのでそっちにとびついてしまい、改造リモコンは不要になった。
  • なんかREGZAを誤解していたようだ。TVのくせに外付けUSBHDDに録画予約出来るらしい。
    • 改造リモコンで時間が来たら録画ボタンを押すような回りくどい処理は最初から不要らしい。

ととと・・・


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

  • しかし、TVの電源スイッチはたいていトグル式なので、TV消し信号を連続放射するって、いったいどんなコードを垂れ流すのだろう・・・。
  • 赤外線リモコンネタとしては、目覚ましの代わりに、朝になったらTVをつけるリモコンとか、旅行で留守中にもTVをつける偽装留守装置とか、外出先から家電操作とかのネタはあるのだろうなぁ・・・でもニッチ需要だけど。
  • 既存の(要らなくなった)赤外線リモコンをPCのワイヤレス(テンキー)キーボード扱いにするような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 ブラウザー
  • インターネットが閲覧できるTVセットトップBOXといえばAppleTVか。(流行ってないけど)
  • 普通にネットブックを大画面TVに繋いだのとどこも変わらん。
  • ところが、今のN450にはHDMI出力が省かれている。これはintelの嫌がらせだ。
  • しかしAtomではHD動画の再生不可なので、皮肉なことにnVidiaのIONのようなアクセラレータが必要だ。


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





PIC24Fの使い道

これだ。 つ・・・ Ν◆Ν

  • http://www.picfun.com/PIC24F/AP/app24F07.html
  • ということはRGB接続のパチンコ液晶ジャンクも頑張ればドライブできるかも。(手持ちが1個あり)
  • 考えようによってはPIC1個が昔のVDP並みの仕事をするわけね。(モノクロだけど)しかも昔のVDPのVRAMって2kBとか6kBだったからPIC24F内蔵SRAMのほうが多いじゃん。
  • やっぱりSPIをシフトレジスタ代わりに使うのね。思ったとおり。
  • PIC18FのSPIはひどいエラッタ(送出開始タイミングとクロックフェーズが全然かみ合ってないのでグリッジが出る)があって使えそうにない気がしたのだが





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


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

read more : pic18spx

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





ジャンク箱に賞味期限切れのCPLD/FPGAが入っていた。

両方ともAlteraだった。

DesignWave 2003-1 EPM7256A

http://psp.dip.jp/web/jpg/PIC/dwm0062.jpg

DesignWave 2003-10 EP1C3

http://psp.dip.jp/web/jpg/PIC/dwm0071.jpg

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

  • もう一個 Latticeの奴まである。
  • そういえばDDT誌の前身はDesignWaveだったか。
  • どれだけ放置してるんだか。

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

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

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





次世代原子炉

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

  • どっちにしても出力を細かく制御するのが難しそうだなぁ・・・。
  • これって制御棒が(あんまり)ないから炉心緊急冷却とか難しくね?
  • 地震国日本ではちょっと難しいかな。それとも地震が来ても運転し続ける?炉が大丈夫だとしてもタービンとかはさすがにダメージ受けるだろうし。
  • とにかくウラン燃料の利用効率が大きいのでウラン代が節約できて比較的メンテナンス性は良いのだろう。
  • 劣化ウランが使えるといっても、使用済み核燃料から金属のウランに加工しなければならないわけだからそれなりに再処理は要るだろうが、
  • 劣化ウランを弾頭なんかに使わずに燃料として燃やせるんだったらいいことづくめじゃないかこれ。





賞味期限切れのCPLD/FPGAについて

  • kugaさんから教わったとおり、EPM7256Aはほんとに賞味期限切れだった。
  • AlteraにしようかLatticeにしようか迷ったけれど、結局LatticeXP2用のispLeverなどをLatticeのHPから ダウンロードしてインストールした。
  • ライセンスもWeb経由で発行してもらった。メールはすぐ来た。
  • あとはUSB Blasterを作成して(というか18F2550基板はあるので、Lattice基板へ繋ぐコネクタ周りの配線などをすればいいだけ)Lチカを焼いてみるという手筈。
  • jtagケーブルって、なんでこう、メーカーごとにバラバラなんだろうか・・・。
  • jtagのプロトコルも、ターゲットごとにまるっきり互換性ないようだし。

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

http://psp.dip.jp/web/jpg/PIC/usbblast.jpg

↑改造前の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コネクターの配線を6本ほど済ませれば終了するんだけれど、ARMの20pin jtagとピン配置がとことん違っているので、やる気を失った。
  • 実は、jtagケーブルなんか作る気も無く、5V<->3.3Vレベルコンバータを乗せる気も無く、抵抗すら入れる気も無くFPGAとPICを直結しようとしている。(なんというズボラ配線
  • それで、PIC基板とFPGA基板同士を直接PINヘッダーのオスメス直結にしようと思っているんだけれど、
  • ARMと共用に出来なくてただいま憤慨中。
  • とか言ってたら、20PINのピンヘッダー(メス)1個だけでLattice/NXP両用の接続が出来るアクロバティックな方法を思いついた。
    • NXP基板のjtag信号のGNDは1本(Latticの7番ピン位置のGND)だけ残してピンを抜く。
    • 抜いたGND部分にはLattice側のTDIとかTMSとかを繋ぐ。
    • NXPのTDIとかTMSはそのまま繋ぐ。
  • 基板直結なので、GNDを信号線の間に全部渡す必要もない。





今月の残り作業予定

  • FPGA基板(LatticeXP2)でLチカ。(これ基本)
  • hidmon-2550/hidmon-14kのソース整理。
  • hidmon-2550/hidmon-14kのHID転送モードをインタラプト転送に戻す。


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

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

Lチカの方法論価格得/失コメント
自己点滅LED5個入り150円から1byteたりともコードを書かないので、バグの混入可能性が極めて低い。/インチキだと言われるLチカ目的達成法としては間違っていない
PIC/AVRなどの低級マイコン+LEDATtiny2313の場合100円〜短いとはいえ自分でコードを書かないといけない/プログラムが書けるようになったつもりになれる。そのまえにPIC/AVRライターを作らないといけない
ARM/H8などの高級マイコン+LED雑誌付録でも2980円〜C級出版の場合はLチカソフトまで付属している/財力のみで可能達成感がないというか自己点滅LEDのほうがいいんじゃない?
雑誌付録でないARM基板+LEDOlimexなら3980円〜/NXPだと3000円〜/STM8S(750円)のライター部分を使う手もあるバッドノウハウがたくさん得られる/どれも茨の道ARM JTAGライター研究中←今ここ
FPGA/CPLD+LED雑誌付録基板か、MAX2CPLD基板1600円〜VHDL/Verilogなどの勉強が出来る/テクノロジーの無駄使いJTAGライターが別途必要。パラレルポート接続なら簡単につくれる。USBケーブルはちょっと大変だけど面白いかも


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

  • KORG、6,300円のコンパクトなアナログシンセサイザー「monotron」を発表
  • http://slashdot.jp/articles/10/03/25/0719259.shtml
  • アナログシンセは高校のとき物理部で2ポリのポリシンセを作ったし。
  • 自分でもオペアンプ等でモノシンセを作ったんで、この形状にはものすごいデジャブーがある。
  • あの時代は2ポリが限界なんだ。なぜかというと鍵盤SWは抵抗ラダー(全部直列)と検出バー間に配線してあって、2音同時押しすると2つのSWによって抵抗がショートされて、(抵抗ラダーには定電流が流してあるので)ラダー全体の電圧がショート長だけ下がる。
GND -*- R -*- R -*- R -*- R -*- R -*- R -*- R -*- R -*---   <--(+)定電流源
     |     |     |     |     |     |     |     |     |
    SW    SW    SW    SW    SW    SW    SW    SW    SW
     |     |     |     |     |     |     |     |     |
     *-----*-----*-----*-----*-----*-----*-----*-----*--->低いキーの検出電圧.
     高いキーの電圧=低いキーの検出電圧+2キー同時押しショートで減った分の電圧。
  • そいて、検出バーの電圧と、ラダー全体が下がった分の電圧を足し算すると高いほうの音の電圧が得られるという仕組みだった。
  • 3音以上押しても、一番低い音と一番高い音しか出せない。中の音の電圧を検出する手段がないのだ。





LatticeXP2 FPGA基板でLチカ成功!

http://psp.dip.jp/web/jpg/PIC/lattic1.jpg

  • XP2Writeにて書き込み中

http://psp.dip.jp/web/jpg/PIC/xp2w2.png

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が)1つだけ表示される。
  • 配線チェックしてみたが間違ってない。
  • ただし、NXPのJTAGにはRESETとTRSTという端子が出ていて、そこには何も繋がなかった。(何を繋げばよいか分からなかった)

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

http://psp.dip.jp/web/jpg/PIC/ubpin.png

  • まず、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:こんどのLチカは凄いぞ!

  • 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しかもオンチップ。外付けDRAM不要でグラフィック表示も可能。
  • クロック144MHz
  • 480MbpsのUSB2.0インターフェース内蔵。
  • なんとFPU搭載これはC級出版業界初?なのか。(違ってるかも)
    • MP3専用デコーダーチップなどに頼らずにmp3デコード可能かも--だけどDACは乗ってないので外付けするかSPDIFのようなもの経由で出す必要あり。
    • FM音源をやらせれば最速(ポリ発音数が他のマイコンを抜いてダントツ)かもしれぬ。
  • SH-2AはSH-2の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ウェイセットアソシアティブ方式) 
ブートモード0: CS0空間に接続されたメモリからブート 
ブートモード1: シリアルフラッシュメモリ(高速通信)からブート 
ブートモード2: NAND フラッシュメモリからブート 
ブートモード3: シリアルフラッシュメモリ(低速通信)からブート 

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

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

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





今月のまとめ

  • PIC24Fライター--完成
  • FPGA基板(LatticeXP2)でLチカ。--完了
  • NXP基板で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切り替えが出来ていない。
    • 原因は元々のアセンブラかその元のCソースにあった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は嫌いなんだ!





目次