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もやってます↓
powered by まめわざ- ARM/STM32 (117)
- OpenOCD (27)
- ARM/NxP (34)
- ARM/Cypress (5)
- ARM/Others (3)
- ARM/Raspi (1)
- AVR (13)
- FPGA (4)
- GPS/GNSS (19)
- MISC (80)
- STM8 (2)
- Wirelessなアレ (16)
- ブラウザベンチマーク (28)
- 日本の自然歩道 (25)
- STM32U0はぢめました
⇒ ねむい (08/07) - STM32U0はぢめました
⇒ ひかわ (07/28) - STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ ねむい (05/17) - STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ どじょりん (05/16) - STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ どじょりん (05/16) - いろいろ試す61(と今年の反省会)
⇒ ねむい (01/02) - いろいろ試す61(と今年の反省会)
⇒ ひかわ (01/02) - いろいろ試す61(と今年の反省会)
⇒ ひかわ (01/01) - STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ ねむい (12/31) - STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ ひかわ (12/31)
- September 2024 (1)
- August 2024 (1)
- July 2024 (1)
- June 2024 (1)
- May 2024 (1)
- April 2024 (1)
- March 2024 (1)
- February 2024 (2)
- January 2024 (1)
- December 2023 (4)
- November 2023 (2)
- October 2023 (2)
- September 2023 (1)
- August 2023 (2)
- July 2023 (1)
- June 2023 (2)
- May 2023 (3)
- April 2023 (1)
- March 2023 (1)
- February 2023 (1)
- January 2023 (1)
- December 2022 (2)
- November 2022 (1)
- October 2022 (1)
- September 2022 (1)
- August 2022 (1)
- July 2022 (1)
- June 2022 (1)
- May 2022 (1)
- April 2022 (1)
- March 2022 (1)
- February 2022 (1)
- January 2022 (1)
- December 2021 (2)
- November 2021 (2)
- October 2021 (1)
- September 2021 (1)
- August 2021 (1)
- July 2021 (1)
- June 2021 (1)
- May 2021 (1)
- April 2021 (1)
- March 2021 (1)
- February 2021 (1)
- January 2021 (1)
- 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)
Copyright(C) B-Blog project All rights reserved.
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