ａｖｒ－ｇｃｃの配列サイズの制約についてさらに
調べてみたら、↓ここに
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つに割ってみる…それぞれの配列は
２つの制約に引っかからないのでＯＫなはず。
ただし連続領域には配置されないので、配列の
添え字として参照するのではなく、関数の
引数として位置を引き渡すと、その関数が
どちらかの配列から値を参照して返す。
みたいな感じにすれば上手く行くかな？
あとでちょっと試してみよう。
出来れば意味のあるところで二分割したいところ
だけど、まぁ、拘る部分ではないから適当に
制約に引っかからない位置で分割すればいいのかな？
もちろん、ａｖｒ－ｇｃｃに関する制約だから、
他の言語系ならこのままでも上手く動くかも
しれないな。
むしろ、Ｉ２Ｃのｅｅｐｒｏｍに押し込んじゃう
のが一番ラクチンなのかもね。
|
おすすめブログ
@goo_blog
