[WitchTech 00860] Re: ファイルアクセスとシリアル割り込みが重なるとシステム破壊

[IMAIZUMI Osamu <imaizumi@nisiq.net>]

<20010901202733J.ohkubo@ist.aichi-pu.ac.jp> の、
   "[WitchTech 00851] Re: ファイルアクセスとシリアル割り込みが重
なるとシステム破壊" において、
   "Hirotaka OHKUBO <ohkubo@ist.aichi-pu.ac.jp>"さんは書きました：


> あとは「使って何が起こっても知らない」なんて脅しが書いてあるバンク制御 
> BIOS を使って SRAM を触らせて頂く(この最中、Flash にあるはずの割り込み
> ルーチンのプログラムはどうやって読み込んでるの？同じ問題が ram0 扱うファ
> イルアクセス関数にもあるハズなんだけど...)か、スタックとして使われてい
> る内部RAMの領域を割り込みルーチンの作業領域にする(alloca() 使うか 
> main() の局所配列に取るとして、確保した領域のアドレスは割り込みハンド
> ラにどうやって渡すの？)という不完全なアイデアしか思いつきません。
> 

  DSが正しくない、CSが正しくないなどいろいろ仮定しながら試してみ
た結果、どうやらBANKマッピングが異なっていてアクセスしているアド
レスは正しいもののそこにあるデータは自分のものではないということ
のようです。

　ということで自分もILになったつもりで割り込み処理ルーチンで操作
する変数をバッファも含めて総てsys_alloc_iramでIRAMに取り、常に
sys_get_my_iramでその領域へのポインタを取ることで解決しました。

　ただ、この方法だとバッファがあるのでかなりIRAMを圧迫します。
#エラーをきちんと上位に伝えるためにエラーコードもバッファする
#必要上、intでバッファを取っているのがさらに拍車をかけています。

  OSが割り込みハンドラでバンクの再割り当てと復帰をするのが当然だ
と思うので次版での修正を*強く*希望します。でなければせめて最低限、
割り込みルーチンではデータ領域のマッピングが保証されないといった
注意書きの追加が必要でしょう。この考慮がないと書き込みを伴う割り
込みルーチンは総ていつシステムをふっとばすかわからない時限爆弾に
なってしまうのですから。今はたまたま動いていても変数領域がちょっ
と動いたら..ILを呼び出すようにしたら..