PIC Writerの製作

未検証や実験や+αなどのページ


■ PIC Writer509のDC-DCコンバーター部について ■

2005/08/19
 プログラマー部がショボイわりに、DC-DCコンバータ部がゴッツくてアンバランスなため、 別の昇圧回路を考えてみた。



 元の昇圧回路は、13V/50〜100mAくらい取れるような回路だったけど、 フラッシュタイプのPICのみの書込みであれば
1mAもあれば十分のようだ。
 実際には、トランジスタでのスイッチや、LEDなどで消費する電流があるため20mAくらいほしいところ。
 使用する部品も、安くて入手性のよい部品がいい。
 タイマーICで有名な555(C-MOSのもの)を使ってみた。
 使用するインダクターにもよるが5mAくらいなら取れそうだ。
 早速、以前に作ったPIC Writer 509のDC-DCコンバータ部を全部はずしてしまった。
 そして、この昇圧回路を余っていた基板の切れ端に組んでみた。


 昇圧回路がないと、なんとも貧粗なプログラマーだ。その左にあるのが3端子(6端子?)昇圧モジュール。
 黄緑色の抵抗のように見えるのが470μHのマイクロインダクター。  それ以外の部品は電子工作をやったこととがある人にとっては、定番中の定番ばかり。  やはり、5mAが限度か。VppにはいっているLEDもはずした方がよさそうだ。
 マイクロインダクターの直流抵抗が20Ωくらいあるのも原因の一つだが、やはり555の出力(Discharge端子)がそれほど電流が取れないのだろう。


 取り付けるとこんな感じ。 何とか動くみたい。
 消費電流を測ってみた。(16F84Aの場合)
    アイドル時:26.7mA、  書込みや読み出しなどのアクセス時:33.0mA
 内訳は、
    電源表示のLED:約5mA、 アクセス表示のLED:約5mA、 昇圧回路:約20mA、 PICその他:1〜2mA
 やれやれ…、ほとんどが昇圧回路の電流でした。それもそのはず、…
 昇圧回路の定電圧部分はツェナーで強制的に電圧を押さえ込んでいる回路になっているためです。
 そのために負荷電流が一定範囲なら常に同じ電流を消費しているのです。
 トランジスタ1本追加してやれば、負荷電流に応じて消費電流を減らすことができるけど、まぁいいか。

 注意として、トランジスタでスイッチしたVppやVddラインのLEDを省略する場合、 トランジスタが正常にON/OFFしているか確認し、
トランジスタが完全にOFFできていないようなら8.2Vのツェナー電圧を変更してみるとか、 LEDの代わりに20k〜100kくらいの
抵抗を入れる。


 ここまでくると、40Pinのゼロプレッシャーソケットの付いたプログラマーを作ってみたくなる。


 無理やり25x15穴の基板にレイアウトしてみたけど、ジャンパー多いし、大丈夫か?
 やっぱり無理だ。ゼロプレッシャーソケットって意外と大きいからもう一回り大きい基板でないと載らない。
 Programmerのメインページに16F57に対応するように改造した40Pinゼロプレッシャーソケットの回路を載せてみた。


 ちょっと戻って、昇圧回路に関するヒントを一つ。

 上の回路では、PICにVppを供給していない時にも、
電圧を一定にするために常にツェナーで電流を
消費する回路になっている。

 といっても20〜30mAなので我慢することにしたが、
それがいやな場合には、トランジスタが1本追加になるが
左のような回路が考えられる。

 どの程度効果があるかまだ実験途中だけど、
少しでも消費電流を減らしたい人には有効かもしれない。

 ツェナーダイオードD2のバラツキによって出力電圧が
低いこともある

 その場合にはツェナーダイオードを13Vの物に変えるか、
適当なダイオード(Dx)を直列に接続するなどして、
出力電圧が12V〜14Vになるように調整するといい。

2005/12/27
 ・・・というわけで実験してみた。

 今まで使っていたWriter509のDC-DCコンバータ部を、
また全部取り払って、CMOSの555にトランジスタを
1個追加した上の回路を取り付けてみた。
 プログラマー部はそのままで、DC-DCコンバータ部のみ
交換した(コネクタの位置は変更)。

 消費電流がどれくらい減ったかを確認するため、2個の
LEDは切断して測った
 (実際、Writer509にこの回路を使用する場合、
アクセス中を示すLEDはVpp[13V]ラインに入れることは
できない。
 必要な場合はVdd[5V]ラインに入れなければならない。)

 DC-DCコンバータ部だけで0.6mA、プログラマー部に
12F675を使ってDC-DCコンバータ部との合計で1.7mA
16F877Aの書込みや読出し時で約8mAとかなり低消費。

 DC-DCコンバーターの回路はこれら以外にも多くの回路が考えられるし、専用のICも多数ある。

 NJM2360Aのオリジナルと思われるモトローラ(現ONセミコンダクター)のMC34063は、ダイソーなどで\300位で売られている 車のシガーソケット(12V)から携帯充電用に電圧を(約5.5V)落とすアダプターにもよく使われている。
 いくつかのサイトで分解・解析した様子が書かれているし、ダイオードやコイル(値は不明)もここから取ることができるのでこれを改造してもいいかもしれない。

 他にはテキサスインスツルメントのTL497AやTL499Aなどもある。
 TL499Aは8ピンのIC内にショットキーダイオードも内蔵しているので、NJM2360より回路が簡単になる。

 MAXIMからもいくつものICが出ていてMAX630などは同じような感じで使用できそうである。
 MAX662は3段のチャージポンプに12Vの安定化回路が内蔵されているので、コイルも不要でコンデンサ2個の外付けで動作する。
 電圧が12V固定なので13V必要とするPICにはちょっと不安かもしれないが、12Vで書込みができるデバイスも幾つもあるので 試してみる価値は十分にあると思うし、もしかしたら少しくらいなら電圧を上げることができるかもしれない。



■ 失われたキャリブレーションデータを求めて ■
2005/09/26

 いろいろなPICの中で内部CR発振回路を内蔵しているものの中には、なるべく正確な周波数で発振できるように 周波数の補正値(キャリブレーションデータ)を持っているものがある。
 内部CR発振回路を持っているデバイスでも、キャリブレーションデータを持っていないものもある。

 ほとんどのPICプログラマーではこのキャリブレーションデータが失われないように、プログラムの書込み時や デバイスの消去時に、一旦キャリブレーションデータを読み出し、デバイスの消去後キャリブレーションデータを 書き戻すような処理を行っている。
 従って、通常キャリブレーションデータが失われることは無いはずだが、操作ミスやプログラマーの不調などで キャリブレーションデータを失ってしまうことも絶対にないとは言い切れない。

 万一、キャリブレーションデータを失ってしまった場合はどうしたらいいだろう…?

 あらかじめ読み出しておいてどこかにメモしてあった場合には、そのデータを書き戻せばいいのだが、 多くのPICに書き込んだり慣れてくると、読み出してメモするのも面倒になってやらなくなってしまう。

 失われたキャリブレーションデータを復元することはそんなに難しいことではない。
 PIC12F629/675などでは、ConfigurationWordを適切に設定することによって内部発振周波数の1/4の周波数(1MHz)をClockOutに出力することができる
 従って、周波数カウンタでこれを計測し、1MHzに近くなるようにキャリブレーションデータを変更しながら計測/書込みを繰り返せばよい。
 ところが、ソフトウェアをメインで行っている人などは周波数カウンタを持っていない人が多く、また、計測/書込みを繰り返すのも手間がかかる。

 滅多に行うことではないが、簡単な操作で行うことができる方がいいのでこんなプログラムを書いてみた。

    ・周波数カウンタを持っていても持っていなくても使用できる。
    ・周波数カウンタを持っていない場合は、パソコンのシリアルインターフェースにデータを送って、
      エラーの有無で周波数を推測する。
    ・キャリブレーションデータは、パソコンのターミナルソフトに表示される。
    ・スイッチ入力でキャリブレーションデータをUp/Downして周波数の変化を見ることができる。

 最低限必要なのは、電源とバイパスコンデンサとパソコンである。
 内部RC発振回路を使用する場合は、特にバイパスコンデンサの影響が大きいので、
最短距離で確実に接続したほうがよい。


 バイパスコンデンサの接続の仕方や電源ノイズなどによって、発振周波数が変わってしまう場合もあるので注意が必要。
 回路が簡単なので、ブレッドボード上に組み立ててもいいかもしれない。
 また、スイッチはつけたほうが操作性がいいが、なければワニグチクリップなどで接触させてもいいかもしれない。

 注意:PIC12F508/509の場合はDOWN SWをPin5(GP2)からPin4(GP3)に変更する。
    また、Pin3(CLKout)に出力される周波数はPIC12F508/509の場合50kHzとなる。

 パソコンのシリアルインターフェースに接続する回路は、特に保護回路などは必要ないはずだが、
直接接続するのが気持ち悪い場合は、470オームくらいの抵抗を直列に接続するといいだろう。
 周波数カウンタは、接続しても接続しなくてもどちらでもいい。

 使い慣れたターミナルソフトか、
Windowsのハイパーターミナルを
   9600bps、
   8bit、
   ストップビット1bit、
   パリティなし、
   フロー制御なし
に設定する。

 PIC12F629/675の場合には連続してデータが表示される。

 PIC12F508/509の場合にはUP/DOWNスイッチを押すたびにデータが表示される。

 デバイスにもよるが、UP/DOWNそれぞれ10回くらい押すとデータが表示されなくなる。
 この状態が、周波数がずれて通信エラーが出ている状態になる。

 正常に表示される上限と下限の数値を控えておいて、その中間を取るとほぼ規定の周波数となる。
 例えば、
   PIC12F675 上限:34A4 下限:3470
 だった場合、上2桁の34は[retlw]なので下2桁だけの平均を取る。
   16進で (A4+70)/2 = 8A
 ただし、PIC12F675のOSCCALは上位6bitのみ有効なので 88 または 8C とするので、
書き込む値は3488または348Cとなる。

 PIC12F508/509の場合は、ターミナルに表示されるデータが連続ではなく、スイッチを押した時のみ
という違いのほかに、キャリブレーションデータエリアに書き込まれるデータが、[retlw]ではなく
[movlw]であるため0Cxxとなる。

 またキャリブレーションデータの値も、PIC12F629/675が00〜80〜FC(上位6bit,中間値80)
だったのに対し、PIC12F508/509は80〜00〜7E(上位7bit,中間値00)となっているので
計算方法が多少異なる。
 例えば
   PIC12F509 上限:0C1C 下限:0CF8
 だった場合、下2桁の平均をとる計算は
   16進で (100+1C+F8) / 2 - 100 = 0A
 となるためキャリブレーションデータエリアに書き込むデータは0C0Aとなる。

HEX ファイル   内   容
OSCTs509.zip PIC12F508/509のキャリブレーションデータ測定用
OSCTs675.zip PIC12F629/675のキャリブレーションデータ測定用
注意: PIC12F629/675でキャリブレーションデータが失われて 完全に消去状態(アドレス3FFのデータが3FFF)になっている場合は正常に動作しない。
 仮のデータ[retlw 0x80]を書き込むことで動作させることができる。

 (PIC12F508/509の場合は特に問題が無い。)
 アドレス3FFにデータがあってもなくても、単に無視してOSCCALレジスタの初期値で動作させればいいだけのことでした。
 このHEXファイルを書き込むだけで電源とパソコンをつなげば表示されます。




■ Writer509開発時の様子など… ■
2005/09/29

 Writer509を作る前にもPICを使っていくつか回路を作ってはいたけれど、いきなり完成形を目指して作り出してもうまくいくはずもなく、 何か簡単なテスト回路でも作って少しずつ動かした方がよさそうだと考えた。

 それまで使っていた「AKI−PICプログラマー Ver.3」を眺めていたら、ゼロプレッシャーソケットが2個もついてるし、 電源回路もついてるし、シリアルインターフェースもついてるし…ちょっとこれを使ってやろうと思った。

 秋月のPICプログラマーは28ピンのPICで制御されているが、それには理由があって、「古いタイプのPICには、書込みコマンドやデータをパラレルで入力するものがある」ためである。
 趣味ではそのような古いタイプのPICは使わないだろうと、さっぱりと切り捨てることにした。
 これからたくさん出てくるであろうPIC18シリーズも書き込みコマンドがちょっと違うし、これも除外した。
 あまり手を広げても失敗しそうな感じがしていたが、よく使われているPIC12FシリーズとPIC16Fシリーズぐらいならいいだろうということにした。

 コントローラに使うPICは、今までよく使ってきたPIC12C509A(またはそのフラッシュタイプの12F509)が使えたらいいなぁと思って考えてみると、
     PIC自体の電源(Vdd,Vss)に2本。
     パソコンと通信するシリアルインターフェース(TxD,RxD)に2本。
     ターゲットデバイスにコマンドやデータを送るライン(PG-Clock,PG-Data)に2本。
     ターゲットの電源を制御するライン(Vdd,Vpp)に2本。
で、まったく余裕がないが8ピンのPIC12C509A(後にPIC12F509、PIC12F675へと変わる)で決定した。

 元々付いていた28ピンのPIC(PIC16C57XT)をはずし、PIC12C509A/JWを乗せてみる。
 もちろん、乗ったからといって「AKI−PICプログラマー」用のWindowsソフトが使えるわけではない。
 第一、元々どんなプロトコルかも知らないし…
 こんな感じの変換基板を作ってみた。


 とりあえずハードはシンプルにしておいたのでトラブルはないだろう。
 
  12C509Aの代わりに18ピンや28ピンのPICなどを乗せて、トレーニングボードの代わりにすることもできるかもしれない。
 でも、ゼロプレッシャーソケットをコネクタ代わりにするのはまずいかな…?
 ソフトウェアの方もなるべく少しずつということで、まずはパソコンとの通信から試してみた。
 パソコン側はターミナルソフトを使って、PICからパソコンに一方的にデータを送りつける。
 それができたらパソコンから送ったデータを受信して、そのままパソコンへ送信するように変えてみる。
 そうやって送受信ができるようになったら、今度はターゲットの電源制御を行ってみる。
 これは単にポートのON/OFFなので簡単だから、送受信と合わせて送られてきたデータによってVdd/VppのON/OFFを行うようにする。

 ターゲットのPICとの通信は、クロックに同期してコマンドやデータを送受信するので少しだけ面倒だった。
 MPLAB 7.20のシミュレータを最大限に活用して動作の確認を行うようにしたが、なかなか日本語で解説しているサイトやマニュアルがない。
 もっと英語の勉強をしておけばよかったなぁと後悔しても始まらないので、Exciteなどの翻訳サイトでちょっと変な日本語に訳しながら進めた。
 せっかくなので、使い方のヒントをまとめておいたのでよかったら見てもらいたい。

 MPLAB 7.20 SIM のスティミュラスを使う
 
 パソコン側のソフトも、テスト用のプログラムを作って確認しながら進めていった。

  とにかくシンプルで、ボタンをクリックすると単純なデータを送信し、受信したデータは16進文字などに変換して表示するだけのものにした。  

 最後の方はつぎはぎだらけで少し混乱してきたので、本来のプログラマーのソフト作成に移行した。

 
 ここで使用したテスト用プログラムとPC-Programmer間のプロトコルは以下のリンクをクリックするとダウンロードできる。

 一部のプロトコルで不具合が出る可能性がある部分に注意書きを追加。2006.12
 <ダウンロード>

【注意】
このプログラムを使用するための条件は以下の通りとする。
・Delphiのソースが読める。
・PICのプログラミング仕様を理解している。
・操作方法によってはデバイスを破壊するリスクがあることを理解している。
など、すべて問題点は自分で解決できる場合に限る。


こんな風にして PIC Writer 509 のハードウェアやソフトウェアが出来上がっていくのであった…。



■ AKI-PICPGM用アダプタ その2 ■
2006/12
 

 Writer509開発のためだけでなく、「AKI-PICPGM Ver3を持っているが、最近のデバイスに対応していない…」という場合、 アダプタを作ることによってWriter509として動作させることができるようになる。
 

 ・製作例写真1
 

 写真では片面ユニバーサル基板と普通の平ピンソケットで作られているが、両面基板と連結ピンで作製したほうが面倒がないと思われる
 

 ・製作例写真2
 サポートするデバイスも"16F57"を含むWriter509でサポートする全てのデバイスが使用できる。
 

 補強のため、動作に必要のない配線も回路図上では配線してある。




■ Writer509用 通信テストプログラム ■
2006/02/16

 上で紹介したプログラムは、Writer509のPC用ソフトを自分で作成したり、アレンジしたり、いろいろいじり回したい人のためのプログラムであったため、 普通にPICに書き込むためにWriter509を作製して使用する人には不要で使いずらいものになっている。

 ここで紹介するテストプログラムは、Writer509を作製したが正常に動作しない場合、問題箇所の切り分けに使用することができる。

 主に、PCとWriter509間でデータを送受信して通信の正常性を検証するのに用いることができる。

  ・書き込み用ソケットにはデバイスをセットしない

  ・COMポートは自動認識されないので、Writer509を
   接続したポートを指定する。

  ・所要時間は、テストカウントが1000の場合約10秒、
   20000で約4分、100000で約20分。
    (所要時間は使用するPCによって変わるようだ。
    CPUクロックが倍近い別のPCでテストしてみたが
    所要時間はかえって倍以上かかった。
    CPU使用率は0〜1%程度だからCPUの性能に
    よるものでもなさそう。チップセットの違い等か…)

  ・最初は1000でテストしてOKならばカウントを増や
    してテストしてみる。

  ・電源の立ち上がりや通信ラインの初期状態によっては、
   正常でもエラーが出ることがある。
    [Small Block]テストを何度か行うと同期が取れるので
   その後カウント数を増やして長時間のテストを行うとよい。
  2006/04/26更新
  ・今までの小さいブロックサイズ(SmallBlock)による通信テストに加えて、大きいブロックサイズ(LargeBlock)
   による通信テストを追加。

  ・小さいブロックでのテストでエラーが出る場合は、下記にあるようにハードウェアのチェックなどが必要。

  ・大きいブロックでのテストでエラーが出る場合は、Writer509の通信方式やPCの処理能力、
    USB-シリアル変換などの影響が考えられる。
    下記の「補足」にあるような設定で回避できる場合もある。

  2006/12/22更新
  ・今までの小さいブロックサイズ(SmallBlock)、大きいブロックサイズ(LargeBlock)による通信テストに加えて
   1バイトの送受信(Byte)による通信テストを追加。

  ・テストにかかった時間の表示を追加。

  2007/03/04更新
  ・高速化対応のプロトコル[AdvanceWrite4]のテスト機能を追加

  ・各[Start]ボタンにマウスを置くと、どのプロトコルを使用するかを表示する機能を追加。

  ・NGに1つでもカウントされた場合は通信エラーが発生しているので配線の見直しなどを行ったほうがいい。
  ・テストカウントに設定した値(1000〜100000)とOKのカウントが異なる場合も通信エラーが発生している可能性がある。



  [SmallBlock]では青枠内の部分がテストできる。
  NGカウントが0でない場合は以下の項目をチェックするとよい。


    ・バイパスコンデンサの0.1μはPICの近くに配線されているか。
    ・PIC12F508/509(または12F629/675)に書き込まれているOSC補正値は正常か。
    ・D1,D2は付いているか。
     (同一基板上でUSB-シリアル変換IC等が接続されている場合は不要)
    ・R1,R2の値が極端に異なっていないか。
     (多少の違いはOK。同一基板上でUSB-シリアル変換IC等が接続されている場合は不要)
    ・R9のプルアップ/プルダウンは間違っていないか。
     (同一基板上でUSB-シリアル変換IC等が接続されている場合は不要もしくはプルアップにする)
    ・PCと接続するケーブルに断線・接触不良などがないか。
    ・USB-シリアル変換ケーブル・ICなどを使用している場合は、ドライバーソフトが正常にインストールされているか。

           【「Writer509通信テスト」プログラムのダウンロード】

    【補足】([LargeBlock]でのエラーについて)
     一般的にいって、プログラマーの処理能力に比べるとPCの処理能力は格段に大きいので、PCからプログラマーへの
    データやコマンド転送は十分注意しながら行う必要があるが、プログラマーからPCへのデータ転送は連続して送信しても
    PCがデータを取りこぼすことはないはずであるという考えでいた。
     現に、Writer509ではPCからプログラマーへは1Byteずつ送信し、プログラマーからPCへは必要なだけ連続して
    送信するように作られているが今まで特に問題は出ていなかった。
     Writer509が多くの人に利用されるようになると、想定していた以外の環境で使用する人も出てきた。
     そこで、プログラマーからPCへのデータも小さいブロックで転送するようにしてみた。
     Writer509の実行ファイル [W509.exe] があるフォルダに作成される [W509.ini] ファイルに以下の行を追加する。
[read]
smallblock=1
     [Option]タブにSmallBlockReadの表示が出れば、小さいブロックでの転送が有効になっている。
     尚、この設定を行うと転送速度がわずかに遅くなるので、今までの状態で特に問題がない場合は行わないほうがいい。
     また、基本的に不安定な通信を補うものではないため、上記の[SmallBlock]での通信テストでNGカウントが出る場合は
     この設定を行っても改善されることはない。
     ([SmallBlock]での通信テストでNGカウントが"0"であるにもかかわらず、[LargeBlock]で通信エラーが起きている
      場合のみ有効)



■ Writer509とRTS、DTRの関係 ■
2006/04/15

 Writer509では基本的にシリアルインターフェースのうち、TxdとRxdしか使用しない。
 
 回路図上では、RTS-CTS、DTR-DSRが接続されているがこれは従来からの慣習でPC-9801等で使用されているi8251ではCTSがOFF(又は未接続)では 送信できないという仕様などからこのように接続されているものがあったが、 現在のPCではWindowsでの使用においてハンドシェークを未使用に設定しておくことによってこれらを自由に使用できる。

 バージョン2.21からINIファイルに以下の行を追加することによって、RTSとDTRの2つの制御線を自由に使用することができるようになる。
[rts-dtr]
enable=1

 Optionタブに以下のように表示され、RTSとDTRをON/OFFできるようになる。


 Writer509の回路の作り方にもよる(昇圧回路やLEDなど)が、消費電流を減らした回路にすることによっては Writer509の電源に利用することができるかもしれない。
 なお、この機能を利用するとWriter509の起動にやや時間がかかるので、使用しない場合はINIファイルへの追加を行わないほうがよい。
 また、シリアルインターフェースから取り出せる電流はPCやUSB-シリアル変換ケーブルによるところが大きいのであくまでも 自己責任の範囲で利用すること。



■ Write509に「FTDI」のUSB-シリアル変換チップを使う場合 ■
2006/12/21

 Writer509のプロトコルは、通常のシリアルインターフェースにとってはどうってことない構造になっているが、 USB-シリアル変換デバイスにとってはちょっと酷のような感じがしないでもない。

 それは、USBがデータを単なるバイト列としてでなく、パケットというデータの塊として送受信しているためである。
 実際、Writer509の動作を見ても、[READ](読み出し)や[BLANK?](ブランクチェック)、[Verify](べりファイチェック)のように、 Writer509からPCへまとまったデータを受信する場合は、どんなインターフェースを使用してもそれほど大きな速度変化はない。
 ところが、[PROG.](書込み)のように短いデータ(1〜2Byte)を、送受信頻繁に切り替えながら通信するとインターフェースによって 速度が大きく変わってくる。

 それでもFTDI以外のCP2102やPL2303などのデバイスは、(ハードかドライバーソフトかは不明だが)シリアルデータをうまい事USBのプロトコルに乗せているようで、 標準のシリアルインターフェースとあまり変わらない速度で通信できている。
 
 次の表は、あるテスト機(PC)でテストプログラムを使っていろいろなインターフェースを比較したものである。
     Celeron 1.2GHz
Windows 2000Windows 98SE
Byteデータ
5000カウント
標準シリアル1918
PL-23031510
CP21022020
FT232RL160(24)160(40)
    
Small Block
1000カウント
標準シリアル1111
PL-23031110
CP21021212
FT232RL40(12)33(14)
 ※上記の「通信テストプログラム」を使用。 単位は[秒]。
 ()内は対策後の測定時間。 それ以外はドライバーをインストールしたままのデフォルトの状態。

 2種類のOS、2種類のテストデータでの結果を示しているが、どのテストにおいてもほかのインターフェースに比べて FT232RLのみ大幅に時間が掛かっていることがわかる。
 
 掲示板を通して多くの人にテストをしてもらったりアドバイスをもらった結果と、いくつか実験した結果をまとめると次のような対策が有効ではないかと思われる。
 この対策をすることによって、他のインターフェースと同等とまではいかなくても、かなり改善されることが測定結果からわかる。

Windows 2000/XPの場合
 デバイスマネージャから該当するCOMポートのプロパティを開き、[Latency Timer] を最小にセットする。
1.デバイスマネージャで該当するCOMポートを探す
 (COM5の場合)
2.[Port Settings]タブを開く










3.[Advanced...]ボタンをクリックする



4.[Latency Timer]を最小の"1"にする
 
Windows 98/98SE/Meの場合
 送受信データがある場合に制御線を変化させてデバイスに通知する。
右に示すもののうち、どれか一ヶ所のみ結線する。
どれでも効果は同じで、2ヶ所以上結線しても変わらない。
(全ての結線を試したわけではないが、ほぼ合ってると思う)
1.TXD←→RI#
2.TXD←→CTS#
3.TXD←→DSR#
4.TXD←→DCD#
5.RXD←→RI#
6.RXD←→CTS#
7.RXD←→DSR#
8.RXD←→DCD#
[例1]デバイスの近くで配線する場合は、
   RXD←→RI# あたりが隣同士で配線しやすいかもしれない。
[例2]ストロベリーリナックスのモジュール[FT232RX]の場合は、
   RXD←→DCD#あたりが隣同士で配線しやすい
 この結線はWindows98/98SE/Meでは有効だと思われるが、
Windows2000/XPではLatency Timerの設定をとともにこの結線を行うと、
逆に僅かに速度が低下する場合がある。
 両方のOSで共用する場合は、直接配線などをせずにジャンパピンなどで
切り替えられるようにしておいたほうがいいかもしれない。



■ Writer509用の最初の1個のファームウェアを書き込む方法 ■
2007/07/01

 Writer509のようにファームウェアを必要としたPICライターでは、PICライターを作成する前にPICにファームウェアを書込む必要がある。
 世間ではこれを「鶏と卵問題」などと言って、
   PICライターを作るにはファームウェアが必要 -> ファームウェアを書き込むにはPICライターが必要 -> …
と、なって何もない状況では部品を買ってきて組み立てただけでは動かすことができない。

 既に別のPICライターを所持していて2台目の作製の場合や、周囲にPICライターを借りられる環境がある人はいいが、そうでない人のために簡単な書き込み器を作ってみた。

 この回路は、「でんし研さん」のサイトに載っているAVR書き込みのアイデアや、「エレキジャック」に載っている PICデュアルライターにも使われている「RS-CR方式」を応用したもので、簡単な回路で「最初の1個のファームウェア」を書込むことができる。
 
 ただし、この回路には次のようなデメリットもあるのでそのことをよく理解したうえで作製/使用してほしい。

   「書き込みはできるが読み出しができない。」

 ・ほとんどの場合問題なく書き込むことができるが、
   「読み出しができない=ベリファイができない」
  ということなので、100%確実に書込めたかどうか確認することができない。
   実際に動作させてみるなど、別の方法で確認するしかない。

 ・PIC12F629/675などはプログラムメモリーエリアにオシレータの補正値があり、一般的に消去時は
   「補正値読出し -> 消去 -> 補正値再書込み」
  という手順が必要になるが、補正値の読出しができないために消去を行うと補正値を失うことになる。
   12F629/675の場合は一発勝負で書込むか、12F683のように補正値が消去されないデバイスで作製するしかない。  
  

 1) 回路図中のC1(0.01uF)はセラミック/積層セラミックコンデンサは避けて、 マイラ/ポリエステル/
  ポリプロピレンのようなフィルムコンデンサを使用

 2) 18ピン用回路は8ピンPICも使用可能。ソケットのPin1をそろえて挿入。

 
<FirmWriterコントロールソフト>
のダウンロード


PIC12F629/675の場合この回路で消去するとオシレータの補正値まで消去されてしまう。
正常に書き込みができなかった場合でも、消去、動作チェック、書込みを繰り返して行うことができる12F683の方が安心。
<12F683用Writer509ファームウェア>
のダウンロード


  この回路およびコントロールソフトは簡易型であり「最初の1個」の書込み用のため、前述の通り

   「読み出しができない」、「ベリファイができない」、「12F629/675のオシレータ補正値が保存できない」

 という制限のほかに、

   「シリアルポートにライターが接続されているかチェックできない」
   「目的の(選択された)デバイスがソケットに挿入されているかチェックできない」
   「デバイスがソケットに逆に挿入されていないかチェックできない」


 等の制約があるので、十分注意しながらの操作が必要となる。

  USB-RS232C変換ケーブルを含むほとんどのシリアルポートで使用できると思うが、一部のノートPCはシリアルポートの
 出力電圧が低いだけでなく出力電流が低い場合があるので、逆に「USB-RS232C変換ケーブル」のほうが確実に書込める
 可能性が高い。
2007/07/10追加
 USB-RS232C変換ケーブルの中にもこの回路に使用できないものがある。
 ノートPC、USB-RS232C変換ケーブルを問わず、マイナス側の電圧が出ないものはこの回路に使用できない(例:HL-340)。


つづく・・・


PIC Writerのメインへ
     
Topページへ