posted by rerofumi

2007/5/2 水曜日 3:40:25

プレイができるところまでできた。
–> Flash video
上のビデオは撮影用に右側のパドルを玉と同じ高さになるオートモードにしてある。それゆえ挙動がおかしいのは気にしない方向で。
ボールはパドルで打ち返す度に速度を増していく、8往復でスタート時の倍くらいの速度。パドルの中央で返すとボールは鋭角で(相手に向かって)飛んでいき、パドルの端で返すと鈍角(上下の壁に向かって)飛んでいく感じになるので、対人間戦だとわりとボールが散らばるはず。

ソースコード(CY8C29466用プロジェクト)
ntsc_pong.zip

テスト回路はこんな感じで作成。

回路図。

今回どうしてもボリュームでダイアル式のパドルコントロールにしたかったので、入力に ADコンバータを使ったのだけれども、PSoC の ADC モジュールはカウンターと割り込みを組み合わせて計測するためその割り込みタイミングでソフトウェア CRTC が乱される罠。
上のほうで歪んでいるのはそのため。
まあ、そのへんあきらめて取り敢えず完成させてみようかといった方針なので放置の方向で。
右のパドルが左側によっていて、都合ゲームフィールドが狭くなっているのも色々と苦しいところがありまして。

取り敢えずできたので良しとしようか。
PSoC は色々とラクチンで便利なんだけれども、問題点があることも今回見えたかなー。
タイミングクリティカルな処理にはどうも弱いというか。そういったところは、デジタルモジュールで簡潔させて、プロセッサコアを持ち出さない様にするしかない感じかな。

posted by rerofumi

2007/4/25 水曜日 23:49:29

スコアの表示部分ができた。
いっぱいいっぱい感が醸し出すテイスト。

今日はそんだけ。
—–

posted by rerofumi

2007/4/23 月曜日 5:02:18

エレキジャック Vol.2 の発売日も近づき、目次紹介が エレキジャックBlog の方でされている。
今回の工作例は「無線」で、入門記事は「PICマイコン」という感じらしい。
その PIC マイコンの記事に「TVゲームの作成」というのが目立っている。
この PICマイコンとコードによるタイミング生成を行ったソフトウェアCRTCとによる、ブレークアウト(ブロック崩し)は応用例の極み的なものであり、なんと発表は丁度10年前の事である。10年経っても色あせない秀逸な作品だ。
まあ、その10周年に CQ出版で再掲載されるというのも何かの巡り合わせなのかもしれず。

関連はないけれども、オライリーの Make: 日本語訳版 Vol.2 の後ろの方にある雑情報のところに伝統的TVゲーム「PONG」の電子工作キットが紹介されている。
実はこのキット、マルツにて「古典的テレビゲーム」の名で購入することができる。
Make: の前に見かけて買ってあった次第。

部品数が少なそうなのでどういう回路で構成されているんだろうとワクワクしていたが、見てみたら PIC16C505 がちょんとあるだけだったのでがっかり。
結局 PIC マイコンとソフトウェアの頑張りで実装されているに過ぎなかったわけだ。
(原始のPONGやTVテニスはTTLロジックのかたまりで実装されていた)

実はうちでも以前、それら先人の活躍にあこがれて TV 出力にちょっとだけ挑戦している。
その時の感触で、プログラミングのシビアさとか色々な難しさが見えたので、やるのならかなり本腰を入れる必要がありそうだと思った次第。

でもやっぱり TV 出力や CRTC(CRT Controller)は私にとってのあこがれであり、いつかはやってみたいということであきらめきれなかったのですよね。
やりたいゲージも溜まりまくったので、いっちょ動くかと腰を上げた次第。

取り敢えず、PSoC に抵抗を 2本繋いだだけのお気軽基板にてスタート。

これで PONG を作ってみよう、と。

実際にテストで画を出してみると、どうしてもエッジががたがたになる。

このジッターがなぜ生じるかというと、PSoC のアーキテクチャと割り込みによる。
PSoC は一般的な 8bit CISC アーキテクチャで、1命令に要するクロックが 4〜13 clock と命令によって異なっている。一方、割り込みはトリガが来たときに実行中の命令の終了を待って、割り込みがかかる。つまり最短の 4clock 命令で回していても、割り込みトリガのタイミングによって、実際の割り込み作業が開始されるまで 1〜4Clock の遅れを生じ、その数値が予測できない。
TV画面上のエッジがのこぎり状になっているのはこの 1〜4Clock のズレが見えているからである。つまり、24MHz という早そうなクロックであっても、TV 信号の上では十分に大きく目に見えるくらいの変化として現れてしまうのだ。
たぶん。

PSoC で TV 出力というと VSoC 等のアプリケーション例が既にあるので、ちゃんと作り込めばいくらかマシにできるのだろう。
今回は、修行ということで完成度は問わずに、このぎざぎざのまま一回 PONG をつくりあげてしまおうと思う。

まだ表示実験だけで、PONG のゲームとしての部分は作っていないけれども、動き始めたあたりで載せ。
試しにボールを動かしてみているところ。出来としては全然駄目だけれども、それでもボールが動き始めた(というか表示がちゃんとできた)時には軽い感動を覚えてしまうあたり。
やっぱり作ってみると色々な事がわかって知識と力になっていくもんだ。
雰囲気のために動いているところを撮影した Flashビデオがこちらに。

ハードコーディングなんで見てもしょうがないけど、ソースコードはこちら。
psoc_ntsc_pong_00.zip

下の部分に数字 1桁のスコアを表示させようと、コーディング中。
—–

posted by rerofumi

2007/4/19 木曜日 1:09:47

取り敢えず、調べてみたもののちとめんどくさそうだということでお蔵入り。
解析結果だけ置いておく。

■ 要求項目

「Wii のバーチャルコンソールを『ジョイスティック』で遊びたい」

そのために。
Wii リモコンに、クラシックコントローラの代わりにジョイスティックを接続したい。

それを実現するためには。
クラシックコントローラと同じプロトコルで通信し、クラシックコントローラを名乗るようなマイコンのソフトウェアを作成すれば良いだろう。後は、マイコンに任意の入力インタフェースを繋いでバーチャルコンソール遊び放題。

■ というわけで

Wii リモコンと拡張コントローラの通信を調べる。

■ 前提、調査前にわかっていたこと

Wii リモコンと拡張コントローラは I2C で通信を行っている。

先人による調査結果がいくつか存在する。
中でも WiiLi.org が一番情報も多く良くまとまっている。
だが、それらは全て Bluetooth 経由で PC から Wii リモコンを見ている時のものなので、ダイレクトにクラシックコントローラとお話した人はほとんど居ない。つか、そういったことをしようという目的が今まで無かったのだと思われる。

以下、概要。

・I2C バスは 3.3V でプルアップされており、クロックは 400kbps
・クラシックコントローラのスレーブアドレスは 0x52
・ヌンチャクのスレーブアドレスも 0x52
・クラコンかヌンチャクかは接続後 ID で判別し、対応を分ける
・I2Cデバイスとしては一般的な、送信データ先頭の1バイトを内部アドレスとして以後のデータはその内部アドレスからインクリメントされていく方式
・内部アドレスは 8bit(=1byte) 00h〜ffh
・内部アドレス 00h から 6byte 読み出すとそれがパッドの情報
・内部アドレス 40h に 0x00 を描き込むとデバイススタート、これを行わないとデータが出てこない
・送られてくるデータは暗号化されている

■ プロトコルを調査してわかったこと

単純にスレーブアドレス 0x52 の I2C デバイスをぶら下げてもパッドとして認識されない。Wii リモコンは拡張コントローラが接続されたときに確認のため、なにかしら認証通信を行っているはずである。
ケーブル内、白いコードがコントローラ内部で GND に結線されている。Wii リモコン本体はおそらくこれが GND に落ちることで、拡張コントローラが接続されたものと認識し、handshake を開始するものと思われる。

以下が接続時のプロトコル。
後述するけれども、値が毎回変わるので一例として。

ここから – – – – – – – – – – – – –
A4 F0 AA
A4 40 A4 DD 6D 0C 2F 7E
A4 46 F2 83 D4 E0 FD 26
A4 4C E3 B3 98 67
A4 FE
A5 B9 80
A4 00
A5 F0 9C D1 A6 3A EF
A4 00
A5 F0 9C D1 A6 3A EF
A4 00
A5 F0 9C D1 A6 3A EF
A4 20
A5 70 40 CD B0 1C 6F A3 FE
A5 EC 92 3F 24 1A 8F 3D B7
A4 30
A5 70 40 CD B0 1C 6F A3 FE
A5 EC 92 3F 24 1A 8F 3D B7
A4 00
A5 F0 9C D1 A6 3A EF
A4 00
A5 F0 9C D1 A6 3A EF
(以後パッドデータ通信が続く)
– – – – – – – – – – – – – ここまで

最初の F0h に 0xAA を書き込んでいるのは意味が無くて、おそらくコントローラの存在確認。
ここで ACK が返ってきていれば、コントローラが接続されているものと判断できる。

40h から 16byte 書き込んでいるが、この書き込む値は 16byte とも毎回異なっている。これが、暗号の鍵でこれによって以降コントローラが返す値が暗号化される。

次に FEh から 2byte 読み込んでいるが、ここで既にデータが先の鍵で暗号化されている。この 2byte がコントローラの種別を表す ID でヌンチャクとクラシックコントローラで異なっている。
ちなみにクラシックコントローラの時、素のデータは 01h,01h である。

00h から 6byte の読み込みはパッドデータの受信。
6byte のパッキングフォーマットは WiiLi.org の情報を参照する。

パッド情報を 3つ拾った後おもむろに 20h, 30h から 16byte ずつ読み込んでいるが、これはコントローラ個別のキャリブレーションデータではないかと言われている。基本 20h と 30h は同じ値が書かれている。冗長性(データが壊れたときのフォロー用)のためにセットであるのではないだろうか。値の意味は判明していない。
このデータは個体別で、同じヌンチャクであってもコントローラ毎に違う値を持っている。
おそらくは、先に 3つ読んでいるパッド情報とこのキャリブレーションデータから、なんらかの初期状態を読み取っているのだと思われる。

以降は 00h からパッド情報を読み取るだけとなる。

暗号については、40h に 0x00 を書き込んだとき、
x = (y xor 0x17) + 0x17 の x が送信されることがわかっている。
この 0x17 が暗号の鍵から生成されたシードで、鍵によって毎回変化しているのではないかと思われる。

■ というわけでひとまずあきらめ

実装をするためには、鍵とシードと暗号の関係をほぐさないとならないので今回はひとまずあきらめる。
といっても、特定条件時のシードはわかっているし、FEh からの固定値もわかっているので、後は何回かデータを収集して法則性を見つけるだけだとは思う。

ちなみに、マイコンにクラシックコントローラを繋いで入力インターフェースにすることは問題なくできた。でもそれは今回の要求ではないのです。

こんなところからマイコンシリアル通信に触れてみませんか？(とかいう

posted by rerofumi

2007/4/18 水曜日 3:48:26

ちょいと、I2C通信している機器のパケットを覗いてみたくなったので V850 基板をそれに用いる。
I2C のバスに GPIO をオープンドレイン接続で繋いで、あとは CPU フルパワーでポーリングしながら信号の上がり下がりを眺める作戦。V850 ほどの速度で動作するプロセッサだったら 400KHz の通信もなんとか処理することができるので。
当初は書き捨てのコードでちびちび調べていたのだけれども、もちょっと手を加えると普通にバスアナライザというか、バスモニタになるんじゃないかと思って作り込んでみた次第。

操作用のボタンを追加。

配線はこんな感じで。

機能は「スレーブアドレス一覧表示」と「特定スレーブのパケットキャプチャ」の二つ。
メニューにてどちらかを選択。

パケットからスレーブアドレスを抽出、ユニークアドレスを見つけたら表示していく。
写真の例では 0x58 と 0x52 二つのスレーブ相手の通信をしている状態。
LCD の表示領域の関係で、16個までの表示。
下(P42)ボタンを押すとメニューに戻る。

パケットキャプチャは特定スレーブアドレスのみをロギングする。
キャプチャを選択すると、取り込みたいスレーブアドレスの設定画面となる。上下でアドレスを選択して、真ん中のボタンでキャプチャー開始。

キャプチャしたパケットはマイコン内メモリにストアされる。
バッファは 10000Byte 用意してありそれがいっぱいになるか、下ボタンで停止するまでキャプチャを続ける。
キャプチャ停止したら、それを uart0(CP2102が繋がっている所)へ出力するので PC のシリアルコンソールで受けて表示させる。

B0 37
B1 FF FF FF FF FF FF FF FF
B1 FF FF
B0 37
B1 FF FF FF FF FF FF FF FF
B1 FF FF

こんな感じで 1パケット 1行の形でシリアル出力される。
頭の 1Byte は上位7bit がスレーブアドレスで下位bitが送受方向。

とまあ、ちょいとした調査には使える感じに。
ちゃんとした計測器を買おうとすると結構なお値段するところを、マイコンとプログラムで簡易ながら実現してみちゃおうというのはマイコン工作のひとつの楽しみ方ではありますな。
まあ、あくまでもどきなので、こんなこともできますよといったところまでに。

ソースコード。
v850_i2c_capture_070418.zip

posted by rerofumi

2007/4/14 土曜日 22:43:35

Interface の V850 付録基板で何か始めてみようかと考えを巡らせていた。
取り敢えずは実験用の母艦と LCDモジュールでしょ。
動作の様子を確認する手段として、LCDモジュールに数値やメッセージを表示するというのはマイコンにおける基本事項みたいなものではないかと。まあ、シリアルコンソールに出力するほうが容易ではあるけれども、LCDの方が一瞥で確認できるのでうれしいのですよ。

LCDモジュールの扱いは簡単だけれども、スクラッチで表示プログラムを作成しようとすると意外と手間だったり。イニシャライズとBusyチェックに手数がかかるんだよね。
なので、最初にLCDコントロールを作ってしまって後々(みんなで)使い回して行こうという感じになるかと。

ソースコード。毎度の事ながら利用はフリーで。
v850_lcd_module_070418b.zip

アーカイブ内の lcd_module.c/.h が LCDモジュールライブラリ。
このソースや手元の実験基板での結線は、
(LCD) -> (V850) – (付録基板のコネクタ)
DB4 -> AN8 – 2-9
DB5 -> AN9 – 2-33
DB6 -> AN10 – 2-34
DB7 -> AN11 – 2-35
RS -> P03 – 2-29
R/W -> P04 – 2-30
E -> P06 – 2-32

できるだけ機能として使わなそうなピンを選択はしているつもり。
それ以外の結線で使う場合は lcd_module.h 内のピン定義を変更することで変えられる様にはしているけれども、実際は諸々の設定の関係でコード内に手を入れることになるかも。

なお、ソースコード自体サンプルプロジェクトであるけれども、ブートシーケンスである bootup.s (crtE.s) とディレクティブ指定の lcd_module.dir に手を加えて MINICUBE2 でデバッグできるよう必要なリソース設定を行っている。
それ故、いくらかリソースを無駄に確保しているけれども、通常問題はないかと。
Interface付録基板上のUSBシリアル経由でダウンロードできることはいちおう確認しています。

ちなみに、実験基板では 5V を電源としてCPU基板とLCDモジュールに与えている。
CPUからの信号線は CMOS 3.3V でLCDモジュールは 5V なのでなんも考えないで直結というのは良くないのだけれども、まあこれでも動くということで。
P7 は 5V トレラントでないから避けるべきだったか。

書き忘れ。
LCDモジュール初期化の際に数ms のウェイトが必要なので、そのためにインターバルタイマーの TM0 を使っています。
また、MINICUBE2 でデバッグスタブが使うので INTCB3R の割り込みベクタを確保しています。
使っているシステムリソースは以上。

[追記]
タイミング的に問題が見つかったのでソースコードをアップデートして差し替え。
具体的には BusyWait 時の念のためタイムアップが ClearScreen の処理完了時間より短かったので、ClearScreen の直後に何か送信するとドロップする事があった。

—–

posted by rerofumi

2007/4/10 火曜日 2:31:30

PSパッドとのシリアル通信については頭に入っているものの、それでちゃんとやりとりができるということをひとまずマイコンで確認してみるの巻。
使用マイコンは毎度の PSoC。個人的に使い慣れまくっているので、ちょいと試したい向きには(私が)楽。

使用デジタルモジュールは、シリアル通信の SPI master と、ACK 待ちタイムアウト計測用の 8bit Counter。上の二つ。
下にある 8Bit Counter は、通信を 16ms 間隔で行うためのタイマーとして使うもので、パッド間通信本体ではなく、それを駆動するため外側に位置するもの。
あと、実験確認時に LCD モジュールに情報を表示しながらデバッグしていくための、LCD ライブラリ。

PSoC の足と、PSPAD の接続は以下の様に。
P0(0) = PSPAD DAT (in)
P0(1) = PSPAD CMD (out)
P0(2) = PSPAD SEL (out)
P0(3) = PSPAD CLK (out)
P0(4) = PSPAD ACK (in)
DAT と ACK は 1kΩ程度でプルアップする。

MSX側は以下のように設定してある。
P1(0) = DSUB9-2 (down)
P1(1) = DSUB9-1 (up)
P1(2) = DSUB9-4 (right)
P1(3) = DSUB9-3 (down)
P1(4) = DSUB9-6 (TriggerA)
P1(5) = DSUB9-7 (TriggerB)
GND = DSUB9-8

パッド間通信部分は、SPI master モジュールと、8bit Counter、それと ACK 信号の GPIO 割り込みで構成されている。
まずは 1byte SPI 送信、転送完了割り込みを設定しておいて転送が終わったら 8bit COunter を start。8Bit Counter の完了と ACK 信号のGPIO割り込み、どちらが先に届いたかで次の byte に進むか、そこで終了するかの処理分け。
_startPadRead を呼び出して通信開始したら、割り込みを用いて非同期で通信が進行していくので、メイン側では m_pad_read をフラグとして監視し、これが 0 になったら通信完了と判断する。

作成したコードとPSパッドとの通信の様子。
もちろん、制作中はこの自作ロジアナが大活躍なのです。
無事やりとりできていることが確認できてよかったよかった。

ついでなので、1chip MSX のジョイスティック端子へ接続する部分も作成。
無事に動いたので、PSパッドを 1chip MSX に繋いで操作できた。

「できた」といっても、自作実験基板とそこに繋ぐケーブルで構成されている実験環境なのでバラック感満点。

なんとはなしに、この時点で当初の目的自体は達成されているような気もする。
しかし、私としてはマイコンでできるということは見えていたので、あまり挑戦的な部分はなくて今ひとつだったり。
なので PLD 版を作っていたわけですが。

今回のソースコード。
psoc_pspad2msx.zip

—–

posted by rerofumi

2007/4/8 日曜日 0:02:21

事の始まりは 1chip MSX 発売日までさかのぼる。
1chip MSX が発送となり直に到着するという状況の時に、それが届いたときの懸念が一つ存在していた。今現在 MSX で使用できるジョイスティックを所有していないということである。
メガドライブのパッドが使えなくもないけれども、あのへんもいい加減骨董品だし酷使するわけにもいかない状況。それゆえに何とかしたい。
今現在、ジョイスティックを買おうと思ったらまともなのは PS2 向けのアイテムぐらいしかなかったりする。
そこで考えた、PSパッドを MSX(兼ATARI仕様) に変換するコンバータを作れば良いのではないだろうかと。コネクタとプロトコルに関してはいわゆる藤田資料があるので、それを参照してシリアル通信するものを作れば良いわけだ。

さて、どうやって作成するか。
マイコンで作るのが王道だし実際に作例も見つかるが、今回は敢えて PLD で作成することにする。まあ、1chop MSX のロジックに組み込めるようにといった意味合いも込めてなのだけれども、実際に組み込むことはしないと思う。
ちなみにシリアル通信クロックが 250kHz なので下手なマイコンだと結構かつかつかもしれない。

CPLD実験基板上にコネクタを接続して、ロジックを作成したのが 1chip MSX の到着日。CPLD が 2個のっているのは、パッド間通信のステートマシンだけで XC9572 が埋まったので、クロック分周と 16ms トリガーをもう1個の XC9536 に移したから。
で、まあ、これが見事に動かなかったわけです。

流石にこの動作を追いかけるのにはロジアナが必要だ、というのがロジアナの製作を開始した経緯となる。

んで、ロジアナもできたのでデバッグ再開。
改めて調べてみて動いていないことを確認(苦笑)。
VHDL のシミュレーション上では期待通りの動作をしているのだけれども、CPLD に焼き込むと動作しないという状況。まあ、チップの上で動かないということはタイミングか初期値の問題かねえ。
いろいろ追ってみると、シリアライザーが DONE を返していないか読み落としているかしている模様。その周辺を読み返してみると大分怪しげなコードになっているのは確かだったり。
まあ、初めて設計したステートマシンロジックなので一発で動作するとは思っていませんでしたが。

pspad2msx_bad070407.zip
動かない物だけれども、VHDL ソースコード。

おまけ。PSパッド用コネクタを手に入れる方法。

PS パッドを PC に繋ぐための USB ジョイスティックコンバータを買ってくる。こいつのコネクタをもいで使うのです。

このコンバータ自体が通信プロトコルを観察する絶好の材料なのです。

ドライバー等を無理矢理ねじ込んでコネクタのプラスチック部分を外してしまう。

こんなふうに端子とコネクタを分離。後は端子を一本一本外していく。
その後、端子をコネクタに挿し直して、パッドコネクタの取り外し完了。

CPLD だとロジックが少なすぎて、チェックがやりにくいので FPGA 実験ボードの方に河岸を変えて調べていく予定。

—–

posted by rerofumi

2007/4/3 火曜日 3:47:38

Interface誌 2007/5 号にはCQ系では恒例となりつつあるマイコン付き基板が付録であった。USBシリアルコンバータがついていてそこ経由でプログラムとデバッグができるというあたりはちょっと良い感じではある。
なんだかもう日常的になってしまったので当初はあまり興味を示していなかったのだが、ぼんよりと読んでいるうちにだんだん V850 が気に入ってきて、ちょいとやってみようかという気分になってきた。
そういえば V810 は国産プロセッサということで憧れていたときもあったんだよなあ。その V810 の後継かー。MMU やスーパーモードが無いので高度な OS を乗せるような向きではないけれども、32bit な割にこじんまりとしたアーキテクチャがなんか和む。SH2 よりは H8/300 と同じバンドといった感じかしらん。

まず最初に調べたくなったのはチップの入手性である。まあ、Interface誌を買いあさってストックを作るというのならばともかく、後々それ以外の方法でも入手できるかどうか。
個人の趣味工作だとここが一番ネックになる。なんせ「企業にしか売りませんよ」とか平然と言って突っぱねる所が多いから。
で、V850 を個人で入手しようとするとどうかというと、実は絶望的だった。チップ購入最後の砦である Digikey で扱っていないので。
個人が Interface誌以外で手に入れる方法は全くないかというとそうでもなく。サンハヤトが NEC マイコンの一部代理店をやってくれている。78K0 を扱っているから予想つくかもね。
そこで 78K0 に混じってV850のターゲット基板が見つかるが、これが現在での個人入手できるほぼ唯一の経路っぽい。
このターゲットボードは何かというと、NEC が作って売っているチップ評価ボードで、プログラムデバッガのMinicube2 とセットで使える形になっている。安価なプログラムデバッガと評価チップボードで気軽に試してもらおうということらしい。気軽と言っても 1万5千円くらいしますが。

Minicube2 は 78K0 と V850 の両方がプログラミング＆デバッグできるというのでちょいとお得感があり。78K0 もやってみようかなあ。

てなわけでゲット。

評価ボードはこんなの。

最近のマイコンプログラム機器はちっこくて取り回しが楽やね。

さて、Interface誌の付録基板の方へお話を戻して。
NEC 純正の開発機材は上の Minicube2 なのだけれども、Interface誌付録のV850基板でもシリアル経由で書き込み、およびデバッグができるように配慮してくれている。
例えば、デバッガは ID850QB と ID850QB-MON の二つがインストールされるが前者が Minicube および Minicube2 で使われる物で、実質不要なものである。-MON とある方はInterface誌付録基板のシリアルポートに合わせたデバッグスタブを使う「特別版」の様だ。
プログラミングツールも FPL という古いツールになっている。
んじゃ、Interface誌付録基板を使うだけなら十分に環境が整っているから良いのではないかといったところだけれども、書き込みやデバッグの際にジャンパピンを設定しないとならないのがちょいと煩雑だったりする。あと、デバッガの調子が悪くてうまく動作させるためになんどか起動しないとならなかったのだけれども、これは私の運が悪かったからかもしれない。

Minicube2 を使って Interface誌付録基板の開発を行えばちょっとスマートかもしれない。そう思ってどきどきしながら接続しようとして思いっきり罠にははまる。
Interface誌付録基板にはデバッグポートと称して 10ピンの CN3 がついている。なんとなくJTAGっぽいシグナル名だから、ここにMinicube2をつなげばプログラミング＆デバッグができるもんだと思っていたけれどもそうではなかった。
確かにJTAG系のコントロールでデバッグができるのだけれども、それはMinicube「1」の方の仕様だったのだ。Minicube2はプログラミングもできるかわりにその辺の使用ピンが変わっているとのこと。なので実はMinicube2も、Interface誌付録基板上に載っているUSBシリアルコンバータ経由のプログラミング＆デバッグと大して変わらなかったりする。通信速度はMinicube2のほうが早いけれどもね。
Minicube2 でInterface誌付録基板をプログラミングしようとすると、デバッグ用コネクタではなく通常コネクタの方につなぐ必要があるのだ。

にんともかんとも。
上の写真は CSI3 での接続例。
Interface誌付録基板の下に母艦となるブレッドボードを用意して、そっちの方にプログラミング用のコネクタをつけた方がよいかも。んじゃデバッグ用 CN3 がいらないかというとそうでもなく、そこにしか来ていない線が一本(FLMD0)必要なのでどうにも美しくなく。

結論としては Interface誌付録基板で遊ぶだけであったら Minicube2 は無理に必要な物ではなさそうだ、ということで。

関係ないけれども、Minicube2のユーザー登録時に「会社名、部署、役職必須」だったのでちょっとムッとする。私は個人の趣味でこれを使いたいのっ。

posted by rerofumi

2007/4/1 日曜日 21:09:04

基板とファームウェアができたので次はそれをコントロールしウェーブデータを表示する PC 上のアプリケーションを作成。

ルーラーや間隔表示の類がまだ無いので、エッジとエッジの間が何sec なのかといったあたりがわからないけれども波形は観測できる。クロックを含むシグナルであったら信号を読むのもそれなりにできるので今のところこれでも十分に使えている。

無駄に OpenGL を使って、するするとドラッグでスクロールやズームが行えるのだけれども、わかりにくいのでその様子をムービーにしてみた。

コメ噛め-簡易ロジックアナライザームービー

途中円グラフみたいなのが出てくるのは、赤がサンプリング中、緑がシリアル転送中のプログレス表示。

ハードがないと動作しないものだからバイナリを置いてもしょうがないので、アプリのソースコードを置いておく。

komelogi-app-070401.zip

Borland Developer Studio 2006 にて開発しており、そのプロジェクトとなっている。
一応、無償で使える TURBO C++ でもビルドできるはず。

アプリの作成に併せて、ボード側マイコンのファームをちょいと変更。

logiana-070401.zip

変更点は、シリアル転送速度を 115200bps にしたのと、サンプリング周期のカウンターを調整してアプリの数値と合わせたあたり。
CPLD に変更は無し。

とまあ、これで簡単な 8ch ロジックの計測ができるようになったわけだ。
速度が 1us (1Mhz) と遅いのだけれども用途によってはこれでも使えるし、やっぱり有るとないとじゃ違うわ。
ちなみにサンプリング周期は今のままでも 6Mhz まで引き上げられるはず。
—–