MikroCと16F88（16F689）でメモリー破壊

MicroCを使って秋月のPIC内蔵LCDをいじっています。
いろいろな表示をさせようと機能を増やしていくと、あるところからLCD表示が崩れたり、マイコンそのものが暴走してしまいます。この秋月I2C LCDを使わずに普通のキャラクタLCDとF88の組み合わせでも同じです。



MikroCのLogファイルを見ると、次のワーニングが出ていることに気がつきました。
トラブルが起きない場合はワーニングがありません。

warning: 43 1511 IRP bit must be set manually for indirect access to 'c_vol' variable main.c
warning: 43 1511 IRP bit must be set manually for indirect access to 'c_amp' variable main.c
warning: 43 1511 IRP bit must be set manually for indirect access to 'c_wat' variable main.c
warning: 44 1511 IRP bit must be set manually for indirect access to 'c_wats' variable main.c

うまくいくときとダメなときのRAMの使用量を比べてみました。

Used RAM (bytes): 110 (46%) Free RAM (bytes): 130 (54%)
Used ROM (program words): 871 (21%) Free ROM (program words): 3225 (79%)
うまくいくとき

Used RAM (bytes): 200 (83%) Free RAM (bytes): 40 (17%)
Used ROM (program words): 1218 (30%) Free ROM (program words): 2878 (70%)
ダメなとき

ここでググったりして色々調べたところ、RAM BANKが0と1を超えるとMikroCはダメだと言うことが判りました。BANK-0と1の切り替えまではコンパイラーが旨くやってくれるようです。

F689ではRAMのBANK構成は次のようになっています。



これをみると、BANK-0で96バイトとBANK-1で80バイトですから、176バイトを超えるとダメということが判ります。たしかに110バイトで済んでいるコードは動いていますが、200バイトを必要とするコードはバグります。

＜追記＞
生成されるアセンブルコードの状況によっては176バイト以下でもダメな場合がありました。BANK-0の90バイト以内にしてうまくいきました。テーブルをやめてループで描画するようにして一気にRAM使用量を減らした結果です。


これを回避するにはいくつかのアドバイスが有りました。

1. 一番簡単なのは仮想リニアアドレッシング機能を持っている別のPICを使う（16F1827は大丈夫だった）
2. 18Fシリーズを使う（全て仮想リニアアドレッシング機能がある）
3. MikroC以外のコンパイラを使う

ということです。
秋月I2C液晶乗っているPICのRAMを目一杯使いたいときはMikroCを捨てなくてはなりません。純正のXC8は大丈夫っぽいのですが、ライブラリが貧弱なのでメンドクサイですね。MikroCはLCDライブラリとかが揃っているので採用したのですが。この液晶に拘らなければ、仮想リニアアドレッシング機能をもったPICを使えば良いだけですが。ピンコンパチで貼り替えできるのが見つかれば良いのですが。しかもSOICピッチ。

ググってもなかなか見つからなかったのでBlogで書いておきます。
国内では全然見つかりませんでした。

コメント 1

PIC は足を洗ってしまって分かりませんが，MPLAB + XC8(?) でも同じでしょうか？Mac でも MPLAB X ってのがあるので，インストールしてみましたが，PICKIT が行方不明になってました．苦笑

ちなみに AVR で使っている Crosspack も最新版を入れたら，delay 関連で挙動が変わってたりしました．
by ocr (2013-12-21 11:30)