[H8奮闘記 SRAM動作のアプリを C で作る（その２）]
使用した SRAM は、型番から 50ns 品と思います。50ns なら、2state@16MHz = 125ns
に充分間に合うはずです。そこで、デフォルト(3state)と2state の動作を見比べられる
テストプログラムを作成しました。
今回は、楽をするために C38HAB.LIB を使ってみました。
ダウンロード
crt0.asm は、B セクションをゼロクリアして main() を呼び出すスタートアップルーチンです。
SIZEOF, STARTOF 演算子でサイズと位置を求めているので、C のスタートアップルーチン
は、これを使い回せるはずです。
H8 は、アクセスステートコントロールレジスタ ASTCR で８つのブロックそれぞれを独立に
アクセスステート数を指定できます。デフォルトでは全てのブロックが３ステートアクセス
になっていますが、十分に高速なメモリ・デバイスが接続されている場合は２ステートアク
セスモードに切り替えることで高速化できます。
使用した SRAM は、ブロック１に接続してあるので ASTCR の bit1 を 0 にすることで２ス
テートアクセスになります。
テストプログラムの動作を見てもらうとわかりますが、2stateアクセスの場合は劇的に速く
なります。というのも、SRAM動作のプログラムの場合は、プログラムコードを H8 が読み
出す時にも３ステートと２ステートの違いが現れ、さらにその命令が SRAMを読み書きする
とそこでもステートの差が出ます。
SRAM を16bit 接続にすれば一度に読める量も増えるのでもっと速くなると思います。
※もし、３ステートアクセステスト完了後に暴走する場合は、SRAM が２ステートアクセス
に追従できていない可能性があります。利用した SRAM が十分に高速かどうか確認して
ください。たとえば、150nsec の SRAM だと２ステート(130nsec)に追従できません。
さて、実際に動かしてみた方はわかると思いますが、転送に異常なほど時間がかかります。
転送が遅い理由は、9600bps であることが一番の原因でしょう。
なぜ9600bpsにしたのか？
実装を簡単にするために、ポーリングで受信するようにしたため、確実に間に合う 9600bpsを
選択しました。
初めての実装であるため、「ロジックのバグ」と「通信取りこぼしバグ」の両方が発生してし
まう危険性を防ぐ意味もあります。
それでも速度的に間に合わないので、PC側の TeraTermPro の設定を、1msec/byte, 5msec/line
のウェイト付きにしています。このウェイト 1msec 指定でも、実際は 10msec くらい待ってい
るような動作をします（ MOT１行に約１秒の転送時間がかかる）。
このウェイトを外しても動作するくらいに、H8側のファームを高速にすればだいぶ高速化でき
そうです。
高速化検討
H8 の命令はあまり高速に動作してくれませんので、ポーリングがネックになります。
ポーリングで１バイト受信してから、次のポーリングが始まるまでの間に１バイト受信して
しまうと、そこから次のポーリングが始まるまでに送られてきたデータは全て取りこぼして
しまいます。
というのも、TxD, RxD しか配線していないため、PC 側は H8 の都合を考えずにどんどんデー
タを送ってきます。H8 の SCI には FIFO は無いので 1byte しか蓄積できません。
これの改善案として、次の２通りが考えられます。
(1) SCI を DMAC と接続してハードウェアでメモリに受信する
(2) SCI受信割り込みを利用してソフト的に FIFO を実現する
(1) の場合は、あらかじめサイズがわかっている場合に便利ですが、受信開始時にはいくつ
受信すべきかわからないため不適当です。
(2) の方法は、FIFO のサイズを十分にとり、簡単な通信プロトコルを用意すれば高速処理で
きそうです。
次回は、それにチャレンジです。
[前へ][▲上へ][次へ]