ねむいさんのぶろぐ

XMEGAを使ってみる4

たぬ

たぬ

たぬ！
ねむいさんもついにたぬたぬのOWNERになれた…
良いことあると良いですね〜♥法明院で見たとき以来惚れこみました♥
ちなみにこの子、前回たぬき村行った時にゲッツしたと言っていた物です！





…さて本題、Windows上でGCCにてAVR/XMEGAの開発が手軽にできる"WinAVR"は、
20100110版で開発は終了しており現在はATMEL公式から配布されているAVR ToolChain
へとひきつがれています。
そして以前から非公式で海外の掲示板で出回っていた有用なProgramMemoryアクセス
の為のマクロが今回から正式にとりこまれていたりするのでここいらでちょっとまとめて
みたいと思います。



そもそものはじまりはXMEGA触り出した去年にさかのぼります。いろいろ文句垂れなが
らXMEGAを動かして来たわけですがARMではお茶の子さいさいでできたはずの"FontX2ファ
イルのような大容量のデータを配列として埋め込む"ことができないという点で躓いた
ことからでした。これAVRの制約というよりAVR-GCCの制約と言った方が正しいのですが、

１．引数が32767以上の配列を確保することができない
２　uint32_tの配列としてバイト数を稼ごうとしてもそもそも合計32767バイト以上に
　　なる配列を確保することができない
３．64kb以上のメモリ領域のアドレスに通常のポインタを使って容易にアクセスができない

と分かる範囲で上げましたが、普通はAVR使いの人はフラッシュメモリ容量64kb以下の
AVRを使いフォント等の大容量のデータはSDカードに置いてそこからアクセスするとい
う手段が常套となっていて今回私のように横着してCの配列として大容量のデータをフ
ラッシュに焼きこむようなことを安易に考えるとこの問題に引っかかるというわけです。


これ何とかならないかといろいろ検索して調べていると数年前に｢ＰＩＣ　ＡＶＲ　工作室｣
のnekosan氏も同じ問題に当たられていたようでこの制約について非常に深い考察を
されていました。
nekosan氏は最終的に制約に引っかからないようにいくつか分割した配列としてアクセ
スする方式にされたようです。また同日のコメント欄にはnekosan氏とChuck氏のやり取
りがあり、その中で中にGET_FAR_ADDRESSという単語が出てきています。
これは後述しますが"３．"の制約を解消するための非常に重要なキーワードとなります。


さて、制約はわかったけど実際どうすりゃいいのと言う話になりますが、私はフォント
ファイルを直接オブジェクトにして焼きこんでCからはインデックスだけ引っ張って来たら
いいんじゃね？と考え、さらにググってみるとavr-freaksのフォーラムにavr-objcopyで
行う方法の議論がありました…って何年も前だけどこれあっちではFAQレベルなのか…



置き場にあるxmegaのFatFS+TFT-LCD表示のデモにはmakeファイル中に具体的に美咲フォ
ントをAnkと漢字ともにオブジェクト化しelfに取り込むための記述をしてあります。

んでこれをCからアクセスするためにはavr-objcopyで吐かれたラベルを参照すればおｋです♥

…と言いたい　と　こ　ろ　だ　が！

64kByte以上プログラムメモリを持つAVRにおいて、64kByte以上の領域にいつもの調子で
アクセスしようとするとお次は"３．"の制約にあたってしまいます。
そもそもavr-gccはアドレスが16bitとして処理されていて、64kb以上のメモリ領域にア
クセスする時は非常に都合が悪いです(int型が16bitなのからお察しできると思います)。
たとえば…

prog_char inaisan[] = "daisuki!";

というプログラムメモリ上のデータを参照する際にこのデータがプログラムメモリ上
の64kByte以上のアドレスの領域にあった場合、

pgm_read_byte_far((uint_farptr_t)inaisan);

ってやっても配列inaisanの頭のデータ'd'は読み出せません。本来のアドレスから65535
さっぴかれたアドレスにある頓珍漢なデータが返ってくるでしょう。
これは本来24bitあるはずの配列のインデックスのアドレスを頭8bit分カットした16bitで
渡してしまうからです(ポインタ変数を介在させてもポインタのサイズも16bitで、16bit分
のアドレスしか表現できないから同じ結果)。
これを解消するのがGET_FAR_ADDRESSというマクロで、uint32_t型の値を返します。

このマクロを通すとpgm_read_byte_far等のELPMを使う関数へ24bitアドレスとして正常に
値を渡すことができます。また、このマクロは長らく非公式でしたが現在ATMELから配布
されているAVR Toolchainではpgm_get_far_addressと名をかえて公式にとりこまれる
こととなりました。めでたしめでたし。
…私の説明分かりずらいから各自pgmspace.h見た方が早いと思います…。


↑んで、見た目は去年と全く変わり映えしませんが上記のすべてを反映させて、
　AVR Toolchainでビルドして動かしたXMEGAのデモさん。
　やっぱARMの方が組みやすいなぁ…と思うことひとしきり




つらつらとまとまりきれないまとめを書いてみましたが、WinAVRからAVR Toolchainに変
わってから気づいたことのTipsとか

●unixライクなツール群
　WinAVRにはARMマイコンのビルドにも重宝したutilsフォルダ内のmakeを含むunixライ
　クなツール群があったのですがATMEL公式から配布されたAVR Toolchainには存在
　しません！代わりにavr-gccと同じフォルダに同等の機能のものが一切合財ぶち込
　まれていますが、使いやすさを考えるとWinAVRのutilsフォルダだけ保存しといて旧来の
　WinAVRよろしくビルド時にはそこからmake呼び出せられるようにすればモアベター
　だと思います。私みたいなコマンドラインビルド野郎向けですがー！
20121130追：
　WinAVRはもはや時代遅れです。WinAVRについていたutilsの代用はこちらをご覧ください。

●EBIのSRAMモード
　24ビットアドレスのアクセスの問題はプログラムメモリの時の問題だけではなく、もち
　ろんI/O領域にも波及しやがります。厳密に言うとAVR Toolchainとはあんまし関係ない
　のですが、ATMEL配布のXMEGAのEBIのSRAMアクセスのデモが地味にバージョンアッ
　プしていて、pgm_get_far_addressよろしく24bitアドレス用のマクロが用意されています。
　
　ねむいさんxmega使ってこれ以上やる気ナッシングになってしまいましたからあんまし関
　係ないですが…

●delay.h
　AVR Toolchainに変えたらmakefileで正しくクロック周波数を設定してヒューズも間違
　ってないのに以前と違ってちゃんと動かねぇ！1！とお嘆きの方、utils/delay.hをよ〜く
　見てください。
　HAS_DELAY_CYCLESというdefineを1から0にすると幸せになれるかも…。若しくは私みたい
　makefile中でavr-gccにHAS_DELAY_CYCLES=0の定義を渡してやるとよいです。

or

　この問題、意外と根は深いようですね…

• 2011.02.01 Tuesday
• 23:50
• ネムイ・トリノミアス
• AVR
• comments(3)
• -