ワイヤリングペンの作成（その２）

　最近は Z80 を使った超小型Z80マイコンや日立製作所（現ルネサス エレクトロニクス）が開発したバイナリ互換の8ビットCPUである HD64180 を使ったHD64180Compactのワンボードを作って遊んでいます。ブレッドボードでは動作が不安定なことがあるので開発用に手配線で試作ボードを作成することがあります。

　配線の線材として以前はラッピング用のPTFE線を使っていましたが、配線作業効率化のためにウレタン線（以降、UEW線と記す）を使うようになりました。UEW線は半田ごてで380℃程度に温めることで被覆が溶けるため、被覆を剥がす手間が不要となり作業性が向上します。被覆が溶ける温度は結構高温なので半田ごての温度を少し高めに設定し前もって被覆を溶かしてから基板に半田付けするようにしています。

　複数の接続ポイントを一筆書きの要領で半田付けすることもできます。しかし試作の場合、回路変更が必要になることもあるので変更し易いように２点間を接続するようにしています。ChaN さんの「プロト基板の配線テクニック」にUEW線配線のノウハウについて書かれていますので一見することをお勧めします。

　UEW線を半田付けする際の道具としてワイヤリングペンが必要になりますが今では市販品の入手が困難な状況です。ネット上ではワイヤリングペンの自作情報が色々見つかりますがこれらの自作記事のほとんどは市販のシャープペンシルにリールを付けたものでUEW線を固定する機能がありません。本ブログの「ワイヤリングペンの作成」の記事で固定機能を有したワイヤリングペンの自作の話を書きましたが、今回、より使い易くなるように部品の見直しを行いました。

　特徴としては

1. UEW線固定機能
   　人差し指で固定ボタンを押すことでUEW線が固定されるのでUEW線を整形し易い
   
2. 太めの本体
   　本体を太くすることでグリップが安定し、長時間作業しても疲れにくい
   
3. 耐熱設計
   　先端には耐熱用の外径 1mm、内径0.6mmの真鍮パイプを実装している（但し、真鍮パイプに直接こて先が触れないようにしてください）
   

　CAD 画面が下図になります。

ワイヤリングペン（CAD設計画面）

　PETG フィラメントで出力した部品が下図になります。

ワイヤリングペンの部品

　組立後の外観が下の写真です。本体とペン先は透明のPETGフィラメントで出力し、その他はグレーのPETGフィラメントを使いました。右手で使う場合はボビンを下の写真の角度で本体に装着すると使い易いです。

組立後のワイヤリングペン

---

【組立方法】

1. ボビンの組立
   　ボビンの軸の両端に円盤型のパーツを取り付けます。軸が円盤より 1mm 程度出るまで入れてください。そのままでも使用可能ですがしっかり固定したい場合はPETGフィラメントの造形物の接着が可能なセメダイン SUPER XG 等で固定してください。この接着剤は PETG を強力に接着できるので PETG の造形物が破損した場合の修復にも使用できます。
   
   

   ボビンの組立

   
   
   
2. ボビンをサポータへ取付け
   　サポータのアーム部を広げてボビンを挟み込みます。取り付け後、ボビンがスムーズに回転することを確かめてください。
   
   

   サポーターへの取付け

   
   
   
3. UEW線の巻付け
   　別途購入した UEW 線をボビンに巻き付けます。ボビン軸のフランジ（円形のつば）付近にあるホールに UEW 線の先端を入れて固定しボビンに UEW 線を巻きます。ボビンのサイズは大きめに設計しているので袋入りの 20m 程度のものであれば全てボビンに巻ききれると思います。
   
   
4. ボタンと固定パーツの取付け
   　ボタンパーツを本体（筒状のパーツ）の内部からボタン用窓にはめ込んだ後にボタン固定パーツに UEW 線を通した状態で固定パーツが本体上面と面一になるまでに入れます。ボタン部品とボンタン固定パーツは下図のようにお互いの平らな部分が接するようにしてください。
   
   ※固定パーツを取り出す際は固定パーツの末端にある溝に爪をかけて引っ張ると取り出せます。
   
   

   ボタンと固定パ^るの取付け

   
   
   
5. ペン先の取付け
   　本体にボビン部分を取り付けます。取付方向は上記の写真を参考にしてください。強く押し込むと抜くのが大変になるので軽く押し込むようにしてください。
   　ボビン取り付け後に、ペン先に UEW 線を通しペン先を本体に軽くねじ込みます。
   
   

   ペン先の取付け

   
   
   

■上記のワイヤリングペンは実際に使ってみて便利だったのでBOOTHで配布することにしました。


[TOP] [ 前へ ] 連載記事一覧 [ 次へ ]

タグ：DesignSparkMechanical 真鍮パイプ ウレタン線 ワイヤリングペン BlogWiringPen

フィラメント乾燥機

　今回はフィラメント乾燥用にかなり前（2022年3月27日）に購入したフードドライヤーを使って初めてフィラメントを乾燥してみましたのでメモしておきたいと思います。通常はシリカゲルを入れた密閉容器にフィラメントを入れプリンタに接続した状態にしているのですが、今回は交換で取り外したフィラメントをシリカゲルと共にチャック付きビニール袋に入れていたことで湿気を含んでしまったようです。

　買い置きしていたフードドライヤーは下の写真の RoomMate というものです。
　1時間～12時間（1時間刻み）でタイマー設定が可能で、温度は35℃～70℃範囲を 5℃単位で設定できます。当時の購入価格は ¥4,480 でしたが先程 Amazon で確認したところ ¥5,280 に値上がりしていました。

フードドライヤー RoomMate

　乾燥対象のフードを乗せるためのトレイが５段ありますが、スプールに巻かれたフィラメントが入るようにするため、３段分のトレイの中央をくり抜きました。
　２つのトレイをくり抜かずに残したのは最下段にくり抜き無しのトレイが必要なこととこの乾燥機が SLA 方式の３Ｄプリンタの造形物の乾燥にも使用可能なためです。また、側面部分に格子状の部分を残してくり抜いたのは残った格子部に金網等を引掛けることで本来のフード乾燥機として使う余地を残したかったからです。
　最初はニッパーで格子の部分を切断しようとしましたが、ひびが広がりそうだったので今は使用していない古い半田ごてにＫ型（ナイフのような形状）のこて先を付けて溶断しました。

トレイ加工

　実際にフィラメントを入れた状態が下の写真です。最下段のトレイは従来のものを置き、その上に中央をくり抜いたトレイを３段重ねています。なんかこう様になっていますね^^

フィラメント格納後の状態

　Amazon で探した専用のフィラメント乾燥機の説明には今回の乾燥対象の PETG は 65℃ で2時間 と書いてあったので 65℃で３時間乾燥してみました。
　乾燥後に気が付いたのですが、フィラメント種別による設定温度はそれぞれの乾燥機の説明でもばらつきがあり、「フィラメントの乾燥で気を付けておきたい3つのこと」を参照させて頂くとスプール自体も 65℃ あたりから熱でたわむことがあるようなので PETG フィラメントの乾燥温度は 60℃ あたりが適切だったかもしれません（今回はスプールのたわみは殆ど発生しませんでした）。

　フィラメント乾燥の Before／After での造形例を下図に示します。
　もともと円錐形の先端部分がだまの状態になることからフィラメントを乾燥しようと思ったのですがだまの状態はあまり改善しませんでした。しかし、乾燥後は（新品だった頃と同様に）表面の艶が増すという効果を確認できました。

乾燥前（上）と乾燥後（下）の造形比較（その１）

　上図のだまは積層したフィラメントが固まる前に次の積層が始まることで下層のレイヤが巻き込まれてだまになるのではないかと推測しています。対策としてはクーリングファンの強化もしくは複数同時に造形することで次のレイヤの積層までの時間を長くする等が考えられます。
　しかし後者の場合、このような縦長の形状での複数の造形では PETG での糸引き問題が出やすくなるので、暫定対処として円錐形を縦に２分割して造形後に接着剤で貼り合わせることにしました。

　フィラメント乾燥前後の造形状態の比較の２つ目のサンプルとして六角柱の造形例が下図になります。
　写真では判り辛いかもしれませんが、乾燥後の方が表面の光沢が増しています（というか乾燥前のものは艶消しのような状態）。

★追記　2024/04/20 {
　上記のだま対策として書いた後者の複数造形による対策を試してみました。乾燥前に試した時には PETG で発生しやすい糸引きが多数発生しのたのですが、乾燥後では糸引きはほとんど発生せず、かつだま問題も解消しました。
}

乾燥前（上）と乾燥後（下）の造形比較（その２）

　おまけで乾燥前のフィラメントの重さを計った時の写真を貼っておきます。乾燥後にも重さを計ろうと計画していましたが、いざ乾燥が終了してみるとなるべく外気に晒さないようにと焦って作業した為、重さを計るのをすっかり忘れてしまいましたｗ

乾燥前のフィラメントの重量

タグ：フィラメント乾燥器 湿気対策 フィラメント 乾燥 PETG

HD64180Compact（その６）16bit乗算処理

　今回使用している HD64180 では Z80 には無かった 8bit x 8bit の乗算命令が追加されています。参考としてデータシートの乗算命令に関する部分の抜粋を貼っておきます。8bit の乗算を 17 ステートで実行できるのでかなり高速です。

HD64180 の８ビット乗算命令

　Z80 における 16bit の乗算の高速化検討に関しては「Z80での高速な乗算処理（その３）２バイト乗算への適用検討」の記事（以降、乗算高速化ページと記す）で書きましたが、HD64180 の 8bit 乗算命令を使った場合、どれくらい速くなるものか実験してみました。
　HD64180 の 8bit 乗算命令を使って 16bit の乗算を実行するために乗算高速化ページにも書いている下記式のようなバイト分割法（と勝手に呼称）で行いました。

(28*x1 + x0)*(28*y1 + y0)    = 216*x1*y1 + 28*(x0*y1 + x1*y0) + x0*y0

　作成したソースコードを以下に示します。あまり最適化はしていませんが高速化のために固定のワークエリアは使用せずスタックを使用するようにしました。最適化してみました。

HD64180 15bit 乗算処理（Z80アセンブラ）

; unsigned 15 bits mul(HD64180) ; DE <- val1(X) ; HL <- val2(Y) ; HLBC -> val1 * val2 ; ; (256*x1 + x0)*(256*y1 + y0) ; = 2^16x1y1 + 2^8(x0*y1 + x1*y0) + x0*y0 ; ; | . | . | . | . | ; <--- x1y1 ---> ; <--- x0y1 ---> ; <--- x1y0 ---> ; <--- x0y0 ---> 036B FMul18: 036B 4B LD C,E 036C 45 LD B,L ; BC:X0Y0 036D 5C LD E,H 036E D5 PUSH DE 036F 58 LD E,B ; DE:X1Y0 0370 69 LD L,C ; HL:Y1X0 MLT BCreg 0371 ED 4C + DB 0EDH,4CH + ((BCreg - RegPairO) SHL 4) MLT DEreg 0373 ED 5C + DB 0EDH,4CH + ((DEreg - RegPairO) SHL 4) MLT HLreg 0375 ED 6C + DB 0EDH,4CH + ((HLreg - RegPairO) SHL 4) if MULTI16 ; if 16bit multi XOR A endif 0377 19 ADD HL,DE 0378 D1 POP DE MLT DEreg ; DE: X1*Y1 0379 ED 5C + DB 0EDH,4CH + ((DEreg - RegPairO) SHL 4) if MULTI16 ; if 16bit multi ADC A,D LD D,A endif 037B 78 LD A,B 037C 85 ADD A,L 037D 47 LD B,A 037E 7C LD A,H 037F 8B ADC A,E 0380 6F LD L,A 0381 8A ADC A,D 0382 95 SUB L 0383 67 LD H,A 0384 C9 RET

※2024/03/11 最適化で高速化

　実機で測定した乗算時間の結果を下表にまとめました。HD64180 は 6MHz で評価に時間がかかりそうだったので乗算高速化ページの時よりループ回数を １／４ に削減しています。表中の Minus aquare method（マイナス二乗法）等の乗算方式についての詳細は乗算高速化ページを参照してください。表中の比率（ratio）は速度比率なので実行時間比率の逆数で同一色内での比率になっています。中段の Z80 6Mhz の部分は上段の Z80 20MHz での測定値からクロック反比例で算出した推定値です。また、Z80 と HD64180 は両者ともメモリ wait は無い状態です。

★追記　2024/03/10　{
　今までの乗算処理時間の計測は乗算処理以外に乗算処理に渡す引数の設定や引数によるループ処理の部分の処理時間も含めた時間を計測していました。しかし、HD64180 の MLT を使用した 16bit 乗算処理がかなりコンパクトになったことから乗算処理以外の処理の時間分を測定し、従来計測していた乗算処理時間から減算することで純粋に乗算処理にかかる時間で比較するようにしました。
}

16bit 乗算処理の速度比較表

　意外だったのは Z80 ではノーマルな乗算法より速かった１バイトのマイナス二乗法を使ったバイト分割法による乗算が、ノーマルな乗算法より遅くなったことです。2byte 版のマイナス二乗法のデータを見ると Z80 での高速化は 1.35 倍 だったものが HD64180 では 1.24 倍に低下していますが、ノーマル手法よりは速いという結果でした。
　また、Z80 と HD64180 の速度差としては HD64180 の方が 1.10 ～ 1.26 倍速いという結果でした。
　元々の目的である MLT による高速化については「MLT を使用した 16bit の乗算処理はノーマル処理の 4.56 倍速い」という結果になりました。流石にハードウェアによる高速化なので速いですね。

　それから今回の評価に直接的な関係はありませんが、Windows の DOS 窓で動作する CPM エミュレータがなんと HD64180 の乗算命令をもエミュれることが判りました。

　最後に上記の速度比較表の元データとなる画面キャプチャーを貼っておきます。

16bit 乗算処理の時間計測画面（Z80 20MHz）

16bit 乗算処理以外の処理の時間計測画面（Z80 20MHz）

---

16bit 乗算処理の時間計測画面（HD64180 6MHz）

16bit 乗算処理以外の処理の時間計測画面（HD64180 6MHz）

★追記　2024/03/11
　HD64180 の MLT を使った 16bit 乗算を変更し再測定

MLT 使用の 16bit 乗算処理の時間計測画面（HD64180 6MHz）

★追記　2024/03/21
　6MHz 動作の HD64180 でアセンブラで記述したASCIIARTの実行時間が通常の乗算処理の7.3秒から3.5秒に短縮されました。

HD64180と20ピンのPICを使った3チップ構成のボードで遊び中
64180で追加の8bit乗算を使った16bit乗算処理は最適化の結果、通常の乗算処理の4.56倍高速なり
64180 6MHzでアセンブラで記述したASCIIARTの実行時間は通常の乗算処理の7.3秒から3.5秒に短縮されたhttps://t.co/4U1k1Af2m3#HD64180Compact pic.twitter.com/9veKW5d2aN

— skyriver (@wcinp) March 13, 2024

[TOP] [ 前へ ] 連載記事一覧 [ 次へ ]

タグ：HD64B180R0P HD64180RP8 PIC18F14K50 HD64180Compact BlogHD64180Compact 高速乗算

HD64180Compact（その５）割込み動作の確認

　前回の記事で書いたようにディバッグモニタを導入し、本記事の末尾に記載したように CP/M の起動までできました。そこで、当初の目的でもあった割込み対応について検討してみましたので記録しておきます。

　初回の記事に書いたように今回の HD64180Compact では従来（Z80PicCompact）の IORQ 信号により WAIT 状態になることに対してマスクする機能を追加しています。この目的としては

1. 内部I/O（レジスタ）アクセス時のWAIT防止
2. 将来追加した外部I/Oアクセス時のWAIT防止
3. 割込み時のIORQでのWAIT防止

の三つありました。

　ａ）については内部I/Oの場合、WAIT 信号は無視され WAIT 状態にならないので処理が止まらないことが判りました（実は弊害があり対処内容を後述します）。
　ｂ）は追加 I/O の実行前に IORQ による WAIT をマスクすればいいだけの話です。
　ｃ）について HD64180 内蔵のタイマを使った割込みで今回確認しましたので以下に記載します。

　今回、割込み動作試験用に作成したタイマ０を使い割込みを発生させる試験プログラムのソースを以下に示します。ベクタ方式の割込みで割込み処理のアドレス指定方法は Z80 のモード２の割込みとほぼ同じです。割込み処理（INTTM0）ではタイマ０割込みのフラグをクリアするためのレジスタ読み込みとカウンタ用ワークの値を 200ms 毎にインクリメントしています。EnPic は IORQ により WAIT 状態になることを可能にするマクロです。

タイマ割込みソース（Z80アセンブラ）

;++++++++++++++++++++++++++++++++++++ ; interrupt test for HD64180Compact ; Ver 0.01 2024/03/04 by skyriver ;++++++++++++++++++++++++++++++++++++ .list EA5F TIMREL EQU 60000-1 ; 0.2s reload reg val(=0.2/((1/6000000)*20)) 00FE CNTAD EQU 00FEH ; int proc incriment 0000' ASEG ORG 0100H 0100 F3 Start: DI 0101 21 0000 LD HL,0000H 0104 22 00FE LD (CNTAD),HL 0107 CD 0128 CALL SetVec 010A CD 0118 CALL IniTim EnPic 010D ED 38 80 + DB 0EDH,Areg shl 3,(HDCNTLA0+IOOFST) 0110 E6 EF + AND 0EFH 0112 F3 + DI 0113 ED 39 80 + DB 0EDH,(Areg shl 3) OR 1,(HDCNTLA0+IOOFST) 0116 FB EI 0117 C9 RET 0118 3E 5F IniTim: LD A,LOW TIMREL OUT0 (HDRLDR0L+IOOFST),Areg 011A ED 39 8E + DB 0EDH,(Areg shl 3) OR 1,(HDRLDR0L+IOOFST) 011D 3E EA LD A,HIGH TIMREL OUT0 (HDRLDR0H+IOOFST),Areg 011F ED 39 8F + DB 0EDH,(Areg shl 3) OR 1,(HDRLDR0H+IOOFST) 0122 3E 11 LD A,11H OUT0 (HDTCR+IOOFST),Areg ; enable Tim0, enable Tim0 int 0124 ED 39 90 + DB 0EDH,(Areg shl 3) OR 1,(HDTCR+IOOFST) 0127 C9 RET ; set vector infomation 0128 3E 01 SetVec: LD A,HIGH INTTBL 012A ED 47 LD I,A 012C 3E 60 LD A,LOW INTTBL OUT0 (HDIL+IOOFST),Areg 012E ED 39 B3 + DB 0EDH,(Areg shl 3) OR 1,(HDIL+IOOFST) 0131 C9 RET ; timer0 interrupt 0132 F5 INTTM0: PUSH AF IN0 Areg,(HDTCR+IOOFST) ; to clear T1F0 0133 ED 38 90 + DB 0EDH,Areg shl 3,(HDTCR+IOOFST) IN0 Areg,(HDTMDR0L+IOOFST) ; to clear T1F0 0136 ED 38 8C + DB 0EDH,Areg shl 3,(HDTMDR0L+IOOFST) 0139 E5 PUSH HL 013A 2A 00FE LD HL,(CNTAD) 013D 23 INC HL 013E 22 00FE LD (CNTAD),HL 0141 E1 POP HL 0142 F1 POP AF 0143 FB EI 0144 ED 4D RETI 0146 ED 4D DUMMY: RETI ORG ($+1FH) AND 0FFE0H 0160 0146 INTTBL: DW DUMMY ; INT1 0162 0146 DW DUMMY ; INT2 0164 0132 DW INTTM0 ; timer0 0166 0146 DW DUMMY ; timer1 0168 0146 DW DUMMY ; DMA0 016A 0146 DW DUMMY ; DMA1 016C 0146 DW DUMMY ; CSI 016E 0146 DW DUMMY ; ASCI0 0170 0146 DW DUMMY ; ASCI1 END

　HD64180 の内部割込み及び外部の INT1、INT2　の割込みはベクタ方式の割込みとなります。参考としてデータシートのタイミングチャートが下図になります。割込み応答時に IORQ がアクティブにならないので上述のように WAIT 状態になる心配はありません。

ベクタ方式の割込みタイミング

　ベクタ割込みの開始を捉えるためにトリガー条件として ST 立下りかつLIRがhighとした際のロジアナ波形例が下図になります。STは各命令の１バイト目のアクセス時にアクティブになるのでこれを目印にマーカーで区切り、実行している命令のニーモニックを図中に追記しました。

タイマ割込み時のロジアナ波形例

　上記のタイマー割込み起動プログラムを起動後に GAME 言語で作成した下記のカウント値が変化した際に画面表示するプログラムを起動しました。

カウント値チェックプログラム（GAME言語）
10 A=$00FE 20 D=A(0) 30 ;=D<>A(0) / D=A(0) ??=A ":" ??=D 40 #=30

　実行した際の画面キャプチャが下図です。"Cw30"と表示されていますが、これは PIC 側が未定義コマンドである 0x30 を受信したことを示しています。このように HD64180 内部レジスタへのアクセス時に発生する短い IORQ を PIC が稀に検出してエラーが発生しています。

カウント値チェック結果

　今回の割込み動作試験で次の問題があることが判りました。

1. 内部レジスタのアクセスをPICが検出してしまう
   
2. 入力待ちの際WAIT状態が継続し割込みが入らない
   

　１項は上記の画面での"Cw30"の表示のことですが、PIC側で IORQ を検出する際、６回連続で IORQ がアクティブな場合に検出するように変更しました（４回チェックでは問題事象が発生したのでマージン込みで６回にした）。
　２項についてはキー入力時に直接データ入力していたところをキー入力有無をステータスでチェック後、キー入力ありの場合にデータ入力するようにしました。

　対処後のカウントチェック画面のキャプチャも貼っておきます。数十分継続してみましたが上記の問題事象は発生しませんでした。

カウント値チェック結果（対処後）

　以上、割込み動作試験での問題と対処について記載しましたが、これにより手持ちの Z80 ボードでは難しかった割込みを使った動作実験ができる環境ができました。

---

［補足］
　CP/M が動作するようになるまでに発生した問題や対処などを以下にメモとして残しておきます。

　初めに下の写真が今回作成した HD694180 と USB 機能を有する 20 ピンの PIC を使った手配線のボードです。

手配線の開発用ボード

　最初は SD 初期化での CMD0 コマンドに対しての応答が無い状態でした。これはハードウェアの問題で PIC 側が SD からの応答を読み取れず、SD から応答がまだ出ていないのに応答を受け取ってしまっている状態でした。

CMD0 への応答なし

　チップ抵抗を交換して応答が正常に受け取れるようになりました。

CMD0 と CMD8 への正常応答あり

　今回の HD64180Compact では今後機能追加し易いように SD の初期化を従来のように電源投入時ではなく、Z80 からの要求により実行するようにしました。このため、PIC 側の SD の初期化完了の際に Z80 側とのタイミング合せがうまく行かなくなってしまいました。原因は SD に送信するコマンド間の SDCS が非アクティブになる期間、Z80 側の WAIT が解除され処理が進むことだったので、初期化コマンド期間は連続して SDCS をアクティブにするように変更しました。結果として初期化を完了するまで Z80 が WAIT 状態のままなので双方のタイミングずれは発生しなくなりました。

　初期化時のロジアナ波形を記録として貼っておきます。下図は初期化全体のロジアナ波形です。ほとんどの時間は CMD41（0x69）に対する Ok 応答（0x00）が来るまでリトライしている部分になります。

SD 初期化時のロジアナ波形例（全体）

　下図は CMD41（0x69）に対して Ng 応答を受けた部分のズームです。

SD 初期化時のロジアナ波形例（NG応答受信時）

　下図は CMD41（0x69）に対して Ok 応答を受け取り、CMD58（0x7a）を発行して初期化を終了している部分です。

SD 初期化時のロジアナ波形例（OK応答受信時）

　初めて CP/M が起動できた際の画面も記念に貼っておきます。但し、この時は HI-TECH C でのコンパイル時に固まり、不安定な要素が残存していました。

　この時の CP/M の起動方法はディバッグモニタで BootLoader の Hex ファイルを読み込んで起動し、BootLoaderが SD から IPL を読み込み起動することで IPL がメモリ上に CP/M 本体をロードし BIOS の boot にジャンプすることで CP/M が起動されます。SD 自体は Z80PicCompact と同じものを使用していますが、MBASIC や BDS C は動きましたが HI-TECH C でのコンパイルで固まるのでまだ不安定要素がありました。

初の CP/M 起動画面

　今回、HD64180は6MHz（USB用の12MHzからの流用）で動いていてBIOS部分はZ80の16MHzと20MHzで動作実績のあるものです。遅くなって動かなくなる部分は全く思い当たらないと思っていましたが原因はハードでした^^;
　修正して安定に動作しHitech-Cのコンパイラも元気に動きました。

HI-TECH C でのコンパイル画面

[TOP] [ 前へ ] 連載記事一覧 [ 次へ ]

タグ：HD64B180R0P HD64180RP8 PIC18F14K50 HD64180Compact BlogHD64180Compact

HD64180Compact（その４）ディバッグモニタ

　前回の記事で書いたように手配線で製作した開発機がハード的には動いているようなのでディバッグモニタを入れることにしました。

　GAME言語で自作した簡易モニタのGAMON入れてみたところ、ブレークが動作しない場合があるので少し悩みましたが、Z80を使用したZ80PicCompactでも同様の現象が発生することが判り、GAMONを修正し正常動作を確認しました。ブレーク機能のディバッグにはブレーク機能が使えないので机上ディバッグですｗ。
　ついでにHD64180でも使えるようにI/O入出力のコマンドのアドレスを16bit対応しました。「GAME言語で作った簡易モニタ」のページでアップデート版を公開しています。

　HD64180関連の情報をネットで眺めていたところ、敏雪さんの「Ｓｏｆｔいろいろ」のページでHD64180用のモニタであるH18MONを見つけ、インストールしてみました。アセンブルには IR80.EXE 相当のアセンブラが必要なようなのですがネットでは見つけられなかったのでperlを使ってローカルのテンポラリラベルを自動変換する等してアセンブルしました。HD64180固有の命令は前回の記事で書いたマクロで対応しました。
　コンソール入出力部分を変更しただけでは動かなかったのですが、メモリチェック部分を変更することで動作するようになりました（ROMでの運用を想定しているため、RAM上にロードした状態では動かなかった）。

　起動画面のキャプチャが下図になります。今回作成したHD64180Compactではブート時にPICからロードされるHexLoaderを0xff00に配置していて、この領域をH18MONがデータ領域として使用しているので、GAMONを使ってロードしています。

H18MON起動画面

※2024/02/29　最新版に差し替え

　上図のヘルプ表示にもあるようにH18MONは逆アセンブルやトレース機能もあり、このような高機能なモニタを公開されている作者に感謝致します。

　ブレーク機能の試行として「メモリ上で実際に動くプログラム（その２）」の記事で書いたフラグの未使用ビット設定確認のソフトを実行した際の画面キャプチャが下図になります。Hexファイルは'^Z'で終端されている必要があるようです。実行結果として"Ok"が表示されているのでHD64180でもフラグの未使用ビットに値を設定できることが判ります。

H18MONでのブレーク動作

※2024/02/29　最新版に差し替え

　因みにGAMONで同様にブレークした際の画面が下図です。

GAMOMでのブレーク動作

※2024/03/02　最新版に差し替え

　逆アセンブル機能はいいとしてトレース機能には食指が動きますが、暫くは手に馴染んだGAMONを使っていきたいと思います。


[TOP] [ 前へ ] 連載記事一覧 [ 次へ ]

タグ：BlogHD64180Compact HD64180Compact PIC18F14K50 HD64180RP8 HD64B180R0P Gamon H18MON