Cortex-M0+マイコンなSAMD21を使っているんだけど、
AtmelStudio開発環境で最初に同梱されているツールチェーンのバージョンが6.3.1だったりする。
古い(枯れた)環境で問題ないけども、最新のバージョンって気になるじゃん?ってことで入れてみた。
https://developer.arm.com/tools-and-software/open-source-software/gnu-toolchain/gnu-rm
上のURLから最新版をダウンロードしてきて、
「C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\arm\arm-gnu-toolchain」
この辺りのフォルダを差し替えるだけ!
まぁ、簡単で良かったけど、
gcc-arm-none-eabi-7-2018-q4はバグってるので
http://gcc-arm-none-eabi-7-2018-q2-update-win32.zip
1つ前をダウンロードしとく必要あり。
詳しくは下のサイトに載っています。
https://bugs.launchpad.net/gcc-arm-embedded/+bug/1810274
インターネット上にある断片化された情報を切り取って、リブログする。 主にソフトウェア、Ubuntu関連、CPUなど気になったニュース、また、日々の面白い出来事やニュースもリブログします。
2019年3月28日木曜日
2019年3月22日金曜日
【ARM】【Cortex-M0+】【SAMD21】DMA転送の罠
【DMA転送の罠】
ソフトバンクが買収したARM社のマイコンをこれから積極的に活用しようとして色々勉強してるんだけど、ARMコアのDMA転送のしくみは罠すぎるというか改善余地ありに思えるw
DMA転送を語る前にまずCPUの仕組みを理解するにはOSを設計できるレベルの知識が必要で、特にスケジューリング周りは外せない。
FreeRTOSなプリエンティブ、多段フィードバックキューやタイムスライスなど。
IT系の国家資格を持ってる人なら試験範囲の部分だし、自作OSの実装などでも触っている部分だしこの辺の事は大丈夫だろうと思って油断したのがARMコアのDMA転送。。
仕様上リングバッファ非対応だとか、ラウンドロビンで優先権を回す方式など、ある程度の仕組みを調べていざ動かしてみるとなぜかフリーズするんですよね。。
(海外サイトでも動かなくて解決案が無く、Githubでもコメントでここはそのうち・・みたいな感じになっていたり。PC向けARMって大丈夫?)
フリーズする理由でいくつか考えてみると、割込みが飛んでこないからっていう理由でコールバック処理されないなど色々模索してみたけど結果解決できず。。しかもレジスタを覗いてみるとラウンドロビンのFIFOキューは空っぽ、、静的な割り当てしても反応しない、、アクティブチャンネルを変えようと思っても切り替わらないしいったいどうなってるの状態。
さまざまな代替案やアプローチを考え試したけどうまくいかなくて、最終的にはPIOでカバーという非常手段を取っておきつつ、何度も1000ページ超える英文のドキュメントを読み直しては間違った解釈が無いか、抜け漏れがないか調べてようやく気付いた事がある。
ラウンドロビン・・・(; ・`д・´)?
あー・・・(悲しみ
通信周りに関して上位レイヤーから物理レイヤーまですべて精通してるつもりだったけど、そうでもなかった件について。。
ラウンドロビンって順番に優先権を渡して終わったら次!っていう感じに回していく仕組みだから、受信側のDMA転送は指定バイト数受信が終わるまで優先権を奪ってしまうんですよね。
つまり、タイムアウトなんて機能がないため
他のDMA転送を開始しない限り優先権は切り替わる事はなく、そのままフリーズする現象が起こる。
というのもバイト単位をビートという名称で括っていて、1ビート単位で受信したよ!って割込みを発生させることができれば解決するように思えるがうまくいかない。
割込みをやめてライトバックキャッシュをポーリングして自分で転送データ数をカウントしていこうと思っても割込みが発生しない=ライトバックキャッシュは更新されない。って現象。
では、参照するたびにサスペンド・リジュームしていけば割込み飛んでくるし解決?って思いきや、割込み入るまで16クロック程度かかったりするのでオーバーランのリスクが高まる。
以上の事から1ビートを1バイト単位に刻めば解決?って思うけどそれはそれでメモリ圧迫するからしたくないジレンマ。。
今日考えたのは、タイマー割込みをDMA転送にして割込み優先度を受信DMA転送より高くしてあげればいいんじゃない?って発想。
1ms割込みを無駄に消費するけど、バス効率が悪くなるだけでCPUの負担は少ないはず。。
これでもう一度DMA転送を試してみようと思う。
教訓:知っているからって油断するとハマる罠あり
ソフトバンクが買収したARM社のマイコンをこれから積極的に活用しようとして色々勉強してるんだけど、ARMコアのDMA転送のしくみは罠すぎるというか改善余地ありに思えるw
DMA転送を語る前にまずCPUの仕組みを理解するにはOSを設計できるレベルの知識が必要で、特にスケジューリング周りは外せない。
FreeRTOSなプリエンティブ、多段フィードバックキューやタイムスライスなど。
IT系の国家資格を持ってる人なら試験範囲の部分だし、自作OSの実装などでも触っている部分だしこの辺の事は大丈夫だろうと思って油断したのがARMコアのDMA転送。。
仕様上リングバッファ非対応だとか、ラウンドロビンで優先権を回す方式など、ある程度の仕組みを調べていざ動かしてみるとなぜかフリーズするんですよね。。
(海外サイトでも動かなくて解決案が無く、Githubでもコメントでここはそのうち・・みたいな感じになっていたり。PC向けARMって大丈夫?)
フリーズする理由でいくつか考えてみると、割込みが飛んでこないからっていう理由でコールバック処理されないなど色々模索してみたけど結果解決できず。。しかもレジスタを覗いてみるとラウンドロビンのFIFOキューは空っぽ、、静的な割り当てしても反応しない、、アクティブチャンネルを変えようと思っても切り替わらないしいったいどうなってるの状態。
さまざまな代替案やアプローチを考え試したけどうまくいかなくて、最終的にはPIOでカバーという非常手段を取っておきつつ、何度も1000ページ超える英文のドキュメントを読み直しては間違った解釈が無いか、抜け漏れがないか調べてようやく気付いた事がある。
ラウンドロビン・・・(; ・`д・´)?
あー・・・(悲しみ
通信周りに関して上位レイヤーから物理レイヤーまですべて精通してるつもりだったけど、そうでもなかった件について。。
ラウンドロビンって順番に優先権を渡して終わったら次!っていう感じに回していく仕組みだから、受信側のDMA転送は指定バイト数受信が終わるまで優先権を奪ってしまうんですよね。
つまり、タイムアウトなんて機能がないため
他のDMA転送を開始しない限り優先権は切り替わる事はなく、そのままフリーズする現象が起こる。
というのもバイト単位をビートという名称で括っていて、1ビート単位で受信したよ!って割込みを発生させることができれば解決するように思えるがうまくいかない。
割込みをやめてライトバックキャッシュをポーリングして自分で転送データ数をカウントしていこうと思っても割込みが発生しない=ライトバックキャッシュは更新されない。って現象。
では、参照するたびにサスペンド・リジュームしていけば割込み飛んでくるし解決?って思いきや、割込み入るまで16クロック程度かかったりするのでオーバーランのリスクが高まる。
以上の事から1ビートを1バイト単位に刻めば解決?って思うけどそれはそれでメモリ圧迫するからしたくないジレンマ。。
今日考えたのは、タイマー割込みをDMA転送にして割込み優先度を受信DMA転送より高くしてあげればいいんじゃない?って発想。
1ms割込みを無駄に消費するけど、バス効率が悪くなるだけでCPUの負担は少ないはず。。
これでもう一度DMA転送を試してみようと思う。
教訓:知っているからって油断するとハマる罠あり
2019年3月17日日曜日
VSCodeでCortex-Mコアのビルド環境を整える
【VisualStudioCodeは便利】
当時viかemacs、どちらを使うか悩んでいた時に
emacs派生のxyzzyを1か月使ってみて色々分かってきたんだけど
VIのシンプルさと軽量である点に惹かれてメインはVIM、しぶしぶVSを使うって感じでした。
(VSにはリファクタリング、コード補間機能が優れていて不満はないけど、もっさり感だけは・・・)
ちなみに今回VSCodeを使い始めようと思ったきっかけは
今やってるマイコンのプログラムのデバッグ環境がVIでは構築できなかったため。
最初は何をすればよいかサッパリ分からない状態だったけど
使い慣れていくうちに、これは便利だな・・・って思えるところまできましたw
というのも、GCCビルドする時もccacheを使う設定にしてみたり
GDB起動する時のConfigurationも自分で変更できるし。
むしろ書かないと何も動かないけど、書けば動くってところに魅力がある。
ってことで、今日はビルド&GDBデバッガ実行が整った記念にSS撮影w
まだ細かいところ、エラー行にジャンプする設定とかまだだけど、デバッガが使えるから重宝しそうです。
・・・さて、設定の内容に移ろうと思います。
まずは.vscodeフォルダに3つファイルがあります。
・c_cpp_properties.json ・・・インクルード関係(参照ジャンプ用)
・launch.json ・・・デバッガ設定
・tasks.json ・・・ビルド設定
大まかに分けるとこんな感じです。
インクルード関係は、コード上波線~~が出てるところにカーソルを合わせると電球マークが出てくるからそれをクリックするだけでOK。
デバッガ設定はGDBを使う場合は、最初JTAGポート開いてデバイスにアタッチして、ロードして、break mainまでの一連のバッチを書きます。
ビルド環境は、Makefileのあるフォルダ設定をして、make clean、make allを実行できるようにします。
もしビルドの高速化でccacheを使う場合は、Makefileに書かれている gcc部分の前にccacheを入れるだけでOKです。
例:
gcc -o hoge.c
これを
ccache gcc -o hoge.c
にするだけ!
コードを張り付けようと思ったけど、
まだビルドエラーした時のエラー行ジャンプがまだなので、次回にします。
![]() |
| VSCode上でCortex-M用のコードをビルド! |
当時viかemacs、どちらを使うか悩んでいた時に
emacs派生のxyzzyを1か月使ってみて色々分かってきたんだけど
VIのシンプルさと軽量である点に惹かれてメインはVIM、しぶしぶVSを使うって感じでした。
(VSにはリファクタリング、コード補間機能が優れていて不満はないけど、もっさり感だけは・・・)
ちなみに今回VSCodeを使い始めようと思ったきっかけは
今やってるマイコンのプログラムのデバッグ環境がVIでは構築できなかったため。
最初は何をすればよいかサッパリ分からない状態だったけど
使い慣れていくうちに、これは便利だな・・・って思えるところまできましたw
というのも、GCCビルドする時もccacheを使う設定にしてみたり
GDB起動する時のConfigurationも自分で変更できるし。
むしろ書かないと何も動かないけど、書けば動くってところに魅力がある。
ってことで、今日はビルド&GDBデバッガ実行が整った記念にSS撮影w
まだ細かいところ、エラー行にジャンプする設定とかまだだけど、デバッガが使えるから重宝しそうです。
・・・さて、設定の内容に移ろうと思います。
まずは.vscodeフォルダに3つファイルがあります。
・c_cpp_properties.json ・・・インクルード関係(参照ジャンプ用)
・launch.json ・・・デバッガ設定
・tasks.json ・・・ビルド設定
大まかに分けるとこんな感じです。
インクルード関係は、コード上波線~~が出てるところにカーソルを合わせると電球マークが出てくるからそれをクリックするだけでOK。
デバッガ設定はGDBを使う場合は、最初JTAGポート開いてデバイスにアタッチして、ロードして、break mainまでの一連のバッチを書きます。
ビルド環境は、Makefileのあるフォルダ設定をして、make clean、make allを実行できるようにします。
もしビルドの高速化でccacheを使う場合は、Makefileに書かれている gcc部分の前にccacheを入れるだけでOKです。
例:
gcc -o hoge.c
これを
ccache gcc -o hoge.c
にするだけ!
コードを張り付けようと思ったけど、
まだビルドエラーした時のエラー行ジャンプがまだなので、次回にします。
2018年11月14日水曜日
[AtmelStudio]クロックの設定
ATMEL SAMD21マイコンを使う上で必ず最初に設定しなければならないクロック設定。
USBホスト機能やUART回りを使うなら外部クリスタル発振子を使った方が断然よいので
今回は外部クロックを使用した場合の例です。
まず最初に使うコンポーネントを追加します。
次にどのオシレータを使うか設定で、内臓8Mと外部32.768kHzのオシレータにチェック入れてから
内臓8MHzは400kHzに分周して、FDPLLで48MHzを生成します。
ソースクロックで入力するオシレータを選択していきます。
GCLK0は48MHz、GCLK3は400kHzを設定すればクロック設定終了です。
ちなみに内臓クロックの精度はこちら。
https://cdn-shop.adafruit.com/product-files/2772/atmel-42181-sam-d21_datasheet.pdf
Page972参照
USBホスト機能やUART回りを使うなら外部クリスタル発振子を使った方が断然よいので
今回は外部クロックを使用した場合の例です。
| クロック設定例 |
まず最初に使うコンポーネントを追加します。
次にどのオシレータを使うか設定で、内臓8Mと外部32.768kHzのオシレータにチェック入れてから
内臓8MHzは400kHzに分周して、FDPLLで48MHzを生成します。
ソースクロックで入力するオシレータを選択していきます。
GCLK0は48MHz、GCLK3は400kHzを設定すればクロック設定終了です。
ちなみに内臓クロックの精度はこちら。
https://cdn-shop.adafruit.com/product-files/2772/atmel-42181-sam-d21_datasheet.pdf
Page972参照
2018年11月13日火曜日
【ARM】高機能JTAG、BlackMagicProbeクローンを激安STM32F103C8T6マイコンで作る。
このBlackMagicProbeというものは、ARMなCortexシリーズ用のJTAG/SWDデバッグアダプタで、通常デバッガはOpenocdを使う所をgdb使うようにしたものです。
デバッガをGDBにしたことで、FreeRTOSなどでいろんなスレッドに飛ばされたりしたときにも細かくトレースできて高速、というのがウリのようです。
もう1つ良い点は、これ1つ持っていれば各社ARMマイコンと各社専用のJTAG/SWDアダプタを買わずに済むというメリットがあります。
そんなBlackmagicProbeですが、オープンハードウェアでオープンソースなので自由にクローンが作れます。
サイトは以下URL.
まず激安マイコンのSTM32F103C8T6はフラッシュ領域が64kBなのですが、アンロックすることで128kBにできます。
今回各ファームは64kB超えのROMサイズなので、必ずアンロック作業が必要になり
特別な書き方で行わないとできないので、STLink Utility上からでは書き込むことはできないので要注意。
ちなみに参考程度のメモですが、
ファームはRaspberryPi3上で環境を構築して同じCortexコアなのでそのままビルド、ファーム転送で構築しました。
2010年12月1日水曜日
ARMのバージョンについて
まとめてみた。
Nov.2006年のInterfaceより抜粋
Nov.2006年のInterfaceより抜粋
v1 最初の命令セット.ほとんど使用されていない
v2 乗算命令とコプロセッサをサポート
v2a キャッシュのサポートと同期命令(SWP)の追加
v3 ARM 社独立後の最初のアーキテクチャ
v3G 詳細不明.v2a と互換性なし
v3M 結果が64 ビットの乗算
v4 システム・モードのサポート.アーキテクチャの完成版
v4T Thumb モードの追加
v5T BLX,CLZ,BKPT 命令の追加
v5TE DSP 命令セットの追加
v5TEJ Java 拡張(Jazelle)の追加
v6 マルチメディア拡張(SIMD).同期命令の強化(LDREX/STREX).割り込み応答の高速化
v6T2 Thumb-2 モードの追加
v6Z TrustZone の追加
v7 最新アーキテクチャ(詳細は第7 章を参照)
ARM1-3 Acorn 社時代に設計されたコア(現在は使われていない)
ARM4-5 存在しない
ARM6 ARM 社として最初に設計されたコア(現在は使われていない)
ARM7 現在のARM プロセッサの基本コア
ARM8 (現在は使われていない)
ARM9 5 段パイプラインへ拡張
ARM10 6 段パイプラインへ拡張
ARM11 8 段パイプラインへ拡張
登録:
投稿 (Atom)

