ねむいさんのぶろぐ

いろいろ試す63

ああもうこんな季節だ…忙しいのに頭が空回りで何もできていない…
とりあえずできることをできるだけ頑張っていく…!!

●ねむいさんのぶろぐhttps化
タイトルの通りでござます。私のぶろぐの母体"びぃブログ"の仕様が
常時https化したことにより私のぶろぐもhttpsに強制的に変わったの
ですが…

10年来使用してきたソースコードハイライト機能syntax highliterが
今回のhttps化で機能しなくなったのが判明し別のハイライト機能に
切り替えることにしました。それで見つかったのがhighlight.jsです。

かつてのsyntax highliterとほぼ同じ表示感覚で使用でき、表示方法も
ほぼ同じ感覚でした。9月末からhighlight.jsを導入しております。

こんな感じにソースコードの

//ハイライト表示ができます

しかしながらhtmlタグがsyntax highliterのころとは微妙に違うので
過去にさかのぼってブログの記事をせっせと修正しました…
くそ…もっと早くやっておけばよかった…
いちおうすべての記事でhighlight.jsに対応しましたが疲れた…

●OneDriveが仕様変更で古い共有リンク全滅
あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”！！！！
9月末くらいの仕様変更でおきぱにおいてあるSTM32のプロジェクトとか
OpenOCDバイナリとかのリンク全部不通になってたぁああああ！！！

というわけでこちらにも対応して全部共有リンクを再生成してソース
コード置き場のリンクはちゃんとダウンロードできるよう修正いたし
ました…あとは過去のぶろぐ中に張った直リンクたちですが数が膨大に
あるのですがこちらもできる範囲で適宜修正していこうと思います…

また、記事を見直して10年以上前の古いものはリンク仕舞いする個所も
あるのでご注意願います…なるべく残せるようにがむばります…

●最新のarm-gccのgdbの挙動がおかしい？
う～～ん私のやり方が悪いのかどっちが悪いのか断定はできませんが
現時点で最新のArm GNU Toolchain　Version 13.3.Rel1のgdbなんですが、
なんでか"tbreak main"が効かずデバッグ開始時にmain関数の先頭で
止まってくれません。

*問題の13.3.Rel1(GDB14.2)の場合

ソースコードはスタートアップの最初のところを示していますが
breakがかからずそのままプログラムが走ってしまいます。
↓ログはこんな感じ。Continuing...の後音沙汰がありません。

Using gdbinit file: C:¥Users¥nemuisan¥.codelite-gdbinit

Current working dir: R:¥STM32H563xxx_NUCLEO_20241101¥lib¥codelite_dbg¥codelite_dbg

Launching gdb from : ../../../

Starting debugger  : C:¥Devz¥arm¥launchpad¥bin¥arm-none-eabi-gdb.exe --command="C:¥Users¥nemuisan¥.codelite-gdbinit" --interpreter=mi "main.elf"

Debug session started successfully!

GNU gdb (Arm GNU Toolchain 13.3.Rel1 (Build arm-13.24)) 14.2.90.20240526-git

Copyright (C) 2023 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later ¥nThis is free software: you are free to change and redistribute it.¥nThere is NO WARRANTY, to the extent permitted by law.

¥nType "show copying" and "show warranty" for details.

This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

.

Find the GDB manual and other documentation resources online at:¥n    <

http://www.gnu.org/software/gdb/documentation/>.¥n

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from main.elf...

Output radix now set to decimal 16, hex 10, octal 20.

`R:¥STM32H563xxx_NUCLEO_20241101¥main.elf' has changed; re-reading symbols.

Remote debugging using localhost:3333

Reset_Handler () at lib/CMSIS/Device/ST/STM32H5xx/Source/Templates/gcc/startup_stm32h563xx.s:59

59¥t  ldr   r0, =_estack

Successfully connected to debugger server

Applying breakpoints...

Applying breakpoints... done

Unable to match requested speed 480 kHz, using 200 kHz

Unable to match requested speed 480 kHz, using 200 kHz

[stm32h5x.cpu] halted due to breakpoint, current mode: Thread

xPSR: 0xf9000000 pc: 0x08053624 msp: 0x20050000, semihosting

Note: breakpoint 1 also set at pc 0x8000252.

Temporary breakpoint 2 at 0x8000252: file src/main.c, line 41.

Continuing...

*ひとつ前の13.2.Rel1(GDB13.2)の場合

ちゃんとmain関数の先頭で停止します。
↓ログはこんな感じ

Current working dir: R:¥STM32H563xxx_NUCLEO_20241101¥lib¥codelite_dbg¥codelite_dbg

Launching gdb from : ../../../

Starting debugger  : C:¥Devz¥arm¥launchpad¥bin¥arm-none-eabi-gdb.exe --command="C:¥Users¥nemuisan¥.codelite-gdbinit" --interpreter=mi "main.elf"

Debug session started successfully!

GNU gdb (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)) 13.2.90.20231008-git

Copyright (C) 2023 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later ¥nThis is free software: you are free to change and redistribute it.¥nThere is NO WARRANTY, to the extent permitted by law.

¥nType "show copying" and "show warranty" for details.

This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

.

Find the GDB manual and other documentation resources online at:¥n    <

http://www.gnu.org/software/gdb/documentation/>.¥n

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from main.elf...

Output radix now set to decimal 16, hex 10, octal 20.

Remote debugging using localhost:3333

Note: automatically using hardware breakpoints for read-only addresses.

Reset_Handler () at lib/CMSIS/Device/ST/STM32H5xx/Source/Templates/gcc/startup_stm32h563xx.s:59

59¥t  ldr   r0, =_estack

Successfully connected to debugger server

Applying breakpoints...

Applying breakpoints... done

Unable to match requested speed 480 kHz, using 200 kHz

Unable to match requested speed 480 kHz, using 200 kHz

[stm32h5x.cpu] halted due to breakpoint, current mode: Thread

xPSR: 0xf9000000 pc: 0x08053624 msp: 0x20050000, semihosting

Note: breakpoint 1 also set at pc 0x8000252.

Temporary breakpoint 2 at 0x8000252: file src/main.c, line 41.

Continuing...

Temporary breakpoint 1, main () at src/main.c:41

41¥t¥tSet_System();

古いほうは古いほうでちょっと問題があってなんでかバイナリサイズが
256MBもあるデバッグビルドになっており、elfファイルの読み込み時間も
時間がかかります(私の環境ではそこまで気にならなかった)。

切り分けのためにFreddieChopin氏のarm-gcc野良ビルド"Bleeding-Edge"
を使ってみます…(32bit版が動作しなかったので64bit版を使います)

GDBが14.2になったのが原因なら同じ14.2なら再現性があるはずですが…

ちゃんとmain関数の先頭で停止しますね…。

Using gdbinit file: C:¥Users¥nemuisan¥.codelite-gdbinit

Current working dir: R:¥STM32H563xxx_NUCLEO_20241101¥lib¥codelite_dbg¥codelite_dbg

Launching gdb from : ../../../

Starting debugger  : C:¥Devz¥arm¥launchpad¥bin¥arm-none-eabi-gdb.exe --command="C:¥Users¥nemuisan¥.codelite-gdbinit" --interpreter=mi "main.elf"

Debug session started successfully!

GNU gdb (bleeding-edge-toolchain) 14.2

Copyright (C) 2023 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later ¥nThis is free software: you are free to change and redistribute it.¥nThere is NO WARRANTY, to the extent permitted by law.

¥nType "show copying" and "show warranty" for details.

This GDB was configured as "--host=x86_64-w64-mingw32 --target=arm-none-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

.

Find the GDB manual and other documentation resources online at:¥n    <

http://www.gnu.org/software/gdb/documentation/>.¥n

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from main.elf...

Output radix now set to decimal 16, hex 10, octal 20.

Remote debugging using localhost:3333

Note: automatically using hardware breakpoints for read-only addresses.

Reset_Handler () at lib/CMSIS/Device/ST/STM32H5xx/Source/Templates/gcc/startup_stm32h563xx.s:59

59¥t  ldr   r0, =_estack

Successfully connected to debugger server

Applying breakpoints...

Applying breakpoints... done

Unable to match requested speed 480 kHz, using 200 kHz

Unable to match requested speed 480 kHz, using 200 kHz

[stm32h5x.cpu] halted due to breakpoint, current mode: Thread

xPSR: 0xf9000000 pc: 0x08053624 msp: 0x20050000, semihosting

Note: breakpoint 1 also set at pc 0x8000252.

Temporary breakpoint 2 at 0x8000252: file src/main.c, line 41.

Continuing...

Temporary breakpoint 1, main () at src/main.c:41

41¥t¥tSet_System();

FreddieChopin氏一番新しい版はGDB15.2まであがっておりましたので
こちらでも念のため確認してみます。

こちらもちゃんとmain関数の先頭で停止します。

Using gdbinit file: C:¥Users¥nemuisan¥.codelite-gdbinit

Current working dir: R:¥STM32H563xxx_NUCLEO_20241101¥lib¥codelite_dbg¥codelite_dbg

Launching gdb from : ../../../

Starting debugger  : C:¥Devz¥arm¥launchpad¥bin¥arm-none-eabi-gdb.exe --command="C:¥Users¥nemuisan¥.codelite-gdbinit" --interpreter=mi "main.elf"

Debug session started successfully!

GNU gdb (bleeding-edge-toolchain) 15.2

Copyright (C) 2024 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later ¥nThis is free software: you are free to change and redistribute it.¥nThere is NO WARRANTY, to the extent permitted by law.

¥nType "show copying" and "show warranty" for details.

This GDB was configured as "--host=x86_64-w64-mingw32 --target=arm-none-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

.

Find the GDB manual and other documentation resources online at:¥n    <

http://www.gnu.org/software/gdb/documentation/>.¥n

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from main.elf...

Output radix now set to decimal 16, hex 10, octal 20.

Remote debugging using localhost:3333

Note: automatically using hardware breakpoints for read-only addresses.

Reset_Handler () at lib/CMSIS/Device/ST/STM32H5xx/Source/Templates/gcc/startup_stm32h563xx.s:59

59¥t  ldr   r0, =_estack

Successfully connected to debugger server

Applying breakpoints...

Applying breakpoints... done

Unable to match requested speed 480 kHz, using 200 kHz

Unable to match requested speed 480 kHz, using 200 kHz

[stm32h5x.cpu] halted due to breakpoint, current mode: Thread

xPSR: 0xf9000000 pc: 0x08053624 msp: 0x20050000, semihosting

Note: breakpoint 1 also set at pc 0x8000252.

Temporary breakpoint 2 at 0x8000252: file src/main.c, line 41.

Continuing...

Temporary breakpoint 1, main () at src/main.c:41

41¥t¥tSet_System();

ううむ…バージョンの違いで起こった現象でもなさそうですしビルド環境の
差なのでしょうか…あとARM公式のはx86版なのが気にかかりますが…
ひとまずはFreddieChopin氏の物を使ってその場をしのぎつつARM公式の
次回リリース版のGDBの挙動を待つとしましょうか…
CodeLiteを使ったデバッグ方法を何とか安定させ正式に公開したいのですが
なかなか手ごわいです…

いろいろ試す62

●Picoscope7のソフトがバージョンアップ！今度こそ安定…か？
すぐフリーズしたり落ちたりでなかなか安定しないPicoscope7のソフトですが
Stable版が7.1.29にバージョンアップしておりました。

今度こそ本当にStableなんでしょうね…！？(どきどき
※会社で現役でバリバリ使用中のPicoscope3206Aで試してます

☝2画面で動かして放置すると固まったorz

…
ファ〇ッッック！！！！！

基本的な操作はだいぶ安定してきましたがちょっと複雑な操作はまだ
安定していないようですね…

というわけで安定して使用できるまでPicoscope6使っていきましょ…。

●arm-gccが久々の更新
Arm GNU-GCCが久々の更新です。
といってもGCC14ではなくまだGCC13のままです…。
13.2->13.3のマイナーチェンジですね。
また、今回はセキュリティ対策のアップデートしております。

同じプログラムをビルドしてバイナリサイズの比較です。
13.2Rel1(前のやつ)

arm-none-eabi-gcc (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)) 13.2.1 20231009

Copyright (C) 2023 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	 479156	      0	 479156	  74fb4	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 477416	   1740	  39668	 518824	  7eaa8	main.elf

main.elf  :

section              size         addr

.text             0x747fc    0x8000000

.ctors                0x0    0x80747fc

.dtors                0x0    0x80747fc

.eh_frame            0x54    0x80747fc

.ARM.exidx           0x98    0x8074850

.data               0x6cc   0x20000000

.bss               0x18a8   0x200006d0

.heap                 0x0   0x20001f78

.ram2                 0x0   0x20040000

.stack                0x0   0x20040000

.ram3              0x824c   0x20050000

.bkpram               0x0   0x40036400

.qspirom              0x0   0x90000000

.comment             0x44          0x0

.debug_frame       0x1e88          0x0

.ARM.attributes      0x38          0x0

.debug_line_str     0x1f2          0x0

Total             0x80b9e

13.3Rel1(新しいほう)

arm-none-eabi-gcc (Arm GNU Toolchain 13.3.Rel1 (Build arm-13.24)) 13.3.1 20240614

Copyright (C) 2023 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	 478396	      0	 478396	  74cbc	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 476624	   1772	  39668	 518064	  7e7b0	main.elf

main.elf  :

section              size         addr

.text             0x744e4    0x8000000

.ctors                0x0    0x80744e4

.dtors                0x0    0x80744e4

.eh_frame            0x54    0x80744e4

.ARM.exidx           0x98    0x8074538

.data               0x6ec   0x20000000

.bss               0x18a8   0x200006f0

.heap                 0x0   0x20001f98

.ram2                 0x0   0x20040000

.stack                0x0   0x20040000

.ram3              0x824c   0x20050000

.bkpram               0x0   0x40036400

.qspirom              0x0   0x90000000

.comment             0x45          0x0

.debug_frame       0x1d98          0x0

.ARM.attributes      0x38          0x0

.debug_line_str     0x1f2          0x0

Total             0x807b7

Flash使用量は減りましたが…、
ううむ若干SRAM使用量増えてますね…。

mapファイルを比較してましたがnewlibでSRAMの使用量が32byteほど増えて
おりました。…まぁこの程度なら許容の範疇でしょう…。

一応STM32H5でlibpngのDecode速度のパフォーマンスを比較してみました。
13.2Rel1

13.3Rel1

あ…ありり…
ちょっとかなり遅くなってる…(脂汗
…
GCC14に期待しましょう～！！

20240826追:
13.3Rel1のGDBはCortex-M33コアでbreakpointが効かなくてデバッグが
できないことが判明しました…(多分バグです)
ひとつ前の13.2Rel1のやつ使いましょう…
20240828追:
13.3Rel1のGDB(GDB14)はちょっと規模が大きいプロクラムになると
breakpointが効かなくなってデバッグが全くできなくなることが
判明しました…orzおそらくGDBのバグっぽい挙動ですがまだ情報が
出そろっていないので今は13.2Rel1のarm-gccを使ったほうが無難です…
どうしてこんなことにorzorz

●組み込み向けのLTO考察
リンク時最適化(LinkTimeOptimization)。ねむいさんは10年位前に使った際に
バグが多くて封印してそれっきりでした。ここ最近はどうなっているのか色々
調べてみましたが、あのころと比べてかなり様変わりしてるのがわかりました。

まずは公式のLTOの解説をしっかりと読みとおすこと。
そのうえでLTOのビルドを成功させるためには幾つかの障壁がありました。

*FONTX2のファイルを直接取り込むincbinと相性が悪い
LTOなしだとビルドできるのにLTOつけるとアセンブラでエラー吐いてこける。
LTOの場合はmakefileがあるところからのフルパスを指定しないといけない。

makefileが存在するディレクトリからの相対パスを指定しなおすことで
苦しみ紛れに屁をこいたような対策ですが何とか対処できました。

*引数も重要
ビルド時に与える引数も"-flto"だけじゃダメになっていて、試行錯誤した結果
以下のオプションを全部追加することでLTOビルドを達成できました。

-flto

-ffat-lto-objects

-fuse-linker-plugin

-flto-partition=none

STM32H5のビルドサイズ比較をしてみましょう
LTOなし

Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 478260	      0	 478260	  74c34	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 476488	   1772	  39668	 517928	  7e728	main.elf

LTOあり

 Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 473372	      0	 473372	  7391c	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 471608	   1764	  39672	 513044	  7d414	main.elf

5kByte弱削減できました。SRAM消費量も微量ながら減ってますね。
もちろんLTOありでもちゃんとプログラムは機能します。
大規模プロジェクトなので効果は感じづらいですがSTM32C0とかの
小規模なプログラムなら削減効果をかなり実感できると思います。

あとリンク段階で変なワーニング出るんですけど対象方法知ってる人いたら
教えてくだち。

●mbedサ終
ついに来てしまいましたね…
ねむいさんもほとんど使用しないままここまで来てしまいましたが
時代の仇花として人々の記憶に残るでしょう…(2026年完全終了)。

ねむいさん的にはオンラインコンパイラは圧倒的に相性悪くてやっぱり
PCで普通にコンパイルするのが身の丈に合っていると感じました。

●STLinkV3はST製以外のマイコンを排斥する！実質STM32専用ｯ！
まぢですか…、OpenOCDからも使えないとは…！
秋月で売ってるやつ買わないでよかった…！
実質STM32以外の他社製のCortex-Mのマイコンのフラッシュ書き込みは
おろかコアにconnectすらできないようです…。

一方で手持ちのSTLink/V2系は大丈夫なのかどうか実際に確認してみました。
使用したのはおそロシアの力でSWIMに無理やり対応させたSTM32F0Discovery
付属のSTLink/V2です…相手は今は亡きLPC810です！

まずはHLAとして接続

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

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/stlink-v2.cfg -c "transport select hla_swd" -f target/lpc81x_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.12.0+dev-00682-gefe902219 (2024-08-12-08:52)

Licensed under GNU GPL v2

For bug reports, read

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

WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg

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

DEPRECATED! use 'gdb target_description', not 'gdb_target_description'

Info : clock speed 1000 kHz

Info : STLINK V2J45S7 (API v2) VID:PID 0483:3748

Info : Target voltage: 2.905861

Info : [lpc81x.cpu] Cortex-M0+ r0p0 processor detected

Info : [lpc81x.cpu] target has 4 breakpoints, 2 watchpoints

Info : [lpc81x.cpu] Examination succeed

Info : [lpc81x.cpu] starting gdb server on 3333

Info : Listening on port 3333 for gdb connections

[lpc81x.cpu] halted due to debug-request, current mode: Thread 

xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc

Info : wrote 3072 bytes from file main.elf in 1.093837s (2.743 KiB/s)

Info : verified 3072 bytes in 0.055933s (53.636 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:01

お次はDAPDirectで接続

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

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/stlink-dap.cfg -c "transport select dapdirect_swd" -f target/lpc81x_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.12.0+dev-00682-gefe902219 (2024-08-12-08:52)

Licensed under GNU GPL v2

For bug reports, read

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

DEPRECATED! use 'gdb target_description', not 'gdb_target_description'

Info : STLINK V2J45S7 (API v2) VID:PID 0483:3748

Info : Target voltage: 2.882555

Info : Unable to match requested speed 1000 kHz, using 950 kHz

Info : Unable to match requested speed 1000 kHz, using 950 kHz

Info : clock speed 950 kHz

Info : stlink_dap_op_connect(connect)

Info : SWD DPIDR 0x0bc11477

Info : [lpc81x.cpu] Cortex-M0+ r0p0 processor detected

Info : [lpc81x.cpu] target has 4 breakpoints, 2 watchpoints

Info : [lpc81x.cpu] Examination succeed

Info : [lpc81x.cpu] starting gdb server on 3333

Info : Listening on port 3333 for gdb connections

[lpc81x.cpu] halted due to breakpoint, current mode: Thread 

xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc

Info : wrote 3072 bytes from file main.elf in 1.219387s (2.460 KiB/s)

Info : verified 3072 bytes in 0.063133s (47.519 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:03

ファームのVerは20240821最新のV2J45S7を使用しておりますが、
STLink/V2のハードウエアなら他社製Cortex-Mマイコンでも大丈夫なようですね…

●そしてぱちもんSTLinkV2にもパチモン対策が
まぁこんなこったろうと思っていましたが、粗製乱造で広まっている中華製偽物
STLink/V2を検知したらシリアル番号を"C"にしてしまうファームウエアが発動
しているようです。
STM32CubeProgrammerではこのシリアルをもつぱちもんSTLink/V2が
使用できなくなります。
OpenOCDからはまだ大丈夫っぽいですがこちらも穴がふさがれそうですね。

ちなみにねむいさんがSTM8マイコンの読み書きするためにおそロシアの力を
使って改造したSTLink/V2はシリアル番号は"C"ではなかったのでセーフでした。
恐らく正規のSTM32マイコンを使用しているか否かで判別しているようですね。

いろいろ試す61(と今年の反省会)

あっという間に年末になってしまいましたね…
残り時間は少ないですが最後まで頑張りましょう～

●ATMELSTARTが新機種のAVR非対応に

ねむいさんはだいぶ前からAVR-DDシリーズも手に入れておりました。
しかし買ってそのまま放置してたのでとりあえず使ってみようと思い、
まずはATMELSTARTで初期コードの生成をやってみようと思ったのですが
AVR-DDシリーズにはもはや対応しておりませんでしたorz

そしてMicorochip社の提供するMPLABなる総合開発環境でコードを
生成する必要があります…

ねむいさんAVRはArduinoすら使わずavr-gccのコマンドラインビルド環境で
プログラム書き込みはavrdude派なのでこんな小規模のマイコンにこんな
糞重い環境使いたくないんですけぉ！！！

う～む微妙だ…

と思案に暮れていたところにMicrochipのgithubを見てみたらちゃんと周辺
機器別のExampleが大量にありましたとさorz
これ参考にAVR-DDのコードをAVR-GCCに当てはめて動作せしめられました。
今回はほんのさわりだけですがAVR-DDシリーズについては来年詳しく紹介
しますのでよろしく！
秋月電子でもAVR64DD28が販売開始でこれは熱くなるかも！？

●Picoscope7のソフトがようやく安定…か？
6から7になって超不安定になってしまったPicoscopeのソフトですが10月に
7.1.13にアップデートしておりました。"Other stability improvements "の
文字列を信じてインストールしてみました！！！

お？

以前のverでは速攻固まって使い物にならなかったI2Cのデコード表示も
ちゃんとできてる！！

と思ったらいろいろいじってたら固まったorz
ううむあと一歩…

全く使えないレベルからだましだまし使えるレベルになってきましたがまだ
安心して移行できる状態ではないですね…
当分の間は6を使っていこうと思います…ていうか私以外にPicoscopeを
使ってる人ほとんどいないのでは…ちょっと波形が見たいけど据え置き型を
出すまでもない状況ではかなり使えるんですけどね～

●いつものの小変更
私のSTM32へのFatFs移植例"いつもの"について、長らくCMSISv5を
使ってまいりましたが今年後半からCMSISv6に移行しております。
で、このCMSISv6ですがNVIC周りで最近結構でかい更新がかかりました。
さらに、CMSIS_v6のその他の変更はこちらにまとめられております。

具体的にはIPというレジスタがIPRに変更になっています。
STM32においては古いペリフェラルライブラリを使用しているSTM32F1と
STM32F4の作例が直撃です(新しいHALライブラリは大丈夫です)。

仕方ないのでこんな感じに修正してお茶を濁しておきました…。
んでもってついでに以下の作例を2024年1月版に更新しております。
STM32F1
STM32F4
STM32F7
STM32H7
STM32L5
STM32H5

STM32L5に関しては今回の更新で完全終了で今後はH5に注力していきます。
H5は精力的に更新していきますので今後ともよろしく！！

●中華液晶追加など
地味ですがねむいさんのいつものの作例中にある液晶ドライバに
2種追加しております。年末なのでついでに紹介しようと思います。

まずはNT39106をコントローラに持つ170x220のQCIFなやつです。

お次はNT39116Bをコントローラに持つ240x320のQVGAなやつです。

これらの液晶モジュールは中華サイトを調べまくったりすでに動作
確認できた品種に似た型番の物から初期化コードを推測して無理くそ
動かしちゃってます。
ここまで来たらもう意地ですがAliexpress見てると次から次に新しい
刺客がやってくるので飽きさせてくれませんね…
こちらも地味に追加を重ねていこうと思います。

●"ペット・サウンズ"で使われてたフォント
電子工作と全然関係ないですがねむいさんはBeachBoysの大ファンで、
PetSoundsは好きなアルバムの一つです。
このアルバムジャケットで使用されていたフォントが今まで何か分からなかった
のですが調べまくって判明いたしました。
それがCooper Blackです！！！
型番シール作成する時はこのフォント好んで使っております。
まぁ完全に個人の趣味ですけどね～

●そして反省会と来年の展望
今年もやろうと思ってできなかったことだらけですが長年後しでやっと
かたづいたやつが１件…
・DropBoxの画像表示問題の解消
　これにつきます。
　5年越しでやっとこ終わりました…長かった…
　このペースでいくと今度は容量問題に立ち当たることになりますが
　その時はその時で対処していきたいなと思います

そして今後やるべき事柄ですがこれは２件…
・ARM開発環境の整備
　特にかつてデバッグで使用していたInsightはWin10以降で使用不能に
　なってしまいましたので現在CodeLiteによるデバッグ方法を確立して
　いる最中となっております。
　2024年中にはわかりやすくなおかつ安定してデバッグできるような
　手順書の作成を進めてまいります。

・AVR関連の記事の増強
　これ最近になっていろいろ問い合わせいただくようになってきました。
　UPDIを使用する新しいタイプのAVRの使用記や書き込みソフト"avrdude"
　についての記事の需要が非常に高まっていると感じます。
　ちょうどAVR-EA/EBも出てさらにAVR-DUシリーズも登場の予感が出て
　来ましたのでちょっとAVRにもがむばってみようと思います。
　せっかくなのでついでにXMEGAの作例も2024年版に更新してみました。
　かつて一度は捨てたはずのマイコンですが再びこうやって相まみえる
　とは運命を感じますね…

てわけで上記2件を来年の目標に記事の充実と整備を続けていこうと
思います！今後ともよろしくお願いします。

いろいろ試す60

いろいろ試してきてついに60回を迎えてしまいましたが
ほんっと大したことやってませんね…

●ぶろぐの画像の修正すべて完了の件
2016年からはや7年も経過してしまいましたがdropboxの仕様変更のあおりを
受けて表示できなくなっていた画像ですがすべて修正が完了致しました！！

長かった…一番しんどかったのは東海自然歩道や登山関連の超大量の
画像の差し替え作業でしたがなんとかすべてこなすことができました…
もう10年以上前になるものもあって本当に年月を感じ…
あああああああああああああああああああああ！！！！１１１！！！１

現在はEDGEで見た際に表示が崩れないようにレイアウトの修正を細々と
行っております。
ゆくゆくはwordpressに移行を考えておりますが…何年後かな…？

●Windows10以降対応の64bit版FONTX2コンバータ作りました
FONTX2は現在では電子工作で大人気のフォントフォーマットです。
詳しい解説はおなじみChaN師のサイトでもされており参考になります。

ところで現在Windowsで使われているTrueTypeフォントからFONTX2ファイルを
作成したい場合はかつてはWFONTXという非常に便利なツールが存在して
いたのですがこれはWindowsNT3.1用の代物で、64bitOSが全盛の現在では
動作させることができません。

そこでねむいさんが64bitOS対応のWFONTX64を作成いたしました！
これはオリジナルからXPに対応されたすん様のWFONTX32をベースとしております。
ねむいさんが見つけた細かいバグ等も修正し使い勝手を多少上げました。

☆使い方☆

まずはプログラムを開いたところです。
ここではねむいさんの最近のお気に入りの小夏フォントを12x12pixelの
FONTX2化する例を挙げます。

注:あらかじめ小夏フォントをインストールしているのが前提です！

ドロップダウンメニューから"小夏等幅"を選択します。

次に高さと幅をピクセル数で指定します。ここで注意ですがたとえば12x12で
表示したい場合はHeightに12,WidthにHeightの半分の6を指定します。

Widthに12をしてしまうと横長になっちゃいます。
12の半分の6を指定してください。

"FontX2 Name"の欄にはFONTX2のヘッダを指定します。FONTX2の仕様上8文字
以上は指定できません(8文字以上入力できないようにしてます)。
ここではKONATHNとします。
また、FontX2Typeは半角の"Ank"を指定します。

Save Nameの欄は生成されるファイル名を指定します。
KONATHN12.FNTとします。

ここまで入力したら"RUN"と"NO STOP"が押せるようになります。
"RUN"はダイアログに1文字ずつ表示しながら変換(遅い)、"NO STOP"は表示
せずに一気に変換します(早い)。

変換が終わるとKONATHN12.FNTが生成されます。
生成されたのはFONTX2の中のAnkフォントで半角のAscii文字だけが
格納されてます。漢字などの2バイト文字は全角用の生成操作が
必要です。

お次は2バイトの全角です。ラジオボタンをAnkからKanjiに変え、
Save NameはKONATZN12.FNTとしましょう。

これで半角・全角のFONTX2ファイルが無事生成されました！

で、こいつをねむいさんのいつものに組み込んでSTM32H5使ってTFT-LCDに
FONTX2ドライバを使って表示できました。

こんなわけで30年の時を超えて現在でもお手軽にマイコンで好きな文字が
お手軽に表示できるようになっております。
また、生成したFONTX2ファイルを含むソースコードの再配布の際は元の
フォントのライセンスに注意し、それに従ってください。

●avrdudeがv7.2になっていた
亀のような更新速度だったころから比べると日々増殖する小宇宙状態と
なっているavrdudeですがいつのまにかv7.1->v7.2に進化しております。

紹介しきれないくらい機能がアップしておりますので特に細かい不具合が
つぶさに修正されておりますので特に理由がない場合以外はv7.2に乗り
変えましょう。

ねむいさんもVerupのスピードに振り落とされないようにしがみついており、
おきぱでも常に最新のavrdudeのwindowsバイナリを公開しておりますので

よろしくお願いします！！

●CMSISもv6になっていた
10年ほどの間CMSISはver5のままメンテが行われておりましたが今年の
春くらいからver6に移行しております。

大まかな構成は変わっておりませんのでそのまま置き換えてビルドが
可能になっております。

この記事を書いてる現在では修正されましたがGCCでコンパイルした際に
"#pragma clang system_header"が引っかかってワーニングが出まくる
事態となっておりましたが10月末にようやく修正されました。
おきぱで紹介しているいつものたちはその修正されたものを適用してますので
こちらもどしどしご利用ください！

●そのGCCも13になっていた
そしてGCCも12から13にバージョンアップしておりました。

arm-none-eabi-gcc (Arm GNU Toolchain 12.3.Rel1 (Build arm-12.35)) 12.3.1 20230626

arm-none-eabi-gcc (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)) 13.2.1 20231009

ねむいさんのSTM32H7-Discovery向けプロジェクト"いつもの"のバイナリサイズを
比較してみましょう。

GCC12

Built Informations:

USING_SYSTEM = BARE_METAL

USING_DISPLAY = USE_OTM8009A_DSI_TFT

USING_DEVBOARD = USE_STM32H747I_DISCO



Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 709212	      0	 709212	  ad25c	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 707324	   1888	2384060	3093272	 2f3318	main.elf

main.elf  :

section               size         addr

.text              0xac840    0x8000000

.ctors                 0x0    0x80ac840

.dtors                 0x0    0x80ac840

.eh_frame             0xb0    0x80ac840

.ARM.exidx            0x98    0x80ac8f0

.itcm                0x174          0x0

.data                0x760   0x24000000

.bss               0x11f2c   0x24000760

.heap                  0x0   0x2401268c

.dtcm                0x20c   0x20000000

.stack                 0x4   0x2000020c

.ram1_d2               0x0   0x30000000

.ram2_d2               0x0   0x30020000

.ram3_d2               0x0   0x30040000

.ram4_d3               0x0   0x38000000

.batram                0x0   0x38800000

.extram           0x233f80   0xd0000000

.qspirom               0x0   0x90000000

.comment              0x45          0x0

.debug_frame        0x1f7c          0x0

.ARM.attributes       0x30          0x0

.debug_line_str      0x1f4          0x0

Total             0x2f54fd

GCC13

Built Informations:

USING_SYSTEM = BARE_METAL

USING_DISPLAY = USE_OTM8009A_DSI_TFT

USING_DEVBOARD = USE_STM32H747I_DISCO



Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 709868	      0	 709868	  ad4ec	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 707980	   1888	2384060	3093928	 2f35a8	main.elf

main.elf  :

section               size         addr

.text              0xacad0    0x8000000

.ctors                 0x0    0x80acad0

.dtors                 0x0    0x80acad0

.eh_frame             0xb0    0x80acad0

.ARM.exidx            0x98    0x80acb80

.itcm                0x174          0x0

.data                0x760   0x24000000

.bss               0x11f2c   0x24000760

.heap                  0x0   0x2401268c

.dtcm                0x20c   0x20000000

.stack                 0x4   0x2000020c

.ram1_d2               0x0   0x30000000

.ram2_d2               0x0   0x30020000

.ram3_d2               0x0   0x30040000

.ram4_d3               0x0   0x38000000

.batram                0x0   0x38800000

.extram           0x233f80   0xd0000000

.qspirom               0x0   0x90000000

.comment              0x44          0x0

.debug_frame        0x1d1c          0x0

.ARM.attributes       0x30          0x0

.debug_line_str      0x1f4          0x0

Total             0x2f552c

あれ…なんかバイナリサイズが600Byte近くも増えてるような…

と、とりあえず速度比較もしてみましょう
jpegファイルのデコード速度を比較します。-O2でコンパイルしました。

GCC12:(236704uSec)

GCC13:(237486uSec)

…
あ…あれ…結構遅くなってる…！？

ま、まぁ多分何かの安定性が上がったかもなのでよしとしましょう…
(脂汗)

いろいろ試す59

●STM32L1とSTM8シリーズがNRNDになってしまった…

ほら言わんこっちゃない…温めすぎて腐ってしまいました…orz
STM8シリーズはもう少し進めたかったのですがSTM32C0が登場して
既存の8ビットはエコシステムから排除され駆逐される勢いとなって
しまいましたね…STM32L1のほうはSTM32L0,STM32U5とかが登場した
のでお役御免となった感じでしょうか…
今のラインナップを鑑みるにねむいさんが使ってきたSTM32F2やF4,
L4,L5とかも次のNRND候補になっちゃいそうですね…
まぁこれも時代の流れということで…とにも書くにもSTM8Lに関しては
最後っ屁で一件記事書いてクローズとさせてもらおうとおもいます…！

●STM32F4のHALじゃなくてSPLがアップデートしていたが…
2022年にHALライブラリじゃなくて古のStandardPeripheralLibraryが
アップデートしていたようです…内容は…

余計なことするな～～！
GPIOのレジスタ周りは致命的だったのでここだけ元に戻してアップデート
いたしました…

●ILI9341をシリアル接続で動かした際にDeviceIDを読み出す方法
10年前に一度記事を書きましたが10年の時を超えて皆忘れてしまってる
ようなので改めて詳しく解説しようと思います。

ILI9340,ILI9341,ILI9342のILITEK製のTFT-LCDコントローラはDeviceID
をそれぞれ持っておりそれらの読み出しコマンドは"0xD3"を使用します。

尤もi8080などのパラレルなデータバスの読出しはデータシートの
通りに従えば期待していたDeviceID(ILI9341なら0x9341)を読み出す
ことができます。しかし、SPI(以下シリアル)バス接続の場合は何故か
この通りにやっても絶対に読み出すことはできません。

これについては10年以上前から様々なコミュニティで話題が上がって
おりますがシリアル接続では独特の手順をもってしないと読みだす
ことができません。

ILI934x系のコントローラはシリアル接続でレジスタの値を読み出す
ためにはデータシート未記載の"undocumented"なレジスタにアクセス
する必要があります。それがRegisterReadIndex(0xD9)です！

使い方は以下の通りです。ReadID4コマンド(0xD3)を実行してシリアル
接続でDeviceIDを読み出す手順です。

/**************************************************************************/

/*! 

    Read ID ILI934x.

*/

/**************************************************************************/

static uint16_t ILI934x_rd_id(uint8_t cmd)

{

	uint16_t val;

	uint16_t temp;



	ILI934x_wr_cmd(0xD9);						/* SPI Register Read Command */

	ILI934x_wr_dat(0x10);    					/* Read Mode Enable,1st Byte */

	temp = ILI934x_rd_cmd(cmd);					/* Dummy Read 	*/

	

	ILI934x_wr_cmd(0xD9);						/* SPI Register Read Command */

	ILI934x_wr_dat(0x11);    					/* Read Mode Enable,2nd Byte */

	temp = ILI934x_rd_cmd(cmd);					/* Dummy Read 	*/

	

	ILI934x_wr_cmd(0xD9);						/* SPI Register Read Command */

	ILI934x_wr_dat(0x12);    					/* Read Mode Enable,3rd Byte */

	temp = ILI934x_rd_cmd(cmd);					/* Upper Read 	*/



	ILI934x_wr_cmd(0xD9);						/* SPI Register Read Command */

	ILI934x_wr_dat(0x13);    					/* Read Mode Enable,4th Byte */

	val  = ILI934x_rd_cmd(cmd);					/* Lower Read	*/



	val &= 0x00FF;

	val |= (uint16_t)temp<<8;



	return val;

}

☝こんな感じでインデックスを一つずつ指定して読みだしていきます。
　このようなかんじでシリアル接続でもDeviceIDを読みだせます。

なんでデータシート未記載なんだYO！とお思いの方もいらっしゃる
でしょうが、実は近年にリニューアルされたデータシートにはちゃんと
記載されてやがったりします。これはILI9342"C"のデータシートです。
もちろんILI9342無印では記述がありませんでした。

また、同様のアクセス方法としてはILI9486Lも同機能のコマンドが存在
しております。てか"DGAMCTRL (Digital Gamma Control 2)"とかなってて
でたらめでめっちゃ適当ですね…

さらに今年判明した衝撃の事実ですが128x128サイズを主にサポートする
ILI9163系のコントローラも0xD9を実行すると不可能だと思われていた
シリアル接続のDeviceIDを読み出し可能なことを確認しました！！
ソースコードに上記のように反映しております！

という感じで定期的に持ち上がるILI934x系のネタですがシリアル接続で
この液晶を使うシーンが極めて多いので情報としてしっかり残して
おこうと思います！
最も昨今はST7789Vx一族にだいぶ押されておりますがー！

これらの成果物は主におきぱにあるSTM32F4のFatFs移植作例に収蔵
されております。プロジェクトの下記ドライバを参照してください。
./lib/display/drivers/src/ili934x.c(ILI9342を除く)
./lib/display/drivers/src/ili9342.c
./lib/display/drivers/src/ili9481.c
./lib/display/drivers/src/ili9163x.c

●新液晶モジュール続々登場！
液晶モジュールつながりでもう一件です。

超久しぶりですがこの前ST7789V2にも対応したついでに新たに買った
中華TFT液晶モジュールをいくつか紹介させていただきます。

こちらはなななんと5inchで540x960pixelでi8080データバス対応という
今までで最大サイズの液晶モジュールです！！！！！
コントローラはNT35516という品種です。
480x854が今までの最大サイズだったので大進化ですね～

で、動かそうとすると結構癖があった…
データバスが外来ノイズに弱くてすぐ崩れるのでねむいさんのいつもの
に合わせるのに結構苦労しましたがなんとか安定動作できるように
なりました。それにしても540x960は広すぎる…

ついに(叢雲のコスプレをした)いないさんの全身が見切れせずに
表現できるように！！やった！！

とはいえ静電性タッチパネルが装着されたモデルがまだAliexpressに
登場してないのでメインで使用する段階ではないです…

やっぱしILI9806Gなこいつが一番使いやすいですね…！

お次はHX8363Bをコントローラに持つ3.97inch,480x800な現在では
定番サイズの液晶です。こちらもタッチパネルなしです。
ていうかなんなんだ真ん中のシールは。

このコントローラはちょっと癖があって8/16bitのインターフェース
を決定する設定は外部に出るピンではなくレジスタに入れる値で決定
します。これ10年以上前に使用したS1D19122に似てますね～

動かしたところです。
まぁ可もなく不可もなくといったところですね～

やっぱしILI9806Gなこいつが一番使いや(r

こちらはR61408が使用された3.97inch,480x800のものです。
FT5216の容量性タッチパネルコントローラがついたタッチパネル
つきになっております☆

最近に販売されている中華液晶の下駄基板はパタンでお絵描きしたりが
なくなって殺風景なのでちょっと寂しいですね…一応RGB/8bit/16bit
そしてI2Cまで使用可能です。R61408のシールは私が貼りました。

動かしたところ。
かなり発色が良いですね～

でもやっぱしILI9806Gなこい(ry

んでもって10年くらいまえのりべんぢですがNT35510のまともな奴が
手に入りましたので動かしてみました。
サイズは定番の3.97inch,480x800です。

こちらも発色がなかなかでした…以前はまともに表示できなかったので
10年越しにりべんぢできたかんじですね…!

最後にRM68180が使用された3.97inch,480x800のモジュールです。
FPCコネクタ接続でインターフェースは8bitという速度的に苦しい
ものですがはてさて

かなり苦労しましたが何とか表示できるようになりました。
RM68120のコードとほぼ同じなのでrm68120.cと同居しました。

というわけで最近久しぶりに入手したTFT液晶モジュールを一気に
紹介しましたが現時点では使いやすさ、安定性、表示領域の面を
鑑みるとILI9806Gなこいつが鉄板と言わざるを得ませんね。

NT35516のやつがもうちょっと頑張ってくれたらよいのですが、
これから先も当分の間はILI9806G使ったやつのお世話になりそうです。

いろいろ試す58

●ブログ画像の復活状況について
ねむいさんのブログではDropBoxを画像用サーバとして活用して
おりますが、さる2016年にDropBoxの仕様が変わって直りんが出来なく
なってしまい2012~2016年途中までの画像が見えなくなっておりますが、
悪いことに最初期の2009~2012年ごろのOneDriveの画像も表示できなく
なってしまいましてこちらの対応にも手を焼いております…

現在は2010年分まではOnedriveからDropBoxに移動して再び表示できる
ようにしておりますが膨大な作業量なので皆様首を長くしてお待ち
願います…。ああ先は長い…

●Picoscope7がアップデートされたが…
先月、Picoscopeのソフトウエアが6から7にメジャーバージョンアップ
されましたが、不安定で使い物になりませんでした。
今月に入って7.1.2にバージョンアップされて多少は安定したかな？
と思ったのですが…

I2Cなどのシリアルデコーディングをプリセットされたファイルを
ダブルクリックして起動したらすぐ固まってプログラムが落ちて
しまいました…orzダメじゃん！！
というわけで安定して使えるようになるまで6の最終版使いましょ。

●STM32用I2Cタイミングレジスタ計算機アップデート
自分用に作ってきたSTM32向けI2Cレジスタ計算機ですが細かい修正を
加えて現在はGithub上で管理をすすめております。

今回は固定値扱いしてきたTrise,Tfallを自由に設定できるようにしました。
デフォルト値は100,10としました。単位はnsecです。

計算機のコアの部分はSTM32U5のプロジェクトにあるI2C計算機をベース
としておりますが、nomalmode(100kHz)のTriseが640nsecに設定されていて
ちょっとおかしい(波形も)のでSTM32F3&STM32F0向け計算機の値を準拠と
しました。

うーむぴったりの値にならないばかりかちょっとクロック周波数が
どうしても遅めに出てしまう傾向がありますね…
なお、CubeMXも同じ傾向があるので細かいところを突き詰めたい方は
ツールでざっと算出して残りはオシロとにらめっこして突き合わせて
行くのがよいでしょう。っていい加減な私。

●STM32でI2C(マスター)が動…かねぇ！！！１！
I2Cバスは昨今の電子工作でセンサや表示デバイス等で多用されている
インターフェースの一つですが、STM32もI2Cをハードウエアレベルで
サポートしております。しかしSTM32でマスターとして使用する際には
下記の大きな注意点があります。

①STM32はI2C基本的にスレーブデバイスとして動いている。
②初期化の手順を間違えるといきなりBUSYフラグが立ってしまう。

①についてはSTM32の全種のリファレンスマニュアルに明記されて
おります。スタートビットを自ら生成することによってマスターに
切り替わることになります。
データのやり取りが終わったら自動的にスレーブに戻ります。

で、このスレーブとしての動作中に外部からスタートビットに相当
する信号が偶然生成されてしまうとBUSYフラグがおっ立ってしまう
ということになります！！！！

これは内部操作からにも波及し、②の状態が成立してしまいます。
つまりGPIOの操作をするだけでBUSYフラグがおっ立ってしまうわけです。

②の間違った手順の具体的例とは、使用するI2CのGPIOポートのAlternate
Functionをする前にI2Cのクロックを有効にしてしまうことです。
これをやるとSTM32F1,STM32F2,STM32F4では100％の確率でBUSYフラグが
おっ立ってしまいます…もうビンビンに…！

実際にBUSYフラグが立ってしまった画像です。
STM32F411-Nucleoで確認していますがI2Cのクロックを有効にした
後にGPIOの設定を行うとI2Cの設定を何もしてないのにSRレジスタが
2(BUSYフラグON)になってしまいます。

そんなわけでBUSYフラグをおっ立てずにI2Cを確実に動作させる手順は
以下のようになります。

1.GPIOクロック有効
2.GPIOの設定(AF含む)
3.I2Cのクロック有効
4.I2Cの設定

上記順番を守るといきなりI2Cが動…かねぇ！という悲劇の発生確率が
下がると思います。特にバグコード生成器のCubeMXを使う際は生成
コードがこの順番を守っているか確認し、さらにオシロスコープで
実際のI2Cバスの波形を必ず確認するようにしてください！！！

ちなみにSTマイクロの日本サイトも初期化順番の注意点にとして
同じような記述があります。

私の知る限り誤った手順でBUSYが立ってしまう品種はタイミングレジスタの
記述が簡素なSTM32F1,STM32F2,STM32F4,STM32L1のみとなりますが、
確実な動作のために他の品種でも上記初期化手順を守るべきだと思います。

いろいろ試す57

GWは北陸出張と雨でどこにも行けなかった…！！！
気力があるうちに貯めたネタを吐いていきます…！

●OpenOCDにちょっと困った変更
ねむいさんのOpenOCDを使った書き込み手順では従来elfファイルを
指定して書き込み/ベリファイを行っておりました。しかし…
一部の方は気づいたかと思いますがOpenOCDでこのアップデート
がマージされて以来一部のelfファイルの書き込みができなくなって
しまいました…

具体的に言うとSTM32H7の作例のようなRAMの割り振りをしていて
BSS領域とデータ領域が別々に存在したり起動後にITCMにコードを
置くような使い方のプログラムが全滅です。

具体的にはこうなります…余計なことしやがって…F〇CK!!!
しかもフリーズ…

対策ですがelfの代わりにhexファイルやアドレスを指定して
binファイルを書き込んでやればいつも通りに書き込みとベリ
ファイが可能です。もちろん書き込み後は普通に動作します。

デバッグに関しては普通にelfファイルを指定しこちらは問題
なくデバッグが可能です。

私のARM開発環境まねされてる方は上記対応をお願いいたします。
ちなみにこのコミット、やっぱり方々から不評が出ているようで
差戻しの提案が出ております･･･早く元に戻して…!

20230514追:
差し戻しパッチ適用しました！！
普通にelfファイルでフラッシュ書き込みできます！！！

●ARM-GCCアップデート
ARM-GCCも2023年版にアップデートしております。
メジャーバージョン12->13を意識したものになっています。

arm-none-eabi-gcc (Arm GNU Toolchain 12.2.Rel1 (Build arm-12.24)) 12.2.1 20221205

↓

arm-none-eabi-gcc (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build arm-12-mpacbti.34)) 12.2.1 20230214

アップデート内容はCortex-M85とCortex-M PACBTI extensionやらの
サポートだそうですが私が気付いた最大の違いはC++の例外処理に
関するコードが挿入されていることです。

具体的にはeh_frame,ARM.exidxに相当するコードが挿入され、若干バイナリ
サイズが増加しております。ARM.exidxとか10年以上昔からありますが
コードが追加されています…ていうかこちらが本来の姿だったのでは…

仕事ではmbedOSでC++バリバリ使っているのでないがしろにできないので
注視していこうと思います。

また、おきぱのFatFs移植例でLTDCを使っているSTM32F7,STM32H7について
従来最適化レベルを"-Ofast"で行っておりましたが無駄にサイズが大きく
なり過ぎているのとlibpngデコード時に画面が激しく乱れる副作用が
GCC12に上がったころから出てきてしまいましたのでSTM32F4の作例も含め
スタンダードな"-O2"にして提供することにしました。

●おきぱのプログラム大更新
STM32系のメンテを続けているSTM32系のFatFs移植例の大更新を
行いました。メインは以下の箇所です。
1. C++で禁止されている"__(ﾀﾞﾌﾞﾙｱﾝﾀﾞｰｽｺｱ)"で始まるマクロや定義
　およびコーディング規約に反する一部の変数名の修正
　->このポカミス思いっきり全弾ヒットしていましたorz

　↑こういうやつ
　　 STM32Primer2の件でちょこっと触れたやつですね。
　　特にインクルードガードに関してはほぼ全部ダブルアンダー
　　スコアやらかしていましたので全部修正してやりました…はぁはぁ。

　　識別子についてはこちらの方の解説もわかりやすいです。

ChaN'師のFatFsは数年前すでに対応済みでしたね…ｻｽｶﾞﾀﾞｧ…

2. タッチパネル入力で押しっぱなしで連打機能
　->タッチパネルで該当するキーを押して一定時間後連打するやつです。
　　この機能はもともとはタッチパネルに一回ちょっと触れただけで
　　複数回押されてしまうことになっていたバグの修正からで、ついで
　　だから入れようということで追加しました。

　　ただし↑と↓だけ機能します。それだけでもすごい楽ですね。
　　該当コードは¥lib¥display¥abstract¥src¥touch_if.cの230行目
　　以降を参考にしてください。

　　これも"ねむいさんのプログラムってタッチパネル入力だけ雑"
　　って10年間くらい言われ続けていましたがやっと重い腰が上がり
　　ました。そして安心して座れる…。

また、下記のi2cデバイスの動作を絡めたexampleも超大改版を行い
ましたが、これに関しては内容が多すぎるので次回に委ねます。
先に公表しておきますが改変したプログラムは下記になります。
・STM32F03x
・STM32G03xxx
・STM32C03xxx
・STM32F401,F411

●STM32向I2Cタイミングレジスタの値計算機作った
STM32F0以降のI2Cはレジスタの構造が一新されてしまいクロック生成に
超めんどくさい計算式が必要でそれをタイミングレジスタに入れる
ようになってしまいました。一応計算用のエクセルファイルが配布
されていますがF3までしかサポートしてなくて使いづらいので…
自分で作製しました。

・使い方

まずexeを立ち上げます。デフォルトでI2Cカーネルクロック48MHz,I2C
のクロック周波数は100(KHz)が設定されております。
I2Cのカーネルクロックは上限400MHzまで設定可能、I2Cクロックは100kHz,
400kHz,1000kHzの3種類だけです。それ以外を設定すると計算結果が0に
なるステキ仕様となっております。

ひとまずKeisanボタンを押すとタイミングレジスタに入れる値がポンと
出てきます。

これを自分のプロジェクトのI2Cの設定時にコピーペーストしましょう。

・精度は?

(※STM32C0-NUCLEOの作例です)
ぁららー(脂汗)
う～んまぁいいんじゃないでしょうか…
すみません適当のやっけつ仕事で…

ちなみにSTMicroが提供しているi2c_timing_utility.cの計算時の定数値
のtriseの値が変な値になっていて実際に波形もへんてこりんなものに
なっていましたのでエクセルファイルの値準拠に変えて計算しています。

STM32F0,STM32F3,STM32G0,STM32C0で確認しましたのでたぶん大丈夫だと
おもいます…

●PicoScopeのソフトが大変更！メジャーバージョンが7に！
読んで字のごとくです…長らくbetaバージョンだったのがついに
メジャーリリースとなったのでねむいさんも乗り換えたのですが…

あのさぁ…特殊なトリガかけようとしたら何度やってもすぐプログラム
落ちるんですけぉ！１１１１！！１１！！１！
今まで6を使ってそれのUIに慣れてしまったのですっっっっっっっごい
使いづらいうえにbuggyとかやめてください…

で、やっぱり苦情が多かったのか前バージョンの6のソフトもダウン
ロードできるようになっております…もっと7が安定化するまで当分6
で運用ですね…。

いろいろ試す56

ぁーGWですね～…
出張疲れでなんもやることないので今まで貯めてきたUSBシリアル
変換で嵌ったチョイネタを公開します。

●USB-シリアル変換のRTSとかの制御タイミングは結構適当？
　いいえ、ねむいさんの脳みそが適当(仕様)
ねむいさん副業(本業は二次裏メイド)でHalf-DuplexなRS485の
ちょっとした基板を製作しておりました。

MAX485データシートから抜粋と追加。
_REとDEを一つにまとめ、HIで送信、LOで受信に切り替えます。
そのような仕組みなので何らかの方法で入力と出力を切り換えないと
いけないのでRS232-Cの規格に存在するRTS信号出力を手動で切り
変えて送受信を制御してやろうと思ったのですが…

…うまく動かない…
なんか送信がぶつかってるような…
最初FTDIのやつ使ってたのですが通信できたりできなかったり
そんでProlificのやつ使ったら全く通信できにゃい！！！
ぬがああああああ！１１１！！！１！！

というところでようやくオシロスコープを引っ張り出して波形を
確認することにしました。ねむいさんいつも他人にはオシロで
ちゃんと波形確認しろと言っておきながら自分もめんどくさくて
やってない。

まぁそれは置いといて実際測定してみるとなんでか分かった。
まず検証に使ったソースコードですがVC++で適当にプロジェクト
作ってCreatefileでCOMポート開いてその際にDCB構造体のfRtsControl
に"RTS_CONTROL_TOGGLE"を設定しておきます。
これでWrite関数を実行、具体的には送信したい文字列を…
今回はDAAAAAAAAA¥r¥nというゼEROみたいな文字列を1秒ごとに
吐き続けるやつで検証してみました。

イケてるとき。
信号レベルはTTLレベルなので反転前なので注意してください。
ここで見るべきは文字列送信終了後にRTSが変化していることです。
でも1.5mSecもかかって信号レベルが遷移している・・？

イケてないとき。
なんと試行して数回目で発生した！！
送信し終わってないのにRTSが戻ってる！！！！
こりゃだめだ…。

RTSの信号をEscapeCommFunction関数で手動で変えてみたりしましたが
文字列送信中にRTSが受信方向に変化しやがったり逆に何mSecも戻
らなかったりもうぜんっぜんだめ…

もう疲れたのでFTDIの奴は置いといて今度はProlificのチップ
使ったUGREEN製のUSBシリアル変換ケーブルで試してみました。

注:信号レベルはRS232なので注意。それと時間レンジに注目！
おいいいいいいいいいいいいいいいいい！！１！！１！！！！
Open関数を実行したとたんRTSが立ちっぱなしになってもとに
戻らなくなってしまいました(COMポート閉じるまでこのまま)
お前なんなんだYO!

これはいけない。

ということでネットの海にダイブしていろいろ調査していると
ねむいさんと全く同じ状況に陥っている方がいました。
西村備山様の"滴了庵日録"の下記ブログ記事にはねむいさんと同じように
文字列を送り終わる前にRTSが変化しているのがわかります。
・FTDIのUSBシリアルの不具合？

また、さらに調査されていてHalf-DuplexでRS485をやりたい人は
TXDEN信号を使えばいいとのことです。
・PCのCOMポートをRS485に接続する

なぜRTSが適切なタイミングで変化してくれないのか、USBの規格や
仕様を考えたらすぐ分かる話なのですが物理COMポートはuSec単位で
反応できる一方、USBでは最速でも1mSec(USBフルスピードで)の
"フレーム単位"ごとにしか状態を変えられないことにあります。

20240829追:
HuMANDATA様がFTDIのRTSの制御線の遅延を検証されております！
必見です！！！！
20240829追:

また、西村様の上記記事の最後にFTDIのドライバでRTSがうまく
変化してくれないと言及されておりますが我らがProlificに
至ってはおそらくOpenFile(COMポート開いた)のタイミングで
RTSがいきなりビンッビンにおっ立ってしまい、もう治まり
そうにありません！！1！！もう許ちて！！！！

…すみません下ネタに近いこと言ってしまいましたが西村様のブログ記事に
倣い、FTDI系では方向制御にTXDENを使用することにしました。

うーむ完璧！USBシリアル変換でRS485でHalf-Duplexな通信
したい人はFTDIならTXDENを使えば良いですね。なんだかんだ
言ってFTDIが一番安定して使いやすいですし。

ちなみに秋月で販売しているCH340Eシリアル変換もTXDENに相当する
制御用ポートがあります。

秋月電子のデータシートより抜粋。
CH340EにはTNOWという端子がありこれがTXDENに相当します。
こいつを引っ張り出してあげましょう。モジュール上にはちょうどR4が
TNOWに付いてて半田もしやすいですね。

うーむこれも完璧☆

今を時めくUSBType-Cコネクタで何より安いのでこれは使い勝手良いかも！？

え、肝心のProlificはどこ行ったって？
ありゃだめですよぅ…(もはや測定する気力がない)。

20231103追：
HumanData様のサイトにRTCをトグルした際の遅延を測定した
データがあります。非常に参考になりました。
やはり2~3mSecの遅延があるようですね…
https://www.hdl.co.jp/USB/jkn016/
https://www.hdl.co.jp/USB-001/usb001-t4.html

●CP2102のぱちもん
前々回DS18B20のぱちもんを紹介しましたが中華製ぱちもん半導体の
勢いはとどまることを知らない。過去にFTDIの偽物が出回ってそれ
つぶすドライバが配布されて大混乱になりましたが、駆け込み寺で
使用されたSiliconLabs製のCP2102にもぱちもんが蔓延していた
ようです。

2017年にアメリカのMAKER系イベントで配布された名札代わりの
ボードの中に使用されていたUSBシリアル変換IC(CP2102)に偽物が
混ざっており動作せず人海戦術で対応に当たったという事象が
ありました。

なおこのぱちもんCP2102はUSB-TTL(3.3V出力付き)Breakoutボード
としてAmazonやebay,Aliexpressでも蔓延しており、見分け方が
提示されておりました。

さらに調べるとロットNo.と思われる部分に"DCL00X"と刻印されてる
奴はぱちもんのようですね。
さらにその基板はReset端子がVbus(+5V)直結になっているため、
Reset端子から電流が流れ込み+3.3Vラインが+4Vとかになってると
思われます。一応全端子5Vトレラントのようですがデータシートの
説明にはVDD(内部3.3Vレギュレータ)に4.7kohmでプルアップせよ
と明記されてますね。
抵抗じゃなくてヒューズがついてるのはOKとかそうではなくこの
パチモンCP2102使ったぱちもんモジュールを使うのを避けたほうが
いいですね…

ところで私の持ってるCP2102は大丈夫なのか！？調べてみました。

DOIT-AM製のESP32-DevKit-Cです。
DCL00Xじゃなくてとりあえず安心…

ESPRESSIF製のESP32-DevKit-C-VE
CP2102Nでした。多分大丈夫でしょう。
ESP32-DevKit-C-VE

ESP32-S3-DevkitC-1
こちらもCP2102Nでした。

今現在CP2102が実装された基板はESP32系だけでした。DOIT-AM製の
2016年末くらいの奴は怪しいかなと思ってたのですが回路図見たら
ちゃんとデータシートの言いつけを守っておりました…ｻｽｶﾞﾀﾞｧ…

因みにDOIT-AM製初期のDEVKIT-Cと秋月で購入したESP32-WROVER-E
を使用したESP32-DevKit-C-VEにはADP3338に交換済みです…！！
一方最新のESP32-S3-DevkitC-1に使用されているLDO、SGM2212は
ADP3338には及びませんがVdrop最悪値が0.6Vなのでまぁ使える
レベルにあると思います。

●UGREEN製のUSBシリアル変換を改造してみた
最初のRTSの件で使用したUGREEN製のですがRS485変換には使い物に
ならなかったのでとりあえず分解してみました

結構な化粧箱に入っておりました。921600bps対応とか抜かして
ますがもちろんそんなボーレートで通信できませんでした。

とりあえず殻むきして中身を出してみます。
よくあるDsub9Pinのコネクタを利用した基板直付けタイプですが…
なんかずれてて隣のパタンとショートしそうになってました！！

Dsub9pinコネクタを外してみました。金メッキとか抜かしてました
が外から見える部分だけ金メッキでした…びんぼっちゃまくんかな？

Prorific製ICはPL2303TAが使用されていますがこのチップ、すでに
ぱちもん対策で廃版になっておりPL2303Gが最新です。
ねむいさんPL2303Gが使用されてると抜かしてたので買ったのですが
まぁチャイナリスクってやつです(12年ぶり2回目)

信号レベル変換ICはZT213LEEAなるものが使用されています。
MAX212系のRS232Cレベル信号変換のICの中華版でしょうか。

データシートを見るとMAX250kbps...
ねむいさん921600bps対応って抜かしてたので買っ(ry

とりあえず先ずは使い勝手を良くしちゃいましょう。
これからシリアル番号をつけて同じPCのどこのUSBポートに
挿してもCOMポートが固定されるように改造します。

PL2303TAのデータシートは外付けEEPROMは24C02を要求してますので
これをつけてやります。

ついでに空いていたD1に青色LEDつけちゃいます。

さらにどっかから拾ってきたEEPROMWriterでシリアル番号の書き換えに
成功です！やったぜ。

基板を覆っていたモールドは取り出し時に破壊しちゃいましたので
コネクタを追加して元のケーブルも活用することにしました。
ていうかケーブルだけは作りが無駄にしっかりしてますね…

まぁ仕事で使うのって9600bpsが関の山だから921600bps出なくても
良いっていえば良いんですけどね…ぶつぶつぶつ・・・・

そんなわけでUSBシリアル変換のことばかりだらだら紹介してしまい
ましたがUSBシリアルについてはこれだけは言わせてもらいたいです！

１．FTDI製はやっぱり鉄板
　　->何だかんだで一番安定してます。
　　　迷ったら真っ先にこれを使いましょう!もちろん本物をですよ！
　　
２．中華製ぱちもんには気をつけろ！
　　->AmazonやAliexpress,ebayでは偽物に気を付けてください。
　　　安物買いの銭失いとならないようにしましょう。

３．あえて中華製使いたいのならお覚悟を
　　->Prolificとかはぱちもん対策でばんばんモデルチェンジ
　　　してますが正規品でもちょっと道から外れた使い方したら
　　　思ったように動かないとかざらだったりCH340系もかなり
　　　癖があるので心してかかるように、また他の方の使用記を
　　　しっかり読み込んだ上で挑みましょう！

1Wire温度センサDS18B20の偽物を追え！

本来は"いろいろ試す"枠の内容ですがこれだけでかなりのボリュームなので
独立記事で行かせていただきます！

●DS18B20がぱちもん乱舞していた件
>AmazonとかAliexpressで売ってる激安DS18B20はまず偽物の件
マジですか…

>特にステンの筒に覆われたタイプの奴はほぼ100%ぱちもん

おいいいいいいいいいいいーーーー！！！
※Molexのコネクタはねむいさんがつけました。

しかも二つも！！！！！！！！
※Molexのコネクタはねむいさんがつけました。

なぜねむいさんはいつもぱちもんをつかんでしまうのか…orz
↑のねむいさんの買ったやつは2016年くらいにAliexpressで買ったやつです。

ちなみに中華製偽物半導体の記事を見てSTM32のぱちもん乱舞の
話から、もしや温度センサも…って話になって調べたら電子工作では
ポピュラーなDS18B20にもパチモンがあると知った次第です。

こちらの方のGithubアカウントに細かい分析が書かれており、
2019年以降でebay,aliexpress,Amazonとかで異常に安い値段で購入可能な
温度センサ"DS18B20"もしくはそれの使用をうたう製品はまず中華製の
クローンもしくは偽物ということです。

そういうわけでねむいさんも手持ちのパチモン疑惑のDS18B20のステンの
筒入りセンサの調査を行ってみました。

上記のgithubアカウントで提示されているArduino向けのぱちもん判定
スケッチをSTM32C0のプロジェクトに移植してみました。
上記の画像の通りプロジェクト中のds18x20.hの赤枠のコメントを外すと
ぱちもん判定モード&パラサイトパワーモードで動作します。

(※MAXIMの製品サイトより引用)
また、"本物"のDS18B20はVCCが内部でダイオードを介してデータ線に
接続されている構造となっておりストロングプルアップという操作によって
VCC不要でデータ線とGNDの2線だけで通信が可能な"パラサイトパワー"が
使用可能ともなっております。

パラサイトパワーを使う際はDS18B20の"VCCとGNDを直結"する必要があります。
こんな感じでパラサイトアダプターを作ってみました。

また、パラサイトパワーで測定を行うには温度測定の際に1.5mAの電流を
供給する必要(ストロングプルアップ)があります。
STM32は1.5mA程度ならGPIOから電流供給可能なので、温度測定コマンドの
時だけODからプッシュプルに変更することにより追加のGPIOの操作なしで
ストロングプルアップを実現しております。

ていうわけで勝負！！！！
(※写真では通常モードですが実験はパラサイトパワーモードでやってます)

Welcome to STM32C031C6T6 test program !!

Version W.I.P!!

Build Date : Mar 21 2023



DS18B20 Genuine Checkers Start!

DS18B20 Device found!

ROM ID : 0x28D39E2B060000A3

DS18B20 ROM ID Check Ok.

Scratchpad : 0x50054B467FFF0C101C

Read Default ScratchPad Check OK.

Scratchpad : 0x5005B4B91FFF0C1013

Exchange 9-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x50054B463FFF0C10FC

Exchange 10-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x5005B4B95FFF0C10F3

Exchange 11-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x50054B467FFF0C101C

Write Modify ScratchPad Check OK.

Get Temperature Datas.

Scratchpad : 0x5A014B467FFF0610A3

All Okay!

This is THE GENUINE DS18B20!!

あれ…？
通った…？
本物…？

じゃもう一つ

Welcome to STM32C031C6T6 test program !!

Version W.I.P!!

Build Date : Mar 21 2023



DS18B20 Genuine Checkers Start!

DS18B20 Device found!

ROM ID : 0x2813A92B060000E9

DS18B20 ROM ID Check Ok.

Scratchpad : 0x50054B467FFF0C101C

Read Default ScratchPad Check OK.

Scratchpad : 0x5005B4B91FFF0C1013

Exchange 9-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x50054B463FFF0C10FC

Exchange 10-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x5005B4B95FFF0C10F3

Exchange 11-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x50054B467FFF0C101C

Write Modify ScratchPad Check OK.

Get Temperature Datas.

Scratchpad : 0x53014B467FFF0D10E9

All Okay!

This is THE GENUINE DS18B20!!

あ…
これも本物だ…

まず大前提としてDS18B20のROMIDは28-XX-XX-XX-XX-00-00-CRC
(XXは任意のHEX値)が本物たる最初のハードルとなります。
今回のステン棒DS18B20はそれぞれ下記のROMIDだったので…
0x28D39E2B060000A3
0x2813A92B060000E9
ちゃんとパラサイトパワーで動いてるしその後のスクラッチパッド
チェックもすべて通過したので本物だったのでしょう…

ステンな君たちのこと疑って悪かったです…

●大昔にTaobaoで大量購入したDS18B20は！？

たしか東日本大震災の前後の超円高のころに大量に購入していたやつです。
骨董品のDS1820(DS18B20ではない)なんかも買って当時ちょこっと使って
それ以来ずっと寝かしていました。たしか150円くらいだったんですよね…

件のgithubの記事曰くレーザーマーキングから察するにねむいさんのは
2009年48週目製造のC4ウエハ、でROHS品であると言えます。
まとめて購入したので全部同じマーキングとなっておりました。
同じロットだったのでしょう。

簡単に抜き差しできるアダプターも作って5個ほど試してみます！！
いざ勝負！！

Welcome to STM32C031C6T6 test program !!

Version W.I.P!!

Build Date : Mar 21 2023



DS18B20 Genuine Checkers Start!

DS18B20 Device found!

ROM ID : 0x289C63850200009A

DS18B20 ROM ID Check Ok.

Scratchpad : 0x50054B467FFF0C101C

Read Default ScratchPad Check OK.

Scratchpad : 0x5005B4B91FFF0C1013

Exchange 9-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x50054B463FFF0C10FC

Exchange 10-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x5005B4B95FFF0C10F3

Exchange 11-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x50054B467FFF0C101C

Write Modify ScratchPad Check OK.

Get Temperature Datas.

Scratchpad : 0xAC014B467FFF041086

All Okay!

This is THE GENUINE DS18B20!!

1個目本物
おｋ

Welcome to STM32C031C6T6 test program !!

Version W.I.P!!

Build Date : Mar 21 2023



DS18B20 Genuine Checkers Start!

DS18B20 Device found!

ROM ID : 0x28976285020000AF

DS18B20 ROM ID Check Ok.

Scratchpad : 0x50054B467FFF0C101C

Read Default ScratchPad Check OK.

Scratchpad : 0x5005B4B91FFF0C1013

Exchange 9-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x50054B463FFF0C10FC

Exchange 10-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x5005B4B95FFF0C10F3

Exchange 11-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x50054B467FFF0C101C

Write Modify ScratchPad Check OK.

Get Temperature Datas.

Scratchpad : 0xBD014B467FFF0310FF

All Okay!

This is THE GENUINE DS18B20!!

2個目本物
おｋ

Welcome to STM32C031C6T6 test program !!

Version W.I.P!!

Build Date : Mar 21 2023



DS18B20 Genuine Checkers Start!

DS18B20 Device found!

ROM ID : 0x28C08985020000AE

DS18B20 ROM ID Check Ok.

Scratchpad : 0x50054B467FFF0C101C

Read Default ScratchPad Check OK.

Scratchpad : 0x5005B4B91FFF0C1013

Exchange 9-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x50054B463FFF0C10FC

Exchange 10-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x5005B4B95FFF0C10F3

Exchange 11-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x50054B467FFF0C101C

Write Modify ScratchPad Check OK.

Get Temperature Datas.

Scratchpad : 0xBB014B467FFF0510C6

All Okay!

This is THE GENUINE DS18B20!!

3個目本物
おｋ

Welcome to STM32C031C6T6 test program !!

Version W.I.P!!

Build Date : Mar 21 2023



DS18B20 Genuine Checkers Start!

DS18B20 Device found!

ROM ID : 0x286366850200001E

DS18B20 ROM ID Check Ok.

Scratchpad : 0x50054B467FFF0C101C

Read Default ScratchPad Check OK.

Scratchpad : 0x5005B4B91FFF0C1013

Exchange 9-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x50054B463FFF0C10FC

Exchange 10-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x5005B4B95FFF0C10F3

Exchange 11-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x50054B467FFF0C101C

Write Modify ScratchPad Check OK.

Get Temperature Datas.

Scratchpad : 0xB5014B467FFF0B10A3

All Okay!

This is THE GENUINE DS18B20!!

4個目本物
おｋ

Welcome to STM32C031C6T6 test program !!

Version W.I.P!!

Build Date : Mar 21 2023



DS18B20 Genuine Checkers Start!

DS18B20 Device found!

ROM ID : 0x28017D85020000BF

DS18B20 ROM ID Check Ok.

Scratchpad : 0x50054B467FFF0C101C

Read Default ScratchPad Check OK.

Scratchpad : 0x5005B4B91FFF0C1013

Exchange 9-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x50054B463FFF0C10FC

Exchange 10-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x5005B4B95FFF0C10F3

Exchange 11-Bit Mode and Alarm Reg Check OK.

Scratchpad : 0x50054B467FFF0C101C

Write Modify ScratchPad Check OK.

Get Temperature Datas.

Scratchpad : 0xE5014B467FFF0B10BE

All Okay!

This is THE GENUINE DS18B20!!

5個目本物
おｋ

5個全部本物！やったね！
というわけでねむいさんが持ってたDS18B20はぜーんぶ本物で安心して
パラサイトパワーでもビシバシ使うことができます！めでたしめでたし！

…で終わるわけないでしょ！

●改めて偽物DS18B20を追え！
さて、じゃぁぱちもんDS18B20ってどんなんなの？って言う感じですが、
きわめて遺憾ではありますが、過去1年縛りでDS18B20でググってみると
ぱちもんと気づかず使用されている~~>マンモス哀れな奴 P! P!~~ｹﾞﾌﾝｹﾞﾌﾌﾝ方が
かなりたくさんいることがわかりました…
ArduinoとかESP32とかラズパイ+Pythonとかのいわゆるファーストプロト
タイピングな人たち狙い撃ちされている感じでございますね…

私も自腹きって今の半導体高騰の相場では異常に安いやつを買ってあえて
試してみました！5個入りでステンのケース入りで1000円以下☆
普通に買ったら1個1000円以上するのにこの時点で本物のわけないだろうが
ぇーっ(ｺﾞｯｺﾞｯ

秋月でも860円になってて高くて買えないよぉ…

それは置いといてとりあえずパラサイトパワーモードで試してみます！
うっすらネタバレしてますけど！

Welcome to STM32C031C6T6 test program !!

Version W.I.P!!

Build Date : Mar 21 2023



DS18B20 Genuine Checkers Start!

DS18B20 Device found!

ROM ID : 0x0000000000000000

ROMID does NOT follow expected pattern 28-XX-XX-XX-XX-00-00-CRC!

はい
パラサイトパワーモードでマトモに動きません！
パチモンでしたーーー！！！やったぜ！
じゃなくてクソァ！！！

Welcome to STM32C031C6T6 test program !!

Version W.I.P!!

Build Date : Mar 21 2023



DS18B20 Genuine Checkers Start!

DS18B20 Device found!

ROM ID : 0x2818B85704493C61

ROMID does NOT follow expected pattern 28-XX-XX-XX-XX-00-00-CRC!

パラサイトじゃないモードでも動かしてみました！
最初のROMIDのパタンチェックすらクリアできてません！！
本物の偽物です！！！！！！おめでとう！！！！！！
なんでやねん！

ちなみにねむいさんのSTM32G0とSTM32C0のサンプルコードでは
パチモン判定モードではSTN液晶にちゃんと"ぱちもん"と表示して
そこから先に進めなくなる親切設計です☆

残り4個もどうせ偽物なので試す時間ももったいないのでさっさと産業ごみで
捨てる予定ですがとりあえずステンのケースぶっ壊して中の偽物を引きずり
出してやりましょう…！！

―――――　5分後　―――――

はぁはぁ…ステンのケースは本物のステンのようでめっちゃ固い…

―――――　10分後　―――――

なんと偽物DS18B20使ってるくせにそれ以外はいい仕事してやがって中まで
ぎっちり硬いエポキシが充填されておりました…なんでやねん！

というわけで"最近の異常に安く買えるDS18B20、特にステンのケースに
入ってる奴はまず偽物"説はマジだったのとねむいさんが持ってたステンの
奴は本物のDS18B20が使用されている貴重品なので大事に大事に使って
いこうとおもいます！

…こういうパチモンが狙う市場っていわゆるライトユーザー層なのかなと
思ってます。"とりあえず動いた(←温度がみえたっぽいから)"おっけーで
終わる人はまずこれをぱちもんと見抜けませんし気づきもしません。

ファーストプロトタイピングが当たり前になった現在、ハードウエア何も
知らなくても"プログラミング"を楽しめるようになったので中華の業者が
そいつらだましてそれで飯食えるくらい魅力のある"市場"になったって
ことなのでこれから先こんなんばっかりになりそうですね～～…。

偉そうに言ってるねむいさんもDS18B20のぱちもんの存在知ったの今年の
はじめです。STM32に限っては10年以上使ってきて細かいエラッタまで知り
尽くしてるから情報ばんばん取り込んでたので回避できてきましたが…
XMEGAとか思いくそ被弾しましたからね…猛省猛省。

これから先、電子工作するときは動いたからおっけーの気分で終わらせず、
電子デバイスの真贋の情報は常にアンテナ張って徹底収集、なおかつ
ちゃんとオシロスコープで波形を確認したりデータシートをよく読んで
齟齬がないかとか最低限のハードウエア確認はしていこうと思いまし、た！

でもパチモン掴んだらぶろぐのネタになっておいしいのでこれはこれで。

いろいろ試す55

もう1か月過ぎそうですがあけましておめでとうございました！！
1月2月は毎年死ぬほど忙しいのでいつも月末ギリギリの投稿です・・・

●OpenOCD 0.12.0ついにリリース！

あれ・・？0.13じゃなかったの…まぁいいや
いちおうRCが取れて正式にOpenOCD0.12.0となりました…

ナイトリービルドが当たり前になっちゃって正式リリースとか関係なしに
動いている今最新のが安定版…みたいな哲学的な状態となってますが今回は
ちょっと注意点があります

libusbのほうの最新のコミットでdeprecatedになった関数があり、
libusbに依存しているライブラリの中でdeprecatedなのを使っている奴が
ビルドエラーになってしまってます。

OpenOCDで引っかかっているのはJ-Link用ライブラリlibjaylinkで今の
ままではビルドが通らないのでおきぱのOpenOCDのバイナリでバインドして
いるのは古いv1.0.26のままとなっております。
libjayの方に更新かかってv1.0.27対応になったらまるっと差し替えます。

OpenOCDのwindowsバイナリはこちらです！

●avrdudeもついにv7.1に！
avrdudeのほうも長らく7.0だったのがようやく7.1となりました…！

相変わらず日付が間際らしいですがバージョン上がった日付のまま
いくらコミット進んでもここの日付は変えないみたいですね…

先月述べた通り表示関連が大幅変更になっていますが見た目は変わって
ないのでいつもと同じ感覚で使用できると思います。
また、libusbはOpenOCDと同じくv1.0.26としております。特に動作に
支障はないので当分1.0.26で行きましょう…

avrdudeのwindowsバイナリはこちらとなります！

●FatFsディレクトリ破壊問題に進展
MMCに書き込んだらFATディレクトリ構造が破壊される問題は
下記の段階まで絞り込めてきました。

・アロケーションユニットサイズが512バイト(1セクタ)以外
のものは書き込んだらディレクトリ構造ごと破壊

もうこれ以外の違いは判りませんがSDフォーマッタでくだんのMMCを
フォーマットするとFAT16で32セクタ(アロケーションユニットサイズが
16kバイト)になってしまうので512バイト以上のファイルをコピー(f_writeを
実行)したら確実に破壊されることがわかりました。

これを回避するためにはFAT32もしくはexFATでアロケーションユニット
サイズを512バイトでフォーマットしてやればどのサイズのファイルを
コピーしても破壊されることはありませんでした。

現行最新のFatFs0.15でも同現象を確認してさらに上記対処法で回避
可能なのですがどうしてそうなるのかというメカニズムは今後も解析を
続け、わかりしだい追ってお伝えします…！

MMCとか今頃使ってる人はいないでしょうけどもし同じ現象にぶち
当たった人はアロケーションユニットサイズを512バイトに固定して
FAT32かexFATでフォーマットしたら回避はできますのでお勧めします？

ついでですが今回の検証でSTM32F4のSPIモード時のMMCv3のクロックの
処理が誤っていたので(MMCv3は最大20MHz以下)修正しておきました。

●↑のついでにFatFs移植例の整備
STM32F4のソースに久々に手を付けたついでにSTM32F7とSTM32H7のFatFs
移植例も整備を行いました。makefileも見直しており、デバッグ時の
スイッチ新設とアセンブラファイルのビルド時のファイル名の小文字化
とかももう少しマトモな表現に直しました。

旧

# Exchange Uppercase into Lowercase

#MPU_MODEL_LOWER = $(shell echo $(MPU_MODEL) | tr A-Z a-z)

lc_jimae = $(subst A,a,$(subst B,b,$(subst C,c,$(subst D,d,$(subst E,e,$(subst F,f,$(subst G,g,$(subst H,h,$(subst I,i,$(subst J,j,$(subst K,k,$(subst L,l,$(subst M,m,$(subst N,n,$(subst O,o,$(subst P,p,$(subst Q,q,$(subst R,r,$(subst S,s,$(subst T,t,$(subst U,u,$(subst V,v,$(subst W,w,$(subst X,x,$(subst Y,y,$(subst Z,z,$1))))))))))))))))))))))))))

MPU_MODEL_LOWER  = $(call lc_jimae,$(MPU_MODEL))

新

# Exchange Uppercase into Lowercase

MPU_MODEL_LOWER = $(shell echo $(strip $(shell echo $(MPU_MODEL) | tr A-Z a-z)))

なんで私はこんな苦しみ紛れに屁をこいたようなものを数年も放置して
しまっていたのか…時間を見てほかのSTM32シリーズにも展開しておきます。

現状は下記3つのプロジェクトに対して最新のものを反映しております。
ついでにHALライブラリもgithubの新しいものを反映するようにしました。
・STM32F4
・STM32F7
・STM32H7

●半導体品切れがいくつか復活するも
秋月ですごい高くなってる…特にLDOとかSTM32とか

私の記憶ではLT1963Aは450円くらいで買えたはずですが…円安とインフレ
めっ…ちなみにdigikeyでは20230131現在950円となりやがっておりおいそれと
使うことができない高根の花となってしまいました…

そしてADP3338も~~EOL~~NRNDとなってしまった今ドロップアウト電圧の低い高性能な
LDOを求めて難民になってしまいましたがいろいろ探して値段性能的に妥協
できそうなやつを見つけてみました(注:SOT-223-3パッケージ、Vin=5V限定)。

まずはSOT223パッケージで真ん中の足がGNDのLT1963A系のやつはMicroChip社の
MIC37100-3.3WSなんかが妥協できそうですね。MLCC使用OKです。
ドロップアウト電圧は0.5V/1AMAXで十分な性能があると思います。
そして値段も300円以下(20230131現在)なので価格的にも優しいです。

お次にSOT223パッケージで1PinがGNDの"LT1117系"のLDOですが、こちらは
DIODESのAP2114HA-3.3TRG1とかですね。こちらもドロップアウト0.75/1AMAX
でドロップアウト0.8V切りは一応クリアでESP32でも持ちこたえられると思います。
もちろんこちらもMLCC使用可です。

まだデータシート上で選定しただけですが特にLT1117系LDOの置き換えを狙う
AP2114HAについては実際に入手してESP32の基板で試してみたいところです！

いろいろ試す54 -2022年反省会-

すみませんやっと時間取れましたが今年残りあと0.2時間くらい…

●OpenOCD-0.12.0-RC3更新
OpenOCDももうすぐ0.13.0になろうとしておりますがRC2->RC3の私的に
注目する更新は、RTOSの自動検知でRTOSがサポートしてないもしくはRTOS
未使用の際にステップ実行したとたんに落ちていたのが修正された…
…のはよいのですが今度はねむいさん特製cfgファイルのほうと衝突
しちゃってTARGETNAME設定の際にとりあえず出つけていた"rtos auto"の
オプションはcfgファイルから削除するようにしました。

ねむいさんRTOSほとんど使ってませんし唯一(仕事で)使ってるMbedOSは
OpenOCDのスレッド検知非対応でrtos autoの設定は実質無意味になっちゃい
ましたからはずしてしまいました。

またつぶしが効くような修正や逆に私がRTOSサポートに本腰入れるように
なったらこの辺りもう一度見直そうと思います…

というわけで今年最後の更新かつ2022年末最新のOpenOCDバイナリはこちらと
なりますのでどしどしつかいたおしてくださいっ！

さりげなくSTM32G4とSTM32L4のフラッシュ書き込みに対応しております！

●AVRDUDEが相わからず更新しまくり
なんでこんな恐ろしいスピードで更新しまくっているのか…！？
息を吹き返していま最もホットなavrdudeもビシバシ充てられるコミット
にしがみついて追従しております。

ところでいつまでバージョン表記はv7.0-20220508のままなんですかね…
中身めちゃくちゃ変わってるんですけぉ…

まぁそれは置いといてこちらは31日付でビルドしなおしております。
こちらもびしばしつかいたおしてくださいっ！

●Android狂騒曲
20230123追：内容が酷過ぎたので少しまともに修正
もう作業進める時間が欲しくてこのブログ書いてる暇が全くないのですが
仕事で必要になりAndroidのタブレットを自分でも購入したことからすべては
はぢまってしまいました。Android上でPythonを走らせてさらにGUIを動かす
という作戦を現在敢行しております。

ガチドザのねむいさんにははぢめてのこと過ぎてあまりにもハードルが
高すぎましたが下記の手順でPythonでGUIを動かすところまで行けてます。

1.Termuxインストール
2.Termuxのエミュレータ端末からPython3インストール
3.同じくpython-tkinterインストール
4.pipでPyserialインストール
5.pipでPySimpleGUIインストール
6.PySimpleGUIのためのx-window導入
7.VNCViewerインストール

上記の長い手順を踏んだうえでser2net化したラズパイZeroとUSB-OTGで
STM32G431K-Nucleoを接続し(STLinkはUSBシリアル変換として動作する)、
さらにwifi経由でラズパイZeroとAndroid間であたかも通常のシリアル
通信のようにデータをやり取りできるところまでできました！！！

今回の例はDHT系の温湿度モジュールAM2322Bの温湿度データを取得して
Termux上のPythonGUI上に温湿度データを取得表示しているところです。
XFCEのデスクトップ画面は殺風景すぎるのでﾃﾞb東條希さんが横たわってる
壁紙で多少の癒し効果を与えております。

ところでこんな回りくどいことやらずに素直にkotlinで直接TCPで通信する
Androidアプリ作れやだって！？
あのね！ねむいさんがそんな正攻法するわけないでしょ！

この狂騒曲はまだ続いておりますが落ち着いたら改めてやったことの
整理ついでに詳細を紹介する予定です。

●Transcend製の3D-TLCの産業用microSDカードTS256GUSD460Tを買った

というわけでTranscendの産業用microsd460Tが市場に出回ってしまったので
年末のくそ忙しい今買って試しました！

まずはWin10でベンチ。直線もチマチマも十分の実力ですね～

例のあれでSMARTを取得してみました。しっかり読み取れますね！
お次はいつもので読んで見ます。

FatFs module test terminal for STM32H747XIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Dec  5 2022

>fg piano



rc=0 FR_OK

>fo 1 ftbt.mp3



rc=0 FR_OK

>fr 132949600



132949600 bytes read at 21495 kB/sec.

>fs



FAT type = exFAT

Bytes/Cluster = 262144

Number of FATs = 1

Root DIR entries = 0

Sectors/FAT = 32768

Number of clusters = 954112

Volume start (lba) = 65536

FAT start (lba) = 98304

DIR start (lba,clustor) = 4

Data start (lba) = 131072



Volume name is TS256G460T

Volume S/N is 9C33-6BBD

...

1 files, 132949600 bytes.

244252672 folders.

244120832 KiB total disk space.

4 KiB available.

>ds 0



rc=0

Drive size: 488636416 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 DB 79 00 07 47 FF 7F 80 0A 40 00 73  @..2.y..G....@.s

CID:

00000000  74 4A 60 55 53 44 55 31 20 80 36 D4 80 01 6A 73  tJ`USDU1 .6...js



Parsing SD CID Register

Manufacturer ID    :0x74

OEM/Application ID :J`

Product Name       :USDU1

Product HwRev      :2

Product SwRev      :0

Serial Number      :0x8036D480

DateCode.Month     :10

DateCode.Year      :2022



OCR:

00000000  C1 FF 80 00  ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 08 11 39 1E  ..............9.

00000010  00 08 00 00 00 02 FC 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 45 84 87 00 00 00 00  .E......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :2

SD Security        :4

SD Bus Width       :5



SD_Spec V6.xx!

Detected as SDXC Card!

Available UHS-I Mode.

Available UHS Speed Class U3.

Available SD Speed Class 10.

Available Video Speed Class 30.

Available Application Performance Class2, A2 Card.

A2 CommandQueue Depth 32 Supported

A2 Cache Supported.

>

A2クラスはもはや当たり前となりましたね～
最もA2に対応したSDホストでないと真価は出ませんが…

そして産業用microSDもだいぶそろってきましたのでここらでラズパイ
向けの価格性能比が最も優れたもの比較でもやりましょう…！
と言いたいところですがもう時間がないので来年に…

●毎年恒例ねむいさんQ&A
Q:ねむいさん…Codelite使ったARMデバッグ手順のﾎｳﾊ…
A:あああああああああああああああああ１！１！！１１！
　

　今最新のGCC12でもLPC2388(ARM7TDMI)のデバッグできまくるの確かめた
　ところまできやがってます！！！！！もうちょっとまって！１！！！
　

　☝GCC12でひりだしたelfはinsightで読めないので苦しみ紛れに屁こいた
　みたいな釈明でその場をしのがせていただきます…
　
Q:時間ない割には山にはいくんだ？
A:それは別腹です

Q:それとDropBOXの過去の消えた画像は？毎年言ってますが…
A:…
　…
　来年から本気出す！！
　それではよいお年を～

いろいろ試す53

副業(本業は二次裏メイド)が激務になったのと秋の登山ラリーが始まったので
まったく時間が取れてませんが何とか進めていきたいと思います…

●ようやくSWDマルチドロップも使い物に･･･！
-OpenOCD-0.12.0-RC2更新-
長かった…ラズパイピコが登場してから長い戦いだったがようやく本家にも
安定した状態で取り込まれたようですね…感無量です。

↓以下RaspiPicoに書き込んだところのログ

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

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2_swd.cfg -f target/rp2040_swd_flash.cfg -c "mt_flash_bin main.bin 0x10000000"

Open On-Chip Debugger 0.12.0-rc2+dev-00001-g12ce17094 (2022-10-30-22:35)

Licensed under GNU GPL v2

For bug reports, read

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

Info : FTDI SWD mode enabled

Warn : Transport "swd" was already selected

Info : clock speed 1000 kHz

Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001

Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001

Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected

Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints

Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected

Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints

Info : starting gdb server for rp2040.core0 on 3333

Info : Listening on port 3333 for gdb connections

Info : starting gdb server for rp2040.core1 on 3334

Info : Listening on port 3334 for gdb connections

[rp2040.core0] halted due to debug-request, current mode: Thread 

xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00

[rp2040.core1] halted due to debug-request, current mode: Thread 

xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00

Info : Found flash device 'win w25q16jv' (ID 0x001540ef)

Info : RP2040 B0 Flash Probe: 2097152 bytes @0x10000000, in 32 sectors



Info : Padding image section 0 at 0x1001fe80 with 128 bytes (bank write end alignment)

Warn : Adding extra erase range, 0x1001ff00 .. 0x1001ffff

Info : wrote 130816 bytes from file main.bin in 4.495757s (28.416 KiB/s)

Info : verified 130688 bytes in 0.206712s (617.405 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:05

コアがちゃんと2つ見えているのがわかりますね～
また、注目すべき点はコアの数だけgdbサーバのポートも増加している点です
デバッグ時はgdbも一個ずつ起動してつなげていきます

openocdも0.12.0になってARM以外のかなりのCPUコアもサポートしています。
STM8はすでに書き込みデバッグに成功していますが新規にサポートされた
RISCVのGD32V系、また本家にサポートが取り込まれたESP32などはまだ全くの
手付かずなのでこれから挑戦していきたいと思います！

というところでねむいさん特製ビルドのOpenOCDはこちらになりますので
どしどしお使いください…！

●で、CodeLiteとGDBを使ったデバッグはどうなったの？

…正直まだ検証が進んでません…
10年同じ事やってたのでtarget extended-remoteってなんだよってとこから
再開ですしSTM32の検証がやっと終わってほかのcortex-M、あとARM7TDMIも
見ていこうと思ってますがすべてのCPUで安定して動かせられるパタンが中々
見つからず苦戦しています。
・今できてること
　→ステップ実行(ステップイン/ステップアウト)
　→ブレークポイント
　→変数読み取り
・InsightではできたがCodeLiteでできなくなったこと
　→IOViewでペリフェラルを直感的にたたけなくなった
　　　(gdbのprintコマンドでせこせこ変えるしかない)
　→main関数内の最上位でステップアウトをうっかりやらかすと死ぬ
　→ブレークポイントを設定しないでrunさせたら死ぬ
　→調子おかしくなったと感じてstopしてもgdbにコマンドがなぜか通らず死ぬ
　→とにかく機嫌損ねたら死ぬ
　

死んだらこちらも能動的に殺しにかかってtaskkillコマンドでOpenOCDごと
強制終了してつなぎなおしてます。Insight時代からやってましたがよく
わからなくなったら全部終了で再開するのが最適だと感じてます。
画像はNuvotonのnano130のデバッグ終了時の画面です…いささか強引ですが
これが一番楽…とこんな感じでLPC系のマイコンとかも確認を進めていきます。

●avrdudeがものすごく中身変わっていた
avrdudeがすさまじい勢いで修正がかかりまくりどんどん進化してます
当然途中で大変更が発生することもあり、これで深刻な影響を受けるのは
たいていビルドする人間です…orzビルドが通らなくなったorz

今回readline周りが大幅変更でまともにビルド通らず動かずで難儀しましたが
何とか安定して動かすことができました…細かいことは省きますがreadlineが
dllとして追加になりました。もちろん自前ビルドです。
以下avr128da48に書き込んだ時のログ

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

C:/Devz/AVR/avrdude/avrdude -v -p avr128da48 -P usb -c pkobn_updi    -U flash:w:main.bin 



avrdude: Version 7.0-20220508

         Copyright (c) Brian Dean, http://www.bdmicro.com/

         Copyright (c) Joerg Wunsch



         System wide configuration file is C:¥Devz¥AVR¥avrdude¥avrdude.conf



avrdude: input file main.bin auto detected as raw binary

         Using Port                    : usb

         Using Programmer              : pkobn_updi

avrdude: found CMSIS-DAP compliant device, using EDBG protocol

         AVR Part                      : AVR128DA48

         RESET disposition             : dedicated

         RETRY pulse                   : SCK

         Serial program mode           : yes

         Parallel program mode         : yes

         Memory Detail                 :



                                           Block Poll               Page                       Polled

           Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack

           ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------

           fuse0       wdtcfg      0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse1       bodcfg      0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse2       osccfg      0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse4       tcd0cfg     0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse5       syscfg0     0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse6       syscfg1     0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse7       codesize    0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse8       bootsize    0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuses                   0     0     0    0 no          9   16      0     0     0 0x00 0x00

           lock                    0     0     0    0 no          4    1      0     0     0 0x00 0x00

           tempsense               0     0     0    0 no          2    1      0     0     0 0x00 0x00

           signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00

           prodsig                 0     0     0    0 no        125  125      0     0     0 0x00 0x00

           sernum                  0     0     0    0 no         16    1      0     0     0 0x00 0x00

           userrow     usersig     0     0     0    0 no         32   32      0     0     0 0x00 0x00

           data                    0     0     0    0 no          0    1      0     0     0 0x00 0x00

           eeprom                  0     0     0    0 no        512    1      0     0     0 0x00 0x00

           flash                   0     0     0    0 no     131072  512      0     0     0 0x00 0x00



         Programmer Type : JTAGICE3_UPDI

         Description     : Curiosity nano (nEDBG) in UPDI mode

         ICE HW version  : 0

         ICE FW version  : 1.21 (rel. 37)

         Serial number   : MCHP3280031800001375

         Vtarget         : 3.31 V

         PDI/UPDI clock Xmega/megaAVR : 100 kHz

avrdude: partial Family_ID returned: "    "

avrdude: AVR device initialized and ready to accept instructions

avrdude: device signature = 0x1e9708 (probably avr128da48)

avrdude: Note: flash memory has been specified, an erase cycle will be performed.

         To disable this feature, specify the -D option.

erasing chip

avrdude: reading input file main.bin for flash

         with 3392 bytes in 1 section within [0, 0xd3f]

         using 7 pages and 192 pad bytes

avrdude: writing 3392 bytes flash ...



Writing | ################################################## | 100% 1.09s



avrdude: 3392 bytes of flash written

avrdude: verifying flash memory against main.bin



Reading | ################################################## | 100% 0.60s



avrdude: 3392 bytes of flash verified



avrdude done.  Thank you.





> Process Exit Code: 0

> Time Taken: 00:02

正直大変更前と見た目は全く変わらないので見栄えがしませんがいろんな人の努力で
どんどん機能がパワーアップしていくわけですね…

avrdudeの10月末最新のバイナリもアップロードしました。
こちらもどんどん使ってくださいませ～！

いろいろ試す52

●CodeLite+GDBを使ったARMデバッグ環境移行加速す！

oh...myｺﾝﾌﾞ･･･とうとうこの日がやってきた…
InsightだとGCC12からサポートされたdwarf5フォーマットのelfが読めない…
ARM-GCCのバグのせいかdwarf4形式のリンカオプションつけてもdwarf5･･･

orz

というわけでねむいさんのぶろぐ旗揚げから13年間続けてきたInsightによる
デバッグ法に別れを告げ、かねてより評価中のCodeLiteによるGDBデバッグ
環境移行と同手順書作成に本腰を入れております！

移行で一番の障壁はworkspaceの概念でしたが…幸いにもディレクトリを遡る
相対アクセスが問題なくできたのでmain.elfを相対参照するようにしたら
デバッグするたびいちいち設定しなおす必要もなく同一のworkspaceファイル
の使いまわしができそうです！

CodeLite.exeはなんでかgnumake3.81から直接召喚できなかったのでwindowsの
CMDでの機能で代用しました。ちゃんと引数付きで呼び出しもできたので
ここで上で説明したworkspaceファイルを相対アクセスで開きます。

実際のデバッグ画面です。
ソースレベルでステップ実行とかの基本は当たり前の余裕ですね。

InsightではWin10では即堕ちして使いものにならなかったCPUレジスタ参照は
バリバリできています。

F7,H7の浮動小数点レジスタも楽勝です♨

…なのですがなんでかこれらレジスタ表記は10進数(一部は16進数)固定で、
進数の切り替えができません。Insightでは柔軟にできてたのでここに
ついては要改善ポインツですね。

また、周辺I/Oのレジスタ値を直接参照するIOView機能とかも一応使えます。
IOViewは周辺レジスタをconst宣言しているせいか、変数参照ウインドウから
直接値を変えられませんでした。
constでも値を自由に変えられちゃうInsightのほうが逆にダメだったのかも。

回避策としてOutputウインドウからコマンド直接入力で値を変えられます。
Outputウインドウと銘打ってますがGDBのコマンド入力も受け付けています。

そして特筆すべきはInsightとは違いGDBから完全に独立したGUIとして働くので
ARMだけではなく他のCPUコアでもそれ用のGDBさえあてがえば普通に使えます！
先月紹介したSTM8Lもご覧の通りばりばりデバッグ可能です！
ていうかSTM8Lの記事ぶん投げっぱなしですが来月がんばります！！！！

となるとESP32とAVRのデバッグ環境もCodeLiteで一括化できそうなので、特に
5年くらい放置してるESP32とかはやる気出てまた活動再開できそうな感じです☆
ARMマイコンビルド/デバッグ環境構築手順もCodeLite+GDBデバッグを主眼にした
2022年版に書き替えている最中ですのでこうご期待！

また、待ちきれない方に先んじてWin10環境下でCodeLite+GDBのデバッグ環境
対応のプロジェクトに更新しております。現在以下のものが対象です!
・STM32H7-Disco
・STM32F7-Disco
・STM32F4-Discovery
・STM32G0ベアメタル

●ARM-GCCがまたアップデートしていた。
まず、前回のいろいろ試すでアップデートされたGCCでビルドすると…

前回記事にしていたにかかわらずこれ気づかんかった…
ちゃんと検証してなかったのバレバレの私orz
これかなり致命的なバグでしたね…私のおきぱのプロジェクトがほぼビルド
不可能状態でした…すみません。
これ前回のいろいろ試すにも警告書いときます。

現行のGCC11.3ものは緊急修正が加わってちゃんとビルドできるようになってます。
が、冒頭のdwarf5の問題でInsightデバッグができなくなってますので要注意！

●AVRDUDEにパッチを投げたお話
これも9年越しの話なのですがねむいさんはJTAGKEY等のFT2232系のISP/JTAG
書き込みで、1セクタサイズ以下のサイズのバイナリを書こうとしたら正常に
書き込めないバグを見つけておりました。しかし、そんな超限定された条件、
例えば128kByteの容量を持つatmega1284p(フラッシュセクタサイズ256Byte)に
たった202バイトの容量のLチカプログラムを書き込むやつがいるだろうか？
という原因からか9年放置されていました。

が、オワコン化したかと思われたavrdudeがgithubに移行したとたんバリバリ
更新がかかりまくるようになり、9年前の問題が再び目に留まったのでわたしも
この問題に決着をつけるべく参戦を果たしました！！！
(☝お前AVR辞めたんちゃうんかいという突っ込みは一切なしで)

その後、管理者の人のコードレビューと別の修正が合体して正式にコミット
されています。

リンク先の議論にもありますがねむいさん的には符号付整数で比較を
行うと符号拡張で符号なし整数では思わぬでかい数字が入ってしまって
思ったような評価ができないのを危惧したのですが最終的に符号なし
整数同士の評価で終わるようにしてくれて実際に問題なく書き込みが
できるようになったのでよしとしましょう。

いろいろ試す51

今回は8bitマイコン中心のネタになります。

●AVRDUDEの整備
新世代のupdiに対応したavrdudeはgithubに戦場を移してかつてとは比べ物に
ならない速度でビシバシ修正が入りまくっております。

私もそれに対応すべくなるべく最新のコミットを常にpullしてビルドしたバイナリを
OpenOCDと同じく皆様に提供しております。

前回の記事の通り、USBシリアル変換でUPDIがお手軽にできてしまったので
avrdudeの需要がかなり増加しておりavrdude目当てでぶろぐに来られる方も
増えておりうれしい限りでございます。

宣伝ですがSTM32系のCortex-M系マイコンのねむいさん特製書き込み
スクリプト付きのOpenOCDバイナリも公開しておりますのでこちらもご利用ください☆

●ATXMEGA128A1"U"を使ってみるつもりだったが…

今年の春、思うことあってXMEGAを再び使う気持ちになり、ATXMEGA128A1の
進化系であるATXMEGA128A1"U"を入手して使用してみました…

ATXMEGA128A1"U"はU無しの物にUSB機能やその他修正を加えたものです。
多分USB付きだからUなのでしょうね…

デバイスIDはなんとATXMEGA128A1と同一です…間際らしい…

A1UのリビジョンはHか～…A1と全く同じじゃん(←まだ気づいてない

しかし、その後いろいろいじって気づいたがねむいさんが本当に使いたかった
4-PortEBIのSRAMが使用できなかった…。
具体的に言うとA1UはEBIがPORTFに割り振られておりA8~A15のアドレスバスが
使用できるはずなのですができない！！！！！

唸ること1週間、AVRFREAKSの記事にATXMEGA128A1Uのチップリビジョンは
'L'であるというコメントが…
そしてもう一回入手したA1UのリビジョンIDを見直すと…

↑A1UはRev:LのはずなのにRev:H
あああAAあああああ！！！これA1UではなくてA1なのでは！？
もう一度チップ表面を見てみる

あれ…私がaliexpressで買ったA1UはA1の奴と見比べるとよく見ると真ん中
あたり削ってるような形跡…
…
リマーク品でしたー！クソァ１！！！１！！！

まぁこんな半導体不足のご時世でデジキもMOUSERもA1Uの在庫0なのにAliexpress
からすんなり買えるはずはないと思ったのですよぅ…

このネタは次回のA1U入手作戦に続きます…

●arm-gccがアップデート
今年の春先にarm-gccがgccバージョン11.2になってアップデートしています

今回からファイルサイズがメタクソにでかくなってるのでダウンロードの際は
十分ご注意下さい。スタティクライブラリを各コアごとにすべて用意して
いるのが原因のようです。ちなみにCortex-M系だけではなくLPC2388等の
ARM7TDMI等もビルド可能です。

●avr-gccもアップデート
avr-gccも12.1.0にアップデートしております。

こちらについては次回予定のATXMEGA128A1Uの記事で合わせて紹介
させてたいだきます。

●STM8Lはぢめてます

ATXMEGA128A1U購入のついでに8pinSTM8LシリーズのSTM8L050J3M3
も試用してます。
こちらもうまいこと使いこなせるようになったら紹介したいと思います。

いろいろ試す50(+2021年反省会)

今年もいろいろありましたね…
月一更新は何とか続いてますがネタはあるのですが試す時間がない状態で
どんどん積みあがってる状態です…！

●Transcend製産業用MicroSD TS256GUSD430Tを試す！

ちょっと臨時収入が入りましたのでAMAZONのTranscend公式から産業用MicroSD
TS256GUSD430Tを購入しました！！

こちらは以前購入したSLCModeの品種と同じくS.M.A.R.T.を取得せしめることが
可能となっており、寿命の把握が簡単にできます！

また、SLCModeは無く通常の3D-NANDの構成のため以前のものと比べてちまちま
書き込みはそこまで早くはないのですが、これも実用には十分すぎるレベルと思います。

次にSTM32H7DiscoveryのFatFsサンプルでカード情報を読みだしてみます。

FatFs module test terminal for STM32H747XIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Dec 30 2021

>fg piano



rc=0 FR_OK

>fo 1 ftbt.mp3



rc=0 FR_OK

>fr 132949600



132949600 bytes read at 22051 kB/sec.

>fs



FAT type = exFAT

Bytes/Cluster = 262144

Number of FATs = 1

Root DIR entries = 0

Sectors/FAT = 32768

Number of clusters = 943744

Volume start (lba) = 65536

FAT start (lba) = 98304

DIR start (lba,clustor) = 4

Data start (lba) = 131072



Volume name is TS256GUSD

Volume S/N is 9C33-6BBD

...

1 files, 132949600 bytes.

241598464 folders.

241466624 KiB total disk space.

4 KiB available.

>ds 0



rc=0

Drive size: 483328000 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 DB 79 00 07 33 BF 7F 80 0A 40 00 85  @..2.y..3....@..

CID:

00000000  74 4A 60 55 53 44 55 31 20 31 07 84 ED 01 57 09  tJ`USDU1 1....W.



Parsing SD CID Register

Manufacturer ID    :0x74

OEM/Application ID :J`

Product Name       :USDU1

Product HwRev      :2

Product SwRev      :0

Serial Number      :0x310784ED

DateCode.Month     :7

DateCode.Year      :2021



OCR:

00000000  C1 FF 80 00  ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 08 11 39 1E  ..............9.

00000010  00 08 00 00 00 02 FC 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 05 84 87 00 00 00 00  ........



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :2

SD Security        :0

SD Bus Width       :5



SD_Spec V6.xx!

Detected as Not SD Card!

Available UHS-I Mode.

Available UHS Speed Class U3.

Available SD Speed Class 10.

Available Video Speed Class 30.

Available Application Performance Class2, A2 Card.

A2 CommandQueue Depth 32 Supported

A2 Cache Supported.

>

もう当たり前のようにA2(対応ホストじゃないと恩恵ないですが)でU3速度ですね。
純粋な読み出しスピードも22MB/Secと理論上の速度に近い値が出てますね。

お次はCMD56コマンドでSMART情報を読みだしてみました。
ぇっ？どうやって見るのって？
./lib/ff/sdmmc_stm32h7.hとか見たら幸せになれるかも！？

"Transcend"のヘッダが読みだされ、ちゃんとSMART情報が得られていることが
わかります。生データはこちらになります。

そしてRDF5を使ってあれを使うとWindowsからSMARTを読み出せちゃいます！！
ねむいさんがあまりにダイナミックにやってしまったせいか"ソフトは法人専用"って
念押しの文章が付け加えられてしまいましたが仕事でTranscendのCF使ってるから
セーフ！セーフ！！
それはさておき"Current SD Card Sped Mode"のD0ってなにやねんという
ところですがここに相当する番地(0x47)の値が0となっているため12MB/Sec
(DefaultSpeed)扱いになってるようです。
でもちゃんとUHS-Iの速度は出てるのは上のベンチにあるとおりです。
まぁ動作に影響はないので問題はないでしょう～

というわけでTaranscendの産業用カードを紹介しました。こちらもRaspi用
ストレージにお勧めだそうで、230Iでは容量が足らない場合はこちらを使って
みたらよいと思います。

●プローブを短くて使いやすいやつに買い替えた話

今日びのオシロプローブは細かい回路に対応するためプローブ本体もコンパクトに
なっておりますがTektroとかの正規品はべらぼうに高くなかなか買う気が起きません。
そんな折安価なプローブでおなじみのHONGKONG TEXAS社から新型プローブが
販売されていることを知り早速購入しました！！！

まだ秋月には出回っておらず、だいぶ前にktekさんという業者さんより購入しました。
先っちょにつける高速信号用アダプターがおまけです。

TX6550A/Bはアナログ帯域は500MHzあり、実力は十分です。
なおTX6550Aが先端シャフト系2.5mm品でTX6550Bが従来の5mm品です。

秋月で販売されている同社の同スペックのプローブと大きさ比較です。
もう図体が全然違うことがわかりますね～細かい回路でプローブ引っ掛ける際に
特に4CHぜんぶつかうような場面で非常に使いやすいです。
あと願わくばケーブルも細く引き回しやすくなってくれるとありがたいですね。
きわめて高価なTektroのケーブルはすごい細くて柔らかく、そのあたりに値段差が
出てきているのかなと感じました…が普通に使う分にはTX6550でも十分恩恵は
得られるとおもいます！

ちなみにTEXAS製のプローブはKeySight等のれっきとした測定器メーカで使用されて
いる純正プローブのOEMとなってます。、N2890AはTX6250に、N2873Aは
TX6550Aに形状が酷似していることからわかりますね。

ねむいさん的には5.0mm版限定のおまけでつけてくれたPA001という高速信号用
アダプタがちょっとうれしかったです。ピンヘッダから出てる信号を確実に
計測するのにすごく役立ちます！！

てわけでますます使いやすくなった測定器環境ですが持ち腐れさせずに
バンバン使い倒していきたいと思います！！そうだね宣伝だね。

●arm-gcc定期更新
ARM預かりになって以来すっかり更新頻度が減ったarm-gccですがいつのまにか
更新していたので比較してみました。
主な変更点ですがGCC10.2.1->GCC10.3.1に代わりました

新

arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10.3-2021.10) 10.3.1 20210824 (release)

Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 766928	      0	 766928	  bb3d0	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 764276	   2652	2383304	3150232	 301198	main.elf

main.elf  :

section               size         addr

.text              0xba7f0    0x8000000

.ctors                 0x0    0x80ba7f0

.dtors                 0x0    0x80ba7f0

.ARM.exidx             0x8    0x80ba7f0

.itcm                0x17c          0x0

.data                0xa5c   0x24000000

.bss               0x11c40   0x24000a60

.heap                  0x0   0x240126a0

.dtcm                0x20c   0x20000000

.stack                 0x4   0x2000020c

.ram1_d2               0x0   0x30000000

.ram2_d2               0x0   0x30020000

.ram3_d2               0x0   0x30040000

.ram4_d3               0x0   0x38000000

.batram                0x0   0x38800000

.extram           0x233f78   0xd0000000

.qspirom               0x0   0x90000000

.comment              0x49          0x0

.debug_aranges      0x4d18          0x0

.debug_info       0x1185fe          0x0

.debug_abbrev      0x18d28          0x0

.debug_line        0xb861e          0x0

.debug_frame       0x13690          0x0

.debug_str         0x1bc6b          0x0

.debug_loc        0x147070          0x0

.ARM.attributes       0x32          0x0

.debug_ranges      0x1cd48          0x0

Total             0x682922

旧

arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release)

Built Informations:

USING_SYSTEM = BARE_METAL

USING_DISPLAY = USE_OTM8009A_DSI_TFT

USING_DEVBOARD = USE_STM32H747I_DISCO



Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 767104	      0	 767104	  bb480	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 764452	   2652	2383304	3150408	 301248	main.elf

main.elf  :

section               size         addr

.text              0xba8a0    0x8000000

.ctors                 0x0    0x80ba8a0

.dtors                 0x0    0x80ba8a0

.ARM.exidx             0x8    0x80ba8a0

.itcm                0x17c          0x0

.data                0xa5c   0x24000000

.bss               0x11c40   0x24000a60

.heap                  0x0   0x240126a0

.dtcm                0x20c   0x20000000

.stack                 0x4   0x2000020c

.ram1_d2               0x0   0x30000000

.ram2_d2               0x0   0x30020000

.ram3_d2               0x0   0x30040000

.ram4_d3               0x0   0x38000000

.batram                0x0   0x38800000

.extram           0x233f78   0xd0000000

.qspirom               0x0   0x90000000

.comment              0x4d          0x0

.debug_aranges      0x4d18          0x0

.debug_info       0x118608          0x0

.debug_abbrev      0x18d28          0x0

.debug_line        0xb86c1          0x0

.debug_frame       0x1367c          0x0

.debug_str         0x1bc6b          0x0

.debug_loc        0x14786a          0x0

.ARM.attributes       0x32          0x0

.debug_ranges      0x1cdd8          0x0

Total             0x6832f9

同条件ではバイナリサイズが767104->766928とスリムになってますね
速度のほうもおいおい試してみます。

●avr-gccも上がった
avr-gccは有志の方が常に最新ビルドしてくださっており非常にありがたい存在
となっております。サポートデバイスに関してはこちらのエントリで紹介している
方法で新デバイスでも対応可能です。

新

avr-gcc (GCC) 11.1.0

Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 125546	      0	 125546	  1ea6a	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 125406	    140	   5903	 131449	  20179	main.elf

main.elf  :

section                       size       addr

.text                      0x1e9de        0x0

.data                         0x8c   0x802000

.bss                        0x170f   0x80208c

.comment                      0x12        0x0

.note.gnu.avr.deviceinfo      0x40        0x0

.debug_aranges               0xa60        0x0

.debug_info                0x285c5        0x0

.debug_abbrev               0x68ff        0x0

.debug_line                0x31c89        0x0

.debug_frame                0x1ea8        0x0

.debug_str                  0x66d1        0x0

.debug_loc                 0x1f9f9        0x0

.debug_ranges               0x1ab0        0x0

.debug_line_str               0x2a        0x0

Total                      0xab1c4

旧

avr-gcc (GCC) 10.1.0

Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 125628	      0	 125628	  1eabc	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 125488	    140	   5903	 131531	  201cb	main.elf

main.elf  :

section                       size       addr

.text                      0x1ea30        0x0

.data                         0x8c   0x802000

.bss                        0x170f   0x80208c

.comment                      0x12        0x0

.note.gnu.avr.deviceinfo      0x40        0x0

.debug_aranges               0xa60        0x0

.debug_info                0x27c29        0x0

.debug_abbrev               0x6758        0x0

.debug_line                0x3295d        0x0

.debug_frame                0x1ef0        0x0

.debug_str                  0x66e6        0x0

.debug_loc                 0x1f5e0        0x0

.debug_ranges               0x1aa0        0x0

Total                      0xaafb1

バイナリサイズが125628->125546に減ってる！やったー！

一時期は黒歴史にまで落ちたAVRですが私の中で再び復活してきたのでこれからも
STM32の弟分の位置付けて使っていこうと思います！！

というところで2021年最後の記事となります。
来年もこんな感じでぼちぼちと続けていきますのでよろしくお願いいたします！

>ところでねむいさん昔のブログ記事の画像
->そ、それでは皆様よいお年を！！１１！！！！

いろいろ試す49

●OpenOCDでマルチコアデバッグするやり方
竹本様よりコメントでお題をいただいたのでトリプルコア搭載のLPC4370ボード、
LPC-Link2を使って実践してみました。

まずねむいさんのOpenOCDバイナリの/tcl/targetlpc4370_lpclink2_spifi.cfgを
編集します。デフォルトはm4コアしか有効にしていませんがm0subを有効にします。
①と②の部分が編集した部分です。
m0appは電源投入直後は寝ているので今回は省きます。
なお順番が重要でm4コアを必ず先頭に持ってきておきましょう。

まずOpenOCDを起動したらm4コアにアタッチします。insightでつなぎます。
insightではTCPポート3333のm4コアがつながります。

openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/lpc4370_lpclink2_spifi.cfg -c "reset halt" -c"arm semihosting enable"

C:/Devz/ARM/insight/bin/arm-none-eabi-insight --eval-command="target remote localhost:3333" --eval-command="tbreak main" --nx main.elf

Open On-Chip Debugger 0.11.0+dev-00365-g9a9e9e2c6 (2021-08-31-11:31)

Licensed under GNU GPL v2

For bug reports, read

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

Info : auto-selecting first available session transport "jtag". To override use 'transport select '.

Info : clock speed 2000 kHz

Info : JTAG tap: lpc4370.m4 tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4)

Info : JTAG tap: lpc4370.m0_APP tap/device found: 0x0ba01477 (mfg: 0x23b (ARM Ltd), part: 0xba01, ver: 0x0)

Info : JTAG tap: lpc4370.m0_SUB tap/device found: 0x0ba01477 (mfg: 0x23b (ARM Ltd), part: 0xba01, ver: 0x0)

Info : lpc4370.m4: hardware has 6 breakpoints, 4 watchpoints

Info : lpc4370.m0_SUB: hardware has 2 breakpoints, 1 watchpoints

Info : starting gdb server for lpc4370.m4 on 3333

Info : Listening on port 3333 for gdb connections

Info : starting gdb server for lpc4370.m0_SUB on 3334

Info : Listening on port 3334 for gdb connections

Info : JTAG tap: lpc4370.m4 tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4)

Info : JTAG tap: lpc4370.m0_APP tap/device found: 0x0ba01477 (mfg: 0x23b (ARM Ltd), part: 0xba01, ver: 0x0)

Info : JTAG tap: lpc4370.m0_SUB tap/device found: 0x0ba01477 (mfg: 0x23b (ARM Ltd), part: 0xba01, ver: 0x0)

Warn : Only resetting the Cortex-M core, use a reset-init event handler to reset any peripherals or configure hardware srst support.

Warn : VECTRESET is not supported on this Cortex-M core, using SYSRESETREQ instead.

Warn : Set 'cortex_m reset_config sysresetreq'.

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

xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc

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

xPSR: 0xc0000000 pc: 0x555d36cc msp: 0x675f04e0

Info : JTAG tap: lpc4370.m4 tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4)

Info : JTAG tap: lpc4370.m0_APP tap/device found: 0x0ba01477 (mfg: 0x23b (ARM Ltd), part: 0xba01, ver: 0x0)

Info : JTAG tap: lpc4370.m0_SUB tap/device found: 0x0ba01477 (mfg: 0x23b (ARM Ltd), part: 0xba01, ver: 0x0)

Warn : Only resetting the Cortex-M core, use a reset-init event handler to reset any peripherals or configure hardware srst support.

Warn : VECTRESET is not supported on this Cortex-M core, using SYSRESETREQ instead.

Warn : Set 'cortex_m reset_config sysresetreq'.

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

xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc

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

xPSR: 0xc0000000 pc: 0x555d36cc msp: 0x675f04e0

semihosting is enabled



Info : Listening on port 6666 for tcl connections

Info : Listening on port 4444 for telnet connections

Info : accepting 'gdb' connection on tcp/3333

Info : JTAG tap: lpc4370.m4 tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4)

Info : JTAG tap: lpc4370.m0_APP tap/device found: 0x0ba01477 (mfg: 0x23b (ARM Ltd), part: 0xba01, ver: 0x0)

Info : JTAG tap: lpc4370.m0_SUB tap/device found: 0x0ba01477 (mfg: 0x23b (ARM Ltd), part: 0xba01, ver: 0x0)

Warn : Only resetting the Cortex-M core, use a reset-init event handler to reset any peripherals or configure hardware srst support.

Warn : VECTRESET is not supported on this Cortex-M core, using SYSRESETREQ instead.

Warn : Set 'cortex_m reset_config sysresetreq'.

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

xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc

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

xPSR: 0xc0000000 pc: 0x555d36cc msp: 0x675f04e0, semihosting

Info : Found flash device 'win w25q80bv' (ID 0x001440ef)

Info : New GDB Connection: 1, Target lpc4370.m4, state: halted

Warn : Prefer GDB command "target extended-remote :3333" instead of "target remote :3333"

Error: JTAG-DP STICKY ERROR

Error: Failed to read memory at 0xfffff000

接続時のログになりますがTCPポート3333に加えてインクリメントされた
値の3334が追加されます。この3334がm0subのコア用のポートとなります。

お次はgdbを別口で起動します。
"target extended-remote localhost:3334"とします。

m0用のプログラム走らせてないのでsticky-errorは出てますが
m0コアにはしっかりアタッチできております！

こんな感じでマルチコア当たり前になった昨今ですがOpenOCDを駆使して
バンバンデバッグしていきましょう！

20230927追:
KYF39でもうできなくなってしまいました！！！！F**U**CK!!!
●KYF39でSBIネット銀行のアプリ"スマート認証NEO"をインストールする
ねむいさんは元来よりSBIネット銀行を利用しております。
利用状況に応じて振込手数料が無料になる回数が増えるスマートプログラムなるものが
あるのですが今年の４月に大改悪しやがりましてスマホでSBIのアプリを入れてスマート
認証NEOなるものを導入しないと自動的に最低ランクになってしまう事態となりました！！

まぁ素直にスマホにインストールすればと思いでしょうが、ねむいさんが持っている通信
端末KYF39は旧世代の人間向けのガラホでこれは普通の方法ではSBIアプリをインストール
できません！！FUCK!!

というわけでこいつに無理やりSBIアプリをインストールしてスマート認証NEOを設定する
方法を紹介します。windows10環境下で行います。
ここから先は自己責任でお願いします！
(注:私も手探りで行いましたので内容は適宜増強していきます)

1.APKをダウンロードする
まずはAPKをダウンロードしないと話になりません。
KYF39はgoogleplayが使えないのでapkcomboというサイトからapkをダウンロードします。
https://apkcombo.com/ja/zhu-xinsbinetto-yin-xing/jp.co.netbk/

それとSMS認証突破するためにSMSforwarderが必要なのでこれも落とします。
https://apkcombo.com/ja/sms-forwarder-auto-forward-sms-to-pc-or-phone/enstone.smsfw.app/

2.APKインストールまで
すみません超手抜きですがとりあえずこちらの方のわかりやすい手順に倣います。
KYF35をお使いですがandroidなのでやってることは一緒です。

SBIアプリとSMSforwarderのインストール順は特に気にしなくてもよいですが
設定は必ずSMSforwarderから行います。

3.SMSforwarderの設定を先に行う
SMS認証のメッセージを自分のPCのメールアドレスから出すようにフォワードさせます。
メールの送付先は送信に使ったメールアドレスにしておきましょう。

なんでこんなめんどくさいことするかというとKYF39デフォルトの+messgaeで見ようとするとなんと今までやったSBIスマート認証NEOの設定がキャンセルされたことに
なってしまい、先に進めなくなるからです！！！！

4.SBIスマート認証の設定を行う
ログイン名とパスワード、認証用PINコードの設定を行います。
SMSforwarderがちゃんと機能していればPCのメールアドレスにsms認証の内容が
来ますのでそれを打ち込み認証完了です！！！

SBIの管理画面からもちゃんとスマート認証NEOが登録されています。
できた…長い戦いだった…

なお、残念ながらKYF39からは残高確認ができずエラー画面となりますが
肝心の振込操作の時の認証操作については何も問題はないのでご安心ください。

そんなわけで時代から取り残されるとこんな不便な目に遭遇するというほとんどの
方にとってはどうでもいい旧世代型レプリロイドのぼやきでした。かしこ。

2021.08.31 Tuesday
12:43
ネムイ・トリノミアス
MISC
-
-

いろいろ試す48

●最近のOpenOCD更新事情
今年の2月に即効飽きて罪基板になってしまったRaspiPico。
こちらは複数コアを持つCortex-M0+のMCUを搭載しているわけですが、OpenOCDで
使う為にはSWDマルチドロップに対応しないといけません。

現状ではまだRaspiPico専用のOpenOCDを使用することになりますが、OpenOCDの
gerritにはマルチドロップのパッチが上がっており検証が繰り返されております。
なんかもうそろそろmergedになりそうな雰囲気ですので首を長くして待つことに
しましょう。それとねむいさんとこのOpenOCDバイナリは本家とESP32とRaspiPico
の3つに分裂してしまっているのですべて統合してすっきりさせたいものです。

●モノがない…
・半導体製品がない
皆様ご存じの通り、コロナショック以来半導体需要が異常に増加しており半導体
特にマイコンの納期がやたらと延びています。
ねむいさんのところも打撃を受けていて旧三菱系ルネサスマイコンの納期が来年とか
言われてしまい必死になって流通在庫をかき集め何とか糊口をしのいでいる次第です。
STM32とかのCortex-M系ARMマイコンももちろん波及しており品切れになったり納期
延長とかになっていると商社の方に話を聞きました。
電脳おじ様のブログにおいてSTM32の枯渇問題について深く言及されており非常に
参考になりました。

来年になったら状況変わるかも？って楽観的に構えてましたが…

・マテリアルがない
ないわけじゃないんですけどなんかすごい値段が跳ね上がっているのです。
特に銅。先物チャート見ていただければわかりますがこちらもコロナショックを
皮切りに2021年7月末現在も超爆上げしており実物も糞みたいに上がっています。
で、銅の値段が上がると影響するのが電線です！特に太い電線の価格がころっころ
変わっている！もう勘弁してくだち！１１１！！！
そして電線の値段が上がるということは…

・ナイロンもないろん
す　み　ま　せ　ん
ワイヤハーネスとか基板接続用コネクタでよく使用される66ナイロンとかが
ないろんとのことです…
こちらについてはころすけさまのコネクタ納期遅れについてのブログ記事解説に
詳しいです…ちなみにコネクタだけじゃなくってリレーやスイッチとかの機構
がある電子部品やはたまたプラスティックのカバーがあるメカパーツすら納期
が遅れているそうでしかも上にあげた通り金属系も値段上がっているのでプライス
ツインターボ上げ状態で最終製品はマルチプルターボ上げになり我々の給与に
マイナスに作用するといたるがしんじゃうルナ先生理論となっております。
なお最終製品の納期はマルチプルターボにならなくてそのぶんだけねむいさんの
休日が減ります。

そんなわけでワイヤハーネスの制作費用も値段が上がってしまったので自分で
ハーネス打つ機会がなんか増えた気がします…
ころすけ様は2022年まで半導体不足が落ち着かないと予想されておりますが
各企業がパニックになって過剰に抱えた在庫が何年かたって秋月とかに大量に放出
されるんじゃないかなと私も思ってます。特にルネサス。

●FatFsのディレクトリ破壊問題を追う
ねむいさんじつは数年越しでだらだら調査している問題があります。
内容は"FatFsでファイルコピーしたらディレクトリが破壊される"という内容で
下記の条件で起こります。
・128MByteのMMCv3カード
・FAT16でフォーマット(FatFs・Windowsでフォーマットしても同じ結果)
・512Byte以上のファイルをコピーすると発生。それ以下では壊れない。
・SPI互換モード/ネイティブモードの両方で発生する。
・気づいたのは2019年の夏。R0.13から最新のR0.14bまで発生確認済み。

CQ誌のMB618T付録基板のSPIで試したときはこんな感じにです
コピーしたらぐっちゃぐちゃ。

2014年ごろのMB618T向けのプログラム引っ張り出してきても同じ。

STM32H7のSDMMC使ったいつものでも同じ結果に…

FatFs module test terminal for STM32H747XIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Jul 30 2021

>fs



FAT type = FAT16

Bytes/Cluster = 16384

Number of FATs = 1

Root DIR entries = 512

Sectors/FAT = 32

Number of clusters = 7836

Volume start (lba) = 63

FAT start (lba) = 64

DIR start (lba,clustor) = 96

Data start (lba) = 128



Volume name is 128MB

Volume S/N is 4F45-2E91

...

1 files, 558702 bytes.

125376 folders.

124816 KiB total disk space.

96 KiB available.

>fl



----A2020/09/13 22:02    558702  2613.jpg

   1 File(s),    558702 bytes total

   0 Dir(s),  127811584 bytes free

>fx 2613.jpg 1713.jpg



Opening "2613.jpg"

Creating "1713.jpg"

Copying file...

524288 bytes copied at 772 kB/sec.



>fl



DR-SA2019/10/01 11:22    524288  ｳｷｺﾃｱ,;ﾕ.eｿｩ

D-H-A2056/06/21 03:38 140824249  ﾏﾉｴ鹵}.､zE

-RHS-2041/09/15 12:51 3292342498  ｲyｬｫ.ﾓ｡

-R-SA2046/06/09 14:32 4013330094  Eｯ・.ﾈｿ

--HS-2026/08/05 29:30 2671303503  g6ｩﾆ=jﾟ.3

--HSA1991/04/24 14:63 1051517575  yﾞj赧ﾔ｡・

DR---2062/02/16 30:21 2454358133  ・xv!ｳﾘﾝ.｣O･

-R-SA2032/15/27 22:61 1018623284  @・・ｾ・.ﾇW

DR--A2029/04/07 13:40 2681369147  ｦn・ﾆq;ｷ.ｰm

D---A2026/14/27 19:29 2945400368  ｷkﾋ[n>xk.・

-RH-A2068/15/21 07:47 1796965267  }ｲｮｿc_ｲｺ.

DRH-A2015/11/05 09:00 3404787036  &Kvﾋﾝ・.	

-R-SA1993/03/19 20:14 1157293741  ﾀｶ8ﾕ・.ﾄﾓm

D-HS-1980/00/00 00:00         0  :u鈎4_ro.z盧

   7 File(s),2116474074 bytes total

   7 Dir(s),  127287296 bytes free

>fm 0 1 16384



The volume will be formatted. Are you sure? (Y/n)=Y



rc=0 FR_OK

>

ううむよくわからない。
フォーマットとかはちゃんとできるしSTM32F7とかのマスストレージのサンプル
つかってWindows上でコピーは全く問題なしだからローレベルの書き込み操作は
問題ないみたいです。

ていうか今日び128GBのSDの時代なのに128MBの1bitモードしかないMMCとかに
こだわるなよって言われそうですがやっぱ気になっちゃいます。

↑とは関係ないですがGCCバージョンアップにともなうビルド時のワーニング
　発生の問題はR0.14aで修正されておりました。ありがとうございます。

2021.07.30 Friday
23:12
ネムイ・トリノミアス
MISC
-
-

PCベースUSBオシロスコープ PicoScope 5444D MSOを使う

●誰が豚に真珠や
今からさかのぼること10年前、超円高時代に有利な価格で売られていた
Picotech製のUSBオシロPicoscope3206Aを秋月さんより購入し、自作環境の
測定器として使ってきました。

そして2021年、満を持して機能を強化した上位モデルの購入に踏み切りました！！

そして我が家にやってきたPicoscope5444D MSO!
アナログ帯域は個人では十分な200MHzで4CH使えてサンプリングもMAX1GS/Sec、
且つMSO(ミックスドシグナルオシロ)と呼ばれるちょっとしたロジック
アナライザポートも備えています！１！１１１！！

さらに下位モデル3000シリーズの差別化として5000シリーズではFlexResと
言ってハードウエアでサンプリングビット数を最大16bitまで可変が可能です！！

2011年のころは4CHオシロとか200MHzで1GS/Secとか100万越えの奴しか
まともなのなかったはずですが現在では選択肢も増えて価格も
大幅に下がりねむいさんの資金力でも十分に手が届く価格となって
きたので購入に至った経緯があります。

最初は送料込みの総額が一番安いAmazonで買おうかと思ってたのですが
納期が未定になってしまったためヤマト科学という計器卸売の商社さんから
購入しました。
お値段は送料無料の税込み331100円でした。アマゾンも＋2000円ちょっとしか
変わりませんけどねなんというか消費税だけで3万近くもするってめっちゃ
やばいですねああそうだ10年前はまだ消費税5%時代だったからていうかもう
かれこれ10年もたってるじゃんかぁ
あああああああaAあああァああああぁああああ！！１１！！！１１！

…
ｹﾞﾌﾝｹﾞﾌﾌﾝ失礼しました。なお、Picoscopeは英国製のため、ポンド/米ドルと
米ドル/円の為替レートにより日本円で買える値段が大幅に変わりますので
ご注意ください。

20220416追:
今悪性の円安が加速しまくってて37万円以上になってる！１１！！１！！１！！！！！
黒ちゃんはやく円安何とかしてくだち！！！１１１！！１１！！！

20231112追:
今悪性の円安が加速しまくってて45万円以上になってる！１１！！１！！１！！！！！
植田ちゃんはやく円安何とかしてくだち！！！１１１！！１１！！！
RSコンポーネンツでは55万円以上になってます☠

●とりあえず使ってみようぜ
とはいえ以前の3206Aと操作感覚は変わりません。オシロを操作するための
PCソフトは数万の格安モデルから100万越えの最高性能モデルに至るまで
同一のものが使用できます。

4CH全部使用したところです。
3206Aと比べてCHが4つに増えた以外は違いはありませんね★

なお、ねむいさんが買った4CHモデルは外部電源を接続しないと2CHまでしか
使えません。(MSOポートもMAX2CH分扱いで、計6CH分となる)

●Picoscopeの真骨頂プロトコルアナライザ機能を使う
まぁこれも3206Aで紹介してますが改めて。
Picoscopeのソフトは2012年あたりにロジアナのお株を奪うシリアル信号の
プロトコルアナライザの機能が搭載されています。

まずはI2Cバスでやってみましょう。
画像のシリアルデコードの項目を選びます。

オシロのA(CH1)とB(CH2)をSDA,SCLに割り当てました。

I2C信号のやり取りは拙作のSTM32F030-NucleoのI2C液晶とSTTS751の
温度表示プログラムを実行したところです。

CSVファイルに出力して後から解析も可能です。
STTS751の温度データを取得しているところがよく分かると思います。

このプロトコル解析はロジアナポート(MSOポート)でも当然のように使用可能です。
ていうかこのMSOポートはこういう用途に積極的に使うべきですね。

MSOでトリガかけるときは設定方法にちょっとコツがいります。
いちいち設定するのは忘れがちで骨が折れます。

一度こういう特的目的の信号の測定を設定したらファイル->保存で設定ファイルを
保存しそのファイルをダブルクリックで起動すると再び同じ設定で測定が可能です。

このプロトコルアナライザの機能、実はかなり使えます。最初はUARTとI2C
くらいしかなかったのですが、現在はFlexRayやUSB1.1(FULLSPEEDまで)、
SPIも解析可能となり非常に強力なツールとなりました。ちょっとしたシリアル
信号の解析ならロジアナを引っ張り出す必要もなくなりました。

そんなわけでねむいさんが学生時分の頃はまさに"高値"の花で全く手が
出なかったオシロスコープは現在では実務にもバリバリ使えるレベルで個人
でも手が届くような値段で手に入るようになりました。

据え置き型との対比としては"PCがないと使えない"という最大の弱点が
ありますがもはやPCは一家に数台な時代ですしテクトロの1000万クラスの
据え置きオシロも中身はWindowsOSで動いてるまさに一体型のパソコンオシロ
みたいなもんですので個々の環境や測定対象に合わせて使いやすいものを
選択してくのがよいでしょう！

いろいろ試す47

●紫…本当に紫

やったZE！キャプ翼のけぉカードゲッツ！！！

…じゃなくてSandiskを喰ったWesternDigital社が監視カメラ用にリリースした
高耐久microSDカード"WD Purple QD101"をやっとこ入手しました！！！！
128GB品のWDD128G1P0Cの型番の製品です！

Sandiskはブランド名は残ってはいますが産業用/工業用はどんどんWDへと切り
替わってる感じですね～これは一般向けですが。
なお、現在はさらに高性能なQD312なるシリーズも出ているようですが値段がまだ
高すぎるのでまた今度の機会にします…

まずはいつものべんちです。
･･･うーｎ…トランセンドのあれが強すぎて霞んじゃいますね…
※宣伝ではない

おつぎはSTM32H7のいつものでハードウエア情報を読み出します

FatFs module test terminal for STM32H747XIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 19 2021

>fg piano



rc=0 FR_OK

>fo 1 ftbt.mp3



rc=0 FR_OK

>fr 132949600



132949600 bytes read at 16964 kB/sec.

>fs



FAT type = exFAT

Bytes/Cluster = 131072

Number of FATs = 1

Root DIR entries = 0

Sectors/FAT = 16384

Number of clusters = 975280

Volume start (lba) = 32768

FAT start (lba) = 49152

DIR start (lba,clustor) = 4

Data start (lba) = 65536



Volume name is WDD128G1P0C

Volume S/N is E240-C6DE

...

1 files, 132949600 bytes.

124835840 folders.

124705024 KiB total disk space.

4 KiB available.

>ds 0



rc=0

Drive size: 249737216 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 DB 79 00 03 B8 AB 7F 80 0A 40 40 5F  @..2.y.......@@_

CID:

00000000  03 53 44 57 58 31 32 38 80 57 E3 8D AF 01 4C 29  .SDWX128.W....L)



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :WX128

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x57E38DAF

DateCode.Month     :12

DateCode.Year      :2020



OCR:

00000000  C1 FF 80 00  ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 0F 05 19 0A  ................

00000010  00 08 00 00 00 02 FC 00 03 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 45 84 87 00 00 00 00  .E......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :2

SD Security        :4

SD Bus Width       :5



SD_Spec V6.xx!

Detected as SDXC Card!

Available UHS-I Mode.

Available UHS Speed Class U1.

Available SD Speed Class 10.

Available Video Speed Class 10.

Available Application Performance Class2, A2 Card.

A2 CommandQueue Depth 32 Supported

A2 Cache Supported.

>

2020年12月製ですね～。そしてManufacturerIDサンディスク(0x3)のまんまです。
A2グレードだそうですがそれ引き出せられるハードがないです…

ところでWDPurpleQD101は"スマートなストレージ管理"なるものがありそれに
対応するカメラなどで寿命判定を行うことができます。
で、具体的にそれって何といいますとCMD56によるSMART値の取得に
ほかなりません!!!

WD製のSDカードはSandiskの流れを汲むのでCMD56の引数及び得られる構造体は
Sandiskと同じ(0x00000001)で行けます！

Sandiskのころと全く同じなのでとても安心感がありますね☆
ログはこちらに置いておきます。ご参考に。

というわけで一般向けでは安価にお手軽に安定して購入できるWDPurpleを
紹介しました。これからの時代はSDカードには高耐久かつ寿命判定ができる
ものが求められます！皆様もねむいさんのぶろぐを参考にして使用環境に
最適なカードを選んでください！

●国土地理院の地図の利用規約が緩和されていた件
すでに3か月もたってしまいましたが昨年末に毎年恒例の国土地理院の地図のweb
使用許可をもらおうと申請したのですがなんと却下されてしまいました。

なんでも令和元年１２月１０日に地図の利用手続きが改正になり、個人ブログの
登山マップで国土地理院の地図を利用する…つまりねむいさんみたいな使い方
する人は緯度経度等の位置座標のない地図は申請不要となったとのことです。

これはとてもありがたいですね～☆わたしのブログではGPSの軌跡を示す時は
↓みたいな感じで地図画像右下に使用表記をしております。

●最強LDO・LT1963A+3.3V版再降臨
一時期は面実装タイプのLT1963Aの3.3V版が売ってましたが秋月さんが型番を
間違ってて不人気だったのですが、ねむいさんがセラミックコンデンサ使用可能な
A版であることを見出したとたんに速攻売り切れになってしまい長いこと経って
しまいましたが使いやすいSOT-223パッケージになって大復活しました。

デジキで買うよりかは安いですが350円もしますが値段分以上の働きをしますので
ねむいさん激推しです！！！！

●Win10で月例更新のたびに｢Windows更新プログラムを構成できませんでした変更を元に戻しています」ってなって更新に失敗しやがる問題の対処の件
一回なると以後100%失敗するやばいやつ。0x80070003のエラーが出ることが
多いですがこれで検索してもとんちんかんな回答ばっかりorz
ねむいさんも半ばあきらめてましたがやっと対処法を見つけました！！！

やり方
①更新失敗したらC:/Windows/Inf/setupapi.dev.log を開く
②"FAILURE"という文字列を検索。
③検索がヒットした箇所に記載されているフォイルやフォルダを
　C:/Windows/System32/DriverStore/FileRepository内に作成
④たいていC:/Windows/System32/DriverStore/FileRepositoryに入っている
　ドライバをクリーナーソフトとかで強引に削除したりするとこうなるorz
　
こんなんわかるか～！
でも何とかアップデートできるようになりました…

いろいろ試す46(+2020年反省会)

ねむいさんは悪くない全部コロナのせい全部！
反省会終了！

…
さて本題に入ります…

●OpenOCD最近の更新トピック
日々着実に機能を増強しているOpenOCD。ここ数か月の更新でめぼしい更新を
ピックアップしてみます。

１．QSPI/OCTOSPIのサポートがついに公式実装！！
何年待たせたんだYO!
ねむいさん待望のQSPI-ROMのOpenOCDからの読み書き機能がようやく公式に
マージされる運びとなりました。ねむいさんのSTM32F7やH7の作例でmakefile
みたら気付いた方もいると思います。一応以前からパッチを当てたビルドは
公開していたのですがなかなかにっちにな需要だったので表の出さずにして
おきました。

公式マージにあたり、若干の動かし方の差異が発生してましたのでこちらで
吸収しております。

makefileは516行目から、

実際に書き込みに使用するOpenOCDのcfgは私のバイナリ同梱のstm32h7disco_dap_flash.cfg
の170行目くらいを参考にしてください。

実際にQSPI-ROMに読み書きした様子はこんな感じです。
↓mass_eraseの時

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

openocd  -s C:/Devz/ARM/OCD/tcl -f target/stm32h7disco_dap_flash.cfg -c "eraser_qspi"

Open On-Chip Debugger 0.11.0-rc1+dev-00010-gc69b4deae (2020-12-27-08:37)

Licensed under GNU GPL v2

For bug reports, read

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

force hard breakpoints

Info : STLINK V3J4M2 (API v3) VID:PID 0483:374E

Info : Target voltage: 3.219171

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

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

Info : clock speed 1000 kHz

Info : stlink_dap_op_connect(connect)

Info : SWD DPIDR 0x6ba02477

Info : stm32h747xih6.cpu0: hardware has 8 breakpoints, 4 watchpoints

Error: stm32h747xih6.cpu0 -- clearing lockup after double fault

Polling target stm32h747xih6.cpu0 failed, trying to reexamine

Info : stm32h747xih6.cpu0: hardware has 8 breakpoints, 4 watchpoints

Info : starting gdb server for stm32h747xih6.cpu0 on 3333

Info : Listening on port 3333 for gdb connections

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

xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc

Info : flash1 'micron mt25ql512' id = 0x20ba20 size = 65536kbytes

Info : flash2 'micron mt25ql512' id = 0x20ba20 size = 65536kbytes

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:02

↓FontX2ファイルなどのバイナリファイルを書き込んだ時

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

openocd  -s C:/Devz/ARM/OCD/tcl -f target/stm32h7disco_dap_flash.cfg -c "mt_flash_qspi lib/FONTX2/inc/fonts/ILFONT/ILGZ24XF.FNT 0x90010000"

Open On-Chip Debugger 0.11.0-rc1+dev-00010-gc69b4deae (2020-12-31-18:42)

Licensed under GNU GPL v2

For bug reports, read

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

force hard breakpoints

Info : STLINK V3J4M2 (API v3) VID:PID 0483:374E

Info : Target voltage: 3.217121

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

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

Info : clock speed 1000 kHz

Info : stlink_dap_op_connect(connect)

Info : SWD DPIDR 0x6ba02477

Info : stm32h747xih6.cpu0: hardware has 8 breakpoints, 4 watchpoints

Info : starting gdb server for stm32h747xih6.cpu0 on 3333

Info : Listening on port 3333 for gdb connections

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

xPSR: 0x01000000 pc: 0x08050484 msp: 0x20020000

Info : flash1 'micron mt25ql512' id = 0x20ba20 size = 65536kbytes

Info : flash2 'micron mt25ql512' id = 0x20ba20 size = 65536kbytes

Info : Device: STM32H74x/75x

Info : flash size probed value 2048

Info : STM32H7 flash has dual banks

Info : Bank (0) size is 1024 kb, base address is 0x08000000

Info : Device: STM32H74x/75x

Info : flash size probed value 2048

Info : STM32H7 flash has dual banks

Info : Bank (1) size is 1024 kb, base address is 0x08100000

Info : wrote 636586 bytes from file lib/FONTX2/inc/fonts/ILFONT/ILGZ24XF.FNT in 17.585402s (35.351 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:19

QSPIの読み書きに関しての注意点ですが現状は完全安定とは言えず、消去や
書き込みを行う度に電源を投入しなおさなければなりません。
いずれは解決されるでしょうがこの点だけはご留意ください。

２．ST-Linkで16bitのメモリ読み書きが実装される
何年待たせたんだYO!もう7年くらいたってるYO！
今更もう遅いよぅ！！！

FM3のフラッシュコントローラたたく以外に何の用があるのか！？
今となっては使い道が分かりません…

●arm-gcc定期更新
arm-gccも12月に更新掛かってました。
主な変更点はついにGCC10.0になったことでしょうか。

とりあえずSTM32H7のビルドサイズの比較…
↓前回の

arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2019-q3-update) 8.3.1 20190703 (release) [gcc-8-branch revision 273027]

Copyright (C) 2018 Free Software Foundation, Inc.

Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 768116	      0	 768116	  bb874	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 765464	   2652	2383344	3151460	 301664	main.elf

main.elf  :

section               size         addr

.text              0xbaca0    0x8000000

.ctors                 0x0    0x80baca0

.dtors                 0x0    0x80baca0

.ARM.exidx             0x8    0x80baca0

.itcm                0x170          0x0

.data                0xa5c   0x24000000

.bss               0x11c68   0x24000a60

.heap                  0x0   0x240126c8

.dtcm                0x20c   0x20000000

.stack                 0x4   0x2000020c

.ram1_d2               0x0   0x30000000

.ram2_d2               0x0   0x30020000

.ram3_d2               0x0   0x30040000

.ram4_d3               0x0   0x38000000

.batram                0x0   0x38800000

.extram           0x233f78   0xd0000000

.qspirom               0x0   0x90000000

.comment              0x76          0x0

.debug_aranges      0x4d48          0x0

.debug_info       0x186579          0x0

.debug_abbrev      0x1f290          0x0

.debug_line        0xba997          0x0

.debug_frame       0x16ca8          0x0

.debug_str         0x1c2fb          0x0

.debug_loc        0x1439d1          0x0

.ARM.attributes       0x32          0x0

.debug_ranges      0x1dc00          0x0

Total             0x6fab68







> Process Exit Code: 0

> Time Taken: 02:09

↓今回の

arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release)

Copyright (C) 2020 Free Software Foundation, Inc.

Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 770912	      0	 770912	  bc360	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 768260	   2652	2383336	3154248	 302148	main.elf

main.elf  :

section               size         addr

.text              0xbb780    0x8000000

.ctors                 0x0    0x80bb780

.dtors                 0x0    0x80bb780

.ARM.exidx             0x8    0x80bb780

.itcm                0x17c          0x0

.data                0xa5c   0x24000000

.bss               0x11c60   0x24000a60

.heap                  0x0   0x240126c0

.dtcm                0x20c   0x20000000

.stack                 0x4   0x2000020c

.ram1_d2               0x0   0x30000000

.ram2_d2               0x0   0x30020000

.ram3_d2               0x0   0x30040000

.ram4_d3               0x0   0x38000000

.batram                0x0   0x38800000

.extram           0x233f78   0xd0000000

.qspirom               0x0   0x90000000

.comment              0x4d          0x0

.debug_aranges      0x4d20          0x0

.debug_info       0x118dd1          0x0

.debug_abbrev      0x18cba          0x0

.debug_line        0xb91af          0x0

.debug_frame       0x13678          0x0

.debug_str         0x1bc3c          0x0

.debug_loc        0x14a497          0x0

.ARM.attributes       0x32          0x0

.debug_ranges      0x1cd68          0x0

Total             0x687fd4







> Process Exit Code: 0

> Time Taken: 02:07

う”…サイズ増えてる…

実はちょっと困ったことがあってGCC10.0に上がったせいでChaN氏のFatFsで
ワーニングが出ちゃっています。

↑2048行目でワーニングが出てしまっています。
これは配列のインデックスが0からさらにデクリメントされる
コードが実行されると推測されてときに発動されるようです。

	/* itoa (hexdecimal) */

	i = 7;

	do {

		c = (BYTE)((seq % 16) + '0');

		if (c > '9') c += 7;

		ns[i--] = c;

		seq /= 16;

		if(i==0) break; /* Nemui */

	} while (seq);

	ns[i] = '~';

↑インデックスが0の時の判定文追加してお茶を濁してます…
ChaNさんこれ見てたら効果的なワーニング対策お願いします！１１！！！

あとこれは気にしないでいいらしいです…

それとSTM32F7discoveryにおいて最適化の問題に引っかかって正常に
LCDが表示されなくなる現象が発生してしまったのですがpragmaで最適化を
切って対処してます…もっといい方法があるかもしれませんが今はこれが
最適解…

●秋月でSTM32G0、STM32L0追加！！
なんと秋月さんよりSTM32L0と8pinのSTM32G0が追加されてます！！

実はすでに入手して動作確認も行ってますがここで話すには多すぎる
内容ですので次回以降にこうご期待！！！！

●安価なAVR128DA48評価ボードゲッツ！

AVRの正当進化系のAVR128シリーズ。
AVR128DA48の超格安の評価ボードを手に入れました！！
その名もAVR128DA48 Curiosity Nano！！！
しかも電圧変換機能を持ったmEDBGつき！！

もうAVRライタは作る時代から安価で買う時代に変遷してしまいましたね～

ちなみにavrdudeはビルドインされたmEDBGとAVR128シリーズには対応して
なかったのですが神パッチによって自由自在にできるようになっております！！

こちらもSTM32G0と同じく来年みっっっっっっっっっちりと特集させてもらい
ますので期待してお待ちください！！

と言いたいところですが先行でAVR128DA48 Curiosity Nanoに対応した
avrdudeを公開しております！！！
興味がある方はどんどん使ってください！！！

…というわけで今年も駆け込みでばたばたしてしまいましたがたくさん
買い込んだマイコンやセンサ基板とかの評価も来年も進めていきたいと思います…
皆さまもよいお年を～

>ねむいさん‥‥DropBoxの見えなくなった画像ﾉﾎｳﾊ…
来年から本気出す！！！！！１！！

いろいろ試す45

●ねむいさん、Facebookでちゃちなスパムに引っかかる
ッッすんませんでしたぁあああああああああああああああああああ
あああああああああああああああああああああああああ！！１１！！１

既に関係者に謝罪、パスワードも変更、乗っ取られて投げてしまった
スパムも全部削除しました…

加えて次にトイレ行くまで自分自身を腹パンし続ける刑を科しました
(↑サイバラりえぞう師匠風に)

メールやメッセージで教えてくれた人ありがとうございます。
ねむいさんもまだ見捨てられてなかったんやなぁって…(ｽﾋﾞﾋﾞ

●BSCH3V更新
かれこれ15年以上愛用している水魚堂さんのBSCHが更新しておりました。
4年ぶりですね…もう4ねんも…
ｹﾞﾌﾝｹﾞﾌﾌﾝこれからもよろしくお願いします。

●OpenOCDの更新状況について
現在もOpenOCDのx86版バイナリを当ブログで提供し続けておりますがESP32専用版も
バンドルした体制になってから時間も結構経ちました。
頻度は往時と比べてかなり落ちていますがねむいさんのバイナリ更新ポリシーとしては
以下の優先順位で更新を続けております。
1.OpenOCD本家のgitでパッチがマージされた場合
2.libusbが新しいパッチが追加され更新した場合
3.libusbに付随するライブラリ(libftdi/libjaylink)が更新した場合
4.ESP32版OpenOCDのgitにパッチがマージされたとき

ぇーっとですね…最近libusbのパッチがマージされて更新したのですがこのビルドの
"libusb.dll"を使うとなんか変に…

↑変なマイナスの数字出してエラーで止まる…

↑正常動作はこんな感じ
libusbがらみは問題の追及にすごい時間かかるんですよね…
しばしの間OpenOCDは0922版でがまんしてください…

進展があったらここのエントリを更新するつもりです。
20200930追:
libusbのcommitを追っていったら怪しいやつがありました。
さらにlibusbをデバッグビルドしてログを出すようにして追っかけてみました。

さっきのコミットが当たったところ、具体的に言うとhandle_event_trriger()で
詰まっているのが分かりました。
この修正箇所だけをひとつ前に戻したパッチを適用してビルドしたものを更新しました。
ねむいさんのところで試した限りでは問題はなかったですがうまく書き込みできない
等がありましたらご連絡お願いします。

20201105追：
直りました。

●マイコン用I2Cライブラリのレストア
先月はラズパイZeroWでI2Cデバイスを動かしてみましたがSTM32F0向けのI2C
ライブラリもS-5851AAAを追加してブラッシュアップしました。
ブラッシュアップに当たりローレベル層のSTM32のハードウエアI2Cの
コーディングが悪かった事が6年越しで判明したのでこちらも修正しましたorz

STM32のI2CってF0/F3リリース以降の品種は取り扱いが結構面倒臭くなってHAL
ライブラリ使っても思ったように動作してくれないことがあるんですよね～
いつも自分でオシロで波形確認しろと言っておきながらめんどくさがってちゃんと
確認しないからこうなった。次からちゃんとやります。

(※室内温度)
それにしても夏すぎる暑だった…

いろいろ試す44

●SDUCの悲劇
今年の五月くらいにSD SpecificationがV7.10に改訂されてSDUCの詳細が
分かりましたがChaN師が危惧していた通り…

ついに来てしまった…電子工作のお供SPI互換モードが…

あああああああああああああああああああ！！！

てわけでSDUCではSPI互換モードでは使用できず、ネィティブモードのみのアクセスと
なります。2TB以上のアクセスを実現するためにCMD22が新設されました。

SDUCを見分けるフラグはACMD41で新設されました。

また、CSDストラクチャーのバージョンからも判別できます。

実際まだ2TBのカードすら実用的な値段で手には入らないので向こう5年くらいは
心配はいらないと思いますし、業務用機器の需要に応じてSDSC,SDHC,SDXCのカードも
作られ続けるでしょうから電子工作用途では32GB以下のカードを買っとけば不自由は
しないと思いますよぅ。

●ARM-GCC更新の件
忘れたころに更新していました。GCC9.3.1になって2020-q2-update Releaseです。
ねむいさんが気づくの大体１か月以上たった後なのですが。

導入して８月中使ってみましたが今回は目立ったバグはなく、そのまま差し替えて
安心して使用できます。

●AVR-GCCも更新の件
AVR-GCCも少し前に更新しておりました。

こちらはGCC10になっています。
WinAVRが消滅してはや10年、Atmelもmicrochipになった昨今ですが個人の有志が
AVRのCコンパイラをメンテしてくれているのは本当にありがたいですね。

●RaspberryPiZeroWはぢめました

ラズパイ系は別記事にしたほうがいいのかなといつも思ってますが業務でラズパイZero
を(というかpythonを)使ったパフォーマンスをした折にねむいさんも個人で所有したく
なってしまいうっかり購入してしまいました☆

CPUはMicron製の奴ですね～
型番ちゃんと調べてないのであとで追記します。

小さい基板にwifi機能も搭載です！

てわけでRaspbianをインストールして無理やり起動！！！
Raspi4みたいにVNCでつながってリモート操作ももちろん可能でさらにインター
ネットも見られちゃう！！！…512MBしかメモリがないので重すぎて使用に
まったく耐えられませんが…

ラズパイZeroの利点は小さいことと消費電力の少なく小回りが利くことにつきます。
基本的なライブラリは全部おぜん立てされているのでpythonでサクッとI2Cデバイスが
動かせちゃいます。
画像は温湿度センサSHT20。有志がこのデバイスのライブラリを公開してくれてるので
ありがたく使わせて貰いました…！

SHT20と秋月で購入できるS-5851AAAを同時使用してみます。S-5851AAAに関してはSTTS751のライブラリを改編して使わせてもらいました。

ラズパイ4と比べると重たいですがVNCでリモートで操作できるのでちょっとした
リモートセンシング環境がサクッとできちゃうのは本当に便利ですね～

食わず嫌いしてたラズパイですができることが広がってくるとがぜん興味が
湧いてきましたよぅ☆

またラズパイZeroのwifi接続でVNC立ち上げまでは
以下のサイトを参考にさせていただきました。ありがとうございます。
http://hara.jpn.com/_default/ja/Topics/RaspPiZero.html
http://srlt.blog.jp/archives/9991491.html
http://blog.robotakao.jp/blog-entry-132.html

いろいろ試す43

10万円来た！これで勝つる！！
住民税と自動車税払った！おしまいっ！

●ラズパイ4でもS.M.A.R.T.をゲッツする
すみません坪井さんの記事のぱくりです…
つぼいさんはOSイメージを書き込みmmc-utilsを改造して/dev/mmcblkから
ダイレクトにCMD56を送り込みS.M.A.R.T.(以下SMART)をゲッツされております。

ねむいさんは前回のノウハウを使ってUSBマスストレージ経由でゲッツします。
TranscendさんよりLinuxのコマンドライン版ソフトのソースコードも提供して
いただいておりましたので。

ラズパイOS｢Raspbian｣は標準でGCCコンパイラが収録されており、ねむいさんの
大好きなmake一発でsdsmarttoolをビルドできました。
ちなみにこのツールはUSBマスストレージ経由でscsiコマンドを流し込むので
OSイメージがある/dev/mmcblkは指定してもコマンドが通らずエラーになります
scsiコマンドに組み込まれたCMD56が通るRDF-5が必須となります。

というわけでラズパイからでもTranscendのSMARTを無事取得完了しました。
パース結果がめちゃくちゃですがこれは最新のUSD230Iは過去の産業用SDの物とは
SMARTのデータ構造が違うためです。ひとまずDeviceHealthだけ合わせました。
ここに至るまでwindowsのコマンドラインとの違いやpermissionに引っかかりまくり、
ガチドザのねむいさんにはそっちの方がちょっと辛い作業でした。

前回紹介した通りRDF-5は特殊なscsiコマンドを通じCMD56を特別に通すように
出来ているのでTranscend製品だけじゃなく、その他のSMART搭載の製品でも
余裕で使えます！ここもパースは放棄したやっけつです

ぇ…ところでもったいぶらないで肝心の引数教えてほしいですって…！？
ぇーっと確かちょうどSTM32H7のいつものを更新したのですがねむいさん謹製の
SDMMCドライバのヘッダファイルとか見たらイカス16進数に巡り合えるかも…
ここから先は君の眼で確かみてくれ！

●ラズパイ4のSDカード別起動時間比較
ラズパイのコマンドラインから起動時間を測定できるのでTranscendとMicronで
比較してみました。

↑Transcend

↑Micron
確かにTranscendのほうがちょっと早いですが…MicronもA1クラスでチマチマ読み
書きは十分すぎるくらい早いので劇的な差は無いみたいですね。
ていうかhciuart_serviceとかいうのがめっちゃ時間喰ってます…こいつ削ったら
もうちょっと起動早くなりそう…

●ARMマイコンビルド環境構築手順をようやくWin10に対応
読んで字の通りです…長年放置しておりましたがようやく完全対応いたしました。
・ビルド編
・デバッグ編
デバッグ編のwin10でInsightがまともに動かない問題は直接引数渡して解決です。
過去にWin7で同様の事象に出くわした方がいてねむいさんのWin7環境では発生して
無かったので正直スルーしておりましたがもうちょっと早く気づいていれば…
すみませんでした。

●京都のマルツ閉店
うあああああああああああああああああああああああああ！１１１！１１１！
副業(本業は虹裏メイド)の帰りに大阪日本橋に寄る以外ないのか

Transcendの産業用microSDカードUSD230Iシリーズを試す

20200617追:最後のほうにSMARTツールの追記あります

だいぶ前のコメントでTranscendの産業用SDとかどう？とネタをいただいたのですが
なかなか手が伸びず放置状態となっていたのが超進展しましたのでお知らせします。

2020年現在、Transcendの産業用SD/microSDカードはamazonで一般でも購入可能
です。ねむいさんも入山料を払い、登頂を開始しました！決して企業案件ではない!!!!

今回購入したTS32GUSD230IはSLCモードを搭載した高耐久性を誇る230Iシリーズに
今春新たに8~64GBの容量が追加された最新のモデルです！

さて、工業用/産業用では高い書き込み耐久性を求められますが本製品は3D-TLC
NANDのビットセルを疑似的にSLCみたいにして使う疑似SLC方式を取っております。
なんとTBWは32GB品で1400、64GB製品では5800に及び過去に紹介したマイクロンの
microSDでは容量最大の256GB品でも180TBWだったので破格の耐久性ですね。
この耐久性を実現しているSLCモードはTranscendさんの公式ﾋで解説がありますので
皆さんもよく目を通しておいてください。

んでもって230Iシリーズで使用している3D-TLCNANDも最新の製造プロセスのBiCS4が
使用されているとのことで(今春追加された8GB以上のモデルで適用されていると
思われます)、容量速度耐久性がここまで大幅に上がったと思われます。

というわけでとにもかくにもPCからベンチマークを取ってみました。

はい、御覧の通りとんでもなく早いです。特に4kの読み書き！
マイクロン産業用
 サンディスク産業用
 キオクシア高耐久
 サンディスク超高耐久
↑と比較してもチマチマ4k読み書きがスバ抜けて早いのがわかりますね～
シーケンシャル書き込みもピカ一です用途としてはドラレコや監視カメラにすら
もったいないくらい、まさに組み込み用PCの起動イメージにするべき逸品です！

お次はいつものでSDカード内のハードウエア情報を読み出します。

●TRANSCEND Industrial Class10 UHS-I V30 U3 A1 TS32GUSD230I

FatFs module test terminal for STM32H747XIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : May 22 2020

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read at 21046 kB/sec.

>fs

FAT type = FAT32

Bytes/Cluster = 32768

Number of FATs = 2

Root DIR entries = 0

Sectors/FAT = 7534

Number of clusters = 964256

Volume start (lba) = 8192

FAT start (lba) = 9508

DIR start (lba,clustor) = 2

Data start (lba) = 24576



Volume name is USD230I_32G

Volume S/N is BDB6-0F99

...

1 files, 132949600 bytes.

30856192 folders.

30726080 KiB total disk space.

964256 KiB available.

>ds 0

rc=0

Drive size: 61736960 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 EB 81 7F 80 0A 40 00 C1 @..2[Y.......@..

CID:

00000000  74 4A 60 55 53 44 55 31 20 19 00 57 30 01 44 23 tJ`USDU1 ..W0.D#



Parsing SD CID Register

Manufacturer ID    :0x74

OEM/Application ID :J`

Product Name       :USDU1

Product HwRev      :2

Product SwRev      :0

Serial Number      :0x19005730

DateCode.Month     :4

DateCode.Year      :2020



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 04 00 90 00 08 11 39 1E ..............9.

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.

Available UHS Speed Class U3.

Available SD Speed Class 10.

Available Video Speed Class 30.

Available Application Performance Class1, A1 Card.

SDSpecは5.xxでA1クラスで各スピードクラスもそろっていますね。
しかも2020年4月の出来立てほやほやの奴です☆
Manufacturer IDの0x74はJiaElec(Transcendの製造協力会社)を示しています。
TranscendはシリアルナンバでRMAの管理をしていますがカードから読み出す上記の
シリアルナンバはそれとは別物であくまでカード表面に記載された番号でなければ
なりません。ご注意ください。

さて、こっから本番ですが230Iシリーズは当然のごとくS.M.A.R.T.(以下SMART)
が搭載されております。搭載されているから買いました！！！
そして肝心のSMART値を得るためのCMD56のアレですがなななななんと!!!!
Transcend embedded様の特別のご厚意により特別に教えていただけることに
なりました！！！！ありがとうございます！！！！

STM32H7のいつものを使ってCMD56でSMARTを読み出してみました。
肝心のCMD56の引数ですがmicronの奴に酷似しているとだけ言っておきます。
多分7月更新のいつものには反映してると思いますのでお待ちください。

何はともあれ"Transcend"のプロダクトマーカーの存在が確認され、SMARTの読み
出しが成功しているとわかります。

SMARTの目玉、カードの寿命ですがTranscendでは70バイト目に存在しています。
まだ使い始めなので100(%)ですね。
読み出したデータはこちらに。4GB以下のモデルと8GB以上のモデルでは同じ230I
シリーズでも細かいスペックやSMARTの構造体が全く違うのでご注意ください。
これからは8GB以上の奴使っていけば間違いはないでしょう。

というわけで払った対価の以上のスペックを持つこのUSD230I、大事なことなので
二回言いますがラズパイとか産業用PCなどのタフな環境で動くOSの起動イメージに
大活躍できそうですね☆

・おまけ(内容だいぶ改訂)
なんとWindowsからSMART読み出せるツールまで提供していただきました…！！
DELKINの奴みたいに特定のセクタアドレス読み出すことでSMART取得できるのか！？
と期待したのですが…

残念ながらそううまくはいかなかったorz
使用しているカードリーダーがサンワサプライの汎用のカードなのでダメなのかなと
思ってTranscendさんに聞いてみるとツールが発行するCMD56を解釈できるRDF5なら
できるとのこと。さっそく購入して試してみました。

購入費用888円が無様に爆散したorz(昔買ったRDF8でもダメだった)
TS-RDF5のファームウエアバージョンは"TS3A"ですが多分特定顧客向けの特殊ファーム
じゃないとダメっぽいですねorz
もしくはCMD56通ってたけどねむいさんが購入したTS32GUSD230Iが新しすぎてSMART
読み出せるツールで対応してなくて撥ねられちゃったか。
エラーログには"Write IO Control Fail, Error Message is:6"って記録されていました。
やはりSD SMART TOOLのバージョンが低いとのことで差し替えたら
ちゃんと動作しました。一番下参照。

当然この程度で諦めるねむいさんではない。
STM32F7DiscoveryのUSB-MSC使ってSMART読み出せるツールが投げるSCSI
コマンドを捕まえてみました。するとUSB-MSCではまず使用しない0xD1なる
コマンドが…このコマンドの構造体を掘るとCMD56で投げるべき引数が
ずらずら出てきました…
なるほどそういうことか…！やっぱカードリーダ側でこれが解釈できる
奴じゃないと🙅なんだ。

これってUSBカードリーダーじゃなくてバス直結のSDA標準準拠SDカード
ホストコントローラードライバ使うようなタイプのカードリーダーなら直に
scsiコマンド送れるからうまくいくのかしらと思ったり逆にCMD56こういう
方法でUSBマスストレージ経由で送れるなら専用のファームとソフトを
こしらえるだけでTranscendだろうがsandiskだろうがmicronだろうがWindows
からいけるやんけと思いましたがそんな手間かけるなら素直に
マイコンで読み出せば簡単やんと安きに流れるねむいさんの情けない性格を
露呈させたところで本日の記事を〆させていただきます。
かしこ。

20200616追:
Transcend Embedded様から最新ソフトもらったので試合続行１１！！！！！１１１

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!(※管理者権限で実行してください)
か…勝った…！
いくつかカードリーダー試しましたがTranscend製のTS-RDF5とTS-RDF8だけが
正しくCMD56を解釈できるのがわかりました。性能はそこそこですが価格も安く
入手もしやすくTranscend製産業用SDのSMARTも読めるのでこちらもおすすめです！

いろいろ試す42

6月になるというのに10万円まだ来ないよ

●Windows10でラズパイ4の起動SDイメージをバックアップ/レストアする
意外とネット上になかったのでねむいさん流のやり方を残しておきます。

使うアプリケーション
・バックアップ
　DD for windows
　R2のほうはまだベータ版で動作しないので(ねむいさんとこもダメ)旧番の
　Ver.0.9.9.8を使用してください。
・レストア
　balenaetcher
　かつてラズパイの初期イメージ書き込み用に推奨されていたものです。
　こちらはzip圧縮したイメージも展開して書き込みができるのでディスク容量の
　節約になります。
　
・DDwinでバックアップのやり方

RaspberrypiのOSがインストールされたmicroSDをUSBカードリーダーに指して
Windows10から認識させます。ラズパイのOSイメージが仕込んであるmicroSDは
bootというラベルが付いたFAT32のパーティションと本来のラズパイのOSがある
ext4があります。Ext2fsdなどのソフトをインストールしてない限りはフォーマットを
求められてしまうのでうっかりフォーマットしないようにして無視しましょう。

DDWinを管理者モードで起動します。管理者でないとドライブを認識できません。

｢ディスク選択｣でラズパイのOSのインストールされたmicroSDカード(bootのラベルの)
ドライブを指定して｢ファイル選択｣で保存先ディレクトリとファイル名を決定して
｢>>読み込み>>｣ボタンを押すとバックアップ開始です。

DDwinはlinuxのddコマンド宜しくディスク上のデータを1セクタずつ最初から
最後まで読み取ります。そんなわけでバックアップはSDカードの容量が大きければ
大きいほど悠久の時間がかかります。
時間がかかりますが確実です。こいつで読みだしたイメージは容量さえ足りれば
どんなmicroSDにも書き出すことができます！
sudo apt-updateの前は保険でバックアップしておくとよいでしょう。

さて、読みだしたデータはmicroSDのカード容量ぶん馬鹿正直に読み出すので
32GBのカードならなんと32GBのサイズになっちまいます！！！
こんなものそのまま置いておけないのでとっとこzip圧縮します！！
zipで固めるとラズパイOS｢Raspbian｣フルセットでも4GBちょっとに収まります。

・balenaetcherで書き戻す


さっきのzip圧縮したイメージをターゲットのSDに書き戻す！！！

展開しながら書き込んでくれます。

書き込みとベリファイ終わり。終わった瞬間にまたwindowsからフォーマットを
求められてしまうのでうっかりフォーマットしないようにして無視しましょう。

ラズパイ本体に描き戻したmicorSDを指して無事起動。
おしまいっ！めでたしめでたし。とっても簡単だ！

というわけで複数のツールと手間はかかりますが確実に起動可能なイメージが
保存/書き込みできますので変な設定してラズパイが起動できなくなった時の復帰
手段として覚えておいて損はありません！

●最近続々出だした高耐久SDカードの性能を見る

まずはTOSHIBA製の高耐久128GBカードEXCERIA THN-M303E1280A2(以下M303E)です。
ねむいさんがこのカードを手に入れたころにはTOSHBAメモリからKIOXIAに名前が
変わってしまいましたが(2019.10.01)、昨年の夏に世に出たようです。
SDSpeedClass10、UHS-I U3、VideoSpeedClass30,ApricationClass1(A1)の
規格や-25~+85度の動作環境温度を満足しており、さらに6,000時間の書き込み保証を
しているそうでドラレコや監視カメラに最適なカードとうたっております。

まずはWindows上からベンチを取ります。

チマチマ書きもめちゃくちゃ早いですね。ラズパイのOS用にも良いでしょう。
マイクロンの物と比べるとちょっと遅く感じますがこの数値でも十分早いです。

お次はSTM32H7からカードの情報を読み出してみました

FatFs module test terminal for STM32H747XIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : May 31 2020

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read at 22726 kB/sec.

>fs

FAT type = exFAT

Bytes/Cluster = 131072

Number of FATs = 1

Root DIR entries = 0

Sectors/FAT = 16384

Number of clusters = 944384

Volume start (lba) = 32768

FAT start (lba) = 49152

DIR start (lba,clustor) = 4

Data start (lba) = 65536



Volume name is M303E_128GB

Volume S/N is 78EB-41E0

...

1 files, 132949600 bytes.

120881152 folders.

120750336 KiB total disk space.

4 KiB available.

>ds 0

rc=0

Drive size: 241827840 sectors

Erase block size: 16384 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 03 9A 7F 7F 80 0A 40 00 AF @..2[Y.......@..

CID:

00000000  02 54 4D 44 52 31 32 38 74 07 63 06 A1 01 3C 03 .TMDR128t.c...<.



Parsing SD CID Register

Manufacturer ID    :0x2

OEM/Application ID :TM

Product Name       :DR128

Product HwRev      :7

Product SwRev      :4

Serial Number      :0x076306A1

DateCode.Month     :12

DateCode.Year      :2019



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 A0 00 20 07 3A 1E ............ .:.

00000010  00 08 00 00 00 01 00 00 01 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 C5 84 43 60 03 40 1A ...C`.@.



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :1

SD Security        :4

SD Bus Width       :5



SD_Spec V5.xx!

Detected as SDXC Card!

Available UHS-I Mode.

Available UHS Speed Class U3.

Available SD Speed Class 10.

Available Video Speed Class 30.

Available Application Performance Class1, A1 Card.

>

単純な読み出しはSDHighSpeedの限界値まで出てますね～
また、SdSpecはV5.xxで各種規格はスペック通りに満たしているとわかります。

お次はSANDISK製(ここはWestanDigitalになっちゃいましたが)のMAX ENDURANCEと
謳う超高耐久microSDカードSDSQQVR-064G-GN6IAです。
なんと30,000時間の書き込み(128GBはその倍)を保証し-25～85度の動作温度保証
とSDSpeedClass10、UHS-I U3、VideoSpeedClass30の規格を満足しています。
アプリケーションクラスは無いみたいですね。こちらもドラレコや監視カメラ
の連続書き込み用でチマチマ書き込みはそれほど得意ではないのかも！？しかし…

とりあえずベンチ。

あれ…TOSHIBAのより性能高い…！？チマチマ書きもA1クラス保証の奴よりいいぞ！？

STM32H7からカードの情報を読み出すとその理由が判明！

FatFs module test terminal for STM32H747XIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : May 31 2020

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read at 21631 kB/sec.

>fs

FAT type = exFAT

Bytes/Cluster = 131072

Number of FATs = 1

Root DIR entries = 0

Sectors/FAT = 16384

Number of clusters = 486992

Volume start (lba) = 32768

FAT start (lba) = 49152

DIR start (lba,clustor) = 4

Data start (lba) = 65536



Volume name is SQQVR-064G

Volume S/N is D6EA-C58C

...

1 files, 132949600 bytes.

62334976 folders.

62204160 KiB total disk space.

4 KiB available.

>ds 0

rc=0

Drive size: 124735488 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 DB 79 00 01 DB D3 7F 80 0A 40 40 F9 @..2.y.......@@.

CID:

00000000  03 53 44 53 48 36 34 47 80 17 A7 01 58 01 41 A1 .SDSH64G....X.A.



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SH64G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x17A70158

DateCode.Month     :1

DateCode.Year      :2020



OCR:

00000000  C1 FF 80 80 ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 0F 05 39 1E ..............9.

00000010  00 08 00 00 00 02 FC 00 03 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 45 84 87 00 00 00 00 .E......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :2

SD Security        :4

SD Bus Width       :5



SD_Spec V6.xx!

Detected as SDXC Card!

Available UHS-I Mode.

Available UHS Speed Class U3.

Available SD Speed Class 10.

Available Video Speed Class 30.

Available Application Performance Class2, A2 Card.

A2 CommandQueue Depth 32 Supported

A2 Cache Supported.

>

御覧の通りなんとA2カードだった！？SDSpecもV6だし間違いない！！！

というわけでMAXENDURANCEを誇るSANDISKの超高耐久カードはカタログスペック
以上の規格を備えた高性能カードでもあったことがわかりました！！！

お値段的には202005時点では同容量では性能が若干劣るTOSHIBAのほうが安いです。
購入の際は価格対効果を考慮して自分に合ったやつを使っていきましょう。

(※STM32H7から読みだしたときに"FAT type = FAT0"とあるのはChaNさんのサンプル
　からポーティングした時のバグです(FAT0ではなくexFAT)。
　6月定期更新で修正します。)
20200531修正しました

いろいろ試す41

駄目だ…コロナのせいで休業になってブログ更新の時間獲れると思ったら逆に
労働時間パワーアップしやがった…(←言い訳)

●Raspberrypiはぢめました
年末に欲張りセットを買ったきりになってましたがわずかな時間を見つけて
ねむいさんもようやく手をつけてみました！！

RaspBerrypi4 modelB 4GB
Raspberrypiの4世代となるボードだそうで主に下記のぱわふりゃーなハード
ウエアが搭載されています。
・gigabit ethernet
・USB3.0
・HDMI dual Display
・Bluetooth4.2
・wifi(速度不明)

もうなんというか普通のPCですね…

CPUはCortex-A72プロセッサの｢BREADCOM BCM2711｣だそうです。

メモリはこのモデルの最大値の4GBの奴を選びました。

Bluetoothとwifiがあるので当然国内の電波法には対応しておりしっかり
技適は獲れてますね…誰がAHOや！

また、電源は今はやりのUSBType-Cコネクタからとります。当然要求される
電流値もぱわふりゃーなヤツで5V/3A以上が最低条件です。
ねむいさんは電圧降下が考慮された5.1V/3Aのスイッチングアダプタを購入
しました！

消費される電流値から放出される熱量を考慮してヒートシンクケースも
アマゾンで購入しております。そんでもってHDMIに対応した480x800のTFT
液晶モジュールも購入してありますので準備万端です。

Raspberrypi4はボード上にeMMCとかはなく、SDカードからの起動オンリーと
なっています。
OSイメージの書き込み方は｢raspida.com｣様の手順に倣いました。
OSは"Raspbian Buster with desktop and recommended software"を選択
して"balenaEtcher"というwindowsのソフトでSDカードにイメージを書き込んで
いました(が2020年4月に公式の書き込みソフトが配布されたようです)

てなわけで電源投入！！

…

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

キーボードはまだないですがマウスでなんとか操作できますがここまで行けました☆

そんでもってwifiからねむいさんのメインPCのモバイルホットスポット経由でVNCで
リモート接続、そしてメインPCからRaspiのブラウザを操作して…

虹裏に自分が建てたスレッドにも投稿成功！

とりあえずねむいさんがやりたかったことはできました…！
ぇ？これからのことどうするって！？それはこれから考えます！！！！！

●Win10のモバイルホットスポットをまともに動かすためのメモ
Windows10にはかつてのSoftAPに相当する機能が簡単に利用できる"モバイル
ホットスポット"なるものが存在しますがなんでかすぐにへそを曲げてしまい、
思ったような動作になりません。

Raspberrypiをwifiで接続しようとしたとき引っかかったのですがIPアドレスが
164.254.***.***というローカルリンクアドレスとかいうやつになってしまい、
このアドレスになっちゃうと外部のネットにつながりません。

で、モバイルホットスポットのメインPCで↑にならないための事前準備など

1.IPv4で接続する、IPv6は停止する(最優先)
2.こちらの方のの設定手順を実行する。SNPの設定は重要。

終わり。
これでwifi/bluetoothから安定してモバイルホットスポットが使用できるように
なります

が、もし再発してしまった場合はまずは下記の操作をしてください。
１．デバイスマネージャー起動 ->表示->非表示のデバイスを表示
２．"Microsoft Wi-Fi Direct Virtual Adapter #(数字)"を全部削除！
　　
３．また、wifiアダプターで使用していなくて非表示になってるやつも削除！
４．PC再起動
これでほぼ何とかなります。Bluetoothでもこの現象が出ることがあり、大抵
USB接続のBluetoothドングルを別のUSBポートに繋げたらなってしまいます。
この場合は落ち着いてデバイスマネージャーから非表示になっている奴を
消すと改善します。Win10のモバイルホットスポット機能は動作の安定性は低い
ですが対処法さえしってしまえば強力な武器になると思います。

いろいろ試す40

オイオイなんかコロナウイルスのせいで色々ものごっつ酷くなってますね
皆様におかれましても外から帰ったら手洗いうがいの徹底は忘れずに…

●InsightがWindows10でまともに動作しなくなっていた
ビルド190xになってとうとうGDB-Insightがまともに動作しなくなってしまいました。
具体的に言うと"TargetSelection"のところで何か設定やって抜けようとした瞬間に
固まりやがりますorz互換性オプションいじっても一切駄目orz

もちろんこの操作を行わないとOpenOCDと接続できないため、こちらで紹介した手順
が全く役立たずになってしまうのですが…

実はこれ逃げ道があります。InsightはGDBと一体化しているのでプログラム起動時に
リモート接続でOpenOCDが開いたポートに接続しに行くようにコマンドラインの引数を
与えてやればよいのです。
具体的に示すと

arm-none-eabi-insight ¥

 --eval-command="target remote localhost:3333" ¥

 --eval-command="tbreak main" --nx ¥

 main.elf

これでおしまいっ！
しかしながら私の以前の手順ではmakeからOpenOCDとInsightの同時実行をするため
Windowsのcmd.exe経由でInsightを起動していたせいで"--eval-command=hoge"が
Insightにちゃんと渡らなかったので(ほかの方法を知らなかったので)一旦Insightの
TargetSelectionの項目を開いて設定をやっておりました。

そしてつい最近にmakeの-2jオプションを指定すればmakeからOpenOCDとInsightを
平行実行できることに気づいてmakefileも修正しております。

こんな感じです。

make debugを実行したらこんな感じで接続できます。
これでWindows10環境下でもInsightを使い倒すことができます。あと20年は優に
戦えそうですね。

あとひとつ気をつけなければならないのがレジスタウインドウを参照しようとしたら
Insightが落ちる問題は解決しておりませんので(XPのころからあった)レジスタを参照
したい場合はコンソールウインドウから"mon reg"コマンドで代用してください。

↑これが禁じ手です。

↑ちょっと面倒ですが"mon reg"で。

そんなわけで私が紹介している開発環境のデバッグ編の内容も上記の変更に
即するよう大幅に変更する予定です。Win10でも安定して使える軽量な
GDBフロントエンドが出てくれたらInsightからそちらに乗り換えられるん
ですけどね…

20200615追:ようやくwin10に完全対応しました！！！！！！

20231008追:
ESP版は本家OpenOCDに統合しました。
●ESP32版OpenOCDはぢめました
2017年初頭に早々に飽きてほっぽっていたESP32ですが思うことあり再び舞い戻る
ことになりました。まずはESP32(xtensa)に対応したOpenOCDのビルドからですが
当たり前ですが通常のOpenOCDのビルドと全く変わらない感覚でビルドできてます☆

一応軽く接続できるところまでは確認しましたのでOpenOCDバイナリに同梱して
おります。名前は安直にopenocd-esp32.exeです。いずれはxtensaのサポートも
OpenOCDのマスターに取り込まれるでしょうからそれまでのつなぎで通常版、
ESP32対応版バイナリの二つセットで公開とさせていただきます。

ちなみにわざわざこんなことやった理由がESP32版OpenOCDはデバッグだけではなく
外付けSPI-FLASHの書き換えもできるようになっていたからで2017年の頃は書き込み
方法がUART経由しかなくなんでJTAG使えるのにSPIフラッシュ書けないんだYOと憤慨
してたのですが2018年以降くらいにJTAG書き込みができるようになったのをいまさら
気づいたからというわけです。

具体的な書き込み検証に関しては次回以降に譲りますがとりあえずブツはすでに公開して
居りますのでどしどし使ってください！
ひとまずESP32の開発環境もう一回総ざらいですね～…すっかり浦島状態です。

いろいろ試す39(with2019年反省会)

もう一年が過ぎてしまいましたね～濃密な一年のおかげと思いたい

●触ってないとOpenOCD忘れそうになる
12月に入り、NuvotonのCortex-M0マイコンに目覚めてしまった方からデバイス対応の
お願いのコメントをいただいたのですが最初正直乗り気ではありませんでした。
~~なぜ日本人が使用してないNUC126なのかなぜSTM32G0ではないのか~~

なぜかというとNuvotonスタッフがOpenOCDのgerritに提出したパッチがあっさり
却下されてしまったあと修正を行わずに自分のgithubでしこしこ更新を続け早数年、
現在のOpenOCDとは容易にマージができない状態になってしまい、ますますぱっちが
受け入れがたい状態となってしまっていたからでした。

しかもOpenOCDのコアをアクセスする部分にもガッツリ絡んでいて私も容易に手が
出せない状況(そら弾かれるわ)でした。

しかしながらアリア藩から脱出するためにできるとこまでマージすることにしました。

・NUC126系とNUC4xx系は入れる方向で。
・フラッシュ書き込みアルゴリズムはNuvotonがこしらえたやつを。
以上2点はがむばって実装してみました。ちなみにNUC126はNUC120とプロセスが別物
なのでなんと消去ページサイズも異なり単純にIDを追加すれば済むものではありません
でした(ハマリポインツ)

ついでに以前ブレークポイントで止まらねぇ問題を引き起こしたデータ領域可変の
モデル(初期の128kbフラッシュのモデル)とかで茶を濁した対策も本格的につぶしに
かかりました。
具体的にはデータフラッシュ領域のアドレスが0x0001F000かつサイズが0(サイズ可変)
の時は強制的にアドレス0固定+メッセージ表示にするようにしました。

↑データフラッシュ領域あり+フラッシュ容量64kb以下の品種の場合。

↑データフラッシュ領域あり+フラッシュ容量128kb以上の品種の場合。

↑データフラッシュ領域無し(or全領域自由可変)の品種の場合。

そんでもって夏ごろにOpenOCDの出力表示のルールが変わってしまったようでPN2の
コンソール画面にwrote**KiBとかが何にも出なくなってしまったのでこいつも強制的に
出るように改造しております。尤もこんな細かい部分誰も気づいて無いと思いますが。

そんなわけで全国に数人いるかいないかのNuvoton使いの方、興味があれば試して
ください。ついでにバグが見つかったりパッチ思いついたらOpenOCDのgerritに投げて
GAIJINさんと直接バチバチやりあってくれると助かります(←ここ重要)

●SystemVolumeInformation問題ふたたび
くそがああああああああああああああああああああああああああ！１１１１！！！！

FAT32とかexFATにSystemVolumeInformationフォルダなんて要らねぇんです!YO!
なんとWin10の1909から昨年の対策だけでは不完全になり、再びSystemVolumeInformation
攻撃してきやがるようになりました！１！１１１！

新規に追加する対策はほとんどの人があまり使っていないBitLocker機能の息の根を
停止することです･･･F**K!

元のページにも1909以降の注意事項追加しておきますね

●大人しくしてろよお前！技適警察だ！
年末に秋月電気通商さんで使いもしないのにXBee3とBLEモジュールRN4020を購入
しました。しかし、このモジュールは本体が小さすぎて技適を張る領域がないのか
モジュールのどこにも技適マークが存在しませんでした。

ねむいさんの大昔の知識ではモジュール上に製造者が認証番号を取得＆付与した
技適マークがないと使用ができなかったはずですが、現在はだいぶ緩和されており
説明書に認証番号とともに技適マークがあれば問題なかったりモジュールを組み込
んだケースにも技適マークを転記可能であるとなておりました。

そして残る問題、"製造者が技適マークを付与する"のが今どうなっているのか、
どどのつまり技適は取れてるけどモジュール本体に技適マークがない場合自分で
技適シール作って貼ってもよいのかということをストレートに訪ねてみました。

・秋月電気通商様
Q:自分で技適シール作って貼ってもいいの？
A:大丈夫だ、問題ない。

・総務省近畿総合通信局様
Q:↑って秋月電気通商さんは言ってますが問題ないですか？
A:大丈夫だ、問題ない。
Ａ：大丈夫だ、問題ない。

ッッッッッしゃぁあああああああああああああああああ！！！！！１１！！！！

というわけで早速シール作りました♥

RN4020のモジュール基板は裏にはっつけました。

これで以前wirelessなアレでねむいさんを悩ませてきた通販における技適ガチャ
も解決です！！！！

♥おさらい♥
自分で技適マークシール作って貼ってよい状況は以下の条件を満たすときです。
ちなみに自分で作って貼るときは｢転記｣になるそうです。

1.該当モジュールの技適(「技術基準適合証明番号」もしくは「工事設計認証番号」
　がちゃんと取れている
2.モジュールの取り扱い説明書(マニュアル)に「技術基準適合証明番号」もしくは
　「工事設計認証番号」が明記されている。

そのほか、技適シール作らなくても最終完成品が液晶モジュールもちならば液晶に
技適マークを表示する手順を示せばOKです(これも転記)。

技適マークシールを作るときのルールはtelecに明示されているのでそれを参考に
作成しましょう。

そんでもって2019年12月現在は届け出すれば海外認証取れてる奴なら技適なくても
限定的に使用可能になっています。
ねむいさんが触り始めてすぐのころはお仕置き部屋でしか運用できなかったwirelessな
アレやコレも堂々と運用できるってことですね～。良い時代になりました。

●いろいろ買った
そんなわけで秋月さんから購入した無線モジュールですがその中に重要なやつが。

そう、ラズベリーパイ！しかも最新の4GBモデルとかいうやつ！

電源やモジュールはAmazonで調達してラズベリーパイ欲張りセットを
揃えました！！！！

システム格納用のMicroSDはもちろん産業用の寿命判定できる奴です！！

ついでにキムワイプも購入しました。
なんか50周年記念デザインになってる…。

こんなに要らないYO
残りは副業先に･･･。

なお、ラズパイは2020年からやろうと思います。来年からがむばる。

●ねむいさんQ&A
ようやく本題にかかります。これがないと年を越せません。

Q:＊＊のプログラムを作ってください！！！！！
　＊＊の回路を作ってください！１！！
A:質問で返すようですがなぜ大会期日ギリギリになってねむいさんに泣きつくんですか！！

Q:私の言うとおりにパッチを作成し提出してください。
　マージされるまでのやり取りはそちらでお願いします。
A:自分でやりなさいよー！！！！！
　↑この手のが未だに来る
　
　ちなみにOpenOCDのgerritのログインにYahooIDを使っておりましたが
　あるときから使用できなくなりなんと自分で提出したパッチすら取り下げ
　不可能というくそったれ状態になっておりましたが2019年の今は良く知
　らないけどまたYahooIDでログインできるようになったのでぼちぼちと
　OpenOCDの開発に復帰しようと思います。ラズパイ買いましたしね☆
　
Q:いないさんいいよね…
A:いい…
　残念ながらねむいさんが見せているのはいなちゃんの片りんに過ぎないのですが
　ねむいさんは虹裏メイドとして活動している都合上どうしても肌色が多めに
　なってしまうのですがそんな成果物はびぃぶろぐの規約上完全アウツなのですが
　いろいろ試した結果下着がちょろっと見えてしまうくらいなら大丈夫っぽいのを
　悟りましたのでガンガンギリギリせめて行こうと思います♥
　
Q:カッティングマットが汚いのですが
A:10年物です。大切にしてください☆

Q:「宮本和知の熱血！昼休み」（ＴＢＳ）は視聴率１％台とボロボロで６カ月で打ち切られてしまった。視聴率１％台とボ
ロボロで６カ月で打ち切られてしまった。視聴率ちなみに巨人時代に絶対的な人気を誇った清原グッズも今やたたき売り
で在庫処分を図る始末。１％台とボロボロで６カ月で打ち切られてしまった。視聴率１％台と人気を誇った清原コーロボ
ロで６カ月で打ち切られてしまった。視聴率１％台とボロボロで６カ月で打ち切られてしまった。視聴率１％台と巨人時
代に絶対的な人気を誇った清原グッズも今やたたき売りで在庫処分を図る始末１％台と指定席になってたかつては清原コ
ーナーとして指定席になっていた棚は、キティちゃんに乗っ取られてしまった。いた棚は、キティちゃんロボで６カ月で
打ち切られてしまった。ロボロで６カ月で打ち切られてしまった。視聴率１％台と清原コーナーとボロボロで６カ月で打ち切られてしまった。視聴率１％台と人気を誇った清原コーロボ
ロで６カ月で打ち切られ視聴率１％台と巨人時
代に絶対的な人気を誇った清原グッズも今やたたき売りで在庫処分を図る始末１％台と指定席になってたかつては清原コ
ーナーとして指定席になっていた棚は、キティちゃんに乗っ取られてしまった。いた棚は、キティちゃんロボで６カ月で
打ち切られてしまった。ロボロで６カ月で打ち切られてしまった。視聴率１％台と清原コーナーとしてボロで６カ月で視
「宮本和知の熱血！昼休み」（ＴＢＳ）は視聴率１％台とボロボロで６カ月で打ち切られてしまった。視聴率１％台とボ
ロボロで６カ月で打ち切られてしまった。視聴率ちなみに巨人時代に絶対的な人気を誇た棚は、キティちゃんに乗っ取られてしまった。いた棚は、キティちゃんロボで６カ月で
打ち切られてしまった。ロボロで６カ月で打ち切られてしまった。視聴率１％台と清原コーナーとしてボロで６カ月で視誇った清原コーロボ
ロで６カ月で打ち切られてしまった。視聴率１％台とボロボロで６カ月で打ち切られてしまった。視聴率１％台と巨人時
代に絶対的な人気を誇った清原グッズも今やたたき売りで在庫処分を図る始末１％台と指定席になってたかつては
A:ﾏｸﾀｻﾝ

　それにしてもコーロボ清原がホームラン打たずに覚せい剤打って捕まるとか
　NOVがあったころは思いもしませんでした。
　
Q:毎年言ってますけど見えなくなった画像早く復活してくださいよ
A:･･･

　･･･
　2020年から本気出す！！１！１！！
　
　

それでは皆様よいお年を～！

いろいろ試す38

今超くそ忙しくなってます…が、僅かな隙間を見つけて記事を更新し続けて行こうと
思います…！！！！

●ビルド・デバッグ環境構築をWin10対応に
昨年末に来年度からがむばりますと言いましたがようやく手を付けました…！
ARMマイコンのねむいさん流ビルド環境構築手順とOpenOCDを使ったデバッグ
手順のWindows10対応版です！

と言ってもXPでやってた頃とほとんど変わってませんけどね～
皆様に｢説明の意味がわからない」と評判だったねむいさん特有の言い回しとかは
まだ随所に残っていますが文章も見直してなるべくシンプルにするべく更新を続けて
いこうと思います…！

…ぇ？やっと10対応にしたのにWindows10の次のOS開発中ってマジですか…！？

●ARM-GCCの新しいのが出た
昨年末にARM-GCCが更新したばかりですがarm-none-eabi-objcopyがバグってihexが
出力できないという致命的な不具合を抱えていたのですがそれが修正されてリリース
となりました。本来なら1年くらいスルーされてるはずなのですが問題が大きくなり
すぎてGCC本家のアップデートに合わせてリリースされたようです。

今回のarm-none-eabi-objcopyはバグってエラー吐かずちゃんとihexが出力されます
ので皆さまも安心してお使いください。

●Windows10のクイックアクセスが憎いよう！！！！

なんでや…ドラッグアンドドロップで左ペインのディレクトリにファイルが
移動できない…orz

調べたら鬱陶しいクイックアクセスをレジストリ編集して消滅させたらこうなる
そうです…F*************CK!!!

●STM32H7Discoveryようやく市中に
待ってた…1年半くらい…
正確には「STM32H747I-Disco｣ですがようやくmouserとかで買えるように
なってますね～♨さっそくねむいさんも注文してみます！！！
来月位にH7の記事書けたらいいな～と思います☆

3D-TLC搭載のマイクロン製産業用MicroSDを使ってみる

とある用事で大阪に降りた際に寄ったいつものPCショップでねむいさんが前から目を
付けていたMicron製のMicroSD(ややこしい)を発見し、早速入手しました！

諸般の事情で128GB‥かつてはこの容量だと10000円越えだったのに産業用でも
5000円以下となりずいぶんと安くなったものです…

正式な型番はMTSD128AHC6MS-1WTとなっております。
Micron公式では産業用向けとして紹介されており3D-TLCセルを使用した大容量・長寿命
を以てネットワーク監視カメラ用途を想定したものとなってりますが当然のことながら
ドラレコにも最適です☆
そして産業用ならでわのS.M.A.R.T.(以下SMART)も当たり前のように存在しており、
ねむいさんはもちろんそちらの方が目当てだったりしてました！

-----------------------------------------------------------------------

CrystalDiskMark 5.2.1 x64 (C) 2007-2017 hiyohiyo

                           Crystal Dew World : http://crystalmark.info/

-----------------------------------------------------------------------

* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]

* KB = 1000 bytes, KiB = 1024 bytes



   Sequential Read (Q= 32,T= 1) :    70.235 MB/s

  Sequential Write (Q= 32,T= 1) :    45.021 MB/s

  Random Read 4KiB (Q= 32,T= 1) :     4.693 MB/s [  1145.8 IOPS]

 Random Write 4KiB (Q= 32,T= 1) :     4.378 MB/s [  1068.8 IOPS]

         Sequential Read (T= 1) :    71.302 MB/s

        Sequential Write (T= 1) :    42.824 MB/s

   Random Read 4KiB (Q= 1,T= 1) :     3.534 MB/s [   862.8 IOPS]

  Random Write 4KiB (Q= 1,T= 1) :     3.475 MB/s [   848.4 IOPS]



  Test : 1024 MiB [H: 0.0% (0.0/116.1 GiB)] (x5)  [Interval=5 sec]

  Date : 2019/06/07 21:17:20

    OS : Windows 7 Professional SP1 [6.1 Build 7601] (x64)

    Micron Industrial MicroSDXC 3D-TLC UHS-1 MTSD128AHC6MS-1WT ADR-3ML35BK USB3.0 uPF720202 M570RU

まずはPC上でベンチマークをとってみました
Sandiskの産業用(第三世代)と比べてみますとチマチマ書き込みがかなり強い印象がありますね(理由は後述)。

FatFs module test terminal for STM32F769NIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Jun  8 2019

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 18452 kB/sec.

>fs

FAT type = exFAT

Bytes/Cluster = 131072

Number of FATs = 1

Root DIR entries = 17931

Sectors/FAT = 16384

Number of clusters = 951296

Volume start (lba) = 32768

FAT start (lba) = 49152

DIR start (lba,clustor) = 4

Data start (lba) = 65536



Volume name is MTSD128AHC

Volume S/N is DAD2-8E1E

...

1 files, 132949600 bytes.

0 folders.

121765888 KiB total disk space.

121635456 KiB available.

>ds 0

rc=0

Drive size: 243597312 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 03 A1 3F 7F 80 0A 40 00 0F @..2[Y...?...@..

CID:

00000000  09 41 50 4D 42 35 33 41 01 E1 00 6F 10 01 28 C5 .APMB53A...o..(.



Parsing SD CID Register

Manufacturer ID    :0x9

OEM/Application ID :AP

Product Name       :MB53A

Product HwRev      :0

Product SwRev      :1

Serial Number      :0xE1006F10

DateCode.Month     :8

DateCode.Year      :2018



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 01 33 19 00 .............3..

00000010  00 00 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 45 80 43 01 00 00 00 .E.C....



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Spec Version X  :1

SD Security        :4

SD Bus Width       :5



SD_Spec V5.xx!

Detected as SDXC Card!

Available UHS-I Mode.

Available UHS Speed Class U1.

Available SD Speed Class 10.

Video Speed Class NOT Supported.

Available Application Performance Class1, A1 Card.

お次はねむいさんのいつものでカード情報を読み出してみました。
FatFs移植例も7月更新分からSDカードのサポート情報の細分化を進めており各種
スピードクラスのサポート状況が分かるようになりました。
このMicron製の奴はカード本体には記載はないのですがA1クラスサポートとなってお
ります。いちおう公式でもA1対応と言っておりますが製造時にロゴのレタリング追加
するの忘れちゃっただけなんでしょうけど。

そしてこのマイクロSD買ったメインの目的のSMART情報の取得です!
このカードではDelkinやSandiskと同じくCMD56でSMART情報の取得が可能なのですが、
なんと公式に資料を公開しており超太っ腹です！こちらの資料によるとCMD56の引数は
0x110005FBとなります。これを引数にしてCMD56を打ち込んでやると無事SMARTの
情報を取ることができました♥(もちろんSPI互換モードでも獲れます )
こちらに読みだした生データを置いておきますのでご参考に。

今回SMARTをとるにあたり上のテクニカルノート見て気づいたのですがこのMicron製の
奴はNANDメモリセルが3D-TLCなのですが一部はSLCのようなんですよね…
"Internalbuffer"としてどういう使い方するかによりますがFAT/exFATファイル
システムで使用する際に先頭にある書き換えが激しいFAT領域まではSLCの区画を
使用して比較的消去サイクルが少ないデータ領域に関しては3D-TLCの区画が
使用されている……といった感じなのでしょうか？？？
そしてSLCの区画をバッファとして使用することによってチマチマ書き込みも
強化されている感がしますね。

こういったハイブリッドなメモリセル構成にすることでコストパフォーマンスと信頼性を
同時に確保して大容量化を目指す路線が今後のSDカードで流行りそうですね～
SDUCでの最大容量が128TBだそうですが近い将来にあっさり到達してしまいそうです。

いろいろ試す37 -平成最後の更新…か！？-

このぶろぐエントリを書こうとして気づいたんですが新元号は4月1日公表で
施行は5月1日なんですよね…平成最後のぶろぐ更新は来月ですね…
あぶないあぶない…さて、

●A2規格のマイクロSDカードｹﾞｯﾂ

チマチマ書きに高いパフォーマンスを見せるらしいSandisk製のA2規格の
microSDカードSDSQXCY-064G-GN6MAです！！！
(って買ったの去年の10月で今頃紹介ですが…)

カードの表裏はこんな感じです。A2ロゴがかっこいいですね！

早速ベンチをとって見ました。
事前にSDFormatterでexFATでフォーマットしております。

ほう…A1のカードはどうでしたっけ…

…
A1ってランダムライトが糞遅くて過去のExtremeと比べてもあんまし
使えない感じでしたがちょっと微妙ですね…
↑A2規格で新設されたキューイングとかに対応したSDホストじゃないと
　本来の力発揮できないそうですorz

恒例のSDの情報を抜き出してみました。

FatFs module test terminal for STM32F769NIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Sep  9 2018

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 18051 kB/sec.

>fs

FAT type = exFAT

Bytes/Cluster = 131072

Number of FATs = 1

Root DIR entries = 14450

Sectors/FAT = 16384

Number of clusters = 486992

Volume start (lba) = 32768

FAT start (lba) = 49152

DIR start (lba,clustor) = 4

Data start (lba) = 65536



Volume name is SQXCY_064G

Volume S/N is 3BBB-87AE

...

1 files, 132949600 bytes.

0 folders.

62334976 KiB total disk space.

62204160 KiB available.

>ds 0

rc=0

Drive size: 124735488 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 DB 79 00 01 DB D3 7F 80 0A 40 40 F9 @..2.y.......@@.

CID:

00000000  03 53 44 53 52 36 34 47 80 24 74 BC C8 01 28 FB .SDSR64G.$t...(.



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SR64G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x2474BCC8

DateCode.Month     :8

DateCode.Year      :2018



OCR:

00000000  C1 FF 80 80 ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 0F 05 39 1E ..............9.

00000010  00 08 00 00 00 02 FC 00 03 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 45 84 87 00 00 00 00 .E......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :2

SD Security        :4

SD Bus Width       :5



SD_Spec V6.xx!

Detected as SDXC Card!

Available UHS-I Mode.

SDSpecはV6となっていて2018年の8月製！当時は
出来たてのホヤホヤをｹﾞｯﾂしていたようですね。

●64GBのサンディスクの産業用のマイクロSDカードもｹﾞｯﾂ

ねむいさんが大阪に降りたときに日本橋のPCワンズという店に寄るのですが、
なんと64GB版の第3世代サンディスクの産業用のマイクロSDカードが販売して
おりました！値段も3,690円とリーズナブルで容量も十分です！

UHS-1なのでシーケンシャルでも超早いです！
…あれ？これA2のやつよりRead性能いいじゃないですか…
もう普段使いのmicroSDもこいつでいいんじゃないかな。

こちらもSDの情報を読み取って見ました。

FatFs module test terminal for STM32F769NIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Feb 19 2019

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 19989 kB/sec.

>fs

FAT type = exFAT

Bytes/Cluster = 131072

Number of FATs = 1

Root DIR entries = 14448

Sectors/FAT = 16384

Number of clusters = 486992

Volume start (lba) = 32768

FAT start (lba) = 49152

DIR start (lba,clustor) = 4

Data start (lba) = 65536



Volume name is SDQAF3_064G

Volume S/N is 4415-38F9

...

1 files, 132949600 bytes.

0 folders.

62334976 KiB total disk space.

62204544 KiB available.

>ds 0

rc=0

Drive size: 124735488 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 01 DB D3 7F 80 0A 40 40 DF @..2[Y.......@@.

CID:

00000000  03 53 44 53 41 36 34 47 80 EC 76 CD 3E 01 26 83 .SDSA64G..v.>.&.



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SA64G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0xEC76CD3E

DateCode.Month     :6

DateCode.Year      :2018



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 0F 05 1A 0A ................

00000010  00 08 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 45 84 43 00 00 00 00 .E.C....



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :1

SD Security        :4

SD Bus Width       :5



SD_Spec V5.xx!

Detected as SDXC Card!

Available UHS-I Mode.

>

SDSpecはV5ですがこちらも2018年製ですね！
もちろん第3世代カードなので当たり前のようにSMARTが獲れます！
こちらに読みだしたSMARTのデータを置いておきますのでご参考に。

シーケンシャル読み書きもそれなりに速度出てて値段もお手頃なので
業務用/ドラレコ向けは勿論普段使いでデータの信頼性が欲しいなんて時にも
お勧めです。価格と性能を求める欲張りな貴女にぴったりかも！？

●定例のソースコード更新の件
ねむいさんが管理しているChaN師のFatFsの移植例いつものの月例更新です。
boochowさんよりコメントいただきました通りねむいさんのプロジェクトは
大文字小文字が統一されて無くてlinux系OSでは途中でエラーになっていましたが
今回からちゃんと整合性が出るようにmakefileを更新しました。
その中でUppercaseをLowercaseに替えるシェルコマンドがwindows環境下で上手く
動かないことがわかり↓のような結構見苦しい自前コマンドで逃げてます…。

# Exchange Uppercase into Lowercase

#MPU_MODEL_LOWER = $(shell echo $(MPU_MODEL) | tr A-Z a-z)

lc_jimae = $(subst A,a,$(subst B,b,$(subst C,c,$(subst D,d,$(subst E,e,$(subst F,f,$(subst G,g,$(subst H,h,$(subst I,i,$(subst J,j,$(subst K,k,$(subst L,l,$(subst M,m,$(subst N,n,$(subst O,o,$(subst P,p,$(subst Q,q,$(subst R,r,$(subst S,s,$(subst T,t,$(subst U,u,$(subst V,v,$(subst W,w,$(subst X,x,$(subst Y,y,$(subst Z,z,$1))))))))))))))))))))))))))

MPU_MODEL_LOWER  = $(call lc_jimae,$(MPU_MODEL))

だれかねむいさんの環境構築法でもっとスマートにできる方法あったら
教えてくだち。

そんでもってCMSISv5もgithubの変更を即反映して更新しておりますが、
なんでかこれの更新から一部のCMSISヘッダファイルがバージョンダウン
(しかも数字だけ)しやがっておりますので今回からV5.2.1とかの細かい更新は
whatnew.txtに書かないようにしました…
理由も書かずにしれっとこういう書き換えするのマジやめて。

●もう少しで10周年やん
やばい…四月になったらこのぶろぐ10年目だ…
…
よくよく考えたらARMマイコンの環境構築とChanN師のFatFsの移植から先に
ほとんど技術的に進んでない…10年も経ってるのに…

…
…

令和からがむばります！！！！！！！！！

2019.03.31 Sunday
21:16
ネムイ・トリノミアス
MISC
-
-

いろいろ試す36

今年は本当に波乱に満ちた年でしたね…
それでも月一ペースで何が何でも記事を更新できた私をほめてあげたい(自画自賛

●4GBのマルチメディアカードをついに入手！…しかし…

流通在庫が高すぎて敬遠していたのですがebayで新個品が放出されたタイミングを
見逃さなかった！！！！！Transcend製の4GBもあるMMC｢TS4GMMC4｣です！

同じトラ製のSDHCカードと比べてみました。

当たり前ですがねむいさんのSTM32F7のいつものでしっかり認識します。

カード情報も拾ってみました

FatFs module test terminal for STM32F769NIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Sep 30 2018

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 17609 kB/sec.

>fs

FAT type = FAT32

Bytes/Cluster = 32768

Number of FATs = 2

Root DIR entries = 0

Sectors/FAT = 960

Number of clusters = 122752

Volume start (lba) = 8192

FAT start (lba) = 14464

DIR start (lba,clustor) = 2

Data start (lba) = 16384



Volume name is TS4GMMC4

Volume S/N is 9FB2-841B

...

1 files, 132949600 bytes.

0 folders.

3928064 KiB total disk space.

3797920 KiB available.

>ds 0

rc=0

Drive size: 7872512 sectors

Erase block size: 512 sectors

Default r/w block size: 2048 bytes

Card type: MMC(Byte)

CSD:

00000000  90 2F 00 2A 1F 5B 83 C0 F6 DB BF FF 96 C0 00 1D ./.*.[..........

CID:

00000000  1E FF FF 4D 4D 43 20 20 20 10 00 00 02 2E BD 73 ...MMC   ......s



Parsing MMC CID Register

Manufacturer ID    :0x1E

OEM/Application ID :

Product Name       :MMC   

Product Rev        :1.0

Serial Number      :0x0000022E

DateCode.Month     :11

DateCode.Year      :2010



Detected as MMCv4.1 Device!

OCR:

00000000  80 FF 80 00 ....

>

今から8年前に造られた最後の方のロットのMMCですね～

ebayの新古品は2000円近辺で購入できるので例のSDライセンス問題も全く心配なく
ホビーで使いまくれると思います！

…と思ったのですが！！！

なんとこのMMC、MMCv4.1なのですが今日びのSDカードですら存在する
SPI互換モードが存在しないためマイコンの工作でSPIで手軽に使用する
ことが一切できませんorz

上で認識してたのはSTM32F7のSDMMCからMMCネイティブモードで叩いたので
さくっと動いて見えたのですが…皆さんご注意ください。SPI互換モードが
存在しないのは4GB品だけで2GB以下の品種はちゃんとSPIでも動きます…。

外人さんも嘆いている
ちょうどeMMCへの過渡期だったので4GB品の製造の際に遅いSPIモードがオミット
されてしまったのでしょう…まぁ電子工作で4GBも使うって早早ないから2GBでも
十分じゃないかな～…うっかりSDカードが動いてしまうこともありますし

というわけで古のデバイスにも癖があったというおはなしでした！

●サポート止めたプロジェクトをメンテしてみた

3年前に更新停止したLPC2388のプロジェクトとかを最新のFatFsとかにあてがって
みました。arm-gccは表向きはcortex-mのサポートとうたっていますが昔の
ARM7TDMIとかも余裕でビルドできます。
OpenOCDの書き込み・デバッグも順調です☆

あとLPC2388はUSBデバイス機能があってMSCやCDCなんかができるんですけど
たとえばCDCでは現在ではzadigを使用して汎用のCDCドライバをあてがう
ことができるので格段に使い勝手が上がってます！
まぁあえてLPC2388を使っていく意味も今となっては有りませんが余興ということで

そしてMicrochipになってしまったATMEL製のXMEGAもFatFsの最新版(0.13c(patch1))
をあてがって動作確認できました。
コード効率が悪い上に容量も128kbしかないのでexFATはおろかLFNすら乗っけられ
ませんがまぁ余興と(ry

ちなみにAVRToolchainは数年前に更新しなくなりましたが有志の方がavr-gccのツール
チェインを更新し続けているためほぼ同じ感覚でgccビルドができます。

avr-gccを使う上で注意すべき点はavr-size.exeがAVRのフォーマットが使えず、
汎用の動作しかしないのでFLASH/RAMの容量は自ら管理しなくてはいけません。
まぁここもARMマイコンいじるさいはリンカスクリプト自前で起こす必要あって
皆さん経験済みなので問題ないでしょう。

avrdudeも更新停止したと思ていたらさりげなく更新してたので久しぶりにビルド
しました。おきぱにあるのでどしどしご利用ください！
また、avr-gccにはavrdude.exeが同梱されてますがかなり古いのでavr-gccと
ねむいさんのavrdudeを組み合わせて使う際はバッティングにご注意ください。

同時にUrJTAG、flashromも微妙に更新がかかっていたのでビルドし直しました。
ビルドに当たってはOpenOCDも含めてMinGW-w64 GCC8.1.0を使用してますので
ビルド環境もアップデートしております！

●arm-gccの新しい奴が出た！
例年年末に出るやつがやっと来ました。
今回の変更点はGCCのバージョンがついに8になったところです！
さっそく導入してみました！

…
ﾅﾆｺﾚ…ihexで出力できない…
64-bit address 0x4b4fa300000000 out of range for Intel Hex file
ってなんなんだＹＯ！
arm-none-eabi-objcopyバグってる…？

調べてみると同じ症状に遭遇された方がいました。どうやらarm-gccの新しい奴にある
objcopyにバグがあり、IntelHEXフォーマットの出力ができないようですorz

対処法はどうしても新しいarm-gcc使いたい場合はarm-none-eabi-objcopy.exe
だけ一個前のverに差し替えるだけでおｋです。
こんな基本的なところでエンバグするの止めてくださいよ～！
※バグじゃなくてオプションのつけ方悪いだけならご指摘願います

20190131追:
公式も認めました！！

●転職しました
読んで字の通りでございます。
2012年から長きにわたる派遣ジプシー生活からようやく解放されて正社員になれたん
やなぁ…って

あまり詳しいことはお伝えできませんが正社員への転職に当たっては最初は自力で
転職サイトとかに登録して活動しておりましたが有効求人倍率が1倍を上回る状況
にもかかわらず年齢的にも経験的にも箸にも棒にも引っかからず全く太刀打ちでき
ませんでした。

しかしながら存在は知っていたものの興味が無かった転職エージェントを利用した
ことで状況は大きく変わり、そこそこの待遇で内定をたくさんいただくようになり
その中で納得がいく会社に2018年内に無事就職する運びとなり、今も頑張っています。

この時利用したエージェントさんですが"め"ではじまる名前と"あ"ではじまる名前の
二社で進めていき両社とも技術系に特化した所でしたので私の適正に近い会社様を
すぐに紹介していただけました。リクルートとかエン転職とか有名どころですが
某魔法少女より｢それらは避けよ｣と事前に忠告されていたため、ちょっとマイナー
ですが"め"と"あ"ではじまるところにお世話になった次第でございます。

ちなみに両者のエージェントさｎより口をそろえてほぼ同じ内容を説教されましたが
｢あなたのブログは選考者に対して大きなマイナスの印象を与えるので紹介しては
　いけませんよ」って言われてもちろんgithubもそこからブログにたどり着けちゃう
ので当然ダメでそれらの要素省いた出がらしみたいなスキルシート作るのが一番
精神的に辛かったのですがたぶん自力でやってた頃あっさりbanされまくってたのって
これが原因かなと思ってたのですがねむいさん面白い記事書けるよう務めてきたはず
ですが、いないさんのちょっとぱんつがみえてるｲﾗｽﾂとか至って健全で普通なのに何故だ(錯乱

20190407追：
ねむいさんのぶろぐがスラドに！！！
マジレスしますと私のぶろぐ記事から読み取れる私の技術的能力・文章作成能力は
｢ありものを組み合わせて動いたつもり分かったつもりの素人レベル」でこいつに
プロとしての仕事はできないと判断下され採用に至らなかったからですがorz
エージェントさんより指導入りまくった実務経歴の方はしっかりと評価していただけた
会社様が多かったので私がダメだっただけでホントに個別論ですね個別論♨
↑苦しい突っ込み入れられたら個別論で茶を濁して逃げるのいいですねねむいさんもよく使います♨

●ねむいさんFAQ
Ｑ：昔のぶろぐ記事でdropboxの見えなくなった画像早く復旧してください
Ａ：ぇっと…
　　今年は大事なことにたくさんエネルギー使っちゃったので
　　
　　来年からがむばります！

いろいろ試す35 -ようやくWindows10環境に手を付ける-

今年もあと一か月を残すまでとなりましたが2018年はろくな年にならないのは
もはや確定事項ですがそれでも明日に向かって歩みださなければ明日喰わせる
飯も確保できないので破滅に向かい突進む運命でも新しい概念にちゃれんぢ
し続けていく覚悟で挑んでおります。

さて前置きが長くなりましたがねむいさんもやっとWindows10の環境を導入する
運びとなりぶろぐの読者様頼りだったWindows10下でのARM開発環境の動作確認を
自前で試すことができるようになってきました…がそのまえにねむいさんがWin10
でいきなり遭遇した困ったことと解決策を紹介します…

●USBメモリとかSDカードさしたら強制的にSystem Volume Informationとかいう
　フォルダがつくられて消せないんですけぉ！！！！！11！！１！

はい読んで字の通りです。
このフォルダ、Win7とかではNTFSでフォーマットすると管理のために作られる奴と
認識しておりましたがWin10の1803ビルドではNTFSだろうがFATだろうがexFAT
だろうがマウントした瞬間にWin10の野郎がマウントしてきて強制的に作って
きやがるようになってやがります＃＃＃＃

これmbedとかのマスストレージで認識してD&Dで書き込みするプロトタイプボート
とかは死活問題ですが特にKinetisに関しては殺し技になってしまいますので開発
中心のPCならSystem Volume Informationフォルダ(とその中にあるWPsettings.dat)
をはなから作らせないようにする措置を取らなければなりません！！
ねむいさんが試行錯誤したところ、2018年11月現在のバージョン1803では以下に
紹介する方法でピタリと止まりました。
※必ずAdministrator権限で操作を行ってください！！！

①DisableRemovableDriveIndexingの設定

レジストリエディタを起動し、
HKEY_LOCAL_MACHINE¥SOFTWARE¥Policies¥Microsoft¥Windows¥Windows Search
キーの配下にDisableRemovableDriveIndexingというdword値を設定し1にします。
過去のバージョンではこれだけでおさまりましたが1803ではこれだけではだめです。

②WindowsSearchの停止

コンピューターの管理->サービスとアプリケーションからWindows Searchを停止させ
無効化させます。正直これを常駐させるメリットが一切何も感じられないのですが
Win7以降でファイルサーチがうんこになってしまったので別のアプリ探して使ってる
始末ですし…システムドライブにSSD使うのが当たり前の昨今では私はWin7でも
真っ先に止めてます。

③Storage Deviceの停止

コンピューターの管理->サービスとアプリケーションからStorage Deviceを停止させ
無効化させます。一体全体何の目的で起動しているのか？？？ことWin10においては
System Volume Informationフォルダを強制的に作ることしかないのではないか
と思うほどです。

以上①～③の操作をすべて行い再起動したらUSBメモリさしまくってもSDカード
さしまくってももう二度と憎いSystem Volume Informationフォルダは勝手に
作られません！…と言いたいところですがWin10はアップデートするとユーザーに
不利な設定に勝手に戻されるようでアップデートごとにこの操作を忘れずに
やらなければなりません。
あああめんどうくさい…

ちなみにできてしまったSystem Volume Informationフォルダを消すにはドライブ
上で右クリックし｢ポータブルデバイスとして開く｣でドライブに入ったら一撃で
中身のWPSettings.datもろとも消去することができます。お試しあれ。

20200119追:
1909以降は上記対策では不完全です！！！！
こちらもご覧ください！
20200119追:

あんまし関係ないですがTranscend製のUSB3.0カードリーダーTS-RDF5は古い
ファームウエアのままWin10環境で使用すると消去時に何故かディレクトリごと
全破壊してきやがりますので必ずアップデートしておきましょう！
…知らずにSDカード挿して折角とった基板の写真が全部消えたorz

●ARM開発環境確認中

約10年前からほとんど変わっていないねむいさんのARM開発環境ですがねむいさんの
現在の手順でほぼ問題なくプロジェクトのビルドとかはできることが分かっております。
しかしながら構築時の気になる細かい点はいくつか見つけたので年末までに手順も
ブラッシュアップして皆様に分かりやすくリニューアルする予定です。

まだ評価中ですがOpenOCD+GDB/Insightも昔とまったく変わらない操作感覚で
書き込みデバックができてます。dllの互換性も全く問題がありませんでした。

これであと20年はゆうに戦えますよ～！

20230921追:
し　か　し　・・・

ドラレコに最適！第3世代サンディスク産業用マイクロSDカードを入手せよ！

ここ最近は諸般の事情で大阪への所要が頻繁にあるのですが、ふと立ち寄った
大阪日本橋のPCショップでとんでもないものを発見してしまいました！！

なんとサンディスクの産業用microSDカード第三世代のものが販売されていたのです！
昨年から一般では入手不可能なサンディスク産業用microSDが市場にﾎﾟﾂﾎﾟﾂと流出
しておりましたがドライブレコーダーや監視カメラなどへの需要が大きく、継続的に
PCショップなどの市場に出回ているようです。

しかも現在の最新モデルである第三世代！！！
もちろんS.M.A.R.T(以下SMART)による寿命判定可能！

第3世代のカードでは32GB以上のモデルでもUHS-Ⅰクラスとなっています。
過去のモデルではClass10表記しかなかったのですがこれで通常使用でも十分
使用に耐えるものになりそうですね。

とりあえずベンチとってみました。
第二世代
 第一世代
と比べるとシーケンシャル書き込みは段違いの性能を示していますね！
チマチマ書き込みに関しても1MB/Sec割ってないので断続的な書き込みに
安定して強く、ドラレコ等で十分使えます！

お約束のねむいさんのいつものでカード情報を読み出しました。

FatFs module test terminal for STM32F769NIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Sep  7 2018

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 17637 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 53 41 33 32 47 80 75 F0 3C AD 01 26 A1 .SDSA32G.u.<..&.



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SA32G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x75F03CAD

DateCode.Month     :6

DateCode.Year      :2018



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 04 00 90 00 0F 05 1A 0A ................

00000010  00 08 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 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.

2018年6月製造の出来たてほやほやでした！
SDの世代もV5となっていますね。

さてこのカードの売りであるSMART機能ですが…もちろん第2世代カードと
同じくCMD56のコマンドで寿命判定を含む512バイト分のSMARTのデータを
読みだすことができます。
上の図の通り"Sandisk"のイニシャルコードが読みとれました。
こちらにCMD56で読みだした際のデータを置いておきますので参考にしてください。

また、当たり前ですが肝心の寿命に関するレジスタの配置はすべて過去の
世代のものと同一ですのでサンディスクの産業用SDでシステムを組んで
いたらソースの改変の必要が無くそのまま差し替えで使用可能です。

前途の通りドライブレコーダーや監視カメラなどが使用される個所は極端な
温度変化が起きさらに日本では高湿度環境下の動作を強いられます。
さらにその状況下でデータの確実性まで求められるため、TLCが使用されて
いる一般向けのmicroSDカード等は信頼性の面で到底使用できません。

タフな環境向けの高耐久なmicroSDカードも認知され始めていますが
サンディスクの産業用microSDカードは少しの電子工作の知識は必要ですが
SMARTが採れ寿命の判定もできるという点で普通の高耐久カードよりも
性能が一歩リードしていると言えるでしょう。あとシーケンシャル読み書き
速度の面でもですね。多くの単純な高耐久カードはまだClass10までですので。

昨年から言っていますがSD向けのSMARTが規格化されドラレコ上で容易に
寿命判定出来ればなおよいのですが現在急速に需要が増加している状態
なのでそのような時代はすぐやってくると思われます。

本家サンディスクも高耐久カードに関する取材を受けていますね。時代はタフさを
求められています！

追記：ドラレコ・監視カメラに使用する際は使用する機器の容量上限を確認しておいてください。
　　古いモデルでは上限値が32GBまでで、64GB以上で必須のexFATに対応していない物が
　　存在しています。容量は減りますが迷ったら32GBの奴選べばまず問題ないです。

いろいろ試す34

あああ…夏がおわる…

●GNU Arm Embedded Toolchainが新しくなった夏
忘れたころに更新されることで有名なARM提供のGCCツールチェインが
更新されていました…

日付は6/23版となっています…2018q2版になってますね
下記の修正が入っています。他は大きな違いはないと考えられます。

Important changes in 7-2018Q2 update release:

* Fixed powf/expf/exp2f/logf/log2f performance regression

  https://answers.launchpad.net/gcc-arm-embedded/+question/662462

* Added support for Arm Cortex-M33 without DSP via -mcpu=cortex-m33+nodsp

* Added Armv8-R multilib mappings

* Fix build requirements for GDB tui support

* Enabled C99 IO format specifier in newlib

* Fixed cmse_nonsecure_caller Armv8-M Security Extension intrinsic

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85203

* Fix crash in __builtin_arm_set_fpscr GCC builtin

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85261

* LTO bug https://bugs.launchpad.net/gcc-arm-embedded/+bug/1747966

  was fixed in previous release. Release note updated to reflect the change.

* Fixed issue with building libgcc's cmse.c without headers

  https://bugs.launchpad.net/gcc-arm-embedded/+bug/1717502

* Fixed issue with arm_cmse.h C99 compatibility

  https://bugs.launchpad.net/gcc-arm-embedded/+bug/1773934

●UHS-ⅡのマイクロSDカードを動かしてみる

買ってしまった…
日本橋に寄った際に目に入ったUHS-ⅡのマイクロSDカード…
ねむいさん今省エネモードなのでお金の使い方も省エネで64GBとか買えないので
32GBのSDHCとなっています…

東芝のEXCERIAシリーズの最高峰に位置するM501とかいうモデルです！！！
UHS-Ⅱ用の端子が追加されていますね！

SDカードサイズへの変換アダプタもUHS-Ⅱ仕様となっていますね～

早速ベンチマークをとって見ましたが…ねむいさんのUSB3.0カードリーダーは
UHS-Ⅱ規格に対応してなかったorz
ていうわけでUHS-Iの規格ですがチマチマ書き込みもまぁそこそこですし
使い物にはなると思います。

ねむいさんのいつものでカード情報を読み出してみました

FatFs module test terminal for STM32F769NIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Jul 28 2018

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 20989 kB/sec.

>ds 0

rc=0

Drive size: 62529536 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 EE 87 7F 80 0A 40 00 53 @..2[Y.......@.S

CID:

00000000  02 54 4D 58 41 30 44 35 44 E2 51 8E B2 01 12 6B .TMXA0D5D.Q....k



Parsing SD CID Register

Manufacturer ID    :0x2

OEM/Application ID :TM

Product Name       :XA0D5

Product HwRev      :4

Product SwRev      :4

Serial Number      :0xE2518EB2

DateCode.Month     :2

DateCode.Year      :2017



OCR:

00000000  E1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 04 02 90 00 20 07 3E 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 B5 84 03 3C 03 47 82 ....<.G.



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V4.xx!

Detected as SDHC Card!

Available UHS-II Mode.

ちゃんとUHS-Ⅱモードがあることを認識していますね。
STM32シリーズはUHS-Ⅱモードのインターフェースはまだ存在しておりませんが
UHS-Ⅱモードがあるか否かはACMD41コマンドでわかります。
ACMD41を打って還ってくるレジスタの37番目のビットが1ならばUHS-Ⅱ対応を
唱っていることになります。

●OpenOCDにセキュリティホールがあるらしい
まじかー
OpenOCDも攻撃されるほど有名になっていたのですね～

一応対応策が提示され、gerritにも上がっているようですが2018年の1月で
審議が止まっているようです

いろいろ試す33

冬が過ぎたと思ったらもう夏ですね…いやはや今年は本当に展開が早い
…STM32H7Discovery遅いな…H7自身もリリース遅れ気味ですし

●携帯音楽プレーヤーのリチウムポリマー電池を自力で交換する

！注！
リチウムイオン電池およびリチウムポリマー電池は取り扱いを誤ると簡単に
爆発炎上します！特にはんだ付けタイプのものは作業中にショートを起こし
やすく、はんだ付けの熟練者以外は絶対に興味本位で取り扱わないでください！
また、当ぶろぐエントリをもとに電池交換の真似をしてあらゆる被害をこうむった
如何に関わらずねむいさんは一切の保証をいたしませんのでくれぐれもご注意
願います！

2018年の現在ではスマホでなんでもできるようになってしまいましたがなんと
ねむいさんはまだガラケーですがそんなことどうでもいいのですがかつて隆盛を
極めた携帯MP3プレーヤも家電量販店のごくごく片隅にひっそりと販売されている
始末です。

当時のヨドバシ梅田店でcowonという南朝鮮のメーカ製のiaudio9(その後9+に
買い替え)を購入しトレランのお供として長らく使って参りましたがとうとう内蔵
リポ電池が消耗しきってしまいました。
5年以上も前の製品なのでサポートがあるかどうかも怪しく、保証もとうに切れて
いるので自分で交換してみることにしました。

ねむいさんのトレランのお供としてゼERO再生機と化したiaudio9+の背面です。
野外で使用しまくったためかなりﾎﾞｺﾎﾞｺ…
中央に見える黄色いテープはiaudioを操作中に突然ﾌﾞｰと大音量で鳴って操作
不能になる不具合に陥った際にリセットスイッチを押すためのピンを本体に
張り付けるためのものです。

スマホの皮むきツールを駆使して丁寧に裏蓋を外します。幸いにもリポ電池は
交換しやすい場所にあります。

リポ電池のアップです。リポ電池の型番は電池サイズが容易に分かるように
なっていてiaudio9+ではPR-383540なので厚さ3.8mm、幅35mm、長さ40mm
となります。

残念ながらそのものずばりは存在しないのでebayでそれに似たサイズの奴を探して
きました。とりあえずオリジナルよりも3サイズが小さければ問題ないです。
そして…

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

2週間ほどでやってきました。税関でﾎﾞｯｼｭｰﾄされるかもと思いましたが。
ねむいさんが購入したリポ電池は403040サイズのものでiaudio9+に十分入る
大きさでした。

それではリポ電池移植手術開始！
安全上リポ電池は過充放電防止回路やショート防止回路などが組み込まれている
(はず)です。ねむいさんも購入時は細心の注意を払って選んで買ったつもりですが
絶対に作業中にショートさせないようにして挑みました！

もとの電池を除去して新リポのリードを短く切って剥いて本体に慎重にはんだ
付け…あああ手が震える…もちろんもう片方のリードは厳重に絶縁しておきます。

そしてマイナス側…はんだコテでショートさせないように周りにマスキングを
貼り鉄壁の防御で作業開始…！GNDパッド広すぎて熱が伝わらん…

はぁはぁ…ｯｯできた～～！

そして緊張の火入れ…こちらも無事起動です☆
これでiaudio9+が復活しました！やったぜ！

ねむいさんiaudio9+を気に入ったので流通在庫があるうちにもう一台確保して
おきました。定期的に電池交換すればあと40年はゆうに戦える！！

●PCショップで販売されている廉価版のサンディスク製産業用マイクロSDカード
昨年サンディスク製の産業用microSDカードを紹介しましたがS.M.A.R.T(以下SMART)
が取れるものと取れないものがあるという検証も紹介しました。
今年に入って32GB版と64GB版のバルク版が安価で出回り出したので私もさっそく
一枚購入して動作確認をしてみました。

これが32GB版の廉価版です！

よく見るとSDSDQAF-032G-IとなっていてSDSDQAF2ではないことがわかります。
つまりこれはSMARTが取れない第一世代の製品である事を示します…が…！？

とりあえず第二世代の奴と並べてみました。
しまった…そっくりすぎてどっちがどっちか分からなくなった…

後ろから見た図です。
基板パタンに違いが見えますが製造プロセスで同じ世代でもいくらでも変わり
ますのでこれで判断することはできません…

とりあえずSDFormatterで更地にした後にベンチかけてみました。
読み書きは昨年の第二世代の奴と大差はないようです。

STM32のいつものでSDカードの情報を抜き出してみました

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 19019 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 53 43 33 32 47 80 90 5C 11 05 01 1B 0D .SDSC32G..¥.....



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SC32G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x905C1105

DateCode.Month     :11

DateCode.Year      :2017



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 04 00 90 00 0F 05 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 35 80 01 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Spec Version X  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

Available NS(or HS) Mode Only.

ぇええ…なんと2017年11月製ですって…
第2世代と並行して作っているということですか？？？？まぁいいや

とりあえず前回のようにSMARTの取得を試みましたが…
残念ながらCMD56に反応せず、フン詰まりになってしまいました…
読み書き性能は第二世代と互角ですがSMARTの取得ができずCMD56送信による
寿命判定ができないという結論になりました。

以上のような結果になりましたがSMART機能が必要なければパッケージ品よりも
安い値段で32GB・64GBの産業用のmicroSDが購入できてしまいますので寿命判定
機能はいらないけど耐久性のあるカードが欲しいという方にお勧めです☆

いろいろ試す32

生存確認･･･ッ！！
現在ひたすら過去記事の見えなくなった画像の修正と古くなった内容の見直しを
続けております。海外からの質問は相変わらず容赦なく来てますがそれをかいくぐ
ってわずかの時間を見つけてひたすら修正！修正！

●GNU Arm Embedded Toolchainが新しくなった
昨年秋から四半期ごとに更新が無くなってしまったARM提供のGCCツールチェイン
ですが忘れたころに更新されていました。
たしかねむいさんの記憶では2018年に入ってから更新されて様な気が･･･でもリリース
日は201712扱いですね･･･このままズルズル更新間隔が伸びていって最終的に有償に
なって実質消滅してしまったCodeSourceryみたいにならないと良いのですが･･･

主な更新は"Armv8-R and Cortex-R52 support."だそうです。
新規のCortex-R系コアのインストラクションセットが強化されていますね。
隠れてARM7TDMI系のサポートも続いているようなのでいまだにLPC2388とか
使いたい人も安心です☆

更新ついでにねむいさんのぶろぐの中でよく参照される環境構築記事を2018年度版
変更に向けて準備を始めました。私のPC環境は確定申告の関係で64ビット版
Win7のままなのでWin8以降、特に厄介なWin10は皆さんのレポート頼りなので
期待しています。

●確定申告始めました
ねむいさんも確定申告って奴を始めました。セルフメディケーション税制って
奴の恩恵にあやかるのと将来ビットコとかで大もうけしたときにあわてず
スムーズに申告できるようになるための練習です。

ねむいさんは既に電子証明書仕込んだマイナンバーカードとパソリを持って
いたためブラウザ上で拍子抜けするくらい簡単に申請が出来てしまいました。
ねむいさんの親父が毎年この時期に大量の領収書を傍らにうんうん唸ってた
のを見て育ったのでメンドクサそうだなと思っていたのですが技術の進歩って
すばらしいですね～

ちなみに虹裏の私のスレでも主張しましたがe-taxの申請画面の最初の奴がカービィ
SDXのセーブデータ全部消えたときの画面思い出してちょっと欝です。
色の順番まで同じとか･･･ああああああ！！！

それとカービィつながりですが今シャクレルカービィとかいうコラボ企画がやってる
ようで死ぬほど笑いました。メタナイトさんしゃくれるとこソコかＹＯ！

●STM32のFatFs移植例月例更新
ねむいさんのぶろぐではどんなに忙しくても意地でも更新している項目が
いくつかありこのぶろぐ記事とあとChaN師のFatFs移植例(通称いつもの)と
OpenOCDのバイナリです。

FatFs自体は昨年10月が最新ですが今年に入って久しぶりにIJG Jpeg libraryの更新
がありそれを反映しています。STM32F7用とSTM32F4用を3月版として既に
差し替えておりますので皆様の参考にどうぞ。

OpenOCDについては必須ライブラリのLibUSBとともに結構いろんな修正が
マージされていますので3月中にでも詳しく解説します･･･。

●ぶろぐのレイアウトちょっとリニューアル中
このぶろぐ今年4月で10周年記念だそうです･･･まじかよ！
この10年でやったこと･･･FatFs移植してから先に進んでない･･･

･･･
orz

それはおいといてこのぶろぐではフリーのブログツールをお借りして見やすく努めて
いるつもりですがいつも使用しているRSSフィードのツールがアップデートしており
そちらに乗り換えました。旧バージョンは乗換えを促すため超デカイ広告が出てしま
うためねむいさんのぶろぐを知る知人が気づいて直接伝えてくれました。

というわけで乗り換えました。今回からスクロール対応です！SNSのアカウントが
必要になりましたが使い勝手やカスタマイズ性は良くなったと感じます！

いろいろ試す31(+今年の反省会)

●ねむいさんのもとに工業用SDカードが続々集まってくる！！！

12月上旬、ねむいさんの元にすこし早いクリプレが届きました･･･！
昨年紹介したS.M.A.R.T.(以後SMART)が取れる一般購入可能な貴重な工業用SDカード
のリピート購入です･･･！

そして今回はTG-4用に新手のカードも購入しました。MLCな64GBで、その名もUtility+
です！こちらも工業用の位置づけで工業用SDとしての機能は完備しておりもちろん
SMARTに対応しているそうです。

実際にTG-4に装着してUSBマスストレージから接続してDelkinDashBoardで
見たところです。以前のと同じようにしっかりとマスストレージからでも
SMART情報が取れてますね～♥

ちなみにベンチを取るとこんな感じでした。
工業用SDカードはデータの確実性を重視しているため読み書き性能に関しては
民生品よりかなり劣るものが多いのですがUtility+はそこそこ頑張ってる感じです。
実際のTG-4で使用したときも速度的な違和感はまったく感じませんでした。

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 17484 kB/sec.

>ds 0

rc=0

Drive size: 125370368 sectors

Erase block size: 131072 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 01 DE 3F 7F 80 0A 40 00 9D @..2[Y...?...@..

CID:

00000000  58 44 44 44 44 49 4E 43 30 00 03 96 E1 01 02 FF XDDDDINC0.......



Parsing SD CID Register

Manufacturer ID    :0x58

OEM/Application ID :DD

Product Name       :DDINC

Product HwRev      :3

Product SwRev      :0

Serial Number      :0x000396E1

DateCode.Month     :2

DateCode.Year      :2016



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 F0 02 00 AB 3F 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 45 84 03 01 00 00 00 .E......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :0

SD Security        :4

SD Bus Width       :5



SD_Spec V4.xx!

Detected as SDXC Card!

Available UHS-I Mode.

今度はSTM32F4のいつものでSDカードの情報を読み出してみました。
2016年製ですね。

CMD56で読み出したところです。SMARTで取れるデータのフッタが昨年の
U331と同じようにCIDと同様の値が記述されてますね。

こんな感じでトレラン用のタフなデジカメにふさわしいタフな工業用SDカード
Utility+の組み合わせでこれからも厳しいフィールドを攻め込んでいきます！

●第三の刺客！SanDiskの産業用SDカード突如現る！
ねむいさんノーマークだったのですが2017年の初秋に一般のPCパーツショップで
SanDiskの産業用SDカードが安価な値段で出回っておりました。
こういったSDカードは一般に流通することはまれなので何らかの企業の大量購入品の
在庫処分でしょうか？なにはともあれありがたいことです。
容量のも8GB～64GB品があり32/64GB品は日本の正規代理店のパッケージ販売
なのでSanDisk特有のぱちもんの心配もほぼ無いかと思います。

出遅れた感じでしたがねむいさんも16GB品を入手せしめる事ができました。
SDSDQAF-016G-Iという型番です。

速度はUHS-Iに対応していますがまぁ良くある工業用グレードの速さですね～･･･
Utility+が早すぎるだけで工業用途にはこの速さで十分というところでしょうか。

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 19279 kB/sec.

>ds 0

rc=0

Drive size: 31116288 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 76 B2 7F 80 0A 40 40 13 @..2[Y..v....@@.

CID:

00000000  03 53 44 53 4C 31 36 47 80 61 6D 11 B0 01 15 63 .SDSL16G.am....c



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SL16G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x616D11B0

DateCode.Month     :5

DateCode.Year      :2017



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 04 00 00 00 04 00 90 00 0F 05 1A 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 35 80 01 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Spec Version X  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

Available UHS-I Mode.

SDカード内の情報を拾ってみました。
なんと2017年5月製ですよぅ！しかもFatFsからの読み出しに関してはUtility+より
早いです･･･！

ところでねむいさんはいかに工業用といえども無闇に買うわけではありません。
このSanDiskのカードはなんとDelkin製のやつのようにSMART情報を取れるのです！！

Delkinの奴のように細かい情報は取れないのですが皆さんも気になる｢寿命に関する
ステータス｣は取得可能なのです！！！もちろん投げるコマンドはCMD56!
(※投げる引数はDelkinのとは違い0x00000001です･･･てか統一しようよこれ)

し　か　し　･･･

↑CMD56投げたところでデッドロックしてるorz

流出しているSanDiskのマニュアルをよく見ると8GBと16GB品の第一世代は
SMART積んでませんと明記されていた･･･32GBと64GBから･･･だと･･･
しかも32GB/64GB品はSDSDQAF"2"-032G-Iってなってて第2世代カードっぽい･･･
SMART積んでるの第二世代以降ですね。
(注：すでに第3世代のカードが流通しています。DigikeyやMouserで購入可です)

仕方が無いので32GB品の第二世代の奴売ってる店探してゲッツしてきました！！１！１

速度は･･･UHS-Iでは無くClass10なので読み書きともMAX約20MB/Secです･･･
でも書き込みはさっきの16GBと比べてダンチだからまぁいいですか･･･

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

>do 1ftbt.mp3

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 16925 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 53 43 33 32 47 80 3D 76 40 13 01 13 7F .SDSC32G.=v@....



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SC32G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x3D764013

DateCode.Month     :3

DateCode.Year      :2017



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 04 00 90 00 0F 05 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 35 80 03 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Spec Version X  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

Available NS(or HS) Mode Only.

お約束のSDカードの情報も拾っておきます。
こちらも2017年製ですね～

お次はSTM32F7のSDMMCからCMD56を投げてDelkinみたいにSMARTが
取れるかどうか！いざ勝負！！

･･･！
帰ってきた512バイトのデータの中に｢SanDisk｣の文字が！！やった！！！！

ちなみに寿命を示すHealthStatusは9バイト目に相当します。
すでに1%使用されてるように見えますがこれはそうではなく｢0~0.99%消費された｣
ことを表すと記されています。
この値が100になったらデバイスはそれまで書き込んだデータを破壊しないように
読み取り専用になりデータ破壊から保護するそうです。

残念ながらSanDiskの奴はDelkinのようにUSBマスストレージからでもSMART取れる
仕組みはありませんがそれでも寿命推定ができるのは心強いことだと思います。
Linux系OSで物理バスにぶら下がったSDMMC持ったボードならCMD56直たたきで
見られるのでラズパイなんかでも活躍できると思います。

そんなわけで今年秋にPCショップで32GB/64GBのSanDiskの第二世代産業用マイクロ
SDカード買えた皆様、おめでとうございます！あなたのカードはSMART取れます！
逆にけちって8/16GBの第一世代の奴買っちゃったあなたはご愁傷様です･･･
まぁSMART取れないだけで物としてはバッチリ使えるのでしっかり
使い倒しまくってください！！！１１！！！

20180111追:
今度は32GB/64GBのバルク品が秋葉で販売しています！！が！！
型番から見て分かるようにこれは第一世代のSMARTが無いタイプですので、
SMART目当ての方は購入をしないよう注意してください！！
SMART積んでる奴はSDSDQAF2-***G-Iの第二世代以降の物です！
20180111追:

●ところでSPI互換モードでCMD56って効くの？
ねむいさん今まで組むのが容易なSDネイティブモードからしかCMD56の発行をして
いなかったのですがSPI互換モードからはCMD56は有効なのか？
年の瀬も迫るなかでねむいさんが公開しているFatFsの実装例、通称｢いつもの｣の
SPI互換モード用のSDカードドライバにCMD56を追加してみました。

ちなみにCMD56はSDネイティブモードではカードのイニシャライズが完了し
実際にカード内のデータの読み書きができるCMD17とかCMD24とかのコマンドが
通る状態になれば同じように使えました。SPI互換モードではステートマシンは
無いのですがとりあえずネイティブモードの挙動をまねてイニシャライズが
完了した直後にCMD56を送ってみました。

Delkin製はネイティブモードと同じく読み出しできました。

SanDisk製の奴も問題なく読み出しできました。

ねむいさんが確認した限りではCMD56はSPI互換でも問題なく通るのが確認されました。
一般的な電子工作でもSMART対応の工業用/産業用SDカードの恩恵をしっかり授かるこ
とができますね☆
ただし工業用でもSMART非実装ものや民生用の奴だとSPI互換モードでもやっぱり
フン詰まりになったり0xFFしか帰ってこないという結果になっています。

SMART取得を前提としてファームを組むならそのカード専用のドライバを作成する
ほうが無難かと思います。やはりねむいさんの希望はCMD56によるSMART情報取得が
規格化されて民生用でもSMARTが利用できるようになることです。
大事なことなので前回に引き続き2回アピールしました。

●毎年恒例反省会とねむいさんFAQ
Q:電磁波が飛ばします。受けとれっ(ﾋﾟｯ
A:ねむいさん昨年末から早々に手をつけて即効飽きてほったらかしにしたESP32で
　すが電磁波を扱っているせいかqiitaとか増田さんじゃないほうのはてなで技術
　風ぽゑむ書かれている方から(qiitaやはてなを利用している人たちはほとんどが
　まともな方でごくごく一部の人間がそういう特殊行動やってると信じたいですが)
　の抗議風自慢と思われる｢だからお前結局何が言いたいねん###｣といいたくなる
　怪文書いただくことが度々ありましてねむいさん最初は｢大変申し訳ありませんで
　したー！｣という内容(日本語訳で｢バーカ｣に相当する)の返事をしていたのですが
　社交辞令を真に受けたのかはっきり｢バーカ｣といわないとわから無いのか知りま
　せんが図に乗って私に無償で協力しろという方もいましてああもうこれかかわった
　時点でねむいさんの負けだなと感じて以後はそういう奴は存在しなかったことに
　しておきました。ねむいさんからはもう何も見えない。

　そんな事がありましてプロフィールの免責事項もちょっとお堅い内容に変えて
　おります。ついでに自分の襟も正して過去の自分の記事も読むと混乱するような
　変な内容や読んだ方に悪い印象を与えるような表現は正すように常に心がけてお
　ります。~~可愛がってるいないさんにオマパンさせるとかもってのほかです。~~

Q:(粋な写真もｽｲと添えつつ)しまかぜに乗って鳥羽まで行きましたよ☆
A:よかったですね＃＃＃
　ねむいさん近畿自然歩道の攻略で何度も近鉄に乗ってますが今に至るまで
　一度も乗れたことありません＃＃＃＃
　閑散期の平日狙えば少しはチャンスがあるのでしょうけど･･･

Q:(学生さんと思われる方から意図をぼかしつつ)｢***のソースコード書いて
　ください！！！！！｣｢***の回路図を描いてください！」等々･･･
A:メールのアカウントから推定して即効あなたのﾋ垢を見つけましたが
　まだ若いのに性癖全開なのは非常に期待が持てｒ･･･
　ｹﾞﾌﾝｹﾞﾌﾌﾝちょっと引きますよぅ･･･
　
　上の質問はちょっと極端ですがねむいさんより偏差値が20くらい上の子達から
　ねむいさんの知能を大幅に超える難しい専門的な問い合わせもびしばしもらうので
　すがねむいさん脳細胞どんどん死滅していっていないさんの今日穿いてるぱんつ
　のことしか考えられなくなっていく段階なのでもうちょっと手加減してくだち。

Q:フルブリッジドライバの下段アームのFETだけ壊れるんですけど
　壊れないようにしてください！！(←急遽当日になって)
A:(こいつまたかＹＯ！)ええいうるさい
　ゲートに抵抗でも入れてなさい！！！！

Q:スマホから見たら画像の読み込みばっかでめっちゃ通信量食うんですけど
A:ね　む　い　さ　ん　ま　だ　ガ　ラ　ケ　ー　Ｄ　Ｅ　Ａ　Ｔ　Ｈ　！

Q:ていうかそろそろねむいさんもスマホに換えましょうよ
A:実際どうしましょうかねぇ･･･キャンペーンがあったらガラホにでも
　移ろうかと思ってます。

Q:(パッチアンテナの面を地面に向けるように実装して)Gms-g9ってたいした捕捉
　性能ないっすねｗやっぱりu-bloxっしょ！(ｲｶｽ思想に取り憑かれた顔で)
A:(正気でやってるのかこれ･･･怖い･･･)
　が、眼科行った後メンタルヘ！

Q:ウンチーコングって知ってるぅ?
A:ウンチーコング･･･それはﾎﾟﾒﾗﾆｱｯｸ繊細空間が展開されたときのスレッド内の
　住人同士の仲が険悪になりﾚｽﾎﾟﾝﾁバトルが勃発せしめんとした際に発動して
　5cmにﾎﾟﾒﾗﾆｱﾝ出来たことにより無益な戦闘によって血を流すことを避け場を
　清らかに鎮めるための対繊細特化型概念である。こと虹裏においては平和的
　に発動される概念だがほかのコミュニティにおいては猿系のキャラクターが
　戦いにおいて敗北した際にギャラリーが連呼して敗北者にさらに精神的にダ
　メージを負わせるといったまったく逆の概念で使用されていることもあるの
　で留意すべし。また、冥府神がほかのキャラクターにその意味を無闇矢鱈に
　問うといった意味不明の行動も見られたがこれは第0話にて彼の行動の真実が
　明らかになっている。話を虹裏に戻すと猿空間においては｢座敷犬(ポメラニ
　アン)のくせに獅子(ライオン)の気持ちなんてわかるわけねーだろっ！｣
　というせりふとともに顔面パンチをｺﾞｯされる場面が見られ、ウンチーコングを
　発動するまもなくﾎﾟﾒが処分される技術も確立されだしている。
　やっぱりかませはかませだった。
　
Q:｢ねむいさん｣で検索するとサジェストに必ず入院とでるのですが何か大病でも
　されたのですか？
A:私のこと病院送りにしたい奴らの単なるサジェスト汚染ですね～！多分
　まぁ｢ねむいさん FX 必勝法｣とかでないだけ幾分マシですが･･･

Q:画像が見えなくなってる昔の記事の画像も早く復活してほしいのですが･･･
A:(う"･･･今年秋から差し替え作業サボったままだった･･･)

ぇっとあのその来年もがむばります！！

2017.12.31 Sunday
11:48
ネムイ・トリノミアス
MISC
-
-

いろいろ試す30

あと2か月で2017年も終わりですか…今年は展開が早すぎた････
でも毎年恒例のロングトレイルの準備に向けてﾊﾞｷﾊﾞｷにトレーニング
してますのでこうご期待！

●OpenOCD久々の更新
OpenOCD小ネタに出来ないほどの小ネタなのでここで紹介します。

まだ黎明期だった9年前より成熟が進みOpenOCDの更新の伸びも飽和してきた
感じですね。かつては当ぶろぐでも毎日更新とかかましてましたが忘れた頃に
mergeされていることが多いので一週間に一度くらいは様子を見てmergeされてる
のがあったらビルドし公開し続けております。

そのなかで有意義な更新が一つ。

STM32F7等のCortex-M7系とかのキャッシュ有マイコンの時の挙動を考慮して
いなかったのが考慮されるようになりました。URLに有るようにフラッシュ書き
込みを行ったあとの即起動するような時に理不尽な糞詰まりやHardFaultの発生が
抑えられます。
QSPI-ROMをリニアに参照するような使い方してるシステムのデバッグ時に
効果が実感されるかと思います。

そんなわけで10月下旬までのmergeを集約したwindows版OpenOCDは
こちらからどうぞ！

●FatFsもR0.13aに更新(＋ぱっちも)
ChaN師のFatFsもR0.13->R0.13aに更新しておりました。
内容はexFATの細かいバグ潰しとLFN有効の際にLFNとSFNを格納するためのバッファ
用の文字列数の定義が追加されています。
あとunicodeにUTF8が追加されました。これによりFF_LFN_UNICODEが設定できる値が
0～2に拡張してます。尤もこっちの機能は直接は使用していなくてご縁が無いので
よくわかりませんがデコードの関数(ff_uni2oem())だけはmp3/AACのID3タグの解析の
際にちゃっかり利用させてもらってたりします。

今回の変更を加味したSTM32F7とSTM32F4は更新済みです。
さらにLPC4088やLPC4357向けも順次更新していきますのでよろしくおねがいします。
月末にR0.13a用のパッチも追加されましたが勿論それも適用しております。

●avrdudeが更新終了してるっぽい？
かつて手軽に扱えるホビー用ワンチップマイコンとして絶大な人気を誇っていたAVR。
しかしATMELがmicorchipに吸収されてSTM32等の32bitなARMマイコンがホビー
向けに進出し、いろんな種類のマイコンがArduinoライクに手軽に扱えるようになった
今では**duino系基板にAVRを利用する強い理由がなくなってしまいAVRそのものの
人気もすっかり寂れてしまった感がします。
~~やはりフラッシュ領域にリニアにアクセスできなくて超めどい完全ハーバードアーキテクチャのせいか~~

そんな中ねむいさんもすっかりビルドするの忘れていましたがavrdudeがひっそりと
更新を止めてしまったようです。

こういうフリーツールの場合正式終了のアナウンスが有るのは極めて希で更新が
途絶え情報のやり取りや使う人がいなくなった時が終焉の時となるのが常です。
メーリングリストも9月を境に全く音沙汰がなく半導体業界の栄枯盛衰、所業無常を
感じる次第でございます。

それを受けてねむいさんのおきぱで公開しているwindows版avrdudeも11月の更新を
もって最終とさせていただきたいと思います。windows版OpenOCDは知る人ぞ知る
メインコンテンツですがwindows版avrdudeも隠れて需要があるのでAVRが電子工作
の場から完全に消えるまではずっと残しておきますのでご安心ください。

なお、以後の更新は行わないのでOpenOCDと違ってサポートも行いません。自己責任
のもとご使用をお願いします。
20201029追：復活しました！１１！！１１！

●STマイクロ配布のライブラリとかツール類がログオンしないとダウンロード
できなくなっていた

フ○ァック！！！！！

・・・・と思いきや苦情殺到したのかログオンしなくてもダウンロードできる
状態に戻ってました？？？？？？？？？
でもメール登録しないとダウンロードできない煩わしさはのこっていてやっぱり
不便ですね～～…エコシステムとはどこから来てどこへｲｸのか！？

●ESP32の基板が電流引けないからってAE-FT234Xの基板上のポリスイッチの部分を無理やりジャンパ
Ｃ☆Ｒ☆Ａ☆Ｚ☆Ｙ過ぎる･･･
しかも火事の脅しつき！
去年あれだけ急激に電流変化するから電源はしっかり作り込めって言ったのに！
これに関わった連中カンガルー先輩に全員〆られちゃえばいいのですよぅ！
↑実務でも特定地域のお客さん(政治不安定地域ため現地に行くことができない)の
　環境でしか発生しない電源の不具合が解決できなくて超イライラねむいさん

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

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

いろいろ試す28

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

●STM32L0シリーズを使う

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

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

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

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

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

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

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

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

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

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

Licensed under GNU GPL v2

For bug reports, read

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

adapter speed: 300 kHz

adapter_nsrst_delay: 100

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

none separate

srst_only separate srst_nogate srst_open_drain connect_deassert_srst

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

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

Info : clock speed 240 kHz

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

Info : using stlink api v2

Info : Target voltage: 3.240553

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

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

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

adapter speed: 240 kHz

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

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

STM32L0: Enabling HSI16

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

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

adapter speed: 1800 kHz

adapter speed: 1200 kHz

auto erase enabled

Info : Device: STM32L0xx (Cat. 3)

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

target halted due to breakpoint, current mode: Thread 

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

target halted due to breakpoint, current mode: Thread 

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

target halted due to breakpoint, current mode: Thread 

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

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

target halted due to breakpoint, current mode: Thread 

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

target halted due to breakpoint, current mode: Thread 

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

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

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

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

adapter speed: 240 kHz

adapter speed: 1200 kHz

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:04

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

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

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

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

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

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

とはいえこのまま放置するのは私としても心苦しいので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のやつがお求めやすい
値段になっちまいましたので運よく特別収入が発生したら即買いしたいと思います！！
いきなり10億円(税引き後)とか手に入らないかしら…

いろいろ試す27

ああ･･･2016年が終わってしまう･･･
今年は年始から本業副業合わせてやばい系のばっかリに絡まれまくりましたよぅ
(※本業は虹裏メイド)

●OpenOCDがビルドできなくなる
これホントはOpenOCD小ネタ扱いですけど小過ぎてここでやります。
12月上旬の更新で"Convert to non-recursive make"という更新が掛かりそれに伴って
Automakeのバージョンもあげる必要性が出てきました。
しかしmsysのビルド済みバイナリは数年前に更新停止ししていて結局全部一からビルド
するハメに！！ねむいさんの環境では結局以下の3点の最新化が必要でした。
・automake-1.15
・pkg-config-0.29.1
・libtool-2.4.6

これでOpenOCDをはじめ他のライブラリやライタプログラムにも悪影響がないを確認
しましたので当面は大丈夫だと思います☆
･･･また数年したらこう言う相違の問題出てくるんだろうなと考えると気が重いです。

●DropBoxがPublicフォルダを廃止し強制的にプライベート化する
ねむいさんのぶろぐの画像保管庫として機能しているDropboxからメールがあり、来年
3月15日でPublicフォルダ(有料ユーザーも7月15日で)強制廃止するよ!というふざけた
内容の文章が来やがりました＃＃＃＃＃＃＃＃＃

Publicフォルダというのは直リンクが可能なDropboxの特殊フォルダで、ぶろぐで画像
サーバとして使うのにはうってつけだったのですが･･･便利ゆえに児童ポルノなどの
やり取りに頻繁に使われまくったせいか規制されてしまったようですｸｿｧ！！！
公式の掲示板でも異を唱えたまっとうな使い方をしている人たち(有料ユーザー含む)が
いましたが粛々と無言で粛清されていくさまを目の当たりにしねむいさんは今後の
画像置き場とにかくどうするかしらと悩んでおりました。
と、そこにとある方のツイートによって一手間掛かりますけど直リンが可能な方法が
あるのが分かり今後はそちらの方法でDropboxを使い続けることにしました。
(やはり真姫ちゃんは有能･･･)

ねむいさん的な使い方はCarotDAVと連動して使う方法で行きます。

まずCarotDAVを使って前もってDropBoxの非共有の個人フォルダにアップロードします。
ここで共有化したいファイルをドラッグして選択し右クリックで"Create Shared Link"
を選びます。確認ダイヤログでOKを押して少し待つと共有リンクのURLがずらずらっ
と出てきます。

あとは末尾の"?dl=0"の部分を""に変えれば以前と同じ感覚でぶろぐに画像
として表示が出来るようになります。CarotDAVではこのように一括で共有リングが
作成できるのでねむいさん的使い方する方にとってもオススメです！

ただ方法は純粋な直リンではなく一旦エンコードを噛ましています。そのせいで今度は
FaceBookに自分のぶろぐを紹介する時にOGPがエラーとなって弾かれてしまいました。
こちらですが現在はぶろぐのヘッダに以下のメタタグを埋め込み固定の画像を拾わ
せるようにして対処してます。↓こんな奴です。

<meta property="og:image" content="http://bcaweb.bai.ne.jp/44unk/inachang/prof_facebook.png" />

FaceBookからはこう言う風に見えます。

とりあえずこれでPublicフォルダ廃止後の新規ぶろぐエントリの画像問題は解消され
ましたが･･･問題は過去5年間、数千枚に及ぶ大量の画像のURLの変更だ･･･
orz

●Naverまとめの所業に憤慨す
現在Naverをはじめ、｢キュレーション｣なる単語で言葉を濁し実際は無断転載でコンテ
ンツをパクり広告収入で儲けるという企業の行為が社会的な問題となっております。

｢猫にコ・ン・バ・ン・ワ｣の管理者のたま吉さんが自身の記事をNaverまとめに無断
転載されていたことで大変怒っておられ、その顛末を記事にされております。
私もそれを受けてパクられてないか調べてみると私もやっぱりパクられてました。
しかも直接関係ない別の人の記事に私の画像が添付されてます！！！！！！！

パク

ラレ
パクられた箇所の一部をトレパクスレ風にやってみました★

超めどいですが年の瀬も迫る中早速Naverに攻勢を仕掛けました。南朝鮮企業のNaverが
普通の言伝で簡単に削除対応するわけが無いのは分かりきっていたので、逃れられない
証拠を突きつけた上で期限内に対応しない場合は内容証明郵便を送りつけ、それでも
応じない場合は簡易訴訟を起こす手立てで親父と相談し作戦を実行しました！１！！

･･･が、ねむいさんの徹底抗戦の意思とは裏腹にNaverがあっさりぱくったことを認め
パクったと指摘した箇所を秒速全削除。一週間も掛からぬうちに勝負はついた。

SDカードの一件でみなさんご存知とは思いますがねむいさんのぶろぐでも各ライセン
シーについてはもっっっっっっっのすごく気を使うようになっており、自身が取り扱う
ぶろぐ記事や写真につきましても当ぶろぐ立ち上げ時からCreative Commonsの非商用を
掲げております。そういった姿勢が相手に｢こいつはやばい奴だ｣と思われてすぐさま
パージする方向に傾いたのでしょう。

しかしながらNaverはその一方で冒頭のたま吉さんに対しては著作権侵害を認めておら
ず(たま吉さんはねむいさんとは比べ物にならない量をパクられているのに係わらず)
態度に一貫性がまったく見られず極めて不信感が感じられます。
｢こいつらはいつもこんなもの(だからこれ以上追求するな見過ごせ)｣で済ませるとたとえ
Naverまとめが今回の問題で閉鎖したとしても暖簾替えて同じことやるのは1000%確実
なので今のウチに根治しないといけませんね･･･(使命感)

というわけでこの件に関する公の発言はここで一旦〆ます･･･が、以後は裏で暗躍して
みようと思います。これから先、もし事態が良い方向に向かったらねむいさんや他の
有志の方ががんばったおかげかもしれませんよ★

あと気になる事ですが今年に入ってから不自然な内容の質問もどきを多く伺うように
なっています。名前も｢ななし｣とか｢匿名希望｣とか適当で、なおかつ質問内容は異口
同音に｢オマエが持ってる(ぶろぐに書いてない)情報あるだけゼンブヨコセ」。
で、ねむいさんも相手の質問内容や文体の癖を注意深く調べぐぐるとアマゾンアフィや
グーグルアドセンス等のアフィ大盛りのはてなorFC2orライブドア系の広告収入特化型で
技術的価値が殆ど無い内容の薄い質問者と思われるブログに行き着いたりします。

ねむいさんとしましてはねむいさんのぶろぐ上で公表した事はいくらでも"参考(←転
載じゃないよ)"してもらってもかまわないというスタンスですが直接応対する案件は
内容の如何によっては対価を頂くようにしてます(それ言ったとたんに相手の反応が
いつもゼEROになっちゃうんですけど)

んでもってねむいさんもだいぶ痛い目にあってきましたので聞いてくる人の素性は必ず
調べてから対応するようにしています。それでもねむいさんを利用してやろうと考えて
らっしゃる傾き者は伊達にしてお帰ししますので
お覚悟するでござる(若先生風に)

20201231追:
Naverまとめ潰れました！！！！正義は勝つ！！！！

●Launchpad ARM-GCCの各種バイナリがARM本家預かりになる！
今期のアップデートからLaunchpadで公開されていたARM向けGCCツールチェイン各種が
なんとARM本家から装いも新たに堂々と公開される運びになりました。
ARMを買収した禿がこんな粋な計らいするわけないのでARM内の別の人たちの発案でし
ょうけど。

そしてGCCのバージョンは6.2.1にアップしております！
地味にオプション表もアップデートしていますので見逃さないように！

まずは同一条件でビルドした時のバイナリサイズ比較
新：2016q4版(GCC6.2.1)

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 6.2.1 20161205 (release) [ARM/embedded-6-branch revision 243739]

Copyright (C) 2016 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 Informations:

USING_SYSTEM = BARE_METAL

USING_DISPLAY = USE_RK043FN48H_RGB_TFT

USING_DEVBOARD = USE_STM32746G_DISCOVERY



Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 721292	      0	 721292	  b018c	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 718700	   2592	 822180	1543472	 178d30	main.elf

旧：2016q3版(GCC5.4.1)

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]

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 Informations:

USING_SYSTEM = BARE_METAL

USING_DISPLAY = USE_RK043FN48H_RGB_TFT

USING_DEVBOARD = USE_STM32746G_DISCOVERY



Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 726736	      0	 726736	  b16d0	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 724148	   2588	 822188	1548924	 17a27c	main.elf

GCC6.2.1版のほうが5kByte近く小さくなってますね～

お次はjpegファイルのデコード速度比較！！
ぁ･･･ちょっとだけ遅くなってる･･･
･･･
･･･
まっいっか！

ついでにProgrammers Notepad2も4年ぶりくらいにアップデートしております。
ねむいさんの環境構築手順ではほぼ影響は無いのでそのまま差し替えてお使いいた
だけますのでまだの方はアップデートしておきましょう！

20170108追：
ちゃんと新規追加されたオプションつけろよﾊﾞｶﾔﾛｺﾉﾔﾛと突っ込みもらいましたので
付けた奴で再比較します！
1.｢-mslow-flash-data｣を付与
このオプションはフラッシュメモリのアクセスが遅いMCUにおいてリテラルプールを極力
行わないようにするものです。Cortes-M3/M4のみ有効でldr系の命令がmovw+movtに
なるべく置き換えられます。

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 6.2.1 20161205 (release) [ARM/embedded-6-branch revision 243739]

Copyright (C) 2016 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 Informations:

USING_SYSTEM = BARE_METAL

USING_DISPLAY = USE_RK043FN48H_RGB_TFT

USING_DEVBOARD = USE_STM32746G_DISCOVERY



Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 727908	      0	 727908	  b1b64	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 725316	   2592	 822180	1550088	 17a708	main.elf

コードサイズはかなり増えてしまいました。

遅くなってるー！？ダメじゃん！
このオプションはSTM32F1/F2/F4系だと有用だったのですけどアーキが一新され、
キャッシュが追加されたM7系では相性が悪いようです。

2.｢-mpure-code｣を付与
前回のGCC5.4.1から追加されておりますがGCC6系から真価を発揮するそうです。
このオプションは定数値をコードセクションに置かないようにするものでリテラルプールは
当然ながら全排除、ジャンプテーブルもldrを使用しないよう徹底されます。

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 6.2.1 20161205 (release) [ARM/embedded-6-branch revision 243739]

Copyright (C) 2016 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 Informations:

USING_SYSTEM = BARE_METAL

USING_DISPLAY = USE_RK043FN48H_RGB_TFT

USING_DEVBOARD = USE_STM32746G_DISCOVERY



Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 726884	      0	 726884	  b1764	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 724292	   2592	 822180	1549064	 17a308	main.elf

GCC5.4.1のオプション追加無しと比べると少しコードサイズが減りました。

おおっ！結構早くなってる！！！
これはイケてますね～♥
とりあえず後方互換性の事も考えてmakefileでは"-mpure-code"はまだ無効のまま
としておきますが2017年中旬以降は積極的に有効にしていきたいと思います！
ちなみに-mslow-flash-dataと-mpure-codeを同時に有効にすると-mpure-codeが
優先的に働き-mslow-flash-dataは実質上無意味になります。

●複数スレッドでmakeのスピードアップ！
STM32F4やSTM32F7のいつものはさまざまなライブラリが混在していてビルドしあがる
のにやたら時間がかかります。現在は複数スレッドでmakeを走らせるのでが当たり前に
なっているので私もちゃれんぢしてみました。

複数スレッドのmakeはそれに適応したmakefileの書き方をしなければならずねむい
さんのmakefileでは普通に-j2オプションつけたら最後のリンク段階でこけますorz

仕方が無いのでmakeを入れ子にしてオブジェクトが出来上がる段階まではj2でビルド
するようにしました。入れ子にする場合は｢XXディレクトリから入ります出ます｣のメッ
セージが鬱陶しすぎるので"--no-print-directory"オプションも付与しております。

おおっ！同時にビルドが走ってる！！

-j1と-j2の速度比較です。-j2はめっちゃ早くなってますね！
スレッド数はCPUコアの数と同じが丁度効率が良いそうですがうっかり数字をつけずに
-jとしてしまうと大変な事になってしまうので皆様試してみたください

うっかりやってしまったorz

●年末恒例ねむいさんFAQ
今年はやばいのしか来ないと言ってましたがぶろぐでも公開できないマジで
やばいのは個別に処理しましたので例年通り虹裏における活動時や当ぶろぐに
きた中から当たり障りの無い方のやばい系の質問について公開回答いたします。

Q:mbedを使っているのですが！？シリアル通信が上手く出来ないのですか！？
　これはどういうことでしょうか！？ちょうさをおねがいます(←原文ママ)!
　それと液晶プログラムを動かしたいのですがどのファイルをさしているのか！
　初心者がわかる文章で希望します！
A:無理して日本語使わなくていいから人間の言葉しゃべってください！
　mbedって！対象が増えすぎてどのmbedかわからないんですけど！
　ねむいさんに分かる文章で希望します！
　ぁれれ･･･文体が感染してしまった･･･

　まじれすしますがねむいさんArduinoとかmbedとか難しすぎてまったく
　分かりません＞＜

　それと液晶のライブラリに関してはこちらのエントリをちょっとだけ
　補修しましたのでとりあえずお目当ての初期化の呪文にはたどり着けると
　おもいます。章仁さんにも紹介していただきました。

Q:(GNUARMECLIPSEのOpenOCDバイナリを使った上で)ねむいさんのバイナリを
　使うとOpenOCDが正しく動きません。これはどういうことでしょうか？
A:･･･ろすぞ！！！
　ｹﾞﾌﾝｹﾞﾌﾌﾝすみません物騒な物言いになりましたがねむいさんがあずかり
　知らない他所ビルドのOpenOCDバイナリを使ってエラーがでてもねむいさんは
　一切対処いたしませんし助け舟も出しません。嘘言ってねむいさんと同じの
　使ってる！って言ってもすぐにバレますよ！

Q:(中華製ぱちもんJ-Link使った上で)ねむいさんのバイナリを使うとOpenOCDが
　正しく動きません。しかも弄ってるうちにJLinkが動作しなくなりました
　しっかりしてくださいよ(めっちゃえらそうな口調で)
A:･･･ろすぞ！！！！！！！！！！
　もうね、昨年からずっとだけどJ-Linkとkinetis関連は対人トラブルの元だから
　ご意見無用にしたいと思います＃＃＃今はぱちもん使ってると突如brickedする
　トラップがSegger側からされてるんですけど詳細はねむいさんも言いま
　せんから！！あと詳細は言いませんけどOpenOCDでもぱちもんだと動かない
　やつあるからバレますよぅ！

Q:小生は(極めて性的な内容なので略)
　少ない年金ですがねむいさんにお小遣いくらいはあげられるとおもいます
　それではよろしく。
A:･･･(やべぇぞこれマジでやばい)
　というわけでねむいさん気持ち悪すぎて答えたくないのでこの件に関して
　年齢が近そうなねむいさんの親父からのスペシャルコメントです
　｢俺の歳で再婚するなら20代の元気な女の子がいいなぁ～｣
　ねむいさんよりコメント：お母ちゃんに呪われてしまえ！！！１！！！！

Q:手軽に高収入！アフェリエイトを始めてみませんか！？
A:帰れや！！１１！！！！
　この手の変な情報商材詐欺勧誘が今年に入って爆発的に増加しています！！！
　
　･･･しまった真面目に答えてしまった。

Q:ラブライブ！の東條希さんを描いて下さい
A:ねむいさんがあんまり知らんキャラ(2016年1月上旬当時)の話を
　分かっていながらあえて無茶振りする子は
　ｵ　ｼ　ｵ　ｷ　ﾔ　ｶ　ﾗ　♥
↑良く分からなかったのでゼERO見ながら描いた

Q:ラブライブ！サンシャイン！！の黒澤ダイヤ様を描いて下さい
A:･･･ダイ煮よ♡♡♡♡
↑なんか知らないけど別の方に私の手描きをブラッシュアップされて
　　しまいました。ハートマークが敷き詰められてこれは･･･♡

　････おかわりがほしいですって！？
　　まったく･･･貴女は本当にしかたのない娘ね♡♡♡♡

Q:ねむいさんこんにちはいつもブログを拝見させております。
　今回のねむいさんのエントリにてラブライブメチャシコ画像集なる
　とても興味を引く動画が紹介されており期待に胸と股間を膨らませて
　再生ボタンを押したのですが再生が始まったとたんに突然青色の
　ロボットが現れて尻をこっちに向けイチジク浣腸を自ら刺してで
　てきたカレーライスを何度も食しては不味いだのふざけるなだの一々
　偉そうに注文をつけて助けに来た仲間のロボットにも浣腸を刺して
　でてきたカレーライスに今度はうまいと言って満足したのが勝手に
　自爆して動画が終了してしまったのですが多分ねむいさんが想定
　していたものと違う動画でしょうか？僕は一体どうしたらいいので
　しょうか？？？今回は桁違いにやばいのでとか動画の中で警告
　されても今更どうしようもないじゃないですか！
A:お前は･･･ｲﾚｷﾞｭﾗｰだ･･･処分する！！

Q:オマパンとか言う気が狂った異常な概念がmayで流行ってますけど
　ああいうの喜んでﾜｰｵ!とか言ってる連中って絶対頭おかしいと思います。
A:ﾜｰｫ!

来年は本当のホントに真面目にがむばります！！！！
それでは皆様良いお年を～

いろいろ試す26

今回もSDカード中心です。

●ついに発見！Transcendの4GBのSDカード

当初SDHCをつかまされてしまった私ですがSDコンパチブルな奴をついに見つけ出し
ました！！というかebayで新たに発売開始(？？？)されていました！

SDHC版と比較…ものすごく似てるけど色が微妙に違う…知らなかったこんなの…

一応SDカードの情報を抜き出してみました(あえてSDv1による初期化です)。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Nov  8 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 14597 kB/sec.

>ds 0

rc=0

Drive size: 7788544 sectors

Erase block size: 512 sectors

Default r/w block size: 2048 bytes

Card type: SDv1

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  00 0E 00 32 5B 5B 03 B6 9D B7 FF 80 0A C0 00 21 ...2[[.........!

CID:

00000000  74 4A 45 53 44 43 20 20 10 3C D5 6B 7B 00 08 AB tJESDC  .<.k{...



Parsing SD CID Register

Manufacturer ID    :0x74

OEM/Application ID :JE

Product Name       :SDC  

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x3CD56B7B

DateCode.Month     :8

DateCode.Year      :2000



OCR:

00000000  80 FF 80 00 ....

SD Status:

00000000  80 00 00 00 00 00 00 20 03 03 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 0F 17 00 04 00 00 20 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!

製造年月が2000年とかなってますけど思い切り嘘ですね。2016年産でから。
一応製造元はTranscendの製造協力会社のものになっており真贋の方は分かりかね
ますが…一応PC上で容量チェックを行った所、4GB分正しく読み書きが可能でした。

SDHCだった方のカード情報はこんな感じです。



FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Nov  7 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 21688 kB/sec.

>ds 0

rc=0

Drive size: 7812096 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5F 59 00 00 1D CC 7F 80 0A 40 00 D5 @..2_Y.......@..

CID:

00000000  1C 53 56 53 44 43 20 20 10 01 D2 00 BC 00 82 DB .SVSDC  ........



Parsing SD CID Register

Manufacturer ID    :0x1C

OEM/Application ID :SV

Product Name       :SDC  

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x01D200BC

DateCode.Month     :2

DateCode.Year      :2008



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 02 00 00 00 03 03 90 00 08 05 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 35 00 00 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :0

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V2.00!

Detected as SDHC Card!

れっきとしたTranscendの奴ですね。

ちなみに読み出し速度は圧倒的にSDHC版の奴の方が上でしたorz

このSDコンパチブルなTranscendのはSDv1の初期化でバイトアクセスとなり、SDv2の
初期化ではブロックアクセスとなりました。この辺以前紹介した4GBカードたちと同じ
ですね。(ていうか同一の会社がガワだけ別で中身同じの作ってそうです･･･。)

そしてそのうちの前回紹介した4GBのドイツカードなのですが端子の埃をふき飛ば
そうとエアダスターを吹き込んだからカードのプラスティックの隙間に圧縮空気が
入り込み、内部から分解してしまいましたorz貴重な4GBカードがッ…！！！

とりあえず分解して荼毘に付しました。基板がこんなにペナッペナです。工業用の
堅牢な奴に比べて明らかに強度的に弱いですね。値段も安価なのでいたしかたなし
なのですけど。

●CMD1の初期化はどのカードまで可能なのか！？
12月頭にCMD1による初期化がSDカードのライセンスの影響を避けるために必要だと
えらそうに言ってしまいましたので今回は実際にCMD1のカードで初期化が通るん
かいな？という疑問を実際に動作させて検証していきたいと思います。

使用するカードは256MB～4GB(SDHCじゃない奴)までの容量のSDカードです。
これは春先にひたすら読み込みまくった時の連中をセレクトです。

前回同様STM32F4-DiscoveryのSPI互換モードでSDにアクセスするほうのいつものを
使い、ChaN師謹製の初期化ルーチンからCMD1による初期化のみ残したプログラムを
動作させてファイラーが起動してディレクトリが見えたら初期化成功とします。
…
結果ですがATPProMAX 1GBのminiSDを除きすべてCMD1による初期化が成功しました!
もちろん成功したカードの中には冒頭で紹介したSDこんぱちなTranscendの4GBの
カードも含まれております。

もちろん2016年製造のPanasonicの工業用SDカードもCMD1の初期化が通ってます！
こいつはCMD8の初期化も通るんですよね～。CMD8で通っても4GB以下なのでバイト
アクセスになります。

ちなみに私が持っているeMMCはSPIモードが既に削除されている品種のため、どう
がんばってもSPIモードに突入することができずだめでした。SDカードと同一の形状を
保って方のいるMMCplusなどのv4系カードなら問題無いです。

お次はネイティブモードでCMD1の初期化だけを残した奴を試してみましたが…。
･･･
結果は全滅orz

Argumentとか0にして見ましたが何してもどのカードでもタイムアウトで全滅ですorz
ネイティブモードだとCMD1は通らないのか！？

答えはSDIO Specificationに有りました。以下13ページ目のフローチャートを抜粋。

…
･･･
ネイティブモードが相手ならMMCの例外な実装によってSDカードがたまたま
偶然に動作せざるを得ない！１１！！１(CV:リョウ・サカザキ)

♥ねむいさんのおまとめ♥
電子工作においては現在も入手可能な4GB以下のSDカードに対してSPI互換モードで
CMD1による初期化のみでカードを動作させることは十分可能であり、この方法ならば
SDAのライセンシーにも全く抵触しません。

CMD1が確実に通るカードの中でねむいさんの激押しは
・TOPRAM製4GB
・ドイツ製4GB
・Transcend4GB
この３種の4GBカードです！値段も安いですし4GBもあれば十分でしょー

それ以外の方法(SDネイティブモードによるアクセス、もしくはSDHC/SDXCカードを
使う)をどうしても施行したい場合はソースコード中にMMCが実際に動作できるCMD1
による初期化を残しつつMMCまたは互換カードの例外的な実装によってたまたま動作
しているように見せかけてあげればよいと思います。よくない。

●SD Specfication Version5のカード

ﾃﾚｯﾃﾚｯﾃｰﾃｯﾃｰ　ﾃﾚﾚﾚﾚｯﾃｰ(ﾃｭｨｰｰｰﾝ)

Ｖ！Ｖ！Ｖ！
もういいわ

2000円ちょっとで売っていたのでつい購入してしまいました。以前私はロゴだら
けや！って予言しましたが本当にロゴだらけですね。
V30のビデオ規格のロゴが付与されたものがSDSpecV5のカードの証です。
これにA1ロゴとかもつく予定なのでさらにカオス状態になりそうです。

ねむいさんの予想では山盛りになってしまった性能表記のロゴのすべてを包括する
新たな統一ロゴが来年あたりに登場すると思います。

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 19787 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)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



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 53 45 33 32 47 80 A4 38 40 2C 01 07 C7 .SDSE32G..8@,...



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SE32G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0xA438402C

DateCode.Month     :7

DateCode.Year      :2016



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 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 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.

おやくそくのSDカードの情報を抜き出してみました。
予想通り確かにSD_Specは"5"を示しておりますね★

いろいろ試す25

今回はSDカード関連中心です。

●SDカードの規格がバージョンアップ
SDカードの規格(Specification)が今年夏にV5.00にバージョンアップしています。

主な変更点は4Kや8K等の高精細映像録画に対応した"Video Speed Class recording"
略して"VSC"の追加です。これに対応したカードは｢V6｣とか｢V30｣とかの転送MB数を
保証する"V値"の付いたロゴが付きます。
既存の速度規格もすべて付与されるのでカードはロゴだらけのゴテゴテ状態となっ
ちゃいますね…実際そうなってるようですけど。
市場には現実的に購入可能な値段で既に出回っております。私も金銭的に余裕が
出来たら買って試してみるつもりです。

また、SCRレジスタのSDSpecにはV5.0を示す値が新たに付与されています。V値が書か
れたロゴが付いているカードはこの値が"5"になるはずです。私のいつものの今月の
更新でこちらにも対応していますので、既に入手した人は試してみてください。

20161201追:
ねむいさんいますぐSDAのサイト見てください！！！ってメール頂いたのですが
お昼にSDAのサイト見たら早くもSDSpecV5.1のアナウンスがされていました…。
今度は"Application Performance Class"の追加だそうで…これに対応した
奴は新たにA1なるロゴが付くようです。
もうロゴだらけですよぅ！！！！！

●ところで電子工作でSDカードを使用する際のライセンスの件について
SDカードをシステム用ストレージとして使用する組み込み機器の開発の際に必要な
ライセンスについて、SDAの中の人(具体的にはP＠n＠s○nic(＠と○は伏字)の人)に
確認を取ることになりました。それのついででさりげなく電子工作においてSPI互換
モードでSDカードを動作せしめる際のライセンシーの扱いについても尋ねてみました。
巷でよく言われている｢SPIモードでSDカードを動かす時はSDAとライセンス契約を結ぶ
必要はあるのか！？｣っていう定期的に話題に持ち上がるもやもやしたアレの事です。

本当は枝葉末節の細かい条件に至るまで尋ねたかったのですが、そこまでやって
しまうとさすがにコンサル料を取られてしまいそうなのであくまであたりさわりの
ない範疇で"さりげなく"です。

ね｢そいえばSPI互換モードだとライセンス不要とかトラ技とかにたまに書いて
　　あるんですけどやっぱSPI互換モードでSDカード使う場合でもちゃんと契約
　　結ぶ必要ってあるんですよね？」

P「はい」

…
…
ねむいさん藪をつついて蛇どころかオロチだしちゃいましたごめんね(ﾃﾍﾍﾟﾛ
外人さんも正攻法で尋ねた方がいたみたいで同じ回答をもらっています。

別ジャンルですが今年頭に似たようなことやった人がいてちょっとした騒ぎに
なったケースがありますね。

そもそもの｢SPIモードなら云々｣経緯ですがこれに｢2GBまでのカードなら云々｣
｢SPIモードはCPRM使えないから問題ない｣とか尾ひれが付いたりした文章も
散見されますがMMCとSDカードの歴史を掘ってみると以下の経緯で現在の概念に
変質していったと私は推測します。

①MMC登場！SPI互換モードも搭載！MMCホストはロイヤリティ不要！
　　　　　　　　　　　↓
②MMCをネイティブモードで動作させる際はお金払って動かし方教えて
　もらう必要がある(2016年現在は｢あった｣)。
　　　　　　　　　　　↓
③だけどSPI互換モードについては当時すでに解析されたり一部情報公開
　されたりでホビイストにもMMCの動作方法が知れ渡っていった。
　　　　　　　　　　　↓
④てわけでMMCをSPI互換モードで動かすだけならお金の心配は不要！
　　　　　　　　　　　↓
⑤SDカード登場や！MMC互換のインターフェースやけどSDホストの開発時
　とかSDホスト採用した製品とか売るときはしっかり銭取るで！
　　　　　　　　　　　↓
⑥げー…SDって開発だけでも金取るのかYO…
　ぁ…一部のSDカードはMMCの初期化(CMD1による初期化)が通るやん…
　これはMMCカードとして動かしてるよSDカードじゃないアルよ(棒
　｢MMCホスト上で"たまたま"SDカードが動いてしまった場合開発側はSDAに
　対してロイヤリティを払う責は無い」
　　　　　　　　　　　↓
⑦MMCの初期化が通るSDカードはSDv1のカードのみで一般的に流通している
　のは当時2GBが上限だった(例外はあるが)。当然4GB以上のSDHC(SDv2)は
　CMD8による初期化必須なのでMMCとしての初期化は一切不可能。
　　　　　　　　　　　↓
⑧…そして現在
　①～⑦までの事柄が伝言ゲーム形式でまぜこぜになり｢全てはMMCとして
　の動作である｣という大前提も忘れ｢2GBまでのSDカードでSPIモードで動
　かすならばライセンス不要って聞いた｣とか挙句の果てには｢SPIモードなら
　ライセンス不要なはず」と勝手に危険な解釈しだす。

これはいけない。

2016年現在ではJEDEC(旧MMCA)にもMMCネイティブモードについての簡易資料が
公開されてます。また、アマチュアでもMMCネイティブモードでMMCやeMMCを動作
させた作例なぞ沢山溢れかえっていますからSPI互換モードがとかネイティブモードが
とかは実際はあまり関係はなくMMCとしての動作、つまりCMD1によるカードの初期化
にてカードを動作させているか否かが本当は重要なのです。
それをしっかり理解して情報を公開されているのはサンテック社の製品解説の
ページとChaN氏の解説です。

マイコンでSDカードを使いたければ筋を通すのであればSDAとNDAを結び、さらに
maker系イベントで製作物を販売したいのならHALAも結ぶ必要があります。
企業ならともかく一個人がSDA+HALAの3000USD(2016年現在)の大金を毎年
払うのは荷が重すぎますしSDA側も民事訴訟を仕掛けて利益を回収できるレベルの
悪質な例を除いては黙認している状態なのでしょうね(この辺の関係ってなんだか
同人誌みたいだ…おっと現在は同人ではないケースもあるから薄い本でしたっけ)。

話を戻してわれわれ一個人のホビイストとしてどうすべきかですがねむいさんと
しましてはChaN氏の解説にある｢MMCまたは互換カード対応｣をお題目とすることを
支持いたします。MMC以外の形状互換のメモリーカードを｢MMC互換カード｣と纏めて
看做す作戦です。SDカードもFlashAirも立派なMMC互換カードですからね☆

ここまで徹底する必要があるのかと問われそうですがあなたがweb上で成果を
発表したりmaker系イベント等で成果物を販売したいなんてときにSDカードの
ライセンスを盾に正義感をはき違えたハナクソ野郎に絡まrt問題点を鋭く見つけ出し
追及することに余念がない方の目に止まり貴重な時間を浪費しないためにも論理的
防御策を講じておくのはとても重要なことです。

そのためには実際にMMCもしくはeMMCを動作させることができるのは必要条件です！
これだけはしっかりと行ってください。メーカー配布のライブラリ等ではMMCは最早
過去のものと断定されCMD1による初期化そのものがソースコード上から消去
されてやがるケースもありますので復活させてあげましょう！作品を展示する際も
eMMCをかっこよく使いこなしているところを魅せるとあなたも一目置かれるかも
しれませんヨ！？
↑なんかすでに｢SD対応じゃなくてMMC対応といっておけばいいらしい｣と都合よく
　曲解してる者たちがいるようですが何度も言いますがその製作物上でMMCが実際に
　動作できなかったりCMD1による初期化ルーチンを記述していないソースを公開し
　ちゃったりしてる場合はそのエクスキューズが一切まかり通りません。
　結局嘘ついてることになりますのでSDカードを｢MMCの例外的実装｣と主張できる
　ようにするためにもCMD1にて初期化するMMCが実際に動作するコードは必ず記述
　しておきましょう。

…ぇ？もしかしてねむいさんがわざわざ昔のMMCや変換基板付きのeMMC入手して
動かしたぜアピールしてたのってまさか…ですって？
はいそのまさかです。
でもAndroid等のボードだとロイヤリティフリーなeMMCが花形ですし凝った使い方
しなければSDHC/SDXCとおんなじ使用感覚ですし使い方は覚えておいて損はないと
言い切ることができます！さぁ今日から皆さんもお題目を唱えましょう！
MMCまたは互換カード対応!

MMCまたは互換カード対応!

MMCまたは互換カード対応!
…
20170107追:
CMD1の初期化がどこまで通るか実際に試しました。
20170107追:

でもめんどくさいのでこのぶろぐでは普通に｢SDカード｣って書いちゃいます。
SDAの中の人に怒られたら書き換えます＞＜

肝心な事言い忘れていましたがこれは皆さん存じてるかと思いますがSDやMMCAの
ロゴを各組織のライセンス契約を結ばずに勝手に成果物や展示物に使用した場合、
商標権を侵害したこととなり非親告罪の刑事罰の対象になります！！！
おふざけでやっても御用となるので絶対にやめましょう！！！！！！！

20230918追:
LANGSHIPのたなかまさゆき様がねむいさんのわかりづらい上記の話を
簡潔にまとめてくださいました。
2023年になったんですからSDAもフェアユース条項とかS.M.A.R.T.の
規格を搭載してほしいと思いまし、た！
20230918追:

●74クロックの怪
MMC/SDカードは電源投入後、VDDが2.0V(VDDmin)を越えたら74クロック分カードに
クロックを送出し最初のコマンド(CMD0とか)を受け付ける準備をします。

(part1_500.pdfより)
SDSpecV5.00では電源立ち上がりの規定がさらに詳しく描かれていますのでこれを
参考にしてドライバを組むとどんなカードでも安定して動くと思います。

①SDカード/MMCに供給するクロックは400kHz～100kHzに設定してマイコンのSPI
　若しくはSDIOモジュールを有効にする。
　(SPIと違いSDIO/SDMMCの場合はこの時点ですぐにクロック垂れ流しになる)
②カードに電源投入してカードの電圧がVDD(2.7~3.6V)に達してからさらに1mSec
　待ち、その後最低74クロック供給する。SDIOの場合はクロック垂れ流しなので
　最低74クロック分供給されるまで待つ。
③SPIモードならCS(DAT3)をLOにしてCRC付きでCMD0送信してSPIモードに移行。
　SD/MMCネイティブモードならそのまま各カードの初期化へ

SD/MMCの規格には上記の際のデータラインの信号レベルはどうすべきかが明記
されていませんがSD/MMCはネイティブ/SPI互換に限らずスタートビットで始まり
ストップビットで終わるクロックに同期したビットストリームによって処理されて
いるデバイスであるためビット列の同期を取るため(=スタートビット(LOレベル)を
ちゃんと受けるため)には無信号時はデータ線をHIに固定しておくべきです。

SDIOではコマンド投げてないときはHIレベルでありさらにCLK垂れ流しのため勝手に
74クロック分進んでビットの同期が取れてしまい問題は無いのですがSPIモードの
場合は明示的に74クロック(SPIは8bit単位なので実際は80クロック)送信する必要が
あり、その際のデータとして0xFFを送信してビット同期をとっておかないといけません。

で、説明が長くなりましたがこの74クロックをわざと省くとどうなるか、SPIモードで
SDカードを動作させているSTM32F4Discoveryで実験してみました。

↑80クロック送信してる行をコメントアウトしただけです。

・まずは大昔のSDV1.10の256MBのMicroSDカード
　->無事動作
　･･･あれ？
・お次はさらに超大昔のSDv1.0xの256MBのMiniSD
　->余裕で動いた
　　あれれ？？？
・超最新の東芝Exceria並行輸入版MicroSDXC64GBの奴！！
　->余裕で動いた
　　？？？？？
・Sandiskの金色の奴！！
　->余　裕　で　動　い　た
　　？？？？？
・じ、じゃぁMMCPlusの2GBの奴！
　->余裕余裕♥
　　は？(CV:スパーク・マンドリラー)
　　んぁ～すまんが～ねむいさんが正しくてお前が間違ってるってことはぁ～ないかぁ？
・さすがにMMCv3の128MBの骨董品なら74クロック抜きじゃ初期化できないでしょ！！
　->余裕のよっちゃん
　　････
・さっきのMMCPlusの2GBは1.8V動作も出来るからこれなら絶対動かんでしょ！！
　
　ここでちょっと素敵デヴァイスの紹介です。
　今年春にヘル朝鮮製のSD->MicroSDの変換アダプタ買ってウボァーしましたが
　その後台湾製のちゃんとした作りのSD->MicroSD変換基板を購入しました。
　これは信号も安定していて安心して使えます♥カードに供給する電圧も
　1.8Vに切り替えられますし♥
　->1.8Vでも正常動作♥
　　?????????????????????????????????????????

･･････････････
わけがわかりませんよぅ･･･

・結論・
結構いい加減な初期化でも大抵のカードは動いた。STM32はこういう結果になり
ましたが他のマイコンやChaN氏の作例に沿ったコーディング以外では動かないかも
しれませんのしっかり規格を守って動かしましょうね！特にCLKを除く信号線の
外部プルアップは必ず施しましょう！

20161214追：
xilinxのサイトで今回のSDカードの74クロックについて言及しているページが
ありました。やはり電源が+3.3Vになりさえすれば74クロック放たなくても
実際は殆どのカードで余裕で動いてしまうようですね！

その一方でChaN氏からコメントいただきましたとおりねむいさんのSTM32F4向けの
SPI互換モード版ではCMDを発行する前にビジーチェックする先行ビジーチェックの
方式をとっていますのでこれにより最低3バイト分のSPIクロックを空撃ちをする形と
なります。xilinxの見解と合わせるとこれだけでもう十分なクロックを放っている
と言えますね。

そしてFatFsとSTM32F4のSPIを結合するHALに相当する私のコードはChaN氏の
AVR向け実装例を源流としています。今回の検証でChaN氏のコードのロバスト性の
高さが判明し今更ながらChaN氏の偉大さがまた一つ確認された形となりました。

･･･ｻｽｶﾞﾀﾞｧ♥

●UHSモードの識別とか
現在主流になった"UHS-1"モードは通電中にI/Oの電圧を1.8Vに遷移させ消費電力の
低減と電圧スイング幅が狭くなった事による速度の向上を図るモードです。
しかしながらSTM32ですらマイコン単体でI/O電位を3.3V->1.8Vに遷移できる機構を
持つ品種は存在しないのであんまし意味は有りませんがUHSに対応しているか否か
程度は判別できるので組み込んでみました。

具体的には初期化動作時、つまりACMD41送出の際の引数にS18Rビット(24ビット目)を
立てるだけです。対応していればOCRレジスタに24番目のビットが立った状態で
返事が返ってきます。

通常OCRレジスタが0xC0FF0800と読み出されるところでS18Rビットが有効だった場合
0xC1FF0800となります。UHS-IIをサポートしたカードだと28ビット目がたちます。
でもそういったカードが私の手に入るのはまだまだ先でしょうけども。

ついでに今月のいつものの更新でSPI互換モードで取得できるSDカードの情報を大幅に
強化しています。SDIO/SDMMCとほぼ同じレベルとなりました♥

それはさておきちょっと興味深い発見をしました。
殆どのカードはSDネイティブモードでもSPI互換モードでも読み出された値は同じに
なるのですがSandiskのカードだけはSPI互換モードの場合はS18Rビットを立てた
引数でACMD41を送出しても反応がありませんでした。
いくつか試しましたがUHS-I対応を謳うUltraやExtremeのカードは全てダメでした。
もちろんSDネイティブモードの時は問題ないです。

Drive size: 15523840 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 3B 37 7F 80 0A 40 40 AF @..2[Y..;7...@@.

CID:

00000000  03 53 44 53 55 30 38 47 80 1B B8 C2 F6 00 C8 2F .SDSU08G......./



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SU08G

Product HwRev      :8

Serial Number      :0x1BB8C2F6

DateCode.Month     :8

DateCode.Year      :2012



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 03 00 00 00 04 00 90 00 14 05 1A 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 35 80 03 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Spec Version X  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

Available UHS-I Mode.

SDネイティブモードの時

Drive size: 15523840 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 3B 37 7F 80 0A 40 40 AF @..2[Y..;7...@@.

CID:

00000000  03 53 44 53 55 30 38 47 80 1B B8 C2 F6 00 C8 2F .SDSU08G......./



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SU08G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x1BB8C2F6

DateCode.Month     :8

DateCode.Year      :2012



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  00 00 00 00 03 00 00 00 04 00 90 00 14 05 1A 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 35 80 03 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Spec Version X  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

Available NS(or HS) Mode Only.

SPI互換モードの時

そもそもSPI互換モードではUHSモードは一切サポートせずNS(MAX25MHz)
どまりなので反応しなくても実害はないのですけど。

SDカードは奥が深いですね。

WVGAな解像度で容量性タッチパネルなTFT-LCDモジュールを動かすその2

どこへ行っていたンだッ！カンガルー先輩ッッ！！
俺達は君を待っていたッッッ！！

なんとめでたい･･･いつの間にかトラ技にカンガルー先輩が帰って来てくれて
ましたよぅ！また暴れまわろうＺＥ☆
めでたしめでたし♥

以下はおまけです。

前回のWVGA液晶の紹介の際にコメント欄で早々にネタバレされてしまい、おまけに
六甲全山縦走路の攻略とかなにやらでサボっていた隙に章さんに先を越されて
しまいましたが480x800をさらに越える480x854という膨大なサイズを持ちつつ容量性
タッチパネルを当たり前のように持つ5inchなTFT-LCDモジュールを4ヶ月くらい
以上前に入手して動作せしめておりますので紹介させていただきます。

前回モジュールとの大きさ比較です。4.3inchでもでかいと感じてましたが5inchの
爆☆発☆的な存在感には到底及びませんね～♥
TFTのコントローラICはILI9806Gとなります。

ここでいきなりですが前回と同じ注意ですが大解像度の液晶モジュールでは
コントローラIC内のフレームバッファ用RAM容量の節約のために本来必要な量の
半分に削られているHalf-RAMモデルのコントローラICが存在します。

大きい解像度だとマイコンとの接続もSPIとかFSMC等のi8080スタイルのMCUバスに
よる接続よりもRGBインターフェースで繋げたほうが効率が良くなるため、少し
でもコストを下げるためにこのような品種が存在しているかとおもわれます。

ちなみにHalf-RAMモデルのコントローラは偶数アドレスしか指定できず、奇数
アドレスを指定しても無効になるので意図した座標にドットを上手く打つことが
出来ず表示がぼろぼろに崩れます(偶数アドレスだけを指定する使いかたならOk)。

ですから私にとっては私のいつものとはものすごく相性が悪く、単なる地雷に
ほかなりませんのでHalf-RAMモデルのコントローラICが乗ったTFT-LCDの購入は
極力避けております。
以下に私がうっかり購入してウボァーした品種を列挙します。

D51E5TA7601
->これは320x480のHVGAなTFT-LCDで中華通販で良く見かけるのでご注意ください。
OTM8012A
->これはWVGAなTFT-LCDコントローラではポピュラーなOTM8009AのHalf-RAM版
　です。OTM8009Aとくらべてあまり遭遇しないので多分大丈夫でしょう。
ILI9806H
ｰ>これは前出のILI9806Gとものすごく間違えやすいですからご注意ください！
　これも中華通販で良く出回っています。うっかり買ってしまうとｱｳﾂです！

話を戻しましょう。動かし方は初期化の呪文を唱えた後は有名なILI9341たちと同じ
ようにMIPI DisplayCommandSetに倣って0x2A,0x2Bでレクタングルを指定したら
0x2Cでデータを送信するというお決まりのパターンです。

そしてこのモジュールではIMxが外に出ていてデータビット幅とかも変更可能です。
ここまで解像度でかくなるとSTM32F4のFSMCでもきついはずなのでなるべく
デフォルトの16bit幅で使うようにしましょ。

もはや説明不要のFatFsとSDカードの動作試験も兼ねたいつもの。

480x854もの広大なサイズなのでいないさんの表示もらくらくです。
前回と比べて54ドット分ちょっと足先が長めに見えているのが分かると思います。
これだけでかい画面を十分に光らせるためバックライト用のLEDの電力消費が著しく、
モジュール全体で常に100mA以上喰うので3.3Vの電源供給は十分に行ってください。

さらに液晶自身の発色もかなり良くなっていてご覧のとおりいないさんの美しい
肌が青映りせず鮮やかに表示されています♥
有機ELとはなんだったのか…

液晶そのものの話はこの辺にしてお次はタッチパネル部分のお話です。
このモジュールは抵抗膜式タッチパネルと容量性タッチパネルの両方が選べます。
もちろんねむいさんは容量製タッチパネルのモデルを購入しましたが前回の物とは
かなり勝手が違い苦戦しました。このモジュールに使用されているCTPコントローラ
ICはFocaltech社のFT5336GQQという相互容量方式の品種です。

そう、こいつはSTM32F746G-Discoveryに乗っていた奴と同じなのです！あのときは
STマイクロ提供のBSPに頼りっぱなしでした。尤も前回でSPLでI2C接続のCTPコント
ローラを叩くためのルーチンをこさえて居たのでこれも問題ないだろうと思って
いたらなんと画面に触った時だけ変化があるINT出力の挙動がまったく違っていて
入力がまったく受け付けられていない状態となっていやがりました。

↑画面をタッチした時のINT出力波形(前回モジュール)

↑画面をタッチした時のINT出力波形(今回モジュール)

しかも今回のは内部でIOVDDが1.8Vにされているのか1.8Vしか出ていません！
(ていうか3.3Vでプルアップしてるのに1.8Vとか出力ODじゃ無いのかYO!)

一応STM32の+3.3V動作時のハイレベルのスレッショルドは切っているので電位の
問題ではなく処理の問題だと判断し、100mSec単位のポーリングで行っていたINT
の処理を割り込みに変えたりあーだこーだやっていましたが思ったように
座標データをとることがなんでか出来ませんでした。

結局100mSec単位のポーリングでSTM32の外部割込みのフラグを見てデータを取り
込むことで従来どおりの操作感覚を取り戻すことが出来ました。
EXTIだけ有効にしてNVICの設定は行わず割り込みベクタそのものに飛ばさないのが
ミソです。毎回割り込み処理に飛ばしているとタッチパネルに触ってる間ずっと
割り込みが発生することになり他の処理がまったく出来なくなっちゃいますので。
ねむいさんのいつもののtouch_if_basis.cやtouch_if.cを見ていただいたら私の
あがきの跡が分かるかと思います。

あとねむいさんが想定したY軸の座標が上下さかさまだったのでこれも前回
モジュールにあわせるようにしています。もしかして気付いてた方もいたかと
思いますが6月の終りにはすでにコードに仕込んでおりました。

ちなみにFT5336GQQのデバイスIDは0x51だそうです。

5inchは良い。心が洗われるね。

こんなわけで6月の終りくらいに購入したモジュールをいまさら紹介するハメに
なってしまいましたがSTM32のFSMCで賄うことが出来る中では実寸や解像度的に
今度こそ！
これが最強最後のTFT-LCDモジュールである！と言う事が出来ると思います！！
たぶん来年あたりも同じこと言ってるかも知れませんがー！

WVGAな解像度で容量性タッチパネルなTFT-LCDモジュールを動かすその1

数年前にこのLCDが最強最後とか言いましたが･･･
ありゃウソですよぅ

これがっ！480x800でッ！IPSの広視野角でッ！しかもCTP(容量製タッチパネル)
までついったっ！MCUバス向けの最強最後のTFT-LCDモジュールです！！！！！
そしてサイズは4inch!!

中華通販で変換基板付で購入しました。配線の手間が省けて超ラクです♥

TFT-LCDのコントローラICはRM68120という480x800サイズに対応したものです。

ここでちょっと気をつけなければならないのは、大きなサイズのLCDコントローラIC
では内部RAMが半分もしくは全部ない場合があり、そういった品種では8-bit,および
16-bitバスなどのMCUバス経由ではマトモに表示することが出来ません。中華通販で
買うときはご注意ください。

容量製タッチパネル(CTP)は抵抗膜式タッチパネルよりも処理が複雑でマイコン
単体では賄いきれないため専用ICがほぼ確実にセットになっております。

ICの頭にFT5216GM7と書いています。FocalTech社のICですね。
ネットでいろいろ調べてみたのですがFocalTech社のデータシートでよい物が
なかなか見つかりませんがこのCTPコントローラICは2.8～5インチで相互容量
方式となっています。STM32F7-Discvery(F769版も)にはFT5336GQQという
マルチタッチサポートな相互容量方式のものが使われています。

容量性タッチパネルコントローラの自己と相互の方式の違いについては
ノリタケLCDさんちの説明がとても分かりやすいです。

さて、このFT5216はタッチポイントが一つしか搭載していません。結局抵抗膜式と
あんまし変わらない感覚ですので使い勝手を抵抗膜式の時と同じになるように、
FT5xx6シリーズはタッチポイントが5つまで、さらにジェスチャ機能もサポート
しておりますが、従来の抵抗膜式タッチパネルと同じ感覚で操作できるように
いつものにCTP向けの処理を追加していきました。

世に出回っているCTPコントローラはI2Cインターフェースと外部割込み
用端子がでているものが殆どです。当然ながらSPIよりも速度が遅いくせに
シビアなI2Cペリフェラルの操作が要求されるのでご注意ください。
また、殆どのケースでINT割り込みの処理が必須になるでしょう。

で、動かしているところです。まずCTPコントローラICのdeviceIDを読み
取って表示できるようにしました。0x79はFT5216の証です。

そんでもっていないさんの全身図を♥
480x800の世界ってｽﾊﾞﾗｼｲ♥

昨年まではWVGAサイズなTFT-LCDも容量性タッチパネルもなかなか手が伸びにく
く実験レベルで終わっていたジャンルでしたが、現在では気軽に利用できる段階に
までなったと感じております。これから先どんどん活躍していく事でしょう。

なんとこの記事、次回につづきます･･･

コスプレ大好きいないさん
どうでもいいですがねむいさん自身いなちゃんが誰のキャラのコスプレしてるのか
知らなかった･･･

いろいろ試す24

今年の暑は夏いですね････
頭が沸騰して凝固しないように少しでも文章を残す訓練をしないと･･･

●LPC11U14の悲劇
マジかよ･･･ユーザーマニュアルにはROMディバイダあるって明記してあるのに･･･

というわけで実機で調べてみました。ねむいさんの持っていたLPC11U14Expressoは
最々初期のLPC11U14が乗っています。

0x1FFF1FF8にはROMドライバのアドレスが格納されています。実アドレスは
0x1FFF1E38となっています。

LPC11UxxのROMディバイダへのポインタが格納されているアドレスはその先頭
から16バイト先にあります。つまり0x1FFF1E48に有効なアドレスが格納されて
いない場合ROMディバイダは使用不可能となります！

ア"ア"ア"ア"ア"ア"ア"ーーーーーーーッ！！！！

･･･
NxPのLPCマイコンはこう言う罠がたくさん張り巡らされていますのでユーザー
マニュアルとか鵜呑みにしないで海外のフォーラムも積極的に巡って情報を
収集してください。

そいえば2年位前ねむいさんが指摘したLPC1500のIAPのアドレスが間違ってる件も
2016年現在まだ治ってない･･･NxP(xは伏字)さんにメッセ送ったのに･･･。

●STM32Primer2を使ったGNSSロガーのリポ電池を変更
ねむいさんはトレランのトラックログ取り用にSTM32Primer2にハード的改造を施し、
それをGNSSロガーとして使用しております。電池もSparkfun製の1000mAhの
リポ電池に乗せ買え12h以上稼動できるようにしていました。
そして2010年から約6年間もの間戦い続けてきたそのリポ電池もかなりへたってきたので
交換する運びとなったわけです。

･･･がしかし！！！なんと昨今の規制強化のせいか850mAh以上の大容量のリポ電池が
軒並み販売終了となっていて購入する事が出来なくなっておりました！！！

探しに探しまくってこちらの通販会社さんから1000mAhのリポ電池を購入する事に
しました。最悪中華直販から輸入も考えたのですがチャイナボカンされたら困るので
国内から購入できる店があって助かりました♥

で、来たのはこちら。
6年前に購入したSparkFun製のものより薄く少し長くなっています。もちろん保護
回路付コネクタ付です。

元からついているコネクタは不要なのでJSTのRCYコネクタに付け直しました。
これで電池の脱着が自由に出来ます。･･･以前はテストのために直付けしたので
6年間そのままにしてましたが今回の電池交換でようやくです。

ぁーちなみにハーネスの力がかかる部分をポリイミドテープでガチガチに固定して
ますがこいつ意外と剥がれません！wifiモジュールをポリイミドでガチガチに固定してた
EnchantMOONのこと｢こんなん振動ですぐ取れるやん｣とさんざ馬鹿にしてましたが
前言撤回ですすみません！！でもよい子は真似しちゃだめだよ！

もちろん交換後も無事正常起動しました。
2016年真夏の炎天下の近畿自然歩道でバリバリ活躍しております！

たぶんねむいさんが世界でSTM32Primer2をいちばん長く使い続けてる女だと
思います･･･！もちろんあと30年は電池交換し続けて使い倒しますよぅ！

●FatFsに大量のぱっち
今年の四月にExFatに対応したChaN氏のFatFsですが、ねむいさん含めた有志からの
使用報告を受けパッチがパチパチ当たってます。現在はpatch7まで行っていますが
ねむいさんもそれに即追従してアップデートしております。

私が特に力を入れているSTM32F7をはじめSTM32F4系、STM32F1系も順次最新の
ものにアップデートしております。皆様どしどしご利用ください★

●ウィルキンソンドライコーラ

･･･
甘味抜いたタブクリアだこれ

●おそロシアふたたび
Latticeの提供しているプログラミングツールはFT2232H系のデバイスに対応して
いてJTAGKey2CompatibleでもEEPROMを書きかえるだけでLatticeのプログラマに
化けるナイスな対応をしてくれましたが、AlteraとXilinxのツールはかたくなに
FT2232系のデバイスには対応しておりませんでした。
しかしながらロシアから恐ろしい刺客がやって来たのです･･･！もちろんLatticeと
違ってかなりダーティな裏技なので詳しいやり方は伏せさせていただきます･･･。

こちらのロシア系BBSのリンク先にあるとあるファイルにAlteraのプログラミング
ツールにFTDI系デバイスを対応させるdllがあり、それに差し替えるだけでQuartus
からAlteraのCPLD/FPGAのプログラミングツールとして使えちゃいます！！！

↑実際に使ってるところ。書き込み速度はもちろん超★爆★速！
　もうこれでUSBBlasterもどき作らなくてもいいんじゃ♥

そして問題のXilinx....
ねむいさんは過去に何度もXに挑戦し敗れてきましたがおそロシアのおかげでついに、
ついに攻略せしめました！！！！
注：ただし以下の条件を全て満たす必要があります。
　　１．FT2232Hのみ有効。FT232HやFT2232Dは不可！
　　２．FT2232Hにぶら下がるEEPROMは93LC56もしくは93LC66のみ有効。
　　　　93LC46はユーザー領域が足らず不可！
　　３．JTAGKey2 Compatible Rev.5を使用する場合、メインモジュールの
　　　　DLP-USB1232Hに搭載されたモジュールが93LC56or93LC66である事。
　　　　これは何が来るか分からないのでばくちですね･･･しかもQFNパッケなの
　　　　で引っぺがすのは普通の人にはちょっと無理でしょう。
　　　　かわりにFT2232H Minimoduleがオススメです。これ93LC56乗ってますし。

↑コツですがMProgを使ってEEPROMのデータを書きこむときにシリアルナンバを
　"有効"にしておきます。この後FTDI_User_Area_Writer.exeを起動しMprog/FTProg
　からは書き込めないユーザ領域にデータを書きこみます。

やったぜ。Digile○ntのJTAG-HS2として認識されました♥ちなみにISE14.7は
プラグインの調達の必要もなくIMPACTから普通に使えます。

実際にSPARTAN3をつなげてJTAGチェインを見てみます。

やったぜ！

もちろんふつうにコンフィグレーションできます♥

2010年からずっと奮闘してきた内容ですがようやくつっかえていた小骨が取れた
感じです♥EEPROMを書き換える少しの手間はありますがこれでねむいさん謹製の
JTAGKey2Compatibleが更に強力なフラッシュ書き込み/デバッグツールとして
活躍していけると思います！！

いろいろ試す23

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

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

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

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

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

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

ぱちもんでしたー！！！！
クソァ！！１！１！！１

ちなみにぱちもん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"
に書き換えておいてください･･･。
↑ご協力ありがとうございました(ぺっこりん

皆様へ、
おきぱのSTM32F4とSTM32F7向けのいつものは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型乾電池と比べると電流容量はかなり低いですがテスタのような
消費電力が低い機器で使用する分にはまったく問題は無いのでオススメです♥

いろいろ試す22

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

●フェライトビーズの使いどころ

注：SDMMC/SDIOのCLK信号に対してはまず初めに直列終端を行ってください。
　　それでもだめなら下記フェライトビーズの使用を考えてください。

ねむいさんはおきぱで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版が出る！
一年に４回リリースされる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年位前のはなｓ･･･グハッ！！！！

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

Q:スマホでピッ！簡単電子工作★
A:ま　だ　ガ　ラ　ケ　ー　使　っ　て　ま　す
　っ　て　言　っ　て　る　で　し　ょ　ｺﾝﾁｸｼｮｰ

(以下ほぼ実際にあったやり取りですだいぶ前の話ですがもう時効だから書きます)
Qr:鶴岡工場(旧NECエレ系列工場)閉鎖ね
A:あっそ良かったねおめでたうございまｓ･･確かここって旧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出版の
　お問い合わせにメールで(差出人の方の名)さんはそちらに在籍されていますか？
　とたずねたのですが問い合わせをしてからはや約１年と８ヶ月、何の音沙汰も
　ありません。問い合わせついでにトラ技の誤植を指摘したのがいけなかったのでしょうか･･･
　やっぱし本当にフィッシング目的の偽装メールだったかも。

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

2015.12.29 Tuesday
23:24
ネムイ・トリノミアス
MISC
-
-

JTAGKey2互換回路をもっと使ってみる3 -決着をつけてやる！-

とりあえず回路図見たい奴は此処や！

●モロ!
2010年に始まり2013年に一応の決着を見たはずのJTAGKey2互換回路製作ですが･･･
ねむいさんは未だモロにこだわっていた。尤もここでいうモロは未加工の紳士画像を
虹裏に張り付けせしめる野蛮な行為ではなく、FT2232HのLVTTLの出力を電圧レベル
トランスレーター74LVCE1G125の5V動作時のCMOS入力に直接モロに入力せしめる
乱暴な行為を指します。

JTAGKey2互換回路において、モロで何が悪いかというとターゲットの電圧が5V系で
動作してるケースです。このとき74LVCE1G125のVIHは3.5V以上となり、FT2232Hの
LVTTLの3.3Vの出力では規格を満たすことができません。
逆に74AHCT541等の高速なバッファを挟んで正規に5VCMOSレベルまで上げてみまし
たが今度はAHCTバッファの大きな伝搬遅延が影響してFT2232Hの特徴である30MHz
動作が出来なくなってしまいました。

そんなわけで私は5V系で電圧・動作温度にマージンをかなり取ってモロった時の動作に
問題が無いことを確認し、規格は満たしてないけど私の回路図と指定した部品使えば
5V系でも実力値で問題なく使えます！…とお茶を濁していました。
しかし心の奥底でルールに反した事をしているとわだかまりを残したまま、TTLレベル
入力でなおかつ1.4～5.5Vの電圧範囲で動き、それでいて伝播遅延も少ない夢のような
デバイスの到来を期待しておりました…。

●ｱﾁｬﾓ･･･
時は流れ、半導体製造プロセスも進化したおかげか5V動作時にTTLレベルの入力電圧
範囲を持ち、それでいて速度もそこそこ早く動作電圧範囲もそこそこ広いまさに待ち望
んでいたバッファICがリリースされておりました！TIから2014年秋口にリリースされた
LV系レベルシフタSN74LV4T125です！

以前からワンゲートロジックのSN74LV1T125は既に出ていたましたがSN74LV4T125は
4回路ぶんコミコミでなおかつ出力電流と伝搬遅延特性が改善されています。
電圧範囲は1.60~5.5Vとちょっと電圧下限の保証が低いけどこれなら勝てる！！
しかし…

遅延で1ビットずつずれてやがる…orz

ちなみに正常に認識した時はこのような感じになるはずでした。

なんか包帯ぐるぐる巻きの猪狩さんに気を取られているうちに佐山聡似の不気味な飴玉
レスラーに不意打ちを受けてさらにチョビ髭ノッポなキックボクサー崩れのレスラー(？)
に追い打ち喰らって｢あちゃ～～もろ････｣とか言われたような気分です。
やはりTTL入力を実現するため追加されているはずの内部ゲートの遅延がかなり
足を引っ張り結局74AHCT541を経由させたのと同じになっちゃいました。

そんなわけで安きに逃げるのは止めて既存のFT2232Hを使用している+5V動作を
保障しているJTAGアダプタたちは実際にどのようにして電圧レベルの変換を行い、
かつ速度も保証しているのかじっくり調査をしてみることにしました…。

●あくまでもモロにこだわる
夜逃げしたAmontecの過去の資料を穴の開くほど調べてみるとオリジナルJTAGKey2
のサポート"電圧"は確かに1.4V～5.5Vでした。
この"電圧"と言うのはターゲット電圧(Vtgt)そのものを指し、JTAGインターフェース
のI/Oの電圧レベルではありません。AmontecJTAGKey2の紹介文をよく読んでみると、
"5V"ではなくわざわざ"5VTTL"と明記されています。5VTTLの出力は5VCMOSの
入力を満たすことができませんのでオリジナルのJTAGKey2はVtgtが5Vであっても5V
フルスイングのCMOSレベルの出力を出せていなかった可能性があります。

ほんとにそうなのかは販売元のAmontec及びAmontecの中の人にI/Oの電圧特性に
ついて詳細を聞けばよいのですが残念ながら夜逃げして早数年経った今はそれはかない
ません。しかもいくつかMLに残された中の人の軌跡を手繰ってみると中の人はサポート
下限は1.4Vのはずなのに1.2Vとのたまっていたり5VCMOSサポート！とおもいくそ
のたまっていたり議論中に突然Amontecの製品の宣伝をしだしたり挙句の果てに"問題は
モニタとイスの間にある!(=お前もう出てけ!)"と言われたり夜逃げしてからは"あいつ
もう死んだんじゃねーの？"とか言われたりﾎﾞﾛｸｿです。最早あまりのクソコテっぷりに
Switzer版ぴるすにしか見えないんですけぉ…
ねむいさんも彼を墓から引きずり出して殴る蹴るの残虐行為はしたくはないのですが、
オリジナルのJTAGKey2の電圧/速度スペックについてはほんとに額面通りであるのか？
懐疑的にならざるを得ませんでした。

とにもかくにもI/O電圧のレベルの上限は5VCMOSではなく、5VTTLレベルであること
は明確となりましたので一歩前進です。5VTTLレベルの出力規格2.4V以上をみたし、
なおかつFT2232Hの出力(3.3V-LVTTL)と74LVCE1G125たちのVIH(0.75VDD)を満たす
ためにはVtgtから何らかの形で電圧を落とし74LVCE1G125に掛かる電圧(Vrefとします)
の上限値を4.0V付近にクランプしてやれば解決です。

また乱暴なことを…と言いたい方もいらっしゃいますかと思いますが実はこの技、5V系
なVtgtで受けつつTTLレベルの電圧をやり取りするために実際に商業向けの商品にも
使用されているれっきとしたものです。それが使われている例をご紹介します。

↑xilinx platformcable データシートより引用
xilinxのプラットフォームケーブルUSBI/IIはデータシートに入出力バッファについて
の極めて有用な解説が記載されています(ここまで細かい資料って昔あったっけ????)

↑xilinx platformcable データシートより引用
プラットフォームケーブルはJTAGの出力にはUHSBufferなるNC7SZ125が使用され、TDO等の
入力には3.3V動作の超高速コンパレータで約1V前後のスレッショルドで取り込まれています。
(※プラットフォームケーブルIIは単なるロジックで受けているようです)

↑xilinx platformcableII データシートより引用
さらにVrefを生成するための回路は至って原始的で3.9Vのツェナーダイオードと抵抗で
Vtgtを強制的に3.9V付近にクランプさせUHSBuffer等に供給するVref上限を3.9Vまで
としていました！もちろん5Vをぶち込むとそこで80mA以上消費され、ダイオードと
抵抗にかなりの発熱を伴うのは容易に分かりますがなんて男らしい実装だ…！

さらにUHSBufferたるNC7SZ125は2000年代初頭にすでに存在している高速ロジックIC
なのですが、こいつの推奨動作電圧範囲の下限は1.65Vとなります。つまりプラット
フォームケーブルが保証しているはずの1.5VLVTTL/CMOSはこのロジックICの推奨範囲
から逸脱して使用されているわけで勿論設計された当初は74LVCEシリーズなんて存在
しなかったので結構ルールから外れた(でも最大定格範囲内の動作を守っている)結構
苦しい使い方されていたのが判明しました。

オリジナルJTAGKey2でも中の人が言っていた"UHSBuffer"とやらのスペックを見ると
当時の状況からはこのNC7SZ125以外に選択肢は考えられないので"最大定格範囲を
超えない"ようにしつつ推奨動作定格を破って動かしていた可能性が極めて高いと推定
しました。おそらくVtgtも何らかの形で4.0V付近にクランプしてVrefを作っていた
はずです。さすがにツェナーダイオード+抵抗の超乱暴実装ではないはずですが…。
まさか…。

また、CMOSの特性上VDDが低下すると伝搬遅延時間も大幅に増加していきます。

↑xilinx platformcableII データシートより引用
プラットフォームケーブルのデータシートではそれについての注意事項がありますが、
オリジナルJTAGKey2にはそんな記述すらないのですがTCK=30MHzの最大スピードで
動作せしめられるようなものは3.3V系のごく限られたターゲットのみでそれ以下の
電圧や速く動くデバイスがそもそも存在しない5V系では結局は良くても最大10MHz
くらいしか出せなかったのではないかと推測します。

●私はもうﾃｨｷﾝじゃない
そんなわけでだいぶ実態が分かってきました。ねむいさんが取れる選択肢は究極
の二択になります。

一つ、冒頭のSN74LV4T125を使用して30MHz動作と1.65V以下の保証を捨てる。
->1.5VCMOS/LVTTLを使用する場面や30MHz動作できるターゲットがほとんどないので
　そいつらをあきらめてSN74LV4T125で組むと自作のハードルがかなり下がります。
　5VCMOSでも規格を満たします。初めてドングルを作る人向けです。

一つ、オリジナルのJTAGKey2のロジックレベル保証を忠実に守る。
->1.5VLVCMOS/LVTTLから5VTTLに至るまでの電圧範囲をサポートせしめる！！！
　2015年現在存在する新しい超高速ロジックICなら低電圧領域でも速度がある程度
　保証されます。その代り回路は複雑になり、使い方にも注意が必要です。

ねむいさんはもちろんオリジナルJTAGKey2の電圧範囲を忠実に守ります！！！
そんなわけでJTAGKey2Compatibleのキモにあたる部分の解説をおさらいを
兼ねて改めてしていきましょう。

TCK,TDI,TMS,SRST,TRSTはDIODES-Zetex社の74LVCE1G125です。
1.4Vから動作するので1.5V系も正式にサポートです★

TDO,RTCK,SRST_inはNexperia(旧NxP)社の74LVC2T45です。こいつは1.2Vから動作する
すごい奴です。この図だけ見るとパスコン乗せてないように見えますが
PDFにはちゃんと乗せてますのでご安心ください。

オプション扱いだった74AHCT541は廃して今回新たに4V出力のレギュレータを追加し
ました。これで5V系のシステム相手でも5VTTLの電圧レベルをサポートできます！
4V以下ではLDOの特性上内部消費電流が増加しますがこの東芝のTCR2EF40は内部
消費はmA以下のオーダーなので発熱も全くなく電圧クランプとしての役割を十分に
果たしてくれます。さらに最低動作電圧は約1V付近と一般的なLDO比べて十分低い
ので1.5V系の時の動作でも電圧が暴れず安定して使用できます♥
勿論全てのLDOがこのような使い方ができるとは限りません！しっかりとデータシート
の特性グラフとにらめっこして目的に最適なものを選んでいきましょう！

●ありがとうV戦士モロ

2年前作ったJTAGKey2CompatibleRev.4にレギュレータを追加しただけですので
見た目はまったく変わってません。74AHCT541乗っかったままですが
どこにも繋がっておらずもはやただのオブジェと化しています。

レギュレータは赤丸でかこった箇所につけました。現在は1608サイズで10uFで
しかも温度特性もそこそこのよいMLCCが売られているので早速使っています★

3.3Vの挙動については回路構成はRev.4以前とまったく同じですので5V系と1.5V系
のきわきわの動作を見ていきます。

前回と同じ条件でATMEGA1284Pをターゲットデバイスに選び検証します。今回は電圧
レベルの問題で引っかかるのはJTAGKey2内部ではなくJTAGKey2の出力バッファと
AVR間です。AVRを選んだ理由は前回と同じものを使ったから条件があわせやすいのと
VIHが通常のCMOS(0.7~0.75VDD)よりも大きい0.8VDDを要求しているからです。
VDD=5.65Vの厳しい条件で温度を振って書き込みや消去が正常にできたらねむいさんの
勝利です！！！
(注:1.5Vの時はAVRの動作補償範囲からはずれ、JTAGのTCK周波数許容値が
　　下がってしまうので今回は一律10MHzではなく4500kHzで検証しています。)

勝った･･･！

手抜きではないのですがATMEGA1284Pの動作保証下限1.8Vを割って1.5Vでも
問題なく動作可能です♥これで1.5VLVCMOS~5VTTLレベルの電圧レベルでは
完全に動作することが確認できてさらに5VCMOSレベルも問題なく動作する実力が
あるのもわかりました♥

ちなみにATMEGA1284Pの内部CR発振器は結構根性があって一度発振できたら1.35V
くらいまで下げても余裕で動作するのがわかりました。電池一本で動きますよ。
さすがにJTAGのTCKの周波数は大幅に下がって1MHzくらいじゃないと駄目ですが。

動作可能なI/O電圧レベルを表にするとこんな感じです。最もパフォーマンスが
出るのは3.3VLVCMOS/LVTTLの時です。5VCMOSでは上述のとおり規格を一部
満たしていませんが動作する実力が確認されたので×ではなく△印つけています。
尤も相手がCMOSならば入力電流もMAX10uA位しかないでしょうから3.8V以上は
余裕で保てるので+5VCMOSでも問題ないですね。

そんなわけで長きに渡る戦いに終止符を打たせていただきます。ですがこれから先、
技術革新が進みTTL入力コンパチでなおかつ伝播遅延が3.3Vでも3nSec以下のすごい
バッファICが出たらまたJTAGKey2Compatibleの改良に取り組みたいと思います！

JTAGKey2Compatible Revision5
↑OpenOCDでSWDしたいときの追加回路もついでに追加しています。

いろいろ試す21…という名の今年も反省会

　　　　　　　　　　　　　　　　お詫び

私ネムイ・トリノミアスは国土地理院とgooglearthの規約を思いくそぶっちして地図
画像をぶち上げておりました。ここにお詫び申しあげますm( _ _ )m

何がダメだったかというと国土地理院の場合はカシミール3Dを使用して表示した
画面を、googleearthは同プログラムを使用してGPS軌跡を表示した画面をキャプ
チャーしたものをブログ上にそのまま上げてしまったことです。

国土地理院のほうは問答無用の完全アウツでgoogleearthのほうは以前は
googleのロゴが画面中に出ていればOKだったのですが今はそれが完全に禁止され、
使いづらいAPI経由の地図表示でないと許されなくなっていました。
20160729追:
googleの方はくそ使いづらいAPIに苦情がありまくったらしく著作権帰属表記
がなされていれば問題なくなりました。よかったよかった♥
20160729追:

というわけで11月くらいからせこせこと過去の東海自然歩道やGPS/GNSS関連の
記事はそれらの問題に引っかからないように修正を今もし続けておりますす
みません。

とはいえ国土地理院に関しては承認をもらえば逆に参照し放題となるので
この際なので正式に地図の使用承認をもらうことにしました。

20230910追:
現在ではねむいさんのようなケースでは複製承認は不要になりました！
一応過去はこうでしたよという記録として記事はそのままにしておきます。
20230910追:

●国土地理院の地図の複製承認をもらう
以前は手続きが恐ろしく難解かつ面倒で敬遠されていたそうですが今はある程度
易しくなっているそうです。しかしながら相変わらずのお役所処理なので
そこらへんのことはしっかり理解して挑まないといけませんでした。

ねむいさんの場合、ブログ上でカシミール3Dで地理院地図を表示しさらに
GPSデータと高度データを追加で記載した画像、具体例をあげるとこんな画像を
ブログ記事上にて表示するための許可が必要ですが、これが法第２９条
「測量成果の複製承認申請」に相当します。

兎にも角にもこの"複製"が大前提です。では実際の手続きに入ります。

現在ではワンストップサービスなるもので申請が可能です。

このサイトの申請ボタンを押してスタート！…の前にユーザーを登録しなければ
なりません。なぜか先に進めてしまうのですが申請段階でログインしてないと
エラーではじかれてしまいます######

右上のログイン画面へのところで新規登録ができるので先に必ずしておき、
ログインも済ませておきましょう。

申請に関しては「基本測量の測量成果」を選択し、次への矢印をクリックします

すると目的を聞かれますので「地図の作成」を選択て次へ。

最初で述べた「複製」を行いますのでここは「紙地図・空中写真をスキャン（コピー）
し、あるいはラスタデータ型の数値地図（地図画像など）をコピーして基図とする」
を選択してください。

複製目的は「インターネット等により情報を提供する」を選択。

ここから複雑になります。ねむいさんの使い方では上記のようにする必要がありました。

そして使用する地図ではカシミール3D上では電子地形図(タイル)を表示します。
電子地形図(タイル)チェックを入れさらにツリー下のすべてにチェックを
入れてください。

｢複製する測量成果の交付年月日又は地図の発行年次｣は｢すべて最新版｣、
｢複製の範囲又は区域｣についてはねむいさんは日本全国を股にかけるので｢日本全国｣、
｢複製の期間｣は｢一年間(※これを選ぶと承認日より一年分の包括申請となります)｣、
｢複製品の利用方法｣は｢Webサイト等での公開｣、
｢有償無償の別｣はもちろん｢無償｣、
｢複製品の部数｣に関してはねむいさんはDropboxにファイルを置くので、
｢サーバー｣にチェックし、｢1部｣と記入します。

残りの項目は個人なら｢不備があった時の対応者｣以外は空欄で。
備考欄に｢確認のやり取りはメールでお願いします｣とすると電話連絡ではなく
メールのみで迅速に済ませられることができます。

これで申請ボタンを押して申請開始です。早ければ1週間ほどで承認番号を
付与したPDFファイルが登録したメールアドレスに送信されるでしょう。
PDFに記載された指示に従って作成した｢成果物｣を速やかに返信してください。
webサイトの場合はその画像が
あるURLを指定してください。
また、ねむいさんのようにやらかしてしまった人もかなり多く居るらしく、
その場合は速やかに指示に則ったフォーマットで画像を作成し差し替えるべし
と指導を受けました。

また、審査状況は申請処理を行った後に現れる審査状況タブからも参照できます。

そんなわけでねむいさんも国土地理院の地図を堂々と使用することができるように
なりましためでたしめでたし♥あとカシミール3Dから地理院地図を表示しているので
ちゃんと"Powered by Kashmir3D"と使用ソフト表記も追加しております。

●GCC ARM Embedded in Launchpadがアップデート
このぶろぐではデフォルトとなったLaunchpadのARM-GCCが予定よりちょっと早めに
バージョンアップしておりました。前回の更新は従来のGCC4.8.4からCortex-M7が
追加されただけだったのですが、今回はGCC4.9.3に上がっています。去年と同じく
いつものを使ってさっそくlibjpegとlibpngのデコード速度の性能比較をしてみました！



libjpeg/libpng rendering speed compare

uses inai-san's oketsu-pantsu gazou.

PNG  : INA~1.png 96128kByte

JPEG : INA~1.jpg 40491kByte



LAUNCHPAD

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20141119 (release) [ARM/embedded-4_9-branch revision 218278]

 @1201_7z SDIO_NSMODE_LIBPNG1.6.15

(Using newlib) -Ofast -mfloat-abi=hard  -mfpu=fpv4-sp-d16

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 492036	      0	 492036	  78204	main.hex

***libjpeg

174817uSec

***libpng

157300uSec



LAUNCHPAD

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.4 20140725 (release) [ARM/embedded-4_8-branch revision 213147]

 @1201_7z SDIO_NSMODE_LIBPNG1.6.15

(Using newlib) -Ofast -mfloat-abi=hard  -mfpu=fpv4-sp-d16

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 491948	      0	 491948	  781ac	main.hex

***libjpeg

181474uSec

***libpng

167060uSec

…イケてるじゃないですか(セルピコ顔で)

バイナリサイズは若干増加しましたがそれが気にならないくらいパフォーマンスが
上ってます！GCC4.8.4のSDIOのハイスピードモードでも勝つくらいの速さです。
これはすごいです。

…と言いたいところですが！

なんと最適化が効きすぎてメモリマップドI/Oのアクセスがごっそり削除されてしまう
ケースが存在しましたorzこちらのディスカッションでも話題に上がっていますが、
プリプロセッサを経由したちょっとトリッキーなアクセスになる場合、すべて
固定値として処理されてしまいますorz

身近な例ではSTM32F1系の旧USBライブラリ(STM32_USB-FS-Device_Driver)が
過剰な最適化の影響を受けます。ここでUSBのレジスタの読み書きの部分が
GCC4.9.3系でごっそり削除してくれやがるため、USB機能が一切機能しなく
なってしまいますorz
たぶん新しいCube系ライブラリではマクロを多用した抽象化が極めて激しい
ためもっとヤバい事態になると思います。まぁそっちは使わないからどうでも
いいですけど回避策として"usb_regs.c"の全体を-O0オプションでコンパイル
するようにpragmaをぶち込んで事を収めました。

現在F1系のUSB機能使っている作例で公開しているのは
STM32Primer2 GPS/GNSS Tracker
のみなので、旧F1系USBライブラリをご使用の方はそちらを参考にしてください。
ついでなので関数ポインタの怪しい部分も明示的にvolatile化しています。

●年末恒例ねむいさんFAQ
ねむいさんのぶろぐを運営するうえでメールやコメント欄(業者対策で全く機能
しなくなってしまいましたが)、はたまた私が虹裏メイドとしてまっとうに本業を
こなしてる時のスレ上において、そして副業時などで頂いたさまざまな
とんちんかんなご質問に対してわたしがとんちんかんに返答させていただきます…

Q:いままで問題なく動いてたのに急に(ry
Q:OpenOCDが動きません。
A:私もOpenOCDがうまく動かないので困ってググってみたのですがこいつのサイト
　ばっかりヒットして非常に鬱陶しいです。なんとかしてくだち。

Q:(捨てメアドで)私は(日本語風の意味不明の文字列なので途中は割愛)
　したがってあなたは開発者なのだから使い方をわかりやすくまとめる義務がある。
A:ここを100000000回声に出して読んでください。
　なんですぐれたシステムとやらを納入してる実績をお持ちの割にはOpenOCDの使い方
　すら理解しようと努力せず丸投げしてくるのか理解に苦しみますがそもそもOpenOCD
　を業務で使用するほうが大間違いですがそれをやんわりたしなめたとたんに
　仕事じゃなくて趣味の遊びですからとか言って逃げるのマジやめてくだち！

Q:ねむいさんのぶろぐをtwitterで薦めたらいきなりブロックされてしまいました(ﾆﾔﾆﾔ)
A:私のぶろぐを他者を攻撃する武器として使うのマジやめて。
　ルネサス系のマイコン、とりわけ旧日立系の産廃H8,SHをﾄﾞﾔ顔で使ってたくせに
　今更
　STM32にﾄﾞﾔ顔で乗り換えてきたようなﾊﾅｸｿみたいな周回遅れの意識他界系な方々の
　プライド最安値を刺激するのかほんとにヒット率高いです…でもそんなねむいさんも
　職業訓練のマイコン演習の際に生まれて初めて触れたマイコンはH8とイエローソフト
　のCコンパイラで、孫にあげるのはもちろんSTM32。
　なぜなら彼もまた、特別な存在だからです。

Q:ねむいさんルネサスのこと嫌ってるくせにルネサスのデジトラ愛用してますよね？
　い　い　え
　唯一使用していたFB1A4MはROHMのDTD123YKT146に置き換えました。そもそも
　NEC時代のFB1A4Mなのでﾉｰｶﾝですよぅﾉｰｶﾝうふふふ。
　これは独り言ですがルネサスの半導体のうち置き換えがきくディスクリートデバイス
　は早急に他社のものに置き換えたほうがいいです。旧NECエレの営業さんもROHM製品
　を進めてましたしねむいさんの好き嫌いの話ではなく突然使えなくなる事態が迫って
　いるので今からでも遅くはないですから急げ１！！！！！
　さて問題は置き換えが効かないV850とかのCPUですが、こちらも徐々にARMに変えて
　いこうと上司や社長に働きかけてます。すでにASICの代替でpsoc5採用になりましたし。
　正確に言うとルネサスが嫌いなのではなくルネサスの中にいる旧日立系の残党が大大大嫌いなのです。

Q:(回路図・コード・てにをは)が間違ってます。
A:すみません教えていただいてありがとうございます。直しました。

Q:何故がた老さんにあなた作の描画ライブラリのバグだしをさせているのですか？
A:ごめんなさいごめんなさい！！！！
　ちゃんとこちらでバグの箇所を見つけ修正しました。がた老さんいつもすみません。

Q:こんなバカな質問投げたのどう見てもあんたでしょ
Q:去年は年上にモーションかけてたくせに今年は年下かよ！
A:それわたしじゃありません！でも微妙に歳ごまかしてるように見えて他人のはず
　なのになんか自分のことみたいですごいヤですね…副業先でも話題になってしまった。
　突っ込みどころが多すぎて言葉に困りますがねむいさん
　じゅうよんさいからそっちの33歳の厄年なねむいさんに一言だけアドバイス
　送りますよぅ♨

　自分のことばっか話すな。ちゃんと人の話を聞け###

Q:FETが焼けました。
A:焼いたFETの数だけ強くなれるはずです。
　わざと焼くと逆に弱くなります。

Q:(ハルロックの)ハルちゃんいいよね…
A:いい…
Q:そっちじゃないだろ
A:ハルちゃんいいよね…
Q:ケモナー↓キ↑モいんだよ(C.V.置鮎)
A:気づかれたくなかったのでな…(C.V.麦人)
A:マジレスすると表紙に気合入りすぎて表紙詐欺の同人真っ先に思い出しｔウソウソ
　ハルちゃん可愛いよ。マンガ読んだことないけど。
　

Q:↑をぶろぐに乗っけるといろんな意味でヤバいんじゃないの
A:線画だけだととびぃぶろくんにバレなくてセーフなのに気付きました。
　たぶん肌色が見えたらアウトですね～。
　来年は虹メらしく手描きを強化していこうと思います
　↑後で知ったのですが作中でSTM32F4を使う描写があったそうで、
　　ハルちゃんはSTM32を知っていることになり、この手描きは的外れでした。

Q:ねむいさんのぶろぐが会社/学校から閲覧禁止にされてしまいました。
A:~~おそらくあなたの上司のケモホモ嫌いが原因ではないかと~~
　至極まっとうな会社や学校だと思います。
　ねむいさんの副業先でも閲覧禁止されて自分のぶろぐ休み時間ですら見れませんから
　おあいこですよHAHA!
　…ｳｳｯ!

Q:ねむいさんのスレにたまに現れなぞの呪文を唱えるこれは何ですか？
A:そんなのこっちがききたいです…"｢｣はお前を監視している"ということでしょうか…
　それはさておきKOUSHIROUさん主演のNHKのドラマがひどすぎて腹筋の筋肉痛が
　いまだに直りません…

Q:｢ねむいさん｣って名前の人ってBL好きな人がやたら多いのですが貴女も…？
A:twitterで一押ししてた方のマンガ買って読んでみたんですけど単なる"やおい"に
　ならず結構読ませる内容でしたよ…新たな世界が見えた…
　ってわけでわたくし虹裏メイドねむいさんは朝田ねむいさんを応援しています♥
　ねむいさんつながりですし♥

さて、そろそろ年越しそば作る時間になったのでこの辺で勘弁してあげましょう…
2014年も最後までドタバタ続きでまったく年が納まっていない感じですが
それでは皆様、よいお年を～Zzz…

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

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

すみませんいきなり自爆しそうになりましたが時代の趨勢は大解像度化の
一途を辿っております。電子工作で使用される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のいつものです。
すでにソースコードに反映していますのでこれらのモジュールを手に入れて
いても攻めあぐねている方の参考になるかと思います。
今後も良い物が入手できたらラインナップにどんどん加えていくつもりです。

2.5元だったはずがいつの間にか5元に値上げしたかと思ったらさらに8元になり仕舞に日本で300円で売られているi2c液晶を動かす

約2年前、ねむいさんはtaobaoでピン配置以外詳細不明のi2c液晶を超破格値の
2.5元で購入しておりました。その後なぜか急に8元に値上げしやがっておりましたが
私は破格かつ超円高だったのを活用して30個くらいガメて以来殆ど動作させず
そのままで放置。

が、

2014年の春、aitendoさんもこの液晶に漸く目をつけたようで一つ当たり
300円で販売しています。~~さすが大陸店、阿漕っスね~~
このまま腐らせるのもなんなので誰かがこれを使って面白い物を作ってもらえる
ようにとの願いを込めて込めて私の当時の解析結果を公開したいと思います。

●これはなんだ

これは今となってはごく一般的なドットマトリクス形式のモノクロ液晶です。
インターフェースはI2Cのみとなっています。
プラ製の外枠はLEDをつけるくぼみのような意味深なものも見受けられますが
あまり気にしてません。

●だからこれはなんだ

なんなんでしょうねこれ…粘着テープ等でべったりつけられてるわけではないので
簡単に取り去ることができます。中華液晶は謎が多いです。

●マイコンとどうつなげればいいのか？
データシートに提示されているのはピン配置のみ…ほんっとこれだけです。
しかしその情報だけでも十分解析が可能です。

ここで閑話休題、I2Cというインターフェースについてですが…
ひとまず、I2Cの規格はNxPのサイトにPDFにて公開されていますのでしっかり確認し
ておきましょう。後述しますが最初はGPIOのエミュレーションの方が動作の把握が
しやすいかと思います。いずれの動作においてもオープンドレインで動作させるのは
変わらないため、SDA,SDLの各信号線にはプルアップ抵抗は絶対に必要です。

プルアップ抵抗算出式は　Rp(kohm)>(Vdd-0.4)/3(mA)　
なので一般的な+3.3V系では
Rp > (3.3-0.4)/3 = 0.967(kohm)となりますが、
100pFの容量で400kBps通信時の所要立ち上がり時間300nSecを考慮すると
Rp < 300(nSec)/100(pF) = 3(kohm)

計算上は0.967kohm~3kohmが適切な抵抗値なはずですが、1kohm付近では
ドライブ能力が低いF**KなI2C液晶だとACKがLowに引いてくれないことが
あるので結局実測(オシロスコープの波形)を元に安全値を求める羽目に
なります…めどい
BolyminのキャラクタI2C液晶を動かした際の実測は以下のようになりました。

(MAX400kbps通信時)
　　1kohm ×
　　1.5kohm ○
　　2.2kohm ○
　　2.7kohm ○
　　3.3kohm ○

というわけで400kBpsでI2Cデバイスを動作させる際はプルアップ抵抗は
2.7kohmが最も適しているかと思われます。

ですが速度的に潰しの効く100kbpsまで落とすなら4.7kohmで吊っとけば大抵は
問題はありません。…て言うわけで今回も4.7kohmで行きます。

先ずは液晶と意識せず一つのI2Cデバイスと思い込んでI2CのACKが返ってくる
アドレスをサーチしてやりましょう。ほとんどのデバイスは8bit変数で示される
範囲内なので捜索数も少なくそんな時間がかかりません。
で、ヒットしたアドレスは0111_101xと0111_100xでした。ヒットした
アドレスを元にいろいろググってみるとI2Cで64x96のドットマトリクスに
適合したドライバICはUC1602Sが最も近いのではないかと推測しました。
データシートを見るとデータとコマンドのレジスタが上記アドレスのとおり
二つに分かれており推測が正しかったと分かります。

ここで改めてこのI2C液晶、"GG0906186FWNNC"を動かしせしめるための
準備を行います。ドットマトリクス液晶に必須のバイアス電圧を作り出す
ための電圧ドライバもUC1602Sには入っているので後はデータシートを参考に
VLCD用のキャパシタを外付けしてやればおしまいです。
具体的には上記回路図の要領でVLCDに0.33uFぶら下げればよいです。

●動かす！

使用するマイコン/基板は今流行りのSTM32-Nucleoボードを使用します。
初めて動作させる際は低速ですがデバッグがしやすいGPIOによるI2Cバスの
エミュレーション(ソフトI2C)が良いです。上でも注意しましたが制御は
すべてODです！あと裏ワザになりますが、STM32の場合はGPIOを出力に
設定をしていてもODで制御してREADの際はポートをHI(=疑似トライステート)
にしておけばターゲットデバイスから吐かれる信号レベルがわかりますので
入出力を切り替える手間が省けてオトクです★

…ていうかハードウエアI2C制御版のほうはF1/F4系と全く違ってて動かし方を見つけ
てる最中なので今しばらくお待ちください。
20230822追:
2023年現在はハードウエアI2Cでもバリバリ安定動作してます！！！！

UC1602Sのイニシャライズのための呪文もねむいさんが既に調査済ですので
ご安心ください。ご覧の通りに無事表示が出来ました。
TFT-LCDで使用したFONTX2ドライバを使用しております。

これだけでは使いどころが分かりづらいので同じI2C接続デジタル温度計STTS751を
つなげて簡易の温度計をｻｸっと作成してみました。

特に危なげなく温度を表示することが出来ました♥
やっけつ配線ですがこういう出来合いボードは本当に便利ですね～

今回のF0版Nucleo向けのソースコードはおきぱに置いておきます。圧縮ファイル内
のlibフォルダにxMSTNというフォルダがあり、ドットマトリクス液晶の制御のための
コードが集中しています。
今回制御したUC1602SはxMSTN/driversフォルダにuc1602.cとして抽象化して
ありますので別のマイコンやmbedに移植される方はご参考に。移植は容易に
できるはずです。

デフォルトではSTTS751の制御はIF文で切っていますのでSTTS751を
お持ちでない方もaitendoさんから購入したi2c液晶単体でも動作確認が
可能です。この液晶は動作電流がかなり小さく、低消費電力な工作にも
かなり使えるアイテムとなるでしょう。

I2Cネタは書きたいことが沢山有りすぎてまとまりがつかない状態です。
特に怪しい中華製I2Cキャラクタ液晶の電源投入時の変な動作とか回避の
ためのバスリカバリとかキリがないです。ですが今回みたいなひょんなことを
チャンスにして公開していきたいと思います。

いろいろ試す20…という名の今年の反省会

今年もいろいろありましたが私としてはやってることはほとんど変わらず
山走りとかに行ったりLチカを極めるべく研究したりOpenOCDのエンバグ
とかです。

特にステップアップらしき事をしたのは今まで利用だけしていたOpenOCDの
プロジェクトに対してパッチを提出する形で能動的に参加したことでしょうか。
言葉の壁はもちろんありますが何度もこなしていくうちにある程度分かって
きますので皆様もオワコンとか言わずにどんどん参加してほしいと思います。

●マイコン向けの最強最後のTFT-LCDをゲッツか

i8080バスで接続できるもので現時点でほぼ最強かと思われるモジュールを手に入れ
ました。320x480(HVGA)・ILI9486L・超広野角・3.8inch・抵抗膜式タッチパネル
付と至れり尽くせりでSTM32F4系のFSMCで接続するには最適です。
これ以上のピクセルサイズになるとRGBやMIPI-DSIのほうが速度的に有利になるので
やはり"マイコン"で使用するのなら320x480が上限と感じます。

以前の主力だった3.45inchの奴(コントローラIC:R61581/B0)と比較してみました。
一回り大きいのがわかると思います。

●GCC ARM Embedded in Launchpadがアップデート
読んで字のごとくですがクリスマス前に合わせて更新というなかなかニクいアップ
デートです。今回からGCC4.8.x系になりました。また今回の目玉は新しいコンパイラ
オプションの"-mslow-flash-data"の追加です。これはどういうものかというとリテ
ラルロードを極力movtに変えてバスの競合を避けパフォーマンスのアップを図ると
いわれるものです。ARM本家のこちらとこちらもご参照のこと。

"-mslow-flash-data"のありなしで吐かれたアセンブラリストの比較をしました。
使用したプログラムはSTM32F4のいつものです。赤でハイライトしてる部分がその違い
ですがLDRで行っていたリテラルロードがmovtに置き換わってるのがわかります。
LDR命令の場合、最短3クロックサイクルかかりバスの競合があるとさらに5クロック
サイクル以上掛かることになります。movtに置き換えた場合はサイズは増加しますが
2クロックサイクル固定です。

次に実際のパフォーマンスを比較してみました。libjpegとlibpngのデコード速度の
実時間を計測して比較しました。表示に使ったのLCDはもちろん最初の項で紹介した
これです！
また表示に使用した画像は320x480サイズにしさらにpngとjpegに変換を行った
いないさんのおぱn…いないさんのｲﾗｽﾂをサンプルとして計測結果をuSec単位で
こんな感じで表示しｔ

…ｹﾞﾌﾝｹﾞﾌﾌﾝ
さて実際の結果ですが、せっかくなのでfreddiechopinさんとこのBleeding-Edgeツール
チェインや役立たずに堕ちたSourceryCodebenchも(←今回の比較のためにわざわざ
登録してインストールしためっちゃめんどくさいF**K!)交えコンパイラオプションも
いろいろ変えて各コンパイラ性能比較も兼ねて行いました。

↓とりあえず各条件の計測時間の羅列です
　(※-mfloat-abi=softの時はlibjpegのDCT_FLOATは無効にしていますのでバイナリ
　　　サイズが全般的に下がっております。)



libjpeg/libpng rendering speed compare

uses inai-san's oketsu-pantsu gazou.

PNG  : INA~1.png 96128kByte

JPEG : INA~1.jpg 40491kByte



LAUNCHPAD

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.3 20131129 (release) [ARM/embedded-4_8-branch revision 205641]



@@L1111

(Using newlib) -Ofast -mfloat-abi=hard  -mfpu=fpv4-sp-d16 -mslow-flash-data

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 496760	      0	 496760	  79478	main.hex

***libjpeg

182341uSec

***libpng

168305uSec



@@L2222

(Using newlib) -Ofast -mfloat-abi=hard  -mfpu=fpv4-sp-d16

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 489144	      0	 489144	  776b8	main.hex

***libjpeg

181903uSec

***libpng

168485uSec



@@L2222 (nano-lib)

(Using nanolib -u _printf_float) -Ofast-mfloat-abi=hard  -mfpu=fpv4-sp-d16

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 470620	      0	 470620	  72e5c	main.hex

***libjpeg

194318uSec

***libpng

234706uSec



@@L3333

(Using newlib) -Ofast -mfloat-abi=softfp  -mfpu=fpv4-sp-d16 -mslow-flash-data

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 496752	      0	 496752	  79470	main.hex

***libjpeg

182345uSec

***libpng

168311uSec



@@L4444

(Using newlib) -Ofast -mfloat-abi=softfp  -mfpu=fpv4-sp-d16

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 489136	      0	 489136	  776b0	main.hex

***libjpeg

181925uSec

***libpng

168588uSec



@@L5555

(Using newlib) -Ofast -mfloat-abi=soft -mslow-flash-data

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 496152	      0	 496152	  79218	main.hex

***libjpeg

186999uSec

***libpng

168740uSec



@@L6666

(Using newlib) -Ofast -mfloat-abi=soft

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 488592	      0	 488592	  77490	main.hex

***libjpeg

187095uSec

***libpng

168490uSec















BLEEDING-EDGE

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors / bleeding-edge-toolchain-130810) 4.7.4 20130613 (prerelease)



@@B1111

(Using newlib) -Ofast -mfloat-abi=hard  -mfpu=fpv4-sp-d16

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 555460	      0	 555460	  879c4	main.hex

***libjpeg

183801uSec

***libpng

170161uSec



@@B2222

(Using newlib) -Ofast -mfloat-abi=softfp  -mfpu=fpv4-sp-d16

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 555436	      0	 555436	  879ac	main.hex

***libjpeg

183797uSec

***libpng

170156uSec



@@B3333

(Using newlib) -Ofast -mfloat-abi=soft

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 553492	      0	 553492	  87214	main.hex

***libjpeg

187582uSec

***libpng

170098uSec













SOURCERY CODEBENCH

arm-none-eabi-gcc (Sourcery CodeBench Lite 2013.11-24) 4.8.1

@@S1111

(Using newlib) -Ofast -mfloat-abi=softfp  -mfpu=fpv4-sp-d16

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 504568	      0	 504568	  7b2f8	main.hex

***libjpeg

184072uSec

***libpng

203915uSec



@@L2222

(Using newlib) -Ofast -msoft-float

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 504040	      0	 504040	  879c4	main.hex

***libjpeg

186811uSec

***libpng

203920uSec

かなり条件が入り乱れているので要点をかいつまんで紹介しますと、
まず"-mslow-flash-data"有だと、無しのものより逆にlibjpegのデコード速度が若干
下がるといった結果になりました。libpngはちゃんと速くなったのですが…全体的に
スピードアップすると思っていたのでちょっと微妙な結果です。
おきぱにて公開してるいつものはつぶしが聞くように"-mslow-flash-data"オプションは
デフォルトではコメントアウトにしてます。
↑2014年が明けて一週間たったころにようやくlibpngとlibjpegの評価をあべこべに
　書いてたの気づきましたすみませんorzちゃんと修正しました。
　"-mslow-flash-data"オプションを付与するとlibjpegでは逆効果になってしまいます。

またLaunchpad特有のnewlibをシュリンクしたnano-libを使用した場合、全体的な
パフォーマンスが低下することが分かりました。libjpegもlibpngもmallocを使用
するので、そこにパフォーマンスの違いが現れていると思われます。
作成するアプリケーションの目的に応じて使い分けるのがよいでしょう。

次に各コンパイラ比較ですが同条件(-Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16)
の場合、LaunchpadのGCCがサイズの小ささ/速度ともにトップになりました。
さらにLaunchpadのは"-mfloat-abi=hard"も選択できる(Sourceryのはsoftしかない)
ので、もはやわざわざ登録してまでSourceryCodebenchを利用する意味が全くなく
なりました。
皆様も早急にLaunchpadに乗り換えられることをお勧めいたします。

すぐにだっ！

●よくいただく質問に対する回答とか
というわけで今年のぶろぐもこれでお開きですが、毎年恒例の尺が余ったので
メールや虹裏でいただいた変な質問にぶろぐ上で返信をさせていただきます。

Q:GDBで接続した瞬間に"Remote 'g' packet reply is too long"とい(ry
A:長き戦いよ、さらば！
　ていうかちゃんとぐぐりなさいよー！

Q:USB3.0でLibUSBが(ry
A:こちらをご覧ください。
　USB3.0のホストのほうもファームやドライバの最新化は必須ですよぅ！

Q:いままで問題なく動いてたのに急にOpenOC(ry
A:変なことやらかした人に限って口をそろえたように"問題なく動いていたのに急に
　何ちゃら"は何らかのシンクロニシティなのでしょうか…？？？

Q:(ブラジルポルトガル語と思われるFatFsに関する質問)
A:Sorry,I cannot understand your language,at least in English.

Q:(簡体字中国語と思われるSTM32(←中国で人気のマイコンだそうです)に関する
　　何らかの質問)
A:Sorry,I cannot understand your language,at least in English.

Q:(日本語と思われる文字列だが日本語としてまったく解読不能の何らかの質問)
A:Sorry,I cannot understand your language,at least in English.

Q:ねむいさんとか言うサイトみたけど役立つ情報が全くない上に何が
　言いたいのかよくわからないので
A:私もそう思う。
　特に今日の前半のとことか。意識他界方がこんなトコ来ちゃ駄目ですよ…

Q:OpenOCDのWindowsバイナリは配布されておらず
A:ここが見えないのですかここが！！

Q:(企業のメールアカウントで)***なのですが****を希望しますor早く修正してくだ
　さい。以上。(←回答納期をつけてくる場合も…#)
A:今年に入ってなぜか急にたくさんいただくようになりましたが……企業内で開発を
　行われる場合は有償のサポートが付いたツールを使用されるほうがいいと思います。
　もしくはgpl.txtを1000000000000回音読して"利用者が全責任を負う"っていうこと
　を体で理解してください。ちなみに私の副業先ではARMはIARで開発しております。

Q:ルネサA:帰れや！

Q:ギンギンに勃○してるのですが
A:ﾔﾀﾞﾓｳ///

Q:ギンギンに○起してるのですが
A:ﾔﾀﾞﾓｳ///
　これデザインしたの私と同性の方でしょうか…？
　本来のとは逆向きに付いてますし///

Q:ねむいさんで検索すると候補に入院と出てきます。これは何ですか？

A:これは重篤なサジェスト汚染ですね～！
　当職が入院したとかいう体だけ(非性的な意味で)が取り柄のねむいさんのあいでん
　てぃてぃを否定する検索が多数行われているのは絶対に許さ~~ないよ~~れません！！
　力を。

Q:ねむいさんのぶろぐに右端にあるブラウザベンチマークというリンクをクリック
　したら突然大量の画像が貼られるページにいどうして動作が重たくなり、ブラウザ
　がクラッシュしてしまいました！！！１！！ファ*クユー!!!
A:びぃぶろ君が悪いんですけぉ！１！！ねむいさんは悪くないんですけぉ！１！！１

Q:ねむいさんはさんざモロはあかんといっときながらブログでモロを進めていたのは
　どういうことなの？虹裏メイドだからって何か許された特別な人間だと思ってるの？
A:わかりましたから落ち着いてください。かつて存在した虹裏novという場所があった
　のですが話はそこにさかのぼります。そこでは魅力的ないやらしい口元をした紳士
　画像を赤と黄色を交互に放射状にした…いわばマケドニア国旗のような非常に目立
　ちやすい注目をひく画像に加工したものをスレッドの頭画像とし、おもに紳士に関
　する話題やコラージュを中心としたスレッドの進行体系をとっておりました。
　しかし、実写のコラージュを用いたスレッド信仰であったためふたば☆ちゃんねる
　のｸﾝﾆﾘﾝｻﾝにとって二次元裏のポリシーに反する目の上のタンコブだったのです。
　紳士画像のスレッドの住人はそれには構いなしにナイフみたいに尖っては触る者皆
　すべてに不許を貫いておりｸﾝﾆﾘﾝｻﾝに対する反逆とも呼べる行為を続けていました。
　そしてある日ついに、ついに虹裏novはｸﾝﾆの怒りによってなんと板ごと御取り潰し
　に遭うという悲劇的な結末を迎えました。しかし紳士画像のスレッド住人はそれで
　息絶えたわけではありません。住人達はもといたimg,may,jun,decにとしあきとして、
　｢｣として溶け込みつつもマジスタンスとして2014年になろうとする今現在も続く許
　されざるビューティフル・ウォーを繰り広げているのでございます。
　現在では、前途の紳士画像を二次元裏@ふたばに貼付するという行為はｸﾝﾆに対する
　反逆の証として児童ポルノ画像の貼り付けよりも重篤な一発アウト(スレッド削除・
　アクセス禁止措置)が取られるようになっております。safetyに紳士を語るためには
　紳士を構成する目元といやらしい口元を隠す黒塗りを施した"加工済紳士画像"の
　貼付けにて進行を行わざるを得ないのですがそういった処理前の未加工な紳士画像
　がモロ画像もしくは縮めてモロと呼ばれ、爆発性の危険物として扱われています。
　しかしながらそういったモロが貼られない状況が紳士スレッド内で続くと突然日清
　チキンラーメンのパッケージをはじめ鶏肉を主体とした調理済の料理画像が貼られ、
　あたかも"(モロを貼れない)お前はチキンだ！チキン野郎だ！"と言わんばかりの
　挑発を受けることになります。挙句の果てには手描きを用いチキンとかはたまた妙に
　ウイットに富んだ発音でティキンとかいうモロにストレートな心温まる発言を行ッ
　てくれやがります。ですがあなたたちは紳士です！そのような挑発には決して乗っ
　てはいけません！奴らはあなたの正義感を巧みに利用してモロを貼らせるように仕
　向けているだけです！！１！もし挑発に負けて大人の男怒らせるなよオメーラと言
　わんばかりに未加工の紳士画像を張り付けてしまったらゲーム・セットです。たち
　どころに大勢のアンパイアが現れつぎつぎにアウトの判定を下され、ポケットモン
　スターのアチャモにも｢あちゃ～…もろ」と吐き捨てられ、仲間であったはずのスレ
　ッド住人にdelを叩き込まれてとどめにｸﾝﾆﾘﾝｻﾝになーとアク禁を喰らうでしょう！

Q:東海自然歩道の静岡バイパイコースについて質問です。
　玉露の里にかかる橋のマークはなかなかイカス植物ですね？
A:し…しらない…
　気のせいでしょうﾊﾊ

Q:東海自然歩道の静岡バイパイコースについて質問です。
　休暇村富士の玄関で栽培されてる葉っぱはなかなかイカス植物ですね？
A:し…しらない…
　き、気のせいでしょうﾊﾊ

…
ー…そろそろ大掃除しますか…

それではみなさま、よいお年を～

いろいろ試す19

あっという間に(仕事上の)夏が終わってしまいました･･･日記上は更新
してないので夏ばてしてた様に見えるでしょうけどもじつは更なる跳躍の
ために私なりにいろいろやっていたのですよぅ！
とくに東海自然歩道関連もトレーニングを重ねて猛暑の中で難所をクリア
してきたのでこちらも近いうちにじっくりと･･･

●夏休みの工作☆LPC4088

さて、円高の頃に買い込んでいた基板やチップの中で最後の大物で
残っていたLPC4088に着手をはぢめました。

基板はLPC1788ですがLPC4088はほぼピンコンパチなのでそのまま乗っけ
られます。生基板なので仕事や家事終わったあとに大量の部品をちまちま
ちまちま付け続けお盆休み明けにようやくFatFsまで動作を確認しました。

LPC1788のときと同様に大容量のSDRAM乗っけてます。STM32系と違って
heapやstackとしてがんがん使ってもコケないのがすばらしい！
(STM32F1系のFSMCはerrataとしてFSMC上のSRAMをheapやstackに使うな
ととうとう明記されてしまいました!!!11!!F***K!!!!)

LPC4088はLPC1788には存在しないSPIFIインターフェースを持ちます。
しかし･･･
困ったことにLPC1788系と互換性を保った結果LPC4300系と違いSSPポートの
互換性がなくOpenOCDから書けないことが判明orzOpenOCDはSPIFIではなく
ポート互換のSSPで書いてたんですよね～
･･･ドライバの対応はnuvotonドライバの時よりしんどそうだったので
早々にあきらめ外付けのコネクタを設けてFlashROMを使って書き込みする
作戦に変更しました。SPIFIは容量を喰うFONTXファイルの置き場に
使用していきます。

あと付けてないのはLCDインターフェースですがこれは私がいつも使ってる
MCUバスではなくRGBでつなげるタイプのものを必要とするのでそれに合う
液晶の調達から手を付ける予定です。

●Kinetis K20/K10シリーズを触る
わざわざ独立の記事にするほどでもない超小ネタなのでここでさらっと
紹介します。少し前にFRDM-K20なるボードが販売されましたがこの
シリーズの一番小規模のチップであるMK20DX32VLF5とMK10DX32VLF5を
ちょっと触りました。写真はK10のほうです。

K20はUSBと内蔵3.3Vレギュレータが付いてて本当にこれひとつで完結した
基板も作れます。実際に安価に製作されている方もいるようです。

ねむいさんがこれを単品で購入した理由はOpenOCDの書き込み/デバッグ
確認のためだけに過ぎません･･･
が、このチップ特有の機能にちょっとはまってしまいました。

以前、私はKL25やKL05を触りOpenOCDへの書き込み/デバッグを可能にして
きましたが、K10/K20もコアがCortex-M4(F無し)違いでKLシリーズと同じ
ように楽勝だろうと高をくくってました。しかしPOR後のウォッチドッグ
タイマの挙動が違っていてブート直後に即効ウォッチドッグの機能を殺しに
いかないとせっかく書き込んだのにセキュリティ状態に突入してしまい、
mass-eraseして解除してからGDBからイメージをもう一回ロードしないと
デバッグできない事態になることが判明!

工場出荷時はセキュリティ状態は解除されてるらしいですがこのウォッチ
ドッグリセットのせいで実質セキュリティ状態になってる為STLink/V2などの
MDM-APを直接叩くことが不可能なデバッガハードウエアでは手詰まりに
なってしまいます･･･ぬぎゃー
(これFRDM-K20が国内販売されたらまたねむいさんのとこにプログラムが
書けなくなったって質問飛んでくるんだろうなぁ････)

●EFM32シリーズもおさわり
同じくOpenOCDの書き込み確認のために単品購入したチップです。
EnergyMicroというメーカのチップでしたが現在はSiliconLabs社に吸収されています。

Gecko(ヤモリ)のマークがチップ上に付けられたイカすデザインでCortex系の
マイコンでは超低消費電力方面に力を込めたラインナップとなっています。

ねむいさんがチラッと触った限りではCMSISライブラリがSTM32ばりに充実
していてCMSISにどっぷりつかったねむいさんの流儀に非常に組み込みやすく
最初の取っ掛かりのLチカ作成が最速の30分で完成しました(逆に一番難儀
したのはあちこちにファイルが点在してて把握しづらく挙句の果てにKeilの
サンプル中にしかCMSISヘッダファイルが無い品種もあるKinetis･･･
てか公式のサイトでリンク切れはまずいですよぅ)。

書き込みデバッグももちろんすんなり完了ですごい相性よかったので
メインのSTM32からちょっと浮気しちゃいそうです･･うそですよぅうふふふ

というわけでOpenOCDのバイナリには上記3品種の書き込みcfgファイルを
追加してます。パッチも前回から不備が見つかったものをさらに改修して
ますので私と同じ環境をお持ちの方は試してみてくださいね～

･･･すっかりOpenOCDありきのマイコンいじりになってしまいましたが、
実務ではルネさｓ

(日記はここで途切れている)

いろいろ試す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コア…
トリプルコアなの！？

次回に続く！！

Amontec夜逃げ記念☆JTAGKey2互換回路をもっと使ってみる2

20150514追:
2015年現在、JTAGKey2CompatibleのRev.5まで
上がっています。自作される場合はこちらを参考にしてください。
20150514追:

数年前、FT2232Hを利用したJTAGkey2Cloneの紹介をしました。しかしちょっと自分で
も回路上で疑問を感じる点が多く、かねてから再製作の構想は考えておりました。
昨今のロジックICの性能向上も相まって2013年の今、再び満を持しての再製作となり
ました…最初に書いたのもう3年前か…もう3年も経ったの…さんねんも……

ｹﾞﾌﾝ失礼、前回は単に回路図と実に抽象的な使用例を紹介しただけでしたが今回は
どうしてそういう部品選定or回路に至ったかのねむいさん的ポリシーも述べます!

●肝心な回路図は…
実は少し前から公開していたのですが…以下のリンク先"JTAGKey2"のディレクトリ内
にあるpdfファイルが新しいJTAGKey2互換回路の回路図となります。
FT2232Dを使ったJTAGKey無印の互換回路も2009年当初のままですが下記リンク先の
"JTAGKey"のディレクトリに収録していますので同じくご参考までに。
JTAGKey or JTAGKey2Compatible Circuits

神木さんのJTAGKey2互換を参考にして作ったねむいさんのJTAGKey2互換を参考に
して作ったjujurouさんのJTAGKey2互換を参考にした最終形です！

そして以前使用していた"Clone"という単語は以下の理由でそぐわないのでもう使わ
ないようにしました。これからは"互換(Compatible)"で統一といたします。

●オリジナルのJTAGKey2との差異
夜逃げしたAmontecから販売されていたJTAGKey2純正品とは機能面で差異があります。

1．暗号化EEPROM(DS2432)の有無
　これはオリジナルではFT2232のB側のバスのどれかに接続され、Amontec社が
　提供しているamthal.dllはここから書き込まれた情報を読み出し正規品判定を
　行っています。
　digilentの"JTAG HS-1"もそれと似た仕組みで判定を行っているようです。

2. LEDインジケーターの設定
　ねむいさんのJTAGKey2CompatibleのLEDの設定はJTAGKey無印をベースに
　しています。JTAGKey2で変更になったLED表示とは全く合っていません。

3. Lattice-ISPVMの使用可否(OE強制制御)
　Lattice"さん"提供のISPVMは数年前にFT2232系デバイスからでも書き込みが
　できるように神対応をして下さいました！！しかし純正のJTAGKey2からはOEの
　手動コントロールが不可能(MPSSEを強制直結状態にできない)のため蓋を
　こじ開けてジャンパを飛ばさない限り使用不可能です。

OpenOCDやUrJTAG等のフリーなツールでは純正/互換品に関わらず同じ"JTAGKEY"
として扱われるのでまったく問題なく使用が可能です♥

●回路解説
いくつかのブロックに分けて主要部の解説をします。

　1.FT2232H周辺
　　JTAGKey2互換初号機と同じくDLPDesignのDLP-USB1232Hを使用しています。
　　面倒なUSB-HS周辺やFT2232系で必須なEEPROM等の周辺部品を搭載し
　　モジュール化されており非常に簡単に扱うことができます。
　　今だとUM-232H等のFT232Hを使ったモジュールなども使用可能と思われます。
　　ただTx/RxバッファがFT2232Hよりも少なく処理速度に影響しますので、
　　その点はご留意ください。

　2.電圧変換(電圧レベルトランスレータ&バッファ)
　　JTAGKey2互換回路の心臓部です。ここで+1.4V～+5.5Vまでの幅広いターゲット
　　電圧に対応します。前回は+1.65Vからでしたが昨今のロジックICの性能向上に
　　伴いサポートされる電圧範囲の保証される下限がさらに下がりました。
　　それ故に型番どころか製造メーカ指定まで必須となります。ねむいさんの
　　ぶろぐ見てる人は同じ74シリーズの同型番でも製造メーカー間で性能が
　　微妙に違うという昔からよく知られている事実は常識中の常識のはずなので
　　理解していただけるかと思います。
　　DIODES Inc. Semiconductor の74LVCE1G125"、
　　Nexperia(旧NxP)の"74LVC2T45DC"を指定して使ってください。
　　他メーカーの同型番は駄目です！

　　また、各バッファICに繋がりFT2232Hから制御されるOEの制御線は必ず+5V
　　(回路図中ではVbus)で攣ってください。JTAGKey2をPCと接続したときの
　　これらは入力/Lo出力の疑似的なOD扱いで制御するPC側アプリが多く、
　　+5V系で攣っていないと+2.5V付近の中間電圧が掛かってしまい動作不良の
　　原因を作ってしまいます。

　　jujurouさんが指摘していた+5V系の動作の考察についてはさらに掘り下げて
　　別枠で考察させていただきます。

　3.ターゲット電圧検知
　　こちらに関してはJTAGKey互換のころと同じく元NEC現ルネサス製のデジトラを
　　使用しています(ねむいさん的定番部品です)。
　　↑Rev.4でルネサスを排除しました。使い勝手良かったのですが…さらばFB1A4M。
　　　代替としてROHMのデジトラDTD123YKT146を指定しております。
　　↑Rev.5に回路が変わりました！

　4.OE強制制御
　　切り替えスイッチで無理やりバッファのOEをGNDに落としてMPSSEで使用される
　　ポートをターゲットと常に直結状態にします。これは上述のとおりLatticeのISPVM
　　やデバッグ用途で活躍します。3Pの少信号用SWならなんでも使用可能です。

●実際に組んでみよう

今回は~~アイテムラボさんのパワーメッシュユニバーサル基板~~を採用しました。
本来ならVCCに使うべきレーンもすべてGNDに割り当て高速信号の扱いを意識して
配線を行いました…行ったつもりです！！

前回はFT2232Hのモジュール上部が吹きさらしで打撃を喰らいやすい危険な
構造でした。今回からアクリル板を加工して屋根を設けました。
いい感じですね♥

10MHz越えの高速信号を外に引き出すので信号線とGNDが交互に来るフラットケーブル
は必須です。さらに~~SEIWA製コの字型フェライトコア~~を設けて外来/輻射ノイズを殺す
ようにしています。

もともとチップバリスタも基板上に実装するつもりでしたがフェライトコアだけで
100V/1uSecのインパルスノイズ耐量試験を余裕でpassしてしまったのでチップ
バリスタは未実装のオプション扱いにしました。

一からJTAGKey2Compatibleを作る場合は初めにPCと接続したときにVID/PIDが
FTDIの素のFT2232Hとして認識されます。FT2232Hモジュール上のEEPROMに
データを書き込むために先ずはFTDIのドライバを認識させてください。
JTAGKey/JTAGkey2製作用に特別にinfに書き加えたものを用意しましたので
必ずこちらを使用してドライバを読み込ませてください。
2じゃない方のJTAGKeyを作りたい方もこのドライバを使用可能です。

JTAGKey2Compatibleとして動かすためにはEEPROMのデータを書き込んで
化かさなければなりません。従来はMProgを使用してデータを書き込むように
していましたが、現在はFT_Progに統一されましたのでこちらを使用してEEPROMに
JTAGKey2になるためのデータ(xml)を書き込みます。
上のドライバにはJTAGKey/JTAGKey2用のxml
データもJTAGKey_XML.7zとして収録していますのでこれを使用し書き込みを行って
ください。FT_Progの使用法についてはFTDI公式のマニュアルを参照のこと。

書き込みが終わったらUSBケーブルPC一度抜いてさし直してください。成功したら今度
は"Amontec JTAGKey2"として認識されます。

その後はlibusb系を使いたい場合はおなじみZadigでインストールを、FTDIのドライバを
使いたい場合はそのままとしてください。

注:LibUSBKはドライバの入れ替え無しに0.1系と1.0系APIが同時使用可能な便利な
　　ドライバですがWindowsXP下ではあらかじめ0.1系のドライバをインストールし
　　ていないと動作が不安定になるようです。一度0.1系でインストールしすぐに
　　LibUSBKに戻せば問題なく使用可能です。この操作もZadigを使うと楽ちんです


製作したJTAGKey2の動作確認を簡単にしたい場合はOpenOCDよりもUrJTAG
が便利です。ターゲットデバイスに接続して"cable jtagkey"->"detect"の
たった二つのコマンドでJTAGチェインが見えればチェック完了となります。
さらにpodコマンドでSRST,TRSTを含めたJTAGの信号線単体の個別コントロールも
可能なのでトラブルシュートにも役立ちます♥

●ちょっとしたデザインレビュー
20150512追:
以下の検証はRev.4以前のモロが問題だった頃の回路の内容です。
Rev.5にてオリジナルJTAGKey2のサポート電圧範囲に忠実になりましたので
現在はモロで問題有りません。
20150512追:

さて、実際に信用に足るJTAG用デバッガとして使うためにはいくつかクリティカルな
条件を設け試験する必要があります。JTAGkey2互換回路では大きく分けで2つの考慮
すべき点があり、どちらも回路図中の電圧レベル変換ブロックに集中しています。

1.電圧入力レベルに関する点
FT2232HのI/Oの電圧はMAX30Mbpsの高速信号を扱うため+3.3V系のLVTTLと呼ばれる
電圧レベルで固定化されています。(FT2232D系だと3.3V～5Vで可変だったのですが)
これを考慮してかFT2232Hは+5VI/Oトレラントとなっており+5V系の入出力に対して
耐性を持っています。ですのでFT2232Hの+3.3V出力に10kohmで+5Vにプルアップ
する程度の衝突ならびくともしません
(この荒業は疑似的なOD制御の時に役に立ちます)。
また、SRST,TRST,JTAG各信号線のゲーティングをしているバッファICのOE端子は
FT2232H側が疑似的にOD出力の形で操作しているため、常に+5Vで吊るのが正しい
です。(FT2232H,74LVCE1G125,74LVC2T45のいずれも+5Vの入力トレラントを持つ)

本回路中で使用されている74LVC2T45DCは+1.2～+5.5V,74LVCE1G125は
+1.4～+5.5Vまでカバーしており、何れも+5V入力トレラントも保証しています。
つまり+1.4～+3.3Vまでの回路の場合は電圧入出力とも全く問題はありません。
しかしターゲットが+5V系のケースでは74LVCE1G125のHレベル入力下限(3.5V)を
満たしません。
こちらについてはjujurouさんの情報をもとに74AHCT541(※)を挟み、
LVTTLから+5VCMOSの電圧変換を行うことによって電圧レベルの問題は一旦は
解消としました……しかし…

(※…NxP製の物は74AHCT541と74VHCT541の特性は全く同じ)

2.信号の伝達遅延に関する点

74AHCT541を挟んだことによって同素子内部のゲートを通過する際の遅延が余分に
追加されることになりますが、最初に組んだときは204MHz動作のLPC4330と
TCK=15MHzで接続し、周囲温度も十分振って安定して書き込みデバッグできたので
問題なし！としていました。

ですが純正JTAGkey2がサポートしてるのが30Mbpsだったのを思い出し"本当に
30Mbpsで通信できるのか？"と感じ、購入後放置していた公証80MHzまで使用可能な
SPI-ROMSST25VF032B-80-4I-S2AFとFlashROMを使ってTCK=30MHzで読み出し
試験してみました。
が、リードしたデータがすべて1bitずれた状態となってしまい玉砕orz
…というわけで真面目に伝達遅延の影響について考察を開始しました。

ターゲット電圧3.3VでTCK=30MHzで通信した際に一クロックサイクルは33.33nSec
であり、FT2232HのTCKからでたクロックがターゲットのTCKに届き、それに準じて
ターゲットMISOからの出力とFT2232HのTDO(SI)に届くまでの時間の合計が
33.33nSecを超えてしまうとビットシフトした状態でデータが取り込まれアウトに
なってしまいます。

データシート記載の使用温度環境-40~+125度で動作させた場合(データシート上で
明記されてないものは一番条件が絞れてる温度範囲)のパラメータを抽出して計算
すると上図のように33.33nSecを余裕で超える遅延が発生することになり74AHCT541
を挟むと30Mbpsの通信が理論上ですら不可能なのが判明orz

74AHCT541を省くと7.0nSec分遅延がなくなるため30MHzでもビットシフトは
起こらない計算になり、実際に74AHCT541を省いたモロにするとSST25VF032Bと通信
(DeviceIDの取得,書き込み,ベリファイ)が問題なくできることを確認しましたorz
やはりモロでなければだめだったのですorz

それと配線の引き回しも非常に重要です。10cmを超えるような引き回しをすると
上記のモロでも駄目でした。また、FT2232Hモジュールからレベル変換ICを何も
挟まないガチの直結も試しましたが10cm以上を超えるとやっぱりだめです。
30Mbpsで安定して通信を行うためには高速クロックで動作する回路を意識しないと
いけませんね。

PicoScope3206AでTCKの波形取得してみましたが74AHCT541付きの波形は
見るからにちょっときつくなってますね…。

↑15MHzの時のSPI-ROMのTCK波形(74AHCT541付)

↑15MHzの時のSPI-ROMのTCK波形(モロ)

↑30MHzの時のSPI-ROMのTCK波形(74AHCT541付)

↑30MHzの時のSPI-ROMのTCK波形(モロ)

ここでちょっと疑問に思ったのですが市販のFT2232H系のJTAGハードウェアは
本当に30Mbpsで動かせられるのか？という点です。10MHz以下までTCK速度を
落とさないとOlimexのARM-USB-OCD-Hでは安定して書き込みできないという報告
もあり、もしかしてそれらはレベル変換にFT2232D系で使用されていた低速な
LV系バッファが使われ続けているのではないのかと訝しんでしまいます。
純正のJTAGKey2ではどうなんでしょ?？さすがにできるはずですが…???

3.モロへの誘い
で、ここで74AHCT541外したら3年前作ったのと全く同じじゃん！
とお思いの方が多い筈です。
それは引っ込みがつかなくなったねむいさん本人が一番強く感じています。

というわけで癪なのでモロで動かしたときに+5V系で本当に問題が
ないのかの実力検証を行いました。

使用MCU:
　->ATMEGA1284P
動作電圧:
　->+5.65V
　　(安定化電源にてAVRの推奨上限+5.5Vにさらに+0.15Vのマージンを加える)
試験環境温度:
　->-15度~+70度
　　(-15度はコールドスプレーでJTAGKey2互換回路基板上をくまなく冷却,
　　　+70度はドライヤーで同基板上をくまなく加熱)
試験内容:
　->試験環境温度下でATMEGA1284pにOpenOCDを試用しJTAGモード(TCK=10MHz)
　　で100kByte程のプログラムの書き込み動作を行いその動作中にJTAGの
　　通信エラーやフラッシュの書き損じが一切出ないことの確認。

　　JTAGモードにした理由はAVRの場合はコア電圧/クロックに関わらず10MHzの
　　高クロックでAVR内のOCDブロックとの通信が可能なためです。

結果:
　->全く問題なし。
　　現行のAVRドライバはread動作を行うとOpenOCDごと落ちるｽﾃｷ仕様なので上記
　　環境下でJTAGKey2をISP端子につなぎ変えたうえでAVRDUDEにてISPモードで
　　読み出しを行い、さらに読みだしたhexをOpenOCDでJTAGモードでフラッシュの
　　全領域消去->書き込み。
　　そこから再びAVRDUDEでISPモードで読み出しを行いhexファイルの完全一致の
　　確認をもって問題無しと判断しました。

てわけで電圧/温度/TCK速度とも一番厳しい状況を作り試しましたが全く問題は
ありませんでした！試験で使用したOpenOCDはatmega1284pのフラッシュ書き込みに
対応させた奴使ってます。ログは↓こんな感じです。

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

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

Open On-Chip Debugger 0.8.0-dev-00011-g70a2ffa-dirty (2013-05-11-14:47)

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: 10000 kHz

srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst

adapter_nsrst_delay: 100

verify Capture-IR is disabled

Info : max TCK change to: 30000 kHz

Info : clock speed 10000 kHz

Info : JTAG tap: avr.cpu tap/device found: 0x1970503f (mfg: 0x01f, part: 0x9705, ver: 0x1)

Info : JTAG tap: avr.cpu tap/device found: 0x1970503f (mfg: 0x01f, part: 0x9705, ver: 0x1)

auto erase enabled

Info : device id = 0x1970503f

Info : target device is atmega1284p

wrote 113408 bytes from file main.elf in 4.453210s (24.870 KiB/s)

Info : JTAG tap: avr.cpu tap/device found: 0x1970503f (mfg: 0x01f, part: 0x9705, ver: 0x1)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:05

同じくAVRDUDEはFT2232系MPSSEに正式対応した6.0RC1をビルドして使用
しております。JTAGKey2があれば難しい設定もワークアラウンドも必要なく
ARMもAVRも余裕で書き込みできるようになっていい時代となりました♥

+5V系でAHCTバッファ挟まなくても問題なかった理由は、74LVCE1G125のVthが
実際は中間電位の+2.5Vで切られていてそれさえ跨げばちゃんとレベルが遷移
できていたからと推測します。データシート上の規約におもいくそ違反して
ますが実力/マージン共に十分あることが確認でき自分が理解して使用する
範囲ならモロでも全く問題なしと判断しました。
(↑売り物の製品の設計の時はちゃんとデータシートに記載された
指示/定格をすべて守ったうえでみっっっちり動作テストを行うのが大前提です！)

もちろん保証の範囲外なので、他のメーカの同種型番のIC等では入力に
ヒステリシスが設けられて全く動かないかもしれません。真似して製作される
方は回路図中でねむいさんが指定したICを必ず選定してください。
｢違うメーカのレベル変換ICをどうしても使うんだーぃ！｣という方はご自身で
動作検証を念入りにした上で使用してください！！！！！！！
念入りというのは回数だけ無意味に重ねるだけではなく温度と電圧くらいは
最低限振れという意味です。ベストな環境だけで満足すると
後で絶対にしっぺ返しがきますから…。

ということで74AHCT541はオプション扱いにとどめ、TCK=15MHz以下でしか
使用しなくて電圧的に心配な人だけ付けてね！ていう風にして冒頭の回路図に
最終的に落ち着く運びとなりました。めでたしめでたし。

20150210追：
+5V系の時の74LVCE1G125の挙動をもう少しガン掘るトしてみました。

VCC=+5.5Vにして入力をわざとゆっくりと上げ下げした時に実際に何Ｖで
出力信号が遷移するかという実験をしました。

先ずは立ち上がり。2.5Vできっちり信号が変化しだしているのが分かり
ますね。2.5V以降の途中で波形が乱れている件は後で解説します。

お次は立下り。こちらも2.5Vで信号が変化しだしています。

本来ならばCMOSロジックの場合はVthはVCCの中点で本実験の+5V系上限値
+5.5Vの場合は2.75VになるはずですがLoレベル寄りの2.5Vとなっていました。
実際に使われる+5.0Vで換算すると74LVCE1G125の真のVthは2.27V付近となる
ことが容易に分かります。FT2232Hの+3.3V出力直結モロでもドライブ能力を
十分に強化して電圧降下を起こさなければVthをまたいで1V近くのマージンを確保
できるので電気的には全く問題がないことが分かります
(※FT2232HのI/Oドライブ能力を最弱の4mA設定にしても30MHzでぶん
回しても問題ありませんでした)。

そんな訳でホビー用途ならAHCTバッファ無しのモロで十分であるという結論と
させていただきます。逆に売り物にする場合は今回のロジックICに限らずデータ
シートに記載されている事項をすべて守った上で周囲環境条件を十分に振って
みっっっっちり
テストしまくって最終的にどういう仕様に落とし込むかを慎重に決めてください。
大切な事なので二度言いました。
｢ねむいさんのぶろぐに書いてある通りに作ったおれはしらん｣とかいう奴に
エンジニアの資格は無いです。

また両者の波形とも遷移直後に大きく出力波形が乱れていますがこれは入力
スルーレートの規約(5V時5ns/V)に違反しているからで、遅すぎる速度の入力に
よって発振が起こっています。上記の測定結果は入力をオープン(殆どのケースで
中間電位になる)にしていると出力が発振を起こして予期せぬ誤動作に繋がる
という重要な事柄も示しています。
CMOSの入力は吊るか落とすかどっちかはっきりと！

最後にスルーレート規約も守ったうえでVCC=5Vで3.3Vドライブした時の波形の
例を。VersaloonのSWCLK波形を入力にしています。
ご覧のとおり問題なく電圧の遷移が出来ていることが分かりますね。

2013.05.20 Monday

20:18

ネムイ・トリノミアス

MISC

comments(2)

-

いろいろ試す15…という名の今年の反省会

●LPC812Xpressoを試す

Cortex-M0+コアが搭載されたLPC800シリーズ。この評価基板ではLPC812が
使用されております。またLPC1114系にはないファンクションマルチプレクス
機能などがあり、柔軟なプログラミングが可能です(と言ってもSTM32の第二世代
以降はかなり柔軟なリマップが出来るので物珍しいことでもありませんが‥)

さて、裏返すと見てはならない物が視界に入ってしまいましたが気を
取り直して即分離してSWD接続のVersaloon+OpenOCDしてみました。
…しかし…

ぐは…だめだ２番目のセクタ以降が書けてない…
OpenOCDのソースコード中にあるlpc2000.cにLPC800系のドライバ追加
しましたがフラッシュメモリの構成がLPC1000系と全く違うのでやっけつじゃ
むりですね…年明けにでも本腰入れてOepnOCDのソース掘ってみますかー！

●aitendoさんのANUXを試す

ねむいさんもご多忙にももれず買ってしまった…
え？この前のあれはどうしたって？
通電しっぱなしで放っておいたらDCDCと思われる部分が死んだので捨てました‥

さぁ通電だ！
>ANUX基板の電源スイッチ（SW1）を3秒ほど押して、１秒ほど画面が表示されます。
だそうですが早速出ましたね★

おおっ！Androidが起動しました♥

…
無事起動を確認したので他の人柱の報告待ちと行きましょうか１！１！！
さぁ次です次！！

●STM32EvoPrimterのその後

↑こうなりましたorz
リチウム電池を通電状態でうっかり放置してしまったため
放電終止電圧を大幅に下回って液漏れを起こしてしまった模様ですorz
漏れ出た電解液が基板に浸出してビアや部品の足を浸蝕していましたorz

てわけでかろうじて生きていたLCDだけ回収して荼毘に付して次です次！！１

●よくいただく質問とか
去年と同じく尺が余ったのでメールやコメントよくいただく質問に対する回答を
していきたいと思います。

Q:GDBで接続した瞬間に"Remote 'g' packet reply is too long"とい(ry
A:あのさぁ…イワナかった？
　ねむいさんのOpenOCDのバイナリは上記の対策済みなのでこちらをお使いください。
　
　また、どこぞの与太者がビルドしたものなんて使いたくない！！
　なんて人は~~帰れよ~~こちらの方法を試してみるのもいいと思います。
　…でも面倒ですよねぇ…FPレジスタのサポートなんてまだまだ先ですし…
　諦めてねむいさんがビルドしたバイナリ使いましょうよ…
　ちゃんとNOD32とAVASTでウイルスチェックしてますから♥(←しつこい)

Q:いままで問題なく動いてたのに急にOpenOCDが繋がらなくなってフラッシュ
　書き込みができなくなった！！１！！なんとかしろ！！！！
A:分かりましたから落ち着いてください。たぶんJTAG(若しくはDAP)へのクロックが
　WFI命令等で供給を断たれてOpenOCDから繋がらなくなっただけです。
　現在のARMマイコンにはほぼ必ずシステムメモリからのブートローダが内蔵されてい
　ます。そちらから起動してメーカ提供のUARTブートローダ等でフラッシュを全消去
　して電源をOFF->ONしたら回復します。

Q:ねむいさんのステッピングモータドライバの回路図でFETのドレイン-ソース間に
　保護素子が付いていませんがほんとに設計の仕事してるんですか?
A:アバランシェ耐量でぐぐりなさい！１！！

Q:動力線の接点不良が心配なので丸端(丸型圧着端子)を圧着せずに半田つけで接続
　しました(^^)これで大丈夫！
A:やめれ！
Q:なんでですか?半田つけなら確実じゃないですか！
A:熱サイクルで半田の接合部が徐々に劣化してそこの部分で発熱し出すから駄！目！
Q:先生は信頼性の高い半田つけの方が‥
A:あの…学校の授業で圧接の仕組みとかハーネス設計とかもやるべきだと思いますよー
↑つうかこれマジでヤバいのでちゃんとかしめ工具で圧着しましょうね。

Q:AWG22だと300Vで8A流せますね。てことは24Vだともっと流せますね！
A:なわけないでしょ…300Vってのは絶縁耐圧でそのAWG22とやらは300V以下の
　どの電圧でも8A以下ですよぅ…てかUL番号何番の電線ですかそれ…

Q:ＸＸのシステムを設計してくださいorＸＸをしたいのですがプログラムを提示
　してください。以上。
A:ねむいさんかいないさんの可愛いｲﾗｽﾂと等価交換ですね…！(ﾆｰｻﾝ風に)
　えろすな奴だとサポートつきです♥

Q:twitterで参考になるサイトとして"ねむいさんのぶろぐ"をすすめたら
　相手にいきなりブロックされました…
A:ねむいさんは素のEclipseが存在しない世界に生きているので素のEclipseで攻撃
　されると反物質世界の住人のテレサさんのごとく爆発して死ぬ体です。Eclipseが
　好きな方から見ると仏敵に見える可能性があります。気を付けてください。
　とくにARMマイコン使い慣れている方ににコメントを行う際は言葉を選び注意を
　払いましょう。ちなみにEclipse使うと爆発して死ぬねむいさんですが、メーカ
　お仕着せなEclipseベースのIDE等はちゃんとチューンされているのでねむいさんは
　爆発しません…。

Q:虹裏メイドってなんですか？
A:お笑いの集団です。
Q:某同性愛者向けAVに登場する人物がねむいさんと言うことになっていますが？
A:ララバいさんはそんなこと言わない

…はぁはぁ…だいぶ疲れてきましたので今年はこのへんで勘弁しときますよぅ‥
それでは皆様、よいお年を～
Zzz…

2012.12.31 Monday

22:41

ネムイ・トリノミアス

MISC

comments(2)

-

いろいろ試す14

●余ったAT90USBKeyをPDI接続のXMEGAライタとして使う
AT90USBKeyは(元)主人の遺品の一つでしたが引き継いだ私がSTM32をはじめとした
32bitマイコンに完全移行した今、もう必要ないかと捨てるつもりでした。
しかしLUFAの成果物の一つにAVRISPmk2の実装があったことを今更知り、
XMEGA専用のフラッシュロムライタとして再生することにしました。

XMEGAにあるPDIインターフェースはCortex-M系のマイコンにあるSWDとよく似ていて
2線式で書き込み・デバッグを行うことができます。しかもXMEGAの場合はJTAG接続よ
りも書き込みスピードが速い(ATMEL曰く)のです！！

ATUSBKey上のAVRISPmk2の実装はPD2&PD3(PDIDATA),PD5(PDICLK)として引き出
されます。AT90USBKey上では上記図の様に配線します。またポートの出力バッファの
破損を防ぐためPDIDATA・PDICLKとも各自100～220ohmの抵抗を直列に付ける
べきです。本当は電圧トランスレータをかます必要がありますが、私は3.3V使い
しかするつもりがないのでこれで十分です。

PDIインターフェースはXmegaのReset信号を通信に使用します。外部リセット用の
メカニカルスイッチを実装している際にチャタリング防止のキャパシタを
ぶら下げてる場合は必ず外してください。

ドライバはおなじみのLibUSBを使い、書き込みはAVRDudeから行います。
メッセージはこんな感じです↓

> "C:¥Devz¥Coreutils¥bin¥make.exe" program avrdude -p atxmega128a1 -P usb -c avrisp2 -U flash:w:main.hex avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e974c avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file "main.hex" avrdude: input file main.hex auto detected as Intel Hex avrdude: writing flash (118286 bytes): Writing | ################################################## | 100% 9.27s avrdude: 118286 bytes of flash written avrdude: verifying flash memory against main.hex: avrdude: load data flash data from input file main.hex: avrdude: input file main.hex auto detected as Intel Hex avrdude: input file main.hex contains 118286 bytes avrdude: reading on-chip flash data: Reading | ################################################## | 100% 7.77s avrdude: verifying ... avrdude: 118286 bytes of flash verified avrdude done. Thank you. > Process Exit Code: 0 > Time Taken: 00:17

ついでなのでXMEGAのFatFs+TFTLCDの実装サンプルも新しくしました。
しかしこのXMEGA、A1シリーズの384kByte版や4bit-EBIの完全版とかがATMEL本家
からことごとく無かったことにされ、素直にARM使った方が良い昨今は存在意義が
ほんとにわかりません…まさに~~好き者~~物好きなあなたへ。
※もともと所持していた図体がでかいAVR-JTAGICEmk2は副業先に提供しました。

●ついでですがWinAVRからAVRToolchainに乗り換えるときの諸注意など
さすがにWinAVR使う人激減してますが、ねむいさんのようなコマンドラインビルド
主体の人がAVRToolchainに乗り換えるためのtipsを紹介します。

①PROGMEMの定義
　これもう海外ではavr-gcc4.7系が出てすぐにFAQと化した事柄ですがたまに質問
　もらいますので日本でも既に他の方々が言及してますが私もお伝えします。
　
　prog_****系の(prog_char)等の宣言が4.7系で廃止になったのでテーブル等の定数
　をフラッシュメモリ置くときは以下のように定義し直せばOKです。

　旧 :const prog_char unk[] ="inachang!";
　新 :const char unk PROGMEM[] = "inachang!";

　私が公開してるXMEGAのサンプルはすでに修正入れています。

②utilsが無い！
　AVRToolchainはAVRStudio6で使用するのが大前提なのでunixライクツールがあった
　utilsフォルダが存在しません。ですがAVR-GCCのバイナリがあるフォルダに同等の
　物が一緒にほぼ全部ぶち込まれてるので大抵は困りません。
　(sh.exeだけは無いです)
　シェル(sh.exe)に依存するmakeの書き方をしてるとエラーで止まるのでご注意
　ください。…LUFAっていまだWinAVR20101110が前提なんですよね…めどい…。
　因みに私が公開してるXMEGAのサンプルはもちろんこのビルド手順準拠です。
　ARM-GCCの代わりにAVRToolchainをGCCコンパイラとして指定するだけです♥

●デジカメ買い換えました

2010年の8月に購入後数日で比叡山の登山道の石の上におっとこして以来だましだまし
使用していたねむいさんのIXYDIGITAL220Fちゃんが湯の山温泉のバトルで力尽き
とうとう縦向きでしか撮影できなくなりE32エラーも連発するようになったので
最新のIXY3に買い換える運びとなりました…

2年たつと全然性能が違いますね…まぢて…マクロ撮影が1cmまでできるので
TFT-LCDのCOGの解析に役立つかもしれません！

●今まで普通に使えてたSDカードが急に書き込み禁止になったんですけぉ！！１！！
物がよくつぶれる(人も)ようになりました。ねむいさんが使ってるPCも上記の症状が
出るようになってしまいました…。SDカードは認識するがライトプロテクトが解除
出来ず書き込み禁止になるパターンはいくつかの原因が考えられます。

①SDカード本体のライトプロテクトキーがLOCKになっている
　->SDカードについているLOCKキーは物理的なものでSDカード内部と
　　電気的なつながりはありません。もしこれがLOCKの位置になってたら
　　ずらすと直ります。しかし大抵は…④に続く

②SDカードリーダ・ライタのドライバ側がライトプロテクト設定にしてある
　->ちょっとインテリジェンスなカードリーダ・ライタはたまにソフトウエアで
　　プロテクト設定可能な機能があります。違うカードリーダ・ライタだと普通に
　　読み書きができる手合いの奴ですね。マニュアルを見て解除してください。

③Windowsを使ってる場合限定でレジストリの設定でライトプロテクトにしている
->google先生に聞いてください…

④SDカードリーダ・ライトのソケットに問題があり、常にLOCK状態になっている
　->使い込んだリーダライタやノートPC付属の奴ではよくありがちです。
　　ではなんでこんなことになるのかを説明します。

SDカードの挿入検知(INS)とライトプロテクト(WP)検知はメカニカルスイッチで
行われ、カードリーダ側でその電圧レベルを読み取って状態を判断します。
INSとWPのポートは大抵は3.3Vでプルアップされています。

カード未挿入状態ではINSは解放されているので3.3Vになり、なおかつWPも上写真
ように解放されているので3.3Vとなり、ロジックレベルではどちらもHIになります。

このときSDカードのLOCKスイッチをLOCKにしないで挿入するとINSはSD
カードリーダ側のソケットと電気的に接触し信号レベルがGNDに落ちます。

同じくWPも挿入するとSDカード側のLOCKスイッチに物理的に押されてGNDに
落ちます。この状態ではカードリーダ側は読み書き可能と判断します。

一方SDカードのLOCKスイッチをLOCKの位置にスライドして挿入した場合、同じく
WPの接点とソケットのGNDが一時的に押されるわけですが深くまで挿すと位置的に
再び解放されてロジックレベルがHIに戻ります。
この状態ではカードリーダ側は書き込みのみ可能と判断します。

まとめると3つの状態があることがわかります。

・カード未挿入
　INS　:HI(3.3V)
　WP　 :HI(3.3v)
・カード挿入(LOCKの位置ではない)
　INS　:LOW(0V)
　WP　 :LOW(0v)
・カード挿入(LOCKの位置)
　INS　:LOW(0V)
　WP　 :HI(3.3v)

そしてWPの接点はINSよりも構造が脆弱で長期間使用で接点の弾性の劣化・酸化による
接触不良を非常に起こしやすく、ある日突然常にHIレベル(WP有効)と認識されるように
なってしまいライトプロテクト状態となってしまうわけです。

これについての対処方法ですが、つまりは接点を復活させればいいわけですが、USBの
カードリーダ使ってて起こった人は買い換えた方が手間暇も喰わず安上がりです。
しかしノートPC等で基板にソケットが備え付けられてるタイプの奴は一苦労です。大抵
修理保証期間を過ぎたころに上記の接触不良が発生するので上記の箇所の修理でも多額
のお金がかかるケースもあります。
ねむいさんの場合、購入後5年以上経過していたのとPCの裏蓋を外すとカードリーダー
のソケットが手の届く位置にあったので、WPの端子を導電性布テープで詰めて固定し
GNDに強制的に落としてLOCKスイッチの位置にかかわらず常にWP解除状態としました。

接触不良の初期段階の書き込み禁止になったりならなかったりの時は接点復活王なども
有効かもしれません。いずれにしてもソケットが手が届く位置にある場合限定です。

●STM32F4DiscoveryでMP3プレーヤーを構築する

ｸｸｸ…(by鍵最高)もうほぼ完成状態です…♥
こちらについては月末あたりに別枠でまたお知らせしますね～

2012.11.26 Monday

23:03

ネムイ・トリノミアス

MISC

comments(0)

-

いろいろ試す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ビルド手順はubuntuやマカーな方にとっては未だに
需要があるので新たに整備が必要だと感じてきました。逆にWindows使いの
方は9割がたEclipse環境に行くので初見で私のぶろぐまでたどり着く人は
実はものすごく少なくそもそも知っててもみなかったことにさｒ

…さて前ふりはこの辺にしといて小ネタが貯まってきたので消化してきます。

●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さん！！これ国内で販売したら大ヒットまちがいなしですよぅ！

　
とにかく動かすの優先だったので配線が全てやっけつなのは許してほしい。

2012.08.31 Friday

23:59

ネムイ・トリノミアス

MISC

comments(2)

-

OpenOCDの新MPSSEドライバを試す

20130403追追:
こちらのページにてOpenOCDとInsightを用いた効率的なデバッグ方法を
紹介しております。合わせてご参考願います。

20130403追:
私のおきぱで公開しているOpenOCDバイナリはWinUSB/LibUSB両対応と
なっております。
Zadigでインストールする際にLibUSBKを選択するとドライバの入れ変え無しに
どちらの方法からでもアクセス可能でさらに便利になっております。

MLを追いかけてる人ならご存知と思いますが少し前のOpenOCDのコミットで
新MPSSEプロトコルによるJTAGkey2をはじめとしたFTDI系デバイスでアクセス速度が
さらに向上するサポートが追加されました。
Windows環境下ではLPC17xx系でフラッシュ書き込みの速度不足を感じていたので私も
すぐに飛びつきました。

さて従来のものとどう違うかなのですが、新MPSSEは使用するドライバが
LibUSB(libftdi)やFTD2XX(libftd2xx)ではなくMicrosoftの汎用USBドライバで
あるWinUSBを使用する(実際はlibusb-1.0 async API のバックエンド)ようになります。

ねむいさん今までWindows環境上ではかたくなにFTDI純正ドライバ使用して
きましたが速度的に大幅に優勢になったのとlibusbがWin7系でも十分安定した
ので今回の変更を機にFTD2XXを捨てて乗り換えることにしました。

以下いくつかのMCUで実際に書き込みの比較を行います。
FT2232系デバイスとしてJTAGKey2を使用しています。

●RCLKを効かせたLPC2388の場合
*FTD2XX

> "C:¥Devz¥Coreutils¥bin¥make.exe" program openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf" Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29) 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 trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain RCLK - adaptive Info : device: 6 "2232H" Info : deviceID: 67358712 Info : SerialNumber: 22222222A Info : Description: Amontec JTAGkey-2 A Info : max TCK change to: 30000 kHz Info : RCLK (adaptive clock speed) Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) Info : Embedded ICE version 7 Error: EmbeddedICE v7 handling might be broken Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units fast memory access is enabled dcc downloads are enabled target state: halted target halted in Thumb state due to debug-request, current mode: User cpsr: 0x00000070 pc: 0x0002b5ae auto erase enabled wrote 491520 bytes from file main.elf in 7.796974s (61.562 KiB/s) verified 465140 bytes in 0.515632s (880.935 KiB/s) requesting target halt and executing a soft reset target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x000000d3 pc: 0x00000000 shutdown command invoked > Process Exit Code: 0 > Time Taken: 00:09

*WinUSB

> "C:¥Devz¥Coreutils¥bin¥make.exe" program openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf" Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26) 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 trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain RCLK - adaptive Info : RCLK (adaptive clock speed) Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) Info : Embedded ICE version 7 Error: EmbeddedICE v7 handling might be broken Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units fast memory access is enabled dcc downloads are enabled target state: halted target halted in Thumb state due to debug-request, current mode: User cpsr: 0x00000070 pc: 0x0002b5a8 auto erase enabled wrote 491520 bytes from file main.elf in 4.859437s (98.777 KiB/s) verified 465140 bytes in 0.437505s (1038.247 KiB/s) requesting target halt and executing a soft reset target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x000000d3 pc: 0x00000000 shutdown command invoked > Process Exit Code: 0 > Time Taken: 00:06

もう全然威力が違うのがわかりますね♥

●STM32F4の場合
*FTD2XX

> "C:¥Devz¥Coreutils¥bin¥make.exe" program openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf" Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29) 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 adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 cortex_m3 reset_config sysresetreq 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 1000 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: 0x080451a0 msp: 0x10010000 15000 kHz Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE Info : device id = 0x10006413 Info : flash size = 1024kbytes stm32x mass erase complete wrote 550968 bytes from file main.elf in 4.093803s (131.432 KiB/s) verified 550968 bytes in 0.781260s (688.701 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 > Process Exit Code: 0 > Time Taken: 00:20

*WinUSB

> "C:¥Devz¥Coreutils¥bin¥make.exe" program openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf" Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26) 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 adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 cortex_m3 reset_config sysresetreq verify Capture-IR is disabled Info : clock speed 1000 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: 0x08045c28 msp: 0x10010000 21000 kHz Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE Info : device id = 0x10006413 Info : flash size = 1024kbytes stm32x mass erase complete wrote 550968 bytes from file main.elf in 3.937550s (136.647 KiB/s) verified 550968 bytes in 0.546882s (983.859 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 > Process Exit Code: 0 > Time Taken: 00:21

残念ながらSTM32系はフラッシュの消去が遅いので(autoeraseだとさらに遅くなるので
"stm32f2x mass_erase 0"の使用を推奨)そっちに足が引っ張られます。実際のテンポは
あまりよろしくないです。それでも100kiB/Sec越え(どっちも越えてますがー！）
また同じスクリプトファイルでも新MPSSE版はJTAGのクロックが細かく設定できるよう
になり若干JTAGのクロックも早くなります♥
20130507追:
…と思いきや実際にオシロで波形を測定してみると15MHzのままでしたorz
FT2232Hの仕様上MPSSEの最高が30MHzでその一つ下は15MHzとづづきますからLibftdiの
時はOpenOCDの周波数の表示が計算上の値を正直に出してるだけで実際にFT2232Hに
設定されるTCKの周波数とは全く違うということですねorzorz

ちなみにSTM32F1系はもっと悲惨でフラッシュの書き込み速度も遅いため
35~7kiB/Secで一律頭打ちになってしまいます。
*FTD2XX

> "C:¥Devz¥Coreutils¥bin¥make.exe" program openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/stm32f107.cfg -c "mt_flash main.elf" Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29) 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 adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 cortex_m3 reset_config sysresetreq 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 1000 kHz Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0) Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x0802bb00 msp: 0x20010000 7500 kHz Info : device id = 0x10016414 Info : flash size = 512kbytes stm32x mass erase complete wrote 434240 bytes from file main.elf in 11.765700s (36.042 KiB/s) verified 434240 bytes in 1.015631s (417.536 KiB/s) Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0) shutdown command invoked > Process Exit Code: 0 > Time Taken: 00:13

*WinUSB

> "C:¥Devz¥Coreutils¥bin¥make.exe" program openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/stm32f107.cfg -c "mt_flash main.elf" Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26) 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 adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 cortex_m3 reset_config sysresetreq verify Capture-IR is disabled Info : clock speed 1000 kHz Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0) Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x0802bbe0 msp: 0x20010000 9000 kHz Info : device id = 0x10016414 Info : flash size = 512kbytes stm32x mass erase complete wrote 434240 bytes from file main.elf in 11.640700s (36.429 KiB/s) verified 434240 bytes in 0.765629s (553.875 KiB/s) Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0) shutdown command invoked > Process Exit Code: 0 > Time Taken: 00:13

●FM3の場合
*FTD2XX

> "C:¥Devz¥Coreutils¥bin¥make.exe" program openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf" Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29) 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 trst_only separate trst_push_pull 500 kHz cortex_m3 reset_config sysresetreq 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 500 kHz Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000114 msp: 0x20010000 Rize up to Internal PLLed Clock! 15000 kHz auto erase enabled Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 5) Info : Fujitsu MB9B500: FLASH Write ... wrote 524288 bytes from file main.elf in 9.312559s (54.980 KiB/s) verified 505904 bytes in 0.578129s (854.562 KiB/s) Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) shutdown command invoked > Process Exit Code: 0 > Time Taken: 00:12

*WinUSB

> "C:¥Devz¥Coreutils¥bin¥make.exe" program openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf" Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26) 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 trst_only separate trst_push_pull 500 kHz cortex_m3 reset_config sysresetreq verify Capture-IR is disabled Info : clock speed 500 kHz Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000114 msp: 0x20010000 Rize up to Internal PLLed Clock! 18000 kHz auto erase enabled Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 5) Info : Fujitsu MB9B500: FLASH Write ... wrote 524288 bytes from file main.elf in 6.984419s (73.306 KiB/s) verified 505904 bytes in 0.343753s (1437.215 KiB/s) Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) shutdown command invoked > Process Exit Code: 0 > Time Taken: 00:09

FM3の場合はフラッシュの読み書きが非常に速いためRCLKを効かせたLPC2388
並みに速くなっています！
(でもCQ出版系の雑誌記事では大人の事情でわざわざこの性能を殺し、
さらにわざわざめんどくさい使い方やデバッグ方法しか紹介してませんね…)

上記3つの検証ではねむいさん特製の各マイコンに合わせたOpenOCDのスクリプトで
あらかじめCPUの最高速度まで叩き上げてこの数値を出しています。
(最高速にするために動作電圧も+3.3Vを想定しています)。

ということで今回の変更によって益々デバッグの回転力が上がることが期待されます。
また、付加的な利点としてFTD2XXを排したことによりプロプライエタリなライブラリが
なくなるのでOpenOCDのバイナリがおおっぴらに配布できるようになるという私のよう
な教える側の人にとってはARMマイコンのビルド・デバッグ手順の整備が大幅に短縮・
簡略化されることにもなり非常に手間が省けます♥　こっこれで"ねむいさんという
人のページみたけどやり方がさっぱり"って後ろ指挿されることなくなったんじゃ！！

中途半端に尺が余ったので、今までにOpenOCDの操作に関していただいた問い合わせの
中で私が｢初めて触った人が陥り易く、かつ致命的になる｣と感じた問題たちについての
回避策やtipsをご紹介したいと思います。

●STLinkでOpenOCD使ってみたいのですがLibUSBやWinUSBのドライバの
　インストール方法が面倒そうででわかりません＞＜;
->zadigれ

●あんたのところの記事をもとに基板作って自作のプログラム書き込んだらJTAGで
　一切アクセスできなくなってフラッシュが書き換えできなくなってしまった。責任とっ
　てこさえた基板言い値で全部買い取れ。
　~~->ｶｴﾚや!!1!~~
->STM32ではWFI命令を含むプログラムを実行した後ペリフェラルのクロックが停止し
　　ますが同時にコアにあるデバッグユニットに供給されるクロックも仲良く停止し
　　てしまい、JTAG/SWD等で一切アクセスできなくなってしまいます。

　　回避策はWFIが実行される前に速攻HALTをかけてフラッシュを全消去して電源再投
　　入してやれば再びアクセスできるようになります。しかしこの方法はタイミングが
　　シビアすぎるのでお勧めできません。
　　
　　確実な方法は、システムメモリからブートするモードにしておき、リセットかけ
　　ても常にブートローダーに飛ぶようにしておくとJTAG/SWDでアクセスできるよう
　　になってとにかくフラッシュを消去できるようになります。ブートローダーから
　　そのままFlashLoader等のツールでUART経由で消去しても構いません。

　　ここ最近で"元に戻せなくなった"と↑の質問をいただくケースが激増してます。
　　戻す方法はちゃんとあるのであきらめないでください。

●LPCXpresso基板のLPCLinkの部分を分離してJTAGkey+OpenOCDをデバッガにして
　開発を始めてみました。でも何故かmbedやLPCXpresso(ねむいさん注：IDEの方)
　で動いていたLチカのプログラムが全く動きません＞＜;
->NxPの内蔵フラッシュ付きのARMマイコンは伝統的にCheckSumValidationを持って
　　います。これはリセット直後にフラッシュのとある番地にあるリセットベクタの
　　チェックサムの値を確認し正しくなければISPに飛んでいく機構です
　　(ユーザーマニュアル参照)。
　
　　mbedやLPCLinkのライタは書き込む際にリセットベクタのチェックサムを計算し、
　　その番地の値だけ計算済みの値に改変して書き込むのでCheckSumValidation
　　を通過しユーザープログラムを実行することができます。もちろんOpenOCDでも
　　同じことが可能ですが、ベリファイの際は改変前のバイナリと比較してしまう
　　ため、必ずエラーになってしまいます(=ゆえにベリファイだけできない)。

　　ベリファイまで通したい場合は、あらかじめ計算した値をリセットベクタの指定
　　のアドレスに書き込んでおくことで可能となります。私が公開しているLPC系の
　　マイコンのプロジェクトは、すべて計算済みの値を記してあるので参考にしてく
　　ださい(スタートアップのアセンブラファイルに直値を記述)。

●フリーのEclipseを使った開発をしているのですが(ry
->(全身から血をふきだして死んだ)
　　※しかしねむいさんは有償のEclipseベースの開発環境では死にません。
　　　死ぬのはあくまでも設定が死ぬほど面倒な素のEclipseで攻撃された時です。
　　　あといないさんのおぱんつ画像でも一発で死にますので絶対に見せたりしな
　　　いでください絶対ですよ絶対！！１！１

●ねむいさんの手順の通りにしているけどOpenOCDがビルドできません＞＜;
->ビルド済のバイナリを用意したのでこれからはおきぱのOpenOCDのバイナリを使っ
　　てください。FTD2XXのライブラリは使用していないのでGPLに引っかからずバイ
　　ナリを自由に利用できるようにしました!…あとご忠告ですが、最初のうちは変
　　な自分流のアレンジをしたりせずにあくまでも手順に沿ってやりましょうね…。

●mt_flashとかいうのがよくわかりません&見つかりません＞＜;
->大昔はtelnetでOpenOCDとコマンドのやり取りをし、マイコン内蔵のフラッシュに
　　プログラムを書き込む方法しかありませんでした。現在はその方法はスマート
　　では無く、ARMコアなルーターのフラッシュ書き換えの際の動作確認程度にしか
　　利用されていません。
　　デバッグでカットアンドトライをしてる時はとても効率が悪いです。

　　しかしながら上記のような"現在は不適切なor廃止された"とされる数年以上も
　　前のOpenOCDに関する情報が｢最新のOpenOCDを～｣という見出しで検索の
　　トップを占めているのが現状で、何も知らない人がこれらの情報をもとに"最新"
　　のOpenOCDを使おうとしても当然うまくいくはずもなく、"使えない"、
　　"敷居が高い"という印象を持って離れてしまっています。

　　2012年7月現在"最新"の0.6.0ではWindowsはバッチファイルで、Linux系なら
　　シェルスクリプトでJim-Tclのスクリプトをコマンドの引数として一括で呼び出す
　　ことにより簡単に書き込み動作ができるようになります。mt_flashってのはその
　　スクリプトの名前のことで、それが記述されているスクリプトもしくはコンフィグ
　　ファイルがないと当然使用できません。私が公開しているOpenOCDのバイナリ
　　にはそれらが仕込まれたコンフィグファイルがありますので安心してお使い
　　ください。

　　ちなみにmakeと組み合わせることによりさらに効率よく開発が可能です。
　　長々と書きましたがここ見てくれれば間違いないのですがそうだね宣伝だね。

●"Remote 'g' packet reply is too long"というエラーが(ry
->去年の年末に｢次それ聞いたら頭にJTAGKeyぶっ挿して一ビットずつ対策方法焼き
　　こんでくから｣…って私言いましたよね！？

2012.07.28 Saturday

18:18

ネムイ・トリノミアス

MISC

comments(0)

-

いろいろ試す12

年度末始めになるといろいろ忙しくなります。
私がほしいもの(ハードウエア)は2011年中にあらかた買いそろえていたので
わずかな時間を見つけて目下消化中な現在です。

●NokiaのLCDたち
またまた中華掲示板から引っ張ってきたネタなのですが、もうねむいさん一部の
イカス思想の方々からs**kと思われてるかもしれませんがNokiaのGSM用のLCDは
ebayで非常に安価に購入できます。
その中でも比較的ハードル低そうなのを試してみました。

これはNokia1202用のモノクロドットマトリクスLCDです。コントローラーは
STE2007というものだそうです。ハードウエア的な接続や初期化手順は違いますが
基本としては幅広く応用例があるドットマトリクスLCDの代表格であるNokia5110と
ほとんど変わりません。

バックライトもついてますが10mAだとちょっと明るすぎですね。もう少し電流
絞れると思います。
接続はi2cではなく9bit3wireなシリアルのみです。

端子の部分を拡大。
半田付けになれてない人もこれなら何とかいけるでしょう。
ebayでは最安3$前半くらいから購入できます。

こちらはNokiaのC1-01という機種で使用されているTFT-LCDです。
128x160のQQVGAサイズです。

安価なTFT-LCDモジュールのうちホビイストにも手が届くものは数年前の型落ち
品やユーズド品しか回ってこないものですがなんと2011年製のさらぴんでした。
端子の形状は先ほどのNokia1201とほぼ同じ感覚です。またLCDのバックライト
電圧は3.2Vなので非常に扱いやすいです。

動かしてみました。
光のムラはちょっと多いですが、さすが2011年製だけあってコントラストはよい
ですね。こちらも9bit3wireのシリアル固定です。LCDのコントローラはSPDF45124Bか
もしくはHX8353-Cと思われます(両者とも初期化手順・コマンドは同一)

ちなみにebayで買うときの注意ですがこの液晶、大体相場は8$前後で売られて
いますが形がよく似ていてピン配置も同一のものが半額くらいで売られています。
これは別のNokiaの液晶でTFTではなくCSTNなのでご注意ください(SPDF45124Bの
初期化手順と全く同じものが使えます)。

●新たなARMマイコン基板
去年の秋くらいにLPC1788の載った中華基板を購入していました。現在主流になって
いるSTM32F4と比べると見劣りはしますが、それなりの性能は持っています。

外観はこんな感じです。

OpenOCDは既に対応しています。私の公開しているスクリプトファイル群はもちろん
書き込み・デバッグまでサポート済です！

さて、LPC1788はLPCXPressoの最高品種LPC1769版には存在しないMCIインター
フェースがあります。LPC2388にある奴と同じですね。
レジスタの構成もほぼ同一です。
LPCWAREのサイトにはLPC1788のMCI対応のFatFsのサンプルがあるにはあるの
ですが、残念ながら全くと言っていいほど使い物にならなかったのでChaN氏の
LPC2388用のMCIドライバを参考に移植にチャレンジしてみました。

Cortex-M3以降はアンアラインド転送が(速度低下しますが)許容されていて
ごく単純なブロック転送ルーチンで事足ります。DMAのバッファから4byte
単位でメインメモリに高速にコピーするアセンブラのルーチンをこしらえて
みました。

LPC1788のMCIクロックはPCLKが支配的かつ24MHz以下を要求されるため120MHz
だと設定上許容されるクロックは20MHz(PCLK=120MHzの時)になります。
MCUのクロックを少し下げ、CCLK=PCLK=96MHzの時だとMCIクロックも24MHzが
設定できます。

読み取りスピードはこんな感じです。LPCWAREの奴よりは安定しましたが、
残念ながら一部のカードはMCIクロックを大幅に落としても認識ができないものが
ありました。中途半端ではありますが同じくLPC1788を触られている他の方たちが
安定化してくれる事を期待して…白旗
20120905追：
~~安定化しました。安心してお使いください！~~
20230814追:
LPC4088を参考にしてください。

●公開している記事とかプログラムの見直し
私の記事は"ねむいさんの方法だと全然うまくできなかったけど(他の人が公開してる)
方法だと一発で出来た！"というご意見が圧倒的に多いですorz

ねむいさんは事態を重く見て、書きっ放しで放置せずに他の方が試して
引っかかった点を調べて即座に反映するようにしています。正直いつまでも
環境構築ネタなんかに留まってるとほんとに進歩出来なくなってしまうん
ですが、MTMとかの展示系やロボット等の競技系に参加するつもりは今後も
無いので最初のとっかかりとなる情報・ノウハウくらいはケチらずに
公開していく所存でございます。
↑英語圏漁ればこの程度の情報いくらでも転がってるだろっていう突込みは無しで!

ついでにFatFsの移植した例がどこにあるのか分からないとご指摘いただき
ましたので少し前から目立つ場所に日本語以外でもわかるようにリンクを
明記してます！

●そういうこともあって
私も一か所にとどまらずに新たな一歩を進んでみました！

おきぱではすでに対応したコードを公開していますが、STM32F2/4系にlibpngの移植
を行いました！詳細は次回に！

2012.04.07 Saturday

18:03

ネムイ・トリノミアス

MISC

comments(0)

-

いろいろ試す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円がががｇ
　ぁーでも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系のフラッシュ
にも対応してほしいですね♥

2012.02.19 Sunday

22:56

ネムイ・トリノミアス

MISC

-

-

いろいろ試す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として使うためのピン配置があべこべだったのが元の正しい形?に戻っています。
私のぶろぐを参考にSTM32VLDiscoveryをVersaloon化されてる方は注意してください。

↑私も久しぶりファーム変えて気づかないではまった･･･
以前と同じこと言ってる気がしますが春日井から戻ったら手順書も更新します。

てわけで去年とまったく同じことしかやらないまま今年の電子工作納めて
しまいました。

･･･
さて、尺があまってしまったのでよくメールなどで頻繁に頂く質問、いわゆる
FAQをこの場を借りて答えたいとおもいます。

＞メカトロ(含むロボット関連の競技)で使うモータドライバを組むことに
　なりましたがお勧めのFETを教えてください
　・・・など、モータ制御に関する質問
→これなぜか非常に良く聞かれるのですが副業の仕事内容的にモータドライバに
　関する質問は｢私ぜんっぜんわかりません＞＜」としか答えられません･･･
　なんせ私は1聞かれたら100答える人間でなおかつぶろぐのこと副業先の方々が
　皆知ってて変なこと書かないように監視されてますから･･･
　ちなみに本業の虹メに関してはやりたい放題に見えて実ははるかに
　恐ろしいくらい厳しいガイドラインがあって政治・経済・野球・サッカー・
　アニメ・漫画・特撮・絵師さん個人の話題そしてジャガイモの入ったカレーなど
　個人の嗜好が大きく分かれる事がらの話はタブーなっています。
　とくに｢｣の前ではジャガイモの入ったカレーの話題は絵師さんに絵を描くことを
　強要する行為と同じくらいタブー中のタブーにあたります。
　私的にはいないさんのぱんつのつぎにじゃがいも入りの野菜カレー大好物なんですけぉ･･･

　すみません話反れました･･･

＞(任意のマイコン)からARMに乗り換えましたがGPIOのスピードが遅いのですが
→｢最適化｣「吐かれたアセンブラリストを良く見直して無駄な分岐・ロード・ストアが
　出ないようにGPIOアクセスする部分のコードを組みなおす｣
　それとCPUコアが100MHz以上で動いててもGPIOがそのスピードについてけるとは
　限りませんからよくマニュアル(ARM本家の仕様書も)やデータシート穴の開くほど
　読んでください。
　それをマスターしたら君もGPIO高速パタパタで大空に羽ばたくことができる！！
　そしてもうこんなところに戻ってくんなよー！！！１！

＞中華の電気電子系の掲示板からよくネタをパクってますよね
→はい
　私の描いた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ビットずつ焼きこんでいきますからね！

＞ねむいさんってマミゾウのパクリだよね
→そうだね

2011.12.29 Thursday

23:59

ネムイ・トリノミアス

MISC

-

-

Windows10対応軽量シンプルな環境でARMマイコンをInsightとOpenOCDを使ってデバッグする(2020年度版)

20230711追記！！！
GCC12でビルドされたelfファイルは下記のinsightを使った
方法ではスムーズにデバッグできません！！
現在GDB+CodeLiteによる新しい時代に即したデバッグ
手順を作成しておりますので完成まで今しばらく、
いましばらくお待ちくださいませ！！！１１！！

OpenOCD for Windows is HERE!
↑ねむいさんは自前ビルドのOpenOCDバイナリ公開してます。
　解説はこのバイナリを基にすすめますので4649!

この記事は前回からの続きです。前回のものよりちょっと内容が難しくなってます。
前回の内容を基に環境を構築していることが前提で話を進めさせていただきます。
今回はOpenOCDを使用し実際にARMマイコンにJTAG/SWD経由でフラッシュ書き込み
そしてデバッグを行うところまでいきます。
もちろん今回も軽量動作,NO-Eclipse,NO-Cygwinです。

※今回の記事も時代に合わせて適宜加筆修正していきます。

●必要なもの
　1.ARMマイコンが実装されたターゲットボード
　　凡例として、STM32F4シリーズであるSTM32F4Discoveryを使用します。
　　私が配布しているSTM32F4向けのFatFs移植例は、デフォルトのターゲットボードが
　　STM32F4Discovery、デバッガハードウエアがSTLink/V2となっています。
　　Nucleo系板や2015年以降発売のDiscovery系板はSTLink/V2-1に変ってます。
　　
↑とりあえず何も編集しなくてもよくなってます。

　2.JTAG/SWDデバッガハードウエア
　　上記のCortex-M4はデバッグユニットとしてJTAGとSWDという接続方式の両方を
　　サポートしています。ARM7TDMIはJTAGインターフェースのみでした。

　　現在、ホビーユーザーが手軽に利用できるものとしてFT2232系を使ったJTAG
　　デバイスが主流です。
　　以後の解説はそれを利用したJTAGKey2互換の"JTAGKey2 Compatible"
　　を使用しJTAG接続にて解説していきます。
　　JTAGKey2 Comatibleを自作される方はこちらの解説を参考に。

　　SWD接続についてはCMSIS-DAPが現在の主流となっています。
　　NxP系の評価ボードにはmbed版としてデフォルトで搭載されているので
　　もはやおなじみだと思います。
　　その他の品種ではVersaloonや上記のJTAGKey2CompatibleでもSWD接続可能に
　　なっています。
　　
　　2023年現在はCortex-M系マイコンが主流となり、SWD接続がデファクト・
　　スタンダードなっております。
　　

　3.OpenOCD
　　OpenOCDはターゲットMCU(ARMマイコン)と後述するgdb/insightの仲介役を
　　果たすフラッシュ書き込み機能を持ったサーバープログラムです。
　　ねむいさん謹製のビルド済みバイナリを用意しておりますので、
　　OpenOCDのWindowsバイナリはこちらからダウンロードしてください。

　　注意すべきはデバッガハードウエアに対するドライバで、上記リンクに
　　あるOpenOCDバイナリは下記のデバイスとドライバをサポートしています。
　　*JTAGKey2をはじめとしたFT2232系デバイス:(WinUSB)
　　*Versaloon:(WinUSB)
　　*STLink/v2:(STMicro純正/WinUSB)
　　*TI-ICDI(Stellaris Launchpad):(TI純正/WinUSB)
　　*J-Link(WinUSB)
　　*J-Link On LPCLink2(WinUSB)
　　*CMSIS-DAP(HIDとしてドライバレスだがmbed版はVCPドライバ必須)
　　*STLink/V2-1(VCPドライバ必須)

　　各ドライバのインストールは以前は、PID/VID調べてINFファイルを作って
　　…と非常にめんどくさかったのですが、現在はWinUSB向けのGUIな汎用
　　インストーラのzadigを使用することによりインストールが大幅に簡略化され、
　　手軽になりましたのでzadigでインストールを行ってください。
　　公式のサイトにはインストール手順も英文で懇切丁寧に書かれていますが
　　見る必要も無いくらい簡単にWinUSBが導入可能です。

　　注：このOpenOCDは32bit版ですが64bit版Windows環境でも問題なく動作します。
　　　　　64bit版OpenOCDと比べて速度的な面で大差はないです。

　　ARMは新旧の情報がweb上のいたるところで倒錯しすぎて何が正しい組み合わせか
　　分からないと思います。Windows環境でOpenOCDを使われる方は私のぶろぐを
　　しっかり見ていただければ途方に暮れることだけは避けられるかと思います。

　４．Insight(gdb-gui)
　　InsightはgdbのGUI版です。また、純粋なフロントエンドではなく内部にGDB
　　そのものが取り込まれているので別途gdb.exeを用意する必要はありません。
　　当ぶろぐではこれを使用しソースコードレベルのデバッグを行います。
　　これも詳細は後述しますがバイナリが配布されていますのでビルドする必要は
　　ありません。

●下準備
　１．OpenOCDの準備
　　かつてWindows環境にてMSYS/MinGWを用いた手順を公開しておりましたが、
　　OpnOCD0.8.0以降はビルドするまでの手順が大幅に煩雑になり慣れてない
　　人にはビルドがほぼ不可能になってしまいましたので公開を廃止しました。
　　代わりとしましてビルド済のWindowsバイナリを公開しております。
　　ご利用ください。インストール箇所は前回のビルド環境構築手順に倣い、　　
　　C:/devz/arm/ocdにあるものとします。

　２．Insightの準備
　　SourceForgeにあるNetXのページのかなり下のほうにある
　　"arm-none-eabi-insight-7.4.50.20111222-cvs-mingw32-netx.0.7z"を
　　ダウンロードし、任意のフォルダに展開してください。
　　こちらもC:/devz/arm/insight/binにあるものとします。

●ターゲットデバイスにプログラムをダウンロード
　　前回の手順を参考にSTM32F4-Discovery用のmain.elfが作成されたものとします。
　　デバッグ時は最適化オプションを必ず"-O0"にしてビルドしてください。

　１．makeファイルの編集
　　前回も解説しましたが、makefileにあるOpenOCDとInsightがインストール
　　されているパスを指定してください。
　　
　　Insightの引数は下図下段の要領で"--eval-command"で渡すように記述します。
　　Insight起動後のTargetの設定は一切不要です。引数の内訳は以下の通り
　　　--eval-command="target remote localhost:3333"
　　　　-> TCP3333番ポートに接続
　　　--eval-command="tbreak main"　　　　　　　　　
　　　　-> 接続後main関数の先頭で一時停止
　　　-nx　　　　　　　　　　　　　　　　　　　　　　
　　　　-> .gdbinitを作成しない&内容無視
　　

　２．PN2の設定
　　PN2の"TOOL"から呼び出すことが出来るように前回と同じ要領で引数つきで登録し
　　てください。登録するのは"program"と"debug"です。

　３．書き込み
　　"TOOL"から"make program"を呼び出し、OpenOCDからSTM32のフラッシュ
　　書き込みスクリプトを呼び出しターゲットデバイスに"main.elf"を
　　ダウンロードします。
　　OpenOCDのcfgファイルのパスの指定が間違っているとエラーが出ますので
　　各自の環境に合わせてパスを修正してください。
　　

　４．フラッシュ書き込み用のコマンドについて補足
　　makefile内では以下のように記述されています。
　　1.OpenOCDをJTAG・SWDデバイスのcfgファイル・ターゲットMCUのcfg
　　　ファイルを"-f"コマンドで指定して起動する。
　　2.同時に-cのコマンドでターゲットMCUのcfgに記述されているproc(関数)
　　　を呼び出す。
　　3.procに記載されている順にコマンドが実行されフラッシュ書き込みを行う。

　　上記一連の動作にてgdbやtelnetからの回りくどい操作は一切要せず、簡単に
　　フラッシュの書き込み動作が可能です。

●ターゲットデバイスをInsightを使用しデバッグ
　１．makeファイルの編集
　　正しくプログラムが書き込まれたことを確認したら次はデバッグです。
　　makeでOpenOCDとInsightを同時起動するためにちょっと工夫を凝らしています。
　　先に定義したディレクトリパスやコマンドを下記のように配置して、
　　クリック一発で呼び出しできるようにします。
　　

　２．OpenOCD・Insightの起動と接続
　　"TOOL"から"make debug"を呼び出すと、OpenOCDがターゲットMCUに接続、
　　その後Insightが起動します。
　　さらにOpenOCDとInsightのTCP接続まで一気に進み画像のようになれば成功です。
　　

　　ここで注意ですがWin10ではInsightのメニューにあるTarget Settings関連を
　　いじるとInsightが固まってしまい動作不能になるため絶対に
　　触らないでください！

　　この状態で"Continue"を押すとmain関数の最初の行、一時的にmain()に張った
　　ブレークポイント(main()の最初の行)に飛びます。このブレークポイントは
　　一時的なものですぐに消えるのでリソースの無駄にもなりません。
　　
　　
　　ここまできたらあとはInsight上でステップインとかステップアウトとか
　　ブレークポイント張って停止させたりレジスタとかメモリとか(条件付で)
　　I/Oレジスタの値読み出したり自由自在です！

　　また、デバッグ時の重大な注意ですが、Win10ではInsightのレジスタ
　　ウインドウを開くと100%落ちてしまいますので面倒くさいですがコマンド
　　ウインドウから"monitor reg"でMCUの各レジスタを参照するようにしてください。
　　

　３．デバッグの終了
　　終了する時はTools->Stop Toolsで終了させたいところですがが、PN2では
　　ひとつのプログラムしか終了できず、Insightだけが終了してOpenOCDが
　　終了してくれません。
　　私は下記の要領で強制的にタスクを殺すwindowsのtaskkillコマンドを使った
　　バッチファイルを作成してこれを呼び出して"確実に"終了させています。
　　↓この呪文をバッチファイルにしてwindowsフォルダに突っ込んで
　　　おきましょう。
　　taskkill /F /IM openocd.exe
　　taskkill /F /IM arm-none-eabi-insight.exe
　　

2011.08.14 Sunday

14:18

ネムイ・トリノミアス

MISC

comments(16)

-

Windows10対応軽量シンプルなARMマイコンのGCCビルド環境を構築する(2020年度版)

OpenOCD for Windows is HERE!
↑ねむいさんは自前ビルドのOpenOCDバイナリ公開してます。
　解説はこのバイナリを基にすすめますので4649!

当記事はWindows環境下におけるARMマイコンの開発環境構築を目指してはおりますが
私が公開しているプロジェクトをビルド/デバッグするために必要な最小限の手順の
指南という位置づけです。
はっきり言いますが初学者向きの解説ではありません。専門的な語句の意味や
GNUMakeを駆使したコマンドラインビルドの方法を熟知している前提で話を進めます。

2019年現在は無料のEclipseベースの開発環境GNUARMECLIPSE、
STM32限定でフル機能が使えるAtollic TrueStudioとMDK-ARMの2品種、
そしてオンラインコンパイラ+ライブラリ等の強力なサポートがあるmbedとかが
充実しており、一般的な事柄を学びたい初学者の方にはそちらを強くお勧めいたします。

ちなみにねむいさんはメーカサポートが無い素のEclipseを使うと｢あわびゅ！｣と
叫びながら全身から血を吹き出して死ぬ奇病に罹っていて、且つCygwinを使うと
バストサイズが強制的に20cm減のマイナス補正を喰らい(=フラットなB(Breasts)特性
を持ついないさんと同レベルに堕ちてしまい）虹裏メイドねむいさんとしての
あいでんてぃてぃを完全に失ってしまうため、当ぶろぐでは絶対に扱いません。

　※要注意※
　　　ツール群の盛衰や時勢により時々刻々と本記事の内容は変化していきます!

●必要なもの
　１．ARM用GCCコンパイラ
　　とにもかくにもまずはこれです。
　　現在はLaunchpad.netが提供し、ARM本家から配布されている
　　GNU Tools for ARM Embedded Processors
　　を強くお勧めします。表向きCortex-Mx向けとなっておりますが、LPC2388等の
　　ARM7TDMIもしっかりサポートしており古い品種でも問題なくビルドが可能です。

　　今回の手順ではダウンロードした上記コンパイラをC:/Devz/ARM/launchpad
　　直下に解凍するものとします。解凍後launchpadフォルダには
　　arm-none-eabi,bin,share,libの4つのフォルダがあるのが正解です。

　　Windows環境下で動くARM用GCCコンパイラとして、Bleeding Edge Toolchain
　　なんかもあります。いずれもABIはEABIで2015年以降流通している
　　最新のGCCコンパイラはもはやすべてEABIとなっています。

　２．サポートツール群
　　ねむいさんが公開しているプログラムはコマンドラインビルドを想定しています。
　　IDE全盛の昨今は古臭いものとなってしまいましたがmakeコマンドでビルドする
　　というベタベタなクラシックな手法を敢えてとっています。
　　makeの他にunixコマンドのechoやrmなどを用いているので、これらのunix
　　ライクなコマンドをネイティブなWindows環境下で動かすことができる
　　Coreutilsを使用します。

　　a.Coreutils本体
　　有志の方々が作成されたCoreutilsの"Binaries"のリンク先をダウンロードし、
　　 2バイト文字やスペースを含まない任意のフォルダに解凍してください。
　　b.GNUMake3.81
　　次にGNUMakeを同様にダウンロードしたあと解凍しCoreutilsを解凍した
　　場所と同じフォルダに置いてください。
　　c.サポートDLL群
　　最後にmakeをダウンロードしたページの下にある"dependencies zip file
　　 (中身はlibintl3とlibiconv2)"をダウンロードしGNUMakeと同様の処置を
　　してください。

　　今回の手順では上記3点がすべてC:/Devz/Coreutils/bin内にあるものとします。
　　このbinフォルダ内にmake,echo,rm等のunixライクコマンドとdepedenciesの
　　libintl3.dll,libiconv2.dllが存在していることを必ず確認して進めてください。
　　ここで間違ってると下述のPN2からmakeを呼び出す段階でコケて失敗します。
　　
　　よくやる間違いが、最初のCoreutilsを解凍して出てくるbinフォルダの中に
　　さらにmakeやdepedenciesの入ったbinフォルダを置いてしまうことです。

　
C:/Devz
　　　├ARM
　　　|└launchpad
　　　|　└bin　(←GCCコンパイラのバイナリがある場所)
　　　|└ocd(←openocd.exeのある場所)
　　　└Coreutils
　　　 └bin　(←make他unixライクコマンド群のある場所)
　　　
↑ねむいさんは上記のディレクトリ構造にしています。
　　以下この構成で話を進めます。

　　ちなみにAVRToolChainでもARMと同じような感じのディレクトリ構成にすると、
　　同じ感じでコマンドラインビルドが出来ますのでおすすめです。

　　※以前はWinAVRのutils配下にあった同様のファイル群の使用を推奨していましたが、
　　　WinAVRは開発が停止し数年経ち、フリーで利用できるAVRToolchainに主流が移行
　　　したのでもう一切使用しませんし使ってはいけません。

　２.５．sh.exeが見つかりません対策(必ずしも必要ではない)
　　ネット上で手に入るARMマイコンのGCCプロジェクトの中ではWinAVRのmakefileを
　　ベースにしたものがいくつか存在し、そこにはshell関数などのbashに依存した記述が
　　数か所あります。この記述が含まれているとまともにビルドができません。

　　当ぶろぐで公開してるプロジェクトはmakefileからbash(/bin/sh)に依存して
　　いる記述はすべて排しておりますが、他の方のプロジェクトをビルドする際の
　　回避措置として紹介します。
　　こちらからwin-bash.zipをダウンロードし、解凍して出てきたwin-bash.exeを
　　Coreutilsのbinフォルダに突っ込んでください。次にmakefile　ファイル中に
　　記載されているはずのSHELLの設定を以下のように書き換えてください。
　　SHELL = sh
　　↓
　　SHELL = win-bash.exe
　　bash.exeは自身のファイル名によって特殊な動きをするので横着してwin-bash.exeの
　　方をsh.exeとリネームしてしまうと逆にビルドが通らなくなります。ご注意ください。

　３．エディタ
　　メモ帳でｾｺｾｺ編集してコマンドプロンプトからmakeを実行してもいいですけど
　　makeを引数つきで呼び出せられるエディタを使えばIDEのように使えます！
　　ねむいさんのお勧めはProgrammers Notepad2(PN2)です。素のEclipseは(ry
　　ビルド時の解説はこのPN2を使用して解説します。

　　注：必ずStable2.3以降を使用してください。
　　　　また、日本語入力に対応するために下記の要領で多バイト文字の設定を
　　　　”Shift-JIS”に変更しておいてください。
　　　

　　それとPN2のインストール先は無用なトラブルを避けるためスペースや2バイト
　　文字が混ざるディレクトリは避けてください。

　４．デバッガソフトウエア&ハードウエア
　　ARM用のデバッガはホビーユーザーご用達のGDBサーバであるOpenOCDを
　　使用します。次回の記事で使用法を紹介します。
　　また、MCUとJTAG/SWDで通信するハードウエアはFTDIのFT2232系JTAG-I/Fを
　　使用するのが私の中でスタンダードになっています。
　　これらに関しても次回詳しく紹介します。

●下準備とビルド
　※以後はエディタとしてPN2をインストールして使うことを想定して解説します。

　１．ソースコードの展開
　　今回の凡例として、STM32F4向けの液晶表示プログラムをダウンロードして
　　ローカルに落としたzipファイルをローカルフォルダに展開します。
　　このときディレクトリパス(アドレス)にスペースや２バイト文字が絶対に
　　入らないようにしてください。
　　

　２．makeファイルの編集
　　PN2がインストールされている場合、拡張子pnprojのアイコンをダブルクリック
　　すると下のような画面になると思います。"makefile"をクリックしてmakefileの
　　編集画面を出しましょう。
　　
　　OpenOCDとarm-none-eabiのファイル名は特殊なことをやらない限りは
　　もう変えないようにしてください。
　　

　　下画像の要領でそれぞれの環境に合わせてARM用GCCコンパイラ、サポートツール
　　群、デバッガのディレクトリパスを設定していきます。パスの区切りは"¥"
　　ではなく"/"を使用してください。
　　ディレクトリパスはスペースや２バイト文字が絶対に入らないように
　　してください。大事なことなので二度言います!!
　　
　　

　　makefileの書き方の作法は此処では解説しないので
　　各自詳細は調べて下さい。

　３．PN2の設定
　　PN2をインストールしたての人は、makeコマンドをPN2の"TOOL"から
　　呼び出すことが出来るように以下の要領でmakeコマンドを引数"all"
　　つきで登録してください。
　　その後、"build","clean"の引数についても同様に登録してください。
　　
　　
　　

　　重要：Windows環境変数のPATHは設定する必要はありません！
　　　　　下手に設定しているとビルドが通らなくなることがあるのでご注意ください。

　４．ビルド開始
　　
　　デフォルトでは評価ボードの設定はSTM32F4Discovery向けになっています。
　　また、各評価ボード設定時の各ピン配置を知りたい場合は同梱のdoc/Boards.txtを
　　参照してください。

　　設定が終わったら"Tool"から"make all"を呼び出しビルド開始です。
　　

　　ビルドが完了したらメモリ使用量などの情報がコンソール上に現れます。
　　もしコンパイルエラーなどが発生しビルドが止まったら赤色で強調表示されるので
　　エラー箇所の特定も簡単です。
　　

　　上記の液晶表示プログラムはデフォで下記のライブラリ/ドライバを
　　有効にしてます。
　　　　-libjpeg
　　　　-libpng
　　　　-giflib
　　　　-FONTX2ドライバ
　　　　-抵抗膜式/容量性タッチパネルドライバ(特定のボード限定)
　　　　-HelixMP3デコーダ(特定のボード限定)
　　　　-HelixHE-AACデコーダ(特定のボード限定)
　　数分ほど時間がかかります。Warningが出ますがビルド時の設定喚起の
　　ためにソースコード中に"#warning"プリプロセッサを敢えて入れてる箇所が
　　いくつかありますので気にしないでください。
　　エラーが出てビルドが止まった場合は各種設定を見直しましょう。殆どの場合、
　　makefile中でPATHの設定を誤っています。

　　ちなみに"make all"はコンパイルしたオブジェクトを全部消してまっさらに
　　してからビルド、"make build"はすでにオブジェクト吐かれたソースはスルー
　　してビルド(ソースコードを一部書き換えてカット&トライしたいときに最適)です。
　　"make clean"はその名のとおり生成されたelfやhexファイル含めてアセンブラ
　　リストファイルやオブジェクトをまるっと消去してしまいます。

お次はターゲットCPUへの書き込み&デバッグですが…次回に続きます。

2011.07.28 Thursday

23:11

ネムイ・トリノミアス

MISC

comments(9)

-

いろいろ試す8

国内は大変苦しい状況が現在進行形で続いていますが、今は新しい生活が
始まる季節でもあります。ねむいさんも二度とていどひくいと
いわれないように言われないように毎年この時期に新たな決意をしながら
勉強を重ねてきたつもりですが彼ははるかにていどたかくなってしまって
やっぱ資質も必要だよねと思いつつLED点滅で足踏みして茶を濁す毎日を
送っております…そうかあの悪たれも今春から阪大か～…#

…てわけで前回に引き続き今回も小ネタをこなしていきます。

●キャラクタLCDを2線で制御する
元ネタは中華サイトのBBSより。
2線と言ってももちろんi2c液晶ではないです。最低でもデータ4bit+制御
2bit分合計6本のI/Oの接続が必要なHD44780互換タイプのLCDモジュールを
受動部品を駆使してたった２本のI/Oで制御を行うとこのとです。
コンセプトとしてはでんし研氏の鶏卵問題を解決するAVRライタに近いですね。

↑実際にATMEGA1284Pを使用してやってみました。久しぶりにAVR使った…

20230629追:
11年後も同じ事やってる私

●LPC1114のI/Oトグルが遅い?…
> >>278
> main　system　clock４８Ｍで、ＩＯﾊﾟﾀﾊﾟﾀは約２Ｍだたよ。
とのことです。んなアホなと私も思いましたが、検証用のI/Oをトグルさせてる
部分のコード↓
while(1) { LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data }

をGCC4.5.1の-O2でビルドして出てきた該当箇所のアセンブルリストが
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data 390: 4a03 ldr r2, [pc, #12] ; (3a0 ) <-2cycle 392: 4b04 ldr r3, [pc, #16] ; (3a4 ) <-2cycle 394: 2100 movs r1, #0 <-1cycle 396: 50d1 str r1, [r2, r3] <-2cycle LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data 398: 3101 adds r1, #1 <-1cycle 39a: 4249 negs r1, r1 <-1cycle 39c: 50d1 str r1, [r2, r3] <-2cycle 39e: e7f7 b.n 390 <-3cycle

でリファレンスマニュアル首っ引きで調べると合計14サイクル、理論上でもシステム
クロックが48MHzで約3.43MHzくらいでしかトグルすることが出来ない計算になってし
まうので最適化レベルにもよりますけどやっぱしこんなものですね…
ちなみにガチでLPC1114で理論上とりうる12MHzのトグルスピードを出したいのならば
STR命令の部分だけ延々と続くようにしてやればいいので、
while(1) { LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data ～(出来る限り沢山並べる) LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data }

ってしてやるとよいです。
この場合実際のトグル波形は↓のようになります。

Cortex-M0のSTR命令は最短2サイクルのため、GPIOがAHBバスに繋がっている
LPC1114では48MHzの場合は最高I/Oトグル速度は理論上12MHzとなります。

話は変わりますが、audin氏が指摘しているMARY基板で公開しているソースの
ライセンスが矛盾している件ですが、ねむいさん的には金銭が絡まない限り、
つまりソースコード自身はタダで利用できる状態のうちは別に大きく騒がれない
だろうと思われます(ぉぃ
などと偉そうに言ってるそういうお前はどうなんだと言われそうですが、私の
公開しているものは該当するスタートアップのコードはSTM32のアセンブラの
スタートアップコードを参考にしてarm-v6mでビルドが通すことのできる独自の
ものなので…
…ぇーとあのその…セ、セウト！

20111203追：
その後の顛末
あつ氏の見解

 audin氏曰くMARYのライセンス形態が修正されたようです
i2c.h,i2c.cに関しては大本のNxPのKeil向けライブラリのライセンスに関する
文章を引用すると...
> Software that is described herein is for illustrative purposes only
> which provides customers with programming information regarding the
> products. This software is supplied "AS IS" without any warranties.
> NXP Semiconductors assumes no responsibility or liability for the
> use of the software, conveys no license or title under any patent,
> copyright, or mask work right to the product. NXP Semiconductors
> reserves the right to make changes in the software without
> notification. NXP Semiconductors also make no representation or
> warranty that such application will be suitable for the specified
> use without further testing or modification.
とのことです。
ざっと見たところ
"ここにあるソフトは製品(ここではLPC1xxx)のプログラムのしかたに
関する情報をカスタマーに提供する例示的な目的のためだけに書かれました"
ってのと
"(あなたが)このソフト使うことに(NxPは)責任も負債も持ちませんし
特許・著作権・製品のマスクワークのもとにあるライセンスや商標も譲渡しません"
という点がミソですね。再配布(redistribution)の制限に関する記載が見当た
らないのですが、再配布たことによって面倒なことになっても俺(NxP)は
責任持たないよと解釈しておけばよいでしょうか。

おまけ
MARY基板でaitendoさんの格安OLEDボード動かして見ましたねむいさんは
CheepにいくZE！これは公開しているプログラムに反映されています。

●SUG○IHUBはSUG○Iのか
http://www.system-talks.co.jp/product/sgc-4X.htm
ねむいさんはシステムトー○ス製のSUH○IHUBを副業元のノートパソコンで
愛用しています。SUG○Iハブは独自の電力増強回路によりUSBデバイスを安定
して動作させることができるという触れ込みです。確かにやっすいUSBハブでは
よく発生する「バスパワーのUSBデバイス挿しただけで突入電流で電圧ドロップ
して同じハブに刺さってるUSBデバイスも巻き添えで認識外れる」現象が一切
発生しません。しかし…

STM32のマイコン基板を一から組んででLDOの動作確認してる時に気づいた
のですが、このハブを使った時だけダウンストリーム側のVbusの波形が
えらめっちゃ汚い…

※ねむいさんが持ってるSUG○Iハブはこっちの少し古い型なので現行の
モデルでは改善されているかもしれません

恐らく独自の電力増強回路(=+5VDCDCコンバータ)のスイッチング時の
出力波形がもろに出ちゃってる感じです。デジタル回路だけならあんまし
問題無いですが、これアナログ含む回路だとこんだけ揺れてるとちょっと
都合が悪いです。
てわけでハブ側の改造でさらにSUG○くできるかしてみました。

基板はDC-DCコンバータとNEC製のUSBコントローラIC,そして2ポート分
(PORT1とPORT2)だけですがUSBパワースイッチャ(電源監視)ICまで積んで
あります。さらにダウンストリーム側には100uFのアルミケミコンが1ポート
ずつ鎮座しています。市販のハブのほとんどが最低限のパーツで寄せ集めた
チープな作りなのを鑑みると値段にしては超豪華な作りだと思います。
で、こんだけ出力に電解乗ってて波形があれってことはESR不足かな？
てことでDCDCの出力部に低いESRのキャパシタ乗っけりゃ解決かなと
判断してねむいさんのトラの子NEC-TOKIN製NEOCAP(150uF/10V品)を
ぶち込んだ！

よし！
てわけでさらにSUGO○くなれたようです。前途のとおりデジタル回路用途
のみなら未改造でも問題無いので昨今のUSB機能付きのマイコンでバリバリ
開発する人には多少のおいたにはびくともしないこのハブお勧めです！

●某付録のRX62N基板
国産マイコンは諸般の事情で全く興味ないので去年と同じく電源周りの挙動だけ…

電源立ち上がり

電源立ち下がり

去年のSH2A基板はLDOの出力が入力が断たれた後も0.数V程ず～っとチャージを
保ったままになって次回の電源投入時に不具合が出ていました。しかし、
今回は+3.3VLDOにSBDをかまして素早くチャージを放電するようにしてあり、
しっかり対策されているようですね。

2011.04.16 Saturday

16:50

ネムイ・トリノミアス

MISC

comments(0)

-

いろいろ試す7

この度の大地震で被災された皆さまには心よりお見舞い申し上げるとともに
一日も早い復興を願っております。私も復興支援を私なりにやってみます！

…てわけで電子工作野郎になる時間がなかなか取れなくなってしまったので
今回はもともとタイトル通りいろいろやるつもりだった内容を大幅縮小
変更してお送りいたします。

●AVRマイコンを使ったバックアップ機能つきRTC時計

前回軽く紹介していましたが実用レベルになれたので改めて紹介します。
目玉は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のデータを受ける部分の処理がまずいのでしょう。
てわけで魔の時間帯でもデータを受け付けるように…
…しただけでフン詰まり現象は無くなりました！

UARTの通信込みでこんだけ叩きだせるなら恩の字じゃないかしら！？
でもやっぱし専用ICには到底かなわないので…
遊び以外で使わない方がいいですよ(重文)
上記の成果はおきばにあります。
20110406追：
STM32のUSBライブラリがV3.3.0に上がりVCPのデモもこの問題が修正された
…と見せかけて修正されていないようです。ご注意を！

●STM32 ValueLine-Discovery
を秋月さんから購入しました。ねむいさんみたいに買ってすぐにバラすような人
対策か、ST-Linkの部分が切り離すことができません。しかしこのST-Link部も
Versaloon化できるようになっているのでさっそくVersaloon化してみました。
これについては後ほど別記事で詳しく取り上げたいと思います。

↑お約束のTFT液晶モジュール。8bitバス繋げるのめどいのでSPI接続
方式の液晶で…。この評価ボードのセットはSTM32が二つも付いているので
(部品取り基板として)とても利用価値があると思います。
機能限定で単品物作るなら新品でパーツ揃えるより安上がりで最適でしょう。

●トラ技別冊LPC1114ボード
圓山宗智氏作のMARYと呼ばれるLPC1114と周辺のボード群にちょっと興味が
魅かれたので購入してみました。最初はLPC1114基板とCP2104基板で2枚組かと
思ったのですが、本当に同じ基板が2枚(LPC1114+CP2104の基板が2つ)なのですね…

LPCXpressoと大きく違う部分はLPC1114のメイン発振器が内部オシレータ
(LPCXpressoは外部に12MHzの水晶がある)の使用を想定しているのでスタート
アップ時のオシレータ選択レジスタを内部オシレータにしとかないと
動かないといったところくらいでしょうか。

CQ誌のサイトからダウンロードしてきたMARYのサンプルを参考に過去に
作ったとっかかり用のLPCXpressoのプログラムと共用できるようにしてみました。
MARYで動かす時はmakefile内のボードの定義をMARYに変えるだけでおｋです。

2011.03.29 Tuesday

21:36

ネムイ・トリノミアス

MISC

comments(8)

-

いろいろ試す6

あけましておめでとうございました！

去年に"来年から本気だす"といったものの自分の誕生日の絵作ったりたぬたぬの置物
をはるばる信楽まで(次回詳しく解説)買いに行ったりしてブログの更新もままならな
いほど大忙しであっという間に1月中盤です。

更新はしてませんでしたがいろいろ手は動かしています。今は思うところあって
AVRマイコンを使ったベタな時計を作っています。

と言っても私が一から作ったわけではなく、↑写真左のように以前に作られた
ATmega328で作成された物をATmega644pへと移植するような感じです。
5年前に残された資料をもと元主人の異遺品をふんだんに使って
あれやこれやしたり元主人が作り込んだヘボい処理を修正したりしてますが
コンセプトとしてはO-family氏のATmega88pを使用したもの
とほぼ同じ物になりそうです。しっかしVFDは見やすくて良いものだ～

また、去年汎用のTFT液晶モジュール表示プログラムのARM版を更新しましたが、
XMEGA版もやっとこ最新に更新しました。こちらです。
ビルドは最新のAVR Toolchainを使用してください。
WinAVR20100110とはSRAM・ProgramMemoryににおいて64kb以上の領域に
アクセスするためのマクロが公式に取り込まれた絡みで互換性は
全くありません!この件については次次回の記事にてみっちり解説します。

んでもって上のやつを早急に終わらせたら次はまたARMに戻っておべんきょ継続です！

↑川内康雄氏の著書をねむいさんも購入しました。仕事でやってる人も続々参入して
レヴェルが跳ね上がった今の電子工作シーンに対応するため、私も一から基礎を
みっちりやりなおすことにしました！
それ言ったの何度目だよそれっていう突っ込みはスルーで！

試用するSTM32についてももうすぐ出るらしいが全く音沙汰がないF2系の
大規模なMCUを意識してSTM32F103ZET6と超高速SRAMが乗っかるボードを
taobao経由でチップと基板を別々に買い必要なパーツだけ実装して使ってます
(日本で同じものをフルセット買うよりかなり安くなるため)。

↑STM32F103ZET+高速SRAM物で一番小規模な奴。
　セコく基板だけ買ったせいで回路図もらえなかったので解析からする羽目にorz

↑中華評価ボードでは比較的有名なPowerAVR製の基板たち。
　上がSTM32F103ZETのもので下がよく使ってるSTM32F107VCT6のもの。

STM32F107VCT6版は単に以前のものを移植だけで済みました。
これは~~すでに公開してる~~プログラム中で統合済みです。しかしながら
STM32F103ZETははぢめて触るのでベースとなる環境から整えないといけません。
先ずは基本的なFatFsと液晶表示の実装なわけですが今回は外付けSRAMも絡むので
そちらも併せて取り入れていくことになるでしょうね～。
これができたら次はI2S!んでさらにそれをSTM32F107VCTにフィードバック！
(↑すぐなかったことにする人間なので一応宣言しときます…)

そしてARMに関してはもう一品、LPC1343を使ったライントレースロボットの学習教材
ビュートローバーも秋月さんから販売されていたので買ってみました。

↑コンパクトなパッケージ。

↑中身こんな感じです。

↑組んでみました。

…

電池買って無いや。続きはまた今度！

2011.01.15 Saturday

13:51

ネムイ・トリノミアス

MISC

comments(0)

-

あばばばば

…はぁ、今年も終わりですね～…
今年の〆として、
STM32F107VCT用とLPC2388用、そしてSTM32Primer2用の液晶表示プログラムを
更新しました。
いつものおきぱにありますのでご自由に～

そうそう、CodeSourceryの中のGCCが4.5.1になってLinkTimeOptmizationも実装
されていますけどもちろんそれにも対応しています。-fltoを付けるだけですが、
結構目に見えて違いが出てきますので試してみてください。

今年の後半は高専等の学生さんからの質問をたくさんいただくようになりました。
私もわかりやすい記事を書くよう努めたいと思います。あと｢｣からいないさんの
イラスト云々のお問い合わせも時々いただきますが"びょういんいけ"と的確に
対応しております。

…とりあえずもう液晶デバイスばっかいぢるのは卒業してねむいさん自身も
新たなるステージに進む必要があると痛感しています(ｷｯ
まぁそう気張らずにtaobao等で購入した怪しいデバイスとかを消化していく
つもりです。やってるうちに新しいネタを思いつくと思います。

というわけでねむいさん来年から本気出す！！

2010.12.31 Friday

19:20

ネムイ・トリノミアス

MISC

comments(0)

-

中華TFT液晶モジュールを動かしてみる(概論)

※今回の記事は適宜追加・修正していきます。

Arduino等のプロトタイプボードを使ってaitendoさんで売ってるようなMCUバスで動
かすタイプのTFT液晶を専用基板起こさずに無理くそうごかそうとするとどうしても
ジャンパ線山盛り配線になってしましますがこれを8bitじゃなくて16bitバスでやって
みるとどういうことになるかというと…

こういう地獄絵図になるわけでしてもう二度と横着しないと心に誓う。
さて、上の画像表示に使ったのはコントローラICにILI9327をもつDST9901A-NHと
いう3.2インチ、WQVGA(240x400)の液晶モジュールです。データシートには
コントローラICがHX8352Aとか書かれていますがブツはちゃんとILI9327です。
aitendoさんでも同じのを扱っていますが、私はtaobaoで他の商品と一緒に
まとめ買いした物です。
(ねむいさんはHX8352Aのものもちゃんと持っててこれはDST9901A-NHとくりそつなｎです
が8月位に一度ぱ…動かしてるところをお見せしてますね～…ぬふふ)

データシートや製品紹介に記載されてる内容が現物と全く違うとか言うのは
中華液晶だけでなく中華製品にはよくある話ですが、TFT液晶モジュールを使って
何かを作るのではなくてモジュールそのものを動作させ(ただけで満足して飽き)
ることが目的と化してしまったねむいさんが得た情報をtaobao経由の購入の
事例にからめてお伝えします。

基本的にTFT液晶(とOLED)モジュールは大きく分けてRGB,MCU,シリアルの3つの
接続方法があります。MCUバスとシリアルバスで接続できるモジュールはフレーム
バッファを内蔵したコントローラICを必ず持っていて、AVR等のメモリ資産が無い
小規模のマイコンでも簡単に扱うことができます。
今回はそのMCUバスとシリアルバス接続方式のモジュールついて説明します。

●MCUバス接続方式について
マイコンとモジュールを繋げる基本構成は下図のようになっています。

↑i8080タイプのMCUバスの場合
ほとんどのモジュールはi8080タイプの8bit若しくは16bitのMCUバスとして
アクセスを行います。一部のモジュールではM68kタイプのアクセス方式を選択
できるものがありますが一般的にi8080タイプのアクセス方式の方が圧倒的
多数となっています(例外的にHD44780とかはM68kタイプですね)。
中規模のマイコンが持っている外部バスで接続したときは、マイコンからは
アドレスが2つだけあるSRAMに見えることになります。

このi8080タイプの方式はMIPI AllianceDBI(Display Bus Interface) Type B
に相当します。

また、データバス幅はコントローラICのデータバス幅選択ピン、ILI系列のICならIMx
に当たるピンをモジュールへのリセット信号入力時に信号レベルを確定しておくこと
によって選択されます。モジュールによっては外部まで出ておらず、FPC上のチップ
抵抗の配置によって決定しなければならない物や16bit幅に固定されてしまっている
ものがあります。
逆に低解像度でサイズが小さいものはFPCの面積的に8bitに固定されていたりします。

以下にaitendoさんでも購入できるモジュール達のビット幅変更箇所等を。
STM025QVT-001はソフトウエアからビット幅が変更可能な逸品なので
おきぱにあるソースコードを参照のこと…。

YHY024006A

EGO028Q02
上二つはFPC上のジャンパ抵抗(0ohm)の配置でバス幅を決定。

WBX280V009
FPC上のジャンパ抵抗(0ohm)を画像の位置に移すとIM0ピンが外部に出る。
…と以前書きましたが最近出回ってるのは少し違う模様。
なんと写真に示すとおりFPC上のパタンで16bitバス固定になっていました。
8bitバスで使ってる方や、Ardunio使いの方は別のTFT液晶モジュールを
使用しましょう。

DST9901A-NH
ビット幅選択ピンは外部に出ている。FPC上に抵抗を実装できるパタンはあるが、
前途の理由でFPC上で作業は不要。

ちなみにFPC上の該当のピンにIMxが出ていなくて実質上NC(NoConnect)になって
るモジュールもありますが、UEW等の極細の線でジャンパを飛ばしてやれば無理やり
ですが外部から選択もできます。ていうかこうしておく方がなにかと便利ですよぅ！

●シリアル(SPI)バス接続方式について
マイコンとモジュールを繋げる基本構成は下図のようになっています。

今日びの一般的なマイコンではほとんど有しているSPIインターフェースを用いて
接続することができます。基本的にMCUバス接続方式とアクセスの手順は変わらず、
パラレルのデータバスがシリアルになっただけです。
比較的小規模の解像度のTFT液晶/OLEDモジュールがシリアルバスの接続方式を
有しています。一部のモジュールでは外部ピンの設定によりMCUバスも選択できる
ものがあります。
このとき一部のコントローラICではシリアルバス接続だとREADができないものが
あります(よってMISOが不要)。
ST7735は一つのラインがMOSI/MISOを兼ねていたりして制御は少々特殊です。
READもするのならハードウエアSPIよりGPIOのソフトSPIの方が使いやすいです。

この方式はMIPI AllianceDBI(Display Bus Interface) Type Cに相当します。

QVGA以上の解像度ではコントローラICがサポートしているにもかかわらず設定用
ピンが外部に出ていないためシリアルバス接続方式が選択できないものがほとんど
でしたが2023年ではHVGA(320x480)解像度でもSPIインターフェースがありますね…。
逆に大きい解像度のRGBインターフェースをもつパネルにもSPI用のピンが出ている
ことがありますが、これはリフレッシュレートやガンマ値の設定専用という
あくまでRGB_IF(MIPI DPI(Digital Pixel Interface))の補助用です。

以下にシリアルバスで接続できるモジュールたちを。

aitendoさんのおなじみ小型OLEDモジュール。バス選択ピンの設定によりMCUバス
接続方式も可能です。このキャリーボードはSPI固定になっています。
コントローラICはSSD1332。少々癖があります。
・CSは8クロック目でD/Cの同期をとるため、下げっぱではだめ。

同じくaitendoさんでも売ってるH161T01。これを使った~~「TFT-LCD Shield~~」が
MTM06でNetSynth.orgのブースにて販売されました！そうだね宣伝だね。
お問い合わせは~~shield.io~~はねむいさんまで!!

taobao経由で購入したシリアルの他にRGB,MCUバスも選択できてQVGAな液晶。
しかし前途のとおりコントローラICがSUCKと言う罠

同じくtaobao経由で購入した、シリアルの他にRGB,MCUバスも選択できて
QVGAな液晶。これはコントローラICが馴染みのILI9325なのでさっきのと違って
暴走とかしないで安定して動きます♥♥
…と思ったらdeviceIDを調べるとILI9325フルコンパチのILI9328であることが
分かりました…。まぁこの程度のチャイナリスクは想定済みです。

最近ebayを試用したときにego-chinaさんから購入したSPI接続専用タイプの
TFT液晶モジュールJD-T18003-T01。コントローラは皆さんおなじみのST7735です。
高速性は必要なくてちょっとした表示に使いたいなんて時に重宝します♥

そして小動物の足。
20110519追:
JD-T18003-T01には型番・外見はまったく同じですが、中のコントローラICが
異なる品種(ST7735R)があります。
ST7735RのものはST7735と初期化手順が異なるのでST7735のコードでは一切
動きません！ご注意ください！
しかもご丁寧にRDIDxで読み出すデバイスIDまで一緒なので私のいつものの
ディスプレイドライバのソースはST7735とST7735Rは分けてあります。
敢えてそうしてあります。

↑購入したばかりの状態だと保護シールのはがしタブの色の違いで
　見分けがつきます…

さて、これらのマイコンから簡単に扱える液晶/OLEDモジュールは少し前までは国内
向けのリユース液晶をボｯタ価格で購入せざるを得なかったのですが、現在は大陸系の
電子部品屋であるaitendoさんがいわゆる中華TFT液晶モジュールを販売していて、
日本国内でも使いやすく安価な液晶を手に入れることができるようになりました。

通常の電子工作に使用するならば入手性・価格性・資料性・ユーザともにaitendoさん
で扱っている商品で十分なのですが、もっとマニアックなのを使いたいとかあやしい
液晶モジュールををあえて動かしたいとかいう奇特な人にはtaobaoで購入することを
お勧めします。こっからが今日の本題です！

●taobaoで売っている商品を買う
先ずtaobaoのメインサイトで欲しい商品を検索して探します。検索のときには当然
ひらがなカタカナはNGです。TFT液晶モジュールを探すなら"液晶屏"とかのキーワー
ドを絡めてみましょう。

めぼしいものを幾つか見つけたら買いたいものをいったんリストアップしましょう。
国を跨ぐので中国国内送料に加えて国際送料がかかります。小種類・少数だと効率
が悪いのでよく考えて買う物を決めましょう。

買いたいものが決まったら日本国内で購入代行をしてくれる業者さんに依頼します。
日本国内から業者挟まないで直接購入するのは日本住みでなおかつ故郷にも生きた
銀行口座を持ってる中国人くらいしか無理だと思います。
購入代行業者さんも業務形態・料金の計算方法などはさまざまですので説明をよく読
んだり質問した上で自分が購入する予定の物・値段・量・そして店舗数を考慮して
最適なところを選びましょう。料金の支払いは、落札作業前と日本に発送される前の
2回にわけて請求されることがほとんどです。

業者さんを選んだら購入依頼のやり取りを行いますが出来るだけ詳細を伝えるように
してください。こちらでは周知のことでも担当の人は基本的に部品知識は無いので
意図が伝わらないことが有ります。これこれこういう理由でこうしてくれ・こう伝え
てくれとお願いしましょう。また、購入は現地の落札担当の人が相手先店舗の人とや
りとりを行うことがほとんどです。その際に不明な点がある時は質問が返ってくると
きがあるので丁寧に分かりやすく返答しましょう。また価格が半導体部品で1元とか
異様に安い値段設定されているものもありますが、これはたいてい万個単位で購入し
た場合の価格のことで、**個なら一つ**元だがそれでもいいか？と返事がきます。
逆に他の店舗と比べて2/3くらいの微妙に安い値段で取り扱ってるのはリマーク品や
フェイク品がまぎれている可能性があるためよく吟味してください。

それと超重要な事柄ですが相手先店舗が製品紹介文に"資料は配布する"と明記され
てある時は落札時に必ずもらうようにお願いしましょう。言わないとブツだけが
来て解析に大幅に時間がかかります。もらえるものは全部もらってください！
20110404追：
taobao代行王さんで購入代行依頼した際に上記のお願いしても無視されます。
自力解析出来るor過去に動かした経験がある物じゃないとお勧めできません

しかしこれだけよく考えてやりとりしてもお国柄とんちんかんになりがちですが…

…っというわけで落札が終わりお目当ての商品が届きます…物や地域にもよりますが
2010.12現在だと購入代行依頼してから早くて3週間弱で手元につきます。
いていEMSで届けられます。

●実際に解析して動かしてみる

↑2.2寸の液晶モジュール。
落札時にデータシートを送ってくれと何度も頼みましたが対応してくれませんでしたorz
こういうことは非常によくあります。仕方なく自分で解析を行います。
解析の流れは以下の手順で進めます。

　ピン配置の推定
　　　　↓
　コントローラICの推定
　　　　↓
　初期化手順の決定
　　　　↓
　基本動作確認

TFT液晶モジュールを数種類以上触られてる人はご存知かと思いますが、FPCの
ピン配置はメーカーが違えどほぼ同様の"定番"なパタンのものがあります。
たとえばEGO028Q02とWBX280V009はピン配置が全く同じでキャリーボードが
使い回しできたりします(YHY024006Aもピッチは違いますがピン配置は同じです)。
そのことから同じピクセルサイズ&インチ数の液晶モジュールの中でデータシートが
手に入るものを調べ、記載されているピン配置から詳細不明のモジュールの
ピン配置を推定することができます。

幸いにもこのモジュールは一目しただけでわかるレベルでパタンが別れていて
容易にピン配置を推定することができました。

次に、液晶のコントローラICの推定を行います。ピン配置の推定した時と
同じように似たサイズモジュールのデータシートより候補とするコントローラICの
型番を控えます。
2.2寸のものは176x220ピクセルの品種が多いようですね。176x220ピクセル対応の
品種をあらかじめ絞り込んでおきましょう。これをもとにコントローラ内の
レジスタの値を読み出し、コントローラICの決定を行います。大抵は00h番地の
レジスタにコントローラ固有の"device code"をもっています。

ILITEK系列のものはほとんどこれでコントローラの種類を判別できます。電源電圧は
LED用電源を除いて3.3Vでほぼ事足りますが、一般的にはLCDモジュールでは標準的な
2.85Vが作れたらそれに越したことは無いです。

しかしこの液晶モジュールは読みだしても0x00が帰って来るだけでした。違う番地の
レジスタに値を放り込んで読むと放り込んだ値が正しく返ってくることから読み書き
はきちんとできていることが分かります(これができていない時はピン配置の推定まで
戻って調査しなおしです)。

私は上の結果から、176x220ピクセル対応で特定のレジスタ番地にdevice codeが無い
品種のものとして"HX8340B"がこの液晶モジュールに使用されていると推定しました。
ここまで絞りこめたら後はネットでこの型番を検索して初期化手順を調べます。
たいてい中華サイトから見つかるでしょう。なんせ中華液晶モジュールですから…。

ところでコントローラICのレジスタの値を読み出すとか言ってるけど具体的にどうすれば
いいの？という話になりますが、私の場合は動作実績があるILI9325系列のプログラム
を使用し読み出しを行っています。これはChan氏が公開しているOLEDテスト用の
プログラムをベースに各液晶モジュールにも対応できるように構造化させたものです。
またchan氏のFatFsのテストプログラムも兼ねています。
おきぱへ
上のおきぱにあるコードで実践していますが、"汎用で使える抽象的なレベル"と"
デバイス固有のレベル"なコードとを分ける、プログラムのライブラリ化/モジュール化
をしておくようにすると、未知の液晶/OLEDモジュールを調査する時やトラブル
シューティング時の問題の切り分けにも役に立つかと思いますので、コードサイズや
速度を気にしない方に強くお勧めします。

話は脱線しましたが、HX8340Bの初期化手順を作り、確認用プログラムを走らせます。

おっし！
こんな感じで上手くいけたら目的達成です。画面が真っ白でうんともすんとも言わない
場合はピン配置やコントローラICの推定まで戻って解析を進めましょう。
この液晶、大きすぎず小さすぎずで手軽に扱える掘り出し物を引き当てたみたいで、
ねむいさん的にはとても気に入ってます♥
次構想してる基板に載せちゃおうかな見たいな
20110824追：
その後の調査で宇顺电子のS95329というS95215Aを改変したモジュールである
ことが確定しました。

20111110追：
さらにその後改訂版のデータシートを手に入れ"Read HIMAX Device ID"
コマンド(0x93)でDeviceIDを読み出すことに成功しました。

データシートや資料が手に入ればここまで苦労することは無いのですが、何せ相手は
大陸なので資料が手に入ったとしてもまだ安心はできません。ふつーに全く違うデバ
イスの資料付けてきたり素で勘違いしてたりなんて日常茶飯事で私が経験してるもの
だとコントローラICがILI9320ものを指定して購入したつもりが実際に動かしてみると
"ハズレ"のLGDP4531で、資料として送ってくれた"ILI9320"の初期化ルーチンとやらも
見比べるとLGDP4531のものだったとかあってもう勘弁してくだち…
もしLGDP4531のものを引いてしまったら奇声上げながら窓から投げ捨てる以外にない
とおもいますね…(←本気でやっちゃだめよ！)

というわけでオチが無い話をつらつらと書き殴ってしまいましたが、そこまでしてチ
ャイナリスク負いたくない人は中華液晶モジュールばっかいじってる奇特な人と仲良く
なって動作が保証されてるのを譲ってもらうのがいちばんだとおもいまし　た！
それといつまでも液晶デバイスばっかいじってても進歩がないので次はまぢで新しい
別の試みに手を出していこうと思います。

ちなみにおきぱで今もメンテを行っているSTM32F4向けTFT液晶モジュール表示
サンプルは以下のコントローラICに対応しています。いろんなサイト巡って集めて
きて、すべて動作確認を取っています。
当エントリは何気に当ぶろぐの一番人気のメインコンテンツの一角となってます！

20161028追:
現在、液晶ブームはひと段落したのか今度はESP-WROOM-02関連の記事が仏契です。
次点はブラウザベンチマークとか日本の自然歩道です。

20230801追:
ESP32やRaspi関連の絡みで液晶関連で参照数と問い合わせが
増えてきました…このエントリもだいぶ追い上げてます…！

↓以下、動作確認済みのTFT-LCDコントローラICです↓

*ILITEK
ILI9160
ILI9163B
ILI9163C
ILI9132
ILI9220
ILI9222
ILI9225
ILI9225B
ILI9225C
ILI9225G
ILI9320
ILI9325
ILI9325C
ILI9326
ILI9327
ILI9328
ILI9331
ILI9335
ILI9338B
ILI9340
ILI9341
ILI9341V
ILI9342
ILI9481
ILI9486L
ILI9488
ILI9806H(HALF-RAMモデルのためMCUバスには向かない)
ILI9806G

*Renesas
BD663474
HD66772
HD66773
R61514S
R61503U
R61505
R61505U
R61505V
R61505W
R61509
R61509V
R61526
R61580
R61581
R61581B0
R61408

*Himax(奇景光電)
HX8309A
HX8310A
HX8312A
HX8340A
HX8340B(T)
HX8340B(N)
HX8345A(T)
HX8346A
HX8347A
HX8347D
HX8347G
HX8352A
HX8352B
HX8352C
HX8353C
HX8353D
HX8357A
HX8357B
HX8357C
HX8357D
HX8369A
HX8369A-00
HX8369A-01

*NEC
uPD161704A

*Solomon Systech (International) Limited
SSD1332(OLED)
SSD1339(OLED)
SSD1351(OLED)
SSD1283A
SSD1286A
SSD1289
SSD1297
SSD1298
SSD2119
SSD1963(外付けタイプ)

*EPSON
S1D19122
S1D19105

*Sitronix
ST7735
ST7735R
ST7732
ST7781
ST7785(ST7787とまったく同じコードで動く/バスアクセスはかなり遅くすべし)
ST7787(バスアクセスはかなり遅くすべし)
ST7789V2

*MagnaChip
MC2PA8201(Nokia6300 & NokiaE51)
D51E5TA7601(HALF-RAMモデルのためMCUバスには向かない!)

*LG
LGDP4511
LGDP4531(←VCCｦ2.8V以下にしないと不安定になります！！！)
LGDP4535
LGDP4522
LGDP4524
LG4538(LGDP4538の誤字ではない)
LGDP4525
LGDP4551

*Samsung
S6E63D6(OLED)
S6B33B6(CSTN)
S6D0117
S6D0128
S6D0129
S6D0144
S6D0151
S6D0154
S6D0164X1
S6D1121
S6D05A1
S6D02A1
S6D04D1

*Raydium(瑞鼎科技股份有限公司)
RM68050(ILI9325と全く同じ)
RM68070(ILI9335と全く同じ)
RM68042
RM68090
RM68110
RM68120
RM68130
RM68180

*Orise Tech(旭曜科技)
SPFD5420A
SPFD54124B
SPFD54126B
SPFD5408A
SPFD5408B
OTM3225(ILI9325とまったく同じ)
OTM8009A(STM32F769I-discoveryでDSIにも対応)
OTM8012A(HALF-RAMモデルのためMCUバスには向かない!)
OTM4001A(R61509Vと全く同じ)

*統宝光電
C1L5-06
C1E2-04

*Novatek Microelectronics(聯詠科技股份有限公司)
NT3915
NT39106
NT39116B
NT35510
NT35516
NT35702
NT35582

*Tomato LSI Inc
TL1793
TL1771

*その他
SEPS525(OLED)
REL225L01
FT1505C

おまけ
駄目押しチャイナリスク

↑ﾜｰｨ USB3.0のExpressCardだ～！

↑ｳﾎﾞｧｰ!

2010.12.27 Monday

13:12

ネムイ・トリノミアス

MISC

comments(2)

-

いろいろ試す5

以前購入したものの全く触れていなかったPSoC5を少し触りました。PSoC5は中の
CPUコアがMAX80MHzで動作するCortex-M3が採用されています。6月位にPSoC5の
評価キットPSoC 5 FirstTOUCHが安価で販売されたので、CypressからSRAMと
一緒に購入しました。

統合開発環境のCPUコア(Cortex-M3)プログラムのビルドはGCCです。
CodeSourceryG++を呼び出すようになっています。

P.O.V.による文字表示がデモプログラムが出荷時に書き込まれています。
電源を入れてぶんぶんふるとメッセージが順次表示されます。

今現在C言語ソースしかいじり方が分からないのでCypressのサイトの
チュートリアルでもみてツールの使用方法を覚えていきますか…。
以上前フリ終わり！

さて、ゆっこちゃんの誕生日(だいぶ前ですが)も無事終わり、少し落ち着いた
のでかねてから考案中だった複数のフォントに対応したFontX2ドライバ作りを
行いました。
ProjectC3氏のページの内容を元に以下のような動かし方にしました。

1.半角・全角ごとにFontX2ファイルのヘッダー部の構造体をSRAM上に構成する。
2.各フォントを登録するごとにSRAM構造体の分だけをｺﾞﾘｺﾞﾘ消費。
　(というわけで比較的大規模のマイコン上での使用を想定してます)。
3.半角・全角ともにグローバルなFontX2の構造体ポインタを置き、文字描画する関数
　群は全てこれを参照するようにする。
　使いたいフォントで文字を描画する前に構造体ポインタに「1.」で登録した構造
　体のアドレスを渡すようにする。こうすることで使用したいフォントを簡単に切り
　換えることができる。
4.FontX2側のドライバは使用するFontX2ファイルの登録と、要求されたascii/sjis
　文字コードに対してフォントデータの実体があるアドレスのオフセットを返す。

決め打ちでやるのならばSRAMなぞ消費する必要はないのですが、汎用性を上げたかっ
たのでこんな感じにまとまりました。今はまだマイコンのフラッシュメモリ上にFontX2
のデータをそのままのっけています。こちらも追々と大容量のSPI-ROMに追い出すつ
もりです。

というわけでSTM32やLPC2388のTFT液晶表示プログラムにそれを組み込みました。
タッチパネルの設定の際に使用しています。

当たり前ですがフォントそのものは同じなので以前のと見た目は変わりませんけどね。
表示に使用しているデバイスはSTM025QVT-001を使用しています。何気に使用可能な
MCUバス接続タイプのディスプレイモジュールの種類もどんどん増やしていってます。

あと、IJG JPEGライブラリを使用したjpegファイルのデコードの実験なんかも試みて
います。同ライブラリを使用したsirius506氏作成のmp3プレーヤーのフォトフレーム
部をそら氏がSH-2A向けに利用されたものをさらに参考にさせてもらいました。

いろいろ試行錯誤してようやくビルドが通ったのですがバイナリサイズが220kbyteも
膨れ上がってしまったのでフラッシュメモリ容量がMAX256kByteしかないSTM32F107
系には到底載りません。というわけでjpegデコード機能を乗っけるのはフラッシュ
容量が豊富なLPC2388やSTM32 Primer2向けのみ(将来的にはLPC1769も)
になりそうです。

QVGAサイズの場合LPC2388ではjpegデコードに必要な最低限のRAMは
1024*35=35840Byte
以上必要でした。RAMもそれなりに喰うようです。その際標準関数mallocがheap領域を
使用するのでスタートアップをいじりmakefile内で使用量を明示できるようにしました。

ｺﾂ

ﾒｶ

ﾜｳｿ
やっぱデコード->描画には多少時間かかりますね。他にもIJG JPEGライブラリは
リサイズ機能なんかもあってピクセルサイズが大きいものでも縮小してくれます。
今回使用した小動物たちの画像は大阪海遊館で撮影したコツメカワウソたちです。
まだ全く手を付けてませんが120MHzで動くLPC1769で同じことやるとどんだけ早く
デコードできるかちょっと楽しみです。

最後になりますが、少し前からTFT-LCDShield開発の折にtaobaoで液晶モジュール
などをいろいろ購入していました。その中でひときわ目立ってた3.5inch、
320x480の大解像度、それでいて扱いやすいi8080インターフェースで接続できる
液晶モジュールを紹介します。

デカイ！

で、デカイ！

72MHz駆動のSTM32F107VCT6だとSDカードから320x480,24bitの標準的なWindowsBMP
ファイルの一枚絵を読み取り表示するのに掛かる時間を測定したところ約360mSec掛
かりました。
(全画面消去->SDカード読み出し->RGBデータ24bit->16bit変換->GPIO転送)

普通これくらいの解像度になるとRGBインターフェースしかないのですがこの
モジュールはi8080のMCUバスで接続できるコントローラIC(ILI9481)が内蔵されて
いてAVR等のワンチップマイコンでも手軽に扱えます(ただし16bitバス強制)。
まだタッチパネルが搭載されたモデルは一般に出回っていないものの、簡易で
フォトフレームを作成するのなら見栄えがあるものができると思います。

おや？aitendoにも似たようなものが…？(棒読み)
追：私のはFPCの形状・ピン間隔・外観が全く違う別物です！

2010.10.14 Thursday

20:38

ネムイ・トリノミアス

MISC

comments(5)

-

JTAGKey2Cloneをもっと使ってみる

20150514追:
2015年現在、JTAGKey2CompatibleのRev.5まで
上がっています。自作される場合はこちらを参考にしてください。
20150514追:

よし
やっと日記書く余裕ができた…MTM05に参加された皆様、本当にお疲れ様でした。
日記はぢめてもう1年たったことだし、ねむいさんもていどひくいと言われないような
仕事をしたいものです。本業の虹メの方がスレの途中で寝落ちしまくっててていどひくいどころ
じゃない状態なのは置いといて。てかいつもスレに参加してくれてる人ごめんなさい…。

さて本題、前回はJTAGkey2のクローンを作成し、LPC2388のフラッシュプ
ログラミングでRTCKの威力を確認しましたが、今回もう少し設定をなぶってみました。
CQ-FRK-NXP-ARMの基板は12MHzの外部クロックが乗っているのでOpenOCD接続時に
デフォルトの内部4MHzRC発振からそちらで動くように切り替えると速度が速くなる
わけですが、PLL使って最高速の72MHzまで叩き上げるとさらに速くなるはずです！
(もう十分早いけど)

↓というわけで試して比較してみました。
●Ext12MHz,With AdaptiveClocking(RTCK),CCLK=12MHz
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf"
> Open On-Chip Debugger 0.5.0-dev-00267-gef72484 (2010-05-26-21:28)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 100
> jtag_ntrst_delay: 100
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> RCLK - adaptive
> RCLK - adaptive
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 6 "2232H"
> Info : deviceID: 67358712
> Info : SerialNumber: 22222222A
> Info : Description: Amontec JTAGkey-2 A
> Info : max TCK change to: 30000 kHz
> Info : RCLK (adaptive clock speed)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x000038bc
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> wrote 131072 bytes from file main.elf in 2.671892s (47.906 KiB/s)
> verified 118132 bytes in 0.921881s (125.139 KiB/s)
> requesting target halt and executing a soft reset
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x600000d3 pc: 0x00000000
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:05

●Ext12MHz,With AdaptiveClocking(RTCK),CCLK=72MHz
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf"
> Open On-Chip Debugger 0.5.0-dev-00267-gef72484 (2010-05-26-21:28)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> RCLK - adaptive
> RCLK - adaptive
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 6 "2232H"
> Info : deviceID: 67358712
> Info : SerialNumber: 22222222A
> Info : Description: Amontec JTAGkey-2 A
> Info : max TCK change to: 30000 kHz
> Info : RCLK (adaptive clock speed)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x000021bc
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> wrote 131072 bytes from file main.elf in 2.609392s (49.054 KiB/s)
> verified 118132 bytes in 0.234377s (492.212 KiB/s)
> requesting target halt and executing a soft reset
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x600000d3 pc: 0x00000000
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:05

CCLKを72MHzに叩き上げたことによってベリファイ速度が滅茶苦茶速くなってます…
さすがですね～。RAMへのダウンロードも同じくらい早いでしょう。
一方フラッシュ書き込みそのものはMAX50kb/Secで頭打ちのようです。これはフラッ
シュ消去/書き込み時間が固定でそこがボトルネックとなっているからでしょう。
STM32の方も同様の理由で頭打ちになってMAX20kB/Secが精一杯ぽいです。これももう
少し早くなると思うんだけどなあ…まだいじる必要があるのか…

あと気をつけなければならないのがOpenOCD用スクリプトのフラッシュ書き込み時の
CCLKの設定ですが、こちらも適切な値に設定していないと正しく書きこまれません。
例としては↓こんな感じです。

RTCK対応のLPC2388用OpenOCDコンフィグは既に72MHz動作対応済みです。

そして今日はもう一件JTAGKey2Cloneを使った重要な事柄があります。

先月発売されたInterfaceには付録としてSH2Aの基板が付いていました。これにはH-UDI
とかいうJTAG用の端子が備わっていて同時期にリリースされた某JTAGデバッガを接続
してデバッグができるようになってます。"た"の人曰く最初はIF誌で同JTAGデバッガの
回路図全公開の予定だったらしいのですが大人の事情で非公開となったそうです。

でもFT2232デバイス(FT2232H)を使っているのは自明かつMPSSEでJTAGとして使える
ピンは固定なのでJTAGkey2Cloneのハードウエアが余裕で使えるんじゃないかと
言うことで実験野郎してみました。
…と思ったらすでにされてる方がいました。
てか某掲示板では動かすまでいろいろアドバイス頂きありがとうございます…。
dllをこう使えばディスクリプタ合わせるためのEEPROMの書き換えすら要らんのか…すげ

てわけでJTAGKey2Cloneまんまで動きましたワーィ


これでSPIROM何発ぶっ飛ばしても無駄な出費払わずにいつもの使って復帰できますね♥
JTAGKey2(無印やクローン含む)があればAltera,xilinx,ARM,SHの開発に使いまわせられます！

でもねむいさん国産マイコンは仕事でうんざりするほど使ってるからSH2Aとかこれ以上
触るつもり全く無いんだし！

おまけ
毎年気になる電源ライン

↓立ち上がり

こっちはふつーですね・・・

↓立ち下がり

あーっとこれは…

1.2Vはスパッと0Vまで落ちてますが3.3Vラインが0.6～0.4V付近で長時間たむろって
ます…
リセットICの電源も+3.3Vから引いてますがこれは誤動作しやすくなるやもしれません。
1.2Vが立ちあがらないUSBが繋がらない云々の件は3.3Vラインの残存チャージが原因の
一つと見てよいですね。

対策は3.3VレギュレータのVoutからVinにチャージを引き抜くようにショットキバリア
かましてやれば良いでしょう。syslab氏もすでに試されていて実際に効果ありの
ようですね。ていうか基板設計するときにもっときっちりオシロで波け…

…まぁいいや…もうARM9のボードで遊ぼう…淘宝网で買った液晶も
たくさん残ってますし

2010.05.28 Friday

05:48

ネムイ・トリノミアス

MISC

comments(0)

-

ねむいさん遊んでる暇あるの！？

届いたわぁ･･･ARM9(LPC3250)のボードが…！
今は別の案件で忙しすぎて触ってる暇すらないけどMTM05終わったk頃くらいに
androidとか動かしてみたいなぁと画策してます…。
ちなみにEmbedded Artisitsさんより直接購入しました。日本国内で代理店通して
同スペックのボード買うとどうしても割高になってしまうので…。
20190726追：上のボードは前の職場にすてｔｹﾞﾌﾝｹﾞﾌﾌﾝ寄贈してきました

ついでにこれも購入しました…しかしOpenOCDでLPC1114/1343書き込み/デバッグ
出来るようになるまで上記のLPC3250のボードとともに塩漬け…。
ついでに"た"の人のARMデバッガCortex-M3対応も期待。

上のARM9のボード購入にあたってJTAGKeyCloneの機能アップ版である
JTAGKey2Cloneの制作を行いました。
お手本にしたのは最初にJTAGKeyCloneを作ったときと同じく神木さんの作例です。

20130422追:
JTAGkey2Cloneの回路図改良しました

JTAGKey2は中のチップがFT2232Hになっています。超高速信号を引き回すことに
なるので、FTDIチップ周りは神木さんのものと同じく出来合いのモジュールを
使用しています。
氏の作例と違う部分はレベルシフタICをJTAGKeyCloneで使用したときとおなじもの
を使用し、FT2232H <-> レベルシフタ間を+5V電圧系で駆動させている点です。
FT2232HのVCCIO上限は+3.3Vなので通常なら思いきり制約に違反している
ところですが、FT2232Hとレベルシフタの+5V入出力トレラント性を大いに利用して
レベルシフタの入力(つまりFT2232Hの+3.3Vな出力)を+5Vでプルアップするという力技で電圧変換の問題をクリアして
います!!
20150218追:
↑の出力プルアップ作戦は470ohmでプルアップしてもFT2232Hの出力バッファの
　引き込み能力の方が勝ってしまうため全く意味がありません。
　結局出力は3.3Vのままで規約違反です。でたらめ書いてましたすみません。
　代わりに+5VCMOSレベルとの動作の際の電圧遷移がどうなっているかを
　調べましたので参考にしてください。
20150218追:

20150514追:
電圧レベルに関してケリをつけました！！！！！！
20150514追:

また、前回のJTAGKeyCloneを作った時はDAISENの変換基板に頼っていましたが、
今回はメッシュアース基板を利用してレベルシフタを基板に直付け・UEW線で引き
まわして高速な信号も扱えるようにしています。

↑こうしてみると1608サイズのパスコンが相対的におっきく見えるほと小さいですなぁ…

こうして作り上げたJTAGKey2CloneはJTAGKeyCloneと同じ感覚で使用ができます。
OpenOCDで使う場合なら、jtagkey.cfgと指定しているのをjtagkey2.cfgに変える
だけで使えます。JTAGKey2の売りはUSB-HighSpeedで各種シリアル転送がさらに
高速になった上にRTCK(AdaptiveClocking=自動クロック追従)がサポートされて
いる点なわけですが、これはLPC2388のようなRTCK端子が出ているデバイスで
真価を発揮します。

以下に各条件でOpenOCDからLPC2388に100kB程のデータをフラッシュ書き込み/
ベリファイした時の速度の比較を記載しておきます。
(以下無駄に長いので覚悟してください)

●JTAGkeyClone(FT2232D)/LPC2388_Ext12MHz X'tal
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> 500 kHz
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 4 "2232C"
> Info : deviceID: 67358712
> Info : SerialNumber: 11111111A
> Info : Description: Amontec JTAGkey A
> Info : clock speed 500 kHz
> Error: JTAG scan chain interrogation failed: all zeroes
> Error: Check JTAG interface, timings, target power, etc.
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> 100 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x000000d3 pc: 0x00000000
> Warn : Bad value '00000000' captured during DR or IR scan:
> Warn : check_value: 0x00000009
> Warn : check_mask: 0x00000009
> Error: JTAG error while reading cpsr
> 500 kHz
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> Error: Target not halted
> Error: failed erasing sectors 0 to 10 (-304)
> Command handler execution failed
> make.exe: *** [program] Error 1
>
> > Process Exit Code: 2
> > Time Taken: 00:04
↑JTAGKeyCloneでは外部クロックだとフラッシュの書き込みが出来ません！

●JTAGkeyClone(FT2232D)/LPC2388_Int4MHz RC
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> 500 kHz
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 4 "2232C"
> Info : deviceID: 67358712
> Info : SerialNumber: 11111111A
> Info : Description: Amontec JTAGkey A
> Info : clock speed 500 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> 100 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x000000d3 pc: 0x00000000
> 500 kHz
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 7.468798s (17.138 kb/s)
> verified 117280 bytes in 2.812518s (40.722 kb/s)
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:14
↑JtagKeyCloneでは内部4MHz RC(電源投入時のデフォルト状態)でフラッシュ
　書き込みするのが無難なようです。

●JTAGkey2Clone(FT2232H)/LPC2388_Int4MHz RC
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> 500 kHz
> fast memory access is enabled
> dcc downloads are enabled
> 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 500 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> 100 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x00002028
> 500 kHz
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 6.750044s (18.963 kb/s)
> verified 117280 bytes in 2.640642s (43.373 kb/s)
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:13
↑JTAGKey2Clone(FT2232D)の時と比べて少し早くなってますね。

●JTAGkey2Clone(FT2232H)/LPC2388_Ext12MHz X'tal
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> 500 kHz
> fast memory access is enabled
> dcc downloads are enabled
> 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 500 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> 100 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x0000373c
> 500 kHz
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 5.843788s (21.904 kb/s)
> verified 117280 bytes in 1.015632s (112.768 kb/s)
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:10
↑JTAGKeyClone(FT2232D)では不可能だった外部12MHzのクロックでの
　書き込み/ベリファイが出来てます。スピードも速くなってます。

●JTAGkey2Clone(FT2232H) with RCLK/LPC2388_Int4MHz RC
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 100
> jtag_ntrst_delay: 100
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> RCLK - adaptive
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 6 "2232H"
> Info : deviceID: 67358712
> Info : SerialNumber: 22222222A
> Info : Description: Amontec JTAGkey-2 A
> Info : max TCK change to: 30000 kHz
> Info : RCLK (adaptive clock speed)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x00002040
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 5.859412s (21.845 kb/s)
> verified 117280 bytes in 2.640642s (43.373 kb/s)
> requesting target halt and executing a soft reset
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x600000d3 pc: 0x00000000
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:09
↑書き込みは少し早くなっていますが、RCLK有効でもベリファイ速度はCCLKの関係で
　頭打ちになってますね。

●JTAGkey2Clone(FT2232H) with RCLK/LPC2388_EXt12MHz X'Tal
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 100
> jtag_ntrst_delay: 100
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> RCLK - adaptive
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 6 "2232H"
> Info : deviceID: 67358712
> Info : SerialNumber: 22222222A
> Info : Description: Amontec JTAGkey-2 A
> Info : max TCK change to: 30000 kHz
> Info : RCLK (adaptive clock speed)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x0000373c
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 2.765643s (46.282 kb/s)
> verified 117280 bytes in 0.921881s (124.236 kb/s)
> requesting target halt and executing a soft reset
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x600000d3 pc: 0x00000000
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:04
↑ううん早い

JTAGkey2Clone+RTCKの組み合わせではJTAGKeyCloneと比べるとフラッシュ書き込み
ベリファイとも約2.7倍ほど早くなってます。LPC2388はROM容量が大きいので早いに
越したこたぁ無いですね♥これでLPC3250を迎え入れる体制ができました！

…あ、わかってます、遊ぶのはやる事やってからです…！！

ついでにLPC23xx系のマイコン使うときのTipsですが、このマイコンは電源を起動する
とフラッシュに書かれたプログラムとは関係なく先ず内蔵のブートローダーが立ち上が
ります。大まかな流れとしては以下のようにしてブートシーケンスを行うようです。

P2.10ピンの状態を読みに行く,P2.10=Lowの時
->ISP起動

P2.10=Lowではない時
->0x14にかかれたチェックサムが有効かどうか確認
チェックサム有効
　->ユーザープログラム起動
チェックサム無効
　->ISP起動
(本来これにCRP他も絡みますが詳細はUserManualのp606以降を参照してください)

したがってフラッシュロムに何も書かれていないとP2.10LowでなくてもISPが
起動します。このときにJTAGから書こうとするとISPのアドレスに飛ばされて
しまってうまくいかない時があります。がた老氏も同じ問題に遭遇されていましたが私も
JTAGKey2Clone使った時に初めて気づきました(JTAGKeyCloneでは出なかった)。
この問題はinit後即soft_reset_halt->フラッシュ書き込みで回避できました(OpenOCD-0.5.0)。
~~確証が完全にとれたらcfgファイル更新しときますね。~~更新しましま。

んでもって現在のOpenOCDのLPC2xxx系のフラッシュ書き込みはチェックサムを計算
して0x14番書き込んでくれる機能がありますがこれやってしまうとベリファイで引っか
かってしまいます(難儀だ)。
どうしてもベリファイしたかったらフラッシュメモリの0x14番地に割り込みベクタの
チェックサムを前もって計算してスタートアップに書き込んどくとOpenOCDからも
ベリファイすることができます
(割り込みベクタなんてほぼ固定ですしこれでも良いと思います)。
もちろんこれやる時はcfgファイル中の"calc_chacksum"は消しておくように！

2010.04.24 Saturday

14:35

ネムイ・トリノミアス

MISC

comments(0)

-

ねむいさんは心がきれいだからウソなんて付けない

20101228追：
MCUバス接続タイプのTFTLCDモジュールを動かしたい奴は必ず読め！！１１！

はぁはぁ…ま、また中華液晶モジュール買ってしまった…それはおいといて

今日はねむいさんがみなさんにいいこと教えちゃいます！！
aitendoさんのWBX280V009/EGO028Q02はコントローラがILI9235…じゃなくILI9325で
既存のコードがそのまま使える！！
それとYHY024006Aの商品ページでコントローラはILI9320ってなってるけどそれは
間違いで本当はILI9325なの！！初期化が微妙に違うからはまるよ！！
(20100720追:さり気に修正されています)

んでもってWBX280V009もJ4にあるチップ抵抗をR2に移すと8bitバス化できるけど
この改造でIM0が端子に引き出せられるようになるので外部から簡単にバス幅を切り
替えられますよぅ！！

(20100720追:
　当たり前ですがこの改造を行ったら外部に出たIM0端子は使用するバス幅に
合わせてちゃんとレベルを決めてやらないとだめです)

(20101219追:
　現在aitendoさんから購入出来るモデルは、FPC上で16bitバスに完全固定
　されています。16bitバスでアクセスできないマイコンやプロトタイプボードを
　持ってる人は、別の液晶モジュールを使用してください。

>このaitendoのWBX280V009は日を追って進化？しているようで、現時点でのロットではＦＰＣ上のパターンで16Bit固定となってしまっているらしい。

進化というかスペックがほぼ同じのとりあえず動いてるTFT-LCDモジュールをWBX280V009
という商品名で売ってるといった方が理解しやすいかと思います。
まぁ大陸系のお店やさんはえてしてこんな感じですので日本人同士だけの中で通じるような
理屈で買い物してるとえらい目にあいまくりです。
しかしながら中のコントローラがちゃんとILI9325なのは非常に良心的だと思います。
これがLGDP4531だとうごかなi(ry

それとねむいさんは某イベンツ向け用に液晶たくさん買い込んだけど中国某省
の5月にはぢまる催し物せいで上京できなくなって今現在使うあてが無くなった液晶
モジュールに囲まれて涙目なのですよｳｳｯ！
それとだれか(仕事はやめることなしに)自由に使える時間ください…

はぁはぁ…試される場合は今日の日付よく見た上で試してみてくださいね…

↓これは本当
いないさんは私の愛妹で
だーりんは私の旦那

2010.04.01 Thursday

08:05

ネムイ・トリノミアス

MISC

comments(4)

-

いろいろ試す4

少し前、imgの｢｣からメールをいただきました。ついにここまで刺客がきたかと
内心びびりまくってたのですが、そういった内容では全くなかったのでひと安心(おぃ
昔と比べて虹メが個人で動き回るということにだいぶ寛容になったのか、はたまた
いちいち目を光らせるのに飽きたのかはともかく、良い時代になったものですなぁ。
~~(いないさんのえろすフォルダを眺めつつ)~~

さて、先に述べた"メールの内容"というのはLPC2388向けのFreeRTOSデモのビルド
エラーの指摘のことだったのですけれども、少し前にCodeSourceryのバージョンが上
がったせいでFreeRTOS側のARM7依存部分にあるアセンブラマクロが通らなくなって
しまっていたのが原因です。現在配布されてるFreeRTOSV6.0.4以降では解消
されているのでそちらのソースと組み合わせてビルドするようにしてください。
ビルドで詰まってる人も多いようなのでこの情報は公表しときます。

●ARM関連とか
いつもの如く長い前ふりですがねむいさんがぼーっとしてるうちにも世間はものすご
いスピードで変わっていってます。Cortex関連もどんどん情報/ユーザーが多くなって
きましたがおまけについこの前もSTM32の新しいラインナップが追加されたりしてNXP
やATMELとさらにカチあう情勢になってきてますね～。まぁ一般に手に入るのはず～～
っと先でしょうから(これにはすごく期待している)今あるものを駆け足で消化
学習しつつリリースを待ちたいと思います。

STM32関連の話題をもう少し続けます。少し前にペリフェラルライブラリがV3.2.0に
なっています。今回はSTM32のValueLineの追加/CMSISのV1.3.0化とのことです。
そして案の定ライブラリのディレクトリ構成が変わってやがりましたので、こちらも
修正してメイクファイルに反映しました。ついでに言うとソース内のグローバル変数も
小変更されているので注意です。
現在おきばにて公開しているSTM32F107VCT/STM32 Primer2向けのソースはすべて
V3.2.0化してます。Primer2向けのFreeRTOSも古くなってますので近々更新予定です。

デバッグ環境も少し見直しました。前回の記事でやっけつVersaloonをこしらえたのです
がこれをSWDのデバッガ/ライタに機能を絞って(つまりほぼCortex専用)加工しました。
JTAGよりもとり回す線の数が少ないので、Cortex系の開発関連では重宝しそうです。

↑Etherpodとドッキング。ホントは画面奥にあるATXMEGA128A1とランデヴーさせる
　つもりだったのだが…。XMEGAの話はこの後に。

↑STM8SをRe-Discoveryして見た…
　(VersaloonはSTM8Sのファームも書けるから問題なし)。
　この写真撮った直後STM8S部分とは"Detached"になります。

●AVR関連とか
少し前からちょっとづつATXMEGA128A1に浮気を続けてますが、ようやくSDカード+FatFs
の動作までこぎつけました。

↑おっきぃがめんはよいものだ…。今回の小動物写真はこちらからお借りしてます。

http://www.flickr.com/photos/ruth1066/ / CC BY-NC 2.0

↑以前ARMで行った読み込みスピードの比較をXMEGAでも。
　比較用のファイルは当時と同じものです。

んで、FatFs用のSPIをDMA化させようとしてず～～～～～っと頑張ってきたのですが、
今現在のねむいさんの技術力ではどうしてもてなづけることができませんでした…orz
くやしい…でも…地道に経験を積んでいっていつかリベンジします！！！！

XEGAをいじってきた中で現時点で重要と思った点は…
1.VBAT端子が存在するXMEGAはATXMEGA256A3B等の末尾A3Bのデバイスに限られている。
　したがってATXMEGA128A1とかは外付けi2cなRTCの方が便利かも。
2.EBIに供給するクロックは64MHzまで設定できる。その時はPLLで64MHzのクロックを
　生成してEBIに、そのクロックをさらに1/2してCPUコアに供給する。
3.SPIはSlaveModeでしかDMAを利用できない。MasterでDMA使いたい場合
　はUSARTのMSPIモードを使う。MSPIモードの時もSPIと同じくSCLKは最大16MHz取れる。

こんな感じでしょうか…後に続く人が同じ部分で引っかからないように記録残しときます
現時点でのソースはこちらに…W.I.P.なコードなのでご利用は自己責任で～…。

FPGA基板を繋げる試み(3PORT-EBIで接続)は時間を見て引き続き試行していきますが、
浮気はもうやめて開発の主軸を再びARMに戻して行くつもりです。
Embedded ArtistsのARM9ボード注文しちゃったし！

2010.03.21 Sunday

13:50

ネムイ・トリノミアス

MISC

comments(2)

-

よりみち

開発上でいくつか大きな変更があったので、ちょっと寄り道させてもらいます。

先日、STマイクロより待望のUSBライブラリの新版がリリースされました。しかし…
残念ながらUSB-HOST/OTGのサンプルはないっぽいorz。しばらく海外のForumを
旅して
きますか…。

既存のプログラムの動作の確認は、先にリリースされていたRC版で予習済なので今回
のライブラリをフォルダごとごっそり差し替えるだけで終わっています。
もちろん動作も確認済。

そして先に告知していましたがSTM32F103のMiddleDensity系は今回の更新で
クローズ、あとSTM32F107VBTの方はSTM32F107VCT6と統合するので削除とします。
これから先はSTM32F107VCT6とSTM32Primer2(STM32F103VET6)を中心に開発を
進めていくつもりです。
また、おきばの方も近々リニューアルする予定です。

それともう一点、いつもARMマイコンのビルドに使っているCodeSourcery G++が
バージョンアップしてGCCが4.4.1に変わっていました。以前3系->4系に
変わったときに最適化のされ過ぎでビルドが通っても思ったよう動かない
等の問題があったので試しにいくつかのプログラムをビルドして動かして
みると案の定変な動作するものが出てきました。

具合的に言うとLPC2388のプログラムでswitch文を含むコードを最適化して実行すると
暴走する箇所があり、原因を調べるとリンカスクリプト内のアラインメントの
設定でした。
これは元々AT91R40708でRAMスタートするときに行っていた処置で,.text内の記述で
. = ALIGN(4);であるところを
. = ALIGN(8);としていました。
それを他にもツブシがきくようにと別のARMマイコンのリンカスクリプトにも移植
してその時の環境では動作に問題なかったため放置していましたがこれがあだに
なってしまっていたようです。
それらは". = ALIGN(4);"に直して無事正常動作を確認しました。

ビルド環境がバージョンアップしたり変わったりするとよくこういうことになりが
ちですが,こまめに直していかないといけないですね…。

2009.11.14 Saturday

14:28

ネムイ・トリノミアス

MISC

comments(0)

-

いろいろ試す3

ハロウィンネタ&他のキャラの誕生日お祝いネタの仕込みで本業(二次裏)が糞ほど忙しく
なってます。しばらくこっちは更新できそうもないので今のうちに書けることを…。

●この前のTFT液晶の在庫数が
一気に減ってたaitendoさんの900円液晶、私がこのブログに使用記を公開したあたりから在庫数が一気に
減ってました。皆様子見だったのですね～…。
もうじき在庫ゼロになりそうな勢いです。
私はLPC2388向けにサンプルコードを公開してましたが、STM32はUSBライブラリが(ry
のおかげでまだ二の足踏んでます。まぁRCは出てるから時間の問題とは思いますが…。

あとSTマイクロ側がUSB-OTGのデュアルロール機能のサンプルとか公開してくれたら
神なんですけお…USBホスト関連のスタックは今でもそれ作るだけでお金になる
ようだから無対価で手に入るの(=枯れる)はずっと先になりそうです。

●STM32F107でUSB_DFU_Bootloader使う件
んでもって前回行ったSTM32F107/5系のブートローダーが機能しない件の回避策
ですが、ねむいさんはブートローダーをDFU一本に絞ることにしました。
したがって以後は下図のような構成でマイコン遊びを続けていきたいと思います。

20091102変更:
BOOT0とBOOT1を取り違えるという最悪なミスに気づいたので修正orz
20091216変更:
PB5は10kohmでも問題ないことが分かり修正orz
STM32F103系と違ってdfu使うための領域とかスタートアップの設定とかを
気にしなくてよくなったのは良い点だと思いますね。errataさえなければ！

●シンプルi2cマスタライブラリ
ライブラリ固め
 AVRでの使用例とか
 LPC2388での使用例とか

●OpenOCDのビルド方法が少し変わった
現在、zus氏のOpenOCDのビルド方法をそのままやるとビルドエラーで失敗します。
svnからgitに変わったのでgitで最新のソースを落とせとのこと。
gitでの取得のコマンドはsvnと微妙に違って
git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
だそうです。けっこう時間かかります。

んでもっていつものフラッシュ書き込みやってみました。
STM32F107VCT6の例です↓

> "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey.cfg -f C:/Devz/ARM/OCD/tcl/target/stm32_flash.cfg -c "mt_flash main.elf" Open On-Chip Debugger 0.3.0-dev-00405-g1e5daf5-dirty (2009-10-22-11:15) $URL$ For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html 1000 kHz jtag_nsrst_delay: 100 jtag_ntrst_delay: 100 trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain Warn : stm32.bs: nonstandard IR mask Warn : use 'stm32.cpu' as target identifier, not '0' Info : device: 4 "2232C" Info : deviceID: 67358712 Info : SerialNumber: 11111111A Info : Description: Amontec JTAGkey A Info : clock speed 1000 kHz Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0) Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x080061a4 msp: 0x20010000 Info : device id = 0x10016418 Info : flash size = 256kbytes stm32x mass erase complete Info : Padding image section 0 with 0 bytes Warn : not enough working area available(requested 16384, free 16336) wrote 95952 byte from file main.elf in 5.906250s (15.865079 kb/s) verified 95952 bytes in 1.921875s Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0) > Process Exit Code: 0 > Time Taken: 00:10

…OpenOCD+Jtagkeyをほとんどフラッシュ書き込み機としか使っていない私。

●FreeRTOSがV6.0.0になってた
なってました。私が使用しているMCUには特に大した変更の影響はないみたいですが…。
いまはSTM32F107VCT6に重点的になっててLPC2388の更新したのずいぶん前に
なっちゃってましたので動作確認がてらにソースの見直しをしました。
LPCUSBを使用したUSB-CDCのソースコードも一本化して可搬性あげるよう
努めてます。
他のMCUにも言えることですがBare-MetalとFreeRTOSで分けていたソースは
#define切って同じファイル使いまわせるように直していくつもりです。
今見返すとつぎはぎだらけでひどかったorz
LPC2388用FreeRTOSのサンプル

LPC2388もある程度遊んだらクローズしてSTM32に集中したいです。今後はSTM32にFreeRTOSの組み合わせが日記のネタの要になるでしょう。

●STM32 Primer2の電源ICがすぐぶっこわれて云々の件
私が検証記事を載せた数日後に公式も同様な見解を述べています。
ううむ、私の読みが完全に当たってしまった…ってわけですか…。
電源IC壊れちゃった人はこの際私みたく別のLDOに変えちゃうのもいいかもしれま
せんね…。(もちろん自己責任で)

2009.10.22 Thursday

22:13

ネムイ・トリノミアス

MISC

comments(0)

-

XBeeを試す

気がつけばもう8月…月日が経つのは早いです。私はと言えば先日虹裏でスレを立てた
直後に寝堕ちという不名誉な最短記録をおっ立ててしまい軽い自己嫌悪に陥ってました。
それでも参加してくれた皆さんには本当に申し訳ないと思います。お詫びにいなちゃん
があっちの皆さんに目の保養をさせていただくことになるでしょう…
(これ目的でわざとやってるわけじゃないよ！)

5月に買ったおもちゃ達もだいぶ消化出来てきました。残りは今回紹介するXBeeと、
ねむいさんがやるやる詐欺でほったらかしてきたAT91SAM7S256のプロトボードを残す
のみとなｒまた前振り長くなりそうだからさっさと本題

現時点では、スイッチサイエンスさんと秋月さんから容易に購入出来る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)。バッテリーで使うならデータフロー制御
よりこちらの電力制御の方が最優先でしょう。

2009.08.06 Thursday

23:55

ネムイ・トリノミアス

MISC

comments(0)

-

いろいろ試す２

LPC2000系って海外の掲示板に情報わんさかあるから詰まった時はそっち見た方が速か
ったりして解決した瞬間にあんだけ足止め食らったのはなんだったんだと自分のア●さ
加減を恨んだりすることも毎度のこと…。
まぁお気楽ご気楽なアマチュアであっても情報戦マジ大事と感じる次第ですなぁ(ｷﾘｯ
…ねむいさん的には本文と関係ない与太話書いてる時が一番楽しいです。

苺は抜きで。
IF誌に載ってたOLED表示プログラムの方も同じ修正を施しました。
最終的には全部の機能合体できたらいいなと考えてます。

おまけ
前回製作したLAN基板にmicroSDカードスロット(165円)つけました。これで死角は無し！

●JTAGkeyをimpactから使う
FT2232を使用したJTAGデバイスは自作方法が急速に広まっています。しかしそれにつ
れて「作ったけど動かない&動かし方がわからない！」云々の叫びが谺してるような
気がします。きっと空耳でしょう。
私はかみき氏ベースのJTAGKey互換回路(+VID&PIDもAmontecのと全く同じ)組んでるの
で幸いデバッガ周りではほとんど躓いたことはないです。

…それは置いといて前にMAI電子さんから破格値で販売されているxilinxのFPGAボード
を運よく購入できました。DWM誌2007年7月の付録のよりも容量が２倍多いです。

早速JTAGでアクセスしてデバイスが見えるかどうか試してみました。
アクセス方法はFenrir氏が作成されたcblsrvのJTAGkey(と互換回路)対応版を使用して
impactのcableserver経由で行います。

Fenrir氏やNakagawa氏が公開されている物は私の環境(ゲストOS:Win2000、ホストOS:XPPRO,
VirtualBox使用)では残念ながらそのままでは動作しなかったので、Nakagawa氏が盛り込ん
だ修正の中でビットシフトしている部分だけ外して動作出来るようにしてます。
(こうやらないと動かないのは私の環境だけでしょう)。

認識するとこんな感じです。

書き込みも非常にスムーズ。もうLPTポートは要らない！？

cblsrv経由で使用できるのはバウンダリスキャンモードだけっぽいです。コンフィグ
ROM・FPGAへの書き込みだけならば速度も速いし(XCF04Fで50秒前後)これで充分。
このボード使って某デジットのタッチパネル液晶とか駆動できるようにしたいです。
VHDLのおべんきょｇ(ry

●OpenOCDのリビジョンが既に2570まで達していた(2009.07.30現在)
安定版は0.2.0が公式からリリースされています…がftdlのライセンスの絡みで実行
形式バイナリは公開されていません。0.1.0のバイナリも削除されています。
これからは自分で構築しなければならないようですね…非常にめんどい…。

OpenOCDは現在加速度的なスピードで開発が進められています。ネットで散見される
ARM系の開発環境構築法にはOpenOCDの設定・使用法も記されていますがあっという間
に陳腐化してしまって書いてるとおりにやるとうまくいかないこともあるようです。
OpenOCD使いこなしてる人はどのようにして風が吹いて桶屋がもうかるのかを理解し
てるでしょうからcfgなり何なりを変えるだけで対処できるでしょうが…初めて
触れる人には新しい情報と古い情報がごっちゃになってて非常に敷居が高く感じて
いるかと思います。ﾅﾑﾅﾑ。がんばれよ！(←他人事)

とりあえず2009.07.30現在一番新しいr2570のを試してみました。手持ちの幾つかの
ARM基板でフラッシュの書き込みができたのを確認しました。
(注：cfgファイルはOpenOCDの世代交代によってどんどん変わっています。そのままでは
使えないものもあるので十分吟味のこと)

-LPC2388の場合

> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown" Open On-Chip Debugger 0.3.0-in-development (2009-07-28-19:41) svn:2570 $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS 500 kHz jtag_nsrst_delay: 100 jtag_ntrst_delay: 100 dcc downloads are enabled 500 kHz Info : device: 4 Info : deviceID: 67358712 Info : SerialNumber: 11111111A Info : Description: Amontec JTAGkey A Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) Info : JTAG Tap/device matched Warn : EmbeddedICE version 7 detected, EmbeddedICE handling might be broken 100 kHz Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) Info : JTAG Tap/device matched Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) Info : JTAG Tap/device matched Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset. target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x000000d3 pc: 0x00000000 500 kHz flash 'lpc2000' found at 0x00000000 auto erase enabled Info : Padding image section 0 with 0 bytes Warn : Verification will fail since checksum in image(0x00000000) written to flash was different from calculated vector checksum(0xb8a06f60). Warn : To remove this warning modify build tools on developer PC to inject correct LPC vector checksum. wrote 98756 byte from file main.elf in 6.125196s (15.745032 kb/s) > Process Exit Code: 0 > Time Taken: 00:09

-STM32F103VBT6の場合

> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey.cfg -f C:/Devz/ARM/OCD/tcl/target/stm32_flash.cfg -c "mt_flash main.elf" Open On-Chip Debugger 0.3.0-in-development (2009-07-28-19:41) svn:2570 $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS 1000 kHz jtag_nsrst_delay: 100 jtag_ntrst_delay: 100 Info : device: 4 Info : deviceID: 67358712 Info : SerialNumber: 11111111A Info : Description: Amontec JTAGkey A Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG Tap/device matched Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1) Info : JTAG Tap/device matched Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG Tap/device matched Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1) Info : JTAG Tap/device matched target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x08001ec0 msp: 0x20005000 Info : device id = 0x20016410 Info : flash size = 128kbytes stm32x mass erase complete Info : Padding image section 0 with 0 bytes Warn : not enough working area available(requested 16384, free 16336) wrote 8508 byte from file main.elf in 0.515641s (16.113136 kb/s) verified 8508 bytes in 0.421888s Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG Tap/device matched Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1) Info : JTAG Tap/device matched > Process Exit Code: 0 > Time Taken: 00:03

-AT91SAM7S256の場合

> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey.cfg -f C:/Devz/ARM/OCD/tcl/target/sam7x256_flash.cfg -c "mt_flash main.elf" -c "reset run" -c "shutdown" Open On-Chip Debugger 0.3.0-in-development (2009-07-28-19:41) svn:2570 $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS dcc downloads are enabled fast memory access is enabled Info : device: 4 Info : deviceID: 67358712 Info : SerialNumber: 11111111A Info : Description: Amontec JTAGkey A Info : JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3) Info : JTAG Tap/device matched 5 kHz target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x60000013 pc: 0x001005f4 2000 kHz background polling: on TAP: sam7x256.cpu (enabled) target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x60000013 pc: 0x001005f4 flash 'at91sam7' found at 0x00100000 cleared protection for sectors 0 through 15 on flash bank 0 auto erase enabled Info : Padding image section 0 with 3 bytes wrote 3636 byte from file main.elf in 1.468797s (2.417476 kb/s) verified 3633 bytes in 0.109378s Info : JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3) Info : JTAG Tap/device matched > Process Exit Code: 0 > Time Taken: 00:04

JTAGでフラッシュに書けるようにしとくと何かと便利ですね～。とくにJTAGkey(と互換回路)
はARMだけでなく先にも述べたとおりFPGAの書き込み等にもいろいろ使用できるので
アマチュアな人たちには必携のアイテムだと思います。

これAVRSPライクなアプリから操作してAVRに書き込みできるようになったら私的
には最強のツールになるのだが…。

●Intel X25-M(新型)を買った
購入して数日で不具合が発覚して涙目ですorzさらに4日間OSのシステムドライブと
して使用した後ベンチを取るとランダムライトの(512k,4k)速度が大きく落ち込んでい
るのが発覚orz

購入直後

4日後

X25-Mの速度低下現象は以下の手順で確実に回復(端的に)。
１．ドライブのバックアップ取る。(バックアップツールはこれ使ってます)
２．AHCI->IDEモードに切り替え、生DOSからHDDeraseのSecure Erase(enhanced)実行
３．電源断->再投入後AHCIに戻しさらにバックアップを復元する
４．わーい♥

ファームの修正で速度低下を恒久的に防止できるようになると良いですね(涙目で)

2009.07.31 Friday

00:51

ネムイ・トリノミアス

MISC

comments(0)

-

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のそれは各社のノウハウになっていて真似して自作できる
代物ではなくなってしまいました。
しかも安くても３諭吉くらいしてホビー用途には手が出しづらい。

しかしながら数年前くらいから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基板を高速にコンフィグ

fenrir氏作成のcblsrvのFT2232対応版を使用してxilinx IMPACTからコンフィグ
(注：fenrir氏によってISE11.x以降でも使えるようになりました！)

そして本懐のamtsvfplayerでSVFを再生…できねぇ！
20120215追:
amtxhal.dllはグルーロジック(非公開)が組まれたPORTB側のDS2432という
EEPROMに仕込まれたキー情報も読みに行っているのでクローンの場合は
amtxhal.dllを使用するプログラムは一切使えなくなります…が
amtsvfplayerくらいしか使われてるの見たことないのでJTAGkeyCloneでも
それ以外の用途では全く問題はありません。
JTAGkey系のCloneでsvf使いたいならUrJTAGを使いましょう。

2009.05.16 Saturday

13:57

ネムイ・トリノミアス

MISC

comments(0)

-

<< November 2024 >>

Sun Mon Tue Wed Thu Fri Sat

1 2

3 4 5 6 7 8 9

10 11 12 13 14 15 16

17 18 19 20 21 22 23

24 25 26 27 28 29 30

ネムイ・トリノミアス

Foreign Visitors,See This First

免責・連絡先は↑のリンクを

ChaN's FatFs Projects and
OpenOCD Binary are Here.
おきぱはここ！

↓SNSもやってます↓

powered by まめわざ

このブログ内の記事を検索

ARM/STM32 (116)

OpenOCD (27)

ARM/NxP (34)

ARM/Cypress (5)

ARM/Others (3)

ARM/Raspi (1)

AVR (13)

FPGA (4)

GPS/GNSS (19)

MISC (81)

STM8 (2)

Wirelessなアレ (16)

おきぱ (1)

ブラウザベンチマーク (28)

日本の自然歩道 (25)

STM32U0はぢめました
⇒ ねむい (08/07)

STM32U0はぢめました
⇒ ひかわ (07/28)

STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ ねむい (05/17)

STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ どじょりん (05/16)

STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ どじょりん (05/16)

いろいろ試す61(と今年の反省会)
⇒ ねむい (01/02)

いろいろ試す61(と今年の反省会)
⇒ ひかわ (01/02)

いろいろ試す61(と今年の反省会)
⇒ ひかわ (01/01)

STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ ねむい (12/31)

STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ ひかわ (12/31)

October 2024 (1)

September 2024 (1)

August 2024 (1)

July 2024 (1)

June 2024 (1)

May 2024 (1)

April 2024 (1)

March 2024 (1)

February 2024 (2)

January 2024 (1)

December 2023 (4)

November 2023 (2)

October 2023 (2)

September 2023 (1)

August 2023 (2)

July 2023 (1)

June 2023 (2)

May 2023 (3)

April 2023 (1)

March 2023 (1)

February 2023 (1)

January 2023 (1)

December 2022 (2)

November 2022 (1)

October 2022 (1)

September 2022 (1)

August 2022 (1)

July 2022 (1)

June 2022 (1)

May 2022 (1)

April 2022 (1)

March 2022 (1)

February 2022 (1)

January 2022 (1)

December 2021 (2)

November 2021 (2)

October 2021 (1)

September 2021 (1)

August 2021 (1)

July 2021 (1)

June 2021 (1)

May 2021 (1)

April 2021 (1)

March 2021 (1)

February 2021 (1)

January 2021 (1)

December 2020 (3)

November 2020 (1)

October 2020 (1)

September 2020 (1)

August 2020 (1)

July 2020 (1)

June 2020 (2)

May 2020 (1)

April 2020 (1)

March 2020 (1)

February 2020 (1)

January 2020 (1)

December 2019 (3)

November 2019 (1)

October 2019 (1)

September 2019 (2)

August 2019 (1)

July 2019 (1)

June 2019 (1)

May 2019 (1)

April 2019 (1)

March 2019 (1)

February 2019 (1)

January 2019 (1)

December 2018 (3)

November 2018 (2)

October 2018 (1)

September 2018 (1)

August 2018 (1)

July 2018 (1)

June 2018 (1)

May 2018 (1)

April 2018 (2)

March 2018 (1)

February 2018 (1)

January 2018 (1)

December 2017 (2)

November 2017 (2)

October 2017 (1)

September 2017 (1)

August 2017 (1)

July 2017 (1)

June 2017 (1)

May 2017 (1)

April 2017 (1)

March 2017 (2)

February 2017 (2)

January 2017 (2)

December 2016 (7)

November 2016 (2)

October 2016 (2)

September 2016 (1)

August 2016 (1)

July 2016 (1)

June 2016 (1)

May 2016 (2)

April 2016 (1)

March 2016 (2)

February 2016 (1)

January 2016 (1)

December 2015 (3)

November 2015 (1)

October 2015 (3)

September 2015 (2)

August 2015 (2)

July 2015 (3)

June 2015 (3)

May 2015 (4)

April 2015 (2)

March 2015 (4)

February 2015 (1)

January 2015 (3)

December 2014 (3)

November 2014 (2)

October 2014 (1)

September 2014 (2)

August 2014 (2)

July 2014 (3)

June 2014 (2)

May 2014 (1)

April 2014 (1)

March 2014 (4)

February 2014 (4)

January 2014 (3)

December 2013 (5)

November 2013 (4)

October 2013 (3)

September 2013 (2)

August 2013 (2)

July 2013 (2)

June 2013 (3)

May 2013 (2)

April 2013 (2)

March 2013 (2)

February 2013 (2)

January 2013 (3)

December 2012 (4)

November 2012 (2)

October 2012 (2)

September 2012 (4)

August 2012 (1)

July 2012 (3)

June 2012 (2)

May 2012 (3)

April 2012 (3)

March 2012 (2)

February 2012 (3)

January 2012 (3)

December 2011 (5)

November 2011 (3)

October 2011 (2)

September 2011 (2)

August 2011 (2)

July 2011 (2)

June 2011 (2)

May 2011 (2)

April 2011 (2)

March 2011 (2)

February 2011 (2)

January 2011 (3)

December 2010 (7)

November 2010 (1)

October 2010 (1)

September 2010 (1)

August 2010 (3)

July 2010 (4)

May 2010 (1)

April 2010 (2)

March 2010 (2)

February 2010 (2)

January 2010 (3)

December 2009 (3)

November 2009 (8)

October 2009 (7)

September 2009 (5)

August 2009 (4)

July 2009 (6)

June 2009 (6)

May 2009 (14)

January 1970 (1)

RSS1.0

Atom0.3

びぃぶろぐ

<< November 2024 >>
Sun	Mon	Tue	Wed	Thu	Fri	Sat
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30