PLCCのDIP変換ソケットは基板のパターン配線が少し大変なので、DIPタイプがないかな～、と探していたんですが、割とすぐに見つかりました。
○DIPタイプの2Mbitフラッシュメモリと256KbitEEPROM
右側半分がWinbondのW29C020C、左側半分がHITACHI(当時、現ルネサス)のHN58C256Pです。
(右下の一つだけ斜めになっているのが気になる…。ここまで綺麗に揃えたのなら、最後まで揃えて欲しかったw＞ショップ)
W29C020Cはこれまで使っていたEONのEN29F002とピンアサインが同じなので、書き込みソフトを作ればそのまま 前に作った書き込み基板 で書き込みできますので早速ソフトを作りました。
しかし、これが意外と難産でした。
EN29F002とW29020Cでは
EN29F002：byte-by-byteによる書き込み
→一度イレースしてから1バイトずつ書き込んでは書き込み完了を待つ書き込みかた
W29C020：128バイトごとのPage Write
→イレース処理が不要でプログラムからはとにかくデータを1ページ分ずつチップに送る書き込みかた(イレースと書き込みはチップ内部でページごとに勝手に行なってくれる)
という違いがあります。
当然プログラムの処理も変わるので前のプログラムをベースに作り直したんですが、これがちっとも動かない（苦笑
原因は書き込み処理の書き方でした。
最初は書き込み開始コマンド送信後次のように1バイトずつフラッシュメモリに書き込んでいました。
for ( i = 0 ; i < sizeof(buf) ; i++ )
{
*(PAGE2_ADDR + i) = buf[i];
}
この処理はEN29F002で1バイトずつ書き込み命令を送っていた名残です。
しかし、これだとコンパイルされた命令の処理が多すぎて、フラッシュメモリへの書き込み開始コマンド送信から実際に書き込むデータが送られるまでに時間がかかりすぎてしまい、書き込み開始コマンドがタイムアウトしてしまっていました。
これを次のように直したら、ちゃんと書き込めるようになりました。
memcpy(PAGE2_ADDR, buf, sizeof(buf));
Cのソースからアセンブラソースを出力してわかったんですが、z88dk(というかz88dkがベースにしたSmall-Cかも)のコンパイラは変数の値を常にHLレジスタに入れて処理するようになっていて、"push hl","pop hl"が頻繁に使われていました。
先のfor文をコンパイルすると、アセンブラで30近い命令になります。
これをmemcpy()に置き換えると、関数の引数をスタックに積むpush命令3つとcall命令、memcpy()本体の10個足らずの命令で済みます。
W29C020Cの仕様上書き込みコマンドから100μ秒以内に書き込むデータを送らないと書き込みコマンドがタイムアウトしてしまうのですが、for文を使った場合実は結構ギリギリのところで間に合っていませんでした。
これはさすがにCのソースからは原因がつかめませんでした。
タイミングが重要な処理では、アセンブラソースで確認することも必要ですね。
次から気をつけます。
◇◇◇
さて、W29C020Cでは書き込み開始コマンドの後一度にデータを送れるので、1バイトごとに書き込み開始コマンドの送信をするEN29F002よりも書き込み時間が短くなるんじゃないかと思い、書き込み時間を比べてみました。
書き込みデータのサイズ：32KB
書き込みにかかった時間
W29C020C：約12分30秒
EN29F002：約13分30秒
チップの特性の違いもあるので単純に比較はできませんが、絶対値としてはあまり早くなりませんでした。残念。
◇◇◇
一緒に買った256KbitEEPROM用のアダプタと書き込みプログラムを作って、現在動作確認中です。が、うまくいってません。
このEEPROMはフラッシュメモリと違って書き込みコマンドの送信は不要で、普通のRAMと同じように書き換えできるので書き込みプログラムは最も簡単になるはずです。
こちらもしょうもないチョンボをしていそうなんですが…。
わかったらまた更新します。
【12/23更新】
やっぱりデータシート記載の見落としでした。
W28C020Cのデータシートでは「Page Write Mode」の項に「チップ内部で書き込み処理をしている間に、次のページのデータ送信をしてもいい」と書かれています。
しかし、HN58C256のデータシートの「Automatic Page Write」の項には特に「いい」とも「ダメ」とも書いてなかったので、同じように処理していました。
もう一度HN58C256のデータシートを隅々まで読んだところ、「Write Cycle」のパラメータ(信号のタイミングチャートにある時間)が載っているリストの欄外に「Data Pollingをしないなら、10m秒以上待ってから次のページの書き込みを始めること」と書いてありました。
これもかなり意訳したもので、実際にはタイミングチャートとリストに載っている時間、その欄外の但し書きを突き合わせて初めてそう解釈できる内容でした。
1ページごとに10ms以上ウェイトしてから次のページのデータを送るようにしたら、あっさり動きました。
【12/23更新終わり】
◇◇◇
ちなみに、フラッシュメモリもEEPROMの一種ではあるのですが、この記事ではイレース処理なしでバイト単位に書き換えができる不揮発RAMを「EEPROM」、書き換えにイレース処理が必要な不揮発RAMを「フラッシュメモリ」と呼んでいます。
◇◇◇
更にちなみに上ではEEPROMとフラッシュメモリに対して「不揮発RAM」という言葉を使っています。これは、EEPROMもフラッシュメモリもランダムアクセス可能なメモリ(RAM)だからです。
(EEPROMやフラッシュメモリを「ROM」と呼ぶのも個人的には抵抗があります)
世間では「RAM」を"電源が切れると内容が消えるメモリ"という意味で使っていることがありますが、これは厳密には間違った用法です。
"電源が切れると内容が消えるメモリ"を示す略語は正しくは「VM(Volatile Memory：揮発メモリ)」です。
時代と共に意味が変わった言葉というのはありますし、それは仕方がないと思います。
しかし、略す前の言葉と違う意味で略語が使われるのはなんだか落ち着かないですね。
まあ、ただの年寄りのぼやきでした。