100点とれるかな？

http://minna.cert.yahoo.co.jp/lpva/9604

のび太が１００点取った時の問題だそうです。

オイラは暗算苦手なので紙とペンでやりました。
４年生ののび太くんには負けなかったようです。
とりあえずよかった…。

問題自体はヒネリは無いので、分数計算を
忘れてなければ何のことはないんですが…


マイコンの検定って言うのはないんだなぁ…。

続、続、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}
};

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

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

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

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

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

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

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


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

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

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

続、avr-gccの制約

ａｖｒ－ｇｃｃの配列サイズの制約についてさらに
調べてみたら、↓ここに
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=58517

纏めが書いてありました。曰く…

＞Unfortunately, Dean, *both* limitations are valid in avr-gcc:
＞1) An array index is a signed 16-bit integer, thus array indexes cannot be computed outside the range [-32768, +32767], and
＞2) No single object can have a byte count greater than 32767 bytes.

＞If you chop the array in half and place both halves into a struct, then the struct itself would be an object whose size is greater than 32768 bytes, and thus the compiler would generate the exact same error.

簡単に纏めると、配列の添え字は１６ビット幅の
signed intなので最大でも32767までしか使えないし、
一つのオブジェクトのサイズがそもそも32767バイト
より大きく出来ない、という２つの制約があるという
ことのようです。


なので、2つの配列に分割する場合にそれらを
連続したメモリに配置するために1つの構造体に
纏めようとすると、結局合体した2つの配列の
合計が32767バイトを超えちゃうので、
それはそれでダメと言うことみたいです。

今回のオイラのケースだと、添え字のほうは
制約に引っかかってないはずだけど、バイト数は
６３ＫＢほどあるから最低でも二分割する必要は
ありそうだな…

ａｖｒ－ｇｃｃは、扱うＣＰＵがＡＶＲって
限定してるから、あまり大きな配列を扱う
前提にはなってないんだね…


で、ぼやいても仕方ないので現実解を考えてみる…


まず配列を2つに割ってみる…それぞれの配列は
２つの制約に引っかからないのでＯＫなはず。

ただし連続領域には配置されないので、配列の
添え字として参照するのではなく、関数の
引数として位置を引き渡すと、その関数が
どちらかの配列から値を参照して返す。

みたいな感じにすれば上手く行くかな？
あとでちょっと試してみよう。

出来れば意味のあるところで二分割したいところ
だけど、まぁ、拘る部分ではないから適当に
制約に引っかからない位置で分割すればいいのかな？

もちろん、ａｖｒ－ｇｃｃに関する制約だから、
他の言語系ならこのままでも上手く動くかも
しれないな。


むしろ、Ｉ２Ｃのｅｅｐｒｏｍに押し込んじゃう
のが一番ラクチンなのかもね。

avr-gccの制約

ａｖｒ－ｇｃｃで大きいサイズの配列を作ったら
コンパイラがエラーを吐き出した件、ちょっと
調べてみました。

ａｖｒ－ｆｒｅａｋｓにそれっぽいものが。
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=80105&postdays=0&postorder=asc

やっぱり３２ＫＢを超えるとエラーになるみたい。

幾つか解決方法を話し合われているみたいなんだ
けど、配列を分割するとか、バイナリデータを
リンカでリンクする時に取り込むとか、外付けの
ｅｅｐｒｏｍを使うとか、そんなところみたい。
決定打は見当たらないな…

うーん。

続：美咲フォント

昨日に続き、美咲フォントを利用する作戦です。

昨日はｐｎｇ画像をｂｍｐ画像にしたモノを、
ＨＳＰを使ってａｖｒ用アセンブラのソース形式
にするところまでやりました。

で、実際にＡＶＲｓｔｕｄｉｏ上でｍｅｇａ１２８
用にアセンブルしてみたら…上手く行きました。
まぁ、容量さえ足りるなら特に難しいところは
ないでしょう…


次。インテルｈｅｘ形式用のＨＳＰスクリプトも
書いてみました。昨日のを流用してチョイチョイと。

で、吐き出したｈｅｘファイルを秋月のｅｅｐｒｏｍ
ライター用ソフト（ＰＩＣライターに付属のソフト）
で読み込んでみたところ、エラーも無く上手く読み
込めました。
容量としては６０ＫＢを超えているので５１２ｋビット
タイプ（６４ＫＢ）以上のｅｅｐｒｏｍじゃないと
入りきりません。

買い置きのｅｅｐｒｏｍを漁ったら、約１０個全部が
２５６ｋビット（３２ＫＢ）タイプだったので、
書き込み確認は出来ませんでしたが…

そうそう、秋月とかで売っているSG12864Aのような
ＬＣＤの場合、ビット列が横じゃなく縦方向で
用意しないといけないので、そういう用途の場合は
ハードにあわせてスクリプトを直す必要が
あるかもしれません。

まぁ、直すのはチョイチョイだから後回し。


次。Ｃ言語ソース形式にもしてみたいな。
ＡＶＲであればＷＩＮ－ＡＶＲ（ＡＶＲ－ｇｃｃ）
で使えるようにしたいところ。

以前デカイデータをプログラム領域（.cseg）に
押し込んでｇｃｃのプログラム組もうとした時に
散々トラブった記憶があるので、ちょっといやな
予感ですが…

とりあえず方針的にはchar型の２次配列にして、
１バイト単位でメモリ上に配置されるように
考えてみます。

で、スクリプトはすぐに出来ました。

実行して、出来たＣソースをＡＶＲｓｔｕｄｉｏ
のＣプログラム中に取り込んでコンパイル…。

でかすぎるというエラー。あ、.dsegに配置しようと
してるな。間違えた。入る訳無い。ＳＲＡＭは
４ＫＢしかありませんからね。
あらためて.cseg上に配置するようにソースを修正…。

またしてもでかすぎるというエラー。うーん、
今回は間違えは無いはずなんだけどな…

でかいというのなら、極端に削ってみよう…
３行程度（２４バイト分）にしてみた。
コンパイル通った。（あたりまえ）

これをシミュレーションに掛けてみて、プログラム
メモリ、ＳＲＡＭ、ＥＥＰＲＯＭ、レジスタの
それぞれをメモリダンプ取ってみると…
うん。やっぱりプログラムメモリにしか配置
されてないよな。（以前の実験ではプログラムと
ＳＲＡＭの両方にメモリを確保に行ってしまい、
全然ダメだったんですが、今回はそれは大丈夫
みたい）

うーん、方針は合ってるのか。

データ量を半分くらいに削ってみる…
お、コンパイル通った！

うーん、３０ＫＢくらいならＯＫか…
オリジナルは６０ＫＢくらいになっちゃう
ので、ここから少しずつ削りながらコンパイル
を繰り返してみると…

およそ３２ＫＢを割ったところでコンパイルが
通るようになるみたい。


うーん、ＡＶＲ－ｇｃｃって、３２ＫＢの壁
なんて有ったんだったっけなぁ？記憶に無いな…
あとで調べなおしてみよう…
（１６ＦシリーズのＰＩＣは面倒くさいのが
　イロイロあった気がするけど…）

いずれにしても、このままでは８ビット版ＡＶＲ
には載せられそうに無いな。


というわけで、スクリプトを書きまくったので、
あとでサイトに纏めておきたいと思います。


ちなみにｅｅｐｒｏｍに格納しておけば、メモリが
ちっちゃいマイコンでも充分使い物になるかと
いう気がします。Ｉ２Ｃで読み出してＬＣＤに転送
みたいに…。

SG12864Aみたいな１２８×６４ドットＬＣＤだと
１ドット＝１ビットでも１０２４バイトが必要に
なるはずなんですが、テキスト文字表示だけに
特化するならマイコン側にグラフィックＶＲＡＭ
を持つ必要は無いので、マイコン側に必要なのは
テキストＶＲＡＭと変換処理ロジックだけ。

１２８×６４ドットを１キャラクターあたり
８×８ドット単位とすれば１２８バイトで済んで
しまいます。
ｔｉｎｙ２３１３じゃぁ厳しいけど、もうちょっと
大きいマイコンなら何の問題も無いでしょう。

忘れてはならないのは、ｊｉｓとｓｈｉｆｔ－ｊｉｓ
の変換とか、その辺りに待つわる文字化けとか、
そのあたりかな。

ハヤニエＬＣＤを工作に引っ張り出すか、
もしくはＭＥＧＡ１２８のオンメモリに組み込んで
リアルタイムのビデオ表示に使うか…

イロイロ使い道は有りそうな予感。
（￣ー￣）