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で
一切アクセスできなくなってフラッシュが書き換えできなくなってしまった。責任とっ
てこさえた基板言い値で全部買い取れ。
->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で攻撃された時です。
あといないさんのおぱんつ画像でも一発で死にますので絶対に見せたりしな
いでください絶対ですよ絶対!!1!1
●ねむいさんの手順の通りにしているけど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ぶっ挿して一ビットずつ対策方法焼き
こんでくから」…って私言いましたよね!?
STM32F4シリーズを使ってみる6 -giflibを実装する-
前回はlibpngを実装してTFT-LCDに表示を行いましたが、今回は同じく現在でも
多用されているgif形式の画像がデコードできるgiflibをSTM32F4に実装し、さらに
アニメーションgifのTFT-LCD上においての再生も成功しました。
●あらまし
giflibはlibungifを前身に持ち、LZWというアルゴリズムでエンコード・デコードを
行います。ご存知の方は多いと思いますがそのパテントを持っていたUnisys社により
一時はgifフォーマットがあまり使われていなくなっていた時期がありました
(代わりのフォーマットとしてpngが出てきました)。
2012年現在はそのパテントの期限も切れて自由にLZWが利用できるに至っています。
gifフォーマットはpngと比べて256色までしか表現できませんが、アニメーションgif
として今でも現役で使用されています。ことさら私たち虹裏メイドに関しては、
ファイルのアップロードに500kByteの制限がある虹裏の板の仕様上pngと並んで
アニメーションを表現するのに非常に重要な形式であり、これをSTM32F4に代表される
大規模マイコンに移植し表示せしめることは最早宿命とも言えます!
STM32F4への実装と動作の理解の助けとして、yoya氏のwikiを参考にさせて
いただきました。ありがとうございます!
●必要なもの
giflib
今回は出来たてホヤホヤのgiflib-5.0.0を使用します。
●ファイルI/O
libjpegやlibpngと同じようにFatFsのAPIを差し替えりゃ簡単…とはまったく言えず、
PC向けにファイルI/Oが特化されたgiflibをChaNさんのFatFsの流儀に嵌めるまでは
かなり試行錯誤を強いられました。最終的にDGifOpenFileHandle()内はFatFs完全特
化する形で書き変えてしまいました。
●makefileに追加するCソースファイル
デコードするためには最低限下記ファイル群が必要です。
dgif_lib.c
gif_err.c
gif_font.c
gif_hash.c
gifalloc.c
quantize.c
dgif_lib.cに関しては一部内容の書き換えが生じます(後述)
dgif_lib_fatfs.cとリネームしておいてください。
●ARMマイコン上で動作させるための少しの変更
FatFsのAPIに当てはめるため、幾つかの変更を強いられます。
dgif_lib_fatfs.c
->"/* Nemui Changed */"の変更・削除した部分を参照してください。
gif_lib.h
->ff.hをインクルードしてください。
->178行目のプロトタイプ宣言は以下に変更してください
GifFileType *DGifOpenFileHandle(FIL* fp, int *Error);
gif_lib.h
->ff.hをインクルードしてください。
●gif(アニメーション)を表示する
多くのアニメーションgifではインターレースがどれかのフレームで使用されて
いたため、インターレースの表示ルーチンも実装しました。giflibにあったexampleを
見れば特に困ることはありません。
もちろん表示スピードは落ちますが透過表現も実装してます。
また、実際の表示に関してはRAMの少ないマイコン上の話なので一列ずつ表示
することになります。この時に消費されるRAMはベースで28672Byte(デバッガの
追跡により算出)と一列ごとのピクセル数*3です。
だいたいlibpngより少し少ない量になりますね。
しかしながら、320x240サイズのちょっと大きめでフレーム数が多いgifアニメー
ションは再生中にもメモリ要求量が増大していき、総量で70kByte近く消費しました。
libpngも大きい画像サイズの奴をデコードしようとすると65kbyte程使うように
なりますがそれより多いのです。
というわけで専ら大容量の内蔵SRAMが使用できるFM3・STM32F2&F4ですね〜。
デコードされたRGBデータは8+8+8の24ビットの形式となっているため、565の
16bitにしてTFT-LCDにデータを書き込みます。
グローバルカラーマップとローカルカラーマップの判別もこの段階で行います。
そして動かしたところです…
(gifファイルはとしあき&「」作の物を使わせてもらいました!)
↑写真が静止画なので分からないと思いますがgifアニメーションが動いてます。
アンドリューW.K.さん(キャラクターが)いいよね…
↑gifアニメーションの最終フレームまで来たら停止します(ループはしません)。
ちなみにgifの仕様上ディレイ時間は10mSec区切りとなるので実装時は適切な
時間のディレイを生成する必要があります。
また、私の表示プログラムでは最終フレームまで行かなくても途中で各入力を
行うことによりファイラに強制的に戻ることができます。
↑STM32F2でも動く!当たり前ですが…
…STM32F1はRAM容量的に流石にきつかったので抜きで。
↑FM3マイコンでももちろん動きます!
ということで今回の成果はおきぱのSTM32F4,F2,FM3のFatFs移植例に
すでに反映しています。前回も少し触れましたが、私が使わせてもらている各
ライブラリ・プログラム・フォントのライセンス表記についてもきちんと明記する
ようにしていくようこころがけています。
おまけ
またまた買ってしまった(写真奥)…これからは解像度320x480で小型なTFT-LCDの
時代です!手前のaitendoさんで売ってるのより一回り小さいやつで、コントローラICは
HX8357Aです。今回のいつものの更新ではこちらの液晶にももちろん対応させています。
大きさも3インチと一回り小さいので出来あいLCD基板にちょうど乗ります♥
XMEGAを使ってみる5 -FatFsのDMA化-
AVRマイコンの進化形であるXMEGA。ねむいさんの偏見ですがこれを触った
人たちの殆どが以下の運命を辿ってる気がしなくもなくもなくもないです…。
1.XMEGAが手に入りました(^^)DMAやDACが使えるので楽しみです。
↓
2.ChaNさんのFatFsが動きました(>▽<)次はDMA化してみます(^^)
↓
3.XMEGAではSPIはスレーブしかDMAをサポートしてないみたいですね〜
UARTのMSPIモードでしかマスタでDMAができないようです(@o@)
いやはやデータシートはしっかり見なくては(^^;
(↑流し読みしないで初めからちゃんと見ろ!)
↓
4.(XMEGA関連の更新が途絶え、関係ない記事ばっかりになる)
↓
5.(息してない)
↓
6.おや?スライムたちが集まって…?
↓
7.
↑こちらのサイトでこの文字を作らせていただきました!
…なんでねむいさんのほうを見る!?
といつもの戯言はこの辺にして以前挫折して放り投げていたXMEGAにおける
FatFsのDMA化、ねむいさんもついに成功しましたのでご報告します。
ain氏のXMEGAのDMA転送に関する記事が大きなヒントになったわけですが、
SPIは送信と受信が対になっていて「(SPIマスタで)データを得たければ先ずは送信せよ」
というのが頭で固まってしまっていてずっとTxからDMAの初段をキックしていました。
まさかRxからキックを開始しなければ転送が成立しないなんて思いもしなかったので
目からうろこでした…。ホントにあとちょっとのところだったのに投げ出して
しまったのか私orz
…と後からいくらでもなんとでも言えるのでまぁ無事動いたから良しとしましょう!
ファイルの読み出し速度の比較を行ってみました。
↑DMAを使用しないベタな転送の時
↑DMA転送時
実験に使用したSDカードはSTM32の時に使っている物と同一です。
STM32F1でSPIのクロックが18MHz時のDMA転送では2100kByte/Sec程出ていました
が、XMEGAにおいて許容されるSPIクロックは16MHzまでとなります。そこから単純に
逆算すると、1800kByte/Sec近く出ることになります。DMA転送前の前処理等での
時間ロスを考慮すれば1500kByte/Secという値はある納得できるものだと思います。
これ以上転送速度を上げようと思ったらオーバークロックをするか、ダブルバッファ
リングで効率化を図る等が必要になるでしょう。同氏の記事にはそれらに加えて
ペリフェラルも合わせてDMAで動かすときの考察もされており非常に参考になります。
というわけで私のおきぱにあるXMEGAのプロジェクトも今回のDMA転送のサポートを
加えて更新しておきました。なんとうかずっと残っていた胸の突っかかりが取れたような
気分でほっとしております♥
また、トップにもたびたび告知していますが、今回の更新から私が使用させてもらって
いる他の方のライブラリやソフトのライセンスの表記について、ソースが入っている
Zipファイルに各コピーライト、ライセンスを記したテキストファイルを同梱し明確化
していくようにしました(ホント今更ですが…)。
もちろん私のSTM32等のプロジェクトも同様の整備を広げていくしていく方針です。
-
免責・連絡先は↑のリンクを
↓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)
- 日本の自然歩道 (26)
- 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)
- November 2024 (1)
- 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)
Copyright(C) B-Blog project All rights reserved.