仮想ベクタテーブルについて

質問

私、このたび１０年ぶりにマイコンプログラム制作をすることになったので、現在必死に勉強しておりますがどうしてもわからないことがあり質問いたしました。

現在は昔と違い、プログラムの書き換えが簡単にできるようにＲＡＭ上にフラッシュのプログラムをコピーして、ＲＡＭ上でプログラムを起動するのが一般的なやり方のようですが、その際、仮想ベクタテーブルはなぜ必要なのでしょうか？

ＲＯＭの先頭アドレスからマッピングされた通常のベクタテーブルに、ＲＡＭにコピーした関数のアドレスを登録しておけばよいように思うのですが？

フラッシュの書き換え回数の問題があるからといっても、ベクタテーブルはアドレスを登録しておくだけだから、通常でしたら頻繁に書き換えなど怒らないかと思うのですが。。。？

なぜ仮想ベクタテーブルというやり方をしなくてはいけないのかよくわかりません。

どなたかわかりやすくご教授下さい。

よろしくお願いします。

回答No.7

pyonmae · ベストアンサー

こんにちは。
お話が最初に戻るわけですね。
余計なやり取りを介してしまい、申し訳ない限りです。

で、最初のご質問「なぜ仮想ベクタを使わなければならないのか？」ですが、これは最初から申し上げている通りです。
仮想ベクタを使わなければならない、なんてルールはどこにもありません。
やりやすいようにやって頂くのが一番です。

ただ、システムは、将来どんな変更があるか分かりません。
ダウンロード更新で済むものがPC持って全国行脚とかになるリスクは、極力避けたいものです。
そのため、システムにはある程度の柔軟性を持たせる事が必要かと思います。
ブートローダを書き替えないのなら、なおさら工夫が必要なんじゃないのかなぁ、と感じるのですが、詳しくは分からないので何とも言えません。
質問者様が検討した結果、仮想ベクタなんぞ要らん！と判断すれば、そうして一向に構わないと思います。

ご検討下さいませ。

お礼

お付き合いありがとうございました。
この辺にしておきます。

回答No.6

pyonmae

おはようございます。
何度も何度もすみません。
どうも私はカン違いをしていたようです。
おっしゃりたい事がやっと分かりました。
「デバッグ」とはどこにも書いていませんでしたね。
申し訳ありませんでした。

プログラムのダウンロード時、ブートローダもろともFlashを全域書き換えるのでしょうか。
それだったら、仮想ベクタを用いる必要は別に無いと思いますが、書き換えが何らかの要因で失敗した場合、取り返しのつかない事になりますね。。。
数台～数十台とかだったらまだマシですが、数百～数千台作られるとかなると、かなりなリスクになると思います。
ブートローダは保護して、アプリは別ブロックに焼くというのが、まぁ「一般的」じゃないですかねぇ。。。
ご検討（健闘）下さいませ～。

お礼

何度もご回答いただきありがとうございます。

ダウンローダにて書き換えるフラッシュは４領域のうちアプリ用の２つのエリアのみです。

ブートローダとダウンローダ領域は書き換えません。

回答No.5

pyonmae

こんにちは。
何度もすみません。えらくはありませんが・・・。
何となくですが、お聞きになりたい事が分かってきた気がします。
まず、H8Sというのは、かなりチープなプロセッサでありまして、「仮想なんとか」というものとは基本的に無縁です。
仮想っぽく動作させるには、それなりのモジュールをシコシコと作っていく必要があります。
質問者様が使用するハードウェアの仕様が分からないのですが、内蔵Flashと内蔵RAMのみを使用しての開発と勝手に推測させていただきます。

まず、H8Sはベクタテーブルが固定で、どこにも動きません。リセットベクタが0番地固定であるため、どの道Flashの先頭エリアには何らかのベクタテーブルを書き込む必要があります。
つまり、「RAM起動」という概念そのものがありません。
あくまでも、プログラムはFlashからのスタートとなります。
その上で、「なんちゃって仮想ベクタ」を実現する場合、色々方法はあるかもしれませんが、一番単純な方法としては、中継的役割をする割り込みハンドラを作成し、それをRAM上に配置し、割り込みベクタにはそのハンドラのアドレスを並る、というものになりましょうか。
もちろん、その中継ハンドラは、アドレスがずれないように配慮しておく必要があります。
そして、その「仮想ベクタ」を含めたデバッグ対象のプログラムを、何らかの方法でRAMに流し込み、そこへジャンプする仕掛けが必要です。

しかし、よしんばそこまで出来たとしても、ブレークポイントやらステップ実行といった人並なデバッグを行うのは、相当困難なのではないでしょうか（GDBを使うとかしないと）。

さて、それで結論ですが、繰り返しになりますが、H8Sを使う場合、ROMもRAMもどちらも「一般的」ではありません。
一般的と言うなら、やはりJTAGではないでしょうか。
私なりの、方法別所見を述べてみます。

・JTAG
　一番無難
　デバッガを購入する必要がある。
　ハードウェアリソースは、ほとんど犠牲にならない。
　一通りのデバッグ作業（ソースレベル、ブレーク、ステップ等）が簡単に行える。
　何かと言うとFlashに書き込みが発生するので、出荷するものとは別に、デバッグ用のハードを準備するのが無難。

・RAMデバッグ
　デバッグを開始できるまでの準備が大変。スキルが必要。
　何らかのコミュニケーションポート（多分シリアル）がつぶれる。
　一旦準備ができれば、以降は快適。ツールによっては、ソースレベルデバッグも可能。
　Flashの書き込み回数が、とても少なくて済む。
　実使用時と、動作が若干異なる（#3さんのご指摘内容）

・ROMデバッグ
　お金もかからないし、動作上の犠牲もほぼ無い。
　Flashは盛大に消耗する。
　ウンともスンとも動かない場合の絶望感が異常。

お礼

度々、回答いただきどうもありがとうございます。
仕事の都合上あまり詳細をかけないのですが、システムの起動はFlashからです。起動時に特定のポートを監視し、アプリケーションを起動するか、ダウンローダーを起動するか選択します。

アプリ起動時は、フラッシュのアプリケーションを外部ＳＲＡＭにコピーしてＲＡＭ上で起動する。
ダウンローダー選択時は、シリアルにてプログラムを外部ＳＲＡＭに蓄積後、フラッシュのアプリを書き換える。

といったものです。上記は仕様であるため変更はできません。

デバッグ環境はＪＴＡＧが使えます。

私が一番よくわからないのは、アプリケーションを外部ＳＲＡＭにコピーしてＲＡＭ上で起動する際に、仮想ベクタ方式を用いなくてはいけないかという点です。

回答No.4

ralf124c

H8Sについては門外漢なので具体的な手法はわかりませんが・・
> 通常、プログラムをRAMにおいて起動する場合はベクタテーブルもＲＡＭに持つというのが一般的な方法なのでしょうか？
昔の話で申し訳ございません。
PC-XTやAT、日本ならAXなんかのころは、メモリマップもシンプルでBIOSルーチンなどを含むROMの内容はそのまま使用されていたと記憶しています。　CPUが386以降、特に486が主流になるころはROMの内容をRAMに複製して扱うようになったというのをなにかの文献で読んだ記憶があります。　その理由として、「速度の問題」と「ROMだと不可能なBIOSルーチンへの都合よく動作させるためのパッチあて」と記憶しています。
　ただし、ベクターテーブルについては、RAMのエリアの特定場所にBIOSプログラムが初期テーブルを生成してOSが起動時に追加分を設定するような仕組みだったようにおぼえています。

> わたしは今までＲＯＭライタでＲＯＭに焼いて動かすプログラムしかやったことがないものですから、ＲＡＭ起動時はどのようにしたら良いのか？どうもピンときません。
くだんのCPUは仮想メモリとかマッピングというのは扱えないでしょうか？
ROMの起動プログラム内にROMの内容をRAMにコピーしてROMの実アドレスエリアをまるごと仮想RAMでマッピングするというプログラムを組む方法かと思います。

が、実際にやったことはないので経験者の回答を待った方が良いと思います。
えらい人へ、
　間違いがあったら訂正お願いします

お礼

回答ありがとうございました。
参考にさせていただきます。

回答No.3

ralf124c

横からすいません。
読み込み速度の違いからじゃないでしょうか？
割り込みが頻繁に発生するようなシステムだとベクターテーブルの読み込み待ち時間がROMではばかにならなくなってくるんじゃないでしょうか。

お礼

回答いただきありがとうございます。

通常、プログラムをRAMにおいて起動する場合はベクタテーブルもＲＡＭに持つというのが一般的な方法なのでしょうか？

わたしは今までＲＯＭライタでＲＯＭに焼いて動かすプログラムしかやったことがないものですから、ＲＡＭ起動時はどのようにしたら良いのか？どうもピンときません。

回答No.2

pyonmae

こんにちは。
たびたびすみません。

ROMベクタ方式に対する、仮想ベクタ方式のメリットは、Flash焼きこみ回数云々というより、もっと広い意味で、「やらなくてもいい、無用な手間が省ける」ですかねぇ。。。
逆に言うと、ROMベクタだと、やらなくてもいい、無用な手間が発生すると思うんですが。
繰り返しになりますが、どうしてそんなに使いたくないのかが分からないです。
理由はないんですか。そうなんですか・・・？

しかしながら、プロセッサがH8Sとなると、事情がちょっと変わってきますね。
どっちかというとJTAGデバッグが一般的なような。
デバッガが準備できるなら、素直にそっちにすれば、仮想がどうとかいう問題も含めて色々解決しますが、どうでしょう。
でも、少々カネがかかってくるし、それこそFlash書き込み回数がハネ上がるので、避けたくなる気持ちも、分かります。
そうなると、H8Sで仮想ベクタは準備が少々面倒くさいので、場合によっては質問者さんの方式（ROMベクタ）がベストかも知れません。
色々検討してみてください。

お礼

参考になりました。
どうもありがとうございました。

回答No.1

pyonmae

こんにちは。
ご質問とは、ちょっとズレた回答ですが。
『仮想ベクタテーブルというやり方をしなくてはいけない』
とは、どなたが言われたのでしょうか？
どんなプロセッサを使われるのか分からないですが、プロセッサの仕様でそういう決め事になっているとかでもないのなら、質問者様のやりやすい方法で進めて頂くのがよろしいのではないでしょうか。

ここからは個人的興味なのですが、逆に、そんなに仮想ナンチャラを使いたくない理由は、何でしょうか。
使わないメリットが思い浮かばないのですが。。。
使えばフラッシュ書き換えの手間そのものがなくなるし、そうするとフラッシュ書き換え回数の心配とか最初から存在しなくなるし、どの道DebugビルドとReleaseビルドを分けるんだから、かかる手間も大して変わらない気もするんですが。。。
・使いたくない理由
・それでも使わなければならない理由
参考までに教えて頂けると、幸いです。

あと、『ＲＡＭ上にフラッシュのプログラムをコピーして、ＲＡＭ上でプログラムを起動する』って、一般的なんですかねぇ。。。

お礼

pyonmaeさん、さっそくの回答どうもありがとうございます。

ちなみに開発するCPUはH8Sです。
「ＲＡＭ上にフラッシュのプログラムをコピーして、ＲＡＭ上でプログラムを起動する」というのは
与えられた仕様なので変更できません。

私はＲＯＭライターでやいて動かす昔ながらのやり方しかやったことがないものですから、今回わからなくて質問いたしました。

仮想ベクタを使う理由、使いたくない理由とかは特にありません。
ネットで私なりにいろいろ調べて、仮想ベクタを使わなくてはいけないのかな？と思った次第です。
従来のベクタテーブルに、関数を登録するやりかたでも構わないのですね。。？

仮想ベクタを使用する利点は、フラッシュの書き込み回数削減のみが目的だということでしょうか？