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

現在CS+でRX63Nでソフトを作成しております

なにぶんRAMが128K Byteのようで、これをまだまだ先になりそうですが

SDカードやLANやUSBからファームを転送してRAM上で動作させるといいんじゃないかと

その場合ROMは大容量なのでC言語ライブラリーモージュルだけをROMにもたせることができれば

いいのじゃないかと素人考えで、そんなことは可能なんでしょうか?

Parents
  • わわいです
    これができたらいい、と思うならいっぺんやってみよう。
    で、その実現方法が自分で思いつけないなら、それが実行できるようになるまで経験を積もう、としかいいようがないですねー
    他人におんぶでだっこでその方法を聞いたところで、実際に実行できるわけもない、とおもったりなんかします

    がんばって実現しましょう。そしてそれを公開してくださればみんながハッピーに。

    #まあ、、、、だれしもが通る道だったりするんですが
  • わわいさん
    やっぱりそれが出来ると、少しは便利になるかもですね、現状ですがとりあえずSCI2が送信/受信がうまく行っているのでUSBにかかろうかと思いましたが、わわいさんの応答でそうだなー、それならSCIの受信がDMACで高速だしSCIでやれるようにしようかな!そうすれば複雑なUSBやLANを組み込むのが容易になるんじゃないかな、ということで次USBやろうと思っていましたが、USB無しのマイコンにも対応できるしSCIを使用してファーム転送できるように開発順序を変えたいと思います(初心者ですからいつできるかわかりません)、とりあえずプロジェクトビルドの種類は1つ追加しました。
  • みな同じようなことを考えているみたいで、このカフェルネで「RXマイコン(GR-SAKURA)のデバッグ時プログラムをRAM上にダウンロードしたい(フラッシュの劣化を防ぎたい)」に同じような内容がありましたので参考にさせていただきます。
  • フラッシュの寿命が長いとかでしたね、ただ今はデップスイッチの切り替えが面倒のと書き込み速度が遅いのが難点と思います、とりあえず割り込みベクタをRAMに配置すべく、セクションの設定をしなければ、CS+RXのRX63Nセクションの説明書というのはコンパイラの説明書を見ればいいのでしょうか?どうやってセクションを設定するのでしょうか?
  • これやっぱりUSBが先に出来るようにいたします、なぜかというと、DMACの転送はByte転送に設定しているためににブロック転送するにはモードを変更しないといけないためです、そうすると遅くなってしまいます、SCIはターミナル用にして転送をUSBすればたぶん良いのではないかと、セクションを変更するダイヤログはすぐに見つかりました、セクションが多くあるのでこれも理解しないといけません。
  • フラッシュの書き換え回数が気になるならば 1日当たりの書き換え回数を概算で求めて製品仕様での書き換え回数をそれで割り、マージンを加味した期間でマイコンボードを定期的に交換すれば良いだけで、実験装置の予算のない学生とかでもない限りはコードをRAM上に置いてデバグとか考えるだけで無駄でしょう。
  • fujita nozomuさん
    そうですよねー、ほんまに無駄とおもうのですが、当方まれにみる偏屈者でして、人がやらんことをしたいと思ってまして、そんな人間につきあっていただければ本当にありがたいです、実用というか勉強ですね、普通セクションなんかいじらないですが、これが理解できるとちょっと偉くなったような気がして、素人の遊びです、でも将来SDRAMを接続したりしてDOSを入れたりすると、昔のパソコンですね、昔のPC-9800で100MHzの最新型パソコン50万出して私買いました、あの頃のPCとRX63N同じぐらいなんですね。
  • >フラッシュの書き換え回数が気になるならば 1日当たりの書き換え回数を概算で求めて・・・
    >・・・コードをRAM上に置いてデバグとか考えるだけで無駄でしょう。

     完成した関数をROMに書き開発中の部分をRAMに設定すれば、RAMの部分だけコンパイルや書き込みをすれば良いので時間を短縮できると考えています。
Reply
  • >フラッシュの書き換え回数が気になるならば 1日当たりの書き換え回数を概算で求めて・・・
    >・・・コードをRAM上に置いてデバグとか考えるだけで無駄でしょう。

     完成した関数をROMに書き開発中の部分をRAMに設定すれば、RAMの部分だけコンパイルや書き込みをすれば良いので時間を短縮できると考えています。
Children
  • > RAMの部分だけコンパイルや書き込みをすれば良いので時間を短縮できると考えています。

    どの程度短縮できるという試算ですか?
  • わわいです
    むかしのはなしですが、内蔵フラッシュの書き込み回数が100回ってデバイスがあって、外部RAMを増設してデバッグしてた、ということがありますねー
    もちっとむかしだと、ワンタイムROM(一度書き込むと消去できないROM)のヤツもあって、RAMを増設、ができなかったので、しようがないのでチップを100個ぐらい用意して使い捨てでデバッグ、とかやってましたねー
  • リカルドさん
    「RAMの部分だけコンパイルや書き込みをすれば良いので時間を短縮」賛成ですね。
  • わわいさん
    「チップを100個ぐらい用意して使い捨て」昔はお金がかかりましたよねー。
  • >どの程度短縮できるという試算ですか?
     
     試算した訳では無いけれど、原理的にそうなるだろうと言う話です。
     ROMだと消去したりベリファイしたり時間が掛かるんじゃないんですか。
     大きなプログラムの場合、1行だけの訂正で全体を書き換えるのはもったいない。
     
     HEWと連携しているMISRA-Cと言うC言語のチェックソフトを使った事が有るのですが、小さなプログラムでも時間が掛かりました。
     中規模のプログラムだったら、かなり待たされるんじゃないかと思いました。
  • > 試算した訳では無いけれど、原理的にそうなるだろうと言う話です。

    損得勘定をした上で、得である試算ができた前提でなければ意味のない行為では? >ライブラリーモージュルだけをROM
  • fujita nozomuさん
    「意味のない行為では? >ライブラリーモージュルだけをROM」そうですね、通常は使用する(必要とする)ことは無いと思います、現状マイコンシステムでは一つのモジュールプログラムとして動作が完結していれば良いので、そのような大規模なソフトが必要かというところですね、将来的な人工知能とかいうような莫大なライブラリーが必要になるようなプロセスでその都度膨大なライブラリーを埋め込むよりもライブラリーのみ独立させてメモリ空間に記憶させておき、それを呼び出して使用するならロード時間も短くなるだろうという発想です、現にWindows等ではそれを採用していてWindowsのプログラマーとしては、将来マイコン分野でも自動車等では大規模化が進んでいまして、いずれそのようになるのではと予想するのでございます。(linuxがあるじゃないか!と怒られそうですね)

  • fujita nozomuさん
    とはいっても、小さいマイコン?それなりに必要なので、全てが大規模化するということではないですが、いろいろなマイコンがあってそれぞれの長所を使用することであると思いますが、C言語ライブラリーが埋め込まれているようなマイコンができないかな、でも制御系にはC言語ライブラリーいるの?ということですか。
  • > 「意味のない行為では? >ライブラリーモージュルだけをROM」そうですね、通常は使用する(必要とする)ことは無いと思います

    前提条件を端折って曲解するのはやめて下さい。

  • わわいです
    >いずれそのようになるのではと予想するのでございます。
    なら実際にやってみましょう。
    それをやってみれば、実現可能か不可能か、その労力に見合った結果が出るのか、ってのがわかってきます。
    机上の空論でぐだぐだやっててもどうしようもありませんぜ。

    #まーやってみて、これはダメだ、と思ってしまうのも勉強というもんで。