続、続、avr-gccの制約

ａｖｒ－ｇｃｃで３２ＫＢを超える定数配列を
作ってｆｌａｓｈに配置しようとすると
コンパイルエラーになっちゃうという件。

定数定義を分割してからコンパイルしなおして
みました。こんな感じ。
（半角不等号は全角に置き換えてあります）

#include ＜avr/pgmspace.h＞

const char misaki_char1[][8] PROGMEM = {
{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00},
（中略）
{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}
};
const char misaki_char2[][8] PROGMEM = {
{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00},
（中略）
{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}
};
const char misaki_char3[][8] PROGMEM = {
{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00},
（中略）
{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}
};

こんな風に適当に３分割してみたところ、
コンパイルはすんなり通り、出来上がった実行
ファイルのサイズも約６３ＫＢと想定どおり。

実際に各配列へのアクセスは行ってませんが、
この時点でコンパイルが通っている以上
特に難しいことにはならないでしょう。

ただ、３つの領域に分割してあり、かつ
構造体とかで１つに纏めるとまたエラーが
でちゃうはずなので、ロジック上で１個の
データとして見せかけるしかありません。

関数の添え字に相当する数値を受け取って、
それに相当するビットマップデータを返す
という関数でも組めば良さそうです。
関数内で３つのうちどの配列から取り出せば
良いか判断させるという感じ。

うん、まぁこれで理論上は好きなようにアクセス
出来ることになったわけだけど…
関数コールのオーバーヘッドが生じるってことは
処理速度上マイナスだな。

Ｃ言語だけで漢字テキストのビデオ表示、みたいな
ことやろうとすると、このオーバーヘッドは
ちょっと無視できないレベルかも…

ＶＲＡＭを「グラフィックＶＲＡＭ」とするなら
あまり問題は無いんだけど、「テキストＶＲＡＭ」
上のデータを逐次デコードしながら表示する
場合には配列へのアクセスが頻繁すぎて
デコードが間に合わなくなるのは目に見えてる…


ＬＣＤ表示の場合なら、ＬＣＤ側にＶＲＡＭを
保有してるだろうから、グラフィックＶＲＡＭ
だろうがテキストＶＲＡＭだろうが関係ないけどね。

まぁいずれにしても、ＡＶＲならアセンブラでも
Ｃでも美咲フォントのデータをプログラムｆｌａｓｈ
上に配置することが出来る目処がついたな。

あとでサイトに纏めておきたいと思います。