HIDmon-14K50
2009-07 2009-08 PIC日記 PIC18F2550 PIC18F4550 HIDmon-2550
目次
HIDmon for PIC18F14K50†
http://akizukidenshi.com/catalog/g/gI-03031/
内容
- HIDmonとはHIDクラスのUSBデバイス内に実装されたマイコン用の簡易モニタのことです。
- マイコン内のROM,RAM,I/O PORTをUSB経由でPC上から自由に参照、変更するツールです。
- I/O PORTの操作については、Gainerや汎用USB-IO的な応用が可能です。
- RAM参照が可能なので、ユーザープログラム実行後のダンプを見ることも可能です。
- bootloaderとして使用することも出来ます。
- HIDmonに関する詳細はHIDmon88の項目をあわせてお読みください。
回路図†
注意:LVP書き込みしたPICを使用する場合はPGM端子(RC3,pin7)を5kΩ程度でプルダウンしてください。
- また、その場合RC3端子は他の用途に使用できなくなります。
ファームウェアDownload:†
新バージョンのご案内
- これまでhidmon-2550とhidmon-14K50は別々のソースアーカイブで公開しておりましたが、ソース統合と高速化 を施したものを公開します。HIDブートローダーを参照してください。
旧バージョン:
- 18F2550/4550ではXtalは20MHzで、それを5分周(4MHz)した後、PLLで48MHzにして利用していたと思います。
- Xtalの分周比はfuse設定によって1〜5まで行けるので、4,8,12,16,20MHzのどれでも使えていました。
- 18F14K50ではPLLは x4固定で、入力に12MHzを与えない限り48MHzを取り出せないので、必然的にXtalは12MHz固定となります。
- 勿論、水晶発振子ではなくて、水晶発振モジュール出力をPICに突っ込むことも出来ますが、その場合は 外部12MHzか、外部48MHzにして内部x4PLLをdisableするかの2択となります。
- 18F14K50の内部発振16MHzではどうやってもUSBが使えないような気がします。
- USB LowSpeed(1.5Mbps)を使う場合は、その4倍の6MHzのUSB Clockが必要になりますが、
- その場合もXtalの選択は2択であり、6MHzを直接つなぐか、12MHzを内部2分周で使うかのどちらかです。
- もし6MHz Xtalを選択した場合、CPU Clockは x4PLLを通しても24MHzにしか上げられないので、
- 結局12MHz Xtalを選択して、x4PLLでCPUを48MHz駆動し、USBモジュールに1/2の6MHzを与えるのが良いでしょう。
- USBを使う限り、内部発振の16MHzは使い道がありません。
AVRユーザーのためのPIC18F始めま専科。†
- もし、あなたがPICkit2やPICkit3などのPICライターをお持ちであれば、以下の情報は不要です。
- PICライターは持っていないけれど、AVRライター(HIDaspxを想定)なら持っている、という人が対象です。
- PIC18Fを始める場合の初期投資は、PIC18F14K50(1個200円)と12MHzのクリスタルだけです。
- PIC書き込み器は、なんと、HIDaspxがそのまま使えます。 --->PICspxの項を参照してください。
- 書き込むファームウェアは、このページのファームウェアDownload: にある、hidmon-14k*.zipを展開して入手してください。
- 書き込みには気の遠くなるような時間(10分くらい)が掛かりますが、最初の1回だけです。
- あとは、USBに接続して、同梱ツール picboot.exe を使ってアプリケーションを書き換え出来ます。
- picbootが使えるようになったら、こんどは、C言語でリライトしたHIDmonを試してみてください。
- pic18spxにはHIDmon機能だけではなく、HIDaspxのようにAVRマイコンの書き込みや、別のPICマイコンへの書き込み機能があります。
- PIC18F14K50ではI/Oピン数やSRAM領域が不足する場合は、PIC18F2550やPIC18F4550をお勧めします。
- C言語からはほぼ上位互換で使用できます。
- C言語でリライトしたHIDmonは、上記PICの3品種のどれにも対応しています。
- Flash容量の制約をそれほど受けず比較的自由にHIDmonのファンクション追加やホスト機能拡張が出来ます。
- 現在のファームサイズは5kB程度なので18F14K50の場合でも9kBの空き領域が使えます。
- AVRに比べて性能は劣りますが、USBプロトコルエンジンがCPUと独立して動いてくれる(割り込みリソースを使わないで動作する)ので、他の割り込みとの競合もなくフルスピード(12Mbps)USBを使用することができます。
PIC16F84AなどのPIC18Fでないシリーズのチップに書き込みたい。
オレンジ電子さん作の「Writer509」を18F14K50に移植された方がおられます。
- こちらも簡単な回路で高電圧書き込みのPICに書けるようです。
- 今ではPICkit2が充分安価に購入できますから自作以外の選択肢だってありです。
以下の情報は古い日記です。
*大変!ポートアドレスに互換性がありません
- 真面目にデータシートを読んでいます。
- なんと0xf60〜0xfffのI/Oポートアドレスからはみ出しているポートがあるではないですか。
- あうあう。これでは動きません・・・(修正が必要です。)
- 0xf5xのポートを触るときは、BSRレジスタを0x0fに再設定するか、
- あるいはmovff命令でお茶を濁すしかなさそうです。
上記もろもろ修正してあります。
- fuse14k.inc にて LVP=ONになっていますが、気にしないでください。
- (HVP書き込みライターをお持ちの方は、LVP=OFFのほうが良いと思います。)
- LVP(5V単一書き込み)で書き込んで使用する場合は、PGM端子(Pin7)を5kΩ程度でプルダウンする必要があります。
- また、PGM端子(RC3)はポートとしては使用できなくなります。
*picboot.exe の '-B'コマンドが役に立ちました。
- 0番地オリジンのbootloaderから 800番地オリジンのbootloaderを書き込んで立ち上げます。
- 800番地オリジンのbootloaderを使って、0番地オリジンのbootloaderを更新することが出来ました。
picboot.exe -B hexfiles/bootloader-0000.hex
- fuse的には特にプロテクトを掛けていませんが、picboot.exeは'-B'オプションを入れない限り、0〜7ff番地を書き換えることはありません。(保護しています)
*PIC 18F14K50の使用上の注意。
- 上記に書きましたが、ポートアドレスの一部が0xf60〜0xfffからはみ出しています。
- USB エンドポイントは8つしか持てません。(18F2550/4550では16個)
- USB DUAL PORT RAMは256バイトしかありません。しかも18F2550/4550とはアドレスがずれています。(0x200〜0x2ff)
- RAMは512バイトしかありません(0x000〜0x1ff)
- ANSEL,ANSELHのRESET時初期値が'1'なので、ANSEL未設定時にデジタルポート(PORTCとか)を読むと常に'0'になります。
- ADCON1ポートの互換性がありません。各ビットの持つ意味も違います。
- フリーのCコンパイラsdccが18F14K50をサポートしていません。(gpasmはサポートしていました。)
- サポートしていませんが、サンプルプログラムはsdccで強引に動かしました。
- sdccのsnapshotのページからDL出来るコンパイラのほうでは18f14k50のサポートが含まれているようです。
- http://sdcc.sourceforge.net/snap.php
- 一応動作確認いたしました。
今後の拡張予定†
ブート対象プログラムの開始アドレスが何種類か存在する(0x800,0x1000,0x2000)問題に対処したい。- --->対応しました。
ドキュメントの整備。- --->回路図書きました。
- sdccはあきらめて、mcc18をサポートする。
- 実はmcc18を使うのが面倒くさいので、sdccを使用中です。
- sdccでLEDブリンクを書いてpicbootから書き込んで起動させるところまではOK。
putc()などが全然動作しない。何故?- ---> 今は動作しています。
- アナログ周りの機能追加
- ぼちぼち
- Fuse(CONFIG)の書き換え機能
- これがあるとLVPライターだけでも、やっていける。
- コマンドラインからのスクリプト起動。
- スクリプトの強化。
- なんかいい組み込み言語ないかな。
*deBUG中
- putc()などが全然動作しない理由の一つはbios_task()の先頭でチェックする、usb_initializedというフラグが壊れているから。
- そこは起動直後に問答無用でゼロクリアして、
- usb初期化されたら、0x55,0xaaという印をつける場所で、それ以外の用途では使用していません。
- bios_task()以外では利用していません。
- にもかかわらず、そこに0でもなし0x55,0xaaでもない、ある固有値が書き込まれています。
謎すぎ!
- 謎といえば他にもあって、0x200〜0x2ffは起動時にゼロクリアしているのですが、最後の10バイトくらいに必ずごみが入っています。
- しかも、この値も固有値です。
- 最後の10バイトくらいは、PICmonから初期化すると初期化できますが、手動リセット後にみると、また同じ固有値になります。
おおまかに推測すると、0x2c0〜0x2ff あたりは誰かがわざと壊しているとしか思えません。
- で、壊される領域に、usb_sm_ctrl_stateという大事な(?)変数がさしかかると、USBデバイス認識しなかったり、USB接続が切れたりするという感じです。
結論から言って、USB DualPort RAM (0x200〜0x2ff)の最後の0x30バイトあたりは破壊されやすいようです。
- HIDmonのワークを0x210〜0x23Fに移すと、何事もなかったように正しく動作します。
- 現在はUSBのinput packet bufferに割り当てて、ホストパケット受信後の短時間だけ信用するというやりかたで回避しています。