いろいろ試す39(with2019年反省会)

もう一年が過ぎてしまいましたね〜濃密な一年のおかげと思いたい



●触ってないとOpenOCD忘れそうになる
12月に入り、NuvotonのCortex-M0マイコンに目覚めてしまった方からデバイス対応の
お願いのコメントをいただいたのですが最初正直乗り気ではありませんでした。
なぜ日本人が使用してないNUC126なのかなぜSTM32G0ではないのか

なぜかというとNuvotonスタッフがOpenOCDのgerritに提出したパッチがあっさり
却下されてしまったあと修正を行わずに自分のgithubでしこしこ更新を続け早数年、
現在のOpenOCDとは容易にマージができない状態になってしまい、ますますぱっちが
受け入れがたい状態となってしまっていたからでした。

しかもOpenOCDのコアをアクセスする部分にもガッツリ絡んでいて私も容易に手が
出せない状況(そら弾かれるわ)でした。

しかしながらアリア藩から脱出するためにできるとこまでマージすることにしました。

・NUC126系とNUC4xx系は入れる方向で。
・フラッシュ書き込みアルゴリズムはNuvotonがこしらえたやつを。
以上2点はがむばって実装してみました。ちなみにNUC126はNUC120とプロセスが別物
なのでなんと消去ページサイズも異なり単純にIDを追加すれば済むものではありません
でした(ハマリポインツ)

ついでに以前ブレークポイントで止まらねぇ問題を引き起こしたデータ領域可変の
モデル(初期の128kbフラッシュのモデル)とかで茶を濁した対策も本格的につぶしに
かかりました。
具体的にはデータフラッシュ領域のアドレスが0x0001F000かつサイズが0(サイズ可変)
の時は強制的にアドレス0固定+メッセージ表示にするようにしました。


↑データフラッシュ領域あり+フラッシュ容量64kb以下の品種の場合。

↑データフラッシュ領域あり+フラッシュ容量128kb以上の品種の場合。

↑データフラッシュ領域無し(or全領域自由可変)の品種の場合。

そんでもって夏ごろにOpenOCDの出力表示のルールが変わってしまったようでPN2の
コンソール画面にwrote**KiBとかが何にも出なくなってしまったのでこいつも強制的に
出るように改造しております。尤もこんな細かい部分誰も気づいて無いと思いますが。

そんなわけで全国に数人いるかいないかのNuvoton使いの方、興味があれば試して
ください。ついでにバグが見つかったりパッチ思いついたらOpenOCDのgerritに投げて
GAIJINさんと直接バチバチやりあってくれると助かります(←ここ重要)


●SystemVolumeInformation問題ふたたび
くそがああああああああああああああああああああああああああ！１１１１！！！！

FAT32とかexFATにSystemVolumeInformationフォルダなんて要らねぇんです!YO!
なんとWin10の1909から昨年の対策だけでは不完全になり、再びSystemVolumeInformation
攻撃してきやがるようになりました！１！１１１！


新規に追加する対策はほとんどの人があまり使っていないBitLocker機能の息の根を
停止することです･･･F**K!

元のページにも1909以降の注意事項追加しておきますね


●大人しくしてろよお前！技適警察だ！
年末に秋月電気通商さんで使いもしないのにXBee3とBLEモジュールRN4020を購入
しました。しかし、このモジュールは本体が小さすぎて技適を張る領域がないのか
モジュールのどこにも技適マークが存在しませんでした。

ねむいさんの大昔の知識ではモジュール上に製造者が認証番号を取得＆付与した
技適マークがないと使用ができなかったはずですが、現在はだいぶ緩和されており
説明書に認証番号とともに技適マークがあれば問題なかったりモジュールを組み込
んだケースにも技適マークを転記可能であるとなておりました。

そして残る問題、"製造者が技適マークを付与する"のが今どうなっているのか、
どどのつまり技適は取れてるけどモジュール本体に技適マークがない場合自分で
技適シール作って貼ってもよいのかということをストレートに訪ねてみました。

・秋月電気通商様
Q:自分で技適シール作って貼ってもいいの？
A:大丈夫だ、問題ない。

・総務省近畿総合通信局様
Q:↑って秋月電気通商さんは言ってますが問題ないですか？
A:大丈夫だ、問題ない。
Ａ：大丈夫だ、問題ない。

ッッッッッしゃぁあああああああああああああああああ！！！！！１１！！！！


というわけで早速シール作りました♥

RN4020のモジュール基板は裏にはっつけました。

これで以前wirelessなアレでねむいさんを悩ませてきた通販における技適ガチャ
も解決です！！！！

♥おさらい♥
自分で技適マークシール作って貼ってよい状況は以下の条件を満たすときです。
ちなみに自分で作って貼るときは｢転記｣になるそうです。

1.該当モジュールの技適(「技術基準適合証明番号」もしくは「工事設計認証番号」
　がちゃんと取れている
2.モジュールの取り扱い説明書(マニュアル)に「技術基準適合証明番号」もしくは
　「工事設計認証番号」が明記されている。

そのほか、技適シール作らなくても最終完成品が液晶モジュールもちならば液晶に
技適マークを表示する手順を示せばOKです(これも転記)。

技適マークシールを作るときのルールはtelecに明示されているのでそれを参考に
作成しましょう。

そんでもって2019年12月現在は届け出すれば海外認証取れてる奴なら技適なくても
限定的に使用可能になっています。
ねむいさんが触り始めてすぐのころはお仕置き部屋でしか運用できなかったwirelessな
アレやコレも堂々と運用できるってことですね〜。良い時代になりました。


●いろいろ買った
そんなわけで秋月さんから購入した無線モジュールですがその中に重要なやつが。

そう、ラズベリーパイ！しかも最新の4GBモデルとかいうやつ！


電源やモジュールはAmazonで調達してラズベリーパイ欲張りセットを
揃えました！！！！


システム格納用のMicroSDはもちろん産業用の寿命判定できる奴です！！


ついでにキムワイプも購入しました。
なんか50周年記念デザインになってる…。

こんなに要らないYO
残りは副業先に･･･。


なお、ラズパイは2020年からやろうと思います。来年からがむばる。


●ねむいさんQ&A
ようやく本題にかかります。これがないと年を越せません。

Q:＊＊のプログラムを作ってください！！！！！
　＊＊の回路を作ってください！１！！
A:質問で返すようですがなぜ大会期日ギリギリになってねむいさんに泣きつくんですか！！

Q:私の言うとおりにパッチを作成し提出してください。
　マージされるまでのやり取りはそちらでお願いします。
A:自分でやりなさいよー！！！！！
　↑この手のが未だに来る
　
　ちなみにOpenOCDのgerritのログインにYahooIDを使っておりましたが
　あるときから使用できなくなりなんと自分で提出したパッチすら取り下げ
　不可能というくそったれ状態になっておりましたが2019年の今は良く知
　らないけどまたYahooIDでログインできるようになったのでぼちぼちと
　OpenOCDの開発に復帰しようと思います。ラズパイ買いましたしね☆
　
Q:いないさんいいよね…
A:いい…
　残念ながらねむいさんが見せているのはいなちゃんの片りんに過ぎないのですが
　ねむいさんは虹裏メイドとして活動している都合上どうしても肌色が多めに
　なってしまうのですがそんな成果物はびぃぶろぐの規約上完全アウツなのですが
　いろいろ試した結果下着がちょろっと見えてしまうくらいなら大丈夫っぽいのを
　悟りましたのでガンガンギリギリせめて行こうと思います♥
　
Q:カッティングマットが汚いのですが
A:10年物です。大切にしてください☆

Q:「宮本和知の熱血！昼休み」（ＴＢＳ）は視聴率１％台とボロボロで６カ月で打ち切られてしまった。視聴率１％台とボ
ロボロで６カ月で打ち切られてしまった。視聴率ちなみに巨人時代に絶対的な人気を誇った清原グッズも今やたたき売り
で在庫処分を図る始末。１％台とボロボロで６カ月で打ち切られてしまった。視聴率１％台と人気を誇った清原コーロボ
ロで６カ月で打ち切られてしまった。視聴率１％台とボロボロで６カ月で打ち切られてしまった。視聴率１％台と巨人時
代に絶対的な人気を誇った清原グッズも今やたたき売りで在庫処分を図る始末１％台と指定席になってたかつては清原コ
ーナーとして指定席になっていた棚は、キティちゃんに乗っ取られてしまった。いた棚は、キティちゃんロボで６カ月で
打ち切られてしまった。ロボロで６カ月で打ち切られてしまった。視聴率１％台と清原コーナーとボロボロで６カ月で打ち切られてしまった。視聴率１％台と人気を誇った清原コーロボ
ロで６カ月で打ち切られ視聴率１％台と巨人時
代に絶対的な人気を誇った清原グッズも今やたたき売りで在庫処分を図る始末１％台と指定席になってたかつては清原コ
ーナーとして指定席になっていた棚は、キティちゃんに乗っ取られてしまった。いた棚は、キティちゃんロボで６カ月で
打ち切られてしまった。ロボロで６カ月で打ち切られてしまった。視聴率１％台と清原コーナーとしてボロで６カ月で視
「宮本和知の熱血！昼休み」（ＴＢＳ）は視聴率１％台とボロボロで６カ月で打ち切られてしまった。視聴率１％台とボ
ロボロで６カ月で打ち切られてしまった。視聴率ちなみに巨人時代に絶対的な人気を誇た棚は、キティちゃんに乗っ取られてしまった。いた棚は、キティちゃんロボで６カ月で
打ち切られてしまった。ロボロで６カ月で打ち切られてしまった。視聴率１％台と清原コーナーとしてボロで６カ月で視 誇った清原コーロボ
ロで６カ月で打ち切られてしまった。視聴率１％台とボロボロで６カ月で打ち切られてしまった。視聴率１％台と巨人時
代に絶対的な人気を誇った清原グッズも今やたたき売りで在庫処分を図る始末１％台と指定席になってたかつては
A:ﾏｸﾀｻﾝ

　それにしてもコーロボ清原がホームラン打たずに覚せい剤打って捕まるとか
　NOVがあったころは思いもしませんでした。
　
Q:毎年言ってますけど見えなくなった画像早く復活してくださいよ
A:･･･

　･･･
　2020年から本気出す！！１！１！！
　
　


それでは皆様よいお年を〜！

近畿自然歩道を往く -熊野古道大辺路の終点そして中辺路へ-

紀伊半島は広大だ。
2016年の紀伊路から始まって足掛け4年、ついに熊野古道の核心ともいえる
西方浄土熊野三山へと足を掛けます！！！
8月には伊勢路から熊野速玉大社に行きつき今回は大辺路から熊野那智大社に
行きつきましたのでじっくりとご覧ください！



●2019.12.28 近畿自然歩道(熊野古道大辺路(紀伊浦神〜那智(〜那智山)))


虹裏メイドの夜は遅い。
27日に副業先の仕事納めがあったのですが仕事納めは定時より早く上がれるので
そのチャンスを逃さず当日中に南の果ての駅串本に向かいました。
民宿が多数あり電車の始発駅になっているくっしーで前日泊して当日早朝から
スタートする計画を立てておりました！


それにしても串本の冬もすごい…空気が澄みきっていて見上げれは肉眼で
天の川見られるくらいの満天の星です…♥
今話題のオリオン座が目を引きますね！


串本の商店街から離れて国道42号線を30分ほど歩くと今回の宿が見えました。
本当に寝るだけの質素な素泊まり宿ですが私には贅沢すぎるくらい十分です★




･･･
そして虹裏メイドの朝は早い。5:30に宿を発って串本駅へ向かいます。
歩いてるうちにどんどん夜が明けてきました。



日の出を見つめながら前回の続きの場所紀伊浦神駅に。
今回で熊野古道大辺路もおしまいです。
では出発！



まずは駅近くの塩竃神社に道中祈願してトレイルに突入します！



熊野古道は確か道なりでしたが…
あれ･･･埋もれたトンネルで行き止まりだ…


ねむいさんは道間違ったわけではない！１！！！
トンネル見たかっただけだ１！！１！！！


ほどなくして浦神峠です。
休平って名前がついてました。




浦神峠から降りたら里道をなぞって走っていきます。
古道上には昔の神社や地蔵が多数残されていますね。



正月の準備に忙しい大乗寺です。



太田川を越えて太田の集落を抜けます。
9年くらい前の紀伊の水害ではここまで水につかったとのこと･･･まぢですか



お地蔵さんが鎮座している市屋峠を越えます。



市屋の奥根河の池(与根河の池)を越えていきます。



造成地を見下ろす急登を越えたら二河峠です。


この区域の熊野古道は青看板で細かい注意書きがあって親切ですね〜





湯川区域に侵入し?型の汽水湖ゆかし潟を通過します。
ここは紀伊勝浦に近く、勝浦と同じく温泉街がある場所です。



大辺路最後の峠、駿田峠に向かいます！




駿田峠の少し上にある加寿地蔵です。
その対面には地蔵の拝所と那智の海岸線を見渡す見晴らし台があります♥


駿田峠を越えます。
これで峠越えのトレイルは終了です。



天満宮がある紀伊天満に出てきました。
那智駅までもうすぐです。



･･･が、熊野古道は那智側を少しさかのぼっていきます。
しっかし河口付近なのにすごい透明度だ…


道中地蔵がある場所でいったん那智駅に向かいます。



世界遺産となった補陀落山寺です。




補陀落山寺の隣には浜の宮王子神社があります。



十分時間的余裕を残して那智駅に到着です。ここが大辺路の終着です。
そして熊野本宮に続く中辺路のスタート地点となります。
駅の隣には道の駅と温泉までありますね…！


･･･


腹ごしらえをして中辺路攻略スタート！！！１！！！


浜の宮王子にもう一回お参りして道中祈願します。


那智山(那智山 青岸渡寺)へは8km。時間もまだまだ余裕です。



ここも中辺路なので舗装道路上でもたくさんの神社や供養塔があります。


おエゐしスか！？とおもったらなんとまさかの温泉でした…！



車道から曼荼羅のみちという古道に分かれます。
すぐにトレイルに･･･


北条政子を祀る尼将軍供養塔がある荷坂峠を越えま。



荷坂峠を越えると視界が開けて再び車道と合流します。



王子神社ののぼりについていくと市野々王子神社がありました。


そして熊野那智大社に直接向かう大門坂で車道と別れて古道を上ります。



大門坂は熊野古道の中でも有名な場所ですね。



夫婦杉と越えてすぐに最後の王子である多富気王子址があります。



そして大門坂ののぼりも佳境に･･･
といってもそこまでしんどくはないですが



大門坂を上りきると車道と再び合流します。



ゴール地点予定地の那智山バス停ターミナルです。
いつも思うけど真ん中の眼鏡の娘って咲で見た気が･･･




熊野那智大社への最後ののぼりを越えていきます。



熊野那智大社に到着です。
熊野三山は熊野速玉大社に続きここで二つ目となります。



巨大おみくじに挑みましたが…しょぼい…



青岸渡寺にも参拝です。


青岸渡寺の見晴らし台からは三重塔と那智滝が見えます。


青岸渡寺からは中辺路の先のルートがあります。
次回はここからスタートとなります。




三重塔に降りてきました。
徐々に滝が近づきます。



那智滝は飛龍神社内にあります。




那智の滝直下です。
長い時間がかかりましたがついにここまで来ることができました。



那智滝に見送られ那智山バス停に戻りました。


･･･が黒飴ソフトを食べてる最中に気が変わってバスで帰らず
走って那智駅に戻ることにしました！！！
実は時間がまだまだたっぷり余っていたのです！！




下りの道はすごく早い。
那智滝に見送られて大門坂をあとにしていきます。



行きは旧道を進みましたが帰りは国道を駆け下ります。



補陀落山寺と浜の宮王子神社に最後のお参りをしました。



そして那智駅に到着･･･！！！
なんとまだまだ時間に余裕があったので温泉まで入っちゃいました?




温泉を堪能したら駅裏手の那智海水浴場を散策しました。
またこの場所に戦いに来ることになるでしょう･･･！


ちなみに熊野三山のシンボル八咫烏は足が三本あります。
決してtntnではありません！！





那智駅から紀伊田辺まで鈍行ぢごくです…
やっぱり紀伊半島は広すぎる…


すっかり暗くなったところで紀伊田辺駅に到着です。


そして今回の戦利品(ねむいさん用)も購入しました…！
※那智駅で地酒と特産品のお土産も購入済み


そして紀伊田辺からは高速バスで大阪まで･･･
あとはゆったり夢の中でした…ｚｚｚ


というわけで長きにわたる大辺路の攻略も無事終わりました。
しかしながらさらに過酷な中辺路は始まったばかりです！！
これからも気を抜かずに駆け抜けていこうと思います！！！


近畿自然歩道(熊野古道大辺路(紀伊浦神〜那智(〜那智山)))　GPSログ

GPSログは那智山バス停で打ち切ってしまったので実際の走行距離は
38kmほどあります。

近畿自然歩道を往く -走れ高野龍神スカイライン-

12月になるギリギリの糞寒い時期に行くやつー！
だって9月から11月の終わりまでずっと副業の仕事が忙しかったんですもん


っていうわけで今回は近畿自然歩道の中で公共交通機関からのアクセスが
一切存在せず、現地に行くだけでも難易度が高い｢日光神社を訪ねるみち｣を
攻略してまいりました。
なお、ルート中の98%くらいは近畿自然歩道と関係がない高野龍神スカイ
ラインをひたすら駆け抜けるランニング登山となっております！！！１



●2019.11.30 近畿自然歩道(日光神社)


虹裏メイドの朝は結構早い。ここは高野山奥の院前。
弘法大師の奥の院の参拝している人はこの時間帯でもたくさんいました。

高野山は何度も麓から訪れていますが今回はいつもの目的地が出発地点、
ここからひたすら南下して護摩壇山がある龍神村を目指します！



かつては有料道路だった高野龍神スカイラインですが現在は国道371号として
無料で開放されております。近畿自然歩道のエントリポイントはこの道をず〜〜
っと進んで30km先に鎮座しております！！走れ！！



ぐっと下がった気温に朝日が温かい…♥
かつての料金ゲートを超えてさらに進んでいきます。



毎年恒例になった秋のトレラン(?)としては今回は体力任せでかけ上がるだけ
なので難易度自体はEASYかな(と、この時は思ってました…)


熊野古道小辺路と合流してしばし道を共にします。
おそらく来年の秋のロングトレランは熊野参詣路の中で大峯奥駈道の次に
難易度が高い小辺路(の一部)となると思います。


高度は700mからどんどん上がっていきます。絶景が見えてきました。


そんでもって奈良県と和歌山県をひたすら横ぎりまくっています。



小辺路のピークの一つ、水が峰を超えていきます。


うああああもう雪降ってるー！！



水が峰集落跡です…
標高は1100m越えの地点ですが冷たい風がたたきつけて指がかじかんで動かなく
なってしまいました…念のため持ってきたゴム付き軍手が大活躍。


小辺路と別れて再び南下します。
帰りの護摩壇山発のバスに合わせるべくかなり早く出発しましたが
なるべく余裕時間を確保すべくガシガシ走っていきます！



野迫川総合案内所です。
スカイラインから道が分かれて鶴姫の墓なる場所にも行けるようですが
結構な寄り道になるのでパスしました。



ついに旧花園村に到達です！！ｵﾙﾙﾗあとたったの��kmだ!!
基本的に自販機とか全くないのですが道脇には水量が多いおゑイしスがたまに
あるのがありがたいです。



標高1030m、旧花園村の生産物直売所にて。
花園村は2005年にかつらぎ町の一部になり村としては消滅しました。
ペンキで"村"のところだけ消してあってやっけつ感満載である。



ちょっとシーズンが外れてしまいましたがスカイライン沿いの紅葉は
標高の低い場所は残っております。



箕峠にて。お地蔵さんに手を合わせて残りの行程の無事を祈る。


白口峰直下のカーブにて…。
ススキと太陽と青空と緑のコントラストが効いてて最高ですね〜♥


正午に近づきだいぶ気温も上がってきました。



清水温泉に分岐する場所にある清水茶屋は更地になってました…。




高野山からひたすら駆け巡ること30km、ようやく近畿自然歩道のスタート地点の
笹の茶屋峠に到着です…。時間はまだ正午、ここまで予定通りの時間振り。
とりあえず一休みしました。


休憩中がてらこの回周ルートのどっちから攻めるか作戦を練る。
2km弱の

小休止の後まず拝伏山に向かうことにしました(この判断は正しかった)


ここでいきなりルートミスしそうになってしまいました。
ここは道標が全くないのでご注意ください！！！F***K!!!!11!1


伏拝山山頂は危なげなく到達です☆



そして日光神社に･･･
･･･なんかねむいさんのことビビらせようとしてますけど葛城二十八宿経塚巡行を
行所含めて満願った私の敵ではないですよぅへっへっへ･･･

(警告：ここから日光神社までのルートは崩落がかなり進んでマジで危険ですので
　　　　絶対にまねして通行しないでください！！！)


ほ･･･ほらたいしたことねぇじゃんねー…(へっぴり腰


ﾋ


あ、あさっきのが崩落個所でしょここれもう余裕じゃんははへへｈ


あああ無理無理無理無理無理これ絶対無理めっちゃ落ち葉で滑るし
つかんだ岩もぽろぽろ崩れるし滑って堕ちたら30m下にスライダーだし
ごめんなさいもうわるいことしませんもうゆるしｔ


ああああああああああああああああああああああああああああああああああ
ああああああああああああああああああああああああああああああああああ
ああああああああああああああああああああああああああああああああああ
何この斜め45°！！！！！！
(踏ん張った瞬間にズルっと滑ってちょっとちびった)


何とか超危険区域を抜けましたが…
最後の最後まで気が抜けん･･･☠


はぁはぁ･･･
ぜ〜〜んっぜんこわくなかったですよぅ！
(警告：このルートは崩落がかなり進んでマジで危険ですので絶対にまねして
　　　　通行しないでください！！！(重文))
　　　　


たった1.5kmくらいの谷筋道でものすごく時間と体力と精神力を削られまくって
しまいせっかく日光神社にたどり着いたのですが全く頭に入ってきません･･･
昔は高野と熊野を結ぶ拠点たる寺院群があったそうです…。


日光神社がある場所は実は最深部の標高950m…(せっかく1150mまで登ったのに)


笹の茶屋峠に戻り護摩壇山(1372m)まであとはひたすら上りとなります…！


標高がさらに上がりどんどん視界が開けていきます！！
頑張れ私(早歩き)


うぉおおおおおおお！！



田辺市の龍神村の領域に入りました…！
あとほんとにあとちょっと！！！！


スカイタワー見えた！！！！！



・・・ッッツ！
道の駅ごまさんスカイタワーに到着です…！そして無駄にパノラマ写真。
高野龍神スカイラインが冬季になる一日前の今は駆け込みの観光客でごった返して
ました。



休息もそこそこにすぐに護摩壇山山頂に向かいます！
スカイタワーの横を通り雪がうっすら積もった道を行くと…


高野山奥の院からはるばる35kmくらい、護摩壇山に己の足で到達しました！
そしてここが次の近畿自然歩道(龍神街道)の起点となります！


護摩壇山からさらに東に向かいました行く先は…



近年発見された和歌山県最高峰、龍神岳です。


すっごい。絶景ですよぅ〜♥


今年はこの日でバスの通常運行が終わってしまうのでまた来年ですね〜
再びここに来るのが楽しみです☆


というわけで護摩壇山バス停で余裕をもってゴールとしました。
近畿自然歩道でてこずることを想定して早朝出発で時間ヘッジをかけてたのが
うまく機能してくれたかんじです。さすが私。


と余裕こいてたら道の駅の入り口のここで滑ってこけそうになりました☠
危ない危ない…



道の駅の営業もこの日が今年最終で、里芋のチーズケーキを堪能して
お土産の梅干しも購入しました！
ここは紀伊田辺と高野山と竜神村のお土産全部そろっててほんとに文化の
合流地点って感じがしました。



帰りはチャーターしていた急行バスで高野山まで帰還です。
予約制で料金も護摩壇山->高野山駅まで1880円かかります。
と、乗っている間にどんどん日が落ちていく…日が落ちるのも早くなった。



日も落ちたころに高野山駅に到着です。
帰りはごーぢぁすに特急こうやを奮発しました。でも今回だけですよぅ。


ってわけで今年も晩秋のロングトレイルが無事に終わりました。今回のルートは
龍神村から紀伊田辺or中辺路〜熊野本宮に向かう道のつなぎとなり、ここから先は
激闘になるとおもいます。私も装備や体力を整えて挑んでいく所存です。


近畿自然歩道(日光神社)　GPSログ

ものすごく長くなってしまいましたが本題の近畿自然歩道のルートは
笹ノ茶屋峠周辺のﾁｮﾎﾞの部分です…

STM32H7を使ってみる5 -キャッシュ・ワンダリング(後篇)-

←前回

このぶろぐの読者様的にはねむいさんがうっかり「MDMAを使ってみる」などという
公序良俗（こうじょりょうぞく）に大幅に反したタイトルの記事を書いてしまって
警察屋さんに絞られる展開を期待してるのでしょうがそんな安易な手には引っかかり
ませんよぅ！！！てうかそんな明らかにヤバイ合成(まぜ)モノより天然自然のta
ダメ！ゼッタイ！！！








さて今回はエラッタのせいで強制的にライトバックにせざるを得なくなってしまった
キャッシュメモリでDMAとどうやってうまいこと付き合っていくかを解説していこうと
思います。
なお、DMA使うメモリ領域だけキャッシュ不可にするという軟弱な措置はねむいさんの
ライブラリに存在しませんのであしからず！！！！！！！！

●注意すべき前提
キャッシュがきいた状態のメモリアクセスでは、あるひとまとまりのデータの塊
に加えてそのデータ塊のアドレス境界で処理すべきという大大前提があります。
これはキャッシュを搭載するどのCPUでも同一となります。

｢あるひとまとまり」はキャッシュメモリ上のキャッシュラインのバイト数を示し、
｢アドレス境界｣はアドレスがキャッシュラインのバイト数分のビットで同一である
ということを示します。

Cortex-M7においてはデータキャッシュのキャッシュラインサイズが32Byteのため、
｢32バイトごと」かつ｢アドレスの32バイトに当たる下位5ビットが0x0_0000｣であること
が求められます。

過去にSTM32F7でキャッシュ比較したときはあらかじめDMA先を32バイトの境界に
合わせ4kByte刻みで転送という限定的な環境でやってたのでキャッシュコントロールは
かなり端折った記述をしておりましたが今回は腰を据えて汎用的に扱えるよう
落とし込んて行きます。



●DMAで読み取る場合(SDMMCのIDMAの場合)
実はライトバック設定の場合、READの取り扱いが一番やっかいです。
理論的には読み出し先のメモリのキャッシュをInvalidateしてやればよいはずなのですが
なぜかそうは問屋が卸さず、私が試した限りでは必ずCleanもしなけらばならないことが
分かりました?なんでだＹＯ！

DRESULT SD_read(BYTE lun, BYTE *buff, DWORD sector, UINT count)

{

	DRESULT res = RES_OK;

    uint32_t timer = SysTick->VAL + SD_DATATIMEOUT;



    /* first ensure the SDCard is ready for a new operation */

    while((SD_GetCardState() == SD_TRANSFER_BUSY))

    {

		if(timer < SysTick->VAL)

		return RES_NOTRDY;

    }



#if defined(SD_DMA_MODE) && !defined(SD_POLLING_MODE)

    /*

       Force Cache Data Lines content write back to memory and Invalidate them.

       Someone (CPU) might be still accessing those cache lines so we need to

       flush/clean recent content to memory and purge/invalid cache lines before

       allowing Hardware to access RAM.

     */

    SCB_CleanInvalidateDCache_by_Addr((uint32_t*)buff, count * SECTOR_SIZE);



	if((uintptr_t)buff & 0x3)	/* Check 4Byte Alignment */

	{	/* Unaligned Buffer Address Case (Slower) */

		for (unsigned int secNum = 0; secNum < count ; secNum++){



			SCB_InvalidateDCache_by_Addr ((uint32_t*)dmabuf, SECTOR_SIZE);



			if(SD_ReadBlocks_DMA((uint32_t*)dmabuf, (uint32_t)(sector+secNum), 1)!= MSD_OK)

			{

				MSG_PRINTF("Read error on unaligned buffer¥n");

				res = RES_ERROR;

			}



			memcpy(buff+secNum*SECTOR_SIZE, dmabuf, SECTOR_SIZE);

		}

	} else {

		/* Aligned Buffer Address Case (Faster) */

		if(SD_ReadBlocks_DMA((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)

		{

			MSG_PRINTF("Read error on DMA¥n");

			res = RES_ERROR;

		}

	}

#else

	if(SD_ReadBlocks((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)

	{

		MSG_PRINTF("Read error on polling¥n");

		res = RES_ERROR;

	}

#endif

	return res;

}

↑CMSIS_v5を使ってSTM32H7でDMA転送(READ)する場合です。
READアクションをとる前にSCB_CleanInvalidateDCache_by_Addr()を実行します。
Invalidateだけではだめです。CleanしてInvalidateです。ここテストに出るので
覚えておきまししょう!そうせざるを得なかった例がこちらの議論にもありますが正直
私もピンときません。だれか詳しい解説を教えてください。
当たり前ですがデータが32Byteの倍数かつ32Byte境界にﾋﾞｯﾁﾘそろった完全読み出し
専用のメモリ領域ならInvalidateだけで問題ないです。ぇ？自分で答え言ってるだろ
って？ねむいさんは他の人の同意とか同情がほしいのですよぅ！
ぁあそうだ、ライトスルーもInvalidateだけでおｋ、エラッタでどうせ使えませんが。

それと上記のルーチンでは先の述べたアドレスの丸め込みがないじゃないかと思う
方がいると思いますがCMSIS_v5ライブラリのほうに丸め込み処理が取り込まれており、
ｺﾞﾃｺﾞﾃしたマクロ組まなくてもシンプルに記述できるようになっています。
STマイクロのCubeライブラリではこちらの更新がまだ取り入れられておらず、自前の
アドレス丸め込みマクロが記述されておりますので二度手間にならないようにご注意
願います。

そんでもってCleanInvalidateしたことによるキャッシュコントロールによるオーバー
ヘッドが懸念されますがH7はCPUのコアの速度が480MHzも出るので多分気には
ならないとおもいます(投げやり)



●DMAで送信する場合(SDMMCのIDMAの場合)
DRESULT SD_write(BYTE lun, const BYTE *buff, DWORD sector, UINT count)

{

	DRESULT res = RES_ERROR;

    uint32_t timer;





#if defined(SD_DMA_MODE) && !defined(SD_POLLING_MODE)

    /*

       Force Cache Data Lines content write back to memory.

       Someone (CPU) might be still accessing those cache lines so we need to

       flush/clean recent content to memory before

       allowing Hardware to access RAM.

     */

    SCB_CleanDCache_by_Addr((uint32_t*)buff, count * SECTOR_SIZE);



	if((uintptr_t)buff & 0x3)	/* Check 4Byte Alignment */

	{	/* Unaligned Buffer Address Case (Slower) */

		for (unsigned int secNum = 0; secNum < count; secNum++){



			memcpy(dmabuf, buff+(SECTOR_SIZE*secNum), SECTOR_SIZE);



			SCB_CleanDCache_by_Addr((uint32_t*)dmabuf, SECTOR_SIZE);



			if(SD_WriteBlocks_DMA((uint32_t*)dmabuf, (uint32_t)(sector+secNum), 1) != MSD_OK)

			{

				MSG_PRINTF("Write error on unaligned buffer¥n");

				res = RES_ERROR;

			}

		}

	} else {

		if(SD_WriteBlocks_DMA((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)

		{

			MSG_PRINTF("Write error on DMA¥n");

			res = RES_ERROR;

		}

	}

#else

	if(SD_WriteBlocks((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)

	{

		MSG_PRINTF("Write error on polling¥n");

		res = RES_ERROR;

	}



#endif



	/* ensure the SDCard is ready for a next operation */

	timer = SysTick->VAL + SD_DATATIMEOUT;

	res = RES_ERROR; /* Timeout */

	/* block until SDIO IP is ready or a timeout occur */

	while(timer > SysTick->VAL)

	{

		if(SD_GetCardState() == SD_TRANSFER_OK)

		{

			res = RES_OK;

			break;

		}

	}



	return res;

}

↑CMSIS_v5を使ってSTM32H7でDMA転送(WRITE)する場合です。
WRITEのほうは単純明快、転送前にCleanしてやるだけです！
READのほうが扱いがめどくて誤れば致命的なのがなんとも…


ちなみにSTM32のマイコンにおいてREAD/WRITEいずれの場合もDMAコントローラのWORD
(4Byte)制限があるのでそれも加味しておきましょう。



●DMAで送信する場合(SAIのCircularDMAの場合)
ライトスル―が使えなくなったせいでいろんなコードにキャッシュコントロールを
突っ込まざるを得なくなってしまいましたがねむいさんのいつものではAudio再生に
SAIのCircularDMAを使用しており、こちらもきっちり対策しております。

ねむいさん最初にH7触った時に無対策で挑んで見事返り討ちに会いました。サンプル
音源のBeachBoysのハーモニック・サウンドがﾌﾞﾋﾞﾋﾞﾋﾞｯﾌﾞｯというげりうんちみたいな
汚い音が得られてしまったのですが移植時にcodecの音量設定が最大になっていたのも
気づかずげりうんち音で鼓膜が破壊されるかと思いましたがどうでもいいですね。


SAIの場合はWrite専用のぶっぱなのでCleanだけで問題ないです。
問題は挿入する箇所です。

/* on the first buffer fill up,start the dma transfer */

	if(EVAL_AUDIO_Init(OUTPUT_DEVICE_BOTH, DEFAULT_VOLUME, (uint32_t)mp3FrameInfo.samprate))

	{

		MSG_PRINTF("Mp3Decode: audio init failed¥r¥n");

		nResult = -4;

		break;

	}

	/* I2S DMA Transfer First Trigger */

#if defined(STM32H7XX)

	SCB_CleanDCache_by_Addr((uint32_t*)g_pMp3DmaBuffer, MP3_DMA_BUFFER_SIZE);

#endif

	/* Needed to AAC_DMA_BUFFER_SIZE*2,16-bits audio data size(2Byte) */

	/* See more detail,BSP_AUDIO_OUT_Play()							  */	

	EVAL_AUDIO_Play(g_pMp3DmaBuffer, MP3_DMA_BUFFER_SIZE*2);

↑転送なのでCleanのみでおｋ(mp3.support.cにて)
まずはCircularDMAの最初のキックです。まぁこれは当然。
ていうかなんかtypoしてますね私orz AACじゃなくてここではMP3です。
if(unDmaBufMode == INIT_RINGBUF || unDmaBufMode == FULL_RINGBUF)

{

	/* Check FirstHalf Transfer in LastHalf and BufferInit Mode */

	if(em & TRANSFER_FIRST_HALF)

	{

		MSG_PRINTF("Mp3Decode: DMA out of sync (expected TC, got HT)¥r¥n");

		nResult = -3;

		break;

	}

	else{

		g_pMp3DmaBufferPtr = g_pMp3DmaBuffer + (MP3_DMA_BUFFER_SIZE/2); /* 16bit address pointer calc */

	#if defined(STM32H7XX)

		SCB_CleanDCache_by_Addr((uint32_t*)g_pMp3DmaBufferPtr, MP3_DMA_BUFFER_SIZE);

	#endif

	}

}

else /* unDmaBufMode == HALF_RINGBUF */

{

	/* Check LastHalf Transfer in FirstHalf Mode */

	if(em & TRANSFER_LAST_HALF)

	{

		MSG_PRINTF("Mp3Decode: DMA out of sync (expected HT, got TC)¥r¥n");

		nResult = -3;

		break;

	}

	else{

		g_pMp3DmaBufferPtr = g_pMp3DmaBuffer;

	#if defined(STM32H7XX)

		SCB_CleanDCache_by_Addr((uint32_t*)g_pMp3DmaBufferPtr, MP3_DMA_BUFFER_SIZE);

	#endif

}

お次はこちら。
半分転送完了割り込み後の処理で次の転送予定のバッファにCleanをかけます。
g_pMp3DmaBufferPtrに次に転送するバッファのアドレスをコピーした後Cleanです。
g_pMp3DmaBufferPtrはuint16_tのポインタなので注意が必要です。


●DMAじゃないけどLTDCもキャッシュと競合する
ライトスルーが使えなくなった弊害はDMAと同じくキャッシュコヒーレンシーを
求められるLTDCにも波及します。

static void disp_blt (

	int left,				/* Left end (-32768 to 32767) */

	int right,				/* Right end (-32768 to 32767, >=left) */

	int top,				/* Top end (-32768 to 32767) */

	int bottom,				/* Bottom end (-32768 to 32767, >=right) */

	const uint16_t *pat		/* Pattern data */

)

{

	int yc, xc, xs;

#if !defined(USE_TFT_FRAMEBUFFER)

	int xl;

	uint16_t pd;

#endif



	if (left > right || top > bottom) return; 	/* Check varidity */

	if (left > MaskR || right < MaskL  || top > MaskB || bottom < MaskT) return;	/* Check if in active area */



	yc = bottom - top + 1;			/* Vertical size */

	xc = right - left + 1; xs = 0;	/* Horizontal size and skip */



	if (top < MaskT) {		/* Clip top of source image if it is out of active area */

		pat += xc * (MaskT - top);

		yc -= MaskT - top;

		top = MaskT;

	}

	if (bottom > MaskB) {	/* Clip bottom of source image if it is out of active area */

		yc -= bottom - MaskB;

		bottom = MaskB;

	}

	if (left < MaskL) {		/* Clip left of source image if it is out of active area */

		pat += MaskL - left;

		xc -= MaskL - left;

		xs += MaskL - left;

		left = MaskL;

	}

	if (right > MaskR) {	/* Clip right of source image it is out of active area */

		xc -= right - MaskR;

		xs += right - MaskR;

		right = MaskR;

	}

	Display_rect_if(left, right, top, bottom);	/* Set rectangular area to fill */

#if defined(STM32F7XX) || defined(STM32H7XX) /* Flush Cache Datas */

	SCB_CleanDCache_by_Addr((uint32_t*)pat, xc*yc*2);

#endif

#if defined(USE_TFT_FRAMEBUFFER)

	Display_wr_block_if((uint8_t*)pat, xc*yc);

#else

	do {	/* Send image data */

		xl = xc;

		do {

			pd = *pat++;

			Display_wr_dat_if(pd);

		} while (--xl);

		pat += xs;

	} while (--yc);

#endif

}

↑ts_fileload.cにて
Cha'N氏のTinyJPEGライブラリででコード後のデータをブロック転送するときにClean
しないと化けます。DMA2DだけじゃなくCPUが介在するFIFOコピーでも化けます。

大量のデータを一気に吐かせるimgファイル(動画データ)ならその都度キャッシュも
総入れ替えとなるので化けないようですが中途半端に転送サイズが小さいとだめな
ようですね。本来なら動画再生のほうもClean突っ込んでやるのが筋なんですけど。

なお、前回触れたライトアロケートキャッシュ設定にしてしまった場合は逆汚染に
よってせっかく書き込んだデータが潰されてしまうためデータの書き込み都度に
Cleanをしてやらないといけなくなってしまいこれによるオーバーヘッドで見かけの
処理速度が大きく落ちてしまいます。
前回も言いましたがSAIでもビットレート上がるとﾌﾟﾁﾌﾟﾁノイズ入りまくり使い物に
なりませんしやはりSTM32でライトアロケート設定は使わないのが無難です。






というわけで癖が非常に強いSTM32H7ですが、その特性を把握して上手に
コントロールすれば本来の性能をいかんなく発揮できることがわかりました。
STM32F7で十分と思い、食わず嫌いしてましたがSTM32H7、良い感じです！

Go to top of page