いろいろ試す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年にはほぼ消失し、別の会社の製品がライン
アップに収まるはずです。まぁホビー用途なら信頼性の保証は自分もちなので自分が
信ずるモノならばなに選んでも自己責任で終わる話だと思います。

20230920追:
2017年時点では上記の通り1608サイズ消滅の危機がありましたが、
村田製作所は車載用向けMLCCにおいては2023年現在でも1608サイズの
製品の供給を続けております！！！！(いろいろ圧力あったんだろうな…)
20230920追:



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


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

Go to top of page