第１０回作成の「手動プログラム」主記憶では大したことができないので、ホスト8085にSRAMを接続しようとしています。別件シリーズでMicroPython制御のDMACモドキを作製、SRAMに読み書きできるようにしてみたのですが、その挙動が不審。ソフトウエアでぐちゅぐちゅやってないでロジアナあてたら原因判明。やっぱり？
別件シリーズで作成のSRAMモジュールとその問題
ただSRAMを8085に接続しても、オブジェクト・プログラムを書き込んでおかねば8085は初期化されないメモリの上を爆走するばかりです。そこで以下の別件シリーズにて、32KバイトのSRAMモジュールに対して、I2C制御のIOExpander MCP23017を２個使って得た合計３２ビットのIO線をつかい、これをMicroPython 制御でDMACとして動作させる「ソフトウエアDMAC」的なものを作製してみました。
MicroPython的午睡(141)M5Stack、SRAMモジュール読み書き、ダメダメよ
しかし、問題あり、読み書きができないこともないのですが安定しません。「ダメダメ」ね。
ダメダメの原因は２つの複合でした。
-
- I2Cバスは3.3V系から5V系にMOSFETを介して接続しており、ときどきACK信号を取りこぼしてました。さらにACKを取りこぼしたことを「確認しない」ソフトになっていて、そのまま先走ってしまっていたのでI2Cバス上の制御手順がダメダメ。
- 8085のマルチプレクスバス上でリードサイクル時にSRAMから「ありもしない」データを受け取ることがありました。期待通りの結果を得ることもあるのですが、ダメダメな結果の時もあります。タイミングを変えると読めるデータが変わります。なんで変なデータがデータバスに乗っているの？
直接の原因と対処
第１の方は、別件シリーズで対策済です。ちゃんとACKを確認し、ACKが届かないときは最初に戻ってやり直すと。先走るとホスト側とスレーブ側で状態に齟齬が生じて酷いことになっていたみたいっす。またSoftI2Cとしておけば、まかり間違ってもホストのI2Cインタフェースが変な状況に落ち込むこともなく、ソフトだけで復帰可能。そこでSoftI2C化しました。
一方、「データが化ける」件についてはデータバスを疑ってました。8085のマルチプレクスバスとて、アドレスバスのLSB側8ビットは74LS373でラッチして生成、データバス8ビットと分離してます。このデータバス８ビットに何かよからぬものが載っているみたいなのです。
結論を書いてしまうとデータバスによからぬものが載る原因はアドレスバスの上位側の８ビットにありました。AD2のロジアナ機能で観察したら一撃。
上の方にデータバスの下４ビットが表示されており、下から２番目がRD#信号です。このRD＃がロウの期間にSRAMの値を読み取るのですが、上記の赤丸の部分のように期待されない値がパタパタと何度も載ってしまってます。
SRAMに与えるアドレスのうち、下８ビットはデータバスと分離するためALEでラッチしています。74LS373がドライブしているのでたじろぐ素振りもありませぬ。しかし、MSB側のアドレス線がフラフラしているみたい。こころみにMSB側のアドレス線をロウに固定してみたらこんな感じ。
そしてMicroPython側のREAD/WRITEも安定。読み取りエラーなど起きませぬ。なんだ、データバスが安定しなかったのは、無関係に思いこんでいたハイ側のアドレスバスのせいなのね。。。
アドレスバスのハイ側に「ノイズ」が載る原因にも気づいた気がする。まあ、今回は誤動作の原因が分かったところまで。