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


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

Comments

ご無沙汰しております。
写真復旧、大変な作業、お疲れ様です。

以下、ちょっと、教えてくだされば幸いですので、よろしくお願いします。
------------------
使用しているマイコンボード STM32F429I-DISCO

STM32F407VGT/407ZGT/427IIT/429ZIT
の、
Board.txt
-- SDCARD STM32 SPI4
MOSI : PE5
MISO : PE6
となっており、
mmc_stm32f4.h
#define SPIMMC_PIN_MISO GPIO_Pin_5
#define SPIMMC_PIN_MOSI GPIO_Pin_6
と、MOSIとMISOがテレコ(反対)になっているのは、何か理由があってのことなんでしょうか?
-------------
以上よろしくお願いいたします。

shuji009様お久しぶりです、ねむいです。

確かにBoard.txtのなかの記述が間違ってましたね。
ほかの結線も間違ってたので修正して8/1版を更新して
おきました。ソースコードのほうは問題ありません。

ご指摘ありがとうございます。

Post a Comment








Go to top of page