いろいろ試す29

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



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

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

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

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

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


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

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

Built Informations:
USING_SYSTEM = BARE_METAL
USING_DISPLAY = USE_OTM8009A_DSI_TFT
USING_DEVBOARD = USE_STM32F769I_DISCOVERY

Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 726616 0 726616 b1658 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
724016 2600 2379504 3106120 2f6548 main.elf
main.elf :
section size addr
.text 0xb0ba8 0x8000000
.ctors 0x0 0x80b0ba8
.dtors 0x0 0x80b0ba8
.ARM.exidx 0x8 0x80b0ba8
.data 0xa28 0x20020000
.itcm 0x80 0x0
.bss 0xb20 0x20020a28
.heap 0x0 0x20021548
.dtcm 0x10454 0x20000000
.stack 0x4 0x20010454
.ethram 0x0 0x2007c000
.batram 0x0 0x40024000
.extram 0x233f78 0xc0000000
.qspirom 0x0 0x90000000
.comment 0x7f 0x0
.debug_aranges 0x3fd8 0x0
.debug_info 0x141d2c 0x0
.debug_abbrev 0x1d619 0x0
.debug_line 0x48aa5 0x0
.debug_frame 0x12d58 0x0
.debug_str 0x18c38 0x0
.debug_loc 0x10b358 0x0
.ARM.attributes 0x35 0x0
.debug_ranges 0x176c8 0x0
Total 0x5f076e
(arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437])
Built Informations:
USING_SYSTEM = BARE_METAL
USING_DISPLAY = USE_OTM8009A_DSI_TFT
USING_DEVBOARD = USE_STM32F769I_DISCOVERY

Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 726952 0 726952 b17a8 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
724352 2600 2379504 3106456 2f6698 main.elf
main.elf :
section size addr
.text 0xb0cf8 0x8000000
.ctors 0x0 0x80b0cf8
.dtors 0x0 0x80b0cf8
.ARM.exidx 0x8 0x80b0cf8
.data 0xa28 0x20020000
.itcm 0x80 0x0
.bss 0xb20 0x20020a28
.heap 0x0 0x20021548
.dtcm 0x10454 0x20000000
.stack 0x4 0x20010454
.ethram 0x0 0x2007c000
.batram 0x0 0x40024000
.extram 0x233f78 0xc0000000
.qspirom 0x0 0x90000000
.comment 0x7f 0x0
.debug_aranges 0x3fd8 0x0
.debug_info 0x141e1b 0x0
.debug_abbrev 0x1d619 0x0
.debug_line 0x48aa5 0x0
.debug_frame 0x12d58 0x0
.debug_str 0x18c3d 0x0
.debug_loc 0x10b365 0x0
.ARM.attributes 0x35 0x0
.debug_ranges 0x176c8 0x0
Total 0x5f09bf
(arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors 6-2017-q1-update) 6.3.1 20170215 (release) [ARM/embedded-6-branch revision 245512])
text領域が若干絞られていますね。


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




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



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





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

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



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

それでは早速いつものカード情報を抜き出して見ました。
●Sandisk ExtermePRO microSDHC 32GB SDSQXCG-032G-GN6MA
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Jul 17 2017
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 19632 kB/sec.
>ds 0
rc=0
Drive size: 62333952 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
CSD:
00000000 40 0E 00 32 5B 59 00 00 ED C8 7F 80 0A 40 40 C3 @..2[Y.......@@.
CID:
00000000 03 53 44 41 47 47 43 44 80 61 BB 43 93 01 16 03 .SDAGGCD.a.C....

Parsing SD CID Register
Manufacturer ID :0x3
OEM/Application ID :SD
Product Name :AGGCD
Product HwRev :8
Product SwRev :0
Serial Number :0x61BB4393
DateCode.Month :6
DateCode.Year :2017

OCR:
00000000 C1 FF 80 00 ....
SD Status:
00000000 80 00 00 00 05 00 00 00 04 00 90 00 0F 05 3A 1E ..............:.
00000010 00 08 00 00 00 01 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 84 43 00 00 00 00 .5.C....

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

SD_Spec V5.xx!
Detected as SDHC Card!
Available UHS-I Mode.
>

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


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


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

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

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

・・・
チマチマ書きめッちゃ早いやん・・・PROじゃないほうのExtremeなのに・・・

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

・・・
チマチマ書きめッちゃ早いやん・・・PROじゃないほう(ry

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


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

Kinetis KEシリーズを使う

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



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

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


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


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


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


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

> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jlink_swd.cfg -f target/kexx_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.10.0+dev-00161-g1725abc-dirty (2017-06-23-00:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
swd
Info : add flash_bank kinetis_ke kexx.pflash
cortex_m reset_config sysresetreq
none separate
adapter speed: 1000 kHz
Info : No device selected, using first device.
Info : J-Link OpenSDA 2 compiled Oct 13 2015 12:10:56
Info : Hardware version: 1.00
Info : VTarget = 3.300 V
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x0bc11477
Error: MDM: failed to read ID register
Error: MDM: Failed to check security status of the MCU. Cannot proceed further
in procedure 'init' called at file "C:/Devz/ARM/OCD/tcl/target/kexx_swd_flash.cfg", line 125
in procedure 'ocd_bouncer'

Info : SWD DPIDR 0x0bc11477
Info : kexx.cpu: hardware has 2 breakpoints, 2 watchpoints
Info : MDM: Chip is unsecured. Continuing.
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x000000cc msp: 0x20000c00
Info : Watchdog stopped
auto erase enabled
Info : KE02 sub-family
Info : Flash clock ready
Warn : flash configuration field erased, please reset the device
Info : Flash clock ready
Info : Kinetis KE: FLASH Write ...
wrote 8192 bytes from file main.elf in 0.734375s (10.894 KiB/s)
verified 7936 bytes in 0.093750s (82.667 KiB/s)
Info : MDM: Chip is unsecured. Continuing.
shutdown command invoked

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

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

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

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


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


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


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

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

いろいろ試す28

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

●STM32L0シリーズを使う

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


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

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


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


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


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

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

> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f target/stm32l0discovery_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.10.0+dev-00143-gf6449a7-dirty (2017-05-20-14:25)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 300 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : clock speed 240 kHz
Info : STLINK v2 JTAG v28 API v2 SWIM v18 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.240553
Info : stm32l0.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x08002148 msp: 0x20002000
STM32L0: Enabling HSI16
Info : Unable to match requested speed 2500 kHz, using 1800 kHz
Info : Unable to match requested speed 2500 kHz, using 1800 kHz
adapter speed: 1800 kHz
adapter speed: 1200 kHz
auto erase enabled
Info : Device: STM32L0xx (Cat. 3)
Info : STM32L flash size is 64kb, base address is 0x8000000
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000000e msp: 0x20002000
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000000e msp: 0x20002000
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000000e msp: 0x20002000
wrote 16384 bytes from file main.elf in 3.218750s (4.971 KiB/s)
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20002000
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20002000
verified 16096 bytes in 0.140625s (111.778 KiB/s)
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
adapter speed: 240 kHz
adapter speed: 1200 kHz
shutdown command invoked

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

STM32F7を使ってみる18 -CubeF7がv1.7.0になった(ついでにCubeF4も上がった)-

当らないミサイルやGWが日本に迫る中、STマイクロがリリースしている統合ファーム
ウエアパッケージ群のCubeF7
がアップデートしV1.7.0になりました。
ややこしいですがCubeF7中のHALライブラリ本体は1.2.1(CubeF7v1.6.1時)から1.2.2
へとバージョンアップしています。


変更点はCANのライブラリのバグが修正されたことくらいで前回私が指摘していた
幾つかのSDMMC関連ライブラリに関するバグの致命的な部分はそれより前のCubeF7v1.6.1で
修正されていますがまだバグが残ったままとなっています。
でもねむいさんはCubeF7v1.6.1v1.5.0をベースに最新の奴にアジャストしてるので何も影響あり
ませんけどー!!!

ちなみにCubeF4とかの他の品種もアップデートしているようですがHP上で数字だけ
変わっても変更直後はまだ従来の奴だったりする罠がありますのですぐに落とそう
とせず一日ほど待ってからの方がよいです。
ねむいさんは新しモノ好きなのでよくSTマイクロの罠に引っかかるたちです。
この件は昔からフォーラムでたびたび指摘されていますが今に至るまで真剣に対処
されず連携の取れて無さが見て取れるようでちょっと悲しいです。


ちなみに私は現在もDropboxの画像表示できなくなった問題にひたすら対処して
いる段階なのでマイコンその他のアイテムに関する深い解説記事が取れずお預け
状態となっておりますがおきぱのプロジェクトファイルの更新はライブラリの
アップデートとともに月一ペースで更新しておりますのでよろしくお願いします。
今月もちょっと早いですけど5/1版のいつものを更新しました。OpenOCDも新しい
のがマージされたら常に更新掛けてますのでよろしくお願いします。


やる気を保つために次回更新予定のネタを少しお見せします。
OpenOCDのSTM32L0への対応が漸く使い物になるレベルになったので解説を絡めながら
Discovery基板を動かしていく予定です☆

Go to top of page