ＪＤＭプログラマ用で１２Ｆ６２９/６７５に再書き込みできない問題

　高機能なフラッシュタイプのＰＩＣ１２Ｆ６２９やＡ/Ｄコンバータ内蔵の１２Ｆ６７５が国内でも安価に入手できるようになってきました。このＰＩＣとＪＤＭプログラマ、ＩＣ-Ｐｒｏｇがあれば、低予算で電子工作がたのしめそうです。ところが、ここで難問がもちあがりました。ＲＯＣさんのホームページの掲示板でも投稿がありましたが、「ＩｎｔＯＳＣモードでＰＩＣ１２Ｆ６２９（６７５）に書きこむと、次回から読み書きも消去もできなくなった」という問題です。

　ＦＥＮＧ３は当初、マイクロチップ社のデータシートにＶｄｄが適用される以前にＧＰ２、ＧＰ４、ＧＰ５に電源を供給してしまうと、ＰＩＣがプログラムを実行して動き出してしまう、という記述があったので、それが原因だとかんがえていました。それで、ＪＤＭプログラマのオリジナルの回路では、ＧＰ４をＶｄｄに、ＧＰ５をＧＮＤに接続するようになっていたのですが、ＦＥＮＧ３のホームページで公開しているＪＤＭプログラマの改良版では、ＧＰ４、ＧＰ５に何も接続しないであそばせておくか、ＧＮＤに接続するように以前からしていたのです。ところが、ＩｎｔＯＳＣモードでＰＩＣ１２Ｆ６２９/６７５へのプログラム書き込みをすると、上記のような回路でも、次回から再書き込みがまったくできなくなる場合がでてきたのです。「ＰＩＣが壊れてしまったのか？」と思ってしまいました。それで、改めてマイクロチップ社のデータシートにあたってみますと、ＰＩＣ１２Ｆ６２９/６７５のプログラミングでは、Ｖｄｄが適用される前にＶｐｐが上昇してプログラミングモードに必要な電圧になっていることが必要だとわかりました。ところが、ＩＣ-ＰｒｏｇではＰＩＣ１２Ｆ６２９/６７５に対応していても、ＪＤＭプログラマではＶｄｄをもともと制御できるようなつくりになっていません。ＪＤＭプログラマのばあい、ＩｎｔＯＳＣモードにしたばあい、ＭＣＬＲがデバイス内部でＶｄｄにプルアップされているようなので、Ｖｐｐが上昇するよりもさきに、というよりも、ＪＤＭプログラマにプログラムを書きこんだデバイスを挿入してＰＣと接続した時点でＶｄｄが適用されて自動的にリセットがかかり、内蔵クロック、プログラムカウンターが動作しはじめて、プログラムコードを実行することになります。つまり、ＰＩＣが壊れてしまったのではなくて、ＰＩＣライタのほうが再書き込みに対応していなかったわけです。もちろん、再書き込みできないだけで、ＰＩＣには１回目のプログラムが書きこまれています（すべての場合ではありません。ねんのため）。しかし、このままでは、１２Ｃ５０９ＡなどのワンタイムプログラミングのＰＩＣとかわりません。フラッシュタイプなのに、プログラムの再書き込みはおろか、プログラムの読みこみもできなければ、価値は半減してしまいます。

　ＪＤＭプログラマは、とてもよくかんがえられたＰＩＣライタで、シリアルポートの信号線から電源をとるため、外部電源不要で、しかも少ない部品点数で安価にこしらえることができます。これと、書きこみソフトであるＩＣ-Ｐｒｏｇと組み合わせれば、最新のデバイスにも対応できる、はずです。しかし、上記の問題については、ＩＣ-Ｐｒｏｇの作者も作者の掲示板で「ＪＤＭプログラマのように電源電圧をきりかえることのできないプログラマでは、ＰＩＣはすでに動作をはじめており、読みこみ・書き込みで失敗する。ほかのプログラマでためしてください」という内容のコメントを書いています。それでＦＥＮＧ３も電源を制御できるＰＩＣライタをこしらえようと、ＩＣ-Ｐｒｏｇで対応しているパラレルポート接続のＰＩＣライタを数台こしらえたのですが、いずれもライタ自体が動作しませんでした。原因は、ＦＥＮＧ３のパソコンのパラレルポートが壊れていたからでした。

　つぎに、アナログスイッチ（４０６６）をＪＤＭプログラマにとりつけて、Ｖｄｄを制御できるようにしてみました。すると、読みこみができるようになりました。でも、再書き込みでエラーがでてしまいました。アナログスイッチの応答時間は、Ｖｄｄの適用を遅らせるのに不向きなのか、それとも流せる電流がすくなかったのでしょうか。よくわかりません。つぎにＪＤＭプログラマでためした方法は、ＧＰ３を抵抗でＶｄｄにプルアップすることです。この方法でも、読みこむことはできましたが、再書き込みはできませんでした。

　解決法がみつからないで考えあぐんでいたころ、トランジスタを２個つかってＶｐｐのオンオフでＶｄｄをスイッチさせてみると、再書き込みができるようになった、というメールを「シロ」さんからいただきました。さっそくためしてみたところ、みごとに読みこみ・消去・再書きこみができるようになりました。でも、トランジスタで回路を付け加えるのは、部品点数が増えるということもありますが、電子工作初心者のＦＥＮＧ３にとっては、自分ではライタが動作するから納得しても、いざ回路図を公開するとなると、抵抗の定数など自信がまったくありません。

　それで、ＧＮＤを相対的な＋５Ｖの基準電圧にしているオリジナルのＪＤＭプログラマではなくて、３端子レギュレータをつかったＪＤＭプログラマにトランジスタの回路を付け加えてみました（写真下）。１２Ｆ６２９、１２Ｆ６７５をつかったテストの結果は良好でした。

　ＰＩＣ１２Ｆ６２９/６７５に完全対応するようにＪＤＭプログラマを改造する

注意！　下記の改造をすると、１２Ｃ５ｘｘなど他の８ピンＰＩＣには対応しなくなるばあいがあるかもしれません。ＦＥＮＧ３が１２Ｃ５０９Ａでテストしたところ、１回だけ書きこみでエラーがでました。２個目以後はエラーはでませんでしたので、原因はソケットへの差し込み不良など他にあるのかもしれませんが、他の８ピンＰＩＣで何度も書きこみエラーがおきるばあいは、デバイスの選択スイッチをとりつけてＶｄｄを切りかえるようにするか、１２Ｆ６２９/６７５には下記アダプタで対応するようにする、という方法があります。

　上記の７８Ｌ０５をつかったＪＤＭプログラマは、トランジスタ２個と抵抗を追加するだけなのですが、すでにＪＤＭプログラマをこしらえた方にとっては、新たにライタをつくる必要があります。それで、いまあるＪＤＭプログラマに少し手をくわえるだけで１２Ｆ６２９/６７５に対応できるようにならないものだろうかと考えて、こんどは、フォトカプラをつかってＶｄｄをスイッチしてみることにしました。東芝の汎用フォトカプラＴＬＰ５２１-１（ランクはＧＢ）を使いました。ながせる電流はＰＩＣのプログラム書きこみに必要な範囲ぎりぎりというところだとおもいますが、Ｖｄｄの適用を遅らせるためのスイッチングの応答速度はちょうどよさそうです。下図がその回路の追加例です。フォトカプラの発光側の電流は、デバイスが要求するＶｐｐとＶｄｄの電流のバランスをとるために２．２ｋオームの抵抗Ｒ３をいれて制限してあります。また、発光側の発光ダイオードには、耐圧７Ｖをこえる逆電圧がかかる可能性がありますので、逆電流をふせぐためにダイオードＤ８を挿入しました。

　訂正　最初に公開した追加回路図で、ＶｄｄがＰＩＣの端子につながったままになっていました（yu.linusさんからのご指摘）ので、お詫びして訂正します。yu.linusさんのホームページも参照してください（２００３年１１月１６日）。

　訂正　１８ピンのＰＩＣのＶｄｄ端子もスイッチさせてしまうと、１６Ｆ８４Ａなどに読み書きでエラーがでることもまれにあるようなので、Ｖｄｄと直結するように回路図を訂正しました。また、アダプタのほうも配線を訂正しました（２００３年１１月１８日）。

　追加情報　フォトカプラＴＬＰ５２１-１は周囲温度の変化によって誤動作したり特性が大きくかわるばあいがあります。ＰＩＣへのプログラム書きこみや読みこみ、消去などでエラーがでたり、読みこんだコードがおかしくなったりするときは、フォトカプラの発光側の電流制限抵抗Ｒ３を４．５ｋオームから４．７ｋオーム程度の抵抗にとりかえてためしてみてください（２００３年１２月３日）。

　トランジスタをつかってＶｄｄの適用を遅らせる回路が、ＩＣ-Ｐｒｏｇの作者のホームページの掲示板にさいきん投稿されていましたので、紹介しておきます。

　トランジスタ１個とＣＲをつかってＶｄｄの適用を遅らせるかんたんな回路を海老原さんがライタの写真つきで公開されています。部品点数が少ないので、こちらもためしてみてください。海老原さんのご厚意により、個人的な日記のページに直接リンクしています。

　上記えびめもで紹介されている回路をアラムさんがＪＤＭプログラマに挿入できるアダプタにされました。回路図　作例写真１　作例写真２

　ＶＤＤ遅延回路をつかったライタでのトラブル（２００３年１２月９日）

　上記Ｖｄｄの遅延回路をつかって、ＰＩＣ１２Ｆ６２９へＩｎｔＯＳＣモード（ＭＣＬＲオフ）でプログラム書きこみしたのち、デバイスを消去すると、プログラム再書きこみで失敗し、さらにデバイスを読みこんでみると、「０」で埋め尽くされたようになり、復旧できなくなる、という事例があります。くわしいトラブルの状況については、yu.linusさんのホームページをご参照ください。

　ここでは、ＦＥＮＧ３がこのトラブルをまず再現してみようとおもいます。

　１）まず、未書きこみのブランクのデバイスを用意します。Ｖｄｄの遅延回路をつけたライタで、内蔵オッシレータのキャリブレーション値を読みとって、メモしておきます。

　２）コンフィグビットを、ＩｎｔＯＳＣモード、ＭＣＬＲオフにして、プログラム書きこみを実行します。

　３）プログラム書きこみが正常におこなわれ、ベリファイでＯＫとなります（ここで、内蔵オッシレータのキャリブレーション値が正常に書きこまれていなくてもベリファイでＯＫがでることがあります。対処方法はこの章の最後のほうで説明します）。

　４）つぎに、デバイスの消去を実行します。プログラムメモリやデータメモリは消去されますが、コンフィグビットは、さきに書きこんだ設定のままになっているときがあります。

　５）さらにコンフィグビットもデフォルト状態にもどそうと、ＩＣ-Ｐｒｏｇの設定でＩ/Ｏの遅延をいろいろためして消去をくりかえしていると、下図のようになることがあります。

　この現象を、もっとかんたんに再現できないものか、挑戦してみました

　１）まず、未書きこみのブランクのデバイスを用意します。標準のＪＤＭプログラマで、内蔵オッシレータのキャリブレーション値を読みとって、メモしておきます。

　２）プログラムメモリの０３ＦＦ番地を「００００」にして、ＩｎｔＯＳＣモードでＭＣＬＲをオフにして、プログラム書きこみを実行します。

　３）ＩＣ-ＰｒｏｇでＩ/Ｏの遅延を最小の（１）にしてデバイスを読みこむと、上の図のようになります。

　デバイスがこんな状態になると、正直いって、おどろきますね。消去もできないようだし、再書き込みしてもエラーがでるし…。それで、なぜこうなるのかという原因の追求はあとでやるとして、こんな状態になったデバイスをデフォルト状態にもどす、つまり、ちゃんとデバイスの消去（Ｂｕｌｋ　Ｅｒａｓｅ）ができるようにするには、どうしたらいいかということです。デバイスを復旧させることが先決ですので、ＦＥＮＧ３はそのようにしました。

　「０」で埋め尽くされたデバイスをデフォルト状態に戻すには、ちょっとした「テクニック」が必要です。

　まず、標準のＪＤＭプログラマでの方法を紹介します。この方法は、デバイスにプログラムコードが書きこまれていないことを前提にしていますので、ＩｎｔＯＳＣモードでＭＣＬＲをオフにしてプログラムコードを書きこんだデバイスにたいしては、ＰＩＣが動作をしますので、おそらく有効ではありません（消去できたようにみえても、実際にはまったく消去されていません）。

　１）ＩＣ-ＰｒｏｇのＩ/Ｏの遅延を最大（４０）にして、デバイスの消去を実行します。

　２）つぎに、Ｉ/Ｏの遅延を調節して（１０程度）、デバイスの消去を実行します。

　つぎに、Ｖｄｄの遅延回路をとりつけたＪＤＭプログラマでの対処方法を紹介します。この方法は、実際にＩｎｔＯＳＣモードでＭＣＬＲをオフにしてプログラム書きこみをおこなったばあいを想定していますので、プログラムの再書きこみをするときなどに直面するかもしれない現実的な問題への対処方法です。

　１）Ｖｄｄの遅延回路をとりつけたＪＤＭプログラマで、デバイスの消去を実行します。

　２）Ｖｄｄの遅延を適用しないで（デバイスのＶｄｄ端子にＶｄｄをテストリードなどで結線する）、ＩＣ-Ｐｒｏｇの設定でＩ/Ｏの遅延を最大（４０）にして、デバイスの消去を実行します。

　３）Ｖｄｄの遅延を適用しないで、ＩＣ-Ｐｒｏｇの設定でＩ/Ｏの遅延を調節（１０程度）して、デバイスの消去を実行します。

　さて、ＰＩＣ１２Ｆ６２９/６７５にＩｎｔＯＳＣモードでＭＣＬＲをオフにしてプログラム書きこみをしたのち、デバイスの消去をするとメモリが「０」で埋め尽くされるのは、いったいなにが原因なのでしょうか？　正直いいますと、ＦＥＮＧ３にもほんとうのところはよくわかりません。わかりませんが、けっしてＰＩＣが壊れてしまったので、消去も再書きこみもできなくなったわけではないことは、たしかです。下の図は、デバイスを再書き込みしようとしてデバイスを消去したら、メモリが「０」で埋め尽くされたさきほどの上の図のＰＩＣ１２Ｆ６２９を、ＩＣ-Ｐｒｏｇの設定でＩ/Ｏの遅延を調節して読みこみ直したものです。プログラムメモリの０３ＦＦ番地が「００００」になっているのがわかるとおもいます。つまり、０３ＦＦ番地にあるべきインストラクションとオッシレータのキャリブレーション値がそれぞれ「０」として書きこまれてしまっていたのです。なぜ「０」が誤って書きこまれてしまうのか、その原因はよくわかりません。Ｖｄｄのみの遅延だけでなく、ＤＡＴＡやＣＬＯＣＫも関係してくるのでしょうか。

　上の図のようになってしまうと、ＰＩＣの内蔵オッシレータに依存したタイミング機構が正常に機能しなくなるのではとおもわれます（まちがっていたら、ごめんなさい）。英語だらけのＰＩＣのデータシートですので、英語の理解力にとぼしいＦＥＮＧ３にはよくのみこめないのですが、デバイスの消去時には、このタイミング機構が必要不可欠になっているのに、これが正常に動作しないとなると、消去もできないということになります。Ｖｄｄを遅延させないようにして、ＩＣ-Ｐｒｏｇの側で遅延を最大にしてデバイスの消去を実行すると、こんどは、０３ＦＦ番地が「３ＦＦＦ」にもどります。この操作をおこなった直後の時点では、他のプログラムメモリやデータメモリのエリアはふたたび「０」で埋め尽くされます。そして再度、ＩＣ-ＰｒｏｇのＩ/Ｏの遅延を（１０）程度に小さくしてデバイスの消去を実行すると、こんどはインストラクションと内蔵オッシレータのキャリブレーション値は消去された「正常な」状態ですので、デバイスが正常に消去され、プログラムメモリやデータメモリ、コンフィグビットの状態も正常なデフォルト状態にもどる……そんなことではないかと、電子工作初心者のＦＥＮＧ３は考えています。

　より確実に再書きこみをおこなうには…

　上述のように、ＦＥＮＧ３が実地にためしてみた経験から、ＰＩＣ１２Ｆ６２９/６７５にＩｎｔＯＳＣモードでＭＣＬＲをオフにしてプログラム書きこみをして、再書きこみや消去をするばあいには、ＪＤＭプログラマではつぎのようにすれば、より確実になるのではないかとかんがえています。

　１）ブランクのデバイスにプログラム書きこみをするときは、標準のＪＤＭプログラマでおこなう（ベリファイでエラーがでることがあるが、気にしない）。
　２）１）でデバイスにプログラムが正常に書きこまれているかどうかを確認するときや、読みこむときは、Ｖｄｄの遅延回路を使う。

　３）デバイスを消去して再書きこみするときは、まず、Ｖｄｄの遅延回路を使って、デバイスの消去を実行し、ライタ上で動作するおそれのあるプログラムコードを消しておく。

　４）つぎに、０３ＦＦ番地を消去するために、Ｖｄｄの遅延回路を使用せずに、ＩＣ-ＰｒｏｇでＩ/Ｏの遅延を最大にしてデバイスを消去する。

　５）Ｖｄｄの遅延回路を使用せずに、ＩＣ-ＰｒｏｇでＩ/Ｏの遅延を（１０）程度にして、プログラムメモリとデータメモリ、コンフィグビットを完全に消去する。

　以上です（あぁしんど）。なお、「ＲＣＤライタ」では、このようなやっかいな問題はまだ報告されておりません（２００３年１２月９日現在）。

　ご注意！　上記の操作をおこなうと、ＩＣ-Ｐｒｏｇやパソコンがその後の操作でフリーズ状態になってしまうことがあるかもしれません。今回の事例だけにかぎりませんが、ＩＣ-Ｐｒｏｇを使用していてフリーズ状態になったばあいは、データを保存してからパソコンを再起動し、そののち、ＩＣ-Ｐｒｏｇのハードウェアの設定を初期化してＩＣ-Ｐｒｏｇを再起動するか、ＷｉｎｄｏｗｓのレジストリエディタをつかってＩＣ-Ｐｒｏｇのレジストリを削除すると、復旧します。

　ＰＩＣ１６Ｆ６ｘｘ、１６Ｆ８ｘｘでも再書き込みできるのか？

　フラッシュタイプのあたらしいＰＩＣがつぎつぎと登場しています。それらのなかには、プログラミングにさいして、たとえばＶｄｄを可変させる特別なアルゴリズムをとっているものもあります。ＶｄｄよりもさきにＶｐｐを適用したら高電圧プログラミングモードで、ＶｐｐよりもさきにＶｄｄを適用したら低電圧プログラミングモードになる、といったぐあいです。８ピン以外のＰＩＣでも電源以外のすべての端子をＩ/Ｏピンに設定できるタイプも登場しているようですので、１２Ｆ６２９/６７５でおきた問題と同様の、いやそれ以上の難問にＪＤＭプログラマは遭遇するかもしれません。しかし、努力すれば、解決することができるかもしれません。あたらしいデバイスでも入手できしだい、テストしてみる予定です。また、みなさんからのご意見、ご感想、お叱りなど、ＦＥＮＧ３は歓迎します。

　nyaoさんから、ＰＩＣ１６Ｆ８１９にＩｎｔＯＳＣモードで書き込みすると、再書き込みができなくなるという報告をいただきました。正確にいうと、後閑さんのホームページにあるＰＩＣ１６Ｆ８１９のサンプルプログラムを、ＦＥＮＧ３のホームページで紹介しているゼロプレッシャーソケットでつくるＰＩＣライタ５号機で、ＭＣＬＲをオフにしてプログラム書きこみをすると、次回から読み書きできなくなるが、なんどもデバイスの消去を繰りかえすと、再書き込みできるようにはなる、ということのようです。

　この現象を再現するのに、少々時間がかかりました。というのは、シリアルポート接続のＰＩＣライタ（ＪＤＭプログラマ）のすべてのタイプでおきるわけではないからです。また、おなじタイプのライタでも、再書き込みできるばあいとできないばあいがあって、一様ではなかったからです。

　まず、ゼロプレッシャーソケットタイプのＰＩＣライタ５号機で、この現象を再現してみました。ＭＣＬＲをオンにしてプログラム書きこみをしたばあい、エラーもでずに書きこみが終了し、その後、再書き込みも問題なくできました。ライタのＬＥＤは点滅しません。

　つぎに、おなじライタでＭＣＬＲをオフにしてプログラム書きこみをしてみました。すると、ベリファイでエラーがでるばあいがあります。その直後から、ライタのＬＥＤが点滅をはじめます。そして、次回からデバイスの消去を実行しても、プログラムの再書き込みができなくなりました。

　では、さいしょに書きこんだプログラムは、ＰＩＣにちゃんと書きこまれていて、正常にうごいているのでしょうか。実験ボードをつかってテストしてみました。実験ボードは、ＦＥＮＧ３がＰＩＣの勉強をはじめたころにつくったものです。８つのＲＢポートにＬＥＤをとりつけてありますので、こんかいＰＩＣに書きこんだサンプルプログラムには、うってつけです。さいしょに、ＭＣＬＲをオンにしてプログラムを書きこんだＰＩＣをテストしてみました。ライタに挿入したときにはライタのＬＥＤは点滅しませんでしたが、実験ボードでは、８つのＬＥＤがクロック速度をしだいに遅くしながら点滅します。つまり、ライタのＬＥＤは点滅しませんでしたが、プログラムは正常に書きこまれ、動作していたわけです。ＭＣＬＲをオンにしてありますので、実験ボードのリセットボタンを押すと、ちゃんとリセットされて、プログラムが最初からスタートします。

　つぎに、ＭＣＬＲをオフにして書きこんだＰＩＣを実験ボードにセットしてためしてみました。こちらも、プログラムどおりに８つのＬＥＤが交互に点滅します。こちらもプログラムは正常に書きこまれ、動作しています。ただし、ＭＣＬＲをオフにしてあるため、実験ボードのリセットボタンを押してもリセットは効きません。

　それではなぜ、ライタ上では、ＭＣＬＲをオンにしてＰＩＣに書きこんだばあい、ライタのＬＥＤは点滅せず、ＭＣＬＲをオフにしてＰＩＣに書きこむと、ライタのＬＥＤが点滅したのでしょう？　こたえは、マイクロチップ社のＰＩＣ１６Ｆ８１８/８１９のデータシートに書かれていました。ＰＩＣ１６Ｆ８１８/８１９では、プログラミングモードに入るさいに、Ｖｄｄが上昇してから１００マイクロ秒以内にＶｐｐがプログラミングモードに入るのに必要な高電圧に達している必要があります。そうでないと、ＩｎｔＯＳＣモードのばあいは、ＰＩＣが予想外の命令を実行しだすばあいがあるというのです。つまり、ＰＩＣがライタ上で電源を得てうごきだすばあいがあるというわけです。ですが、ＭＣＬＲをオンにしたばあいは、ライタにつながっているＭＣＬＲ端子はＬｏｗなので、ＰＩＣはＶｄｄをライタから供給されてもうごきだしませんので、ライタのＬＥＤは点滅しなかったわけです。ＭＣＬＲをオフにしたばあいはどうなるのでしょう。ＭＣＬＲをオフにすると、ＩｎｔＯＳＣモードのばあいは、ＭＣＬＲがＰＩＣ内部でＶｄｄにプルアップされるようです。そのために、プログラム書きこみが終了した時点で、ベリファイをまたずにＰＩＣがリセットされ、プログラムが実行されてライタのＬＥＤが点滅するようになった、というわけです。

　ところで、おなじＪＤＭプログラマあるいはその改良型で、つかっている部品も回路もそうたいしてかわらないのに、どうしてプログラム再書き込みができたりできなかったりするのでしょうか？　これも、実験してみました。実験には、標準のＪＤＭプログラマ、ゼロプレッシャーソケットタイプのＰＩＣライタ５号機（以下、ＰＩＣライタ５号機）、「スマートメディア」サイズのＰＩＣライタ（以下、「スマートメディア」…）をつかいました。これらのライタで、さきほどのサンプルプログラムをＭＣＬＲをオフにしてプログラムを書きこんで、その後、再書き込みをしてみました。

　結果は、標準のＪＤＭプログラマとＰＩＣライタ５号機では、たびたびプログラムの再書き込みができなくなることがわかりました。再書き込みができなくなったばあい、デバイスの消去をなんども実行するか、書きこみソフトＩＣ-Ｐｒｏｇの「設定」の「ハードウェア」で、「Ｉ/Ｏの遅延」を最大に設定してからデバイスを消去し、設定をもとにもどしてから再書き込みすると、うまくいくこともわかりました。「スマートメディア」…では、問題なくプログラムの再書き込みができました。

　ライタによってなぜちがうのでしょうか？　ＦＥＮＧ３は測定器具といってもテスターしかもっていませんので、こたえはかんたんではありません。でも、ＭＣＬＲをオフにしてＰＩＣにプログラムを書きこんだそれぞれのライタの端子間電圧を測ってみました。サンプルプログラムは、ＲＢ０からＲＢ７の８つのポートに接続されたＬＥＤを点滅させるようになっています。ところが、ライタのほうは、プログラミングに必要な電源と信号ピン以外の「あそんでいる」ピンのあつかいが、それぞれことなります。あそんでいるピンをＧＮＤにおとしているばあいは、ＶｄｄがＧＮＤにＰＩＣのピンをとおしてつながっていることになります。また、ＬＥＤを駆動させる電流がライタのクロックやデータラインにまわりこんだりします。そのため、ライタのＶｄｄはおおむね、ＬＥＤの点滅にしたがって、＋５ＶとＧＮＤの中間値になっていまいます（ＪＤＭプログラマのばあいは、１．８２Ｖから２．１５Ｖ、ＰＩＣライタ５号機のばあいは、２．１５Ｖから３．０Ｖ、「スマートメディア」…のばあいは、２．１５Ｖから２．３７Ｖのあいだをそれぞれ変動）。

　Ｖｐｐの立ち上がりの速度について、計測してみる必要がありますが、ＦＥＮＧ３はその器具をもっていませんので、計測できません。推測になりますが、今回ＰＩＣに書きこんだサンプルプログラムについては、「スマートメディア」…のＶｐｐのたちあがりがまさっていたので、再書き込みが可能になったのではないでしょうか？　他の方の検証を期待します（２００３年１１月２３日　下記の「アダプタの製作です」と前後する内容をふくんでいますが、この場所に追加しました）。

　１６Ｆ８１９でも内部クロックモードでプログラム書き込みをすると、１２Ｆ６２９/６７５と同様の問題がおきるという報告がありましたので、少し前から製作していたＪＤＭプログラマ用のアダプタを公開します。回路図、部品等は上記の追加回路とおなじです。あと必要なものとして、丸ピンの８ピンのＩＣソケットが２個、１８ピンのＩＣソケットが１個（これは丸ピンでも平ピンでも可）、ユニバーサル基板のあまり（４×１７個の穴が必要です）、線材、接着剤などです。すでにＰＩＣライタをこしらえていて、配線が密になっていますと、回路の追加もめんどうなものです。このアダプタは、標準のＪＤＭプログラマやＦＥＮＧ３のホームページで紹介しているＰＩＣライタに対応しています。ライタのソケットの８ピンＰＩＣを挿入する位置にアダプタをセットして使用します。１８ピンタイプのＰＩＣでもこのアダプタが役立つのか、検証作業はこれからです。テストされたかたは、結果をＦＥＮＧ３までおしらせくださるとうれしいです（２００３年１１月１６日）。

訂正　１８ピンのＰＩＣでは、Ｖｄｄをスイッチさせると読み書きでエラーがまれにでることがわかりましたので、Ｖｄｄの配線をつけかえました。ＰＩＣ１６Ｆ８１９にどうやって対応するかは、これから模索します。したがって、１８ピンのＩＣソケットでなくても８ピンのソケット３個でアダプタがつくれるということになりそのばあいは、基板サイズも４×１２の穴数があればいいことになります（２００３年１１月１８日）。

　注意事項：ＰＩＣライタの製作にあたっては、自己責任でおこなってください。このページに記載されている情報をもとに製作された結果、ライタが動作しない、ＰＩＣが破損した、パソコンが壊れた、家庭不和になった等の損害を被られても、ＦＥＮＧ３はいっさい関知しません。