Ｃ言語ライブラリーモージュルだけをROMにするのは可能でしょうか？

みな同じようなことを考えているみたいで、このカフェルネで「RXマイコン(GR-SAKURA)のデバッグ時プログラムをRAM上にダウンロードしたい(フラッシュの劣化を防ぎたい)」に同じような内容がありましたので参考にさせていただきます。

フラッシュの寿命が長いとかでしたね、ただ今はデップスイッチの切り替えが面倒のと書き込み速度が遅いのが難点と思います、とりあえず割り込みベクタをRAMに配置すべく、セクションの設定をしなければ、CS+RXのRX63Nセクションの説明書というのはコンパイラの説明書を見ればいいのでしょうか？どうやってセクションを設定するのでしょうか？

これやっぱりＵＳＢが先に出来るようにいたします、なぜかというと、DMACの転送はByte転送に設定しているためににブロック転送するにはモードを変更しないといけないためです、そうすると遅くなってしまいます、SCIはターミナル用にして転送をＵＳＢすればたぶん良いのではないかと、セクションを変更するダイヤログはすぐに見つかりました、セクションが多くあるのでこれも理解しないといけません。

フラッシュの書き換え回数が気になるならば 1日当たりの書き換え回数を概算で求めて製品仕様での書き換え回数をそれで割り、マージンを加味した期間でマイコンボードを定期的に交換すれば良いだけで、実験装置の予算のない学生とかでもない限りはコードをRAM上に置いてデバグとか考えるだけで無駄でしょう。

fujita nozomuさん
そうですよねー、ほんまに無駄とおもうのですが、当方まれにみる偏屈者でして、人がやらんことをしたいと思ってまして、そんな人間につきあっていただければ本当にありがたいです、実用というか勉強ですね、普通セクションなんかいじらないですが、これが理解できるとちょっと偉くなったような気がして、素人の遊びです、でも将来SDRAMを接続したりしてDOSを入れたりすると、昔のパソコンですね、昔のPC-9800で100MHzの最新型パソコン50万出して私買いました、あの頃のPCとRX63N同じぐらいなんですね。

わわいです
まー、ビルドコンフィグレーション（DebugとかReleaseとかですな）をRAMデバッグ用（RAM_Debug とかなんとか）に新しく作って、すべてのアドレス割当をRAM上にしてしまうというのはよくやりますねー
まあ、RAM容量が潤沢にないと使えない手ですが

で、DMAを使うとかいうはなしですが、いまどきでは内蔵RAMのアクセスについては、DMAが圧倒的に遅くなります（というより、内蔵RAMのアクセスがクソ早い）。また、内蔵RAMを相手にする場合はその心配はないですが、DMAではキャッシュが使えないためキャッシュ無効のエリアでしか相手にできないってこともあったりします。

ということで、そこらへんのワケがわかってないうちは、DMAはやめといたほうがいいとは思いますです

わわいさん
DMAですよね、これあんまり信頼してもいけませんよね、前に割り込みでケアした時に高ボーレートの機器が接続されて取れなかったことがありましてDMACにしました、DMACも使わなかったらもったいないの精神です、「キャッシュ無効のエリアでしか相手にできない」SHではそうでした、RXはこれもキャッシュがあるのでしょうか？シリアルでDMACは意外と便利です、リピートモードで使用するとポインタの管理がいりません、自動でリングバッファを構成してくれます、SCI2はサンプルもありましたし、簡単に実現できました、評価ボードの回路図が違ってたようで信号が出るまでえらい時間がかかりました、あれからコマンドラインとタスクモジュールも追加して快適です、先ほどＵＳＢペリファイ？のサンプルをダウンロードしましたから、明日からＵＳＢに取り組みます、またいろいろ教えてください。

RX63N で RAM 上でコードを実行した場合、ROM と比べてどの程度の効率で実行できるのか具体的な説明が『RX63N グループ、RX631 グループ ユーザーズマニュアル ハードウェア編』で見つけられなかったので、RX63N を搭載している GR-SAKURA で下記のコードを試してみましたが

gr_sketch.cpp:

/* GR-SAKURA Sketch Template V2.13 */
#include 

void tarai(int, int, int);
byte ramtarai[0x100];

void setup()
{
    Serial.begin(9600);
    memcpy(ramtarai, (const void*)tarai, sizeof(ramtarai));
}

void loop()
{
    unsigned long start;

    start = millis();
    tarai(12, 6, 0);
    unsigned long romtime = millis() - start;

    start = millis();
    ((void(*)(int, int, int))ramtarai)(12, 6, 0);
    unsigned long ramtime = millis() - start;

    Serial.print("ROM: ");
    Serial.print(romtime);
    Serial.print(", RAM: ");
    Serial.print(ramtime);
    Serial.println();
}

tarai.cpp:

int tarai(int x, int y, int z)
{
    return (x > y) ? tarai(tarai(x - 1, y, z), tarai(y - 1, z, x), tarai(z - 1, x, y)) : y;
}

実行結果:

ROM: 5019, RAM: 5513
ROM: 5019, RAM: 5514
ROM: 5018, RAM: 5514
ROM: 5018, RAM: 5514
ROM: 5018, RAM: 5514
ROM: 5018, RAM: 5515
ROM: 5018, RAM: 5514
ROM: 5018, RAM: 5514
ROM: 5018, RAM: 5514
ROM: 5019, RAM: 5513

ROM と比べて RAM 上のコードでは 1割程度の性能低下が見られました。

想像してたほどの性能低下はないなというのと、それでも RAM の方が性能が落ちてるのは命令キューの関係だろうか? という感じですが、正直よくわかりません。

fujita nozomuさん
実際にやってみられましたか、ROM と比べて RAM 上のコードでは 1割程度の性能低下、これは内蔵ＲＡＭでですよね、これが外部ＲＡＭやＳＤＲＡＭになるともっと遅くなるのではないでしょうか、内蔵ＲＡＭですとノーウェイトでやって もＲＯＭと比較して1割程度の性能低下であるとすれば、ビット幅も両方３２ビットですし、ＲＯＭキャツシュが陰にあるのかも、リリース品はＲＯＭで出荷するのが理想的ですよね、ただ昨今バグ発覚で現地に赴いてノートパソコン接続して書き変えなんて数が多いとやってられませんから、インターネットに接続されていれば、ファイルシステムで動作していれば、ファイルをおきかえるだけでいいので、最近ルネサスさんもイーサーネット経由でＲＯＭをプログラムできるようなサンプルも用意されているようで、ここまで便利になったところで、これからはハッカーに壊されないようにセキリュテイ向上の努力でしょうか。

> ROM と比べて RAM 上のコードでは 1割程度の性能低下、これは内蔵ＲＡＭでですよね

内蔵RAMですが、頻繁な関数呼び出しを行っており、一般的なコードではこれ程の性能低下はないと思います。

void wait(void)
{
    for (volatile unsigned long i = 0; i < 10000000UL; i++) {
        ;
    }
}

↑ のような関数呼び出しを行わない単純な時間待ちであれば ROM と 内蔵 RAM とで実行時間の差はほゞありませんでした。

> 内蔵ＲＡＭですとノーウェイトでやって もＲＯＭと比較して1割程度の性能低下であるとすれば、ビット幅も両方３２ビットですし、ＲＯＭキャツシュが陰にあるのかも

キャッシュではありませんが RX63N には「8バイト ×4本の命令キュー」という仕組みがあり、ROM からの命令の命令読み出しの効率化を図っているようです。

> これが外部ＲＡＭやＳＤＲＡＭになるともっと遅くなるのではないでしょうか

RX63N の命令キューは 8バイトを単位として ROM を読み出す仕組みのようですが、それに対して外部バスや SDRAM はバス幅は最大でも 32bit であり、効率の良いものではないでしょう。