XMEGAを使ってみる4
たぬ
たぬ
たぬ!
ねむいさんもついにたぬたぬのOWNERになれた…
良いことあると良いですね〜♥法明院で見たとき以来惚れこみました♥
ちなみにこの子、前回たぬき村行った時にゲッツしたと言っていた物です!
…さて本題、Windows上でGCCにてAVR/XMEGAの開発が手軽にできる"WinAVR"は、
20100110版で開発は終了しており現在はATMEL公式から配布されているAVR ToolChain
へとひきつがれています。
そして以前から非公式で海外の掲示板で出回っていた有用なProgramMemoryアクセス
の為のマクロが今回から正式にとりこまれていたりするのでここいらでちょっとまとめて
みたいと思います。
そもそものはじまりはXMEGA触り出した去年にさかのぼります。いろいろ文句垂れなが
らXMEGAを動かして来たわけですがARMではお茶の子さいさいでできたはずの"FontX2ファ
イルのような大容量のデータを配列として埋め込む"ことができないという点で躓いた
ことからでした。これAVRの制約というよりAVR-GCCの制約と言った方が正しいのですが、
1.引数が32767以上の配列を確保することができない
2 uint32_tの配列としてバイト数を稼ごうとしてもそもそも合計32767バイト以上に
なる配列を確保することができない
3.64kb以上のメモリ領域のアドレスに通常のポインタを使って容易にアクセスができない
と分かる範囲で上げましたが、普通はAVR使いの人はフラッシュメモリ容量64kb以下の
AVRを使いフォント等の大容量のデータはSDカードに置いてそこからアクセスするとい
う手段が常套となっていて今回私のように横着してCの配列として大容量のデータをフ
ラッシュに焼きこむようなことを安易に考えるとこの問題に引っかかるというわけです。
これ何とかならないかといろいろ検索して調べていると数年前に「PIC AVR 工作室」
のnekosan氏も同じ問題に当たられていたようでこの制約について非常に深い考察を
されていました。
nekosan氏は最終的に制約に引っかからないようにいくつか分割した配列としてアクセ
スする方式にされたようです。また同日のコメント欄にはnekosan氏とChuck氏のやり取
りがあり、その中で中にGET_FAR_ADDRESSという単語が出てきています。
これは後述しますが"3."の制約を解消するための非常に重要なキーワードとなります。
さて、制約はわかったけど実際どうすりゃいいのと言う話になりますが、私はフォント
ファイルを直接オブジェクトにして焼きこんでCからはインデックスだけ引っ張って来たら
いいんじゃね?と考え、さらにググってみるとavr-freaksのフォーラムにavr-objcopyで
行う方法の議論がありました…って何年も前だけどこれあっちではFAQレベルなのか…
置き場にあるxmegaのFatFS+TFT-LCD表示のデモにはmakeファイル中に具体的に美咲フォ
ントをAnkと漢字ともにオブジェクト化しelfに取り込むための記述をしてあります。
んでこれをCからアクセスするためにはavr-objcopyで吐かれたラベルを参照すればおkです♥
…と言いたい と こ ろ だ が!
64kByte以上プログラムメモリを持つAVRにおいて、64kByte以上の領域にいつもの調子で
アクセスしようとするとお次は"3."の制約にあたってしまいます。
そもそも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
この問題、意外と根は深いようですね…
連絡・質問・免責は↑のリンクを
↓SNSもやってます↓
- ARM/STM32 (97)
- OpenOCD (25)
- ARM/NxP (34)
- ARM/Cypress (5)
- ARM/Others (3)
- AVR (6)
- FPGA (4)
- GPS/GNSS (18)
- MISC (62)
- Wirelessなアレ (16)
- ブラウザベンチマーク (28)
- 日本の自然歩道 (18)
- Windows10対応軽量シンプルな環境でARMマイコンをInsightとOpenOCDを使ってデバッグする(2020年度版)
⇒ ねむい (06/15) - いろいろ試す39(with2019年反省会)
⇒ ねむい (01/03) - いろいろ試す39(with2019年反省会)
⇒ ひかわ (01/02) - いろいろ試す39(with2019年反省会)
⇒ ひかわ (01/01) - OpenOCD小ネタ24 -ビルドするときの小ネタとかも-
⇒ あぷろ (12/27) - OpenOCD小ネタ24 -ビルドするときの小ネタとかも-
⇒ ねむい (12/20) - OpenOCD小ネタ24 -ビルドするときの小ネタとかも-
⇒ あぷろ (12/13) - OpenOCD小ネタ24 -ビルドするときの小ネタとかも-
⇒ ねむい (12/11) - OpenOCD小ネタ24 -ビルドするときの小ネタとかも-
⇒ あぷろ (12/11) - STM32H7を使ってみる4 -キャッシュ・ワンダリング(中篇)-
⇒ ねむい (11/27)
- Windows10対応軽量シンプルな環境でARMマイコンをInsightとOpenOCDを使ってデバッグする(2020年度版)

- December 2020 (3)
- November 2020 (1)
- October 2020 (1)
- September 2020 (1)
- August 2020 (1)
- July 2020 (1)
- June 2020 (2)
- May 2020 (1)
- April 2020 (1)
- March 2020 (1)
- February 2020 (1)
- January 2020 (1)
- December 2019 (3)
- November 2019 (1)
- October 2019 (1)
- September 2019 (2)
- August 2019 (1)
- July 2019 (1)
- June 2019 (1)
- May 2019 (1)
- April 2019 (1)
- March 2019 (1)
- February 2019 (1)
- January 2019 (1)
- December 2018 (3)
- November 2018 (2)
- October 2018 (1)
- September 2018 (1)
- August 2018 (1)
- July 2018 (1)
- June 2018 (1)
- May 2018 (1)
- April 2018 (2)
- March 2018 (1)
- February 2018 (1)
- January 2018 (1)
- December 2017 (2)
- November 2017 (2)
- October 2017 (1)
- September 2017 (1)
- August 2017 (1)
- July 2017 (1)
- June 2017 (1)
- May 2017 (1)
- April 2017 (1)
- March 2017 (2)
- February 2017 (2)
- January 2017 (2)
- December 2016 (7)
- November 2016 (2)
- October 2016 (2)
- September 2016 (1)
- August 2016 (1)
- July 2016 (1)
- June 2016 (1)
- May 2016 (2)
- April 2016 (1)
- March 2016 (2)
- February 2016 (1)
- January 2016 (1)
- December 2015 (3)
- November 2015 (1)
- October 2015 (3)
- September 2015 (2)
- August 2015 (2)
- July 2015 (3)
- June 2015 (3)
- May 2015 (4)
- April 2015 (2)
- March 2015 (4)
- February 2015 (1)
- January 2015 (3)
- December 2014 (3)
- November 2014 (2)
- October 2014 (1)
- September 2014 (2)
- August 2014 (2)
- July 2014 (3)
- June 2014 (2)
- May 2014 (1)
- April 2014 (1)
- March 2014 (4)
- February 2014 (4)
- January 2014 (3)
- December 2013 (5)
- November 2013 (4)
- October 2013 (3)
- September 2013 (2)
- August 2013 (2)
- July 2013 (2)
- June 2013 (3)
- May 2013 (2)
- April 2013 (2)
- March 2013 (2)
- February 2013 (2)
- January 2013 (3)
- December 2012 (4)
- November 2012 (2)
- October 2012 (2)
- September 2012 (4)
- August 2012 (1)
- July 2012 (3)
- June 2012 (2)
- May 2012 (3)
- April 2012 (3)
- March 2012 (2)
- February 2012 (3)
- January 2012 (3)
- December 2011 (5)
- November 2011 (3)
- October 2011 (2)
- September 2011 (2)
- August 2011 (2)
- July 2011 (2)
- June 2011 (2)
- May 2011 (2)
- April 2011 (2)
- March 2011 (2)
- February 2011 (2)
- January 2011 (3)
- December 2010 (7)
- November 2010 (1)
- October 2010 (1)
- September 2010 (1)
- August 2010 (3)
- July 2010 (4)
- May 2010 (1)
- April 2010 (2)
- March 2010 (2)
- February 2010 (2)
- January 2010 (3)
- December 2009 (3)
- November 2009 (8)
- October 2009 (7)
- September 2009 (5)
- August 2009 (4)
- July 2009 (6)
- June 2009 (7)
- May 2009 (14)
- January 1970 (1)


Comments
はじめまして、HATOといいます。
いつも拝見させてもらっており、すごい技術を持っている方だなと感心させられています。
現在、OpenOCDに興味を持っていて、色々調べているのですが、SWDに関してわからないことがあるので質問させてください。
OpenOCD 0.5 でSWDに対応するとなっていますが、FT2232を用いたJTAGボードでも使用することができるのでしょうか?調べている限りでは、OpenOCDでSWDを使用している例はversaloonを使用しているものばかりです。いったいOpenOCD 0.5ではどのJTAGボードに対して、SWDに対応するといっているのか、もしご存知なら教えていただけると有り難いです。
よろしくお願いします。
hato様 はじめまして、ねむいです。
私もいろいろ調べてきましたが、現時点でVersaloon以外にSWD接続で
OpenOCDを実用レベルで使用できるハードウエアは残念ながらありません。
OpenOCD0.5.0はまだRCになってすらいないので確定的なことは言えませんが、
FT2232系のKT-Link、"LM3S811 Evaluation Board"、USBインタフェースを
持つマイコンが仕込んであるJLINK(v8以降),RLINK,ColinkEx等は既にJTAG
接続では対応になっており、これらはSWD接続も可能な回路構成になって
いるので候補となるハードウエアといえます。
hatoです。ねむいさん、親切なご回答ありがとうございます。
やはり現時点ではVersaloonの使用が一番のようですね。ただ、紹介していただいたKT-Linkはそれほど高価でないようですし、個人的はに気に入りました。
OpenOCDの対応を待ち、購入を検討してみます。
ありがとうございました。
Post a Comment