OpenOCD小ネタ17 -CMSIS-DAPに本来の力を-



まずはこのぶろぐのアクセス数推移のグラフを見ていただきい。

東海自然歩道関連の記事の更新も一区切りが着き、OpenOCDの解説に力を
入れはじめた(中央矢印)とたんにアクセスがガタ落ちになっていますorz

"わかりやすい解説をしていただけるとありがたいです"との多数の要望を
受け始めたOpenOCD小ネタですが、ねむいさんがこちらでやったアドバイスが
効き過ぎて皆CoIDEとかに移ってしまった模様ですが、これはこれで(開発環境の
整備ごときに)無駄な時間浪費するような被害が減ってよかったのではないか、
ねむいさんは安心して近畿自然歩道とか東海自然歩道の記事更新をしまくれば
みんな幸せになれるんじゃないかなぁと思いましためでたしめでたし。





























で終わってもあまりめでたくないので2015年度はちょっと毛色を変えてくどい
解説は極力排除して面白おかしく斜め45度に傾いた記事を書いていくポリシーを
取っております。

ていうわけで本題です！

●CMSIS-DAP(を制御する側)パワーアップ大作戦
現在ではCortex-Mxコアのデバッグに欠かせなくなったCMSIS-DAPですが昨年より
OpenOCDからも使用可能となっています。しかしながらOpenOCD側の実装と
CMSIS-DAPが使用しているUSBのHIDクラスの関係上フラッシュ書き込み速度が
USBハイスピード接続でもMAXで2kByte/Sec程度しか出ない、LPC11U35版の
ファームにいたっては0.8kByte/Sec以下まで書き込みスピードが落ちるという
極めて不利な弱点がありました。

昨年の秋口からこのﾁﾏﾁﾏ書き込みしか利用できないOpenOCD側の実装を何とか
しようとあの手この手のアイデアが議論され、書き込み命令をキューイング
してCMSIS-DAPに元から実装されていたが使用されていなかったブロック転送
コマンドで一気にドカンと転送する作戦が取られました。
CMSIS-DAPの元となるファームウエアは同じながらも各ベンダ間で独特の癖が
ある拡張に苦戦しましたが、今春ようやく殆どの問題が解消され正式にマージされる
運びとなりました。


説明はこれくらいにして早速威力を見てもらいましょう。
テストで使用した基板はLPC1549Xpressoです。
これにはUSBハイスピードで繋がるLPCXpressoV2ハードウエアが載っています。

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

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc1549_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.9.0-dev-00314-g90ae846-dirty (2015-03-01-09:33)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'cmsis-dap'

none separate

cortex_m reset_config sysresetreq

adapter speed: 1000 kHz

Info : CMSIS-DAP: SWD  Supported

Info : CMSIS-DAP: JTAG Supported

Info : CMSIS-DAP: Interface Initialised (SWD)

Info : CMSIS-DAP: FW Version = 1.0

Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1

Info : DAP_SWJ Sequence (reset: 50+ '1' followed by 0)

Info : CMSIS-DAP: Interface ready

Info : clock speed 1000 kHz

Info : IDCODE 0x2ba01477

Info : lpc1549.cpu: hardware has 6 breakpoints, 4 watchpoints

target state: halted

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

xPSR: 0x01000000 pc: 0x030000b8 msp: 0x02001fe0

auto erase enabled

wrote 8192 bytes from file main.elf in 16.749893s (0.478 KiB/s)

verified 8172 bytes in 4.593720s (1.737 KiB/s)

shutdown command invoked
↑変更前
> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc1549_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.9.0-dev-00357-g09ca5af-dirty (2015-03-31-00:00)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'swd'

none separate

cortex_m reset_config sysresetreq

adapter speed: 1000 kHz

Info : CMSIS-DAP: SWD  Supported

Info : CMSIS-DAP: JTAG Supported

Info : CMSIS-DAP: Interface Initialised (SWD)

Info : CMSIS-DAP: FW Version = 1.0

Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1

Info : CMSIS-DAP: Interface ready

Info : clock speed 1000 kHz

Info : SWD IDCODE 0x2ba01477

Info : lpc1549.cpu: hardware has 6 breakpoints, 4 watchpoints

target state: halted

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

xPSR: 0x01000000 pc: 0x030000b8 msp: 0x02001fe0

auto erase enabled

wrote 8192 bytes from file main.elf in 0.578121s (13.838 KiB/s)

verified 8172 bytes in 0.140624s (56.750 KiB/s)

shutdown command invoked
↑変更後
同じUSB2.0ホストで試しましたがご覧のとおり約10倍以上速くなってますね♥
> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc1549_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.9.0-dev-00357-g09ca5af-dirty (2015-03-31-00:00)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'swd'

none separate

cortex_m reset_config sysresetreq

adapter speed: 1000 kHz

Info : CMSIS-DAP: SWD  Supported

Info : CMSIS-DAP: JTAG Supported

Info : CMSIS-DAP: Interface Initialised (SWD)

Info : CMSIS-DAP: FW Version = 1.0

Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1

Info : CMSIS-DAP: Interface ready

Info : clock speed 1000 kHz

Info : SWD IDCODE 0x2ba01477

Info : lpc1549.cpu: hardware has 6 breakpoints, 4 watchpoints

target state: halted

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

xPSR: 0x01000000 pc: 0x030000b8 msp: 0x02001fe0

auto erase enabled

wrote 8192 bytes from file main.elf in 0.468747s (17.067 KiB/s)

verified 8172 bytes in 0.124999s (63.844 KiB/s)

shutdown command invoked
ちなみにUSB3.0ホストだとさらに早くなります♥


LPC824MAXやトラ技ライタのCMSIS-DAPで使用されているLPC11U35はフル
スピードまでで、尚且つメモリリソースがかなり少ないながらもキューイングの
恩恵に多少あやかることができ、こちらもパフォーマンスの若干の向上が見られました。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc82x_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.9.0-dev-00314-g90ae846-dirty (2015-03-01-09:33)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'cmsis-dap'

none separate

cortex_m reset_config sysresetreq

adapter speed: 1000 kHz

Info : CMSIS-DAP: SWD  Supported

Info : CMSIS-DAP: Interface Initialised (SWD)

Info : CMSIS-DAP: FW Version = 1.0

Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1

Info : DAP_SWJ Sequence (reset: 50+ '1' followed by 0)

Info : CMSIS-DAP: Interface ready

Info : clock speed 1000 kHz

Info : IDCODE 0x0bc11477

Info : lpc82x.cpu: hardware has 4 breakpoints, 2 watchpoints

target state: halted

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

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

auto erase enabled

wrote 8192 bytes from file main.elf in 10.484308s (0.763 KiB/s)

verified 7948 bytes in 0.640621s (12.116 KiB/s)

shutdown command invoked
↑変更前
> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc82x_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.9.0-dev-00357-g09ca5af-dirty (2015-03-31-00:00)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'swd'

adapter speed: 10 kHz

adapter_nsrst_delay: 200

cortex_m reset_config sysresetreq

adapter speed: 1000 kHz

Info : CMSIS-DAP: SWD  Supported

Info : CMSIS-DAP: Interface Initialised (SWD)

Info : CMSIS-DAP: FW Version = 1.0

Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1

Info : CMSIS-DAP: Interface ready

Info : clock speed 1000 kHz

Info : SWD IDCODE 0x0bc11477

Info : lpc8xx.cpu: hardware has 4 breakpoints, 2 watchpoints

target state: halted

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

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

auto erase enabled

wrote 8192 bytes from file main.elf in 4.718719s (1.695 KiB/s)

verified 7948 bytes in 0.406248s (19.106 KiB/s)

shutdown command invoked
↑変更後

尤もLPC824でもフラッシュ容量は最大32kByte程度なので2kByte/Secでもそこまで
困らないかと思います。

トラ技で配布しているmbed版ではないほうのLPC11U35向けCMSIS-DAP
ファームウェアを使用すればマスストレージに使用していたメモリリソースが
使用できるのでさらにちょっとだけ速度が上がります。


そんなわけで弱点だったCMSIS-DAPの書き込み速度は実用レベルにまで改善したので
OpenOCDからCMSIS-DAPをびしばし使い倒すことができるようになりました。
これでXPresso系のボードの開発もスムーズに進められると思います！

OpenOCD小ネタ16 -ついに浮動小数点レジスタ対応す-

かつてRemote'G'パケットうんちゃらかんちゃらのエラーが猛威を振るって
おりましたがたしかあれはダミーのFPUレジスタ分パケットが余分に送り込まれて
いたことが原因だったとおもいます。懐かしいですね…
時は流れ、ついにOpenOCDでもFPUレジスタ(浮動小数点レジスタ)の値を
ちゃんと読めるようになりましたのでご紹介します。

●FPUレジスタを読もう
ねむいさんの開発環境ではデバッガソフトウエアとしてInsightを使用しています。
こいつはクリック一発でレジスタウインドウが開き汎用レジスタとかを参照
できる便利な代物ですがFPUレジスタを見ようとする際はちょっとコツが要ります。
※言うまでもありませんがFPUを使用できるCortex-M4Fコアを持つSTM32F4,LPC4000系の
　マイコンをご用意ください。

先ずはOpenOCD側のcfgファイルの設定ですがかつては頑なにdisableに
していたtdesc(target description)の設定をenableにしてください。
gdb_target_description disable
↓
gdb_target_description enable

現在のおきぱにあるOpenOCDバイナリ及びねむいさん特製cfgは
enableに変更してます。


とりあえずデバッグ手順通りに進め、attachする直前まで。
ここでattachする(runボタン押す)前より先にレジスタウインドウを開いておきます。


そんでattach。そして速攻レジスタウインドウを閉じる


もう一度開くとあら不思議!レジスタウインドウにFPUレジスタが追加されてます♥
注!当たり前ですがFPUを有効にした後に参照してください！
　タイミング的にはmain()の先頭に立った直後が良いでしょう。


FPUが使用された時はレジスタウインドウ内のFPUレジスタの欄もしっかりと更新され、
FPUレジスタの中身がしっかり読み取れていることが分かります。


ちなみにレジスタウインドウを前もって開かずにattach後に開こうとするとInsightが
高い確率でひでぶして落ちてしまいます。tdescの実装直後みたく何やっても落ちる
事は無くなりましたがInsight側の問題とは思いますが上記の確実に参照できる回避
策でお願いします。


FPUを持たないCortex-M3系もちゃんと判別してこんな風に汎用レジスタ
のみ表示となります。


同じくCortex-M4でもFPUが無いKinetis系ではしっかり判別して汎用レジスタ
のみ表示です。


実際のデバッグではRTOSとか使わない限りレジスタの参照する場面は
正直言うとあまりないですが選択肢が増えることは頼もしいことだと思います。
どしどし使っていきましょう。



●あと細かい修正とか注意事項
FPUレジスタの読み取りには関係ありませんがこちらの件もかなり重要なので私に
”エラーが出る！”っていう質問が殺到する前に前もって注意しときます。
こちらのコミットから"make program"でshutdownやexitコマンドを含む
スクリプトを実行するとOpenOCDがエラーを返すようになった為エラー終了
するようになりました。

ねむいさんの公開しているバイナリではフラッシュ書き込みスクリプト付きの
cfgに影響があり、ちゃんと書きこめていてもエラーで終了しているように見えます。

↑こんな感じになります。

これは不具合ではなくこういう動作仕様になっちゃいましたのでご了承ください。
･･･と言いたいと　こ　ろ　だ　が　！！

20150313追：
なんとこの記事書いた直後にご了承できない方がgerritに修正を突っ込まれた
ようです。やっぱし正常に書けてるのにエラーで終わるのは決まり悪いので
ねむいさんも激支援します！
おきぱのopenOCDバイナリも早速反映をしてみましたので
安心してお召し上がりください♥

STM32F4シリーズを使ってみる14 - FatFsとSDカード再考その3(SDIOでDMAした時の不具合対策編) -

サブタイトルがどんどん長くなる･･･それはおいといて
前回の解説でまぐろ様と言う方より最初に4Byteの倍数以外の数のデータを
書き込んだ際に書いたデータがずれると言う不具合報告をいただきました。
結局原因はDMAする際にメモリアドレスがWORD(4バイト)のアライメントの境界に
そろっておらずずれた状態でDMAしていたことだったのですが、私自身も勘違い
したまま使っていたのでこの場で情報を整理して根本的にどう対処すれば
よいのかを記しておきます。
その前にどうでもいいですが"Alignment"はアラインメントでもアライメント
でも発音は正しいそうですが以後はアライメントで統一します。

●ズレる
たとえばファイル"mankoi.txt"を書き込みモードで開き、ヘッダとデータの塊を
f_sync()を挟んで書き込むコードを実行するとします。ここで"sakisan","gff"は
共に書き込む予定のバイト数を満たす十分な大きさをもち4バイトの境界に揃った
const charの配列のポインタとします。
またf_系の返り値のチェックは下では解説のために省略していますが
実コードでは付与しております。

f_open(&File[0], "mankoi.txt", FA_OPEN_ALWAYS | FA_WRITE);

f_write(&File[0], sakisan, 37, &s2);	/* 4の倍数でないバイト数 */

f_sync(&File[0]);

f_write(&File[0], gff, 4096, &s2);		/* マルチブロックで一気に書き込む予定 */

f_sync(&File[0]);

f_close(&File[0]);

期待される動作はsakisanで示された37バイトのデータを書き込んだ後gffで
示された4096バイトデータを書き込みファイルをクローズして無事終了
…のはずです。

SDIOでDMAを使用しないFIFOポーリングによる書き込みではちゃんと期待
される動作となります。しかしDMAを使用した場合最初のブロック(=512バイト)を
書き込んだ次のブロックの最初の書き込もうとするデータが1〜3バイトずれて
しまいます。
このずれ方は転送予定だった最初のバイト数を4で割った余りと等しくなります。

STM32F4のマニュアルではDMAをする際のメモリアドレスの境界はFIFOバースト
長さ/INC値に合わせよと明記があります。STのサンプルでは送り元メモリ及び
送り先ペリフェラルはそれぞれ4バイトとしていたのでそれに倣って4バイトの
境界にメモリアドレスを合わせる必要があります(私のサンプルのSPI版の
場合はDMAの転送サイズはByteのため今回の影響はありません)。
ねむいさんはてっきりFatFsのデータのやり取りに使用する為に静的に確保した
バッファの配列を4バイトアライメントにしておけばそれで問題なかろう･･･
という致命的な勘違いをしておりました。

上記f_writeからはSDIOドライバと結合したdisk_writeが呼ばれますがこのとき
渡される内部バッファのポインタアドレスが4バイトの境界にそろっているとは
限りません。しかしながらdisk_write内のSD_WriteBlock及びSD_WriteMultiBlock
はDMAで転送する際は送付元メモリアドレスが4バイト境界(4で割り切れる数)に
なっている必要があります。ズレる状況で実際にどういうことが起こっているか
デバッガで追いかけてみましょう。


最初にシングルブロック転送で37バイト分書き込む時です。最初なので
当然メモリのアドレスも4バイトの境界にいます。


f_sync()の処理を終えてから次の4096バイト(実際は最初の512-37バイトを
引かれた値)をマルチブロック転送で書き込んだ時です。ご覧のように渡された
ポインタbuffのアドレス値が4で割り切れない数になってます。


当然のことながらmankoi.txtに書き込まれた文字列はズレます。

●対策
前回も述べましたがSTM32F2/F4は対策はとても容易でDMAの設定でメモリ側の
データサイズを1バイトの"Byte",FIFOバッファのメモリ側バースト長をSingleにすれば
1バイトごとの転送となり効率は落ちますがアライメントは関係なくなり問題は
解決します。

しかしSTM32F1系はSDIOはF2/F4系と違いAHBバスにぶら下がっていてなおかつ
AHBバスに直接ぶら下がったペリフェラルへのDMA転送は常にWORD(4Byte)単位
でなければならないという制約があり、F2/F4みたいな技が不可能です。
したがって下記に示す根本的な対策を行う必要性があります。
/* If unligned memory address situation,copy dmabuf to aligned by 4-Byte. */

/* SECTOR_SIZE = 512 (Byte) */

uint8_t dmabuf[SECTOR_SIZE] __attribute__ ((aligned (4)));

if((uint32_t)buff & 3)	/* Check 4-Byte Alignment */

{	/* Unaligned Buffer Address Case (Slower) */

	for (unsigned int secNum = 0; secNum < count && Status == SD_OK; secNum++){

		/* Use optimized memcpy for ARMv7-M, std memcpy was override by optimized one. */

		memcpy(dmabuf, buff+SECTOR_SIZE*secNum, SECTOR_SIZE);

		Status = SD_WriteBlock(dmabuf,

					  (uint64_t)(sector+secNum)*SECTOR_SIZE, 

					  (uint8_t)SECTOR_SIZE);

	}

} else {

	/* Aligned Buffer Address Case (Faster) */

	if(count==1){

		Status = SD_WriteBlock((uint8_t*)(buff), 

							  ((uint64_t)(sector)*SECTOR_SIZE),

							  SECTOR_SIZE);

	}

	else{

		Status = SD_WriteMultiBlocks((uint8_t*)(buff), 

									((uint64_t)(sector)*SECTOR_SIZE),

									SECTOR_SIZE

									,count);

	}

}

f_writeから渡されるbuffのアドレスの下位2ビットを比較して4Byteの境界に
ない物は整列された配列にコピーし直しシングルブロック転送を行うものです。
このアライメント補正したシングルブロック転送を行っていくとブロックサイズ
の境界(512Byte=128*4Byte)に揃い改めて高速なマルチブロック転送が可能と
なるので効率をなるべく落とさないような仕組みにしてあります。
勿論Readの際もﾁﾏﾁﾏ読み込みの際は同じような対策でズレを防止できます。

これの対策の元ネタはSTマイクロのフォーラムにあったやり取りです。
かれこれ3年以上経ってましたがねむいさんずっと勘違いしてたせいでこの
対策の意味が今更分かったorzそれにしてもClive1...貴方は何者なんだ…！

そしてChaNさんのページでもズレるから各自対策してね★ってしっかりと
注意書きがしてありました…orz見落としてただけジャン私orz

で、でも現行のSTM32F4Cubeとかのサンプルって1.4.0になってもアライメントの事ガン無視
ですし、ま、まぁこれに気づく人のほうがたぶんす、少ないですってﾊﾊ♥

･･･と言うわけでおきぱにあるSTM32F2/F4のサンプルは上記の根本対策を
講じております。好みに合わせてDMAの設定だけで逃げるお手軽対策も
できるようにしてあります。

またF1系,LPC1788/LPC4088のFatFsでも根本対策を施していますので
ご利用ください。ちなみにLPC2388に関してはChaNさん謹製のMCIドライバを
使用していますがちゃんとアラインド/アンアラインド化をしているため
もともと大丈夫です。

●そういえばFatFsの設定で･･･
FatFsの設定のためのffconf.hには_WORD_ACCESSなる定義があり、1にすると
ポインタの参照が32bit単位になり高速化ができる･･･はずですが32bitマイコンの
場合はCPUコアのアライメントの制約で1にすると上で述べたDMAみたく
CPU例外が起こってしまいます。
しかしながらCortex-M3/M4ではアンアラインドなアクセスが一部の命令で可能なため
1にする事ができます。"一部"なのでChaNさんは0を推奨しています。

ねむいさんが試したところではff.cではまだDWORD(8Byte)やそれ以上の
マルチバイトにアクセスする状況が発生していないのでアンアラインド転送の
制約に引っかかるSTRD,STM,LDRD,LDMの命令は現状のコンパイラではff.c内
では一切使用されず例外も発生しないので1で問題はないと言い切れます！
もちろんアンアラインドなアクセスではペナルティが発生してその時の速度は
低下しますがそれでも全体的にはバイトアクセスの時より速度もコードサイズ
でも優れているので積極的に１にしていきましょう！
さらにGCCのコンパイラ・オプションで”-munaligned-access"を有効にすると
アンアラインドアクセスを承知でコードの効率化が図れます。

20160620追：
FatFs0.12ではこのオプションは廃止されました。
コンパイル時に必ずアラインド状態のアクセスになるようコードが変わっています。
20160620追：

ちなみにアンアラインドなアクセスが起こった事を知るための機能もあります。
SCB->CCR |= SCB_CCR_UNALIGN_TRP_Msk;

SCBのCCRレジスタにはアンアラインドなアクセスの発生をトラップするビットが
あります。これを立てるとアンアラインド転送が起こった時にHardFaultに
させることができます。

一方Cortex-M0,M0+ではコアのアーキテクチャが違うのでアンアラインドな
データアクセスは許されず、問答無用でHardFaultになりますので常にバイト
アクセスかもしくはアライメントがそろった転送をしましょう。

そういうわけで不具合もしっかりと修正されたので今度こそ実際に
パフォーマンス比較をやっていきたいと思います！

中華Bluetoothなアレを試す3号機 -ぱちもん大戦-

え？STM32のFatFsの続きはどうしたって？
ちょっとかなりヤバい不具合が発覚したので予定の動作検証は私以外の環境でも
動作確認できて問題ないことが確認できるまで様子見です･･･

その代わりルール違反ですが騒音と振動と電磁波が遮断されたお仕置き部屋で
実験したらルール違反とならない例のアレをご紹介しますのでご期待ください！
(※建前)
それでは張り切ってイってみましょーか★




ついに来ました！中華bluetoothモジュールで超有名なアレです！！
文字通りアレで通じるくらい有名なアレです！もちろん役に立つ使い方なぞ
紹介しませんがねむいさんは斜め45度の角度でこのモジュールに切り込んで
いきます！

それはさておきHC-05は広く知れ渡っているのと複製が容易だったのが災いして
ぱちもんもたくさん存在しているそうです(次回以降にファームの吸出しについて
解説します)。
公式のHPや公式のtaobao店舗では稲妻エフェクトまで出してぱちもん撲滅に
力をいれていてぱちもんの見分け方とかも公開しています。

どうやら表にシルクが全くなく、裏のシルクが真っ白で変なデジタル数字が
降られているのがぱちもんのようですね〜･･･


･･･
オイーーーーーーーーーー！！！！！！
ねむいさんAliexpressでHC-05の"正規品"を確認して購入したのですがおもいくそ
ぱちもん掴まされてました･･･orz

どうすんのよ5つも買っちゃったじゃないのさ！


なお、冒頭の奴は表にシルクがあるタイプで正規品･･･と見せかけて写真ではわかり
づらいですがCSRのチップ見たいな奴が別の製品を削ってCSRのレーザ刻印しなおしてる
リマーク品という超ぱちもんですorz動作が正規品と比べてハードウエア的におかしいorzorz
20150430追:
リマーク品ってどういう感じなのかよく見たいというリクエストいただきましたので、
どアップ画像貼らせていただきます

お 分 か り い た だ け た だ ろ う か ･･･
改竄の形跡がわかりやすいエッジの部分を接写してみました。
思いっきり鑢かなんかでゴリゴリ削ってレーザーマーキングした痕跡がわかりますね。


ねむいさんが思うにぱちもんメーカーは少しでもコスト下げるためにシルクとかを
極力単純にするか省いてるものが多いと感じました。しかもAliexpressやebayでは
公式の画像を無断転載して平気で商売してるとか余裕なのでやっぱしそういう
場所で買い物する限りまずぱちもんを掴まされると思ってよいでしょう。

ちなみに別の店舗でHC-06のXBee風モジュールも購入したのですが見事に
ぱちもんでしたorz


･･･
というわけで気を取り直して改めてwavsen(广州汇承信息科技有限公司)から
直接正規品を購入してみました。値段はちょっと高いですが保障を購入して
いるのですから安いものです。
なんとHC-05とHC-06はSIGにちゃんと登録があります。
でも日本国内で使うのは御法度なのは変わらないわけで聖闘士星矢ハーデス編に例えたら
正規の冥闘士(スペクター)だろうが寝返ってハーデスに従った奴らだろうが処女座の
シャカから見たら等しくただの敵なので天魔降伏なのですがねむいさんも
ルール違反にならないようにちゃんとお仕置き部屋で実験してるわけで(※建前)

大陸のほうの中国の人とのやり取りでしたが英語が通じて会計もスムーズに済んで
しかもお礼のメールまで返信してくれたのですが大陸のほうの中国人が金を
ちょろまかさずたいした数も購入してないのに敵対してるはずの日本人の私に
こんなに親身に接してくれてちょっとこの人たち優し過ぎるんじゃないかぱちもん
作ってる奴らにいいように利用されてるんじゃないかと余計なこと考えて
しまいましたがほんっとに余計ですね。



というわけでやってきましたよう！(右端のチェックマークないのはHC-06)



これが！

本物の！

証ＤＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡＡ！

なんと正規品には"HC"のロゴが振ってある特注品の水晶を使っています。
そこいらのぱちもんとはやはり格が違いますね！


ちなみにファームウェアバージョンは"+VERSION:2.0-20100601"でした。
これが決定版ファームのようですね。HC-06のほうはV1.8でした。
ちなみに世に流通しているぱちもんも"+VERSION:2.0-20100601"です。
それは冒頭で述べたとおりぱちもんがこれら正規品からファームを吸いだし
精巧なぱちもんを作っていたからです！
そんなわけでどうやってファームを吸い出したかの詳細は次回に続きます！

Go to top of page