XMEGAを使ってみる5 -FatFsのDMA化-

AVRマイコンの進化形であるXMEGA。ねむいさんの偏見ですがこれを触った人たちの
殆どが以下の運命を辿ってる気がしなくもなくもなくもないです…。

1.XMEGAが手に入りました(^^)DMAやDACが使えるので楽しみです。
↓
2.ChaNさんのFatFsが動きました(>▽<)次はDMA化してみます(^^)
↓
3.XMEGAではSPIはスレーブしかDMAをサポートしてないみたいですね〜
　UARTのMSPIモードでしかマスタでDMAができないようです(＠o＠)
　いやはやデータシートはしっかり見なくては(^^；
　(↑流し読みしないで初めからちゃんと見ろ！)
↓
4.(XMEGA関連の更新が途絶え、関係ない記事ばっかりになる)
↓
5.(息してない)
↓
6.おや？スライムたちが集まって…？
↓
7.
　
　↑こちらのサイトでこの文字を作らせていただきました！


…なんでねむいさんのほうを見る！？



といつもの戯言はこの辺にして以前挫折して放り投げていたXMEGAにおけるFatFsのDMA化、
ねむいさんもついに成功しましたのでご報告します。

ain氏のXMEGAのDMA転送に関する記事が大きなヒントになったわけですが、SPIは送信と
受信が対になっていて｢(SPIマスタで)データを得たければ先ずは送信せよ｣というのが頭で
固まってしまっていてずっとTxからDMAの初段をキックしていました。

まさかRxからキックを開始しなければ転送が成立しないなんて思いもしなかったので
目からうろこでした…。ホントにあとちょっとのところだったのに投げ出してしまったのか私orz
…と後からはいくらでもなんとでも言えるのですがまぁ無事動いたから良しとしましょう！


ファイルの読み出し速度の比較を行ってみました。

↑DMAを使用しないベタな転送の時

↑DMA転送時
実験に使用したSDカードはSTM32の時に使っている物と同一です。

STM32F1でSPIのクロックが18MHz時のDMA転送では2100kByte/Sec程出ていましたが、
XMEGAにおいて許容されるSPIクロックは16MHzまでとなります。そこから単純に逆算
すると、1800kByte/Sec近く出ることになります。DMA転送前の前処理等での時間ロスを
考慮すれば1500kByte/Secという値はある納得できるものだと思います。

これ以上転送速度を上げようと思ったらオーバークロックをするか、ダブルバッファリング
で効率化を図る等が必要になるでしょう。同氏の記事にはそれらに加えてペリフェラルも
合わせてDMAで動かすときの考察もされており非常に参考になります。



というわけで私のおきぱにあるXMEGAのプロジェクトも今回のDMA転送のサポートを
加えて更新しておきました。なんとうかずっと残っていた胸の突っかかりが取れたような
気分でほっとしております♥

また、トップにもたびたび告知していますが、今回の更新から私が使用させてもらって
いる他の方のライブラリやソフトのライセンスの表記について、ソースが入っている
Zipファイルに各コピーライト、ライセンスを記したテキストファイルを同梱し明確化
していくようにしました(ホント今更ですが…)。

もちろん私のSTM32等のプロジェクトも同様の整備を広げていくしていく方針です。

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

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

XMEGAを使ってみる3

Versaloon関連で飛んできた人はこちらへ


年度末になると何でか糞忙しくなりますね〜…私はというと企業研修で来ている知り
合いの学生の子(去年11月下旬からSTM32初めてあっという間にマイクロマウスまで
製作ってた!!)に私のブログの内容をしてねむいさんていどひくいと罵られたり、
お客さんの現場で生暖かい目で見つめられながらハーネス打ちかえたり、私より一回
り年下の弟が私より一回り年上の彼女連れてきたりするなかで隙を見てマイコンの
勉強をやってきてます…。


LPC2388やSTM32系のMCUで動かしてきた大きめのTFT液晶、EGO028Q02や
YHY024006AをATXMEGA128A1にも導入すべく準備を進めてきました。
前回、現行のATXMEGA128A1にはPORTLが存在しないため4PORT-EBIが実質上
使用不可能と書きましたが、メモリアドレスを2つ(アドレス線は一本)しか使用しない
上記液晶たちは話が別です。FPGAボードを接続する前の肩慣らしに先ず4PORT-EBI
でTFT液晶を制御する試みを行いました。

ATxmegaのEBIに供給されるクロックはシステムクロックの2倍なので最高64MHzのクロック
スピードで動作させることができます。高速のSRAMは恩恵を受けられるでしょうが、LCD
からしてみると早すぎです。read時だけウエイトを0->4に落とす等の細工をしています。
長々と書きましたが4PORT-EBIは無事機能して,YHY024006Aに画像やフォントを表示する
ことができました。


↑まだFatFs積んでないので容量の都合上このサイズの画像しか表示できないです。
　ァァ残念だー(棒

あとATXEGAで試してみたい機能はADC,RTC,事象システム,FatFs(SPIをDMAにする)搭載、
それと今回試したEBIを今度は3PORT-EBIモードで大容量SRAMというかそれが乗っかっ
たFPGAボードと接続する。そんな感じでしょうか。また、すｚ氏やいえなが氏も現在進行系で
XMEGAを触られているのでお二方の作品の完成もたのしみですね。










と、いつもならここで力尽きて日記が終わるわけですが…ていどたかい虹裏メイドを目指す
ねむいさんもうちょっと頑張ってみます！！次いつ更新できるか分からないし！




私も多分にもれずSTM8S-DiscoveryというSTM32ボードを購入しましたが、以前から目を
つけていたVersaloonという汎用JTAGライタ/デバッガに改造を試みました。

このVersaloonに使用されているマイコンはSTM32の48pin,ROM62kb,RAM20kB,ペリフェラル
としてUSBが存在する物のようですね。そしてSTM8S-DiscoveryにSTLinkとして乗っか
ってるSTM32F103C8T6はVersaloonになる条件をすべて満たします。

んでもっておあつらえ向きに書き換え用のJTAGの端子も出ているのでまずはUrJTAGで
様子を見てみました。


↑とりあえずJTAGKeyを繋げる…


↑ふつーのSTM32ですね〜…ちゃんとJTAGで見えます(ﾆﾔ･･

次にOpenOCDからフラッシュのバックアップを取ろうとしましたが…


↑やっぱしダメか…

というわけで一度STM32のフラッシュを書き換えてしまうともう2度とSTM8SをDiscoverする
ことが出来なくなってしまうわけです。しかし！ねむいさんはSTM32のボードを購入した
つもりなので容赦なく消しましたｵﾗｰ！！

次にVersaloon用の回路(後述のRelease1の回路構成)に作り替えます。必要なものは
12MHzのクリスタルです。STM8SにつながっているSWIMを構成している一部のピンは
VersaloonとDFUの動作を阻害するので必ず足上げしたりジャンパカットしてください。
注：基板の改造は必ず情報の1次ソースで提示されてる回路を参照してご自分で
判断を行ってください！！実験色が非常に強いのでここでは詳しく書きません！！


↑ねむいさんは横着なので基板からSTM32を外さずに無理やり上記の改造をしましたが
　真似される奇特な人は基板から外して別に組んだ方がいいですよ?
　ちょろっと出てるUEW線は用が済んで外したTDIとTDO。

↑使わなくなったSWIMのピンはDFUモードに入るためのモード設定ピンに再利用しました。
　中途半端に起立しているチップ抵抗がやっつけ感漂う…

VersaloonはDFUによりセルフアップデート出来る構成をとっています。それに倣って最初
はDFUを書き込みます…。STM32F107系に慣れてしまった身ではとてももどかしいです。
JTAGで書くに越したことないですが、持ってない人は必要なピンだけジャンパ引き出して
システムメモリからブートして書き込むって方法もあります…。


↑DFUが立ち上がりDFUDemonstratorが立ちあがったところ。
　ここまで来たら勝ちです！

現在、Versaloonはいくつか種類があり、製作者のSimonquan氏のページからソース、回
路図、ホスト側プログラム、OpenOCDへの対応方法などの情報はすべて提供されています。
今回私はRelease1の回路を構成しRelease1用のファームをビルド、そしてDFU経由で
Versaloon本体を書き込みしました。



↑出来上がったVersaloonを別のSTM32ボードと接続して、vsprogにてJTAGモードとSWD
モードそれぞれの方法で認識させたところ。


↑vsprog(gui)で書き込みもできます。STM32だけではなくAVR/MSP430/PSOC/STM8Sも
　書き込めるようです。


↑SWDに対応するパッチを当てたOpenOCDを使用してSWDでデバッグ。

今は動作確認の為のやっけつの仮組ですが目的のSWDで使えそうなのがわかったので、
STM32を別の変換基板に移し替えて汎用のJTAGデバッガ/ライタに仕上げるつもりです。

今回の実験に使ったVersaloon用のDFUとVersaloon本体のプログラムをこちらに。非常に
実験色が強いので完全自己責任のご意見無用とさせてもらいます。

XMEGAを使ってみる2

NGワーオ：ARMその他32ビットマイコン
↑ねむいさんが余計な事を言わないため用



…さて、XMEGAを使えるものにすべく少しずつフレームワークを固めてきましたが、
今現在まだまだ手探り段階です。


↑突っ込みどころ満載な画像

私のXMEGA用の開発環境はコンパイラがWinAVR,ライタ/デバッガがJTAGICEmk2です。
主人の遺物から強奪したから譲り受けたJTAGICEmk2はハードウエアのリビジョンが古く、
PDIモードが使用できないためJTAGモードでしかアクセスできません!!

んでもって何でライタと書き込みアダプタをつなぐケーブルがFPCじゃないかというと
FPCコネクタがｶﾞﾊﾞｶﾞﾊﾞになってて普通の電線で無理やり繋げて修復するまで書き込み
すら満足にできなかったからですよｸｿｧ!!
…はぁはぁ…まぁコマンドラインツール使えるからあまり不便には感じませんが…。


この環境でフラッシュメモリに焼きこんだFONTX2ファイルやBMPファイルを表示できる
ようになるまで出来ました。AVR使いの方はご存知かと思いますがコンパイラやAVRの
アーキテクチャそのもののいろんな制約で表示できるようになるまで難儀しました。
しかし一度峠越えて扱い方わかるともうあとは楽でした…


↑BMPファイルを表示した上にFONTX2(美咲フォント)で赤文字透過表示したところ。
　一部誤字があってアレな部分が伏せ字になってしまってますが無害です(棒
　バレンタインだったし！


…さて、こっから先どうするかを考えなくてはならないのですが、EBIを使ってSRAMとか
繋げることも考えました。XMEGAで使用できるEBIはALE無しでもSRAMに接続できるはず
ですが現行のXMEGAのモデルではEBIを構成するために必要なの一部のバス(PORTL)が物
理的に存在せず、実質上ALE使わないと大容量のSRAMを扱うことができませんｸｿｧ！
…ｵﾎﾎ私ったら…失礼…SDRAMはもっとひどいことになってるらしいですね…。

でもLCDを繋げるくらいならALE無しでも十分すぎるくらい賄えるので、前回の液晶を先ず
EBIで繋げてアクセスするところからはぢめます…。
それと今思いつきましたがMAI電子さんより購入した高速SRAM付きFPGAボードを死蔵
していますのでこれを利用しない手は無いですね…！
丁度fenrir氏がcblsrvをISE11.xでも使えるように更新してくれましたので…
ねむいさん今度こそ本気だす！！


↑やるやる詐欺

XMEGAを使ってみる

シリアルの動かしかたを数か月間分からなかったのを気に病むことはない！！ねむいさん
だっていないさんのブラのホックを外すことができるまでに9か月かかったのだから(ｷﾘｯ

といいたいところですが何かしらの問題にぶつかった時にネットで検索してすぐ見つかる
レベルの他人のソースにあたる癖は止めてデータシートとエラッタシート等の基本的
情報は事前にしっかり読んで把握しておきましょうね。あと第三者が作った機械翻訳
バリバリ手抜きの日本語訳なんて当らずに原文を素で読める英文読解力付けましょうよ。
そういう指導ばっかしてたら一般には絶対降りてこない未知のエラッタがたくさん潜む
renesasとかのマイナーな品種のマイコンとかを実務で宛がわれた時に何も対処
できなくなっちゃって電子工作感覚でネット上のフォーラムで聞いて他人に笑われる
子を世に出しちゃいますよ！(ブーメランをかわしつつ)

電子工作の"遊び方"を教えるんじゃなくて電子回路設計する際の"考え方"を指導しましょう。



はぁはぁ…まぁいいやねむいさんの学習目的だし…
とは言いつつも私が公開してるプログラムが"コアダンプ吐いてビルド止まった!"り
"パスが通ってるのにエラーになったりしてビルドができない！"ていうコメントされて
るのを他の方のtwitterやブログ等で目の当たりにするとさすがに気が咎めてき(ても
私自身打つ手がなにもなかっ)たのですが、数多に存在するうまくいかない原因のうちの
一つをめっけました。makefile中のワイルドカードの指定がマズかったようです…。

いままで公開してきたものほぼすべてに波及してたので何とか時間見つけて修正して
きました…。LatticeのAVRコアだけはツールのライセンス期限切れで動作確認が出来
てませんがこちらも追々と…WinAVR更新してなかったら気づきもしなかったのか私…



長い前振りになってしまいましたがWinAVRを20100110に更新したついでに今まで死蔵
してたXMEGAを使ってみました。なんと今回がねむいさんのぶろぐ初のAVRカテゴリ！
使用にあたってすｚ氏とO-Famiry氏、そしてSTM32のdfu作成プログラムでお世話になって
いるシバ某氏との使用記を参考にさせてもらっています。
最初に言っておくとすでにARM使いな人はXMEGA使う意味まったく無いのとAVRから
ステップアップして規模のおっきいマイコン使うこと考えてる人はプログラムの組みや
すさ考えると"やっぱARMっしょ"になってしまいますがそれは端に置いておきます！

日本で比較的容易に手に入るのはATXMEGA128A1ですね、今回私もこれを使いました。
取り合えずいつものSPIのTFT液晶でMCUの情報を読み出し表示させるところまで…。

今回購入したXMEGAのチップリビジョンは"H"でした。リビジョンHでもerrataがまだわん
さかあります。このXMEGAが世代交代するころにはきっとerrataも無くなるでしょう(ｦｲ

ホントはでかいフラッシュ領域を頼りに絵とか日本語フォントとかもフラッシュに焼き
こんで表示したかったのですが、フラッシュ領域がRAM&I/O空間と分離されているのと
WinAVR固有の配列確保の時のサイズの制約のおかげでトリッキーにする必要があり、
うまく表示できるまでかなり時間喰われそうなので今回はパス。
せっかく買ったのがもったいないのですけど他の方が優れた作例を出されるまで再び
塩漬にしておきます…。



あと忘れるとこだったけど、冒頭のビルドエラー修正の"ついで"でSTM32F107VCT6用の液晶
表示プログラムに前回使用した2.4"と3.2"用ドライバ(16bitアクセス)を追加しているので
現物を所持していて興味がある人は試してみてくださいね。

Go to top of page