SOLID未分類 SOLIDで安全なリアルタイムシステムを開発する
唐突ですが、MMUってご存じでしょうか？
論理アドレスを物理アドレスに変換する、アレです。
使用例を挙げるならば、Linux。複数プロセスが同時に動作するマルチプロセスです。
同時、と言っても、ある瞬間で見るとどれか一つのプロセスが動いているわけですが、次の瞬間には違うプロセスに切り替え、きちんと動きます。
それぞれプロセスは、
・実行プログラム本体があるメモリ空間
・データ保管空間
・スタック
など、必要なメモリ空間があります。
マルチプロセスシステムにおいて、各プロセスが個々にメモリ空間を持ってしまっていたら、プロセスを管理する側は大変です。
同時で動く全プロセス分、重ならならいメモリ空間に割り当てないといけないので、それぞれのプロセスのアドレスにオフセットがそれぞれ付くことになります。
（方法は色々あるかと思います。あくまでも一例です。）
同時に動けるプロセスの数が少なければ、これもいいかもしれません。
ですが、Linuxのようなある意味完全体のマルチプロセスシステムでは、そうはいきません。
いくつプロセスが同時に実行するかなんて、カーネルはわかりません。
そこでMMUです。
「プロセスの空間」を論理アドレス（CPUが理解するアドレス）でココ！と定義し、みんなプロセスはそこで動くことにします。
その論理アドレスに対する物理アドレス（メモリに実際に格納されている場所）は、ＭＭＵが把握します。
プロセスごとに、同じ論理アドレスで違う物理アドレスが紐づけられるわけです。
どのプロセスがどの物理アドレスにいらっしゃるのか、を整理整頓しているのが、MMUのテーブルです。
このように、Linux等、ある意味完全体のマルチプロセスシステムの場合、MMUはなくてはならない重要な存在です。
CPUは論理アドレスで、ホイッとメモリアクセスすればよく、実際にその論理アドレスに対応した物理アドレスに変換するのはMMUで、変換先のメモリはバス経由でアクセスされます
ただし、プロセス入れ替えの際にそれなりの遅延は発生します。
（MMUテーブルを切り替えたり、その時に多分キャッシュが総入れ替えになったり。。。）
では、uITRONの場合はどうでしょうか。
uITRONが期待されているのは厳密なリアルタイム性です。
uITRONもマルチスレッドで動作させる場合、ある程度コンテキストスイッチは発生します。（それさえも許容できない場合、マルチスレッドにしないことも可能）
ですが、MMUを使って大規模なマルチプロセスシステムを採用し、プロセスの入れ替えをきっちりとやり切る事は、リアルタイム性重視の観点からはちょっと難しいです。
じゃ、uITRONでは全然MMU使わない？
いえ、Cortex-Aの場合、キャッシュを使おうとするとMMUを有効しないといけない、とう消極的な理由で、MMUは使用されていたりします。
しかしこの場合、
「論理アドレス＝物理アドレス」
で、実質MMUはスルーされています。
ちなみに他のCPUでは、キャッシュとMMUが完全分離されているものもあり、こういうCPUでは「キャッシュだけON」という場合もあります。
しかし！
MMUには、変換テーブルに属性を持たせることができたり、例外を発生したりすることができます。
「キャッシュ使いたいから、仕方ないからMMUをONにしなきゃ。」
だけだと、勿体ない！
組み込みのデバッグあるある：
「数時間に一度の頻度で、謎のリセット発生。」
疑うべくは、メモリ破壊、不正アドレスアクセス、多重割り込み発生、、、
いろいろ考えられますが、メモリ破壊、不正アドレスアクセスの要因の筆頭候補には以下２点があります。
・NULLポインタアクセス
・スタックオーバーフロー
実はどちらも従来もハードウェアブレークで引っ掛けるという形で実現できます。
ハードウェアブレークを「アクセス対象番地へのリードライトアクセス発生」で仕掛けておくと、メモリアクセス発生直前にブレーク発生します。
ちょっと試してみましょう。
ハードウェアブレークを使ってみます。
とりあえず、ハードウェアブレークでメモリアクセス起因のブレークが発生することを確かめてみます。なので、アドレスは適当な内蔵I/Oレジスタの値にしてみました。
プログラムではデータライトをしていますので、書き込んでも大丈夫そうな、SPIのFIFOレジスタをアクセス先としてみました。
逆アセンブルウインドウと、レジスタウインドウから、対象メモリへのライト直前でブレークしていることがわかります。
同じように、アクセス対象アドレスを０番地としてハードウェアブレークを設定すれば、０番地への不正アクセス、すなわちNULLポインタアクセスを捕まえることができます。
ですが、ハードウェアブレーク機能は便利なので、他にも使いたくて、チャンネルを開けておきたいんですよね。
内蔵I/Oへのアクセスを引っ掛けたりしたいし、ブレークポイントが設定できないようなデバッグで使いたいし、、、
SOLID IDEでは、これらの検出にMMUを使っています。
まぁ、ちょっとやってみましょう！
先程のプログラムで、*pのアドレスを０番地に変更し、実行してみます。
特にブレークポイント、ハードウェアブレークは設定しません。
*pへのライトアクセスでプログラムが自動で停止し、Data Abort Exceptionが発生しました。
デバッグ例外ウインドウに表示されています。
これ、MMUを使用して実現されています。
[仕組み]
０番地付近は、プログラムによって使用されない領域です。したがって、MMUのアドレス変換テーブルに、論理アドレス０番地付近は登録されていません。
実際に０番地にアクセスがあった際、MMUにより対応する物理アドレスに変換すべきですが、そんな論理アドレスは変換テーブルに載っていないため、物理アドレスに変換ができず、データアボートが発生している、という仕組みです。
これは、論理アドレス＝物理アドレスとしてとりあえずMMUをオンにしている、という状態であれば発生しないデータアボートです。
プログラムで使用するアドレスを把握し、関係のないアドレスは変換テーブルに登録してはいない、というひと手間があるおかげです。
次は、スタックをオーバーフローさせてみます。
再起関数を永遠に呼び出すプログラムを書けば、簡単にスタックはオーバーフローしますね。（こういうのは得意ですよ。）
Data Abort may have been caused by stack overflow
というデバッグ例外が発生し、プログラムが停止しました。
[仕組み]
スタック領域と隣り合っている領域を、MMUによるアドレス変換テーブルに載せない。
そうすることにより、スタックの範囲から出てしまったとたんに「アドレス変換ができない」という例外が発生する。