USB-*lasterを購入した。
早速、中を開けてみると、FTDIのチップと、CPLD、MAXIMのレベル変換ICが入っていた。
CPLDの横には、JTAGコネクタと思われる興味深い10ピンのジャンパがある。
JTAGコネクタを見るとMITOUJTAGをつないでみたくなる。
ここにByteBlasterIIをつなぎ、MITOUJTAGを起動。
さらに、MITOUJTAGでロジックアナライズしてみる。
だいたい、どのピンがどういう役割かはわかる。
某(?)CPU用のエミュレータ機能を追加する作業を行っています。
メモリ・レジスタの読み書きや、シングルステップ実行、ELFファイルのダウンロード＆実行などができるようになりました。このCPUは32ビットCPUですが、命令は16ビットなので、ちょっと苦労しました。
Linux動作中に突然CPUを止めて、ステップ実行させるなどということもできるようになりました。
しかし、Linuxを実行しているシステムで、JTAG ICEを使ってメモリ上の任意の領域に勝手にファイルをダウンロードして実行させようとすると、さすがにメモリ保護で検知されてリセットがかかったりするようです。JTAG ICEとLinuxを共存させるには、どうすればいいのでしょう。
今のところ、安定性は、100点満点で59点くらいです。もうちょっと安定に動作するように改良していきたいところです。
ともかくこれで、同じフロントエンドで３つのCPUに対応しました。
次は、フロントエンドの改良とGDB/Insightへの接続を目指します。
今日は、打ち合わせのため朝から新横浜へ。
東京から新横浜の間はもちろん新幹線。
新幹線に乗るというだけで、ちょっと嬉しくなってしまう。
帰りは品川で降りて、山手線で新橋へ行き、日本で一番辛い(と思われる)味付けの四川料理屋で昼食。
その四川料理屋は日本原子力学会のビルの向かいにある。
昼はメニューは、「ランチの７番」がおすすめ。夜のメニューは「火鍋コース」がおすすめ。
今日の「ランチの７番」は坦々湯麺だった。久しぶりに辛いものを食した。
そのまま急いで帰り、仕事。
すごく久しぶりに秋葉原へ行った。
最近は、ほとんどの電子部品は通販で買ってしまっているので、めっきり行く回数が減っています。でも、秋葉原で買いたい部品もあります。それは、ネジ、プラスチックのスペーサ、ピンヘッダ、D-SUBコネクタなどです。
秋葉原に着いて驚いたのは、つくばエキスプレスが開通していたことと、駅前の広場が広くなっていたこと、ヨドバシカメラがオープンしていたこと、千石の２号店(？)の位置が変わっていたことかな。
秋葉原に行くたびに「いつの日かダイビルに事務所を構えたい」という目標が思い起こされます。秋葉原が健全な街として発展してくれますように・・・
さて、商品を買って領収書をもらうとき、「有限会社ナヒテックでお願いします」というと、なかなか「ナヒテック」と聞き取ってくれない。「麻痺テック」「泣きテック」「らひテック」などいろいろ出てくる。正しく聞き取ってくれる場合は半分くらいだろう。秋葉原ではナヒテックの知名度はまだまだ低いようだ。
今日はテクトロのオシロに装着する通信モジュールを購入ました。波形をパソコンに取り込めるのが楽しみです。
今夜の作業は、MIPS用の逆アセンブラの開発です。
MIPSの命令は、左6ビットが命令コードになっていて、64種類の命令の大まかなカテゴリがあるようです。ただし、これでは足りないので、いくつかの命令は、他のフィールドを読むことでその種類が決定されるという体系になっているようです。
つまり、階層的にできているので、何枚かの表をつくれば逆アセンブラを作ることができます。
たとえば、10100011001010010001110001011100 という命令があるとすると、左端の101000というのがopcodeを表していて、これはSB（Store Byte）という命令だということがわかります。
こんどは、000000 01001010011001011000 100000という命令があるとすると、左端の6ビットが000000です。これは"SPECIAL"という一種の命令群であって、実際の命令コードは右端の100000となります。つまり、左端がSPECIALであって、右端が100000なのはADD命令ということになります。
このように、何段かのテーブルをひくことで、MIPSの命令は理解することができます。このテーブルを引くための領域が、左端と、真中か右端に固まってくれているので、ソフトウェアで機械的に処理しやすいといえます。
一方、ARMの命令体系も同じような感じではあるのですが、命令コードを判断するためのフィールドの部分の長さや位置がまちまちだったり、飛び地があったりするので、逆アセンブラを作るのはとても面倒でした。
MIPSは、ARMよりはスッキリしていると実感しました。
作業を始めてから４時間くらいで、簡易版逆アセンブラを実装することができました。
まだいくつか解釈できない命令がありますが、全命令を実装するのは、そんなに難しいことではないでしょう。
MIPS用のJTAG ICEを開発していて悩ましいことは、イレギュラーなケースに対応させることが難しいということです。例えば、ICEが動作中にターゲットボードの電源を落としたりリセットをかけたり、または、CPUの動作を停止させたままパソコン上のICEのプログラムを再起動した場合でも元の状態に戻れるか、などという問題があります。
今夜は、MIPSのJTAG-ICEを実装しました。
とりあえず現状では、WindowsのGUI上からMIPS32に対して、
・CPUコアの停止と再開
・汎用レジスタへの、値の読み書き
・CP0(コプロ0)への、値の読み書き
・シングルステップ実行
・メモリリード・ライト
・ELFまたはMOTファイルの読み込みと実行
などができるようになりました。
昨日の状態からメインのGUIの部分には変更を加えなくとも、下にぶらさがるライブラリを変更するだけでMIPSにも対応できたので、目的の１つは順調に進んでいます。
MIPS用の逆アセンブラはまだ作っていませんが、作り始めたらARMに比べれば楽に作れるかなと楽観視しています。
MIPSをJTAG ICEでいじっていて一つ困った点があります。
一般にJTAG ICEは、特権モードよりもさらに上位の「最強モード」で動作することが多く、存在しないメモリ領域を読もうが書こうが問題にはならないと私は思っていました。しかし、MIPS互換CPUのAu1550では、JTAG ICEで読んではいけないメモリ領域(例えば0x00000000)を読むと、何らかの例外かメモリ保護が発生して、JTAGが変なモードに入ってしまい、ICEが使用できなくなってしまうようなのです。
このような状況から復帰ができるようにすることが、課題の一つです。
JTAG ICEは便利です。CPUのROMにプログラムが入っていない状態でも使うことができ、RAMやフラッシュROMなどへのデータのダウンロードができるからです。
私はこれまでARM7用のJTAG ICEを開発しMITOUJTAG BASICに実装してきましたが、これはARM7に特化した内部構造になっているため、このJTAG ICEをARM9や、MIPS、その他多くのCPUに対応させようと思ったとき、その作業は非常に難しくなると予想されました。
そこで、様々なCPUのJTAGデバッグを、統一の取れたユーザインタフェースでアクセスできるよう、新しいJTAG ICEの開発をはじめました。
このJTAG ICEは、フロントエンドのGUIの部分を変えずに、各種CPU用のJTAG ICEアルゴリズムを動的に変更させることで、様々なCPUに対応させようというものです。
開発をはじめてから３日目、ようやくARM7のシングルステップ実行と逆アセンブラが動くようになりました。ROM上に配置された命令を逆アセンブラで確認しながら、１つ１つ実行させ、汎用レジスタの変化を見ることができるようになりました。(まだ逆アセンブラ結果が少し間違っていますが)
この逆アセンブラはまだ開発中なので、全部の命令には対応していませんが、分岐命令と、LDR/STR命令、データ処理命令を実装しただけで、プログラムの大半の部分を解釈できてしまいました。
ARMの機械語は、フラグや修飾がいっぱいあって難しいです。さすがRISCといいたくなります。
某事業化情報交換会に出席。
投資家(VC)は年10倍くらいに急成長するようなビジネスを望んでいるらしいという気がした。ちょっとそれは・・。
緩やかな成長でいいから、堅実なビジネスを行うにはどうすればよいのだろうか。堅実なビジネスはVCにとってはあまり面白くないらしい。
それはともかく、いろいろな人と出会う。有意義な会であった。
VirtexII Pro内のPowePCを、PPC405のプリミティブをVHDLで直接呼び出すことで実装し、EDKを使わずにPowerPCを使う方法を研究しています。
------------------------------------------------------------
今日は、PowerPCの命令コードをブロックRAMに格納する方法を考えます。
ブロックRAMを使う場合の難しいところは、ブロックRAMはアドレスが与えられてから次のクロックの立ち上がりで、データを出力するというところです。
PPC405は32bitモードの場合、プリフェッチ動作で４ワード分の命令を要求します(デフォルト)。
VHDLのCASE文で命令をハードコーディングすれば、
------------------------------------------------------------
ステップ0:PPC405がアドレスを出力、FPGAのロジックがデコード、PPC405にアドレスACKを返す
ステップ1:+0番地の命令をPPC405に与える、データACKを返す
ステップ2:+1番地の命令をPPC405に与える、データACKを返す
ステップ3:+2番地の命令をPPC405に与える、データACKを返す
ステップ4:+3番地の命令をPPC405に与える、データACKを返す
------------------------------------------------------------
と、５クロックで終了しますが、小規模なプログラムであっても現実的ではありません。
命令コードの格納にブロックRAMを使うと、
------------------------------------------------------------
ステップ0:PPC405がアドレスを出力、FPGAのロジックがデコード
ステップ1:ブロックRAMにアドレスを与える
ステップ2:+0番地の命令をPPC405に与える、データACKを返す
ステップ3:+1番地の命令をPPC405に与える、データACKを返す
ステップ4:+2番地の命令をPPC405に与える、データACKを返す
ステップ5:+3番地の命令をPPC405に与える、データACKを返す
------------------------------------------------------------
と１クロック余計にかかります。次のアドレスを予想することで１クロック削減することもできなくはないのですが、ちょっと面倒になります。
とにかく、ブロックRAMを１個つかうことで、512ワード分の命令を自由に実行させることができるようになりました。
命令コードはブロックRAMに初期値として与えますが、初期値はUCFファイルで指定します。しかし、GCCで作ったバイナリをいちいち変換してUCFファイルにコピーペーストするのでは、ソフトウェアをコンパイルし直すたびにFPGAまでコンパイルしなければなりません。これでは時間がかかってしまいます。
そこで、JTAGを通じてブロックRAMにデータをダウンロードする仕組みを開発しています。
XILINXのFPGAにはUSER1、USER2という2つのユーザ用JTAGコマンドがあります。このコマンドを使えば、パソコンとFPGAの内部ロジックで自由に通信することができます。
しかし、USER1命令の実装は少々コツがいりますし、ハードを制御するソフトウェアもつくらなければなりませんので、デザインに合わせてすべて作るのでは大変です。
そこで、USER1命令を用いてブロックRAMの制御とGPIOを行う汎用的なマクロを作っています。このマクロはMITOUJTAGの中から操作できるようになります。またこのマクロを用いたJTAGの通信の仕様は公開する予定なので、ユーザプログラムからも容易に操作できるようになります。
このマクロをFPGAに実装すれば、FPGAが動作している最中に、MITOUJTAGやユーザアプリケーションからバイナリファイルをブロックRAMに転送したり、FPGAの内部ロジックに制御信号を与えることが簡単にできるようになるでしょう。
VirtexII Pro内のPowePCを、PPC405のプリミティブをVHDLで直接呼び出すことで実装し、EDKを使わずにPowerPCを使う方法を研究しています。
------------------------------------------------------------
今日は、PowerPCからメモリの読み書きをする方法を考えます。
PowerPCに実行させる命令コードはこんな感じです。
------------------------------------------------------------
INSTRUCTION <= bitrev(32,x"48001236");
else
case rev_PLBC405ICURDWDADDR is
when "000" =>
INSTRUCTION <= bitrev(32,x"39206f00"); -- li r9,0x6f00
when "001" =>
INSTRUCTION <= bitrev(32,x"91090008"); -- stw r8,8(r9)
when "010" =>
INSTRUCTION <= bitrev(32,x"39080001"); -- addi r8,r8,1
when "011" =>
INSTRUCTION <= bitrev(32,x"80290004"); -- lwz r1,4(r9)
when "100" =>
INSTRUCTION <= bitrev(32,x"60000000"); -- nop
when "101" =>
INSTRUCTION <= bitrev(32,x"60000000"); -- nop
when "110" =>
INSTRUCTION <= bitrev(32,x"60000000"); -- nop
when others =>
INSTRUCTION <= bitrev(32,x"60000000"); -- nop
end case;
end if;
end process;
user_PLBC405ICURDDBUS <= INSTRUCTION & INSTRUCTION;
------------------------------------------------------------
上のプログラムを簡単に説明すると、レジスタR9に0x6f00を入れ、データメモリの(R9)+8番地にレジスタR8の値を出力し、R8を1つインクリメントし、レジスタR1にデータメモリの(R9)+4番地から読み出すというものです。これを延々と無限ループします。
PowerPC405は、データメモリをアクセスしようとしたとき、１ワードのアクセスと８ワードのアクセスがあるそうです。stw命令やlwz命令でメモリへのロードストアを行った時には、１ワードのアクセスのサイクルが発行されました。８ワードというのはバースト転送の時につかわれるのでしょうか、まだそれを使う状況に出くわしていません。
データメモリへのアクセスは、C405PLBDCUREQUEST信号が'1'になった時に開始されます。このとき、アクセスしたいアドレスやR/Wの方向、バイトイネーブル信号などが同時に出力されますので、それをFPGA内の回路でデコードします。C405PLBDCUREQUESTが出力されたら、FPGA内のユーザ回路は、C405PLBDCUADDRACKを'1'にして受け取ったことをPPC405コアに知らせます。
アクセスがWriteサイクルの場合、FPGA内の回路は次にC405PLBDCURDACKをアサートします。アクセスがReadサイクルの場合、C405PLBDCUWRACKをアサートします。また、RDACKまたはWRACKがアサートされるときには、P405DCUBUSYもアサートします。こうすることで、PPC405コアは、データメモリとのアクセスに成功したことを認識するようです。
このようにして、データライトを使って、CPUのレジスタR8の値をメモリ(というよりメモリマップドIO)に書き込み、その値でLEDをチカチカさせることができました。
非常に簡単なプログラムではありますが、EDKを使わずにPowerPCが動いたと実感できた瞬間です。
今回はデータメモリのかわりにFPGA内のロジックをつなぎ、命令が格納されているメモリをVHDLのCASE文で作りました。このようなハードロジックのかわりにブロックRAMをつなげば、ちょっとしたプログラムくらいは走らせられるのではないかという気がします。
VirtexII Pro内のPowePCを、PPC405のプリミティブをVHDLで直接呼び出すことで実装し、EDKを使わずにPowerPCを使う方法を研究しています。
------------------------------------------------------------
VirtexII Pro内のPowerPCをリセットした直後、命令アドレスバスをJTAGロジアナで見てみると、0xFFFFFFFC番地からフェッチしようとしているのが確認できた。
そこで、まずはアドレス0xFFFFFFFC番地から読み出そうとした場合に、分岐命令が読み出されるように、VHDLでハードコーディングした。
------------------------------------------------
process(rev_PLBC405ICURDWDADDR , C405PLBICUABUS) begin
if(bitrev(32,"00" & C405PLBICUABUS) = x"FFFFFFFC") then
-- ba 0x1234
PLBC405ICURDDBUS <= bitrev(32,x"48001236") & x"00000000";
else・・・
------------------------------------------------
なお、0x48001236というのは、絶対番地0x1234へジャンプする分岐命令である。
PowerPCは、分岐命令に2つのフラグがあり、下２ビットが相対ジャンプ・絶対ジャンプのフラグと、リンクレジスタを使うかどうかの設定のフラグになっている。
分岐命令を0xFFFFFFFCに置いて実行させると、アドレス0x1234へジャンプするのが確認できた。
ジャンプした後、スタートアップコードが開始するわけであるが、スタートアップコードでは、データバスやアドレスバスをJTAGロジアナで観察することで、CPUコアが動作しているかどうかを確認できるようにしたい。そこで、メモリリードを行ってみることにした。
書きたいプログラムは、
------------------------------------------------
li r9,0x6f00
lwz r1,4(r9)
------------------------------------------------
という単純なものである。
つまり、レジスタR9に適当な値を入れ、R9が指す番地のメモリの内容を読み出したいというものである。0x6f00という値は、ロジアナで見るときに見つけやすいと思ったからであり、特に意味はない。
ところで、PowerPCのプログラムをGCCでコンパイルし、リストファイルを作ると、LI(おそらく Load Immediateの意味)という命令がよく出てくるが、LI命令をいくら調べてもPowerPCにそういう命令はない。PowerPCのGNUアセンブラでLIを使うとエラーになってしまう。
どうやら、LIはADDI命令の縮退した形のようだ。
しかも、GNUアセンブラは、R0やR1といったレジスタの表記は使えず、0とか1とか単なる数値で記述しなければいけないらしい。
結局、GNUアセンブラで上のコードを書こうとすると、次のようになる。
------------------------------------------------
addi 9,0,0x6f00
lwz 1,4(9)
------------------------------------------------
なんともわかりにくいアセンブラ表現だ。
これだと正常にコンパイルできて、次のようなバイナリコードが得られる。
------------------------------------------------
a0100000 <_sstart>:
a0100000: 39 20 6f 00 li r9,28416
a0100004: 80 29 00 04 lwz r1,4(r9)
Disassembly of section .text:
------------------------------------------------
これをVHDLにハードコーディングして、PowerPCに直接入れてみる。
------------------------------------------------
process(rev_PLBC405ICURDWDADDR , C405PLBICUABUS) begin
if(bitrev(32,"00" & C405PLBICUABUS) = x"FFFFFFFC") then
-- ba 0x1234
PLBC405ICURDDBUS <= bitrev(32,x"48001236") & bitrev(32,x"48001236");
else
case rev_PLBC405ICURDWDADDR is
when "000" => -- li r9,0x6f00
PLBC405ICURDDBUS <= bitrev(32,x"39206f00") & bitrev(32,x"39206f00");
when "001" => -- lwz r1,4,(r9)
PLBC405ICURDDBUS <= bitrev(32,x"80290004") & bitrev(32,x"80290004");
when others =>
PLBC405ICURDDBUS <= bitrev(32,x"38000000") & bitrev(32,x"38000000");
end case;
end if;
end process;
------------------------------------------------
PPC405のデータバスは64ビットであるが、今回はデータバスを32ビットモードで使っている。
普通のCPUなら、このような場合、用意したデータバスを、CPUのデータバスの上位32ビットにつなぐか下位32ビットにつなぐか迷うことになるが、PPC405は上のVHDLコードのように上下32ビットに同じ値をつながなければならないらしい。
どちらかを0x00000000で固定したら、アドレスバスが0x…0700にジャンプしてしまった。調べたところ、0x…0700未定義命令例外オフセットだそうで、PowerPCの命令に0x00000000というのはないのでつじつまは合っている。
上のコードをFPGAにフィットし、PowerPCを動作させてみると、
ちなみに、このコードをFPGAにフィットするにあたって、VirtexII Pro(XC2VP4)の全スライス3008個のうちの45個を消費した。PPC405をまともに動作するレベルまで機能アップしても大した規模にはならないと思う。
今日は、汎用レジスタへの即値代入と、メモリ読み出しのバス動作が確認できた。明日はメモリのロード・ストア、バス幅の変更あたりをやってみようと思う。
以前、EDKを触ってPowerPCを動かしてみたことがありました。
今回は、EDKを使わずにVirtexII Proの中のPowerPCを動かしてみようという試みています。EDKを使わないというのは、VHDLのport mapで必要な信号を直接つないで動かそうということです。
EDKを使わないと、PowerPCを使い始めるまでに覚えるべきことが少なくてすみ、FPGAの論理合成時間も減り、ソフトウェアの開発ツールも好きなものが選べて、FPGAのロジック使用率も最適化できるのではないかと考えた。また、PowerPCへの理解が深まるので、向学のためにもよいはず。
※EDKを使ったときには、PowerPCのアーキテクチャを本当に何もしらなくても、LEDチカチカができた。
まず、VirtexII Pro内のPowerPCの入出力ポートをの名前をしらなければならない。ISEのインストールされているディレクトリの中のppc405.pdfという資料がある。右の図は、ppc405.pdfに描かれているブロック図だが、PPC405にはたくさんの信号がある。これらの信号を１本1本正しくつないでいけば、PowerPCは動くはず。PPC405.pdfから信号名をコピー・ペーストして、VHDLの"PPC405"コンポーネントを作った。
まず最初につないだ信号は、クロックとリセット。クロックは、CPUの動作が１ステップづつ見ることが出来るようにするため、水晶のクロックを分周して10Hzくらいの十分遅いクロックにしてPowerPCに入れた。(いいのかどうかはわからないが・・)。
XILINXのユーザガイドUG018を読むと、PPC405の信号の説明が書いてある。PPC405は、データバスと命令バスが分離されたアーキテクチャであるそうで、ほとんどの信号には命令用とデータ用がある。
だから、PPC405のバスには、ISPLB(命令サイド・プロセッサ・ローカル・バス)、DSPLB(データサイド・プロセッサ・ローカル・バス)というのがある。VirtexIIの中のPPCには、ブロックRAMと接続しやすくするためにOCM(オンチップ・メモリ・コントローラ)という外のモジュールがあり、これも命令用とデータ用がある。そのほかにも、DCR(デバイス・コンフィギュレーション・レジスタ)というのがあるが、まだDCRの説明を読んでいないのでDCRが何なのかはわからない。
とにかく、ISPLBにそれなりの回路をつなげば、PPC405コアが命令をフェッチして実行してくれそうだということはわかった。ISPLBの波形はUG018.pdfの2章に描かれている。その信号を忠実につくればよいのだろう。
さて、何かのプログラムを実行させようかと思ったとき、ちゃんとしたプログラムを作ろうとすると大変である。XILINX用のPPC405マニュアル(UG018、250ページ)以外にも、PowerPCのリファレンスマニュアルが500ページある。一日で読むわけには行かないし、CPU特有のテクニックみたいなのものがあるだろうから、アセンブラがわかったところでちゃんと動かせるようになるまでには大変苦労するだろう。
手っ取り早くプログラムを走らせる一番簡単な方法は、適当なプログラムをC言語で作り、それをコンパイルし、逆アセンブラすることで、そのCPUの命令体系とテクニックを学ぶというものである。
そこで、CYGWIN上でGCCを動かして、そのコンパイル結果を逆アセンブラしてみることで、どのようにプログラムを組めばいいかを調べたいと考えた。http://www.embedded.jp/にGNUWINGというのがあるので、ここからGNUWINGをダウンロードし、インストールする。GNUWINGは、各種の組み込み用CPUのGCCやGDBなどがすぐに動く状態で纏められたものである。
簡単なプログラムを書いてコンパイルしてみると、リンカに__eabiというセクションがないと言われた。__eabiというセクションをリンカファイルに記述すると、あっさりと通った。
elfファイルが生成できたら、powerpc-eabi-objdump -S sample.elf > sample.lstとやれば、lstファイルが生成される。lstファイルには、C言語とアセンブラの対応が書かれている。
Cでint a = 1;とやると、
a0100040: 38 00 00 01 li r0,1
a0100044: 90 1f 00 08 stw r0,8(r31)
と出た。なるほど。何をやりたいかが何となく分かる。
きっと、r31はローカル変数のためのベースポインタみたいなので、オフセット8のところに変数aを格納しているのだろう。r31はこのように使うのがセオリーなのかな。
こうしていくと、どんな命令が良く使われるかがわかる。こうして、whileやfor文の書き方、分岐の書き方、演算のやりかた、メモリへの読み書き方法などが学べる。
どうやらPowerPCにはNOPという命令はないらしく、or 0,0,0 で代用された。orの3番目のオペランドの意味はまだわからない。
さて、PPC405にNOP命令を実行させるべく、PowerPCの命令用データバス(ISPLB)をor 0,0,0命令(0x60000000)に固定させ実行させてみたが、アドレスバスが動く気配がない。よくよく調べてみると、PowerPCは、ビットの配列が普通の感覚と逆なようだ。
つまり、i386や、MIPSやARM、SH4では、
bit31.......bit0
という順番で並んでいるのに対して、PowerPCは、
bit0.......bit31
という順番なのだ。最上位ビットはbit0なのだ。
そういうわけで、0x60000000を反転させて0x00000006をデータバスに入力し、アドレスバスや制御信号をFPGAの外に引き出し、観察してみた。
ちゃんとアドレスがカウントしている。どうやら、PowerPCは動いてくれているようだ。アドレスバスも、bit29が一番先にカウントしている。bit29がLSBなのだ。(4バイト単位で命令を読むためbit30と31は動かない)
要するに、ビットの数え方が全部まったく逆なようだ。
次は、分岐命令を実行させて、アドレスバスがジャンプすることを確認しようと思う。
長い間お休みしていました掲示板を、試験的に再開することにいたしました。
http://www.nahitech.com/nahitafu/bbs/
新しくなった 「なひたふ電子回路掲示板」 をよろしくお願いします。
おまたせしました!!
MITOUJTAG BASIC Version1.2.3をリリースしました。
今回のバージョンアップでは、
・パラレルポート用デバイスドライバの搭載
・信号検索機能の実装
・新規デバイス対応（EPM240)
・ホイールマウス対応
・フラッシュROMプログラマが機能アップ
・SmartJTAGが最大10倍高速化
などの更新が行われました。
詳細はこちらをご覧下さい。
本件に関するお問い合わせは、naitou@nahitech.comまでお願いします。
最近のコメント