OpenOCD小ネタ23 -新機能続々更新-

夏が終わったと思ったらもう冬かよ…秋はどこだ…


さて、そうこうしているうちにOpenOCDも着々とバグフィクスや新機能が追加されて
おります。そろそろV0.10からV0.11になっても良いと思いますがgerritで管理され
てる全員参加型のフリーウエアにそれを求めるのはあまりにも野暮ですがそれはおい
説いて紹介させてもらいます。


●CMSIS-DAPの速度がアップ!
CMSIS-DAPはARM肝入りのフリーなデバッガアダプタで最近販売されている安価な
Cortex-Mx系の評価キットでは欠かせないものとなっております。

ねむいさんのぶろぐでも2014年にいち早く紹介させてもらっています。当初はマイコンへの
書き込み速度が非常に遅く使い物にならなかったのですがその後機能強化されようやく
実用レベルに
、そして今回の修正ではさらにスピードアップとなっております☆
もっとも2017年春にはすでにパッチが上がっていてねむいさんが提供するバイナリには
そのパッチが適用されておりましたので皆さん実は気づかず使用されていたことになります!


それではさっそく比較してみましょう。
今回CMSIS-DAPを仕込んだLPC1549Xpressoを引っ張りだしてきて32kByteの
バイナリを書き込み、ベリファイを行いそれぞれの経過時間を比較しました。
●修正適用前

> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc1549_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.9.0-dev-00357-g09ca5af-dirty (2015-03-31-00:00)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'swd'
none separate
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: JTAG Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD IDCODE 0x2ba01477
Info : lpc1549.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x030000b8 msp: 0x02001fe0
auto erase enabled
wrote 32768 bytes from file main.elf in 2.525144s (12.673 KiB/s)
verified 29400 bytes in 0.426025s (67.393 KiB/s)
shutdown command invoked

> Process Exit Code: 0
> Time Taken: 00:04

●修正適用後
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc1549_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.10.0+dev-00563-gda4b2d5-dirty (2018-10-29-08:10)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select '.
none separate
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: JTAG Supported
Info : CMSIS-DAP: FW Version = 1.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Info : lpc1549.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x030000b8 msp: 0x02001fe0
auto erase enabled
wrote 32768 bytes from file main.elf in 2.477142s (12.918 KiB/s)
verified 29400 bytes in 0.425024s (67.551 KiB/s)
shutdown command invoked

> Process Exit Code: 0
> Time Taken: 00:03


書き込み速度だけ抜き出して比較
前 :wrote 32768 bytes from file main.elf in 2.525144s (12.673 KiB/s)
後 :wrote 32768 bytes from file main.elf in 2.477142s (12.918 KiB/s)


あらら…140%早くなるんじゃないの‥??
…まぁちょっと早くなったしまぁいっか!


●NuvotonのNuLinkに対応!
台湾NuvotonのCprtex-M系マイコンNumicroシリーズ、数年前にねむいさんがフラッシュ
書き込み対応
させて以来即効飽きて放置してましたが…なななんと!
Nuvotonの開発チームの人が直々にNuvotonのCortex-Mx向けのデバッガNuLinkを
OpenOCDに対応
してくれました!!!!11!!!


ちなみに秋月で購入できるNuvotonのキット付属のNulinkはUSBコンポジットデバイスで
制御対象マイコンとつながるのはUSB-HIDとなっており、これだけで動作させるならば
ドライバすら不要です☆

> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/nulink.cfg -c "transport select hla_swd" -f target/numicro_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.10.0+dev-00563-gda4b2d5-dirty (2018-10-29-08:10)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
none separate
Info : clock speed 1000 kHz
Info : NULINK is Nu-Link1
Info : NULINK firmware_version(6386), product_id(0x00012009)
Info : IDCODE: 0x0BB11477
Info : NuMicro.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0000035e msp: 0x20003fd0
auto erase enabled
Info : Device ID: 0x00012000
Info : Device Name: NUC120LE3AN
Info : bank base = 0x00000000, size = 0x00020000
Info : Nuvoton NuMicro: Sector Erase ... (0 to 41)
Info : Nuvoton NuMicro: Flash Write ...
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
wrote 21504 bytes from file main.elf in 6.905395s (3.041 KiB/s)
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
verified 21288 bytes in 0.324018s (64.160 KiB/s)
shutdown command invoked

> Process Exit Code: 0
> Time Taken: 00:13

パッチを適用したOpenOCD書き込んだログはこんな感じです。
仕様上ちょっと癖があり接続しに行くと他のデバッガと違ってワンテンポ間が開く
感じで繋がります。そして立ち位置としてはTI-ICDIやSTLink系と同じHLA扱いと
なっております。ですのでAPの直叩きはできないので注意が必要です。

それとCMSIS-DAPのようには最適化されていないのかVersaloonの1/2くらいの書き込み
速度となってますね…今後の改良はNuvotonチームに期待ですね。


SW-DPの直叩き等の低レベルの操作はできないですが通常デバッグで行える操作、
レジスタ、メモリ参照などは問題なく可能です。
これでNuvotonマイコンもフリー環境で使い勝手が大幅に上昇した感じがしますね!




今回の修正を反映したOpenOCDのバイナリはすでにおきぱにありますのでどしどし
使ってください!NuLink対応はまだ公式採用ではありませんがねむいさんバイナリには
すでに適用しております!

また、今回のNuLinkの対応に当たり私がかつて統合したnuvotonドライバでデバッグ時に
一部動作がおかしくなる品種があることも突き止め、それの修正も加味しております。
これについては次回詳しく説明させていただきます!

GNSSモジュールを試用する18 -みちびき四機体制記念-

2018年現在、日本製準天頂衛星「みちびき」は4機体制(うち一基は静止軌道)
となり試験運用されております。最も新しく打ち上げられたQZS-4(PRN195)もすでに
脱皮して試験稼働しているとの事でねむいさんもさっそくみちびきの受信状況を
ねむいさん特製GNSSロガーで確認してみました!


結果は後にしてとりあえず今回の走行ルートにあたる熊野古道の攻略もばっちり
進めてきましたのでしっかり見て行きなさい!


●2018.04.01 近畿自然歩道((道方〜)村山〜南島棚島)


前回の続きで南伊勢に向かうバスに乗るために伊勢市駅へ…
バスの待ち合わせのため近くの月読宮にお参りし道中祈願をします。


伊勢市駅からバスで1時間拷問タイム…
今回も三重交通の株主優待拳で費用を節約して移動です!



昨年末にも来た道方バスからスタートします。今回はR260をまっすぐ
西に向かいます!道路わきには満開の桜がお出迎えです!


阿曽浦口につきました。
はるか向こうには前回通過した南島大橋が見えますね★



今回の近畿自然歩道のエントリポイントはさらに西にあるの村山という
場所ですがかつての街道「熊野脇道」になるべく忠実に追ってみますが…
道が消滅して草かきわけで道路に出たりで前途多難です…



当面はR260の旧道に沿って"浦"めぐりをします。
桜と海の絶景が楽しめる良い季節です♥


そして熊野脇道に忠実に進み過ぎてまた迷う…
山桜が舞い散る中東宮トンネル上の古道を探し回った挙句
強引にR260に降りてしまうが…


おあつらえ向きに階段ができてるorz
無理に道なき道進まないでよかったやん


トンネル上の古道は今の整備され残されています。



東宮トンネルを抜けて奈屋浦に出ると川村瑞賢ゆかりの史跡が
多数みられます。


大仙寺です。ここも川村瑞賢ゆかりのお寺です。



街道は大山寺の東を北上し標高を上げていきますが…
道が消失してやがります…


はぁはぁ…R260をクロスして再び山の中へ…


なんだこの傾斜角!?
トカゲのようにへばりついて登る…


完全にシダで踏み跡も消えコンパスと地図を頼りに稜線を歩きます…
あ!先が開けてる!?


何とか林道に出ました…
(苦労しなくてももっと下からこの林道に沿って上って来れる場所があった)


再びシダラビリンスへ…ココハダレワタシハドコ


8年間の道迷いの経験と動物的直感で無事に熊野脇道に復帰して
R260にも復帰…!さすが私…
ちなみに今回の行程でここが一番の難所でした…


R260はかつての街道をクロスしており
その地点には昔のお地蔵さんが整備されています。


山の中を抜け、河内川沿いに海に向かいます。
途中には倭姫命腰掛岩なる碑石が立っています。


海だ〜〜!私は戻ってきた!


さてここで問題発生です。
ここ神前浦(村山口)は近畿自然歩道「竈方集落をめぐるみち」の起点に相当する
場所なのですが忠実にルートを手繰っていると帰りのバスの時間にまったく
間に合わなくなってしまうため、一部はぶっちしてR260をぶっ飛ばします!1!!1!


てわけでショートカット開始!!
海沿いではないですが桜並木が美しく見てて飽きません♥



この地域はリアス式海岸のため結構上り下りがあり、旧街道は峠を何度も
越えたりしていました。再び近畿自然歩道と落ち合いますが熊野脇道は
「トンネルを直進(トンネル開削前は直登だったらしい)」のため、旧道の
近畿自然歩道に相当する峠道はぶっちですぶっち!



スーパーショートカットを駆使して栃ノ木竈に。
集落の入り口には役行者が祀られています。



自然歩道はトンネル直進ですが脇道はトンネル迂回です…
今回は迂回します…そして古和浦へ



古和浦漁港の対面の斜面には古和一族の碑が配座しています。


さらに旧国道に相当する古道を進むと北野神社に。
ここから標高を上げニラハマ展望台に向かいます。


3年前、超激曇りの最悪のコンディションにここにきてしまいましたが…
今はどうだ!?


oh....素晴らしい…♥
ちょっと霞がかかっていますがお日様が顔を出してくれました…


ニラハマ展望台も桜の花が満開ですね〜☆


展望台を超えると海の水が思い切りきれいな棚橋に出ます!



新桑竈と棚橋竈がある南島棚橋バス停に到着。
バスの15分前に無事到着です…。ショートカットしまくりましたが
3年前は忠実にルート手繰っているので今回熊野脇道中心ですしセーフですセーフ!



少し時間ができたので棚橋竈を散策します。
南島棚橋バス停近くの廃校跡にできた道の駅はつぶれてしまったようです。
3年前は自販機もトイレも使えたのですが…

実は熊野脇道はここから新桑竈を通り姫越山を越えて錦に降りるのですが…
この南島棚橋バス停が付次の出発地点になるのですがトイレも自販機も
なくなった今ちょっと事前準備が必須のようです…。
ちょっと作戦を組み立てなおさないといけませんね。


そして桜吹雪舞う中帰りの町営バスに乗って道方へ…(一時間かかる)
4分くらい遅れてたので来ないのかと思ってビビりました…


ちなみに一時間かかる理由はR260を直進せず一旦いろんな集落を
めぐるためで地元の人の足な訳ですね〜


そしてさらに1時間の拷問を経て伊勢市駅へ…バス移動のほうが疲れた…


特急待ち時間が少しできたので伊勢神宮の参道を散策します…


t n t n モ マ セ ロ(ゼERO)
とりあえず伊勢市に来たらこれです!


シモネタは置いといて熊野脇道もこれで大方つながりました。後は最大の難関、
姫越山を越えて錦に降り、紀伊長島まで向かうルートの攻略となります!

近畿自然歩道((道方〜)村山〜南島棚島) GPSログ


そして肝心のみちびきは何基とらえられたか!?
GNGSVセンテンスからサテライトIDを抽出します!!






…ッッ!!!
っしゃぁっつ!!現行のにみちびき3機分捕捉成功ッ!!!

ちなみに静止軌道のみちびき参号機は捕捉できないのかというと、MT3333搭載
モジュール
を使用したわたしのGNSSロガーではNOです。
三号機のPRNは199で残念ながらハードウエアレベルでQZSSの旧仕様のPRN193~197
しか対応していないため認識ははされないそうですorz
秋月のGNSSモジュール販売のQ&Aでも同様の回答があります。

まぁこれでもGPSのように捕捉できる衛星が3つも増えたことになるので
これでますます使い勝手が上がり頼もしくなる存在と思います!

だからメンテ頑張ってくださいJAXAさ〜〜ん!

いろいろ試す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
のクイック削除で更地にした上で測定を行っております・・・


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

STM32F7を使ってみる15 -工業用SDカードからSMART情報をスマートに読み出そう-

あれ?ESP-WROOM-32が秋月から発売されて絶好のチャンスなのにESP-WROOM-32の
記事書かないのですって?
あああれね…去年の時点で飽きました・・・今更になって弄ってるとか時代遅れですよぅ!(挑発


今回はS.M.A.R.T.(以下SMARTと記)対応のSDカードからSMART情報を読み出してみます。
別にF7じゃなくてもよいのですけど次回以降のネタに繋がる内容なのでしばし御静観願います。
今回もSTM32F746G-Discoveryを使います

工業用のSDカードの中にはSSDやHDDのようにSMARTの情報が取れる希有なものが存在
しております。残念ながら一般に購入出来る民生向けSDカードではそのような機能は
搭載されておらず、SMART対応どころか工業用SDカードも入手がごく限られております。
もちろん値段も民生品に比べ極めて高価です。

なんで高価かと言うとカードの動作に関する"信頼性"を保証しているからにつきます。
皆さんご存知の通り2017年現在市販で流通しているSDカードは明記が無い限りはTLC
タイプのNANDフラッシュメモリが使用されており、TLCというのはSLCやMLCに比べて
大容量が取れる割にデータ保持のための寿命が短い、また書き換えできる回数も極端に
短いという代物となっております。

一方工業用SDカードは4GB以下はSLC,それ以上の容量でもMLCを保証しており(容量を
犠牲にして疑似的にSLC風の動作をするpSLCやaMLCなんで奴もありますが) さらにSDカ
ード内コントローラのファームウェアもデータ保護に特化した特別となっております。
たとえばECCチェック機能とかパワーダウンプロテクションとかオートリフレッシュ機能
とかバッドブロックマネージメント、ダイナミック+スタティックウエアレベリング等々
いろいろありますが、実はこれTLCカードを世に出すために必須の技術でそれが耐久性が
もともと高いSLCやMLCを使用した工業用製品にフィードバックされて最強に強まった
信頼性を謳うわけです。

というわけでこれらの機能実装は最早当たり前となった今、カードの健康情報を
把握するための機構を仕込む事が新たな付加価値として注目されており、各社で
SMARTもしくは独自の寿命診断を組み込んだ工業用SDカードが販売されております。


で、われわれホビイストが問題となるのはその工業用SDカードの入手から始まりさらに
SMART情報を取得するための"情報"を入手し利用せしめるまでに多くの壁がある
ことです!

まずDigikeyやmouser,RSの海外在庫くらいからしか工業用カードの入手法が日本
国内からではまず困難で、さらにSMART対応と謳っていてもカタログの隅っこに(※オプシ
ョン対応)とか書いてあったりして高い金出して購入したのに目当てのSMART機能が
実は搭載されてなかったとか悲惨なことがほとんどです。

それでやっと入手にこぎつけたとしてもSMART情報を取得するための手段やツールは
公開されておらずメーカに直接問い合わせることになりますがほとんどの場合対企業間
の問い合わせにしか対応してなかったり(もちろん個人事業主として問い合わせても
THE・シカト)、SDAのライセンスに加入していないと情報を渡すことができないよなど
つっけんどんの反応しかもらえません。

ねむいさんも方々に手を尽くしましたが個人レベルではなしのつぶてて困り果てていまし
たが灯台下暗し、DELKINというメーカの工業用SDカードを扱っている代理店が日本
国内に存在しておりました
。こちらは在庫があれば一枚から対応(無ければ受注生産
20枚単位)というホビイストにもうれしい対応でしたので早速1GB品を注文し、ゲッツ
しました。



でかいDELKIN箱に小さいMicroSDが対照的です。


今となっては微々たる容量の1GB、見た目も普通のMicroSDカードですが…
このDELKINのU331というシリーズは中身は某粉飾決算にチャレンジしたおかげで
倒産寸前の日本メーカのSLC型NANDフラッシュが使用されております!
なにルネサスより先に死んでんだよ東芝!!11!11!!1!!!!!!
動作温度範囲もやたらと広くて-40~+85度まで保証しております。

ひとまずUSB接続のカードリーダーに接続してパフォーマンスを見てみました

規格的には"2GB以下のSDSC"に位置するカードなのでUHS-1とかには対応しておらず
理論上最大でも25MB/Secの転送スピードとなりますがマイコンで使用する限りでは
ハイスピードモード(最大SCLK=50MHz)に対応さえしてれば全く問題ないです。


SMART情報をPC経由で取得するために"USBカードリーダ"を用いて"DELKIN DashBoard"
なるアプリケーションを使用する必要があります。
ねむいさんの持っているTranscend製のUSB3.0カードリーダーは無事にSMART情報を
読み出すことができました。やったぜ!
どういう理屈でSMART読み出してるかしらないけど(伏線)

ちなみに"DELKIN DashBoard"の動作保証しているDELKIN製カードリーダーは上記の
ねむいさんのもってるTranscendのとまったく同じチップが使用されております。



お次はSTM32を使って動作させてみます。

FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Dec 6 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 14338 kB/sec.
>ds 0
rc=0
Drive size: 1947648 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Byte)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 00 5E 00 32 5B 59 A3 B6 FF FF FF 80 0A 40 00 6D .^.2[Y.......@.m
CID:
00000000 58 44 44 44 44 49 4E 43 30 6D 6D D4 59 01 0C 49 XDDDDINC0mm.Y..I

Parsing SD CID Register
Manufacturer ID :0x58
OEM/Application ID :DD
Product Name :DDINC
Product HwRev :3
Product SwRev :0
Serial Number :0x6D6DD459
DateCode.Month :12
DateCode.Year :2016

OCR:
00000000 80 FF 80 00 ....
SD Status:
00000000 80 00 00 00 00 00 00 28 03 03 90 02 00 AB 00 00 .......(........
00000010 00 00 00 00 00 00 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 25 80 00 01 00 00 00 .%......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Spec Version X :0
SD Security :2
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDSC Card!
Available NS(or HS) Mode Only.
>

先ずはいつものでSDカードの情報を読み出してみました(これだけSTM32F429を使用)
2016年製!
ATPの工業用カードでもそうでしたが現在はW/R性能はSDカード内コントローラの
ファーム次第なのでSLCとはいえ転送速度がめちゃくちゃ早いとは言えません。
どちらかと言うとSLCを使う理由は速さよりもデータの確実性を求める方向に概念が
遷移していると感じます。


そしてついにSTM32F7-Discoveryを使いSMART情報の読み出しに掛かります!
このDELKINのカードはSDカードに昔から存在するCMD56という"汎用コマンド"を用い
てSMART情報の取得を行います。SMART情報を取得する方法は各社バラッバラで門外
不出の所もありますがDELKINは"CMD56でSMART採れるYO!"と公言しているためかなり
フレンドリーと感じます。

この"CMD56"は引数によってデータの受信送信を変えることができるコマンドでCMD17等の
シングルブロック転送と同様最小512Byte単位でやり取りをおこないます。
DELKINカードにおいては特別な引数で、ある一定の順番で、CMD56の送受信動作を
行うことにより目的とするSMARTの情報を得ることができました。





DelkinDashboardとCMD56で読みだしたSMART直値をUARTに吐かせて値の
比較です。カードに何らかの書き込み動作を行うと電源再投入時にDashboardの
"TotalPowerupCount"に相当するSMART直値が更新されているので正しく
SMARTが読めていると判断しました。
ところで具体的にどうやってCMD56投げたのと知りたい方がいると思いますが対価を
払って得た情報ゆえこのぶろぐ上で詳しく公表できませんが…
…おや?このデータシートDELKINと関係ないのになんだかそっくりだー(棒読み


詳しくは言えませんが512バイト分のSMART情報のフッタに相当する部分のデータが
CIDの情報と一致しておりました。何かのvalidationに使うのでしょうか(棒読み
まぁあまり重要な情報ではないでしょう(伏線




このDELKINカードを選んだ理由は拙作のSTM32Primer2を使ったGNSSロガー
信頼性向上につきます。一度Primer2の筐体中に組み込んでしまうと構造上
ケースの中にカードが封印されてしまうため簡単に取り出せなくなるのでSDカードの
寿命診断を何らかの形で外部から行いたいと思いSMARTが取れるカードを選んだ…
と言う経緯です。
次回のちょっとネタバレになりますがこのGNSSTrackerのマスストレージモードでも
DelkinDashboardを使いSMARTの取得に成功しています。
なんでCMD56発行してないのにSMART採れるんでしょうね(意味深


願わくばSMARTを利用した寿命診断機能がSDAで正式に規格化され、民生用の
SDカードでも気軽に寿命診断できる素敵な時代が来るようになることを願います。

だからSDAの中の人のPanasonicさん頼みますよ!
なぜか不自然なくらいパナ推しのねむいさん。






ここでねむいさんFAQ特別編
Q:ねむいさんねむいさん、確実にSLCのカードを見極める方法を教えてくださいっ!
A:
 SLCってカードにでかでかと書いてあるカード選べばOKです☆

ESP-WROOM-32を使ってみる2 -そんな電源で本当に大丈夫か-

ESP-WROOM-32の目次に戻る


別にねむいさんががんばらなくても意識が他界系の人たちが「IoTだウェーィwwww」
とかほざきながらNAVERまとめと変わらんレベルのqiitaとかのやたら検索で引っ掛かる割には糞の役にも立たない
チュートリアルもどきをマンボウの産卵みたいにボコボコ作リ出して情報ノイズを増加させやがるのは
ESP-WROOM-02で予習済みなんですけどまぁアプリレベルの話はそれでもいいんですけど問題はそれ
以前のハードウェアよりの話でねむいさんが散々警告したにもかかわらず電圧
ドロップの問題に今更引っかかったのか納期に間に合わないせいか捨て垢のフリー
メールで日本語になってない日本語で「これは何が悪いと思いますか!!1!!1!」とか
あわよくばねむいさんの発言の揚げ足とってこっちに全責任押し付けてやろうというような
性根が見据えた文面のハナクソ野朗が絡んできて虹裏メイドの中でも特に温厚で
優しい
ねむいさんもさすがにブチ切れて「お前みたいな奴が"ものづくり(←この単語
ねむいさん大嫌いですがあえて使います)"してんじゃねーですよぅこのハナクソ野郎
何が悪いっておまえの存在全てが悪だよバカヤロコノヤロ」と返信したいのをぐっっっっと
我慢してなるべく誠意ある対応を心がけてきましたがもうダメです限界です!もうでちゃいます1!!111
そういえばもう年末だね

ア"ア"ア"ア"ア"ア"ア"ア"ア"ア"ア"ア"ア"ア"ア"ア"ーーーーーーッ!!!11!
(CV:ストーム・イグッリード)

本日の記事これにて完結!!



































今回はwifiモジュールでありがちな消費電流の問題についてESP-WROOM-32の実測を
しながら検証していきたいとおもいます。

wifiモジュールは基本的に多飯喰らいで特にリセット直後の挙動は注意しなくては
いけません。wifiモジュールが使う3.3Vが大きく落ち込むとブラウンアウトリセット
が掛かり無限ループになる危険性もあります。

前回私が購入したモジュールは1117系のLDOが実装されたモジュールでしたが昨年の
私の測定結果
を見れば分かりますがLDO自身のドロップアウトが1V近くあります。
このdoit.am製のボードのUSBコネクタを抜き差ししたときの電圧/電流波形を測定して
本当に安全か確認していきます。


まずはこのボードに電流プローブをつける儀式・・
ここに乗ってる3.3Vを作る1117系LDOはNCP1117かな〜


LDOを一旦はずしました。
すぐさま測定用に"立てて"付け直します。


Voutを浮かして電流プローブを付けられるようにしました。


SDIOの時と違ってプロービングやっけつですが測定対象は比較的遅い変化の電源波形
だから問題ないです。その代わりオシロのピーク検出機能は有効にしておきます。

それではようやく実測にうつります。



電源投入直後っ!
うぉぉう・・・一瞬ですが1.4Aくらいガッツリ電流喰ってますね・・・
XbeeWifi並みですよぅ…。でもこれはResetごとではなくVccの立ち上がり限定
だけのようで安心です☆
なわけないですけど。ていうかこの突入電流て相手側PCにダメージいくんじゃない
と言いたいところですが先に進めませんので見なかったことにします


もう少し時間レンジを窄めました。リセット直後の電流消費は丸で囲った部分の
2発目の大きい電流波形です。BLEブロックがこんな数百mAオーダーで電流喰うわけ
無いのでwifiのブロックがメインとなって動いてますね。


その2発目の部分を拡大です。青色で示す電流波形に注目!
なんと瞬間的に最大600mAも喰ってますよぅ!!!
もちろんこの間+3.3Vラインがおもいくそドロップしてます。


2発目の部分を少し引いた画像です。リセット後の大きな電流消費が収まった後は
電流波形も落ち着きます。しかしながら常時180mA近く消費しています・・・。

ボード上のLEDとCP2102の電流消費をさっ引いても160mA以上消費してるのは確実で
しょう。尤もCP2102は5V->3.3Vの内部レギュレータがあるのでこいつはLDOの+3.3V
には何の影響もないです。つまりESP-WROOM-32自身がめっちゃ喰ってるって訳です。
こんだけ電流喰ってるってことは・・・まさか・・・まさか・・・+5Vラインも仲良く…


おぃいいいいーーーー!!!11!!!!!!
完全に去年と同じ展開ですね・・・しかも瞬間600mAだからドロップが悪化しますよぅ!!
…おや…どこからともなく声が聞こえる…

>ねむいさんねむいさん、ESP-WROOM-32の最低動作電圧2.2Vを全然割ってないから
>ひと時のおちこみくらい見逃してあげましょうよ気にしちゃだめですって!
>おちんこでる時も気にしない、それが皆が知ってるがんばりやさんのねむいさんですよ!

ぁぁ・・・そうですね・・・入力の+5Vラインさえぱわふりゃーな電圧源使えばなんの
問題もありませんたとえドロップアウトが1V以上の1117系のLDO使ったとしても・・・
・・・

そんな↓わ↑け↓あ↑るかー!!

今のままでは余裕度が0.4Vくらいしかないじゃないですかー!
測定の際に使ったUSB-MicroBケーブルは30cm程のごくごく一般的なものです。
コネクタ部の接触抵抗やケーブルそのものの抵抗成分による電圧ドロップを加味すると
一般的なPCのUSB2.0のコネクタよりVbus電源を取るとこのような状態に簡単に陥って
しまいます!!



てわけで早速+3.3Vラインのパワーアップ大作戦です!!
1117系LDOと同じピン配置をもつADP3338を使います。こいつは負荷の高速応答、
セラミックコンデンサ可、なによりドロップアウト電圧がMAX190mVと大変優れた
逸材です!!!
覚えてらっしゃる方もいると思いますがクリスタルが発振せず電源ラインが発振
したことで有名な某C級出版製のゴミ
にも搭載されてしまった不名誉なLDOですが
F特の1uFを出力に乗っけるような愚を犯さなければ何の問題もありません。

今回のESP-WROOM-32板にはもともとLDOの出力に100uFのチップタンタルが乗っていて
容量としては必要十分なのでコンデンサは変えず、単純に1117と置き換えだけ行って
測定してみました☆

ADP3338を一般使いする場合は入出力とも16V/10uFくらいでX7Rもしくは
B特以上の性能の積層セラミックコンデンサ(MLCC)を選びましょう。
秋月さんだとこれとかこれとかお勧めです☆
このLDOの出力に積層セラミックコンデンサ(MLCC)を使うのは意味があります。
MLCCはESRはとても低く一度に大量の電荷を吸い込み/掃出しが可能なので
wifiデバイスのようにいきなり大電流を消費するような回路のデカップリングに
必須なのです。もちろんLDO側も急峻な負荷変動に対応できる瞬発力が要求されます。

単に出力電流容量やコンデンサの容量だけで部品を決めてはなりません。
常日頃データシートとにらめっこして適切な箇所に適切なデバイスを適用
できるように心がけましょう。


+5Vラインが落ち込んでも出力の+3.3Vには全く影響は出ていません!これで電源の心配
無しに思う存分使うことができます♥やったぜ
とはいえ上半身(+3.3V)に比べて下半身(+5V)が貧弱だと他の+5Vデバイスも一緒に
動かしているときに不都合が生じるのでデジタルテスタで遅い変化を測るだけで
終わらずオシロでしっかり波形を確認しながら製作していく癖をつけましょうね。
昨年に引き続き大事なことなので累積で4回言いました!


一応注意点ですがADP3338の入力最大電圧は1117系の半分以下の8Vとなります。
専らUSBのVusbである+5VをLDOのVinとする時の補強を狙っております。
9V以上のACアダプターを主に使う人はADP3338に変えるメリットは何もないです。

まぁこんだけ電気喰うモジュールにLDOに9V以上の入力電圧加えたらLDO自身の発熱が
どういうことになるか皆さんご存知でやはりVusbの+5V程度を入力電圧とすべきなの
は自明と思いますがねむいさん的には30USDくらいになってもいいからDCDCくらいは
組んでほしかったなぁ〜なんて思いましたっ!

ちなみにこのボードの「Vin端子」とVbusはショットキバリアで切られておらず何も
考えずに電圧同時印加すると当たり前にぶっ壊れるステキ設計となっております♥
尤もねむいさんのぶろぐの読者にそんなことやらかす頭がぶっ壊れた奴がいるとは
思えませんから杞憂でしょうけども(カメラ目線で



そいえばDCDCで思い出したけど以前コメントでHX1001進められたけどあれって結局
どうしたの?とお思いの方がいると思います。
実はEMSで配達指定したESP-WROOM-32の方が先に届いてしまったので評価はもう少し
先になると思います。その前にSDカードネタももう一つやりたいのでもうHX1001は
もすこしお待ちください。

20170227追:
ねむいさん+5Vや+3.3Vの事ばかり言ってますがGNDについても帰還電流の流路を意識し
なるべく広いグランドプレーンを確保するのはもはや常識と思っております。
側面から出ているGNDのピンとは電気的には繋がっておりますがESP-WROOM-32の背面の
GNDパッドの接続もぜったいに省略してはいけません!このようなパタンが設けられている
のはちゃんと意味があるのです。特にブレッドボードで工作される方はこの重要性を理解せず
動作させようとされる方がものすごく多いのですが「動いているようです」で済ませるとこの先
必ずトラブルが起こります。
面倒くさがらずに土台はしっかりと固めておきましょう!



20170220追:
mgo-tecさんが当ブログエントリの内容を追実験してくれました。
ねむいさんと同じADP3338を用いてよい結果を出されています
また、電源投入時->リセット時の電流の変化もシャント抵抗を用いた測定法に
よりねむいさんと同じ測定結果を記録しております


第三者による検証の再現性もばっちりとれているのでねむいさんのやったことは
間違ってなかったとまたひとつ確信させていただきましたっ☆
ちなみにねむいさんのdoit.amの出来合いボードのパタンが1117系でちょうど
ADP3338で楽に置き換えできたからこれを選んだわけで、ねむいさんとしましては
秋月で安価に購入できて各種保護回路も万全に備わっていてドロップアウト電圧も
1.5Aでたったの0.34Vと最強に強まっているLT1963Aを強く推させていただきます。

20171115追:
ADP3338、ついに秋月に光臨す!!!

STM32F7を使ってみる13 -STM32F769I-Discoveryを動かしてみる2-

>ARM、禿に喰われる
>ARMはもう終りDA!

うろたえるな小僧共ー!

(↑C.V.牡羊座のシオン様で)

禿の習性からして中身ろくに見ないでまーた買い物のための買い物やっただけだから
アリババの時みたいにどうせすぐにリリースしちゃうでしょう。
ていうか"買収する"と言ってるだけで20160803の時点で買収が完了"した"とは
言ってないのでまだ禿に喰われてすらいない段階ですね。

こと電子工作で使用するARMマイコンの範囲においてはまったく何の影響も出ない
と思います。尤もARMが禿に衰退させられるような程度のジョンブル野郎だったの
ならねむいさんのほうからお断りで自然歩道一本に絞ってこのぶろぐ続けます。

というわけでこの件についていろいろ質問もらったので虹裏メイドねむいさんとしての
見解をさせていただきました。かしこ。

20160906追:
正式に買収完了と同時に上場廃止になりました。
ねむいさんとしても今後の禿の動向に注視いたします。
最悪のシナリオは小規模マイコン向けのコアIPが捨てられることです。
20160906追:


20170411追:
少し前の話ですが予想通り早々に4分の一を売却するそうです…
ねむいさんの予想以上に売るの速かったわ!
今度はアラビアンARMになるのですね…
20170411追:




































すみませんうっかり本日のぶろぐ終わらせそうになってしまいました。

今回は主にSTM32F769I-Discoveryに実装されたAudioCodecを利用してサウンド
再生機能つけるべく頑張ってみました。

●STM32F4-Discoveryからのサウンド再生機能の移植

STM32F769I-Discoveryはご覧のとおりAudioCodec(WM8994)とは生粋のI2Sでは
無くSAI(SerialAudioInterface)のI2S機能から接続されています。
基本的なものはSTM32F4-Discoveryの時と同じなので基本的な部分を押さえつつ
F7のHALに合わせるよう移植していきました。


困ったのがサンプルレートから実際のI2S用のクロックを生成する関数で既存の
BSPの関数を流用すると何でか2倍速で再生してしまうという現象にぶち当たって
しまったことです。
これなんとなくHALのバグっぽいな〜と思っているのですがeMMC対応したとき
かなり時間を喰って懲りているので深追いはせず、自作のテーブルを参照して
適切なPLL値をPLLI2Sに付与する関数を経由させるようにしました。
ややこしいですがSAIのクロック元はPLLI2Sから供給しています。BSPもそのように
なっています。


ていうわけで2作業日くらいで移植完了です。
画像はmp3ファイルを再生しているところです。画面のIART,INAMはID3v1もしくは
ID3v2タグを解析し表示しております。aac,wavファイルも同様に再生できます。


最初にmp3を移植した頃は良く分からなくて実装していなかったのですが、ID3に
格納されている"UTF-16LE"の文字列をChaN氏のFatFsに収録されているff_convert()
関数を用いてS-JIS形式の2バイト文字に直して表示するようにしました。もちろん
ascii形式でも崩れないように対策済みです★
ていうかID3関連はかなり長い期間適当に作って放置しててID3タグ解析の段階でコケて
mp3/aac形式ファイルが再生できない場合があったのず〜〜〜〜〜〜っと放置してました
ごめんなさいごめんなさい!!!!!
STM32F4のほうも今回の修正は横展開しておきましたのでご安心ください。

STM32F769I-DiscoveryなんてもってないYO!という方もご安心ください!
makefileの定義を変えるだけで秋月さんのところで購入できるSTM32F746G-Discovery
でも同じようにオーディオファイルの再生が可能です!



そいえばビットレートが高いデータをサーキュラDMAでバリバリ送る使い方すると
SDIO/SDMMCのDMA転送に干渉してコケる問題はSTM32F7になっても解消されていない
のでmp3/aac/wav形式対応にした場合SDMMCはDMAでは無くFIFOのポーリングで転送
するようにしておりますorz

さらにポーリングの場合はSDIOのクロック周波数が高い場合受信時のアンダー
フローが起こりやすいのでハードウエアフローコントロールを有効にするように
しました。STM32F4ではエラッタで使用不可とされてきましたがF7シリーズでは
解禁です★

さらにさらにですが昨年STM32F4で行ったアライメントズレ対策をSTM32F7に展開
して実装した際に大バグを作りこんでいた事が発覚しコレも修正しています・・・
一年以上ほっぽっていましたが皆raspberryに逝っちゃってSTM32F7に見向きも
しなかったのでばれずに助かりました・・・これもID3タグ解析の実装見直したときに発覚orz



●画面がでかくなったからでかいサイズの動画再生してみる
ChaNさんのLPC2388向けFatFs移植例には独自形式で動画を再生できる機能がありま
した。ねむいさんはこれを他マイコン向けに拡張しつつ使い続けてきました。

STM32F769I-Disccoveryになって画面サイズが800x480に一気に広がったので、
少しデカめのファイルを作ってちゃれんぢです。

とある動画からAVCフォーマットでエンコードされたmp4形式のファイルをAviutilで
無圧縮aviにしてそこからChaN氏のツールで独自形式のファイルに直します。

ちなみに独自形式に変換するavi2imgはChaN氏のFatFs実装例ffsample.zip内¥lpc23xx¥tools¥にあります。
今回のねむいさんの移植例ではDMA2Dの関係でビッグエンディアンが要求されるので
avi2imgを自前でビルドしなおさなければなりません。さらに最大サイズも変更する必要が
あります。真似される方はご注意ください。


再生するプログラムのほうも少し手を加えました。
ファイル名と現在フレーム/総フレームを表示できるようにしておきました。

また、display_basis.hのENABLE_PERFORMANCE_MEASUREMENTのdefineを有効にすると
上記の代わりに一秒あたりのフレーム数を表示できるようにしました。


この動画は640x360サイズあります。一ドットあたりRGB565の16bit=2バイトあるので
一画面あたりのバッファサイズは640*360*2=460800byte必要です。そこから30fpsの
動画を表示せしめようとしたら460800*30=13824000(byte),つまり約13.8MByte/Sec
の速度で読み出さないといけないためSDMMCのNomalSpeedMode(MAX12.5MByte/Sec)
ではまったく歯が立ちません。


この動画はオリジナルは29.97fpsとなっており、そこから生成されるimgファイルも
同じく29.97fpsのためノーマルスピード(ねむいさんの移植例ではSDMMC用のベース
クロックがPLLSAIから生成される48MHzからのため最大12MByte/Sec)では先に述べた
とおりまったく足らず20fps前後しか出ません。


SDMMCのクロックをハイスピードモード対応(ねむいさんの移植例では最大24MByte/Sec)
にすると転送が余裕で間に合うためきっちり29.97fpsが出ます♥
う↑ま↓ぃ↑やったぜー
さすがにこれ以上のサイズだと転送サイズも肥大化していくためスムーズな再生は
難しくなりますがねむいさんはタイチョウの作る動画がオリジナルサイズとFPSで再生でき
ればそれで満足なのでコレでよしとします。ぜんぜんよくないですけど。
使用するSDカードそのものの転送速度も重要になるはずなのでこちらを熟読して、
私の真似される方はカードもしっかり選んでみてください。







・・・ぇ?元の動画を見てみたいですって?・・・まあ別にいいですけど動画内コメントに
警告がありますが桁外れにヤバイ内容なので無理だと感じた方はすぐにブラウザを
閉じて退避した方がいいと思います

"すぐに"を具体的に言うと最初の3フレームめまでです。時間で言うと100mSec以下の
反応速度でブラウザを閉じれば安全となります。ねむいさんのぶろぐを会社や学校
から見ているクレイジーな方々はuSecオーダーで超反応できる人間だらけなので
多分大丈夫と思います。ちなみにねむいさんのSTM32F7のサンプルから再生した場合、
タッチパネルの読み込みが100mSec間隔のため逃れられません。覚悟してください。

ねむいさん的にはゼEROの中でもコレはテーマ性・ストーリー性・変態性・音楽性・
危険性・テンポ・○ンポの全てが危険水準を大きく逸脱した迷作中の冥作であり、
634タイチョウの無限の可能性と危険性を垣間見ることが出来る貴重な作品であると確信
しているのですがリアルタイムで投下されたときはこの人本当に気が狂ってしまった!
と思ったのですがこんなヤバイ動画ばっかり作っててラブライバーに自爆テロ食ら
わないのかYO!大丈夫か曜!とか思っているのですがねむいさんもイケナイお口のほむコラばっかり
やっててやってる事あんまし変わらないかもと思っているのです!
が!
虹裏メイドねむいさんは「ラブライブ!サンシャイン!!」を応援しております!
.見ないと注↑射↓なんですぅ♥










戯言はこの辺にしてちょっと早いですが上記の更新を追加したSTM32F7のいつもの
をいつもの場所に上げておきます
。この一ヶ月間でFatFsにも大量にぱっちが
当たってR0.12aになっていますので全て適用しております★
上のほうでも述べましたがSTM32F4にも横展開しましたのでSTM32F4-Discovery
しかもっていない・・・!なんていう方も安心です♥


次回は真面目にブログ更新します!!!!!!!!!!!

いろいろ試す23

せっかく貴重なGWの休みだというのに何をやっているんだ私は・・・
でもこれを消化しないと先に進めないというBADハマリ状態なのです・・・




●FTDIのFT232Rはぱちもんを撥ねるドライバが出てFT232Rの安いぱちもん
 使えなくなったから中華製のCH340G使おうぜムーブメント

みなさんはすでにご存知のこととは思いますがFT232Rはぱちもん対策が仕込んで
あってあんなことこんなことでぱちもんを使えなくさせています。
中華製のFT232R基板はまずぱちもんなのが前提だそうでぱちもん愛好家の方には
FTDIのドライバ改変で使えなくなるのは死活問題なのは必須です。そういうわけで
中華製のUSB-シリアル変換ICであるCH340Gを使おうという動きがあるようです。

ねむいさん的には何か大前提が思いっきり間違ってる気がしますが「自己責任
なら良いのではないでしょうか自己責任なら」といい居たいところですが大抵は
ぱちもんに分かって手出す人はケチなくせに文句だけは百人前でそういう人に
関わると時間と金を浪費してしまいますので皆様方はそういう人種を機敏に察知し
いち早く距離を置かれることが良いと思います。

…すみません話がそれてしまいましたが残念ながらCH340Gにもぱちもんが存在している
ようです。こちらをご覧ください。真ん中あたりにくわしい解説の画像があります。

CH340Gのぱちもんの見分け方として1Pinのマーキングの丸の削りが大きく広い
物が正規品で丸が小さくクレーター状に削られてるものがぱちもんだそうです。


ねむいさんも何故かCH340Gの出来合いボード持ってました・・・そして・・・

ぱちもんでしたー!!!!
クソァ!!1!1!!1



ちなみにぱちもんCH340Gは公式のドライバ宛がっても上手く動作しないようで
やっぱし中華メーカといえどもしっかりドライバでぱちもん対策してるようです。
このへんFTDIやProlificも同じなのでたとえイタチごっことなろうとも
メーカの自衛策としてぱちもん対策を仕込むのは必然となっているようですね。

安物買いの銭失い、安全/安心は金で買うものとはよく言ったものです。
たまにその売り物の安全安心すらぱちもんのことがありますけど…ふふふ。

20160512追:
こちらの方のブログのコメントに具体的な情報を見つけました。以下引用。

Commented by 中華マニア at 2015-04-24 10:11 x
CH340G自体にも通電していると内部のボンディングワイヤが焼き切れて
すぐ使えなくなる粗悪な偽物があふれかえっているそうです。

あれ…副業先で生産が間に合わず海外の別ルートで購入したNxP(xは伏字のx)製の
FETで似たような経験したような…


●FatFsが0.12にアップデートしてついにexFATに対応!!
GW前にChaN氏のFatFsがexFATに対応してアップデートしておりました。
64GByte以上のSDXCカードが安価で販売されるようになった今、exFATへの対応は
必然であるといえるのです!
・・ぇ?FAT32で無理やりフォーマットできるですって!?それはおいといて・・・

ところでSDHCとSDXCの違いは何か、どうやって見分けるのかという素朴な疑問が
わきますが規格では64GB以上の容量を持つカードがSDXCとなっています。
一般の方が単純明快に見分けられるたった一つの方法です。
SDHCはどう頑張っても32GBどまりです。この辺はこちらの方の解説が詳しいです。
逆に言うと128GBのSDHCとかは絶対に存在しないのでぱちもんであるとわかります。
海外通販でだまされないように注意してください。

ソフトウェア的に見分ける方法はいくつかあって前回もさらっと触れましたが
SCRを読み出しSD_Securityフィールドの値を見ることでも簡単に判別できます。
SDXCはここの値が必ず4になっています。ここの値はSD_SpecのVerには関係あり
ませんのでSDSpecのVerが4でもSDHCだったり3のカードでもSDXCなのが存在する
のは前回の読み出し比較でご存知だと思います。


さて、exFATにすることでFatFsがどういう挙動になるかを実際にフォーマット別
に比較してみました。使用するカードは前回へなちょこ判定したSuperTalentの
64GBのカードです。


前回無理やりFAT32にフォーマットして使ったといいましたがWindows上ではSDXC
カードはほぼ強制的にexFATでフォーマットされてしまうのでParagonHardDiskManager
を使いFAT32にフォーマットして使いました。
exFATのフォーマットについてはもちろんおなじみのSDFormatterV4.0です。

というわけでChaN氏のFat情報を読み出すfsコマンドといつものシーケンシャル
リードの速度比較を行ってみました。STM32F7-Discoveryで行ってます。

※FAT32フォーマット
FatFs module test terminal for STM32F746NGH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : May 4 2016
>fs
FAT type = FAT32
Bytes/Cluster = 16384
Number of FATs = 2
Root DIR entries = 0
Sectors/FAT = 30576
Number of clusters = 3913672
Volume start (lba) = 2048
FAT start (lba) = 2080
DIR start (lba,clustor) = 2
Data start (lba) = 63232

Volume name is SDXC_64GB
Volume S/N is 7022-3F80
...
19 files, 520994673 bytes.
2 folders.
62618752 KiB total disk space.
62109728 KiB available.
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 15414 kB/sec.

※exFATフォーマット
FatFs module test terminal for STM32F746NGH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : May 4 2016
>fs
FAT type = exFAT
Bytes/Cluster = 131072
Number of FATs = 1
Root DIR entries = 0
Sectors/FAT = 16384
Number of clusters = 489208
Volume start (lba) = 32768
FAT start (lba) = 49152
DIR start (lba,clustor) = 4
Data start (lba) = 65536

Volume name is SDXC_64GB
Volume S/N is DF51-7DE4
...
19 files, 520994673 bytes.
2 folders.
62618624 KiB total disk space.
62107904 KiB available.
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 18442 kB/sec.

なん・・・だと・・・!?
exFATにしたらへなちょこじゃなくなった・・・!?
exFATになってクラスタサイズがデカイのが効いているのかもしれません。

FatFsのexFATの対応はまだ始まったばかりでバグも洗い出されて洗練されて
いく真っ最中ですのでこれからの発展に期待ですね。


ついでにFatFsのexFAT対応する時の注意点をいくつか・・・
1.常にLFN対応が必須
 exFATはロングファイルネームしか存在しないためです。それに伴って従来の
 8.3形式ファイル表記に頼ったプログラムだと既存のものから0.12にアップ
 デートする際にかなりの改修が必要です。

2.そんなわけでメモリ消費量が多くなる
 これも致し方ないですね。SRAM容量32kByte以下の小規模マイコンはexFAT
 対応はやめたほうが無難でしょう。尤も32GB以下のSDHCもまだまだ生産されて
 流通しているのでSDXCしかカードが無い!って事態は当分の間無いといえます。
 無理にexFAT対応にするべきではありません。ライセンスの問題もありますから。


・業務連絡・
ChaN様へ
もしここ見てたら"Well written implementations for STM32F/SDIO and LPC2300/MCI"
の"STM32F/SDIO and LPC2300/MCI"のところを"STM32F/SPI & SDIO and LPC4088/SDMMC"
に書き換えておいてください・・・。

↑ご協力ありがとうございました(ぺっこりん


皆様へ、
おきぱSTM32F4STM32F7向けのいつものはFatFs0.12に対応してすでに公開
しております!もちろん0.12向けのパッチも適用済なのでどしどしご利用ください!



●4GBのSDカード
かつて4GB以上の容量をサポートするSDHCの規格が登場し実際に市場に出回り
はじめる過渡期に4GBの容量を持ちながらSDv1規格で動作するいわゆる"規格外"の
SDカードが存在していました。

いったいこのカードはどのような動作をするのか!?実際に現在でも流通している
カードを購入して調べてみることにしました。


ebayでドイツの販売主から購入しました。SDV1.1規格の4GBのSDカードでSDHCに対応
しないちょっと昔の機器で活躍するかも!ていう触れ込みです。

さっそくねむいさんのいつものでSDカードの情報を読み出してみました。
が・・・・
>ds 0
rc=0
Drive size: 7784448 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 1D B1 7F 80 0A 40 00 39 @..2[Y.......@.9
CID:
00000000 1B 53 4D 46 46 46 46 46 10 00 00 20 46 00 FC F3 .SMFFFFF... F...

Parsing SD CID Register
Manufacturer ID :0x1B
OEM/Application ID :SM
Product Name :FFFFF
Product HwRev :1
Product SwRev :0
Serial Number :0x00002046
DateCode.Month :12
DateCode.Year :2015

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 02 00 00 00 04 04 90 00 08 05 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....
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 80 00 00 00 00 00 .5......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDHC Card!

・・・
なんですかこれ単なるSDHCじゃないですかーヤダー!!!
・・・ちなみにh2testwでも調べましたがカードとしてはちゃんと4GBの容量をもった
"SDHC"でした・・・ビキビキ


ぱちもんつかまされたと思って捨てるのもあれなので副業先の修理品撮影用でぢかめ
の記憶素子として利用することになりました。
が・・・
後輩から「ねむいさんこのカード1GBしか認識しないんスけど?」と文句を言われ
このカードのホントの力を知ることになります。

後輩が撮影した画像データを取り出そうとして使ったUSBカードリーダーは10年
以上前の骨董品で、4GBに替える前のでぢかめ用SDも時代遅れの1GBでした。
もちろんこのカードリーダはSDHCを一切認識しないため私が提供した4GBのカードが
容量が変だとはいえ認識すること事態がおかしいのです。

ねむいさん後輩からそのカードを取りかえし、デバッガで動きを追ったところ以下の
事実が分かりました。

1.イニシャライズ時に最初にCMD8(SDv2専用の初期化コマンド)を投げていると
 SDHCとしてブロックアドレッシングモードで動作する。
2.ACMD41をいきなり投げると(SDv1の初期化)SDSCとしてバイトアドレ
 ッシングモードで動作する

つまり新旧の初期化方法のどちらでも正しくカードを初期化できて正しく動作する
ように作られたいわば魔法のカードだったのです!!!

ねむいさんのおきぱのFatFsの移植サンプルはSDカードの初期化手順がCMD0->CMD8->
ACMD41というSDv2もSDv1も包括する流れだったので必ずSDHCとして初期化されて
しまうのでぱちもんだー!と誤認してしまいました。

以下に通常のSDv2の初期化とわざとCMD8を飛ばしてSDv1で初期化したときのカード
情報の違いの差を示します。
・SDv2
FatFs module test terminal for STM32F746NGH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 28 2016
>fl
----A2011/07/27 23:51 351416 0c4f42da.jpg
----A2015/03/03 15:07 307254 1c3e744f.bmp
----A2010/07/20 13:52 1993197471 91sp2_quartus_free.exe
----A2011/06/04 06:07 324588 1c3e744f.jpg
----A2010/03/24 17:47 132389 002.jpg
----A2016/01/30 10:54 244527 2d35e710.jpg
----A2013/06/20 22:49 47566 2ecd0b3e.jpg
----A2010/03/24 17:48 198903 003.jpg
----A2011/05/25 01:11 53023 3c3ba2bd.jpg
----A2010/03/24 17:48 137038 004.jpg
----A2013/05/29 21:02 22235 4b62585a.jpg
----A2012/09/19 23:32 80490 4db4ceb4-d00d-5891-b900-4f97ec745309.image.jpg
----A2010/12/02 23:28 102769 4e61b17f.jpg
----A2010/03/24 17:48 148307 005.jpg
----A2015/07/08 14:32 318848704 install_sw4stm32_win_32bits-v1.2.exe
----A2016/02/26 11:57 421760368 MDK518.EXE
----A2008/09/12 20:19 47341 2005-03-24otter02.jpg
17 File(s),2736004389 bytes total
0 Dir(s), 1239515136 bytes free
>fs
FAT type = FAT32
Bytes/Cluster = 32768
Number of FATs = 2
Root DIR entries = 0
Sectors/FAT = 948
Number of clusters = 121334
Volume start (lba) = 8192
FAT start (lba) = 14488
DIR start (lba,clustor) = 2
Data start (lba) = 16384

No volume label
Volume S/N is 3688-4D7E
...
17 files, 2736004389 bytes.
0 folders.
3882688 KiB total disk space.
1210464 KiB available.
>ds 0
rc=0
Drive size: 7784448 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 1D B1 7F 80 0A 40 00 39 @..2[Y.......@.9
CID:
00000000 1B 53 4D 46 46 46 46 46 10 00 00 20 46 00 FC F3 .SMFFFFF... F...

Parsing SD CID Register
Manufacturer ID :0x1B
OEM/Application ID :SM
Product Name :FFFFF
Product HwRev :1
Product SwRev :0
Serial Number :0x00002046
DateCode.Month :12
DateCode.Year :2015

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 02 00 00 00 04 04 90 00 08 05 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....
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 80 00 00 00 00 00 .5......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDHC Card!


・SDv1
FatFs module test terminal for STM32F746NGH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 28 2016
>fl
----A2011/07/27 23:51 351416 0c4f42da.jpg
----A2015/03/03 15:07 307254 1c3e744f.bmp
----A2010/07/20 13:52 1993197471 91sp2_quartus_free.exe
----A2011/06/04 06:07 324588 1c3e744f.jpg
----A2010/03/24 17:47 132389 002.jpg
----A2016/01/30 10:54 244527 2d35e710.jpg
----A2013/06/20 22:49 47566 2ecd0b3e.jpg
----A2010/03/24 17:48 198903 003.jpg
----A2011/05/25 01:11 53023 3c3ba2bd.jpg
----A2010/03/24 17:48 137038 004.jpg
----A2013/05/29 21:02 22235 4b62585a.jpg
----A2012/09/19 23:32 80490 4db4ceb4-d00d-5891-b900-4f97ec745309.image.jpg
----A2010/12/02 23:28 102769 4e61b17f.jpg
----A2010/03/24 17:48 148307 005.jpg
----A2015/07/08 14:32 318848704 install_sw4stm32_win_32bits-v1.2.exe
----A2016/02/26 11:57 421760368 MDK518.EXE
----A2008/09/12 20:19 47341 2005-03-24otter02.jpg
17 File(s),2736004389 bytes total
0 Dir(s), 1239515136 bytes free
>fs
FAT type = FAT32
Bytes/Cluster = 32768
Number of FATs = 2
Root DIR entries = 0
Sectors/FAT = 948
Number of clusters = 121334
Volume start (lba) = 8192
FAT start (lba) = 14488
DIR start (lba,clustor) = 2
Data start (lba) = 16384

No volume label
Volume S/N is 3688-4D7E
...
17 files, 2736004389 bytes.
0 folders.
3882688 KiB total disk space.
1210464 KiB available.
>ds 0
rc=0
Drive size: 7784448 sectors
Erase block size: 512 sectors
Default r/w block size: 2048 bytes
Card type: SDv1
CSD:
00000000 00 0E 00 32 5B 5B 03 B6 1D B3 FF 80 0A C0 00 E9 ...2[[..........
CID:
00000000 1B 53 4D 46 46 46 46 46 10 00 00 20 46 00 FC F3 .SMFFFFF... F...

Parsing SD CID Register
Manufacturer ID :0x1B
OEM/Application ID :SM
Product Name :FFFFF
Product HwRev :1
Product SwRev :0
Serial Number :0x00002046
DateCode.Month :12
DateCode.Year :2015

OCR:
00000000 80 FF 80 00 ....
SD Status:
00000000 80 00 00 00 00 00 00 20 04 04 90 00 08 05 00 00 ....... ........
00000010 00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....
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 25 80 00 00 00 00 00 .%......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :2
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDSC Card!


もちろんどちらの初期化手順でも得られる使用可能総容量はCSDレジスタの値自体が
アジャストされ変化するためSDv2,SDv1のどちらの初期化手順でもまったく
同一の容量となり、さらにバイト/ブロックアドレッシング両方の読み書きも
すべて正しく行えております。
しかもご丁寧にSCRのSDSecurityのバージョンまでちゃんとアジャストして
SDv1で初期化したらちゃんとSDSCとして認識されるという充実ぶりです!!



ついでですがその他の"4GBのSDカード"も調べてみました。これはTOPRAM製の
カードです。結果から言うと同じく初期化手順の違いでSDSCにもSDHCにも化ける
タイプでした。



こちらは規格外カードの本家ともいえるTranscendの4GBカードです・・・がUSEDで
しか手に入らなかったのでなんか茶色いのがいっぱいこびりついててきちゃない・・・

中華からかった中古なので何がついてる分からずIPAでよごれをこすって落とし
まくって2時間後にようやく動作確認・・・


こいつこそホントに単なるSDHCでした!!!!!F**K!

20160512追:
後でさらに調べて分かりましたが"SD Compatible"とパッケージにはっきり
書かれたものでない限りはSDHCの表記が無くてもただのSDHCでSDv1の
初期化は一切通らないそうですF++K!!!



というわけで規格外な"4GBのSDカード"は規格外ながらも今日もどこかの
ちょっと古い機材で活躍しているかもしれません。


●秋月の006Pリチウム電池
テスタの電池用に秋月さんの006P型リチウム電池を購入してみました。


一般の006Pと比べるとやたら軽くちょっと大きく見えて不安になります・・・


一応無理なく収納できました★


動作も問題ありません♥
実はもう4ヶ月近く使用していますが今のところ電圧が出なくなったり爆発
したりとかはなく、至って問題なく使用できています。このリチウム電池は一
般的な006P型乾電池と比べると電流容量はかなり低いですがテスタのような
消費電力が低い機器で使用する分にはまったく問題は無いのでオススメです♥

技適マーク付き★STマイクロ製BTモジュールを使ってみる

あけましておめでとうございます。
といいたいところだけどぜんぜん明けてねぇよバカヤロコノヤロ(たけし風に)

今年も残すところ11ヶ月きってしまいました。ぇっと年末から続く副業先(ねむいさん
の本業は虹裏メイド)のトラブルはまだぜんっぜん解決してませんが意地でもぶろぐ
は更新します!!!!!あと頂いたコメントやご質問の返信もわずかな時間を見つけ
て行っていますのでもう一ヶ月くらいおまちください・・・


さて、今回紹介するのはSTマイクロ社製のBluetoothモジュールSPBT2632C2A.AT2です。
このモジュールはRN-42と同じくUARTでやり取りができるものですが、Bluetoothの
バージョンは3.0,そして実装面積もRN-4x系より少ない逸品です。


↑SPBT2632C2Aデータシートより
内部構造はRFモジュールとその制御部に分けられており、制御用MCUとしておなじみ
STM32が使用されております!ファームウェアもUARTブートローダで更新が可能です。



そしてもちろん技適マークがあります!!

ねむいさんより注:
ご多忙に漏れず海外通販で扱っている同型番のモジュールには技適マークが刻印されて
いないF**Kな奴があります。現時点で確実に技適マーク入りの奴が購入できるのはRS
コンポーネンツさんのところからだけ
です。


ていうわけで早速Xbee風にしてみます。やっぱしプラットフォームを合わせておくと
らくちんですね〜・・・
どうでもいいけど秋月さん早くESP-EROOM-02のXBeeピッチ変換出してくれないかな・・・


電源を投入すると"Amp'ed Up!"とかいう得体の知れないサウンドデバイスとして認識
されます・・・一瞬購入するモジュール間違えたと思いましたがこれで正しいようです。


やっぱしオーディオとビデオデバイスとか出てますがちゃんとシリアルポートは作成
されるようですよかったよかった・・・。


デフォルトでは115200bps,8ビット,ノンパリティ,1ストップビットとなっています。
画像はBluetooth経由で相互に通信しているところです。ボーレートは2000000bpsとか
むちゃくちゃな高い値も設定できるようですが戻せなくなるとやばいので230400bps
までしか試してません。


さらにこの時Bluetoothとして通信が確立している時はGPIO1がHiレベルとなり、LED等
を接続して画像のようにインジケーターとして利用できます(デフォルト時)。


GPIOの割り振り表です。後述しますがATコマンドで別の機能も指定可能です。
注意すべき点はI/Oの出力レベルが3.3Vでは無く2.5Vとなっている点です。これはモジ
ュール内部でレギュレータがかまされ中のSTM32とRFモジュールが2.5Vで駆動している
からで、ここにVfの高い青色LEDとかを直結すると全く光りませんのでご注意下さい。
ねむいさんまんまと嵌りましたorz無難に赤色で行きましょう・・・。


モジュール自身の設定は"abSerial"なる独特なATコマンド群で可能です。
ちゃんとコマンド表もありますが独特すぎて最初は何がなんだか分かりませんでした。

とにかく"AT+AB なんたら"のフォーマットでモジュールとお話できるようです。
たとえばモジュール全体のバージョンを知りたい場合は・・・
"AT+AB Version"で確認できます。

設定を間違えた時にボーレートを強制的に元に戻す技が現時点で見当たらなかったので
これ以上はまだ触ってませんがSPIやI2Cを吐かせたりSTM32ならではの柔軟な設定が
可能なようです。


というわけで2ヶ月以上前に購入したモジュールをようやくほんの少し弄って紹介
することができました。このモジュール、価格もそこまで張らないので諸般の事情で
RN-4x系のBluetoothモジュールが使えない時の強力な選択肢となると思います。

今現在冒頭の理由で時間がぜんぜん取れなくて買ってもずっと評価してない無線モジ
ュールはまだまだたくさん控えていますのでこんな感じでやっけつの紹介となって
いくでしょうけどもご期待ください!

いろいろ試す22

30日は〆のトレランに行くので年末恒例の奴を今やらせていただきます・・・


●フェライトビーズの使いどころ
ねむいさんはおきぱでSTM32のFatFs移植サンプルを公開してることから「FatFsが動き
ません><」という漠然とし過ぎる困った質問を今でもコンスタントに頂くのですが、
もはやその原因の99.99%が単純な結線ミスとか接触不良が起こりやすいブレッド
ボードで配線30cmくらい引き伸ばしまくって通電してたとかそんなモン動くわけ無い
でしょ的内容だったのですがまた新たに別のクリティカルヘンテコな報告を頂きました。

最短の配線でSTM32F407ZGT6の基板を起こしたにもかかわらず昨今のUHS-1のカード
ではSDIOで認識すらしない、クロックの速度を落としてもダメで昔のUHS表記が無い
Class6とかのカードならOKというこれまた奇怪な不具合だったのです。

STM32のSDIOは1.8VのUHS-1の高速クロックモードには対応しておらず、早くても
HSモード(3.3V/52MHz)ですがHSどころかNSモード(25MHz Max)でもダメとのこと。
ダメなカードも型番を教えてもらったのでPCOnes'sで購入して私も試して見ました。
TranscendのmicroSDHCカード Class 10 UHS-I 600x (Ultimate) なるものです。

謎のMLCアピール・・・。


私が持ってるSTM32F407ZG系の基板は紅牛に無理やりF4を乗っけた基板です。配線長も
なるべく質問を頂いた方と合わせるようにmicroSDソケットを無理糞つけてました。

で、こいつで試すと確かにHSどころかNSモードのクロックでも全く認識しなかった!
念のため別の会社のUHS-1のカードも複数枚試しましたが結構な確率で認識できない
ものが存在していました・・・!UHS無しのClass10表記の奴やねむいさん愛用のATPの
Class6の4GBの奴
はエラッタもちのF407系のいんちきHSモードでもバッチリ認識できて
るのですが・・・ひとまず信号の測定に掛かります。


これがATPのmicrosdhcのクロックの波形(NSモード/24MHz)です。


んでもってこっちがTranscendのほうの波形(NSモード/24MHz)。
ATPのよりも信号のふり幅が狭くなおかつリンギングも激しくなってる感がしますね。


波形の測定に関してはGNDリードの影響を抑えるために当然最短にして測定しています。
あとPCオシロのトリガはETSモードにして等価サンプリングレートを10GHzとしています。
STM32のSDIOのクロックはパワーセーブにしない限りは常に出っ放しになるので繰り
返し信号として測定でき、精確な波形測定ができるわけです。

話を戻しますが二つの波形の違い、なぜこんなに違うかですがこれはUHS-1のカードは
100MHz以上で動作できるUHSモードで転送する際はNSモードやHSモードよりも高速な
立ち上がり/立ち下がりを当然要求されるわけでそれに合わせてI/Oをこしらえていますが、
悪い条件が重なったときに信号の反射によってオーバーシュートやリンギングが激しく
出ることになります。
過去のClass表記のみのカードでは高々50MHzまで動けたら良かったので高速なI/Oを
必要とせず、オーバーシュートやリンギングは同条件でもそこまで大きくはならない
・・・と想定できます。

さて、状態は観測できたので後は対策です。こういうケースの場合はフェライトビー
ズを各信号ラインに直列に入れてやると効果が出るはずです。


いろいろ試してねむいさんの手持ちのフェライトビーズの中ではBLM18BB121SN1D
かなり効果があることが分かりました。この対策で認識できなかったUHS-1のカードも
無事見ることができました(NS/HSモード共)。


これが対策後のTranscendのCLKの波形です(NSモード/24MHz)。
リンギングがしっかり抑えられてるのが分かりますね〜。

こんな感じに無理糞つけけております。
念のためTranscendのとは別の認識できなかったUHS-1のカードも試してみましたが
すべて無事認識できるようになりました。ちゃんと対策として効いているようです♥

これより大きい抵抗値の奴ではHSモードでクロックが大きく崩されすぎてダメになって
しまいます。やっぱり程々が大事です。
また、秋月さんのとこで購入できるタイプのフェライトビーズでは特性が少しなだらか
なため余り効果が出ませんでした。とはいえねむいさんが選んだ奴もかなりピーキー
なのでそのまま真似しても多分効果は出ないと思います。

こういった信号の反射の影響度合いは設計するボードごとに大きく変わってくるので
オシロとにらめっこしながらカットアンドトライをしなければならない領域です。
GNSSモジュールの時も言いましたがむやみやたらにフェライトビーズを突っ込み
まくっても逆にノイズやリンギングをパワーアップさせてしまうことになりかねません。
また、オシロのプローブも見たい信号を正しく測定できるようにGNDリードを超最短
にするなどの配慮も必要で開発者としての様々なセンスが問われることになります。

と、ここまで苦労してSDIOの信号波形整て認識できるところまで持ってきましたが、
GPIOが速度面で強化されたSTM32F43x/42x系とかF7系を最初から使っとけば
上記のめんどくさいことをなーんにもやらなくても安定してSDカードを読み書き出来
たりします・・・酷いオチだ・・・。




全然関係ないですが大阪日本橋のPCOne'sでSDカードのついでに買ったスマホ置き台が
STM32F7Discoveryとぴったりフィットできる形状なので重宝してます♥



●GCC ARM Embedded in Launchpadの2015年Q4版が出る!

一年に4回リリースされるLaunchpad GCCの最新版がリリースされています。
今回はついにGCCバージョンが5になりました!

早速新旧比較をしてみたいと思います。まずは同じ条件でビルドした際のバイナリ
サイズ比較です。条件は以下のとおり。

F7のいつものの20151224版
・SDMMCのクロックはNomalSpeed(24MHz)
・-Ofast,HardFP
・AXIMからフラッシュ実行/SDRAM有効/フォントは内蔵フラッシュに格納
・使用SDカードはAF4GUD、SDFormatter4.0でフォーマット

旧:2015q3版(GCC4.9.3)

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288]
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 602096 0 602096 92ff0 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
599808 2288 821392 1423488 15b880 main.elf


新:2015q4版(GCC5.2.1)
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.2.1 20151202 (release) [ARM/embedded-5-branch revision 231848]
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 612272 0 612272 957b0 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
609984 2288 821392 1433664 15e040 main.elf


バイナリサイズは2015q3版より10kByteほど増えてますね・・・
今度は実行処理速度比較です。SDRAMの時と同じようにlibjpegの展開時間の比較を
行ってみました。


旧:2015q3版(GCC4.9.3)


新:2015q4版(GCC5.2.1)

・・・イケてるじゃないですか・・・(セルピコ顔で)
なんか去年もモズグス編のセルピコさんになった気がしますが、最適化の悪影響が及んでる
かもしれないのでもうすこし様子見して安全性を確かめたいとおもいます。丁度明日は今年
最後のトレランに行くので屈作のSTM32Primer2GPSTr@ckerに2015q4版でビルドした
バイナリを書き込んで試してみるつもりです★



●Firefox版赤福が署名に対応する
虹裏関連のお話ですがFirefox版赤福spが署名チェックに対応することになりそうです

FirefoxはVersion44から拡張の署名が強制になり署名が無い拡張は撥ねられて動作不
可能になるとアナウンスされており署名が無い赤福spが使えなくなると言われていましたが・・・
作者の方ももう気付かれて対処されるようなので等分の間は安泰でいられると思います♥

この調子で合間合間にも対応してくだち・・・



●年末恒例のねむいさんFAQ

Q:わたしは(何らかの下らない他人の自慢話なので省略)
 なぜOpenOCDにこのバグが組み込まれてしまったか考えてみてください。
 ↑(原文ママ)

A:ねむいさんこの質問風八つ当たりにうっかりクソ真面目に答えてしまいました。
 ウブなねむいさんはこのバグの部分とは無関係だったにもかかわらずソースコードの
 更新履歴を丹念に調べエンバグされた経緯と対策まで連絡してあげました。もちろん
 質問されたクソ野郎方からその後どうなったか返事なぞまったくいただいておりませんが、
 実はkinetis.cにある致命的な"このバグ"はまだ修正されておりませんが、次に同じような
 こと聞かれたら適切な返事を返してあげようと思います。

 バカめと。

 ↑20160212追:
 kinetisドライバに真っ当にご助言いただいた方々にこれは俺の事かとお叱りの
 メールを幾つもいただいてしまいました。誤解を招きまことに申し訳ございません。

 致命的なバグはとあるぱちもんデバッガ使ったときに発動するのですが、
 ねむいさんに対してそういう情報隠して正規品使ってると秒速でバレる嘘ついて
 "動くようにしろ""対処してください"とかいって情報聞き出してくる奴は絶対に
 許さないのでそういった御仁たちは拙者尽く伊達にして返すでござる。

Q:ねむいさんってツイッターとかしてないんですか?
 所詮は批判を恐れ安全な場所から一方的に意見を言い放つことしか出来ない
 ティキンなのですか?
A:それはイエスでもありノーでもありますのだわ・・・(第五ドール風に)
 ねむいさんはいろいろあってツイッターやめた代わりにこのねむいさんのぶろぐ
 立ち上げました。かれこれ7年位前のはなs・・・グハッ!!!!


Q:ねむいさんってLINEとかしてないんですか?
A:ま だ ガ ラ ケ ー 使 っ て ま す

Q:スマホでピッ!簡単電子工作★
A:ま だ ガ ラ ケ ー 使 っ て ま す
 っ て 言 っ て る で し ょ コンチクショー




(以下ほぼ実際にあったやり取りですだいぶ前の話ですがもう時効だから書きます)
Qr:鶴岡工場(旧NECエレ系列工場)閉鎖ね
A:あっそ良かったねおめでたうございまs・・確かここって旧NECの・・・
Qr:ついで(?)にあんたのところのASIC生産中止だね
A:何ですって・・・!?
Qr:この前のが最終ロットね。今までご利用いただきありがとうございますを
A:あ”!?(CV柴田理恵)
Qr:代わりに弊社のSmar●tAnalogをご採用願います(営業スマイル)
A:カエレヤ!!
 (ここでルネサスと完全に手が切れPSoC5を採用しかけたが・・・)

Qp:gff...ねむいさんねむいさんそのセミカスタムのASIC、こちらでも
 起こせますよ・・・(はげたかのような目で)
A:オゥこれはありがたい・・・

Qrohm:ルネサスさんからのディスクリートデバイスの置き換え表ありますよ・・・
   ・・・gff(はげたかのような目で)
A:オゥこれはありがたい・・・

ディスクリートデバイスは旧NECエレでがっちり固めてたからヤバかったです。
R○HMさん(○は伏字)ありがたう!!!
今は東芝半導体がチャレンジ()の成果もあってRenesasに合体しそうでやばそうですね・・・
東芝さんのもかなり使ってるんですけぉ・・・


さぁそれはおいといて明日も早いから寝ましょう・・・Zzz・・・

↓としあきくんからのリクエスト↓
Q:カレン金剛の声の区別が付かないデース
A:ネムイサンも区別付かないデース(CV:柴田理恵)
 ・・・と言うのはおいといておすぎさん(悪堕ち)とピーコさん(純粋悪)に同時に襲われたら
 ピーコさんと間違えて悪堕ちした無罪のおすぎさんをうっかり攻撃してしまうくらい
 "うつけ"です・・・

Q:ねむいさんって雑誌に投稿したりしないの?
A:どのジャンルのこといってるのか分かりかねますができたらとっくにやってます。
 そいえば2014年初夏にC9出版のドメインのメアドで「記事作成を手伝ってみませんか?
 という何か目的をぼかした内容のしかも文語体と口語体が混じっておまけに芝まで生や
 したメールを頂いたのですがちょっと怪しかったのでCQ出版のお問い合わせにメールで
 (差出人の方の名)さんはそちらに在籍されていますか?とたずねたのですが問い合わせを
 してからはや約1年と8ヶ月、何の音沙汰もありません。
 問い合わせついでにトラ技の誤植を指摘したのがいけなかったのでしょうか・・・
 やっぱし本当にフィッシング目的の偽装メールだったかも。

Q:ブラギガスを検索したら諸星きらりが何故かサジェストに出てきました。
 虹裏メイドのねむいさんはなにか知ってそうな顔してますが・・・洗いざらい吐け
A:にょわー(野太い無理やりな高い声で)
 ↑もし隣からこんな絶叫きらり語聞こえたら速攻警察屋さん呼びますよぅ!!

STM32F7を使ってみる7 -秋月さんよりF7Discovery販売記念-

※とある大切な方の訃報を受けて霊場めぐりをしていたため更新が一週間以上遅れて
 ます。すみません。


先々週末、秋月さんよりSTM32F7-Discoveryが販売されました
入手しやすくなった事によって皆さんもF7に触れるチャンスができたと思います。
ねむいさんもF7ネタで一つ記事を書きたかったのですがいまいち"ぱんち"が弱く
更新に躊躇していたので今回の販売開始は渡りに舟でした。しかももう一つ嬉しい
ニュースも同時にでてきました。


●OpenOCDがSTM32F7の内蔵フラッシュ書き込みに正式対応
7月上旬、私が最初にいじりだしたころからF2/F4系と別系統のSTM32F7のテスト用
ドライバは存在していたのですが秋月さんの販売と時を同じくしてOpenOCDにF7系の
フラッシュ書き込みサポートがF2/F4ドライバに正式にようやく追加されました


Corex-M7はL1キャッシュを持つのでフラッシュ書き込みルーチンを呼び出すとき
にメモリバリア命令を張って意図した手順で書き込みのための命令を実行させる
ようにしないといけませんでした。
最初にコミットされた時はそんな理由でF7専用のフラッシュになっていましたが
同じMPUを持つF2/F4系でも問題が無かったため結局stm32f2x.cに統合されています。

> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f target/stm32f7discovery_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.10.0-dev-00104-gf3be0f6-dirty (2015-11-13-09:52)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.219974
Info : stm32f7x.cpu: hardware has 8 breakpoints, 4 watchpoints
stm32f7x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0803276c msp: 0x20010000
auto erase enabled
Info : device id = 0x10016449
Info : flash size = 1024kbytes
stm32f7x.cpu: target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x20000046 msp: 0x20010000
wrote 786432 bytes from file main.elf in 18.501879s (41.509 KiB/s)
stm32f7x.cpu: target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20010000
stm32f7x.cpu: target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20010000
stm32f7x.cpu: target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20010000
verified 600552 bytes in 2.451303s (239.251 KiB/s)
shutdown command invoked

> Process Exit Code: 0
> Time Taken: 00:21

書き込みはこんな感じです。以前と全く変わってませんね〜。
私が提供しているバイナリはもちろんSTM32F7-Discoveryに対応しています★
また、以前も伝えましたがSTLink/V2-1のファームは2.24.11以降にアップデートして
おいてください。古い番だとmbedのMSCの方のインターフェースと干渉して書き
込みが必ず失敗してしまいます。秋月さんで購入できる奴はさすがに最新版に
なってるはずですのでたぶん問題ないでしょうけど。


●MPUとSDRAMのキャッシュ設定
過去にも少し触れたMPUの事ですが、F2/F4系ではほとんど出番がなかった代物ですが
L1キャッシュが実装されたF7系では極めて重要な意味を持ちます。しっかり考えて設定
しないとパフォーマンスに大きな影響が出てしまいます。

書くいう私もキャッシュの概念をよく理解してなくてDMAで無駄に苦戦したりしていましたが
新たにFMCを使ったSDRAMで手落ちを見つけてしまいましたorz


AN4667より引用
通常はFMCはD-Cacheを通じてアクセス速度の向上が行われているのですが、それが
有効なアドレス領域はCortex-M7のコア上で制限があります。
SDARAMが割り当てられるアドレス(0xC0000000~)ではご覧のとおりキャッシュメモリの
恩恵にあやかることができません。


AN4667より引用
FMCのSDRAMのアドレスをリマップしてキャッシュが効くアドレス領域に変える
方法もありますがMPUでキャッシュ可の領域に設定してしまう方が簡単です。


MPUの設定はこんな感じです。キャッシュ有効の時に"MPU_ACCESS_NOT_BUFFERABLE"
とするとライトスルーとなります。ライトバックは"MPU_ACCESS_BUFFERABLE"です。

なお、FMCやSDRAMを有効にしてなくてもMPUはそれらと完全に分離しているので、
設定した瞬間にいきなりHardFaultとかになることはありません。
また、QSPIの領域については前途のとおり元からキャッシュ可になっていますので
特にMPUを設定する必要はないです。


てわけで早速いつものjpegファイルのデコード時間で比較してみましょう。
その1.フラッシュインターフェースはAXIM

↑MPUは何も設定してないSDRAMのD-Cache無効状態です。
 最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。


↑MPUを使ってSDRAMのD-Cache有効、ライトスルーです。
 最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。


↑MPUを使ってSDRAMのD-Cache有効、ライトバックです。
 最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。


予想通りキャッシュ無効のデフォルト状態の方が断然はやi...

???
???どういうことなんだ???(←C.V.櫻井のイケボで)

キャッシュ無効が一番早いじゃないですかー!?たぶんAXIMバス経由でプログラムを
実行してるからバスのトランザクションとかキャッシュラインが干渉しまくって逆に
パフォーマンスが低下してしまったのでしょうね。
・・・すみません適当な考察で…てわけでAXIマトリクスの影響を受けないITCMからプロ
グラムを実行してみますか。

その2.フラッシュインターフェースはITCM

↑MPUは何も設定してないSDRAMのD-Cache無効状態です。
 最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。


↑MPUを使ってSDRAMのD-Cache有効、ライトスルーです。
 最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。


↑MPUを使ってSDRAMのD-Cache有効、ライトバックです。
 最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。

ITCM経由だとバスの競合が減りますので確かにキャッシュが効いているのが
分かりますね★
所で本来ならライトスルーよりライトバックの方が早くなるはずなのですが、ライトスルー
の方がほんの少し早い結果になりました。キャッシュを効かせているとキャッシュヒットと
ミスの時のブレ幅がかなり大きく出てくるのでそっちの方が気になるくらいですけど。

おきぱのF7のサンプルではAXIM/ITCMの両方でSDRAM領域のMPU有効・ライト
スルーキャッシュ設定にして更新しております。
以前はQSPI-ROMにFONTX2ドライバを置いていた場合文字の表示で崩れることが
あったのですがSDRAM領域もMPU・キャッシュ有効にするとそれが一切発生しなくなった
という副次的効果が見られましたのでAXIMだと若干パフォーマンスが落ちますが敢えて
MPUを効かせています。

もちろんキャッシュを経由するとDMAの問題がまた持ち上がってきますが私のサンプル
ではDMA2Dをそうなる使い方はしてないのが分かったのでDMA対策は特に行わず
様子見としております。

さらについでですがCubeF7もV1.2.0になってHALライブラリもV1.0.2にアップデートして
おりますので差し替えてあります。でもSDMMCのuint64で処理しなきゃならない処理が
uint32のままでまだ治ってないので私自らHALライブラリに修正を加えておきましたクソァ!

ESP-WROOM-02を使ってみる3 -そんな電源で大丈夫か-

20161231追:
ESP-WROOM-32ではさらにとんでもない自体に!!1!!!
20161231追:



2か月くらい前にESP-WROOM-02の紹介記事を2点書きました。それを多くの方が
紹介してくださったおかげで閑古鳥が鳴いていたこのぶろぐのアクセスも東海自然
歩道攻略時のころ
の全盛期まで盛り返し私もモチベもムクムク盛り返しております♥

多くの人の目に触れるとなると当然質問も多く頂くのですが「電源投入しても
文字列がずっと垂れ流されるだけでコマンドが全く反応しない
or最初は上手く
動いてたのに急にずっと文字列(orゴミデータ)が垂れ流しになった!ESP8266が
壊れたぞ!
」という不具合についての相談を多く受けるようになりました。

●文字列がダーッっと…
共通項は「文字列(orゴミデータ)が連続して垂れ流されて制御不能になる」です。
結論から言うとESP-WROOM-02に供給する+3.3Vの電流容量不足で起こる現象
なのですが、そのプロセスは以下のようになります。

1.電源投入or外部リセット

2.ESP8266のPOR/外部リセットのイニシャライズ
 (このあたりで文字列(デバッグメッセージ)が吐かれる模様)

3.電気喰いのRF部起動

4.電力消費過多で3.3Vがすぐドロップ

5.3.3Vラインがドロップして2.0V付近になるとESP8266リセット状態になる

6.少したってからLDOの保護機能等が解除で3.3V回復

7."2."に戻る

デバッグメッセージがダーと吐かれた直後にリセット掛かってまたデバッグメッセージが…
を繰り返すので"文字列が吐かれ続けて壊れた"ように見えるわけです。



ねむいさん愛用の秋月さんのXbee用のゲタ基板は150mAのLDOが乗っかっています
がESP8266の電源としてこれを使っていると上記のように2.0V近くまでおもいくそ
ドロップしてリセット->その後負荷が軽くなるので回復->また落ちるを繰り返して
しまいます。
根性があるLDOだと最初は最大定格越えても耐えられるのですが使ってるうちに
段々へばってきて上のサイクルを繰り返し、仕舞にEOSで完全に死んでしまいます。



そんなわけでねむいさんは電流容量1AのぱわふりゃーなLDO換装して多少の
電流の過渡応答にびくともしない最強に強まった電源に満足(LT1963A持ってくるまでも
ありません)でした。

したはずでした・・・!






勿論今回はこれだけで終わるわけではなく、皆さんの設計の参考として実際どれ
くらいの電流を消費しているのかを調べてみました。


ねむいさんのXbeeゲタ基板に+3.3Vの電圧と電流を測定できるように加工をして
電源投入直後や投入後の挙動別に各波形を見ていきます。
各種パラメータはもちろんすべてデフォルトの購入時のままです。
ESP-EROOM-02においては購入時のデフォルトはフルパワーです。


電源投入直後


↑の+3.3Vの立ち上がり時の拡大


リセット直後


RF出力時

ぱわふりゃーなLDO使ってるくせになんで3.3Vが思いきりドロップしてんだYO!
答えろYO!という突込みは後で解説することにしてRF出力時は平均280mA(ピーク値
は350mA以上)バリバリに使いまくっているのが分かると思います。
またリセット直後も40mSecもの間200mA以上(ピーク350mA強)ゴリゴリ消費しています。

ご覧の通り+3.3Vラインに供給する電流容量の事を忘れてESP-WROOM-02を使って
いると大きな電圧ドロップによる不安定な動作に悩まされ続けることになります。
しっかりオシロスコープ使って波形測定して確認する癖付けましょうね…。

ハードウエアの設計に慣れた人ならこんなの事前にオシロで電源ラインの波形を
観測して足回りをしっかり固めておいて当然の基本の"き"なのですが…
ねむいさんの懸念はライトユーザーの方たちがこの問題に引っかかり先に進めなく
なってしまうことです。

プロトタイピング用ボードはハードウエアの差異を隠ぺいしてソフトウエア作りに
集中できるようにするために元となるハードウエアはかなりタフに作りこまれています。
ていうかそうなるべきです。全ては信頼の元に成り立っているのです。

でも残念ながらそうなってないのばっかりですのでこれを機にしっかりオシロ
スコープ使って電圧波形くらいは確認する癖をつけましょうね…。


大事な事なので2度言いました。


macsbug氏の記事では各種Arduinoと組み合わせて使用した際の考察がまとめられて
いますのでプロトタイパーな皆様は一読されることをお勧めします。
氏のブログでは+3.3Vを作るLDOにフォーカスして言及されていますが私が以下で
述べるLDOの入力系統(主に+5V)についての考慮も極めて重要です。必ず読んでください!!!


●USBの+5Vは大丈夫か
上で行った+3.3Vの波形がドロップしちゃいけないのにドロップしてる件も調べて
みました。私の使用環境ではUSBの+5VからLDOで落として+3.3Vを作っています。
そんなわけで今度は5Vと3.3Vの波形を比較してみました。


オイー!!!!!!!!!
安物USB2.0ハブ(しかもセルフパワーなのに)元の5Vがおもいくそへばっていたorz

ねむいさんが使ってるLDOはDIODES-ZetexのZLDO1117ですが最大ドロップアウトが
1.2V(1A時)ありますので元が3.8V近くまで落ち込むくらい電流ひいてる状態だと
そりゃ駄目ですわ…。


↑DIODES-Zetex ZLDO1117データシートより引用
さっきの波形はRF送信時の約300mA近く引いてる時の電圧ドロップの波形ですが
グラフのまんまきっかり1V以上のドロップアウトですねorz
いくらぱわふりゃーなLDO積んでいても元のVinが貧弱だとこうなってしまいます。
あとコンデンサの容量を必要以上にむやみやたらに増やして茶を濁すのはねむいさんは
全くお勧めしません。今度は突入電流で素子が破損する危険性が出ますので。


てわけで大電流を引き出せられるセルフパワーなUSB3.0ハブの方に差し直して
測り直してみました。大分マシにまりましたね。
上半身に比べて下半身が貧弱だとやっぱりダメなわけですね〜足回りをしっかり
固めるのはプロトタイピングにこそ重要だと思います。


プロトタイピング用ボードだとUSBの+5Vを電源供給源としてそのまま利用する
場面が極めて多く出てくると思います。
何も考えないで使っているとこういった罠に陥って無駄な時間を費やしてしまい
ます。これを機にオシロスコープを使って電圧波形くらいはいちいち確認して
行く癖をつけておきましょう。


大事なことなので3回言いました。

20151203追:
ねむいさん的にはバッテリ駆動を見据えるならMAXで1A~800mA位の小型高効率
降昇圧DCDCを組みESP-WROOM-02専用の+3.3V電源とすることを提案します。

逆にUSBの+5V電源からだけしか使用するつもりがないならば超低ドロップアウトな
LDOであるADP3338、値が張りますが攻守共に最強のLT1963Aを提案します。
20151203追:





●おまけ
それじゃ他のWifiモジュールってESP-EROOM-02に比べてどんだけ電気喰ってるの?
というわけで手持ちのモジュールも測定してみました。
もちろん技適はばっちり取れてるのをチョイスしてます♥

その1:Xbee WiFi S6B

電源投入直後


↑の+3.3Vの立ち上がり時の拡大
IDDの測定レンジが違うので注意。


リセット直後


RF出力時
IDDの測定レンジが違うので注意。

XbeeWifi S6Bはリセット直後にガッツリ電流もってくようですね・・・負荷の過渡応答性
にすぐれたDCDC持ってこないと製品レベルに落とし込むのは無理だと思います。
ちなみにBが付かないほうのXbeeWifiはなひたふさんですらどうにもできなかった
のでねむいさんが手なずけることは不可能です・・・・そもそもB無し持ってませんし。


その2:GS1011MIC

電源投入直後


↑の+3.3Vの立ち上がり時の拡大
IDDの測定レンジがこれだけ違うので注意。


リセット直後


RF出力時



GS1011MICは今となっては古き世代のモジュールですが瞬間最大電流は低めに
抑えられています。Adhoc等の限定した用途ならば今でも十分に活躍できるモ
ジュールといえるでしょう。

技適マーク付きESP8266モジュール ESP-WROOM-02 を使ってみる






ド ン !



ついにっ・・・!ついにきたっ・・・!

今年の2月に"ESP8266モジュール"が技適取れたとの報(ともの技術メモさん情報より)を
受けて以来、ねむいさんはず〜〜〜〜〜〜〜〜〜っと待っていました!!!

ESP8266モジュール自体は去年から活気付いてきていますがそれまではもちろん技適
なぞ取れていない真っ黒な代物で日本国内ではいつものお仕置き部屋でしか扱えなかっ
たブツでしたが・・・!ESP8266チップ製造元のEspressifさん自らがワイヤレスモジュー
ルを製造に乗り出した折に日本の技適を含む各国の認証を取得して日本でも堂々と
使うことができるようにしてくれました!しかも従来のモジュールたちより遥かに安い単価で!!!


現在技適マークつきの"ESP-WROOM-02"モジュールを確実に購入できるのはタオバオの
本家店舗かもしくは検索で出てくるamazonの国内店舗からのようです。ねむいさんは
タオバオの本家から代行業者さん経由で購入しましたが10個で国際/国内送料コミコミ
で7000円以下でしたから単純計算で一つ当たり700円以下になり時間はかかりましたが
満足しています♥(代行業者さん使ったの数年ぶりです)

注意すべきはAliexpressやebayで"ESP-WROOM-02"として販売されているモジュール
です。こいつらは各国の認証が取れる前の開発者向けのモデルを取り扱っていて技適
マークどころかFCCマークすら存在しない超はずれのモジュールばっかりです!!!
先走って買うとまずハズレが送りつけられるので急がば回れの精神で落ち着いて確実に技適
マーク付きのやつを買える購入先をしっかり選びましょう。

ねむいさんのような哀れな子羊を増やさないように・・・掴まされたorz

腹いせに技適じゃない版のケース引っぺがしてやりました!!
SPI-ROMは貴重なので回収しましょう・・・



さて、それでは早速使っていきましょう!ESP-WROOM-02は電源立ち上がり後の
動作を決めるための外部プルアップやプルダウンすべき端子がいくつか存在しています。
配線を適当にしてると動作不良の元になるのでしっかりと!


前回と同じくピン配置を考案してみました。秋月さんのXBee変換モジュール上に乗っ
けることを想定した配置です。今回も合言葉はb・・・うぐぐ・・・頭が・・・
緑の網掛けの部分は外部接続必須の端子です。ブートセレクトを制御するIO15,IO2,
そしてIO0の端子の処理についてはほとんどの局面でSPI-ROMブートしか使うことは
ないと思いますがUARTブートローダモードなどに手軽に切り替えられるように10kohm
程度の抵抗でプルアップ/プルダウンすべきです。


こんなかんじで秋月さんちのRN-42用Xbee変換基板に搭載してみました。ひとまず
最低限必要なピンを配線しておきました。


ちなみにESP-WROOM-02もwi-fiモジュールなのでリセット直後はどうしても電流を消費して
しまいがちです。XBee用2.54mmピッチ変換基板に元から乗っている電流容量150mA
のLDOだと到底まかなえないので私はDIODES-Zetex社のセラミックコンデンサ使用可能な
ぱわふりゃーなLDOで3.3Vを供給しています。
さらに今は1608サイズで温度特性の良い大容量MLCCが秋月さんで購入できるので少ない
スペースの実装にフル活用しています★




まずはUARTからターミナルを用いてESP-WROOM-02と会話してみましょう。
デフォルトのUARTの設定は115200bps,N,8,1でフロー制御無しです。また、ATコマンド
の終端はCR+LFが必須
となりますのでご注意ください。


まずは基本の「AT」


お次はバージョンチェックコマンド「AT+GMR」です。技適版ESP-WROOM-02は5月上旬に量産
開始でしたからほんとに初期のものですね〜。今はATバージョンも0.25まで進んでます。


UARTで通信できていることが確認できたらお次はwi-fiの通信を使ってみます。
通常のUARTのように使用できる透過モードでwifi2serial化してみましょう。

まずは事前にホストPCとwifi接続し、さらにNetCatを立ち上げて接続待ち状態にして
おきます。今回は1000番ポートと使用しますのでコマンドは下記のようにします
「nc.exe -L -p 1000」

ESP-WROOM-02は購入直後はSoftAPモードになっているはずなのでたとえばホストPCと
wifi接続した時のホストのIPアドレスが192.168.4.2ならば・・・
「AT+CIPSTART="TCP","192.168.4.2",1000」とします。


コマンドが成功したら上記のようにCONNECT OKが帰ってきます。


接続に成功したら「AT+CIPMODE=1」でコマンド透過モードに切り替えます。
このコマンドを打っただけではまだ切り替わりません。


さらに「AT+CIPSEND」を打つことで「>」がUART側ターミナルに現れてようやく相互通信が
可能になります。


Nemuisan!を送信してみました。NetCatの端末のほうに送信できています。


逆にInaisan!をNetCat側から送信してみました。UARTのターミナルにしっかりInaisan!
が現れましたね♥


透過モードではATコマンドが使用不可能になるのですが「+++」を打ち込むと解除できます。
その代わり「+++」をすばやく打ち込まないと駄目です。


一旦ATコマンドモードに戻っても「AT+CIPSEND」ですぐに透過モードに復帰可能です。




という感じに取り急ぎですが購入直後から簡単にできるごく基本的な操作を紹介
しました。こんな凄まじいモジュールが技適マークつきで1000円以下で購入できて
手軽に利用できるようになるなんて(なんか前回もいったような気がしますが)
ほんとに良い時代になりましたね♥

新しい時代の幕開けです!

技適マーク付き★RN-42とRN-41を使ってみる


これがっ!

技適(このモジュールでは工事設計認証)

マークだっッ!!!!




はぁはぁ…ようやく電磁波と騒音と振動が遮断されたお仕置き部屋から出ることが
できた…♥なんだかねむいさんもきれいな体に成れたって感じです…

かつては電波法の絡みで脱着可能なコネクタを必ず持つモジュール以外では認可が
降りなかったせいで微妙に使いづらく一つ1万円以上もしやがっていたBluetoothSPP
モジュールですが…、

少し前に電波法に規制緩和があり半田付けタイプのモジュールにも技適マークを
貼ることが許されるようになり
、2015年現在では秋月さんよりMicroChip社製の(元
RovingNetworks製)のRN-42
を購入することで"確実に"技適マークがモジュールに
付されているBluetoothSPPモジュールを安価に入手し堂々と使用する事ができます♥

ちなみに"確実に"と強調した理由は技適(TELEC)の認証が降りていてもモジュール
本体に技適マークが貼られたり刻印されていない物が流通しているからで、特に
中華系海外通販などでは技適マークが無い品種が圧倒的に多く購入して実物を確か
めるまで分からず結局お金と時間を無駄にしてしまうことが多いです。

秋月さんちで購入できるRN-42の素の(半田付けタイプ)モジュールは1700円とかつて
のボッタ価格の連中と比べると破格です。しかもHC-05とかと違って電波法違反に
ならずいろんな場所で思う存分使いまくりできます。さらに市場に捨て値で出回って
いるHC-05とその眷属ほとんどが性能足らずのぱちもんなのを鑑みるとRN-42がいかに
非常に安価でなおかつ安心して使用できるモジュールであるかが分かります。
因みにHC-05の正規品は国際送料合わせると秋月さんとこでRN-42買う方が安くなり
なおかつ到達距離もHC-05より性能が高いので、2015年の今ではわざわざHC-05他
技適マークなしの怪しい中華モジュールをコソコソ使う理由が何一つ無いです。

ぇ?私?私はちゃんとキワモノなのを理解して電波法違反にならない様に電磁波と
振動と騒音が遮断されたお仕置き部屋で紹介してきましたのでいいんです。
私はいいんです!


ゲフンゲフフン・・・・せっかくきれいな体になったのにまたダーティになりかけたのでRN-42
を真面目に使っていくことにしましょう…



私が秋月さんとこで購入したのはモジュール単品に加えてXBee風に変換基板をあつらえた
もの
です。XBee感覚で使用できるのでお手軽です★現在はさらに安価な秋月オリジナル
のモジュールもありお求め易くなっています♥

いつもの汎用無線モジュールドックでXbeeと同じように接続!
しかし・・・

最初にホストPCで認識させたときはなんでかBuetoothHIDデバイスになってしまい
ました。どうやらデフォルトの設定では電源投入時にIO11をHiにすると強制的に
HIDキーボードになってしまうようです。もともと本家Xbee用の下駄を転用していて
XBeeのファーム更新で使うDTRが丁度RN-42モジュールのIO11につながることになる
ので私の環境では頻繁にこうなっちゃいます。

HIDキーボードモードをキャンセルしたい場合は後でも紹介しますがコマンドモード
で"SH,0000"を送信してやると常にSPPモードで使用可能になります。HIDモード不要
なら真っ先に設定しちゃったほうがいいでしょう、このほか、RN-42ではHC-05たち
とは比べ物にならないくらい幅広い柔軟な設定ができます。
(どっちも同じCSRのBC417なのに)

SPPモードで認識するとこんな感じになります。


XBee風のRN-42のピン配置をまとめてみました。電源投入時不用意にHiレベルにして
しまわないように使わないピンはNCに、その一方でハンドシェイク不要の場合はCTS
とRTSは直結にしておいた方が無難です。
オリジナルのXBeeと比べるとフロー制御用のCTSとRTSが逆のあべこべになっているので
XBeeアダプタを流用されるときは特に注意してください!!ファック1!!!!!

また、公式のデータシートでは一部に誤植があってGPIO6と8の説明があべこべに
なってたり何故かGPIO7が二つ存在していやがるのでご注意ください。


ひとまずXBee風のRN-42の購入直後から簡単な設定までもう一度やってみましょうか。
ホストPCとUARTで繋がる状態にしてUARTのターミナルを下記の設定にします。
・115200bps,N,8,1
・フローコントロールあり(RTS/CTS)
このフローコントロールありが曲者です。前途のようにちゃんとした手順でホストと
RTS/CTSを繋いでおくか、もしくはXBee風のRN-42側でRTSとCTSを直結にしておきま
しょう。解放は厳禁です!

こんな感じに直結用の切り替えスイッチつけておくと楽です★


電源投入後は接続待ち状態になります。この間にターミナルから"$$$"を打ち込む
ことによりコマンドモードに入ることができます。各コマンドは改行をもって受け
付けられます。改行コードはCRもしくはCRLFとしてください。

・コマンドモードに入る
$$$
・ファームウエアバージョン確認
V
・設定を工場出荷時に全て戻す
SF,1
・ボーレートを230400bps,N,8,1に変更
(リセット後に反映されます。コマンドモードも設定されたボーレートとなります。)
SU,230400
・HIDモード切り替え用キーを無効にする
SH,0000
・PINコード2613に変更する
SP,2613
・コマンドモードを抜ける
---



設定がちゃんと反映されていればモジュールをリセット後ターミナルを230400bpsで
開きなおしてコマンドモードに入り"D"コマンドで上記のように表示されます。

ちなみに"R,1"でソフトウエアリセットも可能です。


Bluetooth側の仮想COMポートとホストとの通信はもちろんバッチリです♥


ちなみにUARTからだけでなくBluetooth側の仮想COMからも同じく設定が可能です★





ところでRN-42よりさらにハイパワーなRN-41というClass1な最強に強まったモジュール
も存在しています。以前は技適を取得できていなかったのですが近年は取得され、技適
マークの入ったモジュールが出回っています。


もちろんねむいさんも入手済みです♥Mouserはこの技適マーク入りのモジュールが"確実に"
購入できます。使い方はRN-42と同じですがRN-41はClass1のハイパワーな送信(デフォル
トが最強出力設定になってる)が可能なので当然消費電流も多く、最大100mA,RN-42の2倍
以上電力を消費しますので電源周りも強化必須です!

しつこいくらいにアピール!!!!

秋月さんちで販売されているXBee風変換基板でRN-41もBee化してみました。
合言葉はbe・・・うっ・・・あ、頭がッ・・・!
















さて、せっかく日本国内で堂々とお外で使いたおせるモジュールを手に入れたので屋外で
実践してみたいところですね・・・自宅からそれほど遠くなく、100m以上障害物がない広い
敷地がある場所といえば・・・


京都御苑(GYOEN)!  Kyoto Imperial palace park!

ここなら思い存分実験が可能です!
そうだねお散歩ついでだね。


RN-41/42側は携帯用USB電源を使って電源供給し離れた場所に置きます。
ホストPC側はずーっと昔に買って今も使っているPLANEXのClass1のBluetoothUSBドングル
をつけて何mくらいまでデバイスが見えるか確かめてみました。


RN-42はClass2で額面はオープンサイトで飛距離10m程度のはずなのですが、なんか10m
どころか20mくらいまでデバイス安定してつかめました・・・!?
頑張ったら不安定でしたが30mまでいけたです・・・RN-41いらんやん!


お次は本チャンのRN-41です!


・・・
これ余裕で100m以上あるんじゃないかな・・・

力こそパワー!



そんなわけでよほど力を欲しない限りは無理してRN-41使わなくてもRN-42で事足りる
と思います。無線モジュールはここ数年で規制の面でも値段の面でもハードルが低くな
ってほんとに良い環境になってきましたね♥

STM32F4シリーズを使ってみる12 - FatFsとSDカード再考その1 -

このぶろぐを始めてから今に至るまで「FatFsがうごきません><」という漠然としすぎて
すごく返答しづらい内容の質問をコンスタントに頂くのですがその9割が単なる配線ミス
でしたと言うオチだったのですが、残る1割にSTM32に潜んでいた未知のエラッタや
評価ボードの設計不備、および私の不備というクリチカルな問題が潜んでいたのが
分かっています。

STM32F4が世に出て早数年、いろんな情報やノウハウも出そろってきましたので
ここで基本に還ってF4中心にSTM32とSDカードを接続せしめる手法について今一度
考察していきたいと思います。まず予習としてChaN氏のFatFsMMCの解説のページ
は必ず目を通しておいてください。



●STM32F4との接続・ハードウエア編
STM32F4とSDカードを実用的に繋げるためにはSTM32F4の周辺機能であるSPI若しくは
SDIOを用いて接続可能です。SPIはデータ線が1bitのシリアルですがSDIOは4bit(8bitまで
可能だが8bitバスが利用できるカードは限られている)まで可能でSDIOの方が高速に
データをやり取り可能です。
その代りSDIOの場合はその機能を最大限に引き出すため使用するI/Oポートは固定化
されていてSDIOを使うときは重複する他の周辺機能は使用不可能になります。
一方でSPIは柔軟に割り当てが可能なためピン数がすくない品種で速度をそれほど
要しない場面でSDカードを使う際に重宝します。

おさらいですがSPIを使用するときはSD/MMCのSPI互換モード、SDIOを使用する
時はSD/MMCのネイティブモードとして接続します。当ぶろぐではSDIOを使用する
SD/MMCネイティブモードに特に焦点を当てていきます。


私のおきぱのSTM32F4向けのサンプルではSTM32F4Discovery,STM32F429IDiscovery
ではSPIを、その他のボードに関してはSDIOをそれぞれ使用するようにしております。

↑STM32F4Discoveryとの接続(SPI)

↑紅牛/ECH_BOARD改造基板との接続(SDIO 4bitmode)

SDIO,SPIのいずれの場合においてもSDカード/MMCの電源投入後の初期化時はオープン
コレクタで動作することが前提のため、CLKを除く全てのデータ線は必ず外付け抵抗でプルアップ
してください。プルアップ抵抗値についてはNxPさんのアプリケーションノートAN10911
極めて詳しい解説があります。私はそれらを吟味した上で10kohmよりちょっと上の
22kohmを常用しております。メーカ製評価ボードでは入手の容易なSDHCカードを想定
しているのか下限値の10kohmで吊っているのが非常に多かったです。また、今日びの
マイコンは内蔵プルアップを有する物が多いですがそれに絶対に頼ってはいけません。
面倒臭がらず必ず外付け抵抗を用いてプルアップしてください。

以前MCIを動作させるのに難儀していた中華LPC1788基板ですがEA互換のはずなのに
EA向けのFatFsのサンプルがそのままでは動かないもんで回路図をよく見たら…

SDIOの信号線にプルアップが無かったorzちゃんとつけましょう!
このブログ記事を書く際に久しぶりに動かしてようやく気づいたorz

CLKは基本宙ぶらりんです。リセット直後のI/Oの挙動が不安な場合は100kohm程度で
Loレベルに弱く固定すれば良いです。私が見た限りではEAのボードは「宙ぶらりん
(ダンピング抵抗有)」、ST系のボードも「宙ぶらりん」、中華系のは適当で他のI/Oと
一緒にまとめてCLKもプルアップしてたりそもそも基板の設計不良でCLK以外の必須
の信号線すらプルアップしてなかったりしますがCLKに関しては基本「宙ぶらりん」で
良いと思います。と言いたいところですが!!
STM32のSDIO_CLKは非常に高速なクロックが走り、パタンの引き回しによっては
信号の反射によって猛烈なリンギングを発生させるため信号の信頼性が著しく低下して
しまいます。よってSDIO_CLKの出力端のごくごく近くに純抵抗成分を配置して伝送経路の
インピーダンスのマッチングを図り信号の反射を抑える必要があります。
最適な抵抗値は回路構成や回路パタンの引き回しに大きく左右されるため0~47ohmを
目安にオシロとにらめっこしながら切った貼ったをして決めましょう。繰り返しますが
直列終端は信号源のすぐ近くに配置しないと後で述べるフェライトビードの配置と同じく
全く効果がないどころか最悪パワーアップさせてしまいますので基板設計の段階から考慮
しておくべきです。

20160110追:
直列抵抗入れてもダメならフェライトビーズも足してください。



プルアップの他に注意すべき点は3つあります。
1.ブレッドボードの使用は避ける
 ブレッドボードの使用は「SDカードが繋がらない」の諸悪の根源です。結線ミスが
 原因のトラブルでブレッドボードで実験していたという証言が非常に多かったです。
 ブレッドボードは確かに便利ですが、SDカードに限らず接触不良や接点抵抗の増大
 によるさまざまなトラブルのもとに繋がります。面倒でも半田付けを行う癖をつけ
 ましょう。とは言え何でもかんでも半田付けもだめです。丸端を圧着せず半田付け
 とかもってのほかです#

 
 同じ理由でSDカードソケットに接触圧が弱く金メッキの薄い中華製の安物を使うと
 接触不良につながります。注意しましょう。接触不良の問題は状態が変わりやすく
 不具合を特定しずらいので厄介です。

 ぇ?お前ブレッドボードより酷いやっけつな使い方してるじゃんですって!?
 わ…ゎたしは理解した上でやってるからいいんですよぅ!


2.結線はなるべく短く
 これもSDカードに限らず基本中の基本ですね。SDIOの場合はMAX52MHz、通常使い
 でも25MHzもの高速クロックが走ります。クロストークが起こらないような配線を
 考慮しなければなりません。
 
 
 とはいえ利便性も考えないといけません。私の場合はSTM32F4Discoveryで使う
 場合はトレードオフでカードコネクタに対してこんな配置にしております。
 配線長が10cmを超えてしまうとTCK=21MHzだと"あうち"です。なるべく太く短く
 目指しましょう。ちなみにパワーメッシュ基板を使うと配線もしやすくGNDも安定して
 いろいろ楽ができるのでオススメです。

3.電源
 電源は出来合いのボードを使う際の意外な落とし穴になります。SDカードの仕様と
 STM32F4で使用できる全てのSDカードのモードを考慮すると最大200mA必要とします。
 STM32F4Discoveryの3.3V(はショットキDi経由してるので3Vくらいに落ちる)から
 引っ張ってきても"何とか"動きますが高速で信号のやり取りをしていると特に書き
 込み動作の際に不安定になってきます。
 こんな場合は、フェライトビードを無暗に挟むよりもSDカード電源供給専用LDOを
 用意してあげると効果的です。このとき使うLDOはSDカードの高速アクセス時の大電流
 の吸い込み吐き出しに対応するためにセラミックコンデンサ対応の負荷の過渡応答
 性に優れたものを選んでください。
 STM32でSPI限定で使用する場合、仕様上最大で100mAあればよいので秋月さんの
 ラインナップでいうとXC6202P332PR-GTAR5SB33で十分です。勿論LDOの電圧
 供給源(ほとんどの場合はUSBの+5V)は評価ボートと同じ系統にしてください。

 
 ねむさいんは当然のごとく攻守ともに優れたLT1963Aです♥
 ↑秋月さんも私が指摘してた'A'付きにようやく気づいたようでMLCC対応と明記してます。

全然考を察していない内容になっちゃいましたが次回は既存のライブラリを駆使
してMMC/SDIOドライバを組んで実際に動かすソフト編をご紹介します。

OpenOCD小ネタ15 -LPC5410x,LPC82xシリーズの書き込み対応-

11月ごろに新規ラインナップリリースの報は小耳にはさんでいたのですがまだまだ先かと
思っていたLPC54102XPressoが秋月さんから唐突に発売されておりました。
同時にLPC824MAXも販売されましたので早速手に入れ評価してみましたのでご紹介します。


●LPC82xシリーズのフラッシュ書き込みに対応

LPC824MAX、正式名称はLPCXPresso824MAXです。

中心部のLPC824はCortex-M0+コアを持つLPC810シリーズの上位に位置し、フラッシュ
メモリとSRAM容量の増強に加えてDMAも追加されております。もはやLPC810シリーズと
は別品種(後述の部分も含め)とみて良いでしょう
付属のデバッガはおなじみMBED版CMSIS-DAPです。マスストレージからの書き込みも
サポートしております(が当ぶろぐでは全く使いません)

ん…?なんかコネクタのハンダが雑だ…

!!!!!!なんかコネクタうまくハマらないと思ったら…
とりあえず精密ラジオペンチで障害物取り除いて対処しました。
後で新しいのに取り換えておきましょ。


気を取り直してOpenOCDから書き込みしようとしてみました…
が、
LPC81x系と同じだろうと高をくくっていましたが正しく書き込めませんorz
もう少し突っ込んで調査してみると最初の1kBしか書き込めてない現象…これはまさか

UM10800rev1の386ページにはIAPのスタックはLPC810系と同じく148byte確保せよと
指示してあるのですがこれに従うと駄目でlpc4300系みたいに208byte確保しないと
ただしく書き込み動作、正確にはIAPコマンド51が連続で実行できませんでした。
マニュアルの整備がまだ行き届いてない感じですね。LPC82xはリリースして結構時間
経ってるので多分同じ指摘が来てるはずです。来月あたりにこっそり変わってると思い
ます。NxPさんはドキュメントの修正対応かなり早いので特に気にしてませんがあまり
高に言うとコワモテのくまさんに〆られるのd


そんなわけでLPC824にも書き込みデバッグが可能になりました。
ついでにLPC11xxとLPC17xxで対応しているフラッシュメモリサイズの自動認識についても
LPC800シリーズ向けに対応しておきましたのでcfgファイルの統一可能です♥



●LPC54102のフラッシュ書き込みにも対応


LPC54102XpressoはCortex-M4FとCortex-M0+が同居したLPC5410xシリーズとV3に
バージョンが上がったLPCXpressoのハードウエアで構成されています。

デバッガとしてはLPC-Link2同等品として動作します。CMSIS-DAPでデバッグが可能に
なっております。

またコネクタ構成もArduinoのシールド互換に構成になっており、mbedにも対応予定
だそうですがmbed公式にはまだ影も形も使ってる人すらもいません。つまりこの記事
投稿するのが早ければ私が国内第一号になるはずです!!!


と、その前に書き込みをできるようにしなければなりません。LPC824と同じくOpenOCD
にパッチを当てる必要がありました。ブートローダーの構成・エントリポイントはLPC1500
シリーズと同じですが当然ながらフラッシュメモリのセクタサイズとIAP消費スタック
容量が異なりますのでそれに合わせて作りこんでいきました。


作りこみ自体は慣れたものなのでLPC5410x系のフラッシュ書き込みは危なげなく完了
し、現状M4コア単独のみですが動作も確認できました。

但し書き込み時にはcfgサイドでちょっとコツが必要です。LPC5410xはLPC1000系には
存在しているベクタアドレスのリマップ機能がなく、電源投入時はもちろん各リセット
時にもブートローダー(0x03000000から開始)にまず飛び、ブートROMの先頭が0番地に
来ます。つまりリセット直後にhaltをかけた状態でベリファイを行うと、ユーザフラッシュ
ではなくブートROMの内容を読んでしまいベリファイに失敗します。

これを防ぐためにフラッシュにプログラムを書いた後は一旦リセットをかけてユーザ
プログラムを走らせ(reset run)てからhaltをかけてやる必要があります。
私が公開しているOpenOCDのプログラムと同梱のLPC54102向けcfgは一連の操作を
リブートコマンドとしてprocに定義してありますのでユーザサイドでは特に意識しないで
書き込み・デバッグが可能となっております。

おきぱにはGCCでビルドできるLPC54102XPresso向けのプロジェクトを置いてますので
秋月さんで購入された方は試してみてください。上で述べたとおりこのボードに仕込
まれてるものはLPC-Link2相当でHighSpeedで繋がるため、OpenOCDから書くと極めて
遅いと言われているCMSIS-DAPにも関わらずかなり早いです。


これらLPC2000向けパッチはgerritにもパッチをあげておりますので興味のある方は
ビルドして試してみてください。またWindows環境の方はおきぱのOpenOCDバイナリ
パッチ適用済みですのでご利用ください!

OpenOCD小ネタ9 -STM32F33xシリーズとFTDI系のSWD対応-


6月中旬に唐突に秋月さんちのラインナップに追加された詳細一切不明の謎Nucleo基板
Nucleo-F334R8にはこれまた詳細不明のSTM32F334R8T6が搭載されておりました。

↑今回から撮影用でぢかめを接写に超強いTG-3に買い換えました♥
6月中旬の時点ではF3シリーズであるというほかには詳細が一切不明だったので会社で
試作部品発注したついでに購入してしまいました。(注:Nucleo板は自費で購入です!)

ひとまずOpenOCDで引っ掛けると、デバイスIDが0x10016438というまだOpenOCDのフラッ
シュドライバには存在しない物だっため最初は書き込みエラーではじかれてしまいましたが
ソースコードにそのデバイスID追加して即書き込むことが出来ました。
因みにSTM32F3系はCortex-M4系ですがフラッシュ書き込みドライバはF1系です。もう少
しでF2系ドライバに実装しそうになってしまいましたよ。実は最初に私がパッチを書いた
当初はユーザマニュアルどころかデータシートすらも無かったため、フラッシュのセクタサイズ
は0系からのコピペの飛ばしでした・・・。が、その後にリリースされたReferenceManual
には2048バイトと書かれていたのでセフセフです。

話は前後しますが一週間以上前に提出したパッチはすでに公式にマージされています
おきぱにあるOpenOCDのバイナリもF334R8版Nucleo対応のcfgを作っていますのでお持ちの
方はすぐに試すことができます。便利な書き込みスクリプト付きで対応です☆


というわけでせっかく買ったのでLチカだけじゃなくNucleo版のいつものに相当する
I2Cデバイスを動かすサンプルを移植しました。
長らくの間ねむいさんたった一人しかこのi2c液晶動かして無かったですがごく最近
ついに他の方も動作に成功したようです。私間違ってなかったですよね…!
注:7月1日現在、STM32のライブラリをPeriphDriverからHALDriver(STM32CubeF3)
 に変更しております。CubeFx系のライブラリ対応につきましては後日みっっっっちりと
 解説させていただきましたので覚悟なさい!





お次は長らくの悲願であったFTDI系デバイスのSWD接続正式対応です!
以前から私はぶろぐ上にてレビュー段階のコミットを評価しておりました。その時点で既に
かなりの完成度に達しておりましたがその後adi_v5とswd関連のソースも見直されて
満を持しての今回のマージです♥
…と同時にVersaloonのSWDパッチは完全に使用不可になってしまいましたが実は他の
方が別の手段でSWDに対応させたパッチがレビュー中でして7/1現在おきぱにあるバイナリ
はそちらの物を取り込んでおります。Versaloonも以前と全く変わらない使用感になって
いますのでこちらのマージも時間の問題であると言えます☆

さて、ねむいさんのぶろぐではJTAGKey2(とその互換回路)を使用してSWDせしめる
方法をお伝えします。以前も述べていますが原理は簡単で抵抗一本でSWD化可能です。


たったこれだけの追加回路で完了です。一見強引な方法に見えますが出力同士がぶつ
かっても(私の回路図通りに作りこんでいれば)出力バッファの定格内なので全く問題
がありません。

上記の方法、JTAGKey2に代表されるハード的にSWD未対応な物ではresister-hack
という形でOpenOCDのcfgファイルでサポートされています。それを利用してswdで接続しに
行くJTAGKey2専用のcfgファイル"jtagkey2_swd.cfg"もこちらでこさえております。

おきぱにあるプロジェクトではEFM32とSTM32F4のいつものがすでにJTAGKey2のSWD接続に
makefileレベルで対応しております。現在はまだ3つだけですが順次対応して行きます。
あとついでのついでですがEFM32のZEROGECKOのフラッシュ書き込みも対応させました
こちらも機会があればEFM32のボードとともにご紹介させていただきます。

GPS/GNSSモジュールを試用する12 -Canmore GP-102+を使う-

>GPSモジュール GMS6−SR6(GPS/GLONASS対応)
お前は選ばれなかった…(C.V.麦人)
消費電流多すぎです。っていうかGPSじゃなくてGNSSモジュールですよ。

>GPSモジュール GMS6−CR6
お前は選ばれなかった…(C.V.麦人)
GLONASS取れないとか・・・

>GPSモジュール [GM622T]
お前は選ばれなかった…(C.V.麦人)
Gms-g9の性能知っちゃうとどうもね・・・

>極小高性能GPSモジュール [GM5157A]
お前は選ばれなかった…(C.V.麦人)
MT3337ってMT3333/3339の機能シュリンク版じゃないですかー
自由度めっちゃひくいじゃないですかー!ヤダー!



・・・






>GPSロガー G−PORTER Canmore GP102+
ぁ、こんなん入荷してる・・・単なる既製品だけどこれでいいや


というわけで2011年初頭より自作GPSロガーの比較・サブ機としてとして長年連れ添っ
てきたGP101がとうとう永眠してしまったため新しいサブ機を購入することになりました。
最初はGarminのナビ付きの高級機を考えていたのですが目的がロギングだけなのと
地図は必ずアナログデバイス(=電池いらずの紙)を利用すると硬く心に決めているので
結局秋月さんちから販売されていたGP101の後継機ともいえるGP102+に落ち着き
ました。価格も安くなってますし。

さて、このGP102+はかなり新しめの製品なのでGPS信号の解析用チップにSIRFStar4
搭載されておりQZSSの補足も可能になっています。
2014年現在はみちびきから送信されるGPS補完信号が利用できることになります。
ちなみにGLONASSは利用できません。


恒例のモジュール性能比較…と行きたいところですが今回はGP102+に使用されている
SIRFStar4と私の使ってるGms-g9との分かる範囲でのカタログ比較となります。GP102+
全体の性能はまた別となるのでその点は厳重にご注意ください。
また、後でも述べますが付属のマニュアルだけでは操作に?な点が数多くあるので
JR7CWK氏によるGP102+使用記は必見だと思います。


●ファーストタッチ

さて、このGP102+は操作にかなり癖がありますので注意が必要です。初期型のGP-101
と違い、電源投入はボタン長押しになりましたが投入後すぐにロギングは開始してくれ
ません。目的にあったロギング方法を選択してからスタートとなります。

ちなみに電源OFFはメニューボタンで電源のアイコンにカーソルをもっていき、そこで
メニューボタン長押しです。
詳しい操作はマニュアルをご参照して各自で体で覚えてください(丸投げ)。

…とここまでは一度でも衛星を補足した後の状態の話ですが…なんと購入直後の場合は
最初の電源投入で衛星を補足して現在時刻が得られるまでは各種操作が一切できません。
電波が入らない屋内では文字通り一歩も進めないのでとにかく衛星を受信しないと行け
ません…ねむいさんまずそこでハマりましたorz

ねむいさん的には電源ONしたら即ロギング開始&衛星受信してなくても各種設定可能な
ようにしてほしいと感じました。ちなみに初期GP-101は電源ボタンを一瞬でも押したら
即電源ONでそこから一瞬でも電源ボタン押したら問答無用で即OFFというザックに無防備
に放り込めない代物でしたからそれと比べたらまだましですがー!


そんでもってUSB-miniBケーブルでPCを接続するとどこかで見慣れたマスストレージが
現れます。どうやらGP-102+の制御にはSTM32が使用されているようですね。なんか私の
GPSロガー
に似たものを感じて愛着が早くも湧いてきました。その変わり仮想COMポート
は出てきません。SiRFStarから送出される生NMEAは直接取れないようです。



ファームウェアの更新はおなじみのSTM32のDFUで行います。ちなみにDFUモードに入る
たまには特定の順序でボタン押しっぱにするのですがDFUモードに入った直後にボタン
をすぐに離さないと勝手に電源がOFFになりやがります
のでご注意ください#
ねむいさんここでもハマりましたorz



●実際のフィールドで使ってみよう!
Part1・長浜駅周辺


ねむいさんGWに入る直前に右ひざにヒアルロン酸を注入していたので、トレイルランの
ような重負荷の運動が出来ず、GW中はウォーキング程度の軽い運動をしていました。
てわけで長浜駅周辺に観光に行ったついでにGP102+と自作GPSロガーのロギング
データとの比較を行ってみました。


長浜城です。


大閣井戸と琵琶湖です。琵琶湖北部に来たのはじめてでした。


伊吹山です。ここは今秋にちゃれんぢします!


市街地に戻り北国街道を通って黒壁という場所に行きます。


黒壁と呼ばれるこの区域も観光地となっています。


近江牛のにくまんです♥


お土産たくさん買い込んで帰宅です♥そうだね単なる観光だね。


GP102+はこのように走行距離も表示されます。ポケットでも邪魔にならないサイズなので
普段のランニングにも使用してます。




このようにして取得したログはCanWayなるツールで取り込みGPXや生NMEAに変換しt

!?
F*********************K!!!!!!!!!!!

何度やっても取り込みしようとしたら上記のようなオブジェクト参照がうんちゃらの
エラー吐いて強制終了してしまいましたorz


CanWay使えなかったらどうやってログデータ取り込むのよ!!!と憤慨しておりましたが、
PCでマスストレージで接続していることを思い出し、SIRFStarからの生NMEAをSTM32で
さらに加工したと思われる拡張子がfitのログファイルを発見しました。
どうやら規格が存在するフォーマットだったようでGPSBabelを使いNMEAやGPX形式へと
無事変換することができました。めでたしめでたし。
注:画像は5/24の生駒山脈にトレランに行ったときのログです。


というわけでカシミール3Dを使用して自作GPSロガーとGP102+の軌跡の比較です。
街中なので正直どっこいどっこいですね…
「この地図は、国土地理院長の承認を得て、同院発行の電子地形図(タイル)を複製したものである。
(承認番号 平28情複、 第932号)」



Part2・近畿自然歩道(生駒縦走路)

コラコラなに回れ右してるのですかこっからが本番ですよぅ!
「以下の地図は、国土地理院長の承認を得て、同院発行の電子地形図(タイル)を複製したものである。
(承認番号 平28情複、 第932号)」


近畿自然歩道はねむいさんが全走破した東海自然歩道と同じく日本を代表するトレイル
です。東海自然歩道と違って一本道ではなく、一つのテーマに沿ったルートが網目の
ように近畿圏を覆っています。ねむいさんは既にいくつかの近畿自然歩道を走破して
いますが
総延長が3000km以上あるとのことでもうライフワークになりそうです。


今回は近畿自然歩道「生駒山・鳴川峠・十三峠をめぐるみち」と「高安山・信貴山を
めぐるみち」の2ルートを走ります。それではいざ出発!


まずは石切駅を出発し旧生駒トンネルの脇を登り登山道に入ります。
なんとこの日は旧生駒トンネル内御開帳の日だったみたいです!


少しの間急峻な登山道を登り生駒縦走歩道に落ち合ったら緩やかな尾根道となります。


くさか園地の舗装路にでました。緩やかな舗装路をさらに登っていきます。


トレイルと舗装路を交互に交わして生駒山上遊園地に到着です。


生駒山頂は生駒山上遊園地敷地内のミニSLの中にあり、禁足地(?)です!


生駒山頂遊園地から離れ、暗峠がある国道308号線を目指します。


国道308号線と落ち合った後はすぐに308号線から離れますが・・・


去年と同じく暗峠に立ち寄りました♥


峠の茶屋さんも営業中です。


今年のカキ氷は霙です!!


生駒山頂からは別ルートで暗峠に直接出られます。


生駒縦走路/近畿自然歩道のルートに戻りさらに先を進みます。


車道を登りなるかわ休憩所に。ここは水洗式トイレがあります。


トレイルをひた走り鳴川峠です。



鐘の鳴る丘展望台です。鍵をつけられる場所があり、カップルもよく訪れる場所だそう
です。


十三峠の最高点です。・・・おや・・・?


良く見ると尺取虫さんが・・・ヒルじゃないよ!



十三峠を抜けてすぐのところは注意が必要です。道標にしたがって進むとルートミスです!
生駒スカイラインと平行に進むのが正しいルートです!
しっかし間違えて進んだルートまで正確に軌跡をorz


30分くらいルートミスったってここはすぐ京都に帰れる場所だからキにしない気にし
ない!!そそくさと高安山方面に向かいます!


この謎のヘリコプターの発着場みたいなのは国土交通省の航空レーダーだそうです。
ヤマレコでご指摘いただきました。


立石越につきました。高安山までもうすぐです。


高安山からの信貴山への分岐。実は近鉄高安駅から信貴山まで行ったことがあってこの
あたりは結構詳しかったりするねむいさん。



ケーブル高安山駅に到着です。自販機もあるので補給をかねて小休止です。
かつてはここから信貴山門前まで電車が走っていたそうで・・・


近畿自然歩道はケーブル高安山駅で終点かつスタート地点なので折り返します。
画像は八尾方面からも目視できるレーダー観測所。


高安山の山頂分岐はめちゃくちゃ目立たない場所にあるので見逃さないようにご注意
ください!ていうかなんだこの看板・・・


さて、信貴山への分岐に戻ってきました。舗装路を駆け下りて朝護孫寺(信貴山寺)に
向かいます。


次に目指す矢田丘陵が見えますね〜
ってもう行きましたけどー!


ここを左に行くと矢田丘陵に向かう道です。今回は右に進み信貴山を経て三郷駅へ
向かいます。


朝護孫寺境内に到着です。
今回は信貴山頂上がある空鉢護法へと上ります!


はぁはぁ・・・25km近くフルパワーで走ってきた後ののぼりだからキッツいわ・・・


空鉢護法に到着です。



絶景ですね〜♥
ちなみに空鉢護法では虎ではなく蛇の巳(みー)さんが祀られております。
・・・形は似てますがアラレちゃんに良く出るアレではないですよぅ!


同じく山頂には信貴山城跡もあります。



山頂を離れ境内に下りてきました。本堂が遠くに見えます。



その本堂です。奈良盆地が一望できます。


本道からさらに降りて三郷駅への岐路に着きます。
有名な張子の寅さんです。信貴山頂では蛇ですが山ろくでは寅です。


ここでいったん近畿自然歩道のルートから外れ、開運橋を渡り車道を下ります。


ぐるっと旋回しておなじみの国道25号線と落ち合います。


住宅街を駆け下りてゴールのJR三郷駅に到着です。


次回のルートはここを基点に今一度信貴山寺に行き、そこから矢田丘陵を目指す道に
なります。先にも触れましたがすでに走破してますがこちらのレポートも後日に・・・♥
・・・なんですかそのげんなりした顔は!?



※この地図は、国土地理院長の承認を得て、同院発行の電子地形図(タイル)を複製したものである。
(承認番号 平28情複、 第932号)

というわけで今回走った軌跡の全体図です。距離が長すぎてほとんどぴったり重なって
ますが互いに一長一短ではありますが致命的に外してるところは無いようなのでGP-102+
私の自作GPSロガーのバックアップ機として十分に活躍してくれそうです。
これからもヨロシク!

WVGAな解像度のTFT-LCDモジュールを動かす

私が最初にTFT-LCDに手を染めてからはや4年…もう4年も経っtグハッ


すみませんいきなり自爆しそうになりましたが時代の趨勢は大解像度化の一途を辿って
おります。電子工作で使用されるTFT-LCDも例外ではなくSTM32F4等の高速・大規模な
マイコンではもはや320x480(HVGA)な解像度は当たり前となっていますね。

それ以上の解像度の物は配線や駆動が面倒なRGBインターフェースの物しかなかったの
ですが2013年代後半からまた状況が変わります。なんと480x800(WVGA)なTFT-LCDモジ
ュールでも従来のi8080バス形式で使用出来るものが一般にも出回り始め、私も幾つか
入手したのでまとめて動かしてみることにしました。


●TFT-LCDのバックライト用LEDの話
かつて大解像度/大型のTFT-LCDモジュールにはバックライトに冷陰極管が用いられて
いました。しかし白色LEDの高性能化により冷陰極管にとって代わり、モジュール全体の
大幅な薄型化に貢献しております。また、点灯に必要な電圧も冷陰極管と比べて極めて
低いので感電の危険も無く安全に工作が行える利点もあります。


とはいえ大きな範囲を均一に照らすためにはLEDを複数個配置しなければならず、ムラ
なくLEDを点灯せしめるためには各LEDになるべく均一に電流を流してやる必要が生じます。
そういった点から大型/大解像度のTFT-LCDモジュールではLEDが直列に配置されている
(=全てのLEDに等しい電流を流すことができる)物がほとんどでこの場合はLED駆動用の
昇圧回路を組む必要があります。


私が選んだ昇圧ICはオン・セミコンダクターのCAT4240という品種です。
これは4〜8個の直列LEDを点灯させるのに最適で、回路構成次第で大電流駆動可能です。
後で紹介するWVGAなTFT-LCDたちに使用されているLEDは、6〜8個直列でLED全体の
Ifも20mAもあればいいので昇圧用コイルは電流容量の低い小さいものが使えます。



ほぼデータシートに即して回路図を作成し、LED駆動用昇圧ユニットを組んでみました。
+3.3VからMAX+28Vまで昇圧可能なのでLED8連でも余裕で対応できます♥
回路中で使用されているパーツは昇圧IC以外は同スペックの物が秋月で購入可能です。


●さぁ動かそう

先ずはこちらの5インチのTFT-LCDモジュールです。コントローラICはNovatechのNT35510
という品種です。インターフェースはi8080-16bitバスなので私のいつものと同じように
動作できるはずです。バックライトLEDは8連直列なので上で組んだ昇圧ユニットを接続
していざ電源投入!


…ぁぁ・・・
あああああああああああああああああああ!

保管の仕方が悪かったようで薄さも災いしてLCDを割ってしまったようですorzorz

↑かろうじて映る部分で動作を確認しました…さぁ次です次!!!



お次は4.3インチなドライバICがOTM8009Aという品種のものです。
24bitインターフェースですがレジスタの設定は16bitかつRGB565の設定も可能で従来
どおりの16bitバスに極めて近いため特に苦労はありません。こちらもLEDが直列の6個
使いです。

※これはいないさんです。
WVGAになると表示できる範囲も大幅に増えて大きい画像表示するのに便利ですね♥
・・・あり?どしたのですかそんな顔して?

けなげに+3.3Vから+18V近くまで昇圧を続けるCAT4240さん。コイルもCAT4240もまったく熱く
なっていないのでまだ余裕がありますね。ただし昇圧に使用する+3.3Vの供給源は1A程度
ひり出せられるくらいの余裕は持たせておいてください。



最後に4.3インチでIPSなTFTです。ドライバICはHX8369-Aです。こちらは解像度以外は
従来のHX8357系とまったく変わらず。一番使いやすく感じました(動かしてしまえば
あとはどれもほとんど変わりませんが)。Aliexpressでも購入できます。

※これはほむらちゃんではなくいないさんです。

※こ(ry
IPSなのでデジカメでとっても青っぽくならず発色がかなりよいですね〜




幾つか動かして思い知りましたがさすがにバラックでLED用昇圧回路込のボード組むのは
辛いので最初は面倒でも専用の基板起こした方がいいかもしれませんね。

言い忘れていましたが今回のWVGAなTFT-LCDモジュールの駆動に用いたのはおなじみ
STM32F4のいつものです。すでにソースコードに反映していますのでこれらのモジュール
を手に入れていても攻めあぐねている方の参考になるかと思います。今後もよさそうなのが
入手できたらラインナップにどんどん加えていくつもりです。

STM32F0版Nucleo(Nucleo F030R8)を使ってドットマトリクスI2C液晶を動かすその2

かなり間が開いてしまいましたがねむいさんが膝の治療をしてるうちに世間はまた
大きく変わり、秋月さんからついにF4版Nucleoが発売される運びになりました
ねむいさんの狙いはF073系のボードなので手元のボードを消化しつつ様子見です。

さて、今回の記事は前回の続きです。以前はF0版Nucleoを使ってGPIOによるソフト
ウエアI2C制御にて某I2C液晶を動かし茶を濁していました。が、今回はSTM32F0の
ハードウエアI2C機能を使用して同じことを行います。

しかしながら前回述べたとおりF0,F3系の物はI2Cモジュールの世代が進んでいて以前と
同じソフトウエアは利用できなくなっています。大きな違いはスタート/ストップコンディ
ションが自動で発行できるようになったこと、SDA,SCLにアナログ+デジタルフィルタが
追加されたことそしてSCLの周波数が直感的に設定できなくなったことです。
SCLのクロック設定はSTのサイトから落とせる"I2C_Timing_Configuration"なる物を
使用して得られた謎の16進数をtimingsレジスタに書き込まないといけなくなりました。
余計なことするなー!

とはいえ一度設定すると後から変えるような場所ではないですからまあ許容できる
範囲だと私は思います。どうせ潰しが効く100kHzでしか使わないですし!



F1/F4系のソフトとあわせるために結構苦労しましたが最終的にうまく動く組み合わせ
を見つけて無事F0系でもハードウエアI2Cをしようできるようになりました♥
(写真ではハード/ソフトI2Cの動作の見分けはつきませんが・・・)

おきぱのI2Cドットマトリクス液晶動作サンプルはすでに差し替えてあります。
実は4月頭にすでにハードウエアI2C版を作りこんでました。もちろん液晶だけではなく
前回動作させたI2C温度計もばっちり動きます♥


ちなみに私のサンプルを見て変なことやってるのに気づいた人も居ると思います。わざと
ドットマトリクス液晶とI2C温度計ほかI2CデバイスのHALの部分を分けています。こんな
ことやった理由は今回使用したI2C接続の液晶以外にSPI接続のドットマトリクス液晶を
接続せしめることを見据えているためです。TFT-LCDではすでに実践している手法ですが
こちらも次回以降に紹介して行く予定です。



ついでの話ですがOpenOCDもついにV0.8.0が正式にリリースとなりました!公式のペー
ジには新たに追加された主な機能の紹介があります。その中で私もフラッシュドライバ
周りでいくつか貢献しました。下の画像で黄色で強調している箇所が私が手がけた部分
になります♥

特にKinetis系のサポートは今後のFreeScale公式のツールにもとりこまれる程の影響力
でねむいさんも顔のパーツを真ん中に寄せて地獄のミサワみたいに得意げになりたい
・・・ところ で す が !上の画像に赤で注釈書いてあるように、以前ねむいさんが実装
したNuvotonのCortex-M0向けのフラッシュドライバがtfreakリンサンの勘違いにより無関係の
NUC910系のサポートと記されてしまい、V0.9.0リリースに向けて早くも釈明と大変更の
プランを練っている次第でございますorz
これ以前からずっと言及してきましたがマジでどうしましょうね・・・幸いにもOpenOCDの
Nuvotonドライバ自身が全世界探しても私しか使ってない状態なのでまだ被害が一切出て
ないのが救いですが(呑気)



あ、すみません最後までブログ書いてて気づきましたがNucleoの話に戻りますが同ボード
上に搭載されているST-Link/V2-1用のファームウェアが更新されています
デバッガとVCP同時使用やそのほかの安定性がかなり改善されていますので必ず更新し
てください。以前のSTLink/V2系のファームアップも同じアップデータで可能です。

LPC800シリーズを使ってみる4 -ついでにトラ技ライタも使う-


私もご多忙にもれずトラ技ライタなる基板(雑誌は付録)を買ってきましたよ。
今回は基板単体ではすぐに使うことはできずUSB-miniBコネクタと1.27mmピッチ*2の
ヘッダ、そして幅が狭いタクトSWが必要です。


上記のものはマルツで買わなくても秋月で以前購入したものでほぼまかなえるので、
秋月フリークな貴方は全く問題はないでしょう。私も以前JTAGKey2Compatibleを作成
した時
にチョイスした面実装タクトSWを利用しております。ちょっとコツが要ります
が、私のぶろぐ見てる方ならこの程度の作業は楽勝だと思います。

とりあえず最低限のパーツを付けるとこんな感じになります。あーそうそう、…2/9は
いないさんの誕生日でしたね♥うっかり写っちゃいましたね♥ぱんつは駄目だったけどぶらなら
繊細なぴいぶろ君は怒らないみたいなので学校や職場でどんどん見てほし









さて、このトラ技ARMライタはLPC11U35が載っていて、CMSIS-DAPのファームを仕込む
ことによって文字通りライタにせしめることができます。正直これに関してはLPC812-MAX
のMBED版CMSIS-DAPと全く同じなので特記すべきことはありません。
もちろんふつーにOpenOCDから使用可能です!


ターゲットは300milのDIPと化したLPC811さんです!秋月さんの8PinDIP変換を2連結
で16Pinとして使うのがミソです★
このDIP化ネタ、もはや10番煎じくらいの手あかが付きまくったネタなのですがやら
ずに居られません。


前回LPC810で遊んだ時のように空中配線のやっけつです。ところで…



CN5にJST-EHの8Pinコネクタつける際に気付きましたが…
LPC-Link2からのコピペですかトラ偽らしい(ニーサン顔で)…まぁいや
新声社亡き後誤植を継ぐ者はCQ出版だけですから(諦観
20140313追:
あのさぁ…
この程度は誤植のうちに入らぬということかー!!!


20140220追:
ねむいさんの探し方が悪いだけだと思いますがトラ技ARMライタの回路図が誤植満載の
紙媒体以外で全く見当たりません(怒)今どきPDFで回路図提供しないとかどういう根性
しているのでしょうか(ビキビキホントふざけてますね(ビキビキ
やはりカンガルー先輩をオーストラリアから召還し〆て頂かないと駄目ですねマジで(ビキビキ

思えば過去の記事ではカンガルー先輩に対して"やる気がわかないと仕事をしない気分屋"
とかいう駄目な日本企業にありがちな駄目な経営者目線でレッテルを貼っています。
頑張って仕事して(いる仕草を見せ)ない奴は駄目な奴だ!!!苦労して仕事をしない奴は
生意気だ!!!
と言わんばかりの陰湿な主張がにじみ出ているようでそれとはまったく
真逆のマトモな精神を持つカンガルー先輩はCQ出版と袂を分けて正解だったのであろう
…とひしひしと感じます。

ちなみに現在のカンガルー先輩は本国に帰国後、己の野性に目覚めたのかビルドアップした
筋肉超満載状態
となっております。なぜこんなにムキムキになる必要があるのかというと
巨大動物図鑑さんからの解説から考察すると上半身(上腕)で相手の攻撃を制し破壊力がある
蹴りで攻撃するという独特な戦闘法を取っている事にあることが考えられます。
ここまで述べた時点でもう気づいた方もいるかもしれませんが…

そう、これは二代目霊界探偵の仙水忍さんが体得した霊光裂蹴拳です!あらゆる武術を
体得した上でないと使用が許されないあの!
こうなるとカンガルー先輩は暗黒天使(ダークエンジェル)である可能性まで出てきました。
魔界の穴があくまでもう時間はありません!急げ幽助!








MBED版CMSIS-DAPもなひたふさんビルドのCMSIS-DAPも特に書き込みの性能差はなく、
同様に使用可能ですが何度も言っておりますがMBED版の方はVCPドライバのインストール
を行わないとCMSIS-DAPが認識されないのでご注意ください。




ちなみにフラッシュの書き込みは全般的に遅いです。これはOpenOCDからCMSIS-DAPを
使った時の致命的な弱点で、OpenOCD側のプログラムの構造上PC->ターゲットのデータ
送信時にブロック転送コマンドを使わずすべてちまちまと転送を行っているからです。
Versaloonもおなじような感じなのですがUSBバルク転送なのである程度ひとまとめにして
ドカンとやり取りができ速度的にはまだ何とかなっております。しかしCMSIS-DAPはHID
クラスを利用しているのでバルク転送が出来ず、インタラプト転送になります。

USBのフルスピードの場合はフレームあたり1mSec区切りとなるので、インタラプト転送
でも64バイト送れるはずなのですが、上記のとおりターゲットへの書き込みの際にブロッ
ク転送コマンドを使用していないため4バイトずつデータを送っているのと全く同じに
なってしまい、さらに転送の確認を行っているため実際には2mSecごとに4バイト書き込む
ということになるためどう頑張っても2kByte/Sec以下の書き込み速度になってしまうの
ですorzさらにマイコン-CMSIS-DAP間のSWDのオーバーヘッドもあるので実際の書き
込み速度は1.5kByte/Sec以上出たら御の字ですorz
(注:READの際はブロック転送をおこなっているので早い)

そう言った弱点をトラ技で解説してさらに対策とか講じるのかなと思ったのですが…
OpenOCDに関しては案の定貫徹スルーで商用ツールからの使用を解説しておりました。
解決するためにはadi_v5_cmsis_dap.cにメスを入れて送信時もブロック転送を使えるように
しなければならないのですが他のデバッグアダプタと整合性が取れなくなってしまうので
私もどうしたらいいか今非常に困ってます…。

以前も述べましたがLPC-Link2ならばUSBハイスピードで繋がり、フレーム間隔も125uSec
ごとにスプリットされるので多少速度的にはマシになります。OpenOCDからCMSIS-DAP
をまともに使いたいのなら現状ではLPC-Link2で行うべきです。

20140213追:
なひたふさんも全く同じことを指摘していますね
↑一応記しておきますが…なひたふさんと偶然同時刻に偶然同じ事実を指摘しただけです。
 私は自分の記事を書くのに夢中でなひたふさんのブログエントリを全く見ておらず、
 一切パクってませんのであしからず!
ってしっかり念押ししとかないと斜め読みする人にtwitter上で有ること無いこと流されそうですので

20150406追:
CMSIS-DAPが本来の力を取り戻しました。
糞遅かったOpenOCDからの書き込みも快適に行えます☆


それはさておき今回のトラ技の特集ではなひたふさんがJTAGから始まり主流になった
SWD(正確にはSWJ-DP/SW-DP)に至る流れも含め非常に分かりやすく解説されているので
OpenOCD等のデバッガの動作原理の理解を深めたい方にとって必読だと思います。
基板はあくまでおまけですよおまけ!




おまけのおまけ


F**K!!!!!!

GPS/GNSSモジュールを試用する11 -GtopFlashToolの謎に迫る-

今回の記事はSTM32の内容にもがっちり絡んでくるのでカテゴリどうしようかと悩み
ましたが結局GNSS関連としました。



前回、Gms-g9のファーム更新
の際にGtopFlashToolなるものを使用してUART経由で
ファームウエアのアップデートを行っております。その時にGPSロガーとして使用して
いるSTM32Primer2に仕込んだUSB-CDCからではうまくアップデートを行うことが出来
なかったことを述べておりました。今回時間が出来てようやく重い腰を上げて調べる
ことになったのですがそこには意外な結果が待ち受けていたのでした。


●COMポートが開かない??

Lチカから先になかなか進むことができないねむいさんが唯一実用レベルで作った
STM32Primer2ベースのGPSロガーはSTM32のUSBデバイス機能を利用してGPS/GNSS
モジュールのNMEAセンテンスの記録の他にUSB-CDCとUSB-MSCを実現しております。

USB-CDC機能は主にGNSSモジュールのAGPS等の機能設定を仮想COMポートを開いて
シリアル通信の形で、USB-MSC機能はSDカードに記録したデータをPC上から簡単にTXT
ファイル形式で参照できるように出来ております。


で、GlobalTop GPS Viewer(v1.8)からでは上記のとおり問題なくUSB-CDCの仮想COMポ
ートを開きバリバリ通信できるのですが…

なぜか同じGtopが提供しているGtopFlashToolからはCOMポートが開けませんみたいな
エラーを吐いてアップデート作業ができません。

一方はちゃんとCOM開けてもう一方は開けないとかイミフだったのですが検索してい
るとそれっぽい質問が見つかりました。
Windows環境下ではUSB-CDCをなし得るためにusbser.sysを利用するのですがinfファイル
は自前で作らないといけません。MSDNの情報を基にinfファイルをいじってインストール
してみましたが…やっぱりダメorz

>http://support.microsoft.com/kb/837637/ja
> ユニバーサル シリアル バス (USB) モデムの .inf ファイルは Usbser.sys
> ドライバーを使用して両方および Usbser.sys ドライバー .inf ファイルからを
> 直接参照できます。ただし、お勧めしませんこの。

人間の言葉しゃべれこの。


もしかしてGtopFlashToolが何らかのUSBの通信レベルで何かがコケて仮想COMポート
が見えて無いのかと思い埃をかぶっていた秋月ロジアナを用いてUSBのプロトコルを
解析してみたのですがUSBの通信上ではSTALLした箇所が見つけられませんでした。
↑USBの解析できるまでのロジアナの設定で苦労しましたorz

ちょっと困り果ててしまいましたが鴨川を散歩してる最中にGPS Viewerから仮想COM
開けてたのを思い出してひょっとして何らかの固有の文字列をやり取りしてCOM開い
た判定してるのかと思ってUARTの通信を見たらなんと仮想COM開けてて信号のやり取
りまで出来ているようでした!ちゃんと開けてるじゃないですかー!
しかも制御文字もちゃんと送信されてるのでUART周りは全く問題なしと判断しました。
そもそも糞詰まり対策もやってダブルバッファリングまでしてるのでSTM32のUARTレ
ベルに関する点は問題はないです。となるとやっぱりもっと上の階層の問題ですか。


●別の仮想COMではどうなのか
依然述べたとおりFT232Rに代表される出来合いのFTDIのUSBシリアル変換ICなら全く
問題はなし、自作のUSB-CDCが怪しいと思い別の物を試してみました。

1.STマイクロ謹製のSTM32F1のUSB-CDCのサンプル(STM32F103/107共)
  ->できない
  ※私のSTM32Primer2のUSB-CDCはこれがベースです。
2. LPC2388のLPCUSBのUSB-CDC
  ->できない
3. STマイクロ謹製のSTM32F1/F2/F4用のUSB-CDCサンプル
  ->できるじゃない!
4. MBED CMSIS-DAPのVCOM(FRDM-KL25Zを使用)
  ->できるじゃない!

…ん?それじゃSTM32F1系のUSB機能がやばいのかしら???

5.Versaloon(STM32Primer2と同じSTM32F1系)のVCOM
  ->できるじゃない! orz
  ※VersaloonのUSBのソフトウエア側は独自実装


つまりSTM32のファームウエアの問題ですかorz
でもいろいろ試しててGtopFlashToolのエラーの出方の違いに気づきました!

先にGNSSモジュールをなにも繋がずにフラッシュ書き込みを実行しようとすると
駄目な方は繋いでも繋いでなくても"Fail to open the COM Port"になってて行ける
方はとりあえずCOMポートは開き何か読みに行ってるようで"DL_HANDLE error code"
になっていました。


●SEND_BREAK
というわけでSTM32Primer2のRlinkはOpenOCDでデバッグできないのでそれとソフト的に
等価なSTM32F107VCTのUSB-CDCを用いて上の"Fail to open the COM Port"になる
瞬間をinsightで捉えました…ら一瞬で原因が分かったorz


"Fail to open the COM Port"になる直前にVirtual_Com_Port_NoData_Setup()という
関数を通過していて引数に0x23が来てエラーを返していたことが判明。
この関数はホストから送られてくるUSB-CDC固有のリクエストを扱う関数のようで

このページによれば0x23はSEND_BREAKに相当するものであるとのこと。
STM32F1USB-CDCのサンプルでは未サポートとしてエラーを返していたためGtop Tool
はSEND_BREAKを実行できないCOMポートと判断して"COMポート開けません"とエラー
を返していたことが判明。

ってわけでSEND_BREAKのハンドルを追加してSEND_BREAKのリクエストが送られて
きたらとにかく"USB_SUCCESS"を返すようにしました。


おおっ!

GPSTr@ckerのUSB-CDCでもGms-g9のファーム書き換えできたじゃない♥

GPSViewerではSEND_BREAKは一切送信されていたなかったのでエラーにならなかった
(=COMポートを開くことができた)ことが理解できました。

ところでSEND_BREAKって何か?ともっと調べてみるとUSB-CDC-ACMの規格で定められ
たものだようで文字通り"BREAK信号を送信せよ"という意味です。
そしてBREAKって何というとRS-232Cの規格で定められたものでTxDをスペース(論理L)
に固定する行為を指すとのこと。RS-232Cの電圧レベルでいうと論理が逆転するので、
一定時間+15Vに固定することになります。

そしてGTopFlashToolはなぜわざわざSEND_BREAKを送信していたかということですが、
それはMTK系のGNSSモジュールのファームウエアアップデートの方法にあります。
MTK系モジュールはUART経由で特定のコマンドを受け取るとセルフアップデートモード
に推移しますがその過程で現在通信しているボーレートからセルフアップデート通信
用に自動的にボーレートが上がります。具体的には115200bpsに推移します。このとき
GtopFlashToolからCOMポート経由でBREAK信号が送られているようです。
9600bpsから急にレートの高い115200bpsに上がって間違ったデータとして受け取られ
ないように一定期間データの送信を止める措置を行っているわけです。



というところでいろんなマイコンのUSB-CDCの実装を見ているとSEND_BREAKに対する
取り扱いは現在ではごくまれにしか使われないためかまともにBREAK状態になる実装は
めったになく、適当にOKで返してるのが殆どです。逆に言うとSTM32F1系のUSB-CDCの
サンプルはちゃんと"unsupported"で返してたからマシだったのかも!?

そしてGitHubのGPSTr@ckerは既にGtopFlashToolでもちゃんとファームの書き換えが
出来るように修正済です。さらにFatFs0.10aに更新し今更ですがUSBライブラリもF1系
最終のV4.0.0準拠にして益々最強に強めております!


●あのお方

今回いろいろ調べて最終的に気付いたのですがUSBのファームウエアがらみで困って
いる人のもとに颯爽と現れ強力な解決策を提示して爽やかに去っていくtsuneo氏が
SEND_BREAKにもやはり言及されていました。私の中ではFatファイルシステムにChaN
氏が居ればUSBにはtsuneo氏が居るといった感じです。

そういう私は2014年の今でもUSBアレルギーが全く克服してないのでこれを機会に
今年はUSBを自分の物にすることをテーマに進めていきたいと思います!

GPS/GNSSモジュールを試用する9


すでに静岡ステージにて実践投入開始しちゃっていますがGLONASS対応のGPSモジュー
ルのGms-g9を入手し比較試験を行いましたのでご報告させていただきます。


Gms-g9は前回紹介したGms-g6aのパッチアンテナ版です。中のチップはMT3333なので
基本的な操作に関しては前回とほぼ同一です。ただ、感度の高いパッチアンテナが
付いたモデルなので森深い山中でも活躍しそうです。


恒例のモジュール性能比較です。後で写真をお見せしますがPA6Cと比べると一回り大
きく,]かつてのUP-501と同じくらいの大きさです。あとGLONASS(年末にはGALILEOも
対応になるそうですが)の処理が追加されているので消費電流が3~4mAほど増加してます。



Gms-g9のVCCの入力はご多忙にもれず極力綺麗な電圧を供給しなければなりません。
今回も秋月さんとこで入手できる三端子コンデンサを駆使し規定を見たしました。
この子は2.54mmピッチにうまく載り実装しやすいのでねむいさんのお勧めです★

ギガヘルツ帯レシーバーを作成する際は皆さんご存知の通り配線そのものも極めて
大きく影響してきます。先に紹介した三端子コンデンサもただぶっこめばおkと言う
簡単な代物ではなく、グランドプレーンを流れる電流の経路、デバイスの電流の吸い
込み吐き出しを理解した配置を行わないと逆にノイズをパワーアップさせてしまう
事態になってしまいます。
ムラタ製作所さん他各社から三端子コンデンサやノイズ対策技術の使い方のノウハウが
無償で公開されておりますのでそれらを熟読してしっかり作りこみましょう!




今回は電流プローブで捕捉/追跡動作時の電流波形も採ってみました。
1mSecごとに重たい処理してる感じですね。GLONASSも捕まえてましたがカタログ値より
若干低めにでてました。



お次はフィールド試験です。まずPA6Cとの基本性能の比較を行いました。

大阪城公園のお濠の脇にある天守閣がちらっと見えるベンチ上でベンチをとり補足
時間やDOPの比較をおこないました…が当日はあいにくのくもりでしかも上記画像の
通りQZSS(みちびき)は天頂になく測位に使えないという悪条件下!!

で、こんなん出ました。
御覧の通り明らかに捕捉/測位性能は上回ってますね(HOTでは負けてますが)。GLONASSが
取れるのとパッチアンテナの面積がでかいのが効いているとおもわれます。



フィールド試験第二弾はGPSロガーとして使用した時のランニングテストです。
比較対象のロガーとしてGP101を今回も使用しました。軌跡表示はカシミール3Dを使い、
国土地理院の1/4500地図上に表示しています。GoogleEarthがGN系センテンスを解釈で
きずBSOD(←F**K!)てしまうのでこちらに乗り換えました。
※以下の写真に挿入した地図画像は国土地理院の電子地形図をカシミール3D上にて表示し作成したものを、
国土地理院への申請不要な300x400pixel以下のサイズに縮小して公開しております。


ルートは近鉄枚岡駅から暗峠を越えて南生駒駅に至る超メジャーなハイキングコース
です…がここは暗越奈良街道の一部で立派な国道であります。それではスタート!


最初に枚岡神社に寄ってから国道308号(暗越奈良街道)を進みます。
この辺りは住宅が多いですがまだ空があいてるのでどっこいどっこいですね。


道はやがて勾配が急になっていき森の中を縫い進むようになります。
Gms-g9の方はいい感じに道をとらえてますね。やはり深い森の中で真価を発揮して
きましたよ♥


暗峠近くになると勾配も収まり視界が開けます。ちなみにこの308号線は日中は乗用車も
びしばし通る道なので通行にはご注意を…。

ちょっとここで一休み…。

暗峠手前の道です。※ここは立派な国道です。



暗峠です。歩行者にとってはどうってことないですが乗物乗ってる人はこの石畳が
曲者だと思います。また奈良側の勾配がかなりあり、ボディの長い車は体が引っかかっ
て峠を越えられません(実際に注意書きがあります)。


奈良側に回って大阪側を見ます。暗峠の昔の石碑も残ってます。
画像の左から電磁波が出てる気がするしますがたぶん気のせいでしょう…たぶん


GPSの軌跡や上の画像見たらお分かりでしょうけどもここは生駒山への縦走路にもなって
います。…ねむいさんおそらくここに再び来るかも…。



ちょうどお昼時なので峠にある茶屋でかき氷を食べてきました。
もう夏ですね〜…トレランの時はいつも時間に追われていたので久しぶりに
山(ていうか峠か)でゆっくりできました。


この後一気に峠を下るのでお土産は見送りました…しくしく。


たっぷり休憩を取った後は奈良(生駒)側を駆け下ります。奈良側は見事な棚田が
広がっていますね。


GPSレシーバーは取得る電波の周波数の特性上山の斜面にある道では電波の反射により
非常に捕捉精度が悪くなる傾向があります。残念ながらGms-g9の性能を持ってもちょっと
きついようですね。


※ここは車は通行不可になってますが立派な国道です。
それと見慣れた伊勢参りの札がありますがここも伊勢本街道なの…?


道の勾配も収まりやがて住宅街に混ざります。こういう場所もGPSは非常に
苦手です。それでもGms-g9さんは仕事をしっかりしていた!!


龍田川を越えたあと奈良街道と別れ南生駒駅に到着してゴールとしました。
奈良街道はこの先もまだ続きます。



というわけでGms-g9の威力を存分に味わって今回のテスト終了〜ってことで京都に
帰ろうと思いましたが、思いのほか早く終わってしまったためにもうちょっと散策
してみました。まずは電車で王寺にむかって…



王寺駅から新王寺駅に…何故かこの区間は同じ近鉄なのに駅がつながってなくて歩いて
移動する羽目になる場所です…。



電車でゆられて西田原本駅につきそこから歩いて田原本駅に…何故かこの区間は同じ
近鉄なのに駅(ry



桜井駅まできました。向かうは2年前の真夏に激闘した山の辺の道(東海自然歩道)です。



初瀬川(大和川)にかかる橋を渡り仏教伝来の地の碑がある左側が山の辺の道の
起点/終点です。



2年前に通過した道をさかのぼります。
"→コば市"も健在!


曇ってて良く分からない…



三輪山平等寺の横手から境内に入ります。



ふと見るとベンチに猫ちゃんが寝ていました。
もふもふしても起きず無防備すぎる…。



聖徳太子像の側にも…。
同じく隙だらけすぎる…。


大神神社です。
ねむいさんもしっかりお参りしました。


このあとさらに北上して狭井神社へ。目的は‥。



御神水です。
しかも妙にハイテクでボタン押すと出てくる御神水供給ディバイスに
なってます!!



そしてこれが実物です!
新古一体となった美しささえありますね…。


さて、ペットボトルにたんまり詰め込んで帰ろうか〜
と思ったのですが今さらですが桜井駅以後のGPSロガーの電源を入れるの
忘れてたのでこっから比較再試験開始!


まぁすぐに三輪駅に着いちゃうんですけどね。



誘惑に負けて買ってしまった…
日本酒アイスはクリームと相性悪くてどうしてもパサパサした見た目になっちゃい
ますね〜…これで色が茶色系だったら…ゲフンゲフフン
あ あ 美 味 し か っ た ♥




Gms-g9は立ち上がりの再捕捉性能がすごくいいんですよね〜。
そんなわけでこれからGPSモジュールを購入される方はGms-g9をお勧めします。

いろいろ試す18

GW中は副業(本業は虹裏メイド)が糞ほど忙しかったのですがおかげで給料も貯ま…
るわけがなく円安を迎えた今はひたすら安価な小物や以前に買った物をただひたすらに
消化していきまっす!

●秋月さんとaitendoさんのi2c液晶キャラクタ液晶モジュール

ぇ?昔i2c液晶の記事書いてたやんだって?さぁ?何のことですか?
これのこと?これはキャラクタじゃなくてドットマトリクスですから別物です別物!

…さて、ホビー用途では配線の手軽さから不動の地位を確立したi2c液晶ですが秋月
さんから安価でスリムなAQM0802A-RN-GBW
が発売され私もi2c液晶でびぅです♥

コントローラはST7032iというi2cインターフェースに特化したものだそうです。
BOLIMYINの提供していたサンプルのおかげで危なげなく表示出来ました!


お次はaitendoさんから販売されているバックライト付きで破格のi2c液晶たちです!
もう基板に組み込んでますが、秋月さんのと同じくST7032iのコントローラICで
簡・単・表・示…
…と思いきやO-Familyさんも遭遇したF**Kな不具合にねむいさんも遭遇し,"i2cバス
リカバリ"の重要さを思い知らされる羽目になったのでした…
(※STM32F4のFatFs実装例ではすでにi2cバスリカバリのルーチンを実装しております)

これについてはいずれ解説するであろう"i2c液晶を使ってみる"でみっちりと…


●OZSSとGLONASS対応のGPSモジュール Gms-g9


去年の冬,Gms-g6aというMT3333が乗ったモデルを使用していましたが、チップアンテナ
を使用しているため、せっかくの新モデルなのに初回補足時間/感度はあまりよろしく
ありませんでした。4月末に某送料が安い方の欧州店でパッチアンテナモデルのGms-g9
がようやく販売され、遅ればせながら私もゲッツした次第です。

既に使用されている方のレポートによれば消費電流もPA6Cよりはちょっと多い(GLONASS
の処理があるから)ものの十分控えめなのでSTM32Primer2のロガーと組み合わせても
私のトレラン用途には全く問題ないようです。私はすでにGms-g6aで予習していたので
ロガー側もGN系センテンス対応済みでそのままPA6Cと差し替えて試せそうです。

というわけでいつものユニット化してみました。いちばん右の黒いのがGms-g9です。
PA6Cよりもパッチアンテナの面積が広いので感度はさらに上がっているでしょう。
あいにく今週から梅雨に入ったのでPA6Cとの比較試験は来週以降、トレランでの実践
投入は6月末を実施予定としています。


●ILI934x Mystery
SPIモードでDeviceCodeの読み出しができるようになるまでのお話。
Seeedstudioの中の人がいかにしてデータシートに記載されていない複雑なコマンド
体系を見つけだしたのかはいまだに謎
それとねむいさんの英語力に突っ込みを入れないように!!!




●LPCLink2


LPCXpressoに密着していたLPCLinkはirukaさんの解析によると変更不可能なOTPによっ
て機能が限定されており外部から全くhackすることが出来ずどっかのSTM32では出来た
DiscoveryでVersaloonが出来ないじゃない!と判明しごくごく一部の解析大好きな
好事家からはったくNxPはセコイな!とスル―してゲフンされておりました‥

が、

今回デバッガハードウエア単体として販売されたLPCLink2は回路図全公開、さらに
ファームウエア変え放題でしかもCMSIS-DAPやJlinkファームウエアまで用意している
という超太っ腹なボードとなっておりました!

ねむいさんも秒速で入手しその威力を早速試してみました…

電圧変換は前回紹介した74LVCxTx45系が使用されています。LPCLink2ではDIRを入力
に切り替え疑似的にOD化し、1.2〜5.5Vの非常に幅広い電圧範囲をカバーしているようです。


…LPC4370…?


ねむいさんの目的はJ-Linkです。ほかは一切視界に入れません。THE・シカトです。
そっこう中身のファームをDFUでJ-Linkにしようとしましたがホントの最初はドライバ
不要のHIDローダーで認識されDFUをさらに読み込むようです。この時にDFU用のWinUSB
ドライバ
を読み込ませていないとJ-Linkへのアップデートに失敗するのでご注意を。

WinUSBドライバを読み込ませてこれでJlink化完了!



…ぇっとOpenOCDとかで使ってみましたが‥JTAGKey2と比べるとワンテンポほど反応が
遅くてちょっと微妙な感じです。無理にOSSで使うよりSegger提供のツール使った方が
いいかもしれません。ファームウエア(spifiに格納される)はいくらでも書き換え出来る
のでいろいろやってみましょう。…そう自分で作成したプログラムも…
20130603追:
やっぱりJlinkエミュレーションのファームヤバかったようで
修正版が2013.05.31にUpしてます…。


で、LPCLink2にはTargetのJTAG端子のほかにLPCLink2の心臓部のLPC4370からもJTAGが
引き出されています。LPC4370って検索しても2013年5月末現在は詳しい資料全く出て
いないしLPC4350系のメモリ多い版かしらと思って何気なくUrJTAGで引っ掛けてみると…


なんとコアが3つありました…
CortexM4とCortexM0が2つの合計3コア…
トリプルコアなの!?



次回に続く!!

GPSモジュールを試用する8

20140328追:
最強のGNSSモジュールGms-g9をゲットせよ!

去年、東海自然歩道の家山->久能尾のルートにてGLONASSに対応したGms-g6aという
GNSSモジュールをお披露目しました。今回はこのモジュールと過去の製品と実際の
フィールド上で性能比較を行いましたのでお知らせします。



去年私はMT3339というQZSS(みちびき)対応のチップが載ったPA6Cを紹介しています。
Gms-g6aはそれに加えてロシア版GPSであるGLONASS、同じく欧州版のGALILEOに対応
(ただしオプション扱い)したMT3333というチップが搭載され、アンテナもパッチアンテナ
ではなく軽量小型のチップアンテナとなっています。過去の製品とカタログ上のスペック
を比較すると以下のようになります。



一般的には受信感度は利得に指向性があるパッチアンテナ>チップアンテナとなります
が、Gms-g6aではGLONASSも標準で測位に利用できるのでそれがどこまで寄与できるかに
焦点が集まるはずです!その前に…

先にも言ったようにGms-g6aは指向性が低いチップアンテナのため実装時はパッチアンテナ
の物と全く違う配慮が必要になります。データシートをよく読んで設計を行いましょう。



もちろん電源の配線も重要です。受信感度の低下を抑えるためにVCCラインのばたつきは
50mV以内に収める必要があります。今回は秋月さんの3端子コンデンサを使い、綺麗な
電源電圧波形を得ています。


また、Gms-g6aではGLONASS補足時に吐き出される一部センテンスが動的に変わります。
たとえば$GPRMCの場合は$GNRMCとなりGLONASSの捕捉がわかる仕組みとなっています。
したがって自作のGPSロガーで使用する場合、"$GNxxx"のセンテンスの解釈を新たに加える
必要性があります。さらに使ってみて判明しましたが一定時間補足できないとローパワー
モードに入ってしまい黙ってしまうのでテストパケット等を送信して起こしてやる必要
もあります。詳しい操作はは私のSTM32Primer2を使ったGPSロガーのソースコードを参照
してください。厳しい環境に耐え抜いて使用されてきたお墨付きです。



そして今回の目玉の実地における比較ですが、今回は上空が開けていて遮蔽物がない
場所として、地元の東山山頂公園(将軍塚の近くにある)を実験場所として選びました。

因みにここは野良猫が

沢山いるのですがどの子も不自然に丸々と太った…

ひなたぼっこして…


おっと失礼、本来の目的はGPSモジュールの比較試験でしたね〜

今回の比較試験の対象としてMTK3329が載ったUP501,MT3339が載ったおなじみPA6C、
そして今回の目玉のMT3333が載ったGms-g6aをサンプルとして選び、各モジュールの
cold,warm,hotスタート時の補足時間の平均を行います。


このモジュールはSTM32Primer2をベースにしたGPSロガーに接続され、同ロガーの
VCP機能を経由してPCにUARTのデータを垂れ流しにします。


PC側のツールはGTopが提供するGNSS対応の新しいツール"GPSViewer"を使っています。
各起動状態のテスト回数の指定もできてxlsx形式でデータが保存できるすごいやつです!


Gms-g6aから各状態からの補足時間を記録していきました。この日の最低気温は氷点
下になっていたそうですが…めっちゃ寒かった…ぶるぶる…

…Gms-g6aのコールドスタートの補足がなかなかうまくいきませんので後回し…
まぁ他のモジュールもコールドはこんなもんでしょと思ったのですが…


(UP501の補足テスト中)
やべー曇ってきたよ…風も出てきた…


(↑見えづらいですが雪が舞ってます)
ブルブルガクガク
さてGms-g6aのコールドのデータ取り直そう…
いつの間にか猫ちゃん達も暖かい場所に逃げたようで居なくなっていました。



すっかり体が冷え切った頃に最後のデータも採り終わりましたがおかげで風邪ひいて
しまいました。さて、気になる結果ですが、下の表に今回使用した3つのモジュールの
各状態からのTTFFと各DOPの平均です。

御覧の通りPA6Cが全てにおいて圧倒的な性能を見せつけました…orz
PA6CとGms-g6aはパッチアンテナvsチップアンテナという空中線の性質の差もあります。
残念ながらGLONASSの付与を持ってしてもパッチアンテナの物との差は埋められない
ようですね。とはいえチップアンテナは非常に軽量でパッチアンテナよりも壊れずら
いので測位が少し劣るのを理解して使う分では十分使用に足ると思います(私も実際
に東海自然歩道で使用しましたし)。



というわけでPA6C最強伝説が図らずも証明されてしまいましたがMT3333/MT3332の
乗ったモデルはパッチアンテナ版も存在するようなので為替レートが落ち付いたころにまた
パッチアンテナ版を購入して挑戦していきたいと思います!

LPC800シリーズを使ってみる2

-前回までのあらすじ-
OpenOCDで最初の1kByteしか書けなくてふてくされて他の事やってました。特に
いないさんの誕生日が近づいてきているのでそれの準備に虹裏メイドパワーを
お注ぎ申したり(もう製作完了しました!2月9日はこうご期待!)、副業先の引っ
越しに巻き込まれたり500mも移動してませんが住み家の引っ越しやらでいろいろ忙し
かったのですが、ちょっと落ち着いたのでOpenOCDのコミットを見るとLPC43xx系の
フラッシュありタイプの書き込みサポートがレビュー中状態で追加されていました。

気になって変更箇所見てみるとLPC800シリーズの書き込みにも関する大きなヒント
が見つかったので再びチャレンジしてみた次第です。


ゲームは一瞬で終わっていた…ユーザーマニュアルにちゃんと明記されてたorz
LPC812はLPC2000系やLPC17xx,LPC12xx,LPC13xx,LPC11xxx系と違いIAPスタックの
最大消費量が少し多くなるとの事です。少しの差が成否を分けていたようですorz
そいやvsprogのコードにもそんなこと書いてあったような…まぁいいです。

それをもとにちゃんとドライバを作り込むと拍子抜けするくらい簡単に書き込みが
出来るようになりましためでたしめでたし!

↓LPC812完全対応のOpenOCD+SWD接続のVersaloonで書いた時のメッセージです。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/lpc812_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.7.0-dev-00151-g4a5c9a4-dirty (2013-01-31-19:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : OpenOCD runs in SWD mode
none separate
adapter speed: 250 kHz
cortex_m3 reset_config sysresetreq
Info : Versaloon(0x15)by Simon(compiled on Jul 18 2012)
Info : USB_TO_XXX abilities: 0x0000072E:0x010001EF:0xC0000007
Info : clock speed 250 kHz
Info : lpc812.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
auto erase enabled
wrote 2048 bytes from file main.elf in 0.499965s (4.000 KiB/s)
verified 1600 bytes in 0.109367s (14.287 KiB/s)
shutdown command invoked

> Process Exit Code: 0
> Time Taken: 00:01



↓SWDで繋がるということはもちろんSTlink/V2も使用できるということですね♥
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink-v2.cfg -f target/lpc812_hla_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.7.0-dev-00151-g4a5c9a4-dirty (2013-01-31-19:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
adapter speed: 1000 kHz
none separate
adapter speed: 250 kHz
Info : clock speed 250 kHz
Info : STLINK v2 JTAG v16 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : Target voltage: 2.869535
Info : lpc812.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
auto erase enabled
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
wrote 2048 bytes from file main.elf in 0.343750s (5.818 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x1000002e msp: 0x10000ffc
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x1000002e msp: 0x10000ffc
verified 1600 bytes in 0.062500s (25.000 KiB/s)
shutdown command invoked

> Process Exit Code: 0
> Time Taken: 00:01

STLink/V2のほうが若干書き込み速度が速いですか…!
でもLPC800系はフラッシュ容量の最大が16kByteなので特に気にならないかと
思われます…。



当たり前ですがいつも通りのデバッグもいつも通り可能です。


もちろんSTLink/V2でも自由自在に可能です♥



て訳でLPC812の書き込み・デバッグに完全対応したOpenOCDのバイナリとパッチ
公開します。OpenOCDのLPC812対応に関しては全世界でねむいさんが最初です!
あとは秋月さんがLPC810のDIP品を売ってくれるのを待つばかりですね〜♥
あ、ついでにLPC812-LPCXpressoのプロジェクトも更新してます


おまけ
尺が余ったのでもう少し続けます。

先日ChaN'氏がFatFs0.09bをリリースしました。ドライブのボリュームラベルに対応
しています!ねむいさんもこちらの適用を進めてすでにおきぱにて対応済みのサンプル
を公開しています。今回の作業でSTM32VL,STM32Lでボリュームラベルを設定した時に
ディレクトリ構造が破壊される恐ろしいバグが自分のMMCドライバ側に眠っていたのが
判明したので何気に修正してます。
…ぇーっといままでwriteの方は放置してましたすみません!!

LPC4330を使ってみる2 -OpenOCDでSPIFI-SPIROMに書き込む-

先日秋月さんからもLPC4330-XplorerLPC1830-Xplorerが販売されたわけですが、
ななんとデバッガハードウエアのULINK-MEもついて6200円ですって!本体+DHLの
送料合わせて1万ちかく払って半分壊れたのよこされた私はなんだったのか!?あと
たった2週間ちょっとまてばULINK-MEゲッツ出来たじゃないか!と悔やんでも仕方が
ないのでホビイストとしては手元にあるものを100%活用していこうと思います。特に大将
からご指名受けてしまい放り投げることもできないのですがFatFs実装はあつをさん
おねがいいたします(パタ


さて、LPC4330-Xplorer上ではSPIFIというインターフェースでマルチチャネルI/O対応
のSPI-ROMとLPC4330とが繋がっています。
LPC4330は起動オプションによりこのSPIFI-SPIROMから直接起動&プログラム実行&
リニアな参照ができるというなかなかニクい機能があるわけですが、内蔵フラッシュを
持たないLPC43xx・LPC18xxはどうにかしてこいつにプログラムを書き込まなければ
なりません。有効と思われる方法は以下の2通り。
1.付属のULINK-MEを繋げてKEILのIDEを使ってプログラムをSPIFI-SPIROMに書き込む。
 ↑ULINK-MEもってないので却下。
2.DFUブートローダー経由でSPIFI-SPIROMに書き込む
 ↑情報が出そろってませんがいずれ試します…。
  RAM上には流せられるのは確認しました。


OpenOCDは実はSPIFI-SPIROMの書き込みにすでに対応していましたもちろん公式
にはコミットはされていないので自分でパッチ当て+再ビルド必須ですが、私の試行した
限りではいい結果を得られたので上述の確実な2通りに"もう一つ"追加したいと思います。

20120927追:
公式のコミットにも上がりました!


今回はこのOpenOCDを使った方法をご紹介します。


●その前にGCCでコマンドラインビルド可能なLチカるプログラムをこさえる
前回の時点ですでにOpenOCDにつなげて最初に書き込まれていたSPIROMの内容
のバックアップは取っていましたが自分でこさえたのをやっぱり書き込みたいよねと
いうことでいつもののLPC4330版を見据えたベース作りを行います。

LPC4330のSRAM+SPIFIの構成は以下の図のようになっています。

LPC4330コアの最大周波数204MHzでアクセスできるLocalSRAMは合計で200kByte
ありますがご覧のとおりアドレスは連続になってはおらず、128kByte・72kByte分で
ぶつ切りとされています(AHBRAMは構成的に64kByte分すべて連続アクセス可能です)。

SPIFIから実行した場合,104(MHz)/2(Byte)の読み取り速度のボトルネックがあります
ので見かけの動作速度は超大雑把に見積もって30MHz以下になっちゃいますが、ひと
まず一番単純な構成でプログラムも組み易いEXECUTE FROM SPIFIなメモリプラン
を構成しLチカプロジェクトを組みました。

…やっぱLocalSRAMはSH2Aみたく1MByteくらいほしかったなーと感じますね。これ
100PinのチップですからSRAMもSDRAMも外に引き出すのがまた面倒ですし。実際に
204MHzの動作速度を生かしつつ何か作ろうと思ったらプログラムは128kByte以内に
必ず納めてフォントやテーブルなどの比較的低速でもよい大容量データは全部SPIFI
にうっちゃる等の工夫が要求されるでしょう。

SPFI-SPIROM上動作版のリンカスクリプトの冒頭はこんな感じになってます。


●OpenOCDで繋げて書き込む
現在のOpenOCD0.7.0では公式のソースにSPI-ROMとNxP固有のSPIFIドライバのパッチ
をあてて再ビルドする必要があります。私のぶろぐ上で提供しているOpenOCDのWin32bit
版バイナリ
はこのパッチを適用しています。(下述の書き込みスクリプトも同梱してます)

今回使用するデバッガハードウエアはJTAGKey2Cloneとします。後述しますがLPC4330
のエラッタにより外部リセットの直接操作が非常に重要となるのでリセット(SRST)が使える
ブツが必須です。
それとお気の毒ですがULINK-MEはOpenOCDにハードウエアレベルで対応していない
ので、一切使えません(ファームを書き換えた初代ULINKだけ可能です)!


さて、いよいよSPIFI-SPIROMにプログラムを書き込みます。SPIROMの消去を含む操作を
するためにはFlashのプロテクト解除を必ず行う必要がありました。これを省くと書き込み時に
エラーを返されて失敗します。

↑20130814追:少し前のコミットで修正されました。

↓書き込み時のメッセージは以下のようになります。
 書き込み直後にSRSTを直接操作して外部リセットを2度かけています。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/lpc4330_xplorer_spifi.cfg -c "mt_flash_bin main.bin 0x14000000"
Open On-Chip Debugger 0.7.0-dev-00001-ga4830e7-dirty (2012-09-24-10:03)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
adapter speed: 2000 kHz
Info : clock speed 2000 kHz
Info : JTAG tap: lpc4330.m4 tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: lpc4330.m0 tap/device found: 0x0ba01477 (mfg: 0x23b, part: 0xba01, ver: 0x0)
Info : lpc4330.m4: hardware has 6 breakpoints, 4 watchpoints
Info : lpc4330.m0: hardware has 2 breakpoints, 1 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x10000428 msp: 0x10091fe8
background polling: on
TAP: lpc4330.m4 (enabled)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x10000428 msp: 0x10091fe8
Info : Found flash device 'sp s25fl032' (ID 0x00150201)
cleared protection for sectors 0 through 63 on flash bank 0
auto erase enabled
wrote 65536 bytes from file main.bin in 1.062507s (60.235 KiB/s)
shutdown command invoked
Polling target failed, GDB will be halted. Polling again in 100ms


なんでわざわざSRSTを直接いじっているかというとLPC4330-Xplorerに乗っかってる
チップのリビジョンは内蔵されたSPIFI-ROMドライバがPOR後の外部リセットした後の初期化
で必ずコケて次の外部リセットで正常に動くというイミフなerrataに起因してます。
こいつのせいで今までうまくいった正攻法が全く通じずワークアラウンド満載な
書き込みスクリプトにせざるを得ませんでした。
まぁ結果的に安定したからOKということにしましょう。因みSRSTを繋げてなくてもSWD
接続のversaloonやSTLink/V2で書くことはできますが、この場合いちいち主電源を入り
切りする必要が生じ面倒です。

また、デバッグ中に変なステートに落ち込んでJTAGのアクセスが一切不能に陥ることも
あります。この場合はディップスイッチでブート方法を別の経路にして電源を入れ直すと
ひとまずJTAGで繋がるようになるので落ち着いてSPIFI-SPIROMの内容を全消去して
ください(その後はブート方法をもとに戻すのを忘れずに)。


●OpenOCD+Insightでデバッグ

最後の仕上げにOpenOCD+Insightでソースコードデバッグできる環境も作りました。
こちらもワークアラウンド満載でgdbにattachしたときにsoft_reset_haltをかけてプログ
ラムの先頭で停止するようなトラップを仕掛けてます。

SPIFI-SPIROM上のプログラムを直接参照できるのでとてもありがたいですね♥
もちろんいつものIOViewでGPIOのビットの状態も一目でわかります♥
ちなみにGPIOの初期設定の時にInputBufferを有効にしておかないとピンの状態が一切
読めませんのでご注意ください!(普通のプログラムでも引っかかりやすいポイントです)


●SPIFI-SPIROMからブートしてSRAM上で実行してみる

SPIFIから実行すると大幅にパフォーマンスが下がってしまうので実際に使えるレベル
で試用するならばLocalSRAMからプログラムを実行する必要があります。SRAMの構成上
プログラムと初期設定値があるデータと合わせて128kByte以内に収めないといけない
制約が出来てしまいます。したがって大容量のフォントorデータテーブル等はSPIFI
におきっぱにしておくべきです。

今回はPCと連携せずにスタンドアロンで起動し、SRAM上で実行できる環境を拵えます。
原理としてはきわめて原始的なブートローダをSPIFIに仕込む形になりますが、大まかに
いうと以下の流れで行います。

1.SPIFIのアドレス(0x14000000)からブート

2.Reset_Handlerに飛ぶ(けどアドレスはまだSPIFI上の0x1400****)

3.".text"〜".data"の領域までLocalSRAM(0x1000000)にコピー

4.PCをSRAM上に指定してジャンプ

5.BSS領域をゼロクリア・各種クロック・I/O設定

6.main()に飛ぶ



"4."の部分がミソなわけですが実際のアセンブラのコードを見てもらうと…

一見無意味なことしてるように見えますがその場(SPIFI上)でジャンプすると着地点が
LocalSRAM上になりそのままSRAM上で何事もなくプログラムを継続できる仕組みに
なるわけです。
もうお気づきの方いると思いますが大昔AT91R40807でやってたことと全く同じですね。

また、上記のからくりを実行するためにはbin形式でSPIFI-SPIROMに書いてやる必要が
あります。LMA/VMAの情報を保持しているelf・ihex形式だと失敗しますのでご注意を。



ということでLPC4330-Xplorerもこちらこちらに準拠したビルド・デバッグ環境をこしらえ
ました。あとはどんどん上位層のプログラムを作りこんでいくだけです!


20121003追:
GCCビルド可能なLED点滅(シングルコア動作)プログラム公開します。

LPC4330はぢめました -まだLチカもできない-


積み基板どころか"詰み"基板になるのが分かっていながら人はなぜ、何故、同じ過ちを
繰り返してしまうのだろうか?



…しかしねむいさんはLPC1788にMCI版FatFsを移植を行ったので十分挑戦権があると
自負しています!日本のアマチュアでは今度こそ一番乗りで(あつさんがすでに触ってました…)LPC4330
搭載されたLPC4330-Xplorerの使用感を報告させて頂きたいと思います!!
この基板インド製だそうですがもう時代は中華大陸飛び越えてインドですよインド!


さて、この基板はNxP社肝入りのCortex-M4F+CortexM0のデュアルコアが搭載された
最新のマイコンLPC4330が搭載されています。最大動作周波数はCortex-M系最高速の
204MHzに上り(M4,M0コアの両方とも)、クアッドSPIが使えるインターフェース"SPIFI"も
搭載されています。


USB-HSのPHYもLPC4330内に搭載しており(USB0のみ)、外付けHS-PHYも必要ありません!
もちろんねむいさんのいつものに必要なMCIインターフェースもあります!


んでもって基板の構成ですがSTM32F4Discovery宜しく音アプリを強く意識した構成と
なっていてAudio-CodecやEthernet-PHYも実装されています。さらに基板上にMicroSD
カードコネクタやSPIFI用のシリアルROMも乗っていてFatFsの移植も少しは楽になり
そうですね♥



さぁケーブル繋いで通電だー!と思ったのですが良く見るとコネクタがなんだか変…






写真分かりづらいですが無理やりねじこんだように金具の上側が微妙に曲がってます…



そして付属ケーブルの口見たらこんなになってやがりました…
注:最初からこんなになってました。ねむいさん壊してないですよぅ!
  もちろん刺さりませんorz



もうナン持ってイェェと叫びたくなるのを我慢してさらに基板をよく見ると
手半田で修正した跡がありDIPスイッチが溶けてLEDが焦げてました…
もうダブルオドロキですよねほんと印度クオリティすごいってまたひt


インドのNGXから直接購入したので修理交換の手間と金が非常にかかってしまうと感じ、
結局自分でコネクタ・LED他の付け替え修理を行いました。
LPC4330-Xplorerに実装されたmicroUSB-Bコネクタとほぼ似た形状の奴をtaobaoで購入
しており、スムーズに付け替えは完了しました。ちなみに秋月さんちで売ってるタイプの奴
はコネクタを挿す向きとピンの並びが逆のため付け替えができません!ご注意ください。


LEDの交換ついでに3.3VのLDOもMLCCが使用可能なZLDO1117に換装しておきました。
最初に付属していたUSBMicro-Bのケーブルは捨てて手持ちのを使います。

後はチュートリアルに従いVcomのドライバ入れて基本操作を確認しました。

NGXのチュートリアルにはUSB0サイドのUSBHIDデバイスは挿したらすぐに動くように
見られますがまずUSB1サイドをPCに刺し、その次にUSB0サイドをPCに刺し、最後に
SW2を押すとUSB0サイドのHIDデバイスとして認識されるようになります。



またSW2を押した後は仮想COMポート上で上画像のように各種チェックルーチンが
走るようになっています。


同時にEtherNetもアクセス可能です(192.1681.1.123固定なのでご注意下さい)
LEDの操作がブラウザ上から可能になっています。



最後にJTAGで繋いでみてOpenOCDからどう見えるか確かめてみました。
LPC4330-XplorerのJTAGコネクタがちいさ過ぎてTI-StellarisのICDI付属のケーブル
しかピッチが合うのなかったので、JTAGkey2Cloneの代わりに急遽これを使いました。

↓で繋いだ状態はこんな感じに…
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/luminary-icdi.cfg -f target/lpc4350.cfg
Open On-Chip Debugger 0.7.0-dev-00001-ga4830e7-dirty (2012-09-10-17:57)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 500 kHz
cortex_m3 reset_config sysresetreq
Info : clock speed 500 kHz
Info : JTAG tap: lpc4350.m4 tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: lpc4350.m0 tap/device found: 0x0ba01477 (mfg: 0x23b, part: 0xba01, ver: 0x0)
Info : lpc4350.m4: hardware has 6 breakpoints, 4 watchpoints
Info : lpc4350.m0: hardware has 2 breakpoints, 1 watchpoints

確かにCortex-M4とCortex-M0のふたつのコアが見えてますね〜

ほんとに触っただけというかそれ以前のやっと修理したばっか状態なのでLチカ
すらも進んでませんが、豊富なサンプルをベースにいつものを作っていきます。

LPC1114を使ってみる3

こちらこちらの記事に続いて通算3つ目のLPC1114についての記事です。

前回述べたとおり秋月さんよりLPC1114のDIP版が180円で販売されて私も購入しました。
"どうせLチカ(LED点滅の意)で終わらすんだろ"とお思いの方が大多数とは思います。
その通り私はDIP版LPC1114をLチカせしめてこの記事を書くためだけに購入しました!
と、すべてに対する防御壁作ったところで今日の本題に入ります…。


●DIP版LPC1114のいいところ
1.ブレッドボードに最適なDIP28Pinなのはいいのですが600mil幅という無駄な広さ
 
 IOとかSRAM削ってる(後述)くせにこの広さって…"ほらDIPにするとこんな
 無駄にでかくなっちゃうんだよみんな面実装の奴使おうね★"というメッ
 セージなのでしょうか…

2.SRAMの容量がTQFP48Pin(面実装品)の物から半分に削られた
 "TQFPパッケージは8kByteも使えるよみんな面実装の奴使おうね★"という
 メッセージなのでしょうか…

3.I/OピンがTQFP48Pin(面実装品)の物からいくつか削られた
 "TQFPパッケージはもう少しI/Oピンが使えるよみんな面実装の奴使おうね★"
 というメッs もうええっちゅうに

LPCXpressoに乗っているLPC1114と違う点は上記DIP版はPowerProfileが追加された
第二世代のLPC1100Lにカテゴライズされる製品となってます。現在はLPC1100XLまで
ラインナップされています。


●Lチカる
基本的にLPC1114のソースコードがそのまま転用できますが、上述のとおりSRAMが
4Kbyteしかないのでスタックの値は要調整です。私の公開してるプログラムはMARYにも
対応してる(内部RCをPLLのソースとする)ので取り合えず定義をこちらにしてやればVCC・
GND・SWDIO・SWDCLKのたったの4本でOpenOCDから書き込み・デバッグできます。
(なぜかリンカスクリプトファイルを全くいじらず8kByteのままでもふつーに動きました…
STM32F107みたく隠しでSRAMあるのか!?)

が、

OpenOCDで繋がるってことはソースコード一行も書かなくてもGPIOくらいは動かせられる
(=Lチカれる)ってことで早速やってみました。ブレッドボードすら使いません!1!

…ねむいさんただTCLの"スクリプト"組んだだけだからねCの"ソースコード"は一行も書
いてないy止めろ石投げるな



●LPC1114(DIP版)にプログラムを書き込む
注:2019年現在はこの方法は古すぎて通用しません!
私の最新のOpenOCDバイナリに同梱されている説明書きと対応MCUをよく読み
コンフィグファイルとコマンドを実行してください!


…さて、今度こそ真面目にソースコードビルドして出来たプログラムを書き込みます。
書き込む方法は何通りもあります。UARTブートローダー(ISP)を利用する場合はFlashMagic
使って書き込む・ChaN氏のLPCSP使って書き込むという方法が、さらにSWD接続においては
LPCXpressoを使用して書き込みを行う詳しい方法がLynx-EyEDあつ氏から紹介されています

私が紹介するのはおなじみのOpenOCDからSWD接続のVersaloonやSTLink/V2を使って
書き込みを行う方法です。OpenOCD0.6.0ではCortex-M0並びに一部のSWD接続可能な
デバッガハードウエアのサポートが進められています。
Versaloon使って書き込む方法はこちらこちらを参考にしてください。
DIP版のはSRAMが4kByteしかないのでLPC1114ではなくLPC11U14(←SRAMが4kByte)
と思って書き込みしてやるとうまくいきます。

↑Versaloonで使う場合はlpc11u14_swd_flash.cfgを指定すれば終わりです。


次に、デバッガハードウエアとしてSTLink/V2を使う方法ですがこちらも手順は確立
されていてVersaloon並みに簡単に書き込み・デバッグが可能です。
今回はSTM32F0Discoveryにビルドインされた物をSTLink/V2として使用します。おそ
らくCQ出版系の雑誌記事では営業的な理由で絶対にお目にかかれない内容なので
私が紹介してる方法は貴重なものになるかと思います。



↑外部にSWD線・電源線を引き出す準備です。


lpc11u14_stlink_flash.cfgを選択。
20130501追:
時代は変わり、STLink/v2以外にもベンダ提供APIが使えるデバッガが出来てきましたので
現在はlpc11u14_hla_flash.cfgに変更しております。
-f lpc11u14_stlink_flash.cfg から

-f interface/stlink-v2.cfg
-f target/lpc11u14_hla_flash.cfg

と読み替えてください。

20140829追:
さらに時代は変わりました。
HLA系のデバッガアダプタの使用例はこちらをご覧ください。

ねむいさんのぶろぐで公開しているOpenOCDバイナリはすでにこのコンフィグファイル
は含まれております。また、今回のDIP版LPC1114やLPC11U14等の少SRAMの品種の
書き込みに対応するためにlpc2000.cへのパッチは必須となりますが、ねむいさんの
OpenOCDバイナリはパッチ済ですので安心してお使いください。

20130314改変:
OpenOCDからSTLink/V2を叩く時のデバイスドライバはSTマイクロ提供の物
そのまま利用可能です。逆に以前使用していたLibUSB(libusb0.1系)は廃止し
使用不可能なのでご注意を!



↓にSTLink/V2で書き込んだときに表示されるメッセージを置きます。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f target/lpc11u14_stlinkv2_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-rc1-dev-00015-g47728f9-dirty (2012-08-29-17:12)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
1000 kHz
none separate
250 kHz
Info : clock speed 250 kHz
Info : lpc11u14.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x1fff0040 msp: 0x10000ffc
auto erase enabled
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x81000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x81000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x81000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x81000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
wrote 4096 bytes from file main.elf in 0.468753s (8.533 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x100000e2 msp: 0x10000ffc
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x100000e2 msp: 0x10000ffc
verified 1580 bytes in 0.062500s (24.688 KiB/s)
shutdown command invoked


フラッシュメモリの容量が32kB程度なので速度もそれほど必要ないかと思います。

異なる会社間のツールが使用できるのか!?
そもそも出来たばかりの未知のチップに書き込みができるのか!?
否、出来る、出来るのだ!集中線のフォーカスが明後日の方向いてるけど!

20130427追:
↓うまく書き込みができない場合の確認事項↓

1.そんな結線で大丈夫か
  ->もう一度ターゲットとSTLink/V2のSWD信号がちゃんと繋がってるか確認!
   そんな基本的なこと間違うわけないだろって奴に限って間違ってます!

2.そんなDiscoveryのジャンパ設定で大丈夫か
  ->STM32L/F4/F0DiscoveryにビルドインされたSTLink/V2はデフォルトでは
   STM32側に繋がってます。ジャンパを必ず外しましょう。
   STLink/V2はマルチドロップSWDに対応していないため通信がこけます。

3.そんなVtgtで大丈夫か(←これで引っかかる人多し!)
  ->V17以降のSTLink/V2のファームはvtgtをきっちり合わせないと撥ねられて
   書き込みが失敗します。かならず接続しましょう。
   STM32L/F4/F0DiscoveryにビルドインされたSTLink/V2ではVtgtからAD入力
   に繋がる抵抗が未実装なので回路図をよく見て100ohmも必ず実装しましょう。


おなじみInsightを使用したデバッグ画面。I/OもIOViewも楽々操作です♥


上記の操作をすぐに試すことができるLPC1114DIP版も対応のプロジェクトファイルはこちらです。
ビルド手順はこちらを、デバッグ手順はこちらを参照してください。
DIPに対応するにはmakefileの定義を少し変えるだけでOKです!


●大事なことなので何度でも言います
最後に注意点ですが(これも過去に何度も何度も言及していますが)LPC1114を初めて使う
際は、NxP系のマイコンに存在するCheckSumValidationやCodeReadProtectionも考慮に
入れてください。詳しい解説は本家のユーザーマニュアルに譲りますが、LPC1114では
内蔵フラッシュからプログラムを実行する場合、下図のような構成にされるべきです。


基本的に"ActiveVectorRegion"のCheckSumValidationより少ないアドレスにある情報は
ほぼ固定値となるので(変わるとしたらスタックの頭を変えるときくらい)リンカスクリプト内
でも"KEEP(hoge)"で固めておくとビルドのたびにCheckSumの値を変える必要がなく非常に
便利です。LPCXPressoやmbedではCheckSum値は書き込み時に自動計算されて書き込
まれるのでユーザーは意識しないで済みますが、上記のことを知っておかないと素でビルド
した時にLPCXpressoで動くはずのプログラムが"動かない"と詰まる羽目になります。
(実際にはISPに飛んで行ってしまいます)

また、CodeReadProtectionも0x2FC番地という場所にあってこれを厳格に定義してしまうと
0xC0~0x2FBまでのフラッシュ領域が無駄になってしまいます。よってこちらもあまり変える
ことが無い".data"や".bss"等のSRAM領域の初期化ルーチンを決め打ちで置いてやるように
すればフラッシュ面積の無駄になりません。

私が公開しているプロジェクトのNxP系のマイコンはすべて上記の考慮をしておりますので、
AVRやPICから入られた方は、一度リンカスクリプトやスタートアップファイルをじっくりと読み、
どのように組むべきかを把握しておくとのちのちに役に立つでしょう。


あ、NuvotonのNUC120のこと忘れてた…

いろいろ試す13

DIPのLPC1114の話がここかしこで持ち上がっていますがSRAMの容量半分に削られてるし
ねむいさんはふつーにスルーさせていただきま…
と言いたいところでしたがなんと秋月さんからもリリースされましたので方針を360度変更
してこちらでも取り扱います!!!乞うご期待!!!

それと私が提供してるOpenOCDのバイナリとVersaloon使ってデバッグとか書き込
みでしようとして躓く人必ず出てくると思うので思うので一応注意を書いておきます。
下記の2点さえ抑えていれば大丈夫です。
1.SRAMが半分に削られてるのでlpc1114_swd_flash.cfgじゃなくてlpc11u14_swd_flash.cfg
 を使用するべし。
2.Windows使いの人以外でOpenOCDビルドする必要がある人はlpc2000.cにパッチを当
 てないと書き込みができません。詳しくはここ参考にするべし。

ちなみに2.のOpenOCDビルド手順はUbuntsuやマカーな方にとっては未だに需要がある
ので新たに整備が必要だと感じてきました。逆にWindows使いの方は9割がたEclipse環境
に行くので初見で私のぶろぐまでたどり着く人は実はものすごく少なくそもそも知ってても
みなかったことにさr

…さて、前ふりはこの辺にしといて小ネタが貯まってきたので消化していきます。





●LPC1788にMCIインターフェース版FatFsを移植する。

やっとこ安定化しました…。結局I/Oポートの初期化がおかしかっただけだったという
なんたるイージーミス…
LPCwareのサンプルも同じ間違いしてるから中の人に伝えておきました。

LPC2388ではメインSRAMに直接DMA出来ないため、ChaN氏はUSBRAMとリンクリストで
順繰りに効率的に転送するかたちを取っていました。私の場合もLPC1788ではAHBRAMを
使用して同じことやってます。AHBRAMとメインSRAMは独立しているので転送中別の処
理やってもフンつまりにならないのです。


MCIのクロックは定格内で20MHzまで設定できます。転送効率が良いのでリード速度は
理想値に近いですね♥ちなみに定格に外れますが30MHzも設定は可能です。

↓外人さんもよく来るので英文でメッセージ
Finally,FatFs for LPC1788 MCI interface turns stable by Nemuisan's works!
You can get sourcecode Here!



●SANDISKのUSBメモリ
ごく一部で話題沸騰だったSANDISKのUSBメモリを欧州のebay経由で購入しました!
2012年8月現在は日本国内の通販でも安価に購入可能です。

SDCZ80-032G-X46っていうUSB3.0対応のメモリなのですが、一般に安く売られている
USB3.0な奴と違って小さいサイズのファイルのランダムアクセス(特に書き込み)にも非常に
強く、私のようにレス用画像をUSBメモリに入れてる方にはもってこいのアイテムです♥


deflaggerで見るとSSDが検知されています。SSDをUSB3.0に変換してるタイプの奴な
のでチマチマ書き込みにも強いのですね。こちらの方はさらに詳しく調べられています。

-----------------------------------------------------------------------
CrystalDiskMark 3.0.1 x64 (C) 2007-2010 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

Sequential Read : 195.029 MB/s
Sequential Write : 117.804 MB/s
Random Read 512KB : 144.212 MB/s
Random Write 512KB : 25.899 MB/s
Random Read 4KB (QD=1) : 13.372 MB/s [ 3264.8 IOPS]
Random Write 4KB (QD=1) : 9.992 MB/s [ 2439.5 IOPS]
Random Read 4KB (QD=32) : 11.232 MB/s [ 2742.2 IOPS]
Random Write 4KB (QD=32) : 3.699 MB/s [ 903.1 IOPS]

Test : 1000 MB [E: 0.2% (0.0/29.8 GB)] (x5)
Date : 2012/07/30 9:05:28
OS : Windows 7 SP1 [6.1 Build 7601] (x64)
SDCZ80-032G-X46 FAT32 Vostro3350_Win7x64_USB3.0Renesas_64kbclaster

↑買ったばかりの時のベンチ結果です(検証に使ったPCはDellのVostro3350です)。
 スクショ取り忘れたのでこぴぺで…
 中身がSSDなので64GB版はさらに早くなるようです。

-----------------------------------------------------------------------
CrystalDiskMark 3.0.1 x64 (C) 2007-2010 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

Sequential Read : 131.462 MB/s
Sequential Write : 23.899 MB/s
Random Read 512KB : 121.063 MB/s
Random Write 512KB : 5.004 MB/s
Random Read 4KB (QD=1) : 10.935 MB/s [ 2669.8 IOPS]
Random Write 4KB (QD=1) : 0.240 MB/s [ 58.5 IOPS]
Random Read 4KB (QD=32) : 11.655 MB/s [ 2845.4 IOPS]
Random Write 4KB (QD=32) : 0.281 MB/s [ 68.5 IOPS]

Test : 100 MB [E: 0.0% (0.0/14.7 GB)] (x5)
Date : 2012/07/12 9:26:14
OS : Windows 7 SP1 [6.1 Build 7601] (x64)
USM16GQ/SC FAT32 Vostro_usb3.0_64kb

↑SONYのUSM16GQ/SCと比較。やはりSanDiskのほうが性能がダンチです。


↑約一か月使い込んだ後
 512kと4kのWriteかなり劣化してしまいましたorz


↑今日日のSSDならSecureEraseとかTrimとか使えるはずですがSanDiskから
 そういうツールも提供されていないので黎明期のSSDでよく使われていた
 空き領域のデフラグやってみました…ちょっとだけ性能回復♥



●中華MP3プレーヤー LYUMO M21
ヨドバシで安さにつられて買ってしまったこれは値段通りの性能でした…
めでたしめでたし。

…で終わるわけがないので捨てる前に分解してみました。


生意気にケースは金属製です。


…チャイナクオリティ…ショートしたらやばいですよぅこれ


操作した時に液晶の切り替えがやたら遅いので気になってましたがどうやら私のぶろ
ぐでは定番のMCUバスタイプの中華液晶モジュールが使用されているようです。


ねむいさんは中華液晶を何年も何種類もいじってきましたのでこの文字列見ただけでも
何を意味するか分かります。お尻の"OTM2201"がコントローラICの型番を示します。
そこからi8080接続タイプで176x220の解像度を持ったTFT液晶モジュールであることも
わかります。


液晶モジュールだけ取り外してSTM32F4でうごかしてみました。ピン配置の判定も過去
のデータベースから推定して一発で判明しました♥
ちなみにOTM2201のはずなのにDeviceIDを読んで判明した正式なコントローラICはS6D0164
でした…まぁ中華クオリティ(ry



●いつもの中華液晶たち
aitendoさんから出ると脊髄反射的に手に入れようとしてしまう性格を直さなければ
と思いつつまた動かしていた…

S95311
 
 まだデモコードが提供されていませんがコントローラIC(HX8340A)とピン配置が判明
 しています。QCIFサイズで8bitバスのモジュールではよくある配置なので楽勝です。
 初期化手順も中華サイトを巡ってさらにこの液晶用にガンマと表示方向を指定して
 あげれば余裕です。
 i8080な8bitバス専用です。
 
 8/27の雪子ちゃん誕生日記念の際に作ったコラ絵を映してみました。
 ※今年はえろす抜きです

S93610
 
 コントローラICはILI9163Bです。まだデモコードが(ry
 i8080な8bitバス専用です。
 
 コントローラICとしては何度も動かした実績があるので今回も楽勝です

S95417
 
 ピン配置はYHY024006Aと同じタイプの2.4inchのモジュールです。まだ(ry
 i8080な16bitバス専用です。8bitに切り替えができません。
 
 こちらのコントローラICはST7787でILI9340やR61526系統のコマンド体系となってい
 ます。しかしながらSTM32F2/F4のような高速でぶん回せるバスの速さに追従し切れ
 ないようなのでGPIOによるエミュレーションかXMEGA等の少し遅めのバスで動かす
 のが良いかと思われます。

S95461C
 
 WQVGAタイプのTFT液晶モジュールです。ま(ry
 i8080な16bitバス専用です。8bitに切り替えができません。(意味深)なチップ抵抗
 があることにはありますが載せ替えても16bitのままです。

 
 2年前にHX8352Aのものを動かしたことがあります。今回のはHX8352Bです。似通った
 コマンド体系ですが細かい部分の動かし方が微妙に違います。特にレクタングル指定
 では内部メモリアドレス指定のコマンドも追加する必要がありました。よって初期化時
 に双方のコントローラICを判定してそれぞれの初期化ルーチンの最後にレクタングル
 指定用の関数のポインタを割り振るようして条件分岐による速度低下の発生を抑える
 ように工夫しました。



 そしてChaN氏のFatFsも久々に更新されたので、いつものにも更新ついでに上記モジ
 ュール他に対応しておきました。いつものに収録されているTFT液晶ドライバ群は隠れた
 人気があるようです。特にHX8347Aについては検索で飛んでくる方も未だに多く、役に
 立ってると私は思(いこんで)います。


 


 ●おまけ
 本来はNuvotonのNUC120やM051をOpenOCD使ってデバッグするのも紹介するつもり
 でしたが、意外とボリュームあるので次回LPC1114DIP板の記事の時にご紹介します。
 代わりに…

 taobaoでSTM32の生基板大量に買ったついでにまた買ってしまったTFT液晶たちを。
 気が付いたら殆ど使いもしない液晶モジュールを150種類以上持っていた私…

 
 R61509V互換のILI9326をコントローラに持つWQVGAのモジュールです。

 
 H016IN61というH016IT01(H161T01は間違い)のパラレルバス版みたいなの
 LEDは2個直列なので6.2Vくらい必要です。

 
 QCIFサイズでSPI接続専用でしかもタッチパネル付きの液晶です。LEDは並列3つで
 3.3V単一電源でもOK。以前は3-wire,9bitシリアルの奴に苦しめられましたが、こいつは
 4-wire,8bitシリアルで非常に扱いやすいです♥aitendoさん!!これ国内で販売
 したら大ヒットまちがいなしですよぅ!
 
 
 とにかく動かすの優先だったので配線が全てやっけつなのは許してほしい。

STM32F0シリーズを使ってみる


ッついに!手に入った!!!
ぁすみません・・フォーカスずれてましたね…
このBeachBoysのコレクターCDは探して探して探してカナダの片田舎のレコード屋でやっ
と在庫を見つけてそこの親父にねむいさんのインチキ英語でなんとか意思が伝わって
やっとこ購入できた代物でして存在知ってから入手まで実に2年を要したのですがその
労力を払っても聴く価値のある非常にありがたいCDなのです…!
BeachBoysの新アルバムも発表され、ワールドツアーも行われるようになってねむいさ
んの中でBB熱が再び非常に高まっております。



aitendoさんから販売され、秒速で売り切れたandroid基板をねむいさんも無事ゲッツしました!
twitterのTLを見ているとどうやらこちらの中華PADの中身に使用されている基板だと判明
しているようです。しかしねむいさんはHDMI接続のモニタ持ってないので、先に購入して
いるBeagleBoardXMのDVI-Dにも対応した小型モニタを探す旅から始まりそうです。
こうして積み基板が増加していく…。でもいいんです買っただけで満足ですから!








それでは本題行きます…。今年の春先にSTマイクロさんより"STM32のDNAを御得な値段
であなたにテコ入れする(直訳)"をスローガンにCortex-M0系のSTM32マイコンが発表、
販売を開始しました。国内/海外の展示会場でもゲッツした人もすでにいますが、Digikey
でもSTM32F0-Discoveryが入荷されたので早速購入してみました。

いつものST謹製"Discovery"スタイルの基板で、cortex-M0系のSTM32F051R8T6
搭載されており、日本円で1000円以下のお値打ち価格となっています。
もちろんデバッガハードウェアのSTLink/V2もオンボードで搭載されていてこの基板と
USB(A-miniB)ケーブルさえあれば開発可能です。

しかも今回はプロトタイピングを重視した作りか同じサイズのユニバーサル基板が一枚
ついています。値段を考えると非常にお得です♥(実際にArduinoと組み合わせた
ファームウェアのプロジェクト一式がダウンロードできます)。


現在M0系でポピュラーなのは私のぶろぐでも取り上げていたLPC1114に代表されるNxP
系マイコン(評価基板は3000円前後)ですが、ここに1000円以下の破格値で参入したこ
とによりまたまたホビーユースにおける小規模ARMの勢力図が書き換えられるかと思わ
れます。

さて、最初の基本であるLED点滅から開始するわけですが、LPC1114系のマイコンで培
ったリソースがすでに大量にあるのでこれをベースに15分くらいでSTM32F051R8T6向け
のプログラムをやっけつしてビルドを行います。NxP系と違う点はCRPのための特別な定義
が必要ないところですね。それ以外はスタートアップやリンカスクリプトもほぼ流用します。

次に書き込み手段ですが…もちろんSTLink/V2をOpenOCDから操作して、書き込みや
デバッグを行います。使用するドライバはSTマイクロ提供の物(WinUSB)です。
STM32F051R8T6もM0なNxP系のマイコンよろしくデバッグ用ポートがSWD接続しか存在
しませんがパッチを当てることによりVersaloonとSTLink/V2がOpenOCDから使用できます。
さらに気づいたのですが、最近のOpenOCDのコミットではM0系のデバッグ機能が強化され
ていて以前はcrcエラーが出てしまい不可能だったフラッシュ書き込み時のベリファイも
可能になっています♥


↓STLink/V2でOpenOCDから書き込んだときのメッセージはこんな感じです。
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd_m0 -s C:/Devz/ARM/OCD/tcl -f target/stm32f0x_stlink_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00595-g445a54a-dirty (2012-05-28-09:15)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
1000 kHz
srst_only separate srst_nogate srst_open_drain
Info : clock speed 1000 kHz
Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x080007c8 msp: 0x20002000
auto erase enabled
Info : device id = 0x20006440
Info : flash size = 64kbytes
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003e msp: 0x20002000
wrote 3072 bytes from file main.elf in 0.265629s (11.294 KiB/s)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20002000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20002000
verified 2408 bytes in 0.078126s (30.100 KiB/s)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x080007c8 msp: 0x20002000
shutdown command invoked

> Process Exit Code: 0
> Time Taken: 00:



↓Versaloonの時はこんな感じです。
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd_m0 -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/stm32f0x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00595-g445a54a-dirty (2012-05-28-09:15)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : OpenOCD runs in SWD mode
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : Versaloon(0x15)by Simon(compiled on Feb 29 2012)
Info : USB_TO_XXX abilities: 0x0000076E:0x010001EF:0xC0000007
Info : clock speed 1000 kHz
Info : stm32f1x.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x080007c8 msp: 0x20002000
auto erase enabled
Info : device id = 0x20006440
Info : flash size = 64kbytes
wrote 3072 bytes from file main.elf in 0.265628s (11.294 KiB/s)
wrote 2408 bytes from file main.elf in 0.093752s (25.083 KiB/s)
verified 2408 bytes in 0.140626s (16.722 KiB/s)
shutdown command invoked

> Process Exit Code: 0
> Time Taken: 00:



当たり前ですがどちらの方法でも危なげなく動作します。


もちろんOpenOCD/Insightを使ったデバッグも無制限でバリバリ可能です!



今回の検証に使用したコードはすでにおきぱにて公開していますので自己責任のうえで
お試しください。また、おきぱにあるCortex系のコードでCMSISが使用されている物の
ほとんどはすでにSTREX系命令のビルド時エラー対策の修正がされているCMSIS3.0系
を使用していますので安心してビルドが可能です。

STM8Sは値段は安いですがちょっとあつかいにくいきらいがありました。しかしSTM32F0
なら敷居がさらに下がって小規模マイコンでARMを使用する人も増えるでしょう。
秋月さんからの販売がカギとなると思います。
20121115追:
秋月さんから販売されました!

いろいろ試す11

●STM32L-Discovery
少し前に秋月さんからSTM32L-Discoveryが販売されましたが、遅ればせながら私も
入手しました!


これでDiscovery系のボードもほとんど手に入れましたね。

さて、いつもなら即座にVersaloonに改造するのですが、2012年に入ってからOpenOCD
の0.6.0系のサポートにSTLink・STLink/V2が加わっています。しかもSWD対応です!
去年まではSWDでCorex-Mx系のマイコンに書き込みデバッグするまでがかなりしんどい
方法しかなく(一度コツつかんだら後はスクリプト組んじゃえば楽勝なんですが…)、
皆さん華麗にスルーされてきましたがメーカーやサードパーティの有償のツールを使う
ことなく使い慣れたOpenOCDを利用できるようになりました。



↑STM32L-Discovery(STM32L152RBT6)にOpenOCDを使って書き込みしてるところです。
 書き込み用のスクリプトはいつもの場所に最新の物をまとめてあります。現在動作確認
 してるのは今回のSTM32L-DiscoveryとSTM32F4-Discoveryです。
 STLinkやVersaloon(SWD接続)対応のOpenOCDビルド方法はこちらに。

↑デバッグも自由自在です♥OpenOCDはSTLinkのAPIを呼びだすことで通信を
 成立させているようです。MLを追っていくと対応に当たってOpenOCDのdevの人たち
 の苦心の様子がうかがわれます。

2013年現在はOpenOCDからSTLink/v2を動かすドライバとして、STマイクロ提供の
純正ドライバが利用できます
(といっても中身はWinUSBですが)。


●ほっぽらかしていたBeagleBoard達
去年争奪戦に勝利したにもかかわらず購入した時点で満足して箱に納めてしまってい
たねむいさんですが、aitendoさんの液晶キットを購入したことを皮切りに少しずつ
手をつけ始めています。


↑せっかく奮発してHDMIケーブル買ったのに一旦DVIコネクタ咬ませて変換しとかない
 とこの構成だとまともに写らんなんて考慮しとらんよ…orz
 副業先のPCのでかくて新しいモニタ使わせてもらいますか…無駄に2980円がががg
 ぁーでもS端子使うって手もありますね。


↑去年末にBeagleBoneなるさらに機能を絞ったBeagleBoardの仲間が誕生しました!
 今流行りのクラウド環境を意識したモノになっていてArduinoからの置き換えを狙った
 プロトタイピングに特化した作りとなっているようです。
 こちらの導入記は現在まとめていますのでまた次の機会に詳しく述べたいと思います。



●モノクロドットマトリクスSTN液晶
皆さんは去年さらっと紹介した2.5元I2C液晶を覚えているでしょうか?あの後詳細
が判明した途端に5元に跳ね上がりやがりましたが、ねむいさんは基本的な動作確認
を終えシンプルi2cライブラリに加えようと画策していました。

しかし、Nokia5110に代表されるドットマトリクス方式のモノクロ液晶は動かし方が
ほとんど同じことが分かったので、私がTFTでやってるのと同様に汎用のドットマトリ
クスモノクロSTN液晶向けのライブラリを現在作っています。aitendoさんで購入で
きる一部のOLEDも同じ動作方法の物があり、こちらに組み込んでます。

こちらもまとまり次第別記事で詳しくお伝えします。Nokia5110以外のマイナーな
モジュールに関する動作方法のテクニックも同時にお伝えしますね。


↑てわけで自作ライブラリで5元OLEDを駆動。
 …これ焼きつき激しすぎです!



●一個忘れてました
STM32系のOpenOCDのフラッシュ書き込みルーチンで現在テスト段階なのですが、
asynchronous algorithmと言うものに換えると書き込み速度がアップするそうです。

20120226追:
公式のコミットにも来たわよ



実際にこのパッチを取りこんで試してみました。
デバッガハードウエアはJtagkey2を使ってますが、ボトルネックがフラッシュ
書き込みにあるのでSWD接続のVersaloonでも変わりません。
*Normal
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00415-g338f5a1-dirty (2012-02-16-10:16)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
DEPRECATED! use 'adapter_nsrst_delay' not 'jtag_nsrst_delay'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
3750 kHz
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 3750 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08031280 msp: 0x10010000
auto erase enabled
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
wrote 524288 bytes from file main.elf in 19.750000s (25.924 KiB/s)
verified 454868 bytes in 4.062500s (109.343 KiB/s)
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
shutdown command invoked

*asynchronous algorithm
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00423-gd8b9127-dirty (2012-02-17-21:45)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
DEPRECATED! use 'adapter_nsrst_delay' not 'jtag_nsrst_delay'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
3750 kHz
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 3750 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08031440 msp: 0x10010000
auto erase enabled
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
wrote 524288 bytes from file main.elf in 12.968750s (39.480 KiB/s)
verified 454868 bytes in 4.015625s (110.620 KiB/s)
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
shutdown command invoked


…てわけで25.924 KiB/sから39.480 KiB/sへの大幅アップです!なにこれすごい。
現時点で書き込み速度がRTCK使っても10KiB/s代しか出ないLPC1769系のフラッシュ
にも対応してほしいですね♥

いろいろ試す9

電子工作系のブログ記事はこれが今年で最後なので旅先から無理やり更新してやり
ます。明日(12/30)のAM6:30には犬山遊園に降り立ってる身です・・・!


さて、クリスマスは虹裏向けのネタの仕込みで死にそうになってたねむいさんでしたが
aitendoさんからよさげなTFT液晶モジュールが2点追加されていましたのを目ざとく見
つけ購入だけはしていました。今週に入ってやっとこ作業時間ができたので即効バラッ
クをくみ上げて動作させて見ました。

まずは320x480の解像度でなおかつタッチパネルが付いているTRULY製のTFT液晶モジュ
ールTFT1P2797-Eです。以前も同じコントローラIC(ILI9481)で解像度が同じものが売って
いましたが、これはタッチパネル付きで、この解像度ではtaobaoでもなかなかお目に掛か
らない一品です。

↑早速動かしてみました。
電源電圧は3.3V単一でまったく問題ありません。よく液晶モジュールのデータシートでは
慣習的に2.85VをtypとしていますがコントローラICのVioとVccが3.3Vを許容していれば
なんら問題はないです。F4用の液晶はこれで決まりです!
・・・といいたいところですが、この液晶は以前のものとは違ってノーマリホワイトのよう
なので初期化手順が微妙に違います。ご注意を。


お次はお値段500円と非常にリーズナブルな液晶モジュールS95591-AAAです。こういう2.2"で
QVGAでタッチパネルつきはなかなかtaobaoでもお目にかかりません。aitendoさんやりますね!


↑こっちも早速動かしてみました。
こちらはLEDのバックライト電圧が9Vとなっています。3.3Vから昇圧して定電流回路
組んでやりましょう。私はPowTech社のPT4101というLEDドライバICをよく使用して
いてこのバラックでも秋月さんの変換基板と組み合わせて使用しています。


最後にSTM32VL DiscoveryのVersaloon化について、最近のファームウェアはSWDとして
使うためのピン配置があべこべだったのが元の正しい形?に戻っています。
私のぶろぐを参考にSTM32VL DiscoveryをVersaloon化されてる方は注意してください。

↑私も久しぶりファーム変えて気づかないではまった・・・
以前と同じこと言ってる気がしますが春日井から戻ったら手順書も更新します。

てわけで去年とまったく同じことしかやらないまま今年の電子工作納めてしまいました。


・・・
さて、尺があまってしまったのでよくメールなどで頻繁に頂く質問、いわゆるFAQを
この場を借りて答えたいとおもいます。

>メカトロ(含むロボット関連の競技)で使うモータドライバを組むことになりました
 がお勧めのFETを教えてください
 ・・・など、モータ制御に関する質問
→これなぜか非常に良く聞かれるのですが副業の仕事内容的にモータドライバに関する
 質問は「私ぜんっぜんわかりません><」としか答えられません・・・
 なんせ私は1聞かれたら100答える人間でなおかつぶろぐのこと副業先の方々が
 皆知ってて変なこと書かないように監視されてますから・・・
 ちなみに本業の虹メに関してはやりたい放題に見えて実ははるかに恐ろしいくらい
 厳しいガイドラインがあって政治・経済・野球・サッカー・アニメ・漫画・特撮・絵師さん個人
 の話題そしてジャガイモの入ったカレーなど個人の嗜好が大きく分かれる事がらの
 話はタブーなっています。
 とくに「」の前ではジャガイモの入ったカレーの話題は絵師さんに絵を描くことを強要
 する行為と同じくらいタブー中のタブーにあたります。
 私的にはいないさんのぱんつのつぎにじゃがいも入りの野菜カレー大好物なんですけぉ・・・

 すみません話反れました・・・

>(任意のマイコン)からARMに乗り換えましたがGPIOを切り替えるスピードが遅いのですが
→「最適化」「吐かれたアセンブラリストを良く見直して無駄な分岐・ロード・ストアが出
 ないようにGPIOアクセスする部分のコードを組みなおす」
 それとCPUコアが100MHz以上で動いててもGPIOがそのスピードについてけるとは限り
 ませんからよくマニュアル(ARM本家の仕様書も)やデータシート穴の開くほど読んでください。
 それをマスターしたら君もGPIO高速パタパタで大空に羽ばたくことができる!!
 そしてもうこんなところに戻ってくんなよー!!!1!

>中華の電気電子系の掲示板からよくネタをパクってますよね
はい
 私の描いたJTAGKey2Cloneの回路図とかあっちで貼られてることがあったりして
 面白い発見も

>なんでトレイルランのはずなのに徒歩とあんまり早さが変わらないの?
途中から疲れて歩いてるからです

>GT-723Fを使っています。ちゃんとつないだはずなのに衛星を補足しません><
表出ろ(別にけんかするわけではない)。部屋の中では補足はほぼ不可能ですよ。
 特に最近のマンションは金属線が埋め込まれた窓のガラスなのでそれがシールドに
 なって外部からの電波がシャットアウトされてしまいます。(Bluetoothの電波とかもダメ・・・)

>GT-723FからUARTのメッセージがまったく吐かれなくなってしまいました
→お気の毒ですが壊れました
 LVTTLなI/OラインにCMOSな+5V系の信号ぶちかますと簡単に死んでしまうようです。
 +5Vで動かしてるAVR等と組み合わせるときは注意です。あと落下のショックにも
 弱いです。静電気にもメタクソ弱いです。
 ねむいさんは安価ゆえにとっかえが効いて性能の非常に高いPA6Cをお勧めします!
 ユーロ安の今がチャンス!!!


>Cortex-M3でOpenOCDデバッグしようとすると"Remote 'g' packet reply is too long"
 というメッセージが出て(ry
→もうねむいさん何十回も言ってるのですが・・・#
 次にこれ聞いて来たら頭にJTAGKey2ぶっ挿して1ビットずつ焼きこんでいきますからね!

ねむいさんってマミゾウのパクリだよね
→そうだね

STM32 Value Line Discovery(STM32VLDISCOVERY)をいろいろ使う

CQ出版さんから"世界の定番"との触れ込みで大々的に宣伝されたSTM32ディスカバリ本
が発売されました。これはSTM32F100RBT6が使用されたSTM32ValueLineDiscovery基板
を扱い初心者向けに解説されたものであります。ちなみにSTM32なんちゃらディスカバリ
な基板はVL,L,F4と3種類あって"STM32ディスカバリ"と書かれてしまうとどれを指すのか
非常にややこしいのですがまぁそれは置いておいて…

以前からSTM32VLDiscovery基板については私も秋月さんからひっそりと販売されて
以来ちょこちょこと触れてきましたがこの基板に関する質問のメールをちらほらと頂くように
なったので改めて単独の記事として紹介したいと思います。
ちなみに便乗ではない!!


FatFsとTFT-LCD表示のデモプログラム
私のブログでいうところのいつもののことですが、STM32を扱う中でごく基本的な
要素を抑えてあります。私の他の物と同じくChaN氏のLPC2388向けのFatFsのプログ
ラムをベースにしていますが、移植しやすいように抽象度をかなり上げています。

フリーのコンパイラを使ったコマンドラインビルドに対応
・基板上のLED操作
・基板上のSW入力(外部4+1方向SWはオプションで)
・printf系標準関数がリターゲット可能なUART
(サイズ節約のためChaN氏のxprintfを割り振ってます)
・sprintf/malloc系標準関数のサポート
・systickとタイマを利用したAVR-Libcと同じ感覚で使えるDelay関数
・STM32間のポートの移植性を容易にしたFatFsのデバイス依存部
・容易に移植が可能なTFTLCD/OLED表示用ライブラリ
 SPI-LCDを使った時のブロック転送はDMA化可能。

ほかのマイコンからSTM32というかARMマイコンを始めた人が真っ先に引っかかるのは
sprintf/printf系標準関数がうまく動作しない点だとおもいます。今となってはFAQレ
ベルの事なのでここを熟読したり私のUARTへリターゲットしてる部分のコードを読んで
うまいこと動作させられるようにしてください。

上記のプログラムについては各ペリフェラルに対しポートの割り振りは以下のように
しています。特筆すべき点は、後述するSWD接続のVersaloonを使いデバッグすることに
限定してSWDでは使用しないJTAGポートの一部をSDカードアクセス用に割り振り、使用
可能なI/Oをさらに確保したところでしょうか。

※1:STM32VL-Discoveryデータシートより引用・加筆。
※2:単にポート振っただけでSW入力や8bitLCD等実際に使用してない個所があります。


定番のSPI接続のTFT-LCD(128x160)を動かしてみたところ。
ChaN氏のTJPegDecでjpeg画像を表示している最中です。

次回紹介予定の2.5元のi2c液晶モジュールも。素晴らしい掘り出し物です!



●STM32VL Discoveryに仕込まれてるSTLinkをVersaloon化
最早これも定番でしょう。STマイクロの**ディスカバリー系な基板にSTLinkとして仕込まれ
ているSTM32F103C8T6は各基板ごとに微妙にポートの配置が異なっていて同じVersaloon
のバイナリは使いまわしはできませんが、すでにVersaloon本家ではSTM32VLDiscovery
向けのファームウエアがサポートされています。

さて、肝心のVersaloon化の方法ですが本家ではDFU等のブートローダを仕込まずに直接
Versaloonのバイナリを書きこむようになっていますが、私はアップデートを容易にする
ためにいつも通りのDFUを仕込むようにしました。以下に私が行った手順を示します。
DFU仕込まない場合は"1."の書き込み時にいきなり本家の方のSTM32VLDiscovery用の
バイナリを書きこんでください(この場合別途ビルドする必要あり)。

1.DFUを仕込む
 こちらにSTM32VLDiscovery用DFUブートローダのバイナリを用意しました。
 (Versaloon_DFU_Bootloader_for_STM32VLDiscovery_.zip) 最初に書いてください。
 書きこむ方法はSTLink等のフラッシュを書きこむ手段が別に用意されてる場合はそちら
 を使ってください。Jim氏のTakenApartの記事にSTLinkをつかった手順が示されていま
 すのでそちらの記事をもとにDFUブートローダを書きこんでください。

 また、STM32はこの基板が初めてでフラッシュを書きこむ手段を他に持ってない人は,
 UARTブートローダーを使う方法を、こちらの改造手順2〜8を参照して書きこんでください。
 UARTブートローダを有効にするためのジャンパの引きまわしはSTM32VLDiscovery基板
 上では以下の写真の通りとなります。
 
 この基板上では足あげ等の加工も水晶の付け替えも必要なく0.5mmピッチの足からリ
 ードを引き出すだけなのでまぁ楽勝ですね。DFUを書き込んだ後はもちろんジャンパを
 はずすのを忘れないでください!

2.DFUを起動
 さて、DFUを書きこんだらPCに接続するわけですがSTM32VLDiscovery基板上では下
 画像のリセットボタンがDFUの起動キーとなります。リセットボタンを押しながらUSBケー
 ブルでPCと接続してください。
 
 USBデバイスとしてDFUが認識されたら成功です。
 
 そうだね画像使いまわしだね。言い忘れてましたがDFUseをインストールした時に
 DFUドライバがインストールされますので忘れずにインストールしておいてください。

3.Versaloonを書き込み/起動
 STM32VLDsicovery用のVersaloonのDFUファイルはこちらに。書き込み方はここの"14."を参
 照にしてください。向こうにあるDFUファイルは別物だから使っちゃだめです!
 書き終わったら基板を一度PCと切り離し、再度接続します。この時にVesaloonとして
 認識されたら成功です。VersaloonはLibUSBが使用されていますが、LibUSBのド
 ライバはZadigでインストールした方が確実です。
20120105追:
 以前はSWDのジャンパはあべこべになっていましたが、現在では
 差し替え無しでそのまま使用できます。



4.Versaloon化したSTM32VLDiscovery基板上でターゲットのSTM32F100RBT6をデバッグ
 冒頭で述べたプログラムをビルド・書きこみを行うわけですが、用意するものは
 STM32マイコンをビルドする環境のほかにVersaloonに対応した特別なOpenOCDが必要
 です。おもな手順はこちらこちらですでに紹介しています。

てわけで丸投げしまくりのやっけつ手順になってしまいましたが簡単に改造可能なの
で(自己責任の上で)お勧めします。しかも今のVersaloonはUSB-CDCが同時に使用でき
る複合デバイス構成になっているため、これを利用してこの基板上でUARTの通信手段を
完結させることができます♥

STM32F4はぢめました


…きちゃった♥


…STM32F2すら使いこなせてないうちにCortex-M4コアのSTM32F4が来てしまいました。
CPUクロックが168MHzにアップした上にFPU&DSPユニットが付きさらにメモリも192kByte
までお付けしてお値段据え置き(購入当時日本円換算で1280円)ですって奥さん!!



チップ単体はまだ手に入らないので(これも時間の問題ですね)すが、評価キットとして
STからSTM32F4Discoveryがすでに販売されています。この評価キットはI2Sコーデックに
MEMSセンサもついていてアナログ信号の処理も手軽に扱えそうです。ていうかそういう
風に使わざるを得ないでしょうね…苦手ですが。

20111201追:
秋月さんからも1650円で販売されました!



てわけでさっそく動かしてみました。すでにSTM32F4Discoveryのファームウエアパッケ
ージで予習済みなのでいつものTFT液晶に何か表示するプログラムをビルドし書き込ん
でみます。


CodesourceryはすでにCortex-M4Fに対応しています。ビルドオプションとしては
少しの変更でビルド可能です。
(注:上記のオプションではまだ不完全で、FPUを使った演算になりません!
  FPUを有効にする方法はこちらを)



STM32F2系(Cortex-M3)とアッパーコンパチであるため、OpenOCDはそのまま読み書き
とデバッグ(FPUレジスタ除く)を行うことが可能です!ねむいさんはビルドしたプロ
グラムの書き込みにVersaloonのSWDを使用しました。
(注:エラッタのせいでSTM32F2系とまったく同様のMCUIDとなっているようです。
   VersaloonはコアIDのほうは判別は行っていないようなので引っかかりませんでしたが
   FT2232系のJTAGアクセスではコアIDの判別に引っかかり、STM32F2系のcfgファ
   イルのまんまだと警告を出しますが、先に述べたとおりアッパーコンパチのため、
   とくに実害はありません。私が公開しているOpenOCD用のCFGファイル群はすでに
   STM32F4対応済です。)



びぃぶろくんが、かわかわ美人さんに欲情すると困るので小さく
20120124追:
Gaijinさんがinai-sanはHENTAIだって


とりあえず今回はほんのさわりだけですが、次回はせっかく192kByteに増強してもアド
レスが連続してるのは128kByte分でそのうちの16kByteはEthernet&USBOTG-HSの
DMA専用に事実上取られてしまうので実質112kByteで残りの64kByteはバスマトリクス
上にないから微妙に使いどころがないという内蔵RAMの効率的な使い方とかをリンカ
スクリプトの組み方と交えて実践していこうと思います!

STM32 EvoPrimerを買った...

世間ではSTM32F4シリーズが発表、音系に特化したSTM32F4Discoveryなんかも
もうすぐ手に入るようになった昨今ですが、8月末に秋月で纏め買いしてるついでに購入
してしまいました・・・。こんなの買ってしまった時点で「私は情(に)弱(い)です」って言って
る様なもんですね・・・orz
・・・まぁいいや。

un
↑STM32Primer1,2の後継となるEvoPrimerです。

un
↑今回のはCPUカードを差し替えることによりSTM32F103系、STM32F107系、STM8S系の
 評価を行うことが出来ます。逆に言うとEvoPrimer本体だけ買っても何も出来ません!

un
↑ねむいさんはSTM32F103VET6が載ったPrimer2を持ってるのでSTM32F107系
 CPUカードを選択しました。

un
↑カードを挿して(めっちゃ硬い)真ん中のボタンを押すと"Welcome to STM32!"のボイス
 とともに初期設定画面がでます。ちなみに初回購入時はEvoPrimer本体からCPUカー
 ドからスタンバイ電源を供給するためのスイッチをONにしておかないと起動の度に
 初期設定をする羽目になるので注意です。

un
un
un
↑早速中身を開いてみました。
 QVGAの液晶やI2S等のデバイス盛りだくさんです。ちなみにこのQVGA液晶はピンの設
 定で8bit,16bit,SPI(←これ重要)が使用可能な逸品です!

 液晶モジュールのデータシートを穴のあくほどよく見ましたがこのモジュールは
 SPIの設定はできるもののSDI/SDOのピンが出ておらず実質8/16bitしか使用
 できません。しかもEvoprimerとしては8bitバスしかサポートしてません。
 さらに言うとCタイプだと素直なピン配置になっておらず、わざわざビットシフト
 してから書かなければならない回路構成になってやがるので描画がSPI並みに
 くそ遅いですorzorz

20130107衝撃の事実判明!!!
ちゃんと調査したところコントローラICはちゃんとILI9325でしたが、なんとFPC
内部でSDOがD0に、SDIがD1に直結されていてSPIでもデータの読み書きが
可能なことを確認しました!!!!


un
↑STM32Primer2で致命的となってしまった電源回路ですが、回路図を見渡す限りでは
 対策がされている様なので今回は大丈夫だと思いますよ。た ぶ ん
un
↑STM32Primer2と並んで動かしたところ。一回りおっきくなってて持ち運びができません…。


その他EvoPrimerと同じく買ってしまったもののまったく触っていない物達・・・
un
↑LPC1227LPCXPresso(上)とLPC11U14LPCXPresso(下)ですって奥さん!

 11U14の方って反対側にUSBminiBコネクタついてるわりには3.3Vのレギュレータ無い
 からうかつに切り離せられないじゃないですかーやだー!
 あとXmegaでよく分かられたとは思いますがねむいさんはLPC系のARMマイコンで
 DMAを使いこなす知能がないのでLPC1227の方はあつ氏やtodotani氏の作例を
 参考に弄ってみようと思います。

 ちなみに上記二つのデバイスはSWD接続しかなく、まだVersaloonが対応してないので
 手も足も出ません!・・・といいたいところですが・・・(下記に続く)


un
↑お次は台湾NuVoton製のcortex-M0マイコン、NUC120さんだ!
 基本的なドキュメントやサンプルコードは出揃ってるのでこちらも時間を見て・・・
 もちろんまったく触ってま(ry

 ちなみに書き込みはNulinkと呼ばれるSWD接続可能なライタです。KeilやIAR等の開発
 環境からしか使えないと思いきやCooCoxCoFlashというフラッシュ書き込み専用ツ
 ールを使うとスタンドアロンで書き込みできたりします♥

un
↑このCoFlashというツールですがハードウエアが上記のNulinkに加え、JTAGkey,JTAGkey2
 やST-Link等の有名どころにも対応してるので書き込み専用としてもかなり使える
 と思います!


un
これも脊髄反射で購入してしまった・・・
 ほんっとマイコンしか触ってない私ですがFPGA忘れてしまわないうちに何とかした
 いですはい・・・



GPSを試用する4

前回は秋月電子通商さんで販売されていて入手しやすく高性能なGT-723Fを使用した
GPSロガーの製作例と使用例をお伝えしましたが、今回はさらに性能の高いGPSモジュ
ールUP-501を入手しましたので紹介したいと思います。


UP-501とGT-723F(ついでにGM-316も)の性能比較は以下の通り。
un
UP-501の電圧上限が4.2Vとなっていますがこれはリポ電池を使用したものを想定して
設計されているようですね。現在の電子工作の電源電圧も3.3V物が多くなっているご
時世なので特に気にしなくてもよいでしょう。多分。

実際に使用してみましたが、GT-723Fと比較すると捕捉時/追跡時の消費電流が30mA
以下に抑えられ、なおかつ高感度になっていて悪天候時のコールドスタートでは捕捉ま
での時間がかなり早くなっています。登山やトレランの時は電源投入後の初回捕捉時
間が結構重要で、ここで捕捉時間が長いと貴重な時間を失って結果目的地に着いた後
帰りのバスや電車に乗り遅れるというかなりおまぬけなリスクが上がってしまいます!
(↑ねむいさんはタッチの差でよく乗り遅れるんですよぅorz)。

さらにUP-501にはVBAT端子があり、SRAM上のアルマナック&エフェメリスデータを保
存できるのでAGPSと組み合わせると再補足の時間をさらに早くすることができます。
登山の前日にAGPSのデータをダウンロードしてなおかつ一旦捕捉動作しておけば現地
で捕捉待ちでいらいらすることなくすぐ出発することができると思います。
頻繁に電源を入り切りするような使い方や、悪天候下のときほど効果を発揮するでしょう。

GM-316にも同様にVBAT端子が存在しますがモジュールの小ささ(=パッチアンテナの
小ささ)ゆえに外部アンテナつけないと真価を発揮できないようです。
またAGPSもないのでパッチアンテナのみだと快晴時/開けた場所でも初回捕捉時間が
かなり長くかかります。ゆうに20分以上掛かります。UP-501が手に入る今となっては
こちらのモジュールは外部アンテナをつけて据え置き型のGPS時計の中核部とするの
が良ですね。(捨てるのもったいないし!)



ちょうど台風が来て大雨が降っていたので私の塒のベランダから悪天候時の捕捉時間
の比較をいくつかの条件で行ってみました。
●GT-723Fの場合
コールドスタート(AGPS無) 約14min
コールドスタート(AGPS有) 約3min

●UP-501の場合
コールドスタート(AGPS無) 約10min
コールドスタート(AGPS有) 約3min
ウォームスタート(SRAMバックアップ有,AGPS有,
         捕捉確認後電源を落とし3時間置いたあと電源投入) 約25Sec
ホットスタート(SRAMバックアップ有,AGPS有,
         捕捉確認後電源を落とし即再投入) 約7Sec

GT-723FのAGPS無のコールドスタートの時間は西青山〜柘植にトレイルランしに行った
時にGPSロガーを使用した時の初回捕捉時間とほぼ同じ(スタート地点の西青山駅はかなり
強い雨)でした。また当時同時に使用していたSRAMバックアップが存在するスポーツガイドメイト
の場合、ウォームスタートだったため40Sec程で捕捉できてました。
ちなみに快晴時ではGT-723FとUP-501のいずれもAGPS無のコールドスタートでも
40Sec前後で捕捉します。


un
↑せっかくなのでAGPS用のデータのダウンロードは某BluetoothのUARTモジュール経由
 でワイヤレスでできるようにしてみました。遠隔のデバッグにも結構使えますねこれ。
 XBeeと違って115200でも文字落ちほとんど出ませんし。


あと気になる入手経路ですが、今年7月ごろに一般にも流通しだしたUP-501は現在では
Sparkfunから59.95USD、国内ではswitch scienceさんより5995円で購入できます。
GT-723Fと比べると少々値段が高いのですが、実はMARY基板の企画でマルツさんより販
売されているGB基板
にはこのモジュールが使用されており、しかも約1000円安い4980円で
購入できます!基板をそのまま使うのもよいのですが、用途がしっかりしてるのなら
私のようにモジュールだけを外して利用させてもらうのもよいと思います。えっとなふう
に…モジュールの写真撮ったのが伊勢乃宮雪子ちゃんの誕生日(8/27)だったのでついでに…GPSと基板さんが大事な部分をしっかりガードしてるので職場や学校で見てる人も安心だ!♥
ちなみに二次裏には全部見えてるVerを




…ゲフン失礼…おまけですがスポーツガイドメイトも分解したので写真お見せします。

un
↑表蓋を外したところ。パッチアンテナとモノグラフィックLCD基板が見えます。

un
↑パッチアンテナは基板に直結です。

un
un
↑裏蓋とリポ電池をはずしたところ。左からRF用IC、GPSの心臓部のVenus6、そして
 ProlificのPL2303HX(RevD)が見えます。PL2303HXのシリアルナンバを固定化したい
 ところですがRev.Dのチップは書き込みに6.5Vの高電圧と特別なライタソフトが必
 要なのでこの基板上では不可能です。残念。



というわけで自作のGPSロガーに使用するモジュールはGT-723FからUP-501に切り替え
て動作検証を続けたいと思います。11月から予定の東海自然歩道本線ルートの再開
時には活躍してくれるでしょう。

GPSを試用する2

20140328追:
最強のGNSSモジュールGms-g9をゲットせよ!


前回作成したSTM32Primer2を使ったGPSロガーはさまざまな厳しいフィールドで活躍し、
輝かしい実績を残してきた・・・といいたいところですが、実際は使ってるうちに不都合
がいくつも見つかりそれをひとつずつ少しずつ潰していきながらやっと長時間安定して
ロギングを行えるところまで持っていくことが出来るようになりました。

一番の強敵は衛星を捕捉していてもロギングがランダムで停止してしまう現象に遭遇
したことで、どの部分で問題を起こしているかという切り分けにかなり時間を要しま
した。東海自然歩道のルートで言うと湯ノ山温泉->西藤原のルートから始まって笠置
->奈良くらいまでは特別なファームをあれこれ試したりノイズ抑制のためにコンデンサ
追加したり導電性エアキャップにやさしくくるんだりあれこれ試してようやく不具合を
特定しました。(結局FatFsの書き込み時のエラー処理が不適切なだけだった・・・)




ついでに使っているGPSモジュールもGM316+外部アンテナから秋月さんちから2月にライ
ンナップに加わったCanMore製のGT-723Fに変更し、なかなかの結果を収めています。
un
↑比較表作ってみました。
GT-723Fは衛星を見つける最初期のacquisition(同期捕捉)の段階では80mA以上喰って
しまってしますがtracking(同期追跡)状態に入ると32~36mA前後まで落ち着き、結果的
に野外で使うなら電池の持ち的にもGM316+外部アンテナで使うよりも有利なのが分か
りました。主人の持ってたGT-720Fは常時180mA位馬鹿食いしてたのをかんがみると技術
って進歩してるんだなぁ・・・とおもうことひとしきりです。
un
↑現在の運用形態。STM32 Primer2からVCC,RxD(STM32 Prime2側),GNDを引き出し、
 なおかつGT-723Fは別に基板を設けてそこに固定し、機械的にも接続を強化しています。
 また、このモジュールは+3.0Vからの電源入力に対応していますので、STM32Primer2だと
 LCDのバックライト電源からパワー(3.1Vavg)を拝借する形になります。
un
↑尤もSTM32Primer2いじり倒してる人はとある理由で当然電源周りも改造していて原形と
 どめてない人も多いでしょうからもう好きにすればいいと思いますよ(←投げやり気味)。
un
↑JR笠置駅にて。
 ねむいさんチキンなので実際に使う時はGPSモジュールを導電性エアキャップにくる
 み、さらにここからSTM32Primer2全体をGPSモジュールごとくるんで物理衝撃対策し
 てます。この状態でもザックにぶち込んだ状態で氷点下の環境はもちろん猛暑の中
 でも安定して動作したので満足です♥
 タフすぎて そんはない


肝心の捕捉精度なんですけどGT-723Fはパッチアンテナのみですが深い森の中でもしっ
かり衛星を握ってくれていて、逆にトンネルやトイレ等の電波が完全に遮断される場
所では案外簡単にぱっと手放してくれるようです。GM-316の場合は電波が途切れても
捕捉状態から離れずでたらめな場所を記録してしまうことがよくあったので山中の行
動の記録に使う用途としてはGT-723Fのほうが良いかとおもいます。
それとGT-723F買ったときに結局ついでに買ってしまったのですが市販品のスポーツガイ
ドメイト
と比較した場合もほとんど引けをとらない結果になってます。
un
↑結局買ってしまった・・・Garminは高いから論外で(欲しいけど)
un
↑スポーツガイドメイトは電源ボタン長押しでOFFではなくワンプッシュでOFFとなっ
 てしまう設計のため、ザックに無造作に放り込んで山野を走るような荒っぽい使い方
 は出来ないのが難点です(自転車に固定して使うことを想定されているようです)。
 PCとの接続は内蔵のUSB-シリアル変換でUSB経由でデータの読み書きをします。
un
↑これはJR奈良駅から近鉄長谷寺までのルートを同時に記録したものです。
 ほとんどぴったり重なっちゃってるんですけど赤のラインがスポーツガイドメイト
 で青が自作のGPSロガーです。

本末転倒になってしまっていますが、ロギング中に一方が何らかの理由で停止しても
困らないように現在は両方持って山に行ってます。
本当に本末転倒ですがもういいです(投げやり気味に)。



おまけ
私のぶろぐの中でpvが圧倒的に少ない、つまり人気が無いのが東海自然歩道関連の記
事なのですが、一部の方々にブラウザのベンチマークとして使われているのを知って
まぁ少しは役にたっているかなと思ふことひとしきりですが、それはおいといて山に興味が
ない方はドリフの雷様的な物とおもってあきらめてください。

東海自然歩道の山の辺ルートは本道ではないのでぶろぐには書かないつもりでしたが、
今回は特別にダイジェストを。

石山->宇治
un
このルートは99%舗装路でした。
un
ゴール地点の平等院鳳凰堂。
un
宇治茶のアイス(宇治茶+桜だそうな)

宇治->原山
un
やっぱり舗装路。
un
見所(というかこれしかないけど)の鷲峰山。
un
加茂駅の昔からある倉庫。
(※体力あまってたので原山から加茂駅まで走って帰りました)


原山->笠置
un
童仙房山荘。
un
ないおん!
un
高山ダム。ここから先が長い。
un
関西本線が間近に!
un
ゴール地点のJR笠置駅にある良く分からない像。


笠置->奈良
un
柳生家老屋敷。
un
一刀石。
un
日照が体力を削る季節になってきました・・・。
un
峠の茶屋。
un
鹿。


奈良->長谷寺
un
鹿。
un
一番やさしいルートですが夏場だけは
逆に一番過酷なルートに!!!
un
石上神宮。
un
大神神社領からの展望。
un
狭井神社のハイテク御神水供給装置。
un
長谷寺山門
un
長谷寺駅からの夕暮れ。


これから夏本番です。夏場の激しい運動は熱中症や脱水症状という直ちに死ぬ危険
性の高いリスクが常に付きまといます。ねむいさん絶対に日焼けしたくないので長袖とUV
カットのゴーグみたいな眼鏡で完全ガードしてるおかげで上記のリスクがさらに高ま
るので一応そっち対策もばっちりしてる(つもり)です。
欲張らずに走る距離は30km以内に抑え、朝早く出発して遅くとも15時までには走り
終えて帰るというのを心がけるようにしてます。
あとせっかく体重落ちたのに風呂上りにうっかりビール飲まないようにsh…
ビールには勝てなかったよ…プハー♥

いろいろ試す7

この度の大地震で被災された皆さまには心よりお見舞い申し上げるとともに一日も
早い復興を願っております。私も復興支援を私なりにできるかたちで行っていきます!



…てわけで電子工作野郎になる時間がなかなか取れなくなってしまったので今回はも
ともとタイトル通りいろいろやるつもりだった内容を大幅縮小変更してお送りいたします。


●AVRマイコンを使ったバックアップ機能つきRTC時計
un

前回軽く紹介していましたが実用レベルになれたので改めて紹介します。目玉はRTCの
バックアップをATMEGA644pのパワーセーブモードで行い、外付けのRTCのモジュールを
排したコストダウン仕様となっています。表示部は部品箱の肥やしになっていたNoritakeの
キャラクタVFDを使い視覚性も良好でLM60を使用した温度センサで気温も同時表示出来
るようにしました。
気になるパワーセーブモード時の消費電流ですが、ADVANTESTのnAオーダーで測定でき
るデジタルマルチメーターで測定したところMAX3uA,平均1uAでした。CR2032(約220mAh)
なボタン電池でも単純計算で3000日以上余裕でバックアップ可能なわけです♥
主人がATMEGA328で作ってたやつはバックアップ時にAVCCを断つというセコ技を駆使して
も80uA程喰っていたのでそれを鑑みると非常に満足のいく結果と感じています。

消費電力削減の為にはファームで省電力レジスタ群をいじったり割り込み時のステート
を考慮するのはもちろんのことですが、VCCまわりの回路構成も非常に重要です。AVRは
STM32等の今日びのARMマイコンのように独立したパワードメインは無いので、逆方向
漏れ電流の非常に小さいショットキバリアダイオードでしっかりと分けてやらないとせっ
かくファームで省電力化できても外部回路からダダ漏れとなってしまいます。こういうの
意識しながら作ることを経験しとくと他でも応用が効くと思います。

時計合わせはUARTのコマンドからのみという手抜…シンプルな仕様!mega328バージョ
ンでは回路に取り込んでいたAVR309を外に出して手抜…回路の簡素化を図りました!


●STM32マイコンを使ったUSB-CDCが…
※知ってる人もいるかもですがかなり以前の話です
iruka氏のSTM32を使ったUSB-CDCの考察の最後に出てくる魔の時間帯について。
ループバックして、氏のw32termのテストモードを走らせるとこの時間に高確率で引っか
かってフン詰まり状態になってしまいます。単純にダブルバッファリング化しても同じ結果
だったのでUARTのデータを受ける部分の処理がまずいのでしょう。てわけで魔の時
間帯でもデータを受け付けるように…
…しただけでフン詰まり現象は無くなりました!
un
UARTの通信込みでこんだけ叩きだせるなら恩の字じゃないかしら!?
でもやっぱし専用ICには到底かなわないので、遊び以外で使わない方がいいですよ(重文)
上記の成果はおきばにあります。
20110406追:
STM32のUSBライブラリがV3.3.0に上がりVCPのデモもこの問題が修正されたと見せか
けて修正されていないようです。ご注意を!

●STM32 ValueLine-Discovery
を秋月さんから購入しました。ねむいさんみたいに買ってすぐにバラすような人対策か、
ST-Linkの部分が切り離すことができません。しかしこのST-Link部もVersaloon化できる
ようになっているのでさっそくVersaloon化してみました。これについては後ほど別記事で
詳しく取り上げたいと思います。

un
↑お約束のTFT液晶モジュール。8bitバス繋げるのめどいのでSPI接続方式の液晶で…。
この評価ボードのセットはSTM32が二つも付いているので(部品取り基板として)とても
利用価値があると思います。機能限定で単品物作るなら新品でパーツ揃えるより安上
がりで最適でしょう。


●トラ技別冊LPC1114ボード
圓山宗智氏作のMARYと呼ばれるLPC1114と周辺のボード群にちょっと興味が魅かれた
ので購入してみました。最初はLPC1114基板とCP2104基板で2枚組かと思ったのですが、
本当に同じ基板が2枚(LPC1114+CP2104の基板が2つ)なのですね…
un
LPCXpressoと大きく違う部分はLPC1114のメイン発振器が内部オシレータ(LPCXpresso
は外部に12MHzの水晶がある)の使用を想定しているのでスタートアップ時のオシレータ
選択レジスタを内部オシレータにしとかないと動かないといったところくらいでしょうか。

CQ誌のサイトからダウンロードしてきたMARYのサンプルを参考に過去に作ったとっかか
り用のLPCXpressoのプログラム
と共用できるようにしてみました。
MARY上で動かす時はmakefile内のボードの定義をMARYに変えるだけでおkです。
un

つづく

LPC1769を使う4

※トレランの記事を書く予定でしたがLPCXpressoLPC1769版が手に入ったため次回!

先日から騒がれはじめていますが、LPCXpressoのLPC1768版にLPC1769が乗っている
ものがある。という話。実際に市場に出回っているのはすでにLPC1769のものに置き換わり初
めているようです。ねむいさんもLPC1769版をゲッツしました!!

un
↑ご覧のように"TARGET LPC1769"と明記されているので安心です♥


un
↑LPC1768版で問題だったRTC用のクロックがピンコ立ちになってた件は今回のLPC1769版
 ではちゃんとSMDの製品にかわりスマートな形状に戻りました。
 1768版買わずにずっと我慢してた甲斐があったぜ…

さて、LPC1768とLPC1769の違いですが、単にクロック動作上限が100MHz->120MHzに変わ
っただけです。チップリビジョンも"-"の無印なのでエラッタもごっそり引き継いでいます
細かい部分は各自エラッタシートをご参照ください。
以前に別基板で120MHzにて動作実験を行い、aitendoさんのOLEDを動かすパフォーマンス
とかもやってますが、今回もLPCXPresso1769版でおさらいをしてみました。


un
↑お約束で真っ二つに切断。
 LPCLinkとかLPCXpressoIDEとかはもちろん一切使いません。
 いつもの通りCodeSourceryG++とmakeとVersaloonとinsightを使えば十二分に戦えます!

ところでLPC1114/LPC1343版ではフリースペースになっていた部位はLPC1769版ではI/Oピン
が出ています。このピン群の扱いは当面何も付けないでおいてあとあとどうするか考えます…。
とりあえず秋月のロープロのコネクタを両サイドに取り付けました。

un
↑二つに割ってしまったせいで+3.3Vの供給のことすっかり頭から飛んでましたorz
 仕方ないのでVersaloonの3.3Vから拝借。他者の製品同士が合体してシュールですね…。

un
↑Versaloon+VSGUIでSWDが繋がるのとOpenOCD立ち上げてLED点滅プログラムがSWDデバ
 ッグ出来るのを先ず確認。

un
↑次にいつもの如く液晶表示とかやってみるのですが、今回はSPI接続専用で128x160pixel
 なTFT-LCDを使ってみました!
コントローラICは皆さんもおなじみのST7735です。

un
↑表示周りは完全にモジュール化させてるのでデバイス依存部以外はほぼコピペです。
 120MHzまできっちりまわせよ(某豆腐屋みたいな顔で)


…そういえば5か月くらい前に中華LPC1769基板をいぢっていたような…気のせいか…
前回と全く同じことをしているような気がするわけでもないかもしれなくもない…

LPC1769にはまだFatFs積んで動作確認させた実績ないので早急にベースを固めなけれ
ばなりませんね。

いろいろ試す6

あけましておめでとうございました!

去年に"来年から本気だす"といったものの自分の誕生日の絵作ったりたぬたぬの置物
をはるばる信楽まで(次回詳しく解説)買いに行ったりしてブログの更新もままならな
いほど大忙しであっという間に1月中盤です。

更新はしてませんでしたがいろいろ手は動かしています。今は思うところあってAVRマ
イコンを使ったベタな時計を作っています。
un
と言っても私が一から作ったわけではなく、↑写真左のように以前に作られたATmega328
で作成された物をATmega644pへと移植するような感じです。5年前に残された資料をもと
主人の遺品をふんだんに使ってにあれやこれやしたり主人が作り込んだヘボい処理を
修正したりしてますがコンセプトとしてはO-family氏のATmega88pを使用したものとほぼ同じ
物になりそうです(最初「すん氏の〜」と誤って表記してまいました。双方にお詫びします)。
しっかしVFDは見やすくて良いものだ〜

また、去年汎用のTFT液晶モジュール表示プログラムのARM版を更新しましたが、XMEGA版
もやっとこ最新に更新しました。こちらです。ビルドは最新のAVR Toolchainを使用してください。WinAVR20100110とはSRAM・ProgramMemoryににおいて64kb以上の領域にアクセス
するためのマクロが公式に取り込まれた絡みで互換性は全くありません!
この件については次次回の記事にてみっちり解説します。



んでもって上のやつを早急に終わらせたら次はまたARMに戻っておべんきょ継続です!
un
↑川内康雄氏の著書をねむいさんも購入しました。仕事でやってる人も続々参入してレ
ヴェルが跳ね上がった今の電子工作シーンに対応するため、私も一から基礎をみっちり
やりなおすことにしました!それ言ったの何度目だよそれっていう突っ込みはスルーで!

試用するSTM32についてももうすぐ出るらしいが全く音沙汰がないF2系の大規模なMCUを
意識してSTM32F103ZET6と超高速SRAMが乗っかるボードをtaobao経由でチップと基板を
別々に買って必要なパーツだけ実装して使っています(日本で同じものをフルセット買うより
かなり安くなるため)。
un
↑STM32F103ZET+高速SRAM物で一番小規模な奴。
 セコく基板だけ買ったせいで回路図もらえなかったので解析からする羽目にorz
un
↑中華評価ボードでは比較的有名なPowerAVR製の基板たち。
 上がSTM32F103ZETのもので下がよく使ってるSTM32F107VCT6のもの。

STM32F107VCT6版は単に以前のものを移植だけで済みました。これはのすでに公開してる
プログラム
中で統合済みです。しかしながらSTM32F103ZETのは、はぢめて触るのでベースとなる環境から整えないといけませんね。先ずは基本的なFatFsと液晶表示の実装なわけですが
今回は外付けSRAMも絡むのでそちらも併せて取り入れていくことになるでしょうね〜。これができたら次はI2S!んでさらにそれをSTM32F107VCTにフィードバック!
(↑すぐなかったことにする人間なので一応宣言しときます…)


そしてARMに関してはもう一品、LPC1343を使ったライントレースロボットの学習教材
ビュートローバーも秋月さんから販売されていたので買ってみました。
un
↑コンパクトなパッケージ。
un
↑中身こんな感じです。

un
↑組んでみました。

un
↑…

電池買って無いや。続きはまた今度!

LPC1343はぢめました(+Versaloonを使ってSWD接続でOpenOCDデバッグ)

8/16日にARMマイコン パーフェクト学習基板なるものが販売されました。基板に搭載されて
いるマイコンはLPCXPresso(LPC1343版)とおなじLPC1343です。
奇しくもLPC1114・LPC1769の開発環境のとっ掛りが出来たので死蔵していたLPC1343も
はぢめて見よう か な とおもって手を出してみました。決して便乗ではありませんよぅ!


肝心かなめのスタートアップはLPC13xx系がCortex-M3なのを利用してSTM32で使用した
ものとほぼ同一のものとしました。NxP系ARMマイコン特有のCRP&CheckSumValidation
ももちろんスタートアップに盛り込みます。
また、LPC1343にはUSBインターフェースがあるのでXPresso基板にUSBminiBコネクタ
から+5Vを引けるようにし、とある1.5A/3.3Vレギュレータでシステム全体に3.3Vを給電する
ようにしました。SMDだしセラコン使えるし秋月で買うとかなり安値で買えるし性能高いし
で良いLDOだと思います。

un
え?秋月のはセラコン対応じゃないのになんでデータシート無視して使ってるのですって!?
…さぁ?…誰かがなにかを間違えてるんじゃないかなぁ…?ほら型番とか…
un
↑ねむいさんは画像掲示板の住人なので画像で語る


それはさておき基板単体で給電できるようになったので、次はフラッシュの書き込み&デバッグ
に挑戦です。使用するのはSWD接続なVersaloonです。LPC-Link?何スかそれ?

LPC1114ではまだeraseしかできずあまり期待してませんでしたが、LPC17xx系と同じように
OpenOCDからSWD接続でフラッシュ書き込みを行うことができました…これは…ありがたい…!
あとはLPC11xx系のフラッシュ書き込みに対応してくれたら…!


20120229追:
JTAGが無いって言われた時にぃ、じゃぁLPC1114でもSWD接続のOpenOCDつかって
フラッシュ書き込み&デバッグできるじゃない!って確かそういった気もするんですよね


un
先ずはいつものLED点滅からです。邪魔なうんちゃらLinkはもちろんぶった切ってます。

un
SWD接続なVersaloonでOpenOCD+Insightによるデバッグ中の画面です。ペリフェラルは
LPC1114の時と同じくaudin氏のOpenOCD用IOViewをLPC1343向けに移植しました。
もうLPCXPressoIDEなぞ要りません。

というわけでLPC13xx系の開発環境の足場作りも整いました。これをとっかかりにして
色々広げていきたいと思います。




ところで、LPC11xx,LPC13xxはフラッシュ容量が32kBしかないので外部に何か容量の超
でかいROMをぶら下げる必要があります。いま私が記録媒体としてターゲットにしているのは、
少し前になひたふ氏も触れられていたSSTの大容量SPI-ROM(手持ちはSST25VF016B)です。
これは現在一般PC用のBIOSROMとして超大量に流通し、使用されているのでmouserや
digikeyでも安価に購入できるようになっています。

こいつに自在にデータを書き込めるようになったらPCのBIOSアップデートに失敗しても
もうなにも怖くはありません!!(←実はこれが主目的)
兎にも角にもSPI-ROMを使いこなすのだッ!

un
↑接写できるコンデジに買い替えたのでむやみに接写
 …駄目だ上手く撮れない


追:おきを改修しました。
  それに伴いSTM32F107VCT6,LPC2388用のTFT表示プログラムも最新に更新しています。

またTFT液晶モジュールかよ

20101228追:
MCUバス接続タイプのTFTLCDモジュールを動かしたい奴は必ず読め!!11!




え?この前買った3.2"の中華製TFT液晶どうしたって?…どうしたもこうしたも…
物理的につぶしt"ワタシ大陸に帰るアル"って言って去っていきましたよぅ…
……さよなら5980円!!!!




…さて、つぶしt去っていった液晶さんの代わりにaitendoさんから2.8"のTFT液晶モジュ
ールEGO028Q02
を購入しました…。コントローラICは前回使用した2.4"TFT液晶モジュール
YHY024006A
と同じILI9325です。

コントローラICが同じだから前回のと同じソースコードが使えるかなと思って繋いで
試して見るとお案の定同じでふつーに表示できました!今までで一番楽だったです。
公開しているおソースは試用にあたって気づいたバグや記述ミスも順次つぶして
更新を続けていますが、試される方は自己責任でどうぞ。


↑まずはいつもの癒し系小動物を。

そしていつもはいないさんのえろす絵でお約束するのですが2/9に彼女が20歳の誕生日
を迎えたこともあって今回は真面目に行きます!おめでとう!ぐふふ…
見えてる方の画像は虹裏に投下していますのでびぃぶろぐでは無害です…無害です!

…さぁつぎいってみようか…えっと…今回はaitendoさんからは変換基板は販売され
てないので自分でユニバーサル基板使って製作しました。この基板は秋月の定番のや
つですね〜。


↑まぁお試しなので広めにとっています。広いとミスも減って組みやすいですし。


↑裏にはバックライトLEDドライバとタッチスクリーンICのADS7843を載せています。
 ADS7843のおべんきょはこれからです。


また、今回の液晶を使用するにあたり、同じくEGO028Q02を試用しているそら氏より
YHY024006Aと同じく8bitバス幅でアクセスできる手法を教えてもらいました。
XMEGAみたいな8bitマイコンでも動かすことができるようにIM0端子を細工して外部
からプルアップ/ダウンでデータバス幅を切りかえられるようにしています。


↑EGO028Q02を改造したついでにYHY024006Aも同じ改造を。こちらはADS7843は無しです。


実物見た方は分かると思うんですけどね、データシート上ではIM0端子が出ているよ
うな感じがするんですが実際はNCなんですよね(中華サイトを巡るとNCと明確に記述
されてる同型異番種の物が存在する)…
以前触ったH161T01やYHY024006Aもそうですが、この辺実にチャイナクオリてi(ry

まさか君も秋月ARM基板を買ってしまったのか・・・

少し前にSTM32 Primer1/2用のOS,CircleOSがバージョンアップしてます。同じく
してRaisonance RIDE7の開発環境も新しくなっていました。ねむいさんはCodesourcery
をメインに使っていますがRIDEに使用されているコンパイラもCodeSourcery。
RIDEのはまだツールチェーンのバージョンがひとつ古いです(2009年9月20日現在)

早速RIDEを入れ替え、CircleOSを新しくしようと思ってRFlasher起動させてRLINKを認識
させようとするといきなりB.S.O.D.に!!!再起動掛けて同じ事やろうとしてもやっぱ
りB.S.O.D.…orz仕方ないので一度RIDEの環境を全部消してまっさらな状態でもう一度
インストールを行い(USB周りのデバドラももちろん全部消した上で)、試すと今度はOK。
…RAMディスクにデータ乗っけて作業してること多いのでマジ涙目なお話。
追:WinUSBのドライバをXPでも使えるようにすると涙目が治りました。



…前フリはおいといて、秋月はSTM32 Primer2というARMマイコンのプロトタイプボード
を販売していますが、それよりもずっと前にARMの基板を販売していました。
ご存じの方が多いと思いますが、販売当時のネット上の状況、とりわけ2chの電電板の
反応をみると芳しくない反応だらけでした。ボード単体では何もできないとかROM書く
のにMITUIWAボードなるLAN搭載のボードを別途購入してそのボードにROMを載せ替えて
書き込む必要が、つまりは別途ROMライタが必須だとか、そのボードはせっかくLANが
あるのに何でかシリアル経由で書く必要があるとか程度のことですが。…うn?


なんかもう持ってるだけで情弱扱いされてしまいそうですが、それを言ったら上記の
Primer2だって買っても使いたおさなければ情弱アイテムになりかねないのは同じで
すしでもこれ以上ネガチヴなことは言うのやめてせっかくタダ同然で私の手に入った
ので使ってみようと決心しました。でもほんっとに基板だけしかなかったので先人が
ネット上に遺してくれた資料だけを頼りに動かしてみることに。

この秋月ARM基板の詳しい説明はなひたふ氏HRA氏が残されています。AT91R40807
MCU内にフラッシュロムがなく、8kbのPrimaryRAM,128kbのSecondaryRAMのみがありま
す。秋月ARM基板には外付けでAT29LV1024というフラッシュロムが乗っかっていますが、
MITUIWAボード(=ROMライタ)を使用せずにJTAG経由でなおかつ安価な方法でROMの書き
換えをを秋月ARM基板単体で行う方法をHRA氏は実現しています。
少し詳しく言うとJTAG経由でRAMにIAP(In-Application Programming)を転送・実行し、
秋月ARM基板そのものをROMライタ化させている…といった感じです。

HRA氏はIAPの転送を行うJTAGアクセスの方法としてなひたふ氏が当時無料で公開して
いたMITOUJTAG体験版を使用していますが記事が書かれて数年後の今、MITOUJTAGは
残念ながら私たちホビイストの手の届かない場所に逝ってしまいました。しかし今は
OpenOCDという超強力なツールがあるので私はOpenOCDを使って同じことを再現する
ことにしました。

またサンプルコードについては何分大昔の物なので私が愛用しているCodeSourceryG++
の環境ではまともにビルドが通りません。結局スタートアップやリンカスクリプト等は
ほぼすべて1から書きなおしています。AT91R40807に当たっては避けて通れないリマ
ップのし方とかOpenOCDで同CPUを叩くスクリプトの書き方とかはすごく勉強になった…。
以下各モードでの動かし方とか動かした様子とか。

うー
うー

ROMスタートモードで実行するときは、まずIAP(ここではRomloader.elf)をSecondary
RAMに転送&実行し、UART1上で本来書き込むべきプログラムをフラッシュロムへとダウ
ンロードします。本来はDCC経由で書くべきなんでしょうけどもHRA氏が作成されたツー
ルを最大限に利用させてもらいました…。
うー
ROMに置かれたプログラムは、スタートアップルーチン内でSecondaryRAMに転送され、
そこでさらにbss領域初期化などの処理を経てmain関数へと飛びます。

うー
RAMスタートモードで実行するときは、ROMに書かれた内容はガン無視でリマップされた
SecondaryRAMに0x00100000からダウンロードします。さすがに早いです!

うー
ROMスタート時と違って一切合財SecondaryRAMに押し込むので少しかさが増えてます。

OpenOCDを使用した上記RAM,ROMスタート方法の具体的なテクニックは後に示すソース
中のmakefikeを見てくださいね。


OpenOCD+CodesourceryG++のARM開発環境下でRAM,ROMスタートの方法を見つかるまで
かなり時間がかかりましたけどいつものUart経由でprintf出力の所まではできました。
うー

こっから先は回路図持ってないので出来ません…。ていうかSTM32F107とかLPC2388とか
の魅力的な石が出回ってる現在ではこれ以上この基板に時間をかける気はもう微塵も
ありません!!…しかし、時間が死ぬほど余ってる&この基板をただで手に入れたぜ〜!
なんて人は、リマップやROMなしCPUにおける外部ROMスタートの仕組みを学ぶのに
うってつけだと思います。
※20090930:
祝!秋月さんHPにてついに回路図が公開されたようです!
ねむいさんはもうこの基板やらないけど!

今回のテストプログラムはこちらです。最低限の部品で動きます。
またAT91R40807用のOpenOCDのスクリプトはこちらに。
上記サンプルソースにはビルド済のRomloaderのelfがあるけど別途コンパイルしたい
なんて方のためにこちらに置いときます…。
以上ご利用は自己責任で…。


全然関係ないけどAT91R40807が正解なんだけどAT91R40708といつも間違えてしまうorz

STM32F107をもうちょっと使ってみる

CQ-STARMの基板に乗っかっている3.3V出力のLDOは、たったの150mAしか電流
容量がありません(てかこんだけの電流容量でSDカードとかよく動かせてたな…、
無茶な設計したもんだ)。
STM32F107に載せ替えてこれからもいろいろやって行くつもりなのでそれを見据えて
同基板にもうちょっと多く電流が引くことができるLDOを載せ替えました。

うー
元のLDO周りの回路は全部取り外し…

うー
裏のやたらにワイドなパタンを利用してLT1963AMLCC(X5R,16V,10uF)を取り付け…。

このLT1963Aという石は逆電圧保護・逆接保護・過熱保護などの各種保護回路があり、、
なおかつMLCCが使用可能というナイスなLDOです。その分値段は張りますが…。
昔秋月にL1087というのがあったのですが値段も安くて使いやすかったなぁ…という
思ひ出。

(レギュレートする前の電源ソースにもよるけど)最大1.5Aも電流が引けるので3.3Vで
動くいろんなデバイスをぶら下げられます。秋月のGPSモジュールとかも+3.3Vだと常
時190mA近く食ってるけど改造後は余裕です!でもGPSは次回以降のネタにとっときます…。

これで電流容量的にも安心してSDカードが使用できるようになったのでSTM32F103で
やってたFatFsのテストプログラムを107系に移植しました。といっても移植性が
非常に高いMCUなのでリンカスクリプトとスタートアップとmakefile以外はほとんど
変えずに動作確認できました。次はいよいよ本懐のFreeRTOS上でEthernet-PHYを
RMII接続で動かす!ですね。
うー

本日のソースはこちらに…ご利用は自己責任で…。
STM32F107VCT6に統合したので削除しました。
また、STM32F103のFatFsのテストプログラムはR0.07cに変えたときに見落としていた
処理があったのですがこれの修正を施した上で107系に移植しています。

XBeeを試す

気がつけばもう8月…月日が経つのは早いです。私はと言えば先日虹裏でスレを立てた
直後に寝堕ちという不名誉な最短記録をおっ立ててしまい軽い自己嫌悪に陥ってました。
それでも参加してくれた皆さんには本当に申し訳ないと思います。お詫びにいなちゃん
があっちの皆さんに目の保養をさせていただくことになるでしょう…
(これ目的でわざとやってるわけじゃないよ!)






5月に買ったおもちゃ達もだいぶ消化出来てきました。残りは今回紹介するXBeeと、
ねむいさんがやるやる詐欺でほったらかしてきたAT91SAM7S256のプロトボードを残す
のみとなrまた前振り長くなりそうだからさっさと本題

現時点では、スイッチサイエンスさんと秋月さんから容易に購入出来るXBeeですが、
使用記などもネット上に豊富にあります。Arduinoと接続した使用例が特に多いですね。
せっかくなので私はLPC2388とSTM32のそれぞれのUARTから使用してみました。STM32
(CQ-STARMの)基板はただのVCPとして動作させ、LPC2388はUART0はそのままにUART1で
XBeeの通信をさせるように
してます。今回はLPC2388のUART1の使用実験も兼ねています。

うー

二つ用意したXbeeはデフォルトではtransparent mode,9600,n,1になってるので先ず
STM32,LPC2388のボーレートもそれに合わせて試しました。9600bpsでは特に問題なし。

次にボーレートをあげて通信を試みましたが、事前に読んだマニュアル中に、"コマンド
「ATBD7」で設定できるのは115200bpsではなく実際は111111bps。non-standard-rates
で設定すると)「ATBD1C200」)正確な115200bpsで設定できる"と記述があります(超意訳)。
さらに"XBeeで使用されるRFパケットの通信レートが250kbpsの為、高いボーレートで
通信する時にデータの取りこぼしをなくす為にフロー制御が必須、フロー制御無しで
取りこぼし無しに通信したければ十分低いボーレート(たとえば9600bps等)で行うこと。"
とも書いて有りました(超意訳)。

つまり115200bpsでフロー制御無しで文字列垂れ流しやると100%失敗するようなので
試してみると案の定大失敗orz57600,38400bpsだとかなり安定してきますがそれでも
たまに文字が落ちます。結局transparent mode下ではフロー制御無しでお手軽に確実
に使えるのは19200bpsあたりまでということが分かりました。
(注:XBee本体とお話しするだけなら115200bpsでも別に問題はないです。)
digiのフォーラムにはstopbitを2にすることで115200bpsでも通信が可能になったみ
たいなこと書いてありましたが真似してやってみましたが駄目でしたクソァ!
…まだ"さわり"で動かしたの段階なのでマニュアルを熟読してリベンジですね。

まぁ大量のデータをバリバリ流すなんてことは全く考えてなくて遠隔地にあるセンサの
値を読む程度の使用と想定してますので低いボーレートでも気にはなりませんが…
あとこれ結構電流喰うんですよね(50mA)。バッテリーで使うならデータフロー制御
よりこちらの電力制御の方が最優先でしょう。

LPC2388に実装したFreeRTOS上でEthernet-PHYを使う(だけ)

どうしてもWinARMを使いたいのなら20060606版を使え!
20080331版は一部の標準ライブラリが無いから使っちゃらめぇ!

↑これはねむいさんの独り言です。ねむいさんはCodeSourcery G++を使用することを
強く強くお勧めします。







…さて本題、FreeRTOS配布パッケージにあるLPC2468のデモはMCB2300デモボード
上での使用を想定してオープンソースなTCP/IPプロトコルスタックであるuIPが使用できる
ように組み込まれています。前回は外付けEthernet-PHY(DP83848)の回路を持っていな
かったのでその機能は外してRTOSの動作を見ていましたが、Digi-keyで頼んだ部品が入
ったのでEthernet-PHY周りの回路を製作し、改めて動作の確認を行いました。

Ethernet-PHY周りの回路はMCB2300の回路の丸パクリです…。回路図引く手間が省けた
50MHzの高速なクロックを扱うので、"びびり"なねむいさんはメッシュアース基板で回路
を組みました。基板組むのにかかったお値段は2944円也。QTFP変換基板やメッシュアース
基板使わなかったらもっと安く作ることができるでしょう。動作は保障できませんが。

うー

うー

ChanさんみたくUEW線を活用してカッコよく引き回せられたらよいんですけどね〜…私の
腕ではこれが精一杯ですorz
基板上を走る黒いリードはAWG32・UL3417の超極細耐熱電子ワイヤー。少しかさははり
ますがUEWより扱いやすく、重宝してます。また、CQ-FRK-NXP-ARM基板上の3.3Vレギュ
レータの容量が心もとないので(他のデバイスぶら下げること考えて)Ethernet-PHY基板
用に別途3.3Vレギュレータを設けました。昔秋月で販売していたL1087を使用してます。

一応50MHzのクロックのラインは最短で這わせています。オシロで見る限りでは、
ちゃんと所定の50MHzの周波数で発振しているようなのでひと安心。
ここまでやって失敗してたら死ぬわ。
うー
↑オシロのグランドリード伸び伸びのやっけつ測定。一応50MHzは出ているが…



後はソフトの方ですが公式のFreeRTOSソースはVerUpされてすでにV5.4.0になってます。
以前動かしたLPC2388用のデモソースもV5.4.0上で問題なくコンパイル・動作確認でき
ました。んで、以前はコメントアウトでオミットしていたuIPのタスクとLCDのタスクを
再び復活させるのですが、LCDのタスクは台湾BOLIMIN製のi2c液晶モジュー
のルーチンに差し替え、さらに48MHzで動作させていたFreeRTOSを72MHzで動かします。
オリジナルのLPC2468のデモは48MHzで動かしてたのに今気づいたorz

そんなこんなで無事にWebServerが動作しました。i2c液晶もオリジナルのLCDと遜色なく
表示ができています。printf系の関数もHeap_3.cを使うことによりうまく機能しました。
(printf系はOSから正しい手順で動かす方法あるはずなんで調査中です。)

うー

うー

元のLCDのソースには80段階でバーグラフ表示させるルーチンもあったので、ST7032iの
ライブラリに移植してます。初めて知ったけどこれ使って面白いのが作れそうですね〜。

うー
↑てわけで早速使って組み込んでみた。





今同時に進めてるCortex-M3も将来的にはSTM32F107系に乗り換えるので、RMII接続できる
Ethernet-PHY基板はこれからも重宝しそうです。
本日のソースはこちらに…。先にも書いたけどEthernet-PHYの回路はここ参照のこと
お約束ですが真似して試される場合は自己責任でどうぞ!

涙目のネムイ(STM32 Primer2のあれ)

秋月さんとこからもSTM32マイコン評価キットのSTM32 Primer2が販売されています
大量在庫で6100円の格安です!
ねむいさんは4月頃にDigi-keyで9600円くらいで購入していたので今すげぇ涙目です。
くやしい…でも…使用記書いちゃう!

20110824追加:
超実用!!USBマスストレージ機能つきGPSロガー


20091206追加:
USBマスストレージ機能付きいないさんのえろす画像表示機の制作





20091114追加:
ねむいさんがついに重い腰をあげましたの巻

早く座らせてくれ

20091012追加:
電源IC壊れたけどヤクいさんのために気合いで直しましたの巻


20091008追加:
電源ICが壊れて涙目の巻


20091004追加:
STM32 Primer2を使用したアプリ"いないさんと遊ぼう(性的な意味で)"を追加



うー
オレンジのボタンを押して主電源を入れると"Welcome to STM32Primer2!"と喋ってくれ
ます。おお、なんかすげぇ!入力デバイスはおなじみMEMS加速度センサ、そしてPrimer1
には無い4方向キーパッドやタッチパネルなんかもついていたりします。
少し4方向キーパッドがおしづらいです。日本携帯ゲーム機に慣れている方は戸惑うかも〜


うー
タッチパネルはのほかにもペンタブの先っちょでも使えます。というか画面が小さいので、
ペン入力デバイスをペンタブ売ってるとこで買っといた方がいいでしょう。指でやるとすぐ
指紋だらけになるし。
画像はmp3を再生するアプリ。音質はそれなりです。


うー
裏蓋を外したところ。Primer1ではガバガバだった蓋はけっこうかっちり閉まるように
なってます。裏には拡張用コネクタ、リチウム電池、デバッグ用・アプリ用USBコネクタ、
ステレオジャック、MicroSDカードスロットなんかがついてます。カードは別売りです。


うー
基板のRevは1.1です。

うー
表蓋は木ネジで固定されています。結構固いです。壊さないように丁寧にはずしました。
基板表面には部品がいっぱいのってます(はしょるはしょる)。
……おや?何かリワークしたあとが…


うー
細いラインを太いジャンパで補強しています。グランドを強化してる感じです。これは…


調べるとこういう記述がありました。
うー
多分アートワーク設計の時にGNDをただのプルダウンと勘違いして細いライン引いちゃ
ったのでしょうね…それでインピーダンス上がって寄生インダクタンスが出来てしまって
共振して高電圧が出てレギュレータ壊したと…あれ?どっかで聞いたような…まぁいいや…
どっかの基板と違ってちゃんと対策されて出荷されているので安心して使用できます。


うー
むき出しの状態で使用してみる。タッチパネル液晶の発色がきれいですね〜。


うー
STN液晶のPrimer1と比べてみる…視野角が全然違いますね…さすがTFT液晶


うー
おまけ。Primer1の表蓋外したところです。ねむいさんはCQ-STARMだけでもひいこら
言ってるのでPrimer1,2で遊んでる余裕なんて無いと思います。他の方の応用例に
期待をしたいと思います!

この記事を書いて約1年後、時代はmbedを使ったクラウド環境の開発が栄えてしまい、
ふつーに使っただけで電源回路が破壊されるSTM32 Primer2とかすっかり情弱基板
扱いになってしまったのでしたorz

ディジタル・デザイン・テクノロジ付録基板のLatticeXP2にUrJTAG+JTAGkey互換回路でコンフィグする

2011.05.26追:
LatticeのISPVMがFT2232デバイスに正式対応となりました!
これで手軽に読み書きができるようになります。
いい時代となりましたね♥
追の追:
内蔵Flashに書くときは.jedファイルを指定します。
SPI-ROMに書くときは.bitファイルを指定します。
あとHS-1はGNDに落としておくこと。

2009.07.31追:
Latticeの付録基板を使用中、書き込み・消去が失敗すると以後基板からヤバ目
の発振音がしてJTAGで一切アクセスできなくなる事態に陥いることがあります。
これは「不完全なコンフィグ->コア電流異常消費->電圧ドロップ->再コンフィグ」
のループを繰り返してデッドロック状態に陥ってるからです。

この状態から回復するにはnPROGピンを(Lattice基板上でCN2_B07を)LOWに
引いたまま電源を投入して電源投入直後のコンフィグを開始させない状態で
JTAGにアクセスし、書き込みor消去を正しく完了させる必要があります。
依然としてこのページのアクセスが非常に多く大事なことだから2度言います。




DWM誌が廃刊休刊となり、新たにディジタル・デザイン・テクノロジ誌
略してDDT誌が刊行されました。ご多望にもれず、付属基板なんかがついてます。
石はLatticeのLFXP2-5E-5TN144Cですね。フラッシュベースの不揮発型FPGAですって。

ねむいさんはLPC2388基板と秋月ARM基板動かすのに夢中になってたので
ほうっておいていましたが少しだけ触ってみましたよ。LPTの書き込みアダプタはもはや
作る気がなく、なひたふ氏の78kを使ったライタはCOMポートが増殖してしまいます。
ねむいさん的にはテストを兼ねてUrJTAG+JTAGkeyを使ってSVFファイルの
再生と言う形でLatticeの基板に書き込みをして見ようと思います。


…5月17日現在、ネットで検索してもデモのLEDチカチカを書きこんだ!
以外の作例が全くと言っていいほど見当たりません。
それどころかLEDチカチカの記事すらほとんどないのがさらに不安をあおります。
唯一chanさんはミクを動かしてレヴェルの違いを見せつけてくれていました。すげぇ。


私も一つ組んでみました。30Mhzの水晶とM25P40-VMN6P、LDOのADP3339なんか
つけてみました。あれ?このADP3339って…とお思いの方、かわいそうに…そう、+5V電源を
指示どおりに接続すると高い確率で発振するかのSH2基板に乗っかっていたアレですね〜。
今検索すると"「接続すれば発振する」は通用しない"と言う一文がトップに躍り出て
とても意味深です。でもADP3338/ADP3339はわるないよ?

それはおいといてこんな感じに各部品を実装。電源は容易に脱着できるように
JST-XAを。JTAGの端子は10Pinありますが、実際に信号が出てるのは
TCK,TMS,TDO,TDI,Vcc,GNDだけなので、馬鹿避け用に真ん中の一本はカットしてます。
ついでに9,10Pinもカット(最初からつけなきゃよかったorz)もちろん対になる8Pinコネクタ
(どうせ残りの9,10Pin繋がってないし…)はカットした真ん中の一本に
メクラをかませて馬鹿避けを実現してます。

ADP3339用のコンデンサは裏に実装してます。VinにはGRM21BB31C106KE15を、Voutには
秋月のこの子を付けて常時安定した+3.3Vの供給を行っています。
秋月のセラコンは+3.3V以下のセラコン対応のLDO用に大量に買っておいてもいいと思います。
あ、言い忘れてた、ADP3338/3339使うときはRP1、RP2は必ず除去してください!
真似する人はちゃんとデータシートで確認すべし。
さらに今回はSPIEEPROMは付けたけど一切無視するのでHS1のジャンパもカット。
やっとかないとSVFで書けません。

書き込む準備は出来ましたので次はsvfファイル生成ですね。
ISPLEVERとその他ツールはインストールしてあるものとして話を進めます。
jedの生成までは紙面にあるので省きますよ!!
(ツールをインストールするまで一苦労でしたね〜…認可もらえるまで
時間やたらかかったり、まぁその分しっかり審査しているということなのでしょう。
ちなみに私は組織名:二次裏メイド協会、名前:キリ・イセノミヤで通りました。
はぢめて上司が役に立った(笑)…っていいのかこれで)



では行きましょうか。
というわけでだいぶ端折ってjedが生成されたところからスタート。
これから先は画像付きで。
jedが生成し終わったらispVMを起動する
ChainConfigration1と言うウィンドウは即効消す。
UniversalFileWriterを起動
生成ファイルにSVFを選択
InputDataFileに先に生成したjedを選択
RUNTEST FROM REV.C をONにする
OutputDataFile名を指定する。
Genereteボタンを押してSVFを生成

はい出来ましたね?できてなくても次行きます。
次はいよいよ書き込みです。前ふり長くなりましたがこっからが本番です。
UrJTAGをダウンロードしてインストールしてください。JTAGkeyと通電した基板を接続し、
UrJTAGを起動。生成したsvfをUrJTAGと同じフォルダに置いて以下のコマンドを順番に。
その前に!HS1のジャンパカットし忘れてたら電源落としてカットしておいてね!

>cable jtagkey
>detect(ちゃんと繋がっていればここでチェーンが見える)
>part 0
>instruction length 8
>svf (生成したSVFのファイル名) progress
1分ほどたつと
>Scanned device output matched expected TDO values.
と表示され、FPGAがロードされます。

あと小技ですが、svfファイルの中のeraseの記述で
>! Erase the device
>
>! Shift in ISC ERASE(0x03) instruction
>SIR 8 TDI (03);
>! wait 1.20e+002 SEC
>RUNTEST IDLE 120000003 TCK;

>RUNTEST IDLE 120000003 TCK;

>RUNTEST IDLE 5000003 TCK;
くらいに減らしてやると書き込み時間を大幅に短縮できます。
最速で40秒くらいでコンフィグできます。それぞれの環境で調整して見てください。

また、もし書き込みが失敗してFPGAが不安定な状態に陥ったらnPROGピンを(基板上で
CN2_B07を)LOWに引いたまま電源を投入して再び書き込みを行って回復して
くださいね。基板捨てんじゃねぇぞ!あきらめるな1!!(←乙女の雄叫び)




こんなかったるいコマンド入力いちいちやってられるか!!と言う
方はバッチで実行するやり方もありますのでご紹介します。
こちらの中にサンプル付きでありますので中のファイル見てねむいさんが
何をしたいかが理解できる人だけ自己責任でどうぞ。

30MHzの外部OSC必須です。でもUART要らない人は特に周波数に気にしなくてもいいです。

JTAGkeyClone(FT2232系JTAG I/F)製作のすすめ


20130521追:
FT2232系デバイスを用いたJTAGKey/JTAGKey2製作に関しては
こちらを参照してください!











お仕事の方でサーボモータのおべんきょを一からしてます。
そもそもねむいさんは4年制大学を卒業したにもかかわらず就職氷河期の下、
20代後半まで介●の仕事をしながら本業の虹裏メイドをしていたので電気の分野は
ほぼ一からおべんきょなのですが、私の場合は元主人が遺したARMマイコンに
関するリソースが最初から大量にあったのでARMマイコンに関しては強くて
ニューゲーム状態だったのです。

とはいえまったくのどしろうとでもべんきょうさせてもらえながらちゃんとしごともさせて
もらえてさらにおきゅうりょうまでもらえるくみこみぎょうかいってすごいとおもいます。
ちなみにねむいさんのほんしょくのにじうらめいどはちょうぜつぶらっくでにんきのない
めいどは「」たちにすぐよごれきゃらのきゃらづけをされてあらしのどうぐにされてすてら
れるというれつあくかんきょうなうえにおきゅうりょうがはなくそていどしかもらえません。
ふぁっくです。

きょうのにっきおしまい。








…真面目に読んでしまった人すみません、続行します。



以前はJTAGの制御といえばPCのLPTポートに少しばかりのロジックデバイス、おもに信号
レベル変換のバッファが乗った回路を接続してI/O直叩きで制御ってのが主流でしたよね。
CPLD/FPGAを提供している各社もLPT接続タイプの書き込みケーブルの回路を公開して
いて、趣味で開発やっている人も自作が容易にできていました。

時は流れ、いまどきのナウでヤングでスタイリッシュなPCにLPTポートなんて時代遅れ
のものは搭載されなくなり、代わりにUSB接続のダウンロードケーブルがメーカから
提供されるようになりました。
しかし、USBのそれは各社のノウハウになっていて真似して自作できる代物ではなく
なってしまいました。しかも安くても3諭吉くらいしてホビー用途には手が出しづらい。

しかしながら数年前くらいからFT2232等のJTAGのライブラリがサポートされるデバイスが
出てきて有志の人たちがフリーで多目的に使用できるアプリケーションを作られてきました。




そのFT2232を使用したJTAGハードウエアで有名なのがAmontec JTAG keyですね。
容易に自作できるのでFT2232系は上記を含め多くの派生があります。それを通じてARM
マイコン等のJTAGポートを備えたデバイスにアクセスできる(フリーで使える)PC側のソフト
は、OpenOCD、UrJTAG等などたくさんあります。

先の日記で何度か言及してますが、私もかみき氏の作例をベースに一つ作成しました。
2電源レベルシフタがミソです。氏の回路と違う点は、ターゲットに電源供給する回路を
廃したことと、外付けEEPROM(AT93C66A)の回路を追加してAmontec JTAG keyに化かす
ことを目的としました。




自分自身の学習の意も含め、かみき氏互換のJTAGkeyCloneの回路図を起こしました。JTAGkey2Cloneに関してはこちらをご参照ください。

また、JTAGkeyCloneに化かすためのeepromのデータですが、こちらにあるJTAGKey用の
デバイスドライバのZIPファイルを展開するとJTAGKey_eepDataというフォルダがあります。
この中にあるamontecJTAGKey.eptというファイルをMProgで読み込んでeepromに書き
込んでください。もちろんEEPROMの書き込みの際は先にFTDIのドライバをインストール
しておかなければなりません。これは先のZIPファイル内のftd2xxというフォルダにあります。


20130521追:
JTAGKey/JTAGKey2製作に関してはこちらを参照してください!



以下JTAGkey互換回路を制御できるアプリの使用時の画面とかを。
詳しい使用記は以後の日記で幾つかをぽつぽつと。


IF誌付録LPC2388基板にOpenOCD+insightでデバッグ


asagaoでDWM誌2008年9月号付録のColdFire基板のEzPort経由のプログラム書き換え


OpenOCDで秋月ARM基板のRAMスタート


UrJTAGのSVF機能でDDT誌付録のLatticeXP2基板を高速にコンフィグ


HappyJTAG2とかいう怪しいのでAVRにJTAG経由で書き込み


fenrir氏作成のcblsrvのFT2232対応版を使用してxilinx IMPACTからコンフィグ
(注:fenrir氏によってISE11.x以降でも使えるようになりました!)


そして本懐のamtsvfplayerでSVFを再生…できねぇ!
20120215追:
amtxhal.dllはグルーロジック(非公開)が組まれたPORTB側のDS2432というEEPROMに
仕込まれたキー情報も読みに行っているのでクローンの場合はamtxhal.dllを
使用するプログラムは一切使えなくなります…がamtsvfplayerくらいしか使われてるの
見たことないのでJTAGkeyCloneでもそれ以外の用途では全く問題はありません。
JTAGkey系のCloneでsvf使いたいならUrJTAGを使いましょう。

MassStorageClass DEMOを動かす

最近工作ものばっかに手を取られて本業の二次裏メイド業が
おろそかになってる私。下描きでほったらかしているいないさんの絵が
早く仕上げてと訴えている。もうちょっと待っててね♥




さて本題、てDWM誌2008年5月号の付属基板と同梱のCDには
DFU経由でCQ-STARM基板に書き込みができるように
いくつかのデモがすぐに使えるようにとdfuファイル形式で
入っていました。しかし、紙面の説明がとても乏しく、そのとおりに
やっても動かない云々の意見と(その対策)が出ていたのは
みなさんご承知のとおりと思います。

この同梱されたdfuファイルというのはCQ-STARM向けではなく
STマイクロが提供する評価キットSTM3210B-EVAL/STM3210E-EVAL
向けのものです。

CQ-STARMはSTM3210B-EVALの回路構成を真似て設計されており、
STM3210B-EVAL向けのdfuデモファイル群も一応動くのですが、
その中でMassStorageClassの奴をそのまま使ってしまうと
ちょっとまずいことが起こります。

CQ-STARM上ではSDカードを挿入したときに必ずLになるポート
が出力になっており、ショートしてCPUおよびSDカードに
ダメージが行きます。どうなってるかはここ見てくださいね。
この件も私が見つけたわけではなく、去年すでに騒がれたこと
なのですが、忘れ去られた頃に新たにCQ-STARMに触る人がいる
かもしれないから書き残しておきます。


以下私が行ったわーくあらうんど。
●ソフトウエア
 初期のデモでは確かSTM3210B-EVAL上のLED4つが同時点灯するという
 コードのようでしたがV3.0.0/V3.0.1のデモコード見ると最小限のLEDのポートが
 出力になるようになってました。前回のコードはV3.0.0を適用してあるので
 そっちを使ってもらえればいいかなと思います。
 LEDの出力もCQ-STARMに合わせて変えてます。でも下のパタンカットは必須ですよ!

●ハードウエア
 STM3210B-EVALは本来MicroSD搭載なのでライトプロテクトと挿入検知は
 存在しない。だからここにつながるパタンいらないからカット!
 こんな感じで

ついでだから他の便利な改造も基板に施してますので紹介します。

●USBディスコネクト
 USBのデモにはRESETをかけるとUSBが切り離される"USBディスコネクト"
 のコードが含まれているのですが、CQ-STARMはハード的に駆動させるための回路
 が存在しません。したがってDFUで書いてはUSBケーブル抜きを繰り返す
 必要があり非常にめどいです。だからこの部分を追加。
 具体的な改造はこんな感じ。パタンカットもなくビアとポリイミド
 テープを駆使してなんなく達成。これでUSB-miniBコネクタが激しい抜き差しで
 ガバガバになるのを避けられます。


●加速度センサにコンデンサ追加
 加速度センサ周りに10uFのチップセラコンと1nFのチップセラコンを追加する。
 これは加速度センサの指示ですね。つうか本来はじっそうすべきなのですがなぜか
 この基板を設計した人はそれを無視して動作不安定になるような回路設計を
 してらっしゃいます。

 10uFのチップセラコンは+3.3V系以下の系では秋月のこれを愛用してます。
 こいつは2012サイズなのに大容量でかつ静電容量変化率も少ないので、
 セラミックコンデンサ対応のLDOとも相性バッチリです。
 
 1nFのチップセラコンは1608のをビアと近接のGNDパタンはがして実装。
 10uFの方は元の1uFは一旦どいてもらってポリイミドでガードした上
 に仲良く同居。こんな感じで



使ってみた感じですが、わたしの手持ちの256Mb,512MB,1GB,2GBはすべて
Windows上のディスクドライブとして認識、読み書きもできました。
残念ながらSDHCはファームウエアで対応しておらず認識できないようです。

Go to top of page