ELISEとか好きだからー!!

　かなり放置状態だったデータロガー 2号機計画，とりあえず単体で G を計測するやつを作ろう (これだと追加の半田付けはなんもいらんから) と思った．
　で svn に葬ったソースファイルをチェックアウトしてきて，コンパイルしてみたらコンパイルが通らねぇ(爆) 原因を追っていったらなんかいろいろとコンパイルオプションとかがおかしくね? なんでこんなとこいじったんだろう…?

　まぁめでたくコンパイルも通り，SD カードの初期化コマンドを CMD1→ACMD41 に変更したら，前回使えなかった 8MB ゴミカードも無事初期化できるようになった．

　で，前回は SD カードリードでとまっていたので，SD カードライトに挑戦．ライト速度も見るためにいろいろデバッグメッセージ出力を削ってやってみたら，

　fatfs に「ファイルシステムがねぇ」って怒られる orz

なんかデバッグメッセージを消したことにより wait が減って，動作が変になってるっぽい．まれにライトまでたどり着けたとしても，FAT エントリをめちゃくちゃに破壊してくれるんですが…(笑)

もう窓から投げ捨てていいかな?

　GA-MA78G-DS3H はどのように省電力設定しても，USB に常に電源が入る．例えば電源を切っていても光学マウスの LED が光りっぱなし．で，PCI スロット用 USB2.0 カードがあったのでこれにキーボードとか挿してみたら，BIOS でキーがきかねぇ…＿|￣|○

　なので，マザボ上の USB ピンヘッダをリアの PCI ブラケットに引き出すパーツを上の PCI カードを破壊して(笑) 作ってみた．ただし電源部分は残して PCI バスからとるので，PC 電源 OFF 時は USB 電源も落ちるのがミソ．

　で，早速使ってみたら，キーボートとかマウスとか接続がプチプチ切れる…＿|￣|○ やっぱノイズとかまったく考慮してないからかなぁ…

　久々にゴミを作ってしまった．しかも USB PCI カードを破壊してまで＿|￣|○

　DIMENSION の WOL ということで，パワー SW や WOL 信号の特性を探ってみた．


　まずパワー SW だが，ケースからのフラットケーブルを接続するコネクタの 6, 8番 pin をショートさせると，電源が入る．もっと具体的にいうと，#6 が 3.3V にプルアップしてあって，これを GND とショートさせると電源が入る．


　LAN カードの WOL コネクタのほうは，たぶん真ん中が GND，残りが +5V と WOL 信号で，WOL 信号は定常状態で 0V，マジックパケットを受け取ると，3.3V になった．
　
　しかし，ここで問題があることが発覚．WOL 信号は Windows が起動して LAN カードに何らかの設定がされるまで 3.3V のまま．一方，パワー SW 端子のほうは，ショートさせっぱなしだと (マザボに通電自体はするものの) ブートシーケンスが開始されない．つまり，単純に WOL 信号の極性を反転させてパワー SW 端子に接続したとしても，マジックパケットを受け取った時に通電はするが Windows は起動しない．

　この LAN カードを使って WOL を実現するにはここのようにタイマー回路を組んで一定時間後に WOL 信号を 0V に落とさないとだめだけど，俺にそんな知識ありませんから!! 残念!!

　ほかの LAN カードで試してみるかなぁ（゜ーÅ）ほろり

－－－－－
　ちょっと話題は変わって，今回 DELL を分解してみて，いろいろと合理化されていてびっくり．
　一つはマザボの固定方法で，ネジ 1本でうまいこと固定している．(説明がめんどくさいのでここ見てくれw)


　もう一つはケース排気ファンが CPU 冷却ファンを兼ねていること．これはコストを下げるのはもちろんのこと，ファンの数を減らして静音化につながったり，CPU の廃熱を確実にケース外に排出する優れた機構だと思う．そういや BTX は吸気ファンと CPU 冷却ファンが兼用でちょっとうれしかったが，もう BTX は終わった感じだしねぇ．
　DELL は合理化を進めるあまりパーツが特殊になって，自分では買いたくないがw (この DELL をオクで買ったのは異様に安かったから)，こういう機構は積極的に規格化して自作界にも取り入れてほしいところだ．

　昔，ヤフオクで落とした DELL DIMENSION XPS 4100 を WOL ( Wake On LAN ) 化してみようと思い立った．DIMENSION の BIOS には WOL/PME の項目があるのだが，マザボ上に WOL コネクタはない．たぶん，コストダウンでそこらへんの回路は省略されてるんだろうな… PME の項目があるということは，WOL ケーブルをつながなくても PCI スロットを通してパワー ON イベントが送られるのではなかろうか? と期待したが，どうもそれも NG のようだ．
　幸い，BIOS のこれらの項目を ON にしておけば，Windows シャットダウン後にも LAN カードの電源は落ちないようで，要は LAN カードは WOL パケット (マジックパケット) を受け取って WOL コネクタに信号を出すことができる．すなわち，電源 SW とこの WOL コネクタの信号をうまいことつなげば，WOL が実現できるはず．

　というわけで，いろいろググってみたら，同じようなことを試みている人は結構いるようだ↓
http://www.geocities.co.jp/SiliconValley-PaloAlto/6025/WakeOnLan.html
http://www5.atwiki.jp/kuro-bsd/pages/128.html

これらを参考に，DIMENSION WOL 化計画を進めていくつもり．

-------- initialize --------
CMD0:1 CMD1:7 CMD1:7 CMD1:3 CMD1:3 CMD1:3 CMD1:3 CMD1:3 CMD1:3 CMD1:3 CMD1:3
-------- CSD --------
CMD9:0,FE
0000:CSD structure
0000:System specification version
002D:Data read access-time 1
0000:Data read access-time 2 in CLK cycles
0032:Max. bus clock frequency
0135:Card command classes
0009:Max. read data block length
0001:Partial blocks for read allowed
0000:Write block misalignment
0000:Read block misalignment
0000:DSR implemented
019E:Device Size
0006:Max. read current @ VDD min
0006:Max. read current @ VDD max
0006:Max. write current @ VDD min
0006:Max. write current @ VDD max
0003:Device size multiplier
0013:Erase group size
001F:Erase group size multiplier
001F:Write protect group size
0000:Write protect group enable
0000:Manufacturer default ECC
0005:Write speed factor
0009:Max. write data block length
0000:Partial blocks for write allowed
0000:Content protection application
0000:File format group
0000:Copy flag (OTP)
0000:Permanent write protection
0000:Temporary write protection
0000:File Format
0000:ECC code
0074:CRC
f_mount:0
CMD17:0,FE CMD17:0,FE CMD17:0,FE
f_open:0
CMD17:0,FE
f_read:0: read=512
f_close:0
-------- dump --------
0000:00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
0010:00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
0020:00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
    …
01F0:00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

MassStrage.dfu で 8MB のゴミ SD カードのアクセスが失敗していたので，どこでコケているのか調べてみた．
最初は初期化シーケンスが正しくないのかと思ったが，SD の仕様書と見比べてもそんなにおかしなところはない．お次は AC タイミング的なエラーを疑ってみたが，こればっかりはオシロスコープ持ってないのでわかんね．ただほとんどのコマンド (CMD0 とか 9 とかはぜんぜん正常であることが分かってきた．てことは AC タイミング的な問題ではない?

唯一おかしいのは CMD1．こいつのレスポンスが 0x7 とか 0x3 とかしか返ってこないので，MassStrage.dfu では MSD_GoIdleState() で死んでいたようだ．でもレスポンスが 0x7 とか 0x3 とかって，ここ見る限りそもそもなんかおかしいんですが… (illegal command とかありえねー) もしかして SPI の 8bit アライメントがずれてんのか?
本来
11111111 00000001 11111111
と受け取りたいところを，2bit ずれて
11111100 00000111 111111??
と受け取ってしまってるとか．これならばレスポンスが 7→3 に変化してるのも筋が通るが，何でズレてんのかまではわかんね．ああ，こういうときオシロとかロジアナとかほしいなぁ…

で本来 CMD1 のレスポンスが 0 になるまで wait するのだが，レスポンスがおかしいまま次に進んでも CMD17 (セクタリード) とかは全然正常 (これのレスポンスとかリードデータが bit ズレ起こさないのも，上の仮定と違ってて謎)．というわけでゴミ 8MB SD カードが無事活用できるようになった(?)

他の使えなかった SD カード (2GB) の解析はやってないけど，たぶんセクタサイズが 512B 以外になっててその設定 (CMD16) をやってないからじゃなかろうか?

－－－－－
追記:
　CMD1 が Illegal Command になっていた件，どうやら SD カードの厳密な仕様的には CMD1 は受け付けなくて，CMD41 で初期化しなければならないらしい．CMD41 で初期化すると，ゴミ 8MB カードも無事使用できた．
　MMC と SD は SPI 通信を使う限り，完全互換性があるという思い込みをしてしまっていた．

デザインウェーブマガジン付録 ARM ボードをいぢくる続き．

FLASH に焼かれたルーチンを SRAM 実行プログラムから呼び出す方法を確立してみた．
SRAM は 20KB しかないので，printf 等の大き目のルーチンを SRAM 実行プログラムにリンクしてしまうと，当然残りの SRAM 容量が減ってしまうので開発に支障が出る．そこで FLASH 上にある printf ルーチンをリンクしてしまおうというのが今回の趣旨．

まず，FLASH 上の printf のアドレスを知るためには，
メニューの Project → Options...
Linker → List タブ → Generate linker map file
で FLASH 実行プログラムの .map ファイルを生成すればよい．たとえば printf のアドレスが 0x080063ed だったとすると，SRAM プログラムのソースで

#define printf (*( int (*)( const char *fmt, ... ))0x080063ed)

と書けば OK．

だが，これだと printf を使ってる全ファイルの修正が必要だし，いちいちプロトタイプ宣言を調べて #define を書き並べるのが面倒なので，別の方法を考えてみる．

rom_entry.s なるファイルを以下の内容

    RSEG ROM_CODE:CODE(2)
    EXPORT printf
printf = 0x080063ed
    END

で作成し SRAM プログラムのプロジェクトに追加してコンパイル・リンクすることで，FLASH 上の printf にリンクできた．この方法だと .c の修正はいらないし，.map ファイルから perl スクリプトなんかで機械的に rom_entry.s を生成できるので楽．

いろいろ FLASH 上のルーチンにリンクしたら，もともと 18KB のプログラムが 5.5KB になったよ(笑)

デザインウェーブマガジン付録 ARM ボードをいぢくる続き．

昨日と今日にかけて，フリーの FAT ファイルシステムドライバであるFatFsを組み込んで，SD カードのファイルを読み出せるようにしてみた．

具体的には，ff.c を組み込んで，diskio.c をインプリしていくのだが，disk_read/write() はほとんど SD カードセクタリード・ライトそのまんまだが，disk_ioctl() は何書いていいのか分からん… 幸いここにサンプルがあった．

デバッグ用にシリアル出力を大量にしているとなぜかリードデータが化ける問題があってちょっとハマッたが，最終的に無事ファイルリード完了ヽ(´ー｀)ノ

あと，putchar() 関数を定義して，こいつでシリアル出力するようにしておくと，printf() で普通にシリアルにメッセージが出せるので便利ヽ(´ー｀)ノ

以下，ToDo リスト
・FLASH のルーチンを SRAM プログラムからコールする仕組みを確立
・SRAM ルーチンを割込みハンドラに設定
・割り込みを使用したシリアル入出力
・ここら辺が FIX したら FLASH に焼いて，「SD カード上のファームを SRAM にロード」を運用開始

データロガー 2号機計画を ゆっくり と進行中．

今回は，MassStrage を参考に，SD カードの 1セクタをリードしてシリアル (USB を介した仮想 com ポート) 出力にダンプさせてみた．まぁ MassStrage の msd.c あたりをそのまま組み込んだだけだが．コンパイル通すのに多少苦労しつつ，とりあえずダンプできるまでこぎつけた．

が，シリアル出力が明らかにおかしい．シリアル出力はカエルがぴょんのやつを参考にしていて，USB の送信データバッファ(?) に送信したい文字列を直接コピーしているのだが，おそらく前のやつが送信されきらないうちに次の文字列を上書きしているのだろう．

普通は，アプリ側でリングバッファを用意して，送信したいデータはリングバッファに書く→USB 送信データバッファに空きができたら割込み発生→割込みルーチンで，リングバッファから送信データバッファにコピー，なんて流れになると思うのだが…
もうちっと Cortex の割り込みを勉強せにゃならんね．とにかくシリアル出力をまともにしないと，まともなデバッグができねぇ．

とりあえず，断片的に見えているダンプデータを見る限り，SD カードセクタリードはできているようだ．

－－－－
6/16追記:
とりあえず割り込みを使用しないでお茶を濁しモード．送信データをバッファにカキコ前に

while( GetEPTxStatus( ENDP1 ) == EP_TX_VALID );

で前回のデータが送信されきるまで待つことで，シリアル出力は正常になったヽ(´ー｀)ノ

前回の記事どおり，SD カードの FW を SRAM にロードする仕組みを作っていくが，その前に，シリアル経由で FW を SRAM にロードする仕組みを作る．いくら既存のライブラリが充実しているからって，一発で SD カードアクセスプログラムが動くわけが無いのでw

というわけで，
1. 起動されたらデータを 0x4800 バイト分，シリアル (USB経由) から読み込んで 0x20000000～ へ書き込む
2. 0x20000004 に格納されているエントリポイントにジャンプ
という恐ろしく単純なプログラムを FLASH に焼きこんだ．これすらも，デザインウェーブマガジンに載っていたカエルがぴょんプログラムをちょこっと書き換えただけ．

ちなみに，マガジン付属 CD に入っていたサンプルプログラムの多くは，IAR Embedded Workbench でコンパイルしようとすると「__program_start」シンボルが無い，などと怒られてしまうが，その対処法はここに載っているようだ．

そしてマガジンに載っていた LED を点滅させるプログラムを SRAM 実行用に書き換え→.s19 を 0x20000000 からのバイナリイメージに変換するプログラムを作って変換→TeraTerm の send file で基盤に送信，で無事 LED が点滅したヽ(´ー｀)ノ

これで内蔵 FLASH を書き換えることなく開発・デバッグができる．しかし，早いことベース基盤を作らないと，リセットボタンすらないのでやりにくぅ．

ちなみにメモリマップは前回からさらに変わっている↓

20000000	ベクタテーブル
200000EC	SRAM プログラム用 .text
・・・	SRAM プログラム用 .data .bss 等
・・・	空き
・・・	スタック
(SRAM後端)	FLASH プログラム用 .data .bss 等
20005000

SRAM 実行用プログラムのコード・ベクタテーブルを SRAM の前端で固定したかったので，FLASH 実行用 SRAM 領域を SRAM の最後尾にやって，そこからスタック領域とした．

デザインウェーブの Cortex-M (AAM ARM) 基盤を使ったデータロガー 2号機作成をぼちぼち開始．

とりあえずの目標としては，SD カード上のファームウェアを SRAM 上にロードする仕組みを作る．で開発途上は SD カードにファームを書き込むことで Cortex 内部 FLASH の書き込み回数を減らす．これだとコード + データが 20KB 以内しか作れないが，デバッグの終わったルーチンをまとめて内部 FLASH に追い出して，SRAM 上のプログラムから FLASH 上のルーチンを呼び出す．なんてことを H8 の時はしてた．(H8 は SD カードアクセスはできなかったので，シリアル経由の .mot ロードだったが)

で，SD カードアクセスのライブラリは MassStrage デモのライブラリがそのまま使えそうだ．FAT アクセスライブラリも使われてるかと思ったら，FAT の管理をやってるのは Windows 側なのね．なのでフリーの FAT ライブラリを探してみたら，ここのが使えそうだ．

で，いろいろ make してると，メモリマップがちょとヘンなことが発覚．常識的には SP の初期値は RAM 領域最後尾の 0x20005000 だと思うのだが，標準だと 0x20000000 + プログラムで使う分 + 0x200 くらい．RAM あまりまくってるのにもったいない．

これは gcc でいうところのリンカスクリプトがおかしいのだろうと思っていろいろいじってみた．俺がインストしたのは「IAR Embedded Workbench」なので，リンカスクリプトに相当するのは「STM32F10x_FLASH.icf」になる．で以下のように書き換えた．

/*###ICF### Section handled by ICF editor, don't touch! ****/
/*-Editor annotation file-*/
/* IcfEditorFile="$TOOLKIT_DIR$\config\ide\IcfEditor\a_v1_0.xml" */
/*-Specials-*/
define symbol __ICFEDIT_intvec_start__ = 0x08003000;
/*-Memory Regions-*/
define symbol __ICFEDIT_region_ROM_start__ = 0x080030ec;
define symbol __ICFEDIT_region_ROM_end__   = 0x0801FFFF;
define symbol __ICFEDIT_region_RAM_start__ = 0x20000000;
define symbol __ICFEDIT_region_RAM_end__   = 0x20004FFF;
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__ = 0x0;
define symbol __ICFEDIT_size_heap__   = 0x200;
/**** End of ICF editor section. ###ICF###*/


define memory mem with size = 4G;
define region ROM_region   = mem:[from __ICFEDIT_region_ROM_start__   to __ICFEDIT_region_ROM_end__];
define region RAM_region   = mem:[from __ICFEDIT_region_RAM_start__   to __ICFEDIT_region_RAM_end__];

define block CSTACK    with alignment = 8, size = __ICFEDIT_size_cstack__   { };
place at address mem:( __ICFEDIT_region_RAM_end__ + 1 ) { block CSTACK };

define block HEAP      with alignment = 8, size = __ICFEDIT_size_heap__     { };

initialize by copy { readwrite };
do not initialize  { section .noinit };

place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };

define block RAM_Block with fixed order { rw, block HEAP };

place in ROM_region   { readonly };
place in RAM_region   { block RAM_Block };

要は，もともとの .icf ではデータ・ヒープ・スタックを連続領域にとっていたのだが，STACK を独立させて 0x20005000 から サイズ 0 で(笑) 固定的に取っただけ．
てか，gcc のリンカスクリプトはドキュメントが充実してるし高機能だし楽なんだけど，ツール独自のリンカスクリプトはわけが分からん…

デザインウェーブマガジン 5月号の ARM 基盤用追加部品が届いたので，ハンダ付けしてみた．追加部品は，マガジンに載っていた販売サービスではなく，ツクモロボット王国で買った．こっちのほうが送料が安かったので．

で，チャッチャとハンダ付けして，ハンダ付けがうまく行ってるかどうか確認するために MassStorage.dfu を焼きこもうとして，DfuSe Demo に MassStorage.dfu をロードしたら，

まさか編集者も収録ファイル間違えるなんてことはしないだろうし，そんなことしたら web 上で祭りになってるはずだし，メッセージをググって見てもそれらしい人は皆無．何で俺だけ…（゜ーÅ）ほろり

で，ふと思いついて，CD-ROM 上のイメージファイルを HDD にコピーして，それをロードしてみたら OK．なんと，CD-ROM 上のファイルを直接焼きこもうとすると NG だった．こんなこともあるんやねぇ…

てなわけで手持ちの SD カードを試してみたら，3枚中 1枚しか正常アクセスできなかった．認識率ひくぅ!!Σ（￣□￣； せっかく 8MB のゴミ SD カードを活用できるかと思ったが，こいつは使えなかった…

まぁ，一通り動くことは確認できたので，お次は SD カード上に置いた FW を SRAM にロードする仕組みを作らないとな．何回も chip 上のフラッシュを書き換えるわけには行かないので．

今月の DesignWave マガジンの付録，ARM が乗ったマイコンボードで，加速度センサがついていて，USB ケーブルで Flush 書き込みができそう(?) で，SD カードスロットを別途つければ，SD カードアクセスもできそうで，んーーーーこれは欲しい!

でもこれ知ったの今日だし，売り切れの中いろんな書店を探すのも面倒くさいので，HUNDAI W240D とともに Amazon でポチットな，してしまった．久々の衝動買いw

しかしこの ARM ボード，今使ってる H8 マイコンよりも高機能なので，いろいろできそうだな．っていっても，ネタ的にはデータロガー 2号機くらいしかないのだがw SD カードスロット足せば，これだけで G センサーのデータロガーができるし，A/D コンバータが 16ch もあるので，水温とか油温度とかアクセル開度とかいろいろロギングできたらいいな．

自宅ネットワーク無線 LAN 化プロジェクトの一環で，デスクトップにも USB 無線 LAN モジュールを挿して使っているのだが，本体裏だとあまり電波状態がよくないので，USB 延長ケーブルで延長させる事にした．

じゃいっちょ延長ケーブル買って来るかー，とふと横を見ると，転がっている壊れた USB マウス．もしやと思って探してみると，このマウスに付属していた USB→PS2 変換コネクタも見つかった．

というわけで，これらをくっつけて 0円 USB 延長ケーブルの出来上がりwww
耐ノイズ性とかまったく考慮してないけど，普通に使えてるみたいだからいいや．

上: LAP SHOT の磁気センサーユニット (\6,000 くらい)
下: ホールIC で自作した磁気センサー (材料費 \400 くらい)

機能的にはほぼ同じ．車関係の電装品はぼったくってるのがよくわかる例だな(笑) (自作データロガーも材料費だけなら \1万 くらいのはず．同等の機能の市販品を買うと 5万は下らないよなぁ)

…がっ!
調達したホール IC がちょっとマズかったのか，LAP SHOT のやつより感度が低い．磁石から 1cm くらいでないと反応しない感じ．これじゃちょっと使い物にならんなぁ．

んー，ざんねん．

ロドスタでジムカを本格的にされている，同僚の「ひ」さん．車にハマッていることは知っていたのだが，ひょんな事から俺との共通点を知る事になる．

ひ「近々，シリコンハウスに寄りたいと思ってるんですよねぇ」
俺 (´-`).。ｏＯ（いきなり「シリコンハウス」とな!? こいつ，できる…!!）
　 「なら，ついでにホール素子，買ってきてもらえませんか? DN68xx ってやつ」
ひ「ああ，それなら家にあまってますよ」

ちょwww 家に在庫www

俺「うおお，一個譲ってください! ところでホール素子，何に使ってるんですか（￣ー￣）にやり」
ひ「シフトレバーの位置を検出してシフトポジションインジケータ作ってるんですよ」

車の電子工作キタ━━━━(゜∀゜)━━━━ッ!!

ウチの職場，異様に MT 率高いし，いい職場だわ(笑)

ぬおおお!

+5V にプルアップしたとおもってたら，+12Vにプルアップしちまってたぜ!
おかげで H8 マイコンは異常加熱，でも幸い冷ましたら CPU としては動き出した．
が，ポートが少なくとも 1つ無反応に．あーポート一個死亡＿|￣|○

知人が日本橋に行くというので，DN6847 を買ってきてもらう事に．しかし，シリコンハウスでは売り切れ…（；´д⊂）通販で買おうにも，\60 の物買うのに送料が \890!! もうね，アホかと，バカかと．

というわけで，LAP SHOT の磁気センサーをもう一度引っ張り出してきた．前回試していなかった，SENS ピンのプルアップ/ダウンを試してみる事に．今回は，磁気センサーのケースをばらして，センサーから出ているピンジャック端子の機能割り当てをある程度推定してみた．

でいろいろやっているうちに，SENS ピンと思しき端子を VCC にプルアップすると，無事動く事を確認!!ヽ(´ー｀)ノ これでセンサーユニットが無駄にならなくてすんだ．実験の結果から割り出した，ピンジャックの端子機能は上の図通り．

SENS 端子は定常状態で Hi-Z，磁気を検知すると GND に落ちる．

ただ，気になる事が1点．磁石を 3cm くらいに近づけないと，センサーが反応しない．こんな感度で，コース上に埋め込まれた磁石を感知できるのか? (無理っぽい…)

もしかしたら，VCC は +5V じゃなくて +12V なのだろうか?
でも，もしそうじゃなくて，12V突っ込んだとたん燃えたらやだなぁ…

−−−−
追記: +12V でも感知距離は変わらんかった．んー，本物の LAP SHOT だと何 cm くらいで感知できるんだろ?

磁気センサー回路の続き．
LAP SHOT の磁気センサーユニットだけ買って自作データロガーにつないでみたが，まったく磁気に反応しない，ってのが今までのあらすじ．

動かない理由の可能性としては，
・いろいろ接続を変えているうちに壊した?
・VCC は実は +12V ?
・SENS ピンをプルアップ/ダウンする必要がある?
・そもそも予想していたピンの機能 (VCC, GND, SENS) がぜんぜん違う?

いずれにせよ，これ以上の遂行は困難なので，諦めて，公開されているセンサー回路図の部品を集めて作る事にした．それでホール素子 (磁気センサー IC ね) を調べていたら，こんなものがあるじゃないですか…
これ，アンプも温度補正回路も入っていて，出力はデジタル化されているので，作ろうと思っていた電子回路がこの IC 一個ですんでしまう… すげぇぜ Panasonic! しかも \115 円なので失敗しても痛くないや．後の問題は，コース上に埋め込まれた磁石を検出できるほど感度があるかどうかだが…


これとは別に，PSP の LuaPlayer に USB GPS を制御する関数を追加するほうも進行中．
いちお実装してみたけど，GPS 初期化で PSP が死ぬ(笑) ま，ぼちぼちデバッグしまっさ〜

赤外線方式でラップタイムが計測できる我が自作データロガー．しかし計測には赤外線送信機をコース上に設置しなければならず，もしかしたらサーキットによっては断られるかもしれない．

なので，多くのサーキットで使える磁気センサー式のラップタイマー (正確にはそのセンサー回路) を自作しようと，いろいろググってみた結果，回路図を見つけたのは以下の 2つ．

http://kaele.com/~kashima/car/lapmini/
http://www.asahi-net.or.jp/~TW8I-YSD/CAR/MAKE/sens.htm

ってこれアナログ回路じゃん… すんません，アナログ回路は理解不能です＿|￣|○ しかもアナログ回路の設計だと my オシロスコープがないときついだろうなぁとか，センサ回路は車外に出すためコンパクトに作る必要があるとか，もろもろの大人の事情を加味して，

LAP SHOT の磁気センサユニットだけ買っちまった＿|￣|○

電子工作マニアのはしくれとしても，あるまじき反則技．

　今日も PSPデータロガー プロジェクト を推進w

まず，LUA Player でシリアル受信データを取りこぼしまくる問題は，LUA Player を改造する事で対応．まずここを見ながら LUA Player をコンパイルできる環境を作り，ここを参照しながら，シリアル受信割り込み & バッファリング を使用するよう LUA Player を改造．

で，その結果は上々!! ヽ(´ー｀)ノ バッファリング無しだと，たとえば ABC…Z という文字列を送っても写真のように取りこぼしまくりだが，バッファリングありだと取りこぼすこともなく完璧．

PC⇔PSP はひとまずできる事は確認できたので，最終目標であるデータロガー (H8 マイコン)⇔PSP の通信をテスト．38400bps で何の問題もなく，H8 モニタプログラムのメッセージを受信できてしまったヽ(´ー｀)ノ
# USBケーブルが刺さってるけど，通信はリモコン端子のシリアルケーブルでやってるので．あしからず．
最大の難関であったシリアル通信があっけなくパスしてしまったので，目標の7割は終わったも同然．あとは，データロガーからのデータを元に PSP にデータを描画するプログラムを書くだけ．

PSPシリアル通信ケーブル，結構汎用的に使えて何でもつなげられるから，かなり最強じゃねぇ?

PSP シリアルケーブル完成!!

が，うんともすんともPSPが反応しない…＿|￣|○
どうやらPSPからの +2.5V が供給されていない模様．純正リモコンつないだ状態では 2.5V 入ってるのになぁ… PSP の リモコン I/F はなんかスリープモードを持っているようなので，スリープモードに入って電源遮断されているのか???

とりあえず，乾電池ケースとかかってきて，直に電源を供給してみるしかないか…

－－－－－
3/13追記:何の修正もなく動いたヽ(´ー｀)ノ どうやら PSP のシリアルポート初期化ルーチンを呼ぶ前にリモコン端子を挿していないと，PSP のリモコン I/F の電源が OFF になる模様．なので，PSP のシリアル通信プログラム起動前にリモコン端子を挿しておくと，無事動作した．

ただ，やはり事前の情報どおり，lua player だと，シリアルデータ取りこぼしまくるね…

\980 の PSP リモコン到着．リモコンとして使われることなく，いきなり分解www
一応ヘッドフォンだけは使えるかと，音質を確かめてみたら見事にスカスカな音が(笑) つかえね〜
出来の悪さは，さすがは人民的クォリティ．

ま，欲しかったリモコンコネクタ端子はまともそうだしいいや．
これで，週末には PSP⇔PC シリアルケーブルが作成できそうだ．

PC⇔PSP のシリアルケーブルを作ろうと，日本橋のシリコンハウスで必要な部品を購入．
で，問題になるのは PSP のリモコン端子に挿すコネクタ．こればっかりはコネクタだけで売っていないので，とりあえず壊れた PCI カードのエッジコネクタ部分を切り出してみたが，どうもうまくいかない＿|￣|○ 仕方なく，\980 の怪しい PSP リモコンを発注，と言うところでケーブル作成は中断．

次に PSP のソフトを何で作るか．最初は PSP の開発キットでゴリゴリと C で書こうとも思ったが，いろいろ調べてみると LUA Player なるスクリプト言語がある事発覚．LUA Player でもシリアル通信はできるし，画面描画はこっちのほうが楽そう．だが，LUA Player でシリアル通信するとえらくデータを取りこぼすらしい．これも試してみるしかないか．

　サーキットとかを走り出すと，ラップタイマーとかデータロガーとか欲しくなってくるが，自分は自作のデータロガーを使っている．どんなものかチラッと説明すると，

■LED デジタルメータ
・車速・エンジン回転数を LED デジタル表示
・シフトポジション表示
・レブリミット警告灯

■ ラップタイマー
・赤外線方式 または 磁気センサー方式でのラップタイム計測
・複数磁石対応
・ラップタイムは，このデータロガーと接続した PC 画面上に表示・記録

■ データロガー
・車速・エンジン回転数・前後加速度・ラップタイムをこのデータロガーに接続した PC に送信・記録
・PC 上のメーター合成 (スーパーインポーズ) ソフトで，車載動画と上記ログデータを合成

のような機能を持っている．

　要は，車両からの各情報を H8 マイコンで処理し，データを LED に表示させるとともに，車載ノート PC に RS-232C で送信しログをとっている．自分で言うのもなんだがコレかなり使えるシステムなんだけど (既製品を買えばウン十万は下らないはず)，唯一の欠点はノート PC が場所をとりすぎて，助手席に人が乗れない．このままだと同乗走行とかできない…

で，ノート PC 以外の手段をいろいろ探していたら，なんと PSP と PC を RS-232C でつないで通信できているらしい! つまり，H8 マイコン⇔PSP 通信もできるかもしれない，と言うこと．

ということで，PSP シリアル通信プロジェクト発進!
今日は，ここを見ながら PSP の開発環境をインストールしたところで終了．

　7月・9月とMLS (モーターランド鈴鹿) に，自作IRラップタイマを持ち込んでラップタイム計測を行っているのだが，これの調子がすこぶる悪く，50%位の確率でラップカウントを失敗する．作った当初はほぼ100% 計測できてたのになぁ? 赤外線投光機は見てのとおり32連LED(爆)なので，発光量は不足していないはず．電池切れかなー? と思って今日解析してみた．

　チラッとだけIRセンサの説明をすると，一般的なIRセンサは，38KHz で点滅する赤外線にしか反応しない．そうする事で太陽光などの赤外線に反応せずに，リモコンなどは正常に動作するわけやね．38KHz で点滅する赤外線を入れると，IRセンサは連続した Hi/Lo の信号を出力する．

　で，自作IRラップタイマの投光器では，38KHz の赤外線を更に1KHzで点滅させる．そうする事でIRセンサの出力は1KHzのHi/Lo信号が出力されるはず．だったのだが，なぜかHiベタの信号しか出力されていない．これではラップカウントされないはずだ．しかも電池切れでもなく，元々のLED発光Firmwareの出来が悪いっつーことか．しかしそれに気づかずに1年近く運用してたとは＿|￣|○

　でも肝心の原因が分かりましぇん．32個もIR-LED使ってるので，発光が強力すぎるのか???? んーオシロ持ってないから，何が起こってるのかようわからん．

　とりあえず，1KHz のデューティー比を 25:75 にして，IR-LED発光期間を少なくしてみた．これがビンゴ! IRセンサから無事 1KHz の信号が出力されるようになった．LED4個でも十分に反応してるし(笑) しかもLEDを90度横に向けてもIRセンサが反応してるし．いやなんか強力すぎ．これだけ反応されると，逆にタイム計測の精度が落ちちまう…