GNSSモジュールを試用する16 -みちびき3号機打ち上げ成功記念-

2013年中盤より長らく使ってまいりましたGms-g9(のちにTitan3と改め)ですが今春に
製造元のGlobalTop社がSierraWirelessなるIoTな会社に吸収される運びとなり、web上
から急速にGms-g9に関するリソースが失われる事態となっております。

ランエレさん取り扱いの製品ページにもカスタムファームの作成サポートが終了したとの
報があり、Gtop社消滅の影響が見られます。尤もモジュール単体の流通在庫は世界に
相当数あるようで新規に購入したい人は2020年くらいまでは困らないかと思います。

一応20170831現在はまだGtop時代のデータはレガシー扱いでSierraのサイトに残され
ていますが今後無慈悲に削除される事は十二分に考えられますので早いうちに確保して
おきましょう！
既にAGPSやlocasのデータ・ダウンロードツール"GPS Viewer"は消滅してしまいましたが
もしAGPSの機能を使いたいと思われる方はねむいさんに泣きついたら何とかなるかも
しれませんよぅ。

AGPS用のgtopの鯖は一応まだ生きているらしく、当分の間はGms-g9のAPGS機能を利用
出来そうです(使わなくとも補足性能ものすごい良いですけど)




さて、話は変わりますが8月半ばに我が国が誇る準天頂衛星システムみちびきの3号機
が宇宙に無事に打ち上げられました。既に稼働中の初号機・2号機とは違い3号機は
静止軌道衛星となっております。GPS補完信号の発信はまだのようですが首尾よく
行けば来年にはこちらの恩恵にもあずかることができるようになるとおもいます。

というわけで稼働具合を確認すべくねむいさんのGNSSTr@ckerのファームを衛星IDの
情報を得られるGPGSV,GLGSVセンテンスを記録できるように改修し実際のフィールドで
動作検証をおこないました！場所は近畿自然歩道山陽路るーｔ…
おいこらそこ！寝ない！！！！ここからが本番ですよぅ！！


●近畿自然歩道(春日山・日光寺山)
｢福崎　春日山散策のみち(神姫バス南山田バス停〜神姫バス西大貫バス停)｣
｢柳田国男のふるさとを歩くみち(神姫バス西大貫バス停〜JR播但線福崎駅)｣


今夏は青春18切符を駆使して微妙な距離にある近畿自然歩道のルートを開拓すべく
挑みました。現在兵庫県下の４区間まで進めましたが行く先々で灼熱のアスファルトが
おで迎えしてくれてねむいさんも辟易です。まぁ真夏だから仕方ありませんね〜
二度とこんなことやりません
まだ18切符ラリーは終わっておらず準備の時間も押してるのでささっと紹介させて
もらいますよぅ〜



スタート地点のJR播但線香呂駅です。ほんとのスタート地点は神姫バスの南山田バス停
ですがバスの便が全くなく役立たずのため香呂駅から走ってスタート地点まで向かう
羽目になります。ていうか兵庫県の近畿自然歩道はこんなんばっかりです☠


文明の利器に頼れないとなると己の肉体を信じて走るしかない･･･！！
丁度曇ってくれて直射日光がさえぎられ、ちょっとだけ助かりました。


南山田バス停です･･･ようやく近畿自然歩道スタート！


この時期のトレイルはこんな超藪がたびたび出現しやがります☠


かつて山城があった春日山山頂です。
正式には飯盛山と言います。


まだ厳しい暑さが続く夏なのですが写真では分かりづらいですが赤とんぼが飛び交い
季節は確実に秋になっているのが分かります･･･


嶺雲寺でお水を貰おうと思ったら小さな先客さんが♪


戦没者を祭る慰霊塔です。
次は絶対に勝ちまする！！！！！


中間点の西大貫バス停･･･のつもりでしたが途中から完全に姿を表した
お日様のせいで頭がぼけたのか南大貫バス停が中間点とかん違いしてしまい
30分くらいルートミス･･･orz


クソァ！！！
さぁ気を取り直して
後半戦です！１！！！


大善寺です。このうらの裏山を越えていきます。


しかし･･･次の分岐で道を見失ってしまい、
仕方なく林道最高地点から日光寺の稜線を手繰る強行突破を敢行しました！！


そして林道最高地点です･･"日光寺散策駅"なる道標があり、その背後にある
ごく薄い踏み後を頼りに日光寺山山頂にある電波塔めがけて突破します！！！


はぁはぁ･･･真夏に藪コキするはめになるとわ･･･
何とか日光寺山山頂と電波中継塔につきました･･･
ここまで来ればもう安全･･･


日光寺より福崎方面の景色です･･･
暑すぎてちょっと霞が掛かってますが眺めは最高･･･♪
日光寺から先は全て舗装路で駆け下りるように柳田国男の生家を目指します！


柳田国男を家族の胸像がある辻川山の展望台です。
そろそろ日も傾いてきました。


柳田国男の生家です。一帯は神社やお寺、旧役所などに囲まれています。


一旦JR播但線を渡り福田大歳神社に。夏祭りの盆踊りの準備が進められていました。
祭り囃子が威勢良く聞こえています。


JR福崎駅に到着です。近畿自然歩道のゴールはここですがまだ･･･
･･･ん･･･？


････？？？？？？


ねむいさんの真のゴールは福崎駅から少し北東に向かった先にある
福ふく温泉薬師の湯です♥ここだけは入念に下調べしておりました♥


しかも丁度割引ＤＡＹでした！！なんと運が良い私♥


温泉をたっぷり堪能した後は京都へ帰還します。
姫路駅からは新快速で京都まで一発です☆



というわけで日光寺周辺では思わぬアクシデントがありましたがすばやいプランの
建て直しと十分な装備のおかげで切り抜けて無事走破できました！
前途の通り18切符は残り一回分あるので無駄にしないようにしっかり使いこなして
いきたいと思います！


そして肝心のログのほうですが今回はロガーに衛星IDを示すGPGSV,GLPSVセンテンスも
記録してますのでみちびき2号機が受信されていたらIDに194が･･･

ぁあ･･･ぁらら･･･？
2号機を示す194はおろか193すら全く受信されていませんでしたorz
17時くらいには福崎駅周辺にいたから194がど真ん中にいたはずなのですが･･

8/31に西院で受信チェックしてみたらちゃんと193は見えたのですが真上まで来ないと
受信強度が全く確保できない状態になってました･･･ううむ･･･

これはもう一回りべんぢの必要がありますね〜〜〜〜！！

いろいろ試す29

やばいっす･･･もう8月ですよぅ･･･
例のDropBox画像差し替えの進捗状況ですがここ最近のSTM32関連はほぼ修正が
終了し、これから過去の東海自然歩道関連の膨大な差し替え作業が待っております
･･･
これが一番きついかもしれませんが今が耐え時、がむばります！



●村田製作所が1uF未満の1608サイズのチップコンデンサ作るの止めるってよ
ねむいさんのぶろぐを見られている諸兄の方々なら7月第2週の初頭の時点で既にご
存知とは思いますが･･･ねむいさんもこの報を聞き"品の悪いギャグだ"と思っていま
したが詳細な説明を聞くにあたりマジになっているのが分かりました。

2017年現在、スマホが隆盛を極めておりますがそれに使用される0603サイズ以下の
チップセラコン大大大増産に対応するため1608用のラインを廃止することに決定
したそうです。一応2018年上旬までは発注に対応するそうですが納期がかなり掛かる
ことが必須で引いては村田製作所以外のメーカの製品の模索、ロットの確保のため
の争奪戦が既に始まっている次第です。

国産かつ信頼性という点で日本国内では村田が抜きん出でていましたがここにきての
生産終了予告に国内のメーカ、特にダウンサイジングが進んでいない工業用製品の
メーカとかは超困るはずなのですが容赦なくぶった切られております。切られました。
ちなみにNintendo Switchを販売し飛ぶ鳥を落とす勢いの任天堂すらも情け容赦なく
切られてしまった、と、世の趨勢はそれ程スマホの生産競争に向かっている、と、
桂川のほとりで昼寝をしていた猫が嘆いていました。上二行はねむいさんのコメント
では無くあくまでも桂川のほとりで昼寝をしていた猫のOpinionなので悪しからず。

で、代替品ですが国内ではやはり2012サイズはもちろんの事1608の品種はどこも生産
から撤退しており(1uF以上は除く)海外メーカから調達するしかないのが現状のです。
ねむいさん的には釜屋電機が国内ディストリビューターとなっているWalsin製の物が
丁度隙間産業的に村田の抜けた穴を埋めるのではないか？と予測しております。
電子製品の米とも言える最も大量に使用されているバイパスコンデンサ用の0.1uFの
物が村田が去った後どこが日本国内のパイを掻っ攫っていくのか？
ものの一年もすればその答えが分かると私は予測します。
ていうか1005サイズも量産が続くかどうか怪しいです。これもしっかり対策立てて
おいたほうがよいと思います。基板を0603で起こしなおすか、代替メーカを探すか。

そしてホビイスト的な観点からすれば現在秋月に流れている1uF以下の村田製の奴
は(1608サイズ自身が怪しいですが)2020年にはほぼ消失し、別の会社の製品がライン
アップに収まるはずです。まぁホビー用途なら信頼性の保証は自分もちなので自分が
信ずるモノならばなに選んでも自己責任で終わる話だと思います。


●GNU Tools for ARM Embedded Processorsが定期バージョンアップ
7月頭にARM本家から配布されるようになったARMむけGCCコンパイラが"The 6 2017q2"
にアップデートしておりました。前回からの目だった変更点は･･･

* Advanced SIMD-optimized memchr implementation in newlib
くらいでしょうか？purecodeが実装されてから効率がさらに良くなった感がしますが
いつもののコードを使ってとりあえずビルドログの新旧比較してみました。

Built Informations:

USING_SYSTEM = BARE_METAL

USING_DISPLAY = USE_OTM8009A_DSI_TFT

USING_DEVBOARD = USE_STM32F769I_DISCOVERY



Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 726616	      0	 726616	  b1658	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 724016	   2600	2379504	3106120	 2f6548	main.elf

main.elf  :

section               size         addr

.text              0xb0ba8    0x8000000

.ctors                 0x0    0x80b0ba8

.dtors                 0x0    0x80b0ba8

.ARM.exidx             0x8    0x80b0ba8

.data                0xa28   0x20020000

.itcm                 0x80          0x0

.bss                 0xb20   0x20020a28

.heap                  0x0   0x20021548

.dtcm              0x10454   0x20000000

.stack                 0x4   0x20010454

.ethram                0x0   0x2007c000

.batram                0x0   0x40024000

.extram           0x233f78   0xc0000000

.qspirom               0x0   0x90000000

.comment              0x7f          0x0

.debug_aranges      0x3fd8          0x0

.debug_info       0x141d2c          0x0

.debug_abbrev      0x1d619          0x0

.debug_line        0x48aa5          0x0

.debug_frame       0x12d58          0x0

.debug_str         0x18c38          0x0

.debug_loc        0x10b358          0x0

.ARM.attributes       0x35          0x0

.debug_ranges      0x176c8          0x0

Total             0x5f076e
新(arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437])
Built Informations:

USING_SYSTEM = BARE_METAL

USING_DISPLAY = USE_OTM8009A_DSI_TFT

USING_DEVBOARD = USE_STM32F769I_DISCOVERY



Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 726952	      0	 726952	  b17a8	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 724352	   2600	2379504	3106456	 2f6698	main.elf

main.elf  :

section               size         addr

.text              0xb0cf8    0x8000000

.ctors                 0x0    0x80b0cf8

.dtors                 0x0    0x80b0cf8

.ARM.exidx             0x8    0x80b0cf8

.data                0xa28   0x20020000

.itcm                 0x80          0x0

.bss                 0xb20   0x20020a28

.heap                  0x0   0x20021548

.dtcm              0x10454   0x20000000

.stack                 0x4   0x20010454

.ethram                0x0   0x2007c000

.batram                0x0   0x40024000

.extram           0x233f78   0xc0000000

.qspirom               0x0   0x90000000

.comment              0x7f          0x0

.debug_aranges      0x3fd8          0x0

.debug_info       0x141e1b          0x0

.debug_abbrev      0x1d619          0x0

.debug_line        0x48aa5          0x0

.debug_frame       0x12d58          0x0

.debug_str         0x18c3d          0x0

.debug_loc        0x10b365          0x0

.ARM.attributes       0x35          0x0

.debug_ranges      0x176c8          0x0

Total             0x5f09bf
古(arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors 6-2017-q1-update) 6.3.1 20170215 (release) [ARM/embedded-6-branch revision 245512])
text領域が若干絞られていますね。


mapファイルを比較してみるとvprintf関連が若干異なるようです。
これが"Advanced SIMD-optimized memchr"の成果かも知れませんね。

新

旧
jpegファイルレンダリング比較行ってみましたがパフォーマンスにも余り影響は
無いみた･･･あっ！
なんか旧版だとxprintf使った表示がおかしくなってる！！



･･･と思ったらuSecタイマーで使用してるTIM5の最上位ビットを"UIF bit"のコピーと
して使用する設定になっていてCNTレジスタの値が変に読み出されていただけでしたorz
なんという罠orzこれSTM32F7特有の機能みたいですorz今まで気付かなかったorz
新板でもリセット後経過時間次第で同様の表示不具合が出ることを確認orz
ていうかデータシートしっかり読んでなかった事が露呈しました･･･猛省･･･。
8月1日版のF7向けサンプルでは修正しておきますのでよろしくお願いします。


新

旧
改めて新旧比較･･･
やっぱしパフォーマンスにも余り影響は無いみたいですね〜〜

●A1クラスのmicroSDカードの実力を試す



ボーナスとか言うものはなかったですけど費用を捻出してねむいさんもついに手に
入れましたA1 Class対応のmicroSDカード！！！
もちろんVideo規格のV30にも対応した最新版です！！！

それでは早速いつものカード情報を抜き出して見ました。
●Sandisk　ExtermePRO microSDHC 32GB SDSQXCG-032G-GN6MA
FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Jul 17 2017

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 19632 kB/sec.

>ds 0

rc=0

Drive size: 62333952 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 00 ED C8 7F 80 0A 40 40 C3 @..2[Y.......@@.

CID:

00000000  03 53 44 41 47 47 43 44 80 61 BB 43 93 01 16 03 .SDAGGCD.a.C....



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :AGGCD

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x61BB4393

DateCode.Month     :6

DateCode.Year      :2017



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 04 00 90 00 0F 05 3A 1E ..............:.

00000010  00 08 00 00 00 01 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 84 43 00 00 00 00 .5.C....



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :1

SD Security        :3

SD Bus Width       :5



SD_Spec V5.xx!

Detected as SDHC Card!

Available UHS-I Mode.

>

2017年6月製の出来立てﾎﾔﾎﾔカードです♥
SD_Spec V5.xxとなっており、後々販売される"A2 Class"のカードではV6.xxに上がる
見込みとなっています。連続読み出しもそこそこ早いですね〜。


ちなみにA1 Class(Application Performance Class 1)はランダムアクセスリード及び
ランダムアクセスライトの下限値が定められており、スマホなどのストレージの細かい
ファイルの読み書きに特化した規格となっています。つまりﾁﾏﾁﾏ読み書きに強いカード
を証明する規格な訳です。


それを確認するために今度はPCからベンチマークを取ってみました。
そして･･･

･･･
なんか4kランダムライトが異様におそいんですけぉ･･･

それじゃ昨年購入したV30表記のみのカード(SDSQXVF-032G-GN6MA)

･･･
ﾁﾏﾁﾏ書きめッちゃ早いやん･･･PROじゃないほうのExtremeなのに･･･

じゃ･･･じゃぁ2012年に購入した8GBの昔のExtreme(SDSDQXP-008G-J35)!

･･･
ﾁﾏﾁﾏ書きめッちゃ早いやん･･･PROじゃないほう(ry

ちなみに測定に使用した機材は全て同一の物なので相対的に性能が評価される
ため、リーダの性能が云々とかは理由に出来ません。もちろんテスト前にSD Formatter
のクイック削除で更地にした上で測定を行っております･･･


･･･
ま、まぁ直線番長度合いは旧版のカードと比べて仏契(ぶっちぎり)ですし多分ベンチ
ソフトじゃみえてこない所の･･･ぇっと体感速度とかのパフォーマンスが沢山アップ
しているのかも知れませんと思いたいです(脂汗)

Kinetis KEシリーズを使う

先月に引き続き温め過ぎて腐っちゃったシリーズ第2弾いきます！



元はFreeScle社製でしたがNxPに喰われさらにQualcommに丸ごと喰われてしまう予定で
すが+5V動作可能なARMマイコン、Kinetis-Eシリーズは現在も順調に展開されております。
(ていうか今のラインナップ5Vで168MHzで動くM4コア製品まで拡張されてるのか…)

今回はその最初期にリリースされたKE02シリーズとその評価ボード(以下FRDM板)を紹介
させてもらいます。
ボードの背後でいないさんが何かを主張していますが気にしないでください★


もともとノイズの多い環境でノイズ耐量を得る目的として開発されたマイコン故に+3.3V
動作はもちろんの事+5Vでも動きますがそれ故に動作周波数は当時はM0+コアの中でも
特に低く、AVRと同じ20MHz動作が上限となっています。
内蔵Flash/SRAMも其々最大64kB/4kBとささやかものとなっています。


当時はまだFreeScale預かりだったのでサンプルコードもKLシリーズとかよりもさらに
適当な奴しかなく、Keilのu'Visionに収録されたサンプルコードやヘッダファイルを
参考にGCC向けにプロジェクトを落とし込んでみました。


基本的なMCUアーキテクチャは従来のKinetisと全く同じなので不用意な書き換えですぐにBricked
ってしまう問題も健在です☠


KEシリーズのフラッシュ書き込み機構は従来とは違い、レジスタ構成がまったく別のもの
になっているのでOpenOCDのフラッシュ書き込み用のソースは他のKinetisシリーズとは
別のものになっています。ねむいさん評価報告やっただけだけですけどなんでか知らなんのです
けどソースの作者名に名前連ねてもらっています。ありがとうございます。

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/jlink_swd.cfg -f target/kexx_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.10.0+dev-00161-g1725abc-dirty (2017-06-23-00:33)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.org/doc/doxygen/bugs.html

swd

Info : add flash_bank kinetis_ke kexx.pflash

cortex_m reset_config sysresetreq

none separate

adapter speed: 1000 kHz

Info : No device selected, using first device.

Info : J-Link OpenSDA 2 compiled Oct 13 2015 12:10:56

Info : Hardware version: 1.00

Info : VTarget = 3.300 V

Info : clock speed 1000 kHz

Info : SWD DPIDR 0x0bc11477

Error: MDM: failed to read ID register

Error: MDM: Failed to check security status of the MCU. Cannot proceed further

in procedure 'init' called at file "C:/Devz/ARM/OCD/tcl/target/kexx_swd_flash.cfg", line 125

in procedure 'ocd_bouncer'



Info : SWD DPIDR 0x0bc11477

Info : kexx.cpu: hardware has 2 breakpoints, 2 watchpoints

Info : MDM: Chip is unsecured. Continuing.

target halted due to debug-request, current mode: Thread 

xPSR: 0x21000000 pc: 0x000000cc msp: 0x20000c00

Info : Watchdog stopped

auto erase enabled

Info : KE02 sub-family

Info : Flash clock ready

Warn : flash configuration field erased, please reset the device

Info : Flash clock ready

Info : Kinetis KE: FLASH Write ...

wrote 8192 bytes from file main.elf in 0.734375s (10.894 KiB/s)

verified 7936 bytes in 0.093750s (82.667 KiB/s)

Info : MDM: Chip is unsecured. Continuing.

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:01
OpenOCDでフラッシュ書き込みした時のログはこんな感じです。

かつて幾つかのKinetisの品種では通常のreset initで繋ぎに行くとウォッチドッグ
リセットが発動し、上手くhaltしないと言う問題があってちょっとトリッキーなcfgを
組む必要があったのですが最近のコミットでソースコードそのものとcfgとで連携して
ひとまずウォッチドッグを止めに行く措置が取られ、ほぼすべてのKinetisの品種で
安定して書き込み・デバッグができるようになりました。

ちなみにFlexRAMやFlexNVMを設定している場合でもコケないで正しく書き込みが
出来るようにも修正されています。数年前はかなり危ない実装だったんｽね…

FRDM板の標準デバッガはOpenSDAですがはっきり言ってあまり使えないので速攻
J-Linkに差し替えてしまいましょう！上記ログもJ-Linkで繋ぎにいったものとなって
います！


JLinkのファームに書き換えるとmbed対応済の証であるマスストレージが見えます。
ちゃんとドライブラベルもJLinkになってて芸が細かいですね。使いませんけど。


ちなみにねむいさんのこさえたプログラムはLED点滅をしながら…


FRDM板上にある速度センサの値をprintf関数で返すという評価板の機能フルに利用
したものとなっております☆
尤も冒頭で述べたとおりこのボードで使用されているKE02ZはKEシリーズの最初期
の品種でコアクロック上限が20MHzまでとなるのでUARTのボーレートもねむいさん
標準の230400bpsではさすがに無理で115200bpsに落としています。

最初購入した当初はノイズ云々はサブ的なものでホントは8bitな+5Vマイコンの置き
換え狙いかと思っていましたが2017年現在では168MHzで動くCortex-M4の品種にも
拡大されておりノイズに厳しい環境下での使用をマジで狙ったものとなっているようです。
私も興味が出てきましたのでM4コアの奴が手に入ったらまたレポートさせて頂きます！

いろいろ試す28

おいおいついにGW来たと思ったらもう一ヶ月経っちまいましたよどういうことだYO!

●STM32L0シリーズを使う

数年前に買ったのですけど暖めすぎて腐っちゃいましたてへ♥


STM32L0シリーズはCortex-M0+をコアに持つ低消費電力特化型のARMマイコンとなって
おります。
この評価ボードSTM32L0538-Discoveryも低消費電力に特化した作りとなっています。

主役のSTM32L0は基板裏面にあります。


目玉はこの電子ペーパーです。電源を切っても表示内容が保存されるという優れもの
ですが通常のドットマトリクス液晶のように簡単には扱えずかつ画面書き換えも長い
時間掛かるのでもっぱら静止画表示に留めておくのがまともな使い方といえます。
L0シリーズ初期のSTM32L053C8が使用されております。


この電子ペーパーのドライバにはSTM32L152が使用されてたりします。


こちらが表示して２ヶ月経過した後の画面です。電源を落としても表示内容が保た
れるのですが時間の経過と共にやはり薄れていきます。おもなターゲットとされて
いる店舗の価格表示板での使用を考えたら十分すぎる保持時間ともいえます。
でも白黒なのはウケるのでしょうか？？？？あとはテキストリーダー用途とか？？

フリーの開発環境から使う場合はおなじみOpenOCDで内蔵フラッシュに書き込みます。
※L0シリーズはかなりクロック落とさないとコケまくります。気を付けてください。

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd  -s C:/Devz/ARM/OCD/tcl -f target/stm32l0discovery_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.10.0+dev-00143-gf6449a7-dirty (2017-05-20-14:25)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.org/doc/doxygen/bugs.html

adapter speed: 300 kHz

adapter_nsrst_delay: 100

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

none separate

srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Info : Unable to match requested speed 300 kHz, using 240 kHz

Info : Unable to match requested speed 300 kHz, using 240 kHz

Info : clock speed 240 kHz

Info : STLINK v2 JTAG v28 API v2 SWIM v18 VID 0x0483 PID 0x374B

Info : using stlink api v2

Info : Target voltage: 3.240553

Info : stm32l0.cpu: hardware has 4 breakpoints, 2 watchpoints

Info : Unable to match requested speed 300 kHz, using 240 kHz

Info : Unable to match requested speed 300 kHz, using 240 kHz

adapter speed: 240 kHz

target halted due to debug-request, current mode: Thread 

xPSR: 0xf1000000 pc: 0x08002148 msp: 0x20002000

STM32L0: Enabling HSI16

Info : Unable to match requested speed 2500 kHz, using 1800 kHz

Info : Unable to match requested speed 2500 kHz, using 1800 kHz

adapter speed: 1800 kHz

adapter speed: 1200 kHz

auto erase enabled

Info : Device: STM32L0xx (Cat. 3)

Info : STM32L flash size is 64kb, base address is 0x8000000

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000000e msp: 0x20002000

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000000e msp: 0x20002000

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000000e msp: 0x20002000

wrote 16384 bytes from file main.elf in 3.218750s (4.971 KiB/s)

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20002000

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20002000

verified 16096 bytes in 0.140625s (111.778 KiB/s)

Info : Unable to match requested speed 300 kHz, using 240 kHz

Info : Unable to match requested speed 300 kHz, using 240 kHz

adapter speed: 240 kHz

adapter speed: 1200 kHz

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:04

書き込み時のログはこんな感じです。
ねむいさん謹製STM32L0デバイス向けフラッシュ書き込み用cfgはねむいさんのOpenOCD
バイナリにもちろん収録済みです！

L0シリーズのフラッシュ書き込みは数年前からOpenOCDに対応していたのですが1Word
ごとのﾁﾏﾁﾏ書きしか対応しておらずねむいさんも｢使えねぇ！｣と判断して肥やしに
しておりましたが今年になってようやくマイコン側ローダーのソースが見直され、
まともに使用できるようになりました。
ちなみ何故そうなってしまったかというとCortex-M3シリーズのSTM32L1シリーズと
フラッシュ書き込み用コードと同じ扱いにしてしまったせいでM0+で使用不可能な
M3の命令がローダのバイトコードとして使用されてしまっていたからなのでした。

ねむいさん当時はNuvotonやKinetisのサポートに躍起になっていたのでSTM32に
関しては簡単なコードの追加程度しかコミットできなかったのですが細かい事
考えたら先にすすめませんのでとりあえずどんどん活用していこうと思います。
いずれはNuvotonもローダのコード見直したいですね〜。

というわけでおきぱのラインナップに追加しましたのでよろしくお願いします！
おなじみのUARTにリターゲットしたprintfの実行とメモリ液晶にFONTX2ドライバを
用いて文字表示する内容となっております。
もちろんHALライブラリ対応となっております☆


●過去の記事の正当性について考
3月下旬から続いておりますがぶろぐ上でDropBoxの画像が表示されなくなった問題を
ぽちぽちと地道に修正しております。
201705末現在はアクセス数が多かったESP32・ESP8266・ダイトレ・六甲・STM32F4の
の記事はすべて修正が完了し、STM32F7の修正もほぼ終えたところです。残りは
2016年度以前の小ネタ関連の記事全部と東海自然歩道の記事となりました。

それに伴って自分が書いた過去の記事の内容の見直しも適宜行っています。特に
リンク切れが目立ちますが治せるものは何とか治しています。さすがに3年以上前
の記事になるとどうしても今では誤った概念であると判明したりその時は通じた
手法が現在では通じなかったりといったことが沢山出てきます。ですが対応にも
やはり限界はあります。
こちらの方は私の５年前のぶろぐ記事を参照して知りたい情報が消滅し到達できなかった
ことに言及されておられますが2012年のねむいさんは既に｢CMSISv3以降を使え｣と
アドバイスしているのでそれに従わず自己流でされて勝手に困られて私のせいにされ
てもそれはちょっとちがいますよと、特に免責事項はぶろぐのプロフにも明記して
ありますので私に何年も前の内容を補償する義務はないです。と。
これだけははっきりと真実を伝えたかった。
ていうかへろへろハイカーとかいうのホントなんなんでしょうね…audinさんの旧
ブログのアドレスの居抜きで出来たサイトのようですけど…
とはいえこのまま放置するのは私としても心苦しいので2017年の内容に即したものに
情報を修正させていただきました。

一方こちらの方が指摘されたENとBOOT間違えてた件はESP-WROOM-32から放射された
電磁波の影響からか私の頭がぼけてて完全に私のミスです。

なんにせよどっかの壺にまた｢こいつが書いてることはデタラメ｣とか書かれないよう
世間に公開する前に一息おいて精読して間違いを修正する癖を習慣づけてこれからは
なお一層のこと気を付けて行こうと思いまし、た！


●FatFsが0.13に更新
ChaN氏のFatFsも5月中旬に更新しておりました！
主な更新内容は"syscalls.c"やoptionフォルダ内のコードページ変換テーブル
が廃止されてffsystem.cとffunicode.cに変更されたこと、あと幾つかの定義も
接頭語に"FF_"が付与されて他のソースコードとの定義のバッティングが低減され
てたことです。

exFAT関するルーチンは初登場以降日進月歩で進化しまくっているので皆さん自身
でforumや更新情報を常に確認した方が良いでしょう。

ねむいさん的にはdefineの接頭語に"FF_"が付与されたのが効きました。自分で書
いた部分にも多数のFatFsのdefineで切ってあったので見逃さないように修正して
廻ったので大変です。ですが何とか全部治すことが出来ておきぱに置いてるサポート
中の4種のFatFs移植例も無事0.13対応となっております☆

・STM32F7(HALドライバ使用)
・STM32F4(SPL使用)
・STM32F1(SPL使用)
・LPC4088

おっと、最も重要な事柄が変更されていたのを忘れておりました。
今回の更新からChaNさんのFatFsに関するページは全て英語のみになり日本語に訳
された解説が完全に消滅しました。

昨今のembedded事情を鑑みると有益な情報は凡て英語圏のコミュニティに集約されて
行くのが必然でありこの流れは避けられない事柄ですがねむいさんの知能レベルで
すら英語で意志の疎通が問題なくできておりますので皆さんにとっても問題ないはず
です…よね?(威圧)

●SDカードの規格がV6.00にバージョンアップ
昨年秋にSDv5に更新と報じましたが早いものでA1クラスの定義が追加されたV6.00へと
早々に規格がバージョンアップしております。もう巷ではそのA1クラスのロゴが乗った
SDカードが出回っているようです。

A1クラスの利点は小さいサイズのちまちま読み書きのスピードが一定値以上保証されて
いるという点ですが随所で上がっているベンチマークを見る限りではA1策定以前から
存在する高価格帯の高性能カードと比べると大きな有意差はなさそうです。

ねむいさんは次買うカードはS.M.A.R.T.が採れるDelkinのMLCのやつに決めてますので
しかも今はフラッシュメモリも3D-NANDへの過渡期でSDカードそのものの値段がどん
どん高くなっているのでA1ロゴ付きのカード見かけても手を出さないと思います。
ていうか民生用SDカードの値段が高くなり相対的にDelkinのやつがお求めやすい
値段になっちまいましたので運よく特別収入が発生したら即買いしたいと思います！！
いきなり1000万とか手に入らないかしら…

Go to top of page