センサーデバッガ

今日半日使って作ってみました。

技術的にはこの2記事を組み合わせたものになります。
#LogicalGaming: PSoC 4 で有機ELディスプレイ
http://logical-gaming.blogspot.jp/2014/05/psoc-4-el.html

#LogicalGaming: ADNS系センサのRead / Write Operation
http://logical-gaming.blogspot.jp/2014/04/adnsread-write-operation.html

マウスセンサーのΔX、ΔYを読み込んでリアルタイムに可視化してくれるというスグレモノです。
(何に対して優れているかは分かりませんが・・・)
強いて利点を挙げるのならPCが必要ない事、つまりスタンドアロン動作することですね。モバイルバッテリ等の5V電源があればいつでもADNSセンサーのTracking特性を調査できます。

実際に動いている様子はこちら。XとY軸、両方の変位を表示しています。片方の手でカメラ(スマートフォン)を保持して、もう片方でマウスを振っているので映像が手ブレしています。

撮影環境が著しく悪くて申し訳ないです。手元にはレンズ交換式アドバンストカメラがあるのですが、充電器を紛失しました・・・

解像度は128x64ですので、8bitのΔX、ΔYを4で割っています。
シンプルに実装したので、フレームバッファを2枚用意しました。おかげでメモリが極端に圧迫されて使用率95%ほど。これ以上はPSoC 5LPが使いたくなってきます。

SQUALもグラフ化してみたのですが、ばらつきが極端に多く何のデータかよく分からない感じだったのでボツ。Shutter値やSQUAL等の変化の大きい物を表示するにはなんらかの統計処理が必要ですね。

これでディスプレイ遊びは一旦終了ですね。もしかしたら秋ごろにちょっとやるかもしれません。
そろそろゲーミング業界に貢献性の高い物を作りたいです。

PSoC 4 で有機ELディスプレイ

有機ELディスプレイ(I2C、128x64、二値表示)をスイッチサイエンスから買ったので実装してみました。
2、3日かかると思ったのですが、2時間で動いてしまってちょっと拍子抜けですね。

状況

・PSOC Creator3.0 SP1
・PSoC4 4 Pioneer Kit

・GROVE - I2C OLEDディスプレイ128×64 SEEED-OLE35046P
国内 : http://www.switch-science.com/catalog/829/
輸入 : http://www.seeedstudio.com/depot/grove-oled-display-12864-p-781.html
詳細 : http://www.seeedstudio.com/wiki/Grove_-_OLED_Display_128*64
専用ライブラリ : https://github.com/Seeed-Studio/Grove_OLED_Display_128X64

コントロールチップ : SSD1308 [PDF] http://garden.seeedstudio.com/images/4/46/SSD1308_1.0.pdf
ディスプレイ : LY190-128064 [PDF] http://garden.seeedstudio.com/images/c/c4/LY190-128064.pdf
ライブラリと2つのデータシートを参考にしながら必要な部分を作成しました。

※SSD13xx系をAVRで制御されている方がいらっしゃったので参考にさせて頂きました。
UG-2864HSWEG01/SSD1306 I2Cで動作テスト
http://jsdiy.web.fc2.com/oled_ssd1306/
このページによく纏まっているのですが、このチップのデータの単位であるPage、Segmentの関係はよく理解しておく必要があります。

ディスプレイは二値情報のみなので、1x8の縦長のピクセルを1グループ(Segment)として、扱います。これは、計算機は1Byteでデータを扱う事が多いので理にかなっていますね。1x8ピクセルのグループを横に128個並べて1Page、Pageを縦に8段並べる事で1frame(1画面)になります。

I2C

I2C Componentのコンフィグを下図に示します。オーバーサンプリングの設定が中途半端なのは、ビットレートをちょうど400kbpsにするためです。なお、400kbpsにこだわった理由はフレームレート試算の為です。

PSoC 4はSCB利用のComponentを使用する場合、ピン配置が固定されるので注意が必要です。

CommandのWrite

以下のように実装を行いました。コマンドモードに遷移後、Command入力を行います。ADDRはスレーブアドレスです。

#define ADDR 0b0111100
void OLED_Write_Cmd(uint8 command){
    i2cMasterWriteBuf[0] = 0x80;
    i2cMasterWriteBuf[1] = command;
    I2C_I2CMasterWriteBuf(ADDR, (uint8 *) i2cMasterWriteBuf, 2u,  I2C_I2C_MODE_COMPLETE_XFER);
    while(0u == (I2C_I2CMasterStatus() & I2C_I2C_MSTAT_WR_CMPLT)){}
    (void) I2C_I2CMasterClearStatus();
}

OLEDの起動

OffのCommand、ディレイ、ONのCommand、ディレイのみです。本当はもう少し初期化が必要なのですが、デフォルト値として省略。

void OLED_Init()
{
    OLED_Write_Cmd(0xAE);
    CyDelay(5u);
    OLED_Write_Cmd(0xAF);
    CyDelay(5u);
}

BitmapのWrite

データモードに遷移後、所定のByte数のデータ入力を行います。
void drawBitmap(const uint8* bitmaparray,int bytes)
{
    int i;
    for(i = 0 ; i < bytes ; i++)
    {
        OLED_Write_Data(bitmaparray[i]);
    }
    while(0u == (I2C_I2CMasterStatus() & I2C_I2C_MSTAT_WR_CMPLT));
    (void) I2C_I2CMasterClearStatus();
}

 

最適化

ライブラリの通り、全部のセグメントでアドレス→コントロールバイト→データバイトを書くという実装では遅いです。
I2Cのクロックは最大400kbpsという仕様なのですが、この実装の場合10fps程度しか出ません。なので高速化を施します。
アドレス、コントロールバイトは1フレームに一度だけの転送で、残りのデータ1024バイトは一気に転送します。これによってACK等も含めた転送bit量は 1/3.22 に減少します。

 void drawBitmap_fast(uint8* bitmaparray,int bytes)
{
    int i;
    I2C_I2CMasterSendStart(ADDR, I2C_I2C_WRITE_XFER_MODE);
    I2C_I2CMasterWriteByte(0x40);
   
    for(i = 0 ; i < bytes ; i++)
    {
        I2C_I2CMasterWriteByte(bitmaparray[i]);
    }
    I2C_I2CMasterSendStop();
    (void) I2C_I2CMasterClearStatus();
}

なお、オーバークロックして1000kbpsでも稼働可能です。当方としては定格超えですので常用はしません。クロックを上げるとRESETをかけた後にデータを受け取れなくなる事がまれに発生します。

使用例

int main()
{
    I2C_Start();
  
    CyGlobalIntEnable;
    OLED_Init();
 
    //Set Brightness
    OLED_Write_Cmd(0x81);
    OLED_Write_Cmd(0x00);
   
    //Set Freq
    OLED_Write_Cmd(0xD5);
    OLED_Write_Cmd(0xF0);
   
    //Set Hori-mode
    OLED_Write_Cmd(0x20);
    OLED_Write_Cmd(0x00);
   
    //Set First Seg
    OLED_Write_Cmd(0x00);
    OLED_Write_Cmd(0x10);
    OLED_Write_Cmd(0x40);
   
    //OLED_Write_Cmd(0xA7); //Inverse color if needed
 
    //Draw
    drawBitmap(Image_array,1024);
 
    return 0;
}

画像データ生成ツール

このようなデータの扱い方に対応した配列を生成するツールが存在します。
Bitmap converter for mono and color LCD displays
http://en.radzio.dxp.pl/bitmap_converter/

今回の構成の場合、設定は以下のようにします。
Fileから画像のLoad、Saveが可能で、出力はテキストの配列データになります。

 

生成されたファイルとincludeするか、ソース内に貼り付けることで利用可能です。
リサイズ、二値化はPaint.NET等で行う必要があります。また、今回は8bit Bitmapの画像を使用しました。

 

画像の置き場所

画像1枚で1KBなのでメモリ上に展開してしまうと、メモリが圧迫されます。なので、チップのSRAMではなく、const unsigned char 変数名[]{0x00, ・・・・・};という風に、比較的容量に余裕のあるFlash内に画像を置くことが必要だと思われます。

Overclocking Avago ADNS sensor

To get data lower latency and larger throughput from sensor, we need to overclock SCKL(fSCLK).
In ADNS-5090's datasheet, fSCLK max is determined 1MHz.
But I think, it can be more larger. So I try to find "real" max value of fSCLK.


Note(2014/06/23):
Overclocking external oscillator 24MHz to 32MHz at ADNS-3090 by rafa
http://utmalesoldiers.blogspot.jp/2014/06/adns-3090.html

Experiment environment

MCU : PSoC 4 Pioneer Kit
IDE : PSoC Creator 3.0 SP7
Sensor : ADNS-5090

Experiment steps

Increase SPI's SLCK(fSCLK) from 1MHz(1Mbps).
And try this steps (1 to 4).
--------------------------------------------------------------------------
1. Reset MCU
2. Write* 0x5A to register 0x3A (Reset sensor)
3. Read* 0x00(Get Product ID)
4. If MCU get correct value, result is OK. Else NG.
--------------------------------------------------------------------------
*Read/Write Operation code is Here :
#LogicalGaming: ADNS系センサのRead / Write Operation
http://logical-gaming.blogspot.jp/2014/04/adnsread-write-operation.html

Result

     fSCLK                       result
1.0 Mbps    OK (Max value in datasheet)
2.0 Mbps    OK
3.0 Mbps    OK
4.0 Mbps    OK
4.2 Mbps    OK
4.3 Mbps    OK
4.4 Mbps    NG
4.5 Mbps    NG
5.0 Mbps    NG
10.0 Mbps   NG

Conclusion

Threshold : fSCLK = 4.3 Mbps.
And in 4.3 Mbps, I can get data of DELTA_X, DELTA_Y, and so on.

個人の感想

日本語で書いてもニッチすぎる内容なので英語テイストな謎言語で記述しました。JAで記述して実験データ死蔵するのもアレですし。英語が相当おかしいのは重々承知ですが直す気も気力もないのでご容赦を・・・


定格最大値の4.3倍のクロックでも動いたのは意外というかあり得ないというか・・・とにかく驚きです。でも、安定性は考慮していないので実際にゲーミング用途で常用できるかどうかはなんとも言えません。

当たり前ですがクロックを上げすぎてセンサが機能しなくなっても壊れるようなことはないです。見た感じですと単に機能が止まるだけですね。

定格の1.5倍で動けば「当たり」とされる某界隈とは大違いですね。そちらはクロック自体が1000倍程違いますけど。
排熱等の諸事情でそもそも定格で連続稼働出来ないのを定格以下のクロックで動かして、ブーストと称して販売したりと色々と苦心されているようで・・・わりと近くで眺めている人間としてはクロックアップ競争の難しさと苦肉の策のマルチコア化は将来的にも色々と思う所が多いです。

その某界隈のアプローチの常套手段として動作電圧を上げることがありますが、この場合はどうなんでしょう。正直そこまでやる気力もやる人も居なさそうなので今後の課題ということで。


実は外国だとセンサ制御やってる人は居るのですが、大体がゲーマの方ではなく、Make:つまりDIY方面の方たちです。MCUにArduinoを使えばADNSセンサ用のサンプルコードも無くはないので、実は言語の壁を超えられれば参入障壁はかなり低いんじゃないかと思います。それこそMCUが載ったボードとセンサーのシールドを買ってきてサンプルコードをコピペするだけで動かせるレベルなので。

ゲーミングの世界でもデバイスの自作という選択肢が出てきたら面白そうです。
ゲームエンジンやコンピュータを一から作るよりはハードルは低いと思ったり。
既存パーツをアセンブルするだけの自作PCよりはちょっと難しいですが、ケース自作とかやってる人はぼちぼち居ますし、ぜひぜひ(何を？)

PDFファイルを色反転して閲覧する方法 in Windows

最近PDFファイルを見る回数が非常に増えてきたのでメモとか布教的な。

周囲にLinuxとMacとWindowsが混成している場合、ドキュメントのやりとりはほぼPDF一択になりますよね。個人的には \LaTeX でも良いのですが、PDFは画像も一緒にパッケージングされるのが良い所。

動作が重かったり容量が大きかったりと忌避されていた時代もありましたが、最近は名刺サイズのデバイスでも閲覧できるくらいハードウェアの処理能力が上がっています。
このPDF形式、特に電子部品のデータシートやリファレンスマニュアルの配布形式として一般的です。メーカ的にはViewerの種類関係なしに描画結果がある程度担保できるのが魅力的なのでしょう。

しかしこのファイル、眩しい。白背景に黒い文字は目が潰れます。コード書いてる時間よりデータシートを眺めている時間の方が長いようなアレな人にはかなり辛いです。
そんなわけで、どうしても背景を黒、文字を白という様に色を反転表示したいと考える訳です。

Adobe Acrobatの反転機能は微妙

Adobe Acrobatにも反転機能が付いていることにはついて居るのですが、ファイルによっては上手く動かなかったりします。
アクセシビリティ機能はありますか （Acrobat X） http://helpx.adobe.com/jp/acrobat/kb/4399.html 
表示の強調の項

恐らく、背景色はデフォルト(プログラム側で変更可)になっていて、文字色が固定の場合に黒背景黒文字になっている感じだと思うんですけど。
動作が重いのもマイナスポイントですね。

SumatraPDF

そんなわけでここ1年位使ってるのはSumatraPDFというソフト。
Sumatra PDF のダウンロード - 無料 pdf リーダー http://blog.kowalczyk.info/software/sumatrapdf/download-free-pdf-viewer-ja.html

オープンソースで無料のPDF Readerです。動作はかなり軽快だと思います。後述の色反転機能抜きに考えても相当バリューが高いです。

色反転機能

このReader、実は隠し機能？的なものがあって、起動時の引数に -invert-colors と追記すると描画エリア全体の色を反転してくれます。参考 : http://forums.fofou.org/sumatrapdf/topic?id=2149324

UbuntuのデフォルトのReader(名前失念)とかはUIから直接指定できるんですけれども、このソフトウェアの起動オプションの存在に気がつくのにちょっと時間がかかりました。

PDFを開く時に引数を常に有効にする

しかしPDFに関連付けしても-invert-colorsの引数はついてくれません。普通はショートカットを作成して、引数を追記してドラッグアンドドロップで起動するというのが一般的？ですが毎日何十回もそれをやるのは面倒極まりないです。

コマンドライン引数を常に有効にする方法ですが、コマンドプロンプトからftypeコマンドを使うのが一般的らしいとのこと。しかし面倒なのでパス。
Noobな私はFileTypesManというソフトウェアを使いました。

FileTypesMan

窓の杜 - 【REVIEW】わかりやすい画面でファイルの関連付けを簡単管理「FileTypesMan」 http://www.forest.impress.co.jp/article/2008/10/14/filetypesman.html
このソフトウェアはインストールなしで使えます。

起動→ ".pdf"の項目を探してきて、Openの部分をダブルクリック。CommandLineの項を以下のように追記
"(SumatraPDFのインストールディレクトリ)\SumatraPDF.exe" "%1" %*
                                                                               ↓
"(SumatraPDFのインストールディレクトリ)\SumatraPDF.exe" -invert-colors "%1" %*

2014/05/18追記:
操作の補足の画像です。

表示するとこんな感じ。

これからは快適なPDFライフになりそうです。

Technical Analysis : Anker Laser Precision Gaming Mouse

Overview
Name : Anker Laser Precision Gaming Mouse
Price : 2799 JPY (amazon.co.jp)
Model : 98N5000-BA
Power : 5V 100mA
S/N : 2FPS8F
Made in China


Specification
EN : http://www.ianker.com/goods.php?sku=98AN5000-BA
JP : http://jp.ianker.com/product/98AN5000-BA


Optical system
Laser sensor : Avago ADNS-9800
http://www.pixart.com.tw/product_data.asp?product_id=77&productclassify_id=1&productclassify2_id=3
  Model : A9500
  Subcon : N
  Year : 2013
  Week : 37
  Sensor Die Revision : T
  VCSEL Die Revision : D
  Lot number : 598

Laser Driver MOSFET : Vishay Siliconix Si2301DS(A1SHB)
[PDF] http://www.vishay.com/docs/70627/70627.pdf

Lens : Avago UMS1 、1(ADNS-6190-002 ?)


Control Logic
MCU :  HOLTEK HT82A525R (8bit 、6 or 12MHz)
http://www.holtek.com.tw/english/docum/computer/82a525r.htm

EEPROM : Atmel AT24C64D
http://www.atmel.com/devices/AT24C64D.aspx
  Year : 2013
  Week : 33
  Country : B
 

Switch
Main : OMRON D2FC-F-7N (Made in China) x2

Middle : Blue rasin top tactile switch (unknown)
Wheel : TTC (24 steps)
Tilt : HUANO Red top 0.05A 30V x2

Side : HUANO Red top 0.05A 30V x2

DPI Shift : Black rasin top tactile switch (unknown) x2

Right additional(SW6) : Micro switch (unknown)
Left additional(SW7) : Black rasin top tactile switch (unknown)


(個人的な)感想
偏見に満ち満ちたレビューです。

形状
持ち上げやすい、いわゆる側面が抉れてる系のマウスです。
これを左右対称にして、小さくすればG300に近い形状になるような感じがしますね。

ゴム製グリップのモールドが深くホールド力はありますが、なぜモールドが縦なのかは疑問。前後への滑り止めよりは上下運動、つまり持ち上げる動作の時に最適化したほうが良いと思うのですが。自分にはデザイナーの意図が理解できず残念。

サイズはかなり大きめ。手のサイズが大きい方向けで、少なくとも黄色人種がメインターゲットではない印象を受ける製品です。


表面
筐体表面のラバー塗装は質感は良いですが、経年劣化と剥げを考慮するとクエスチョンが付きます。
星座を模した(?)模様はどうでしょうね。好みが分かれそうです。

個人的には模様なし、表面も樹脂むき出しで滑り止めは樹脂の表面のモールドで行うようなのっぺりした筐体が好みですが、そういうマウスは少ないですね。


重量
素の状態でもかなり重い部類に入ります。個人的には許容値を遥かに超えた重さです。
追加で錘を入れられます。錘の固定方法は低反発のスポンジです。


性能
低DPI域がもう少し細かく設定できると良いと思いました。気のせいかもしれませんが、触った感じで若干遅延しているような・・・？未確認なので誤情報の可能性高し。
筐体サイズと重量が原因でゲームをする気になれなかったので、高速度域のTracking性能やフィーリングに関しては未評価。


回路
センサーとEEPROMの製造週が一ヶ月しかずれていないのがポイント高いですね。何のポイントかは知りませんが。
ダイのシーリングから完成品が手元に届くまで一年かかっていません。

実装ですが、基板上のフラックスの残りが目立ちます。だからどうということはないのですが。フラックスの残り方から察するに、面実装部品はリフローして、電解コンデンサやスイッチ、コネクタ等のDPI部品は手半田している可能性が高いです。でもイモはんだがあったりするのでちょっと怖いですが、この価格帯でこの性能の製品に求めるのもおかしい話。
LogitechやMicrosoftの基板ばかり見ていたので人が作った匂いのする基板はカルチャーショックだったりします。


スイッチ
押した感じで不快なものはないです。こだわりがある人以外は大丈夫だと思います。
チルトがちょっと固いですが誤爆防止だと思えば良いのかもしれません。
HUANOのスイッチが多いのは価格帯を考えれば当たり前でしょう。逆にこの値段で全部OMRONだったらドン引きです。

薬指か小指で押す用のスイッチの距離が前方よりで非常に遠く、自分では絶対に押せない場所にあります。かぶせ持ちの人がちょっと頑張れば届くかな、という距離です。自分的には側面にスイッチは要らない派なので誤爆しないだけマシだと思いました。
逆に親指で押す下の側面スイッチは中々便利そうだと思います。
DPIスイッチは樹脂パーツを前後に傾けて前と後ろのスイッチを押す方式。楽しい。


その他
 実はこのマウスがブログのレビュー第1号だったり。バラしてから写真を撮り忘れたことに気が付きました。

秋葉原でチラホラ見かけるようになったAnkerというメーカの高性能センサを積んだゲーミングマウス。デバイサーの聖地(?)Arkにも確か置いてありました。
Avago社製レーザーセンサ搭載機で3000円以下という圧倒的な低価格なので、お試しでゲーミングマウスやレーザーセンサを使ってみたい人にはオススメです。ルックスもゲーミングマウスらしいルックスだし、LEDの色を変えたりも出来ます。

これを(私の中では)最強のマウスだと名高いG300、現行のG300rとほぼ同価格帯でラインナップしてくるわけですからAnker凄いですね。
一番のネックは筐体サイズと重量で、「もっと小さくて軽いマウスだったら一緒に遊べたのかな」、と思いました。側面が抉れている形状は非常に好みです。

また、3000円以下でADNS-9500と純正レンズがついてくるのは非常にお得ですね。バラす時に罪の意識的なものもあまりありませんし。 (デバイス勢並の感想)
私的には分解レビューは前座で、ここからが本番です・・・

マウスセンサのデータレートを低下させてみる

USBマウスのレポートレートは125、500、1000Hzが一般的です。MCUは、USBでのデータ転送前にXとYの変位をセンサーから取得しているでしょう。なので、センサーは毎秒125～1000回程度の取得には少なくとも対応しているということですね。

それでは、毎秒125回以下のアクセスだと何が起きるか?
・・・・確かめてみましょう。単純に考えるとオーバーフローしやすくなり、データ長が8bitの場合、+127とか-128になりやすくなる、と思えますね。しかし、もしかしたら一定時間で変位が切り捨てられているのかも、という。

データの取得を毎秒1回程度にして実験してみます。

(データ割愛)

予想通り、+127や-128が多くなります。恐らく、内部的には1フレーム毎(ここでのフレームはGPUの描画やUSBの転送のことではなく、センサのフレームの事)に変位を該当Registerに加算する処理がなされているのでしょう。
要するに取得回数を極端に減らした場合、オーバーフローしながらもセンサは正常に動作するということです。何らかの形でマウスの負荷が上昇し、暫くの間データの取得が出来なくても安心です(そんな状況が発生している時点では全く安心出来ないですが)。

極々当たり前の結果ですが実際に確認した人は少ないと思いますので意味のない検証ではないはず。

ちなみにアクセス回数の上限ですがデータレートより、
・tSWW、tSRW、tSRR、tSWRと呼ばれるパラメタ値
によって決められます。この値はセンサによって多少大小があります。
加えて、当たり前ですがセンサのフレームレート以下のアクセスレートである必要もあるでしょう。
もっとレートを稼ぎたい場合はMotionBurstを使うような実装にするのでしょうか。


・ポーリングレート(レポートレート)について
ゲーミング用途においてはレートを減らす意味はあまりないです。
(最近NVIDIAのG-SYNCが話題ですので、フレーム描画に合わせてレポートするとかすれば「何か」起きるような気もします。)

「レートを上げすぎるとシステムへの負荷が増える」という説に関して :
確かにホストシステムへの負荷は上がっているはずで、間違っていないのですが、私が不勉強なせいなのか、「ベンチマークにおいてパフォーマンスの有意な低下を確認した」という資料は見かけていません。自分が「無い」と思っているものを探すのは不可能に近いので知ってらっしゃる方はコメントで情報お願いします。昔の話だとちらほら出なくもないのですが、当時とはMCUの性能、センサのスペックも違うのでホスト/マウスのどちらが原因かは断定出来ないんじゃないかと思っています。
また、いくつかのF2Pタイトルにおいて、125Hz以外のセッティングの場合に照準が波打つ現象は事実なのですが、あれはゲームの仕様という線が濃厚だと思っています(未検証)。


それでもって私が一番知りたいのは125、500、1000Hzどれが一番強いの?というテーマです。
最近考えているのは、

「想定速度域とMCU / ホストシステムの実装によって最適値は変わる」

という結論です。想定速度域がDPIとセンシティビティが大きく関わってきますし、実装に至ってはブラックボックスな上にメーカによって大きく異なりますので結論は出ないというのが結論じゃないでしょうか。そして、もし1000Hzが強いと証明されても、某F2Pタイトルで活躍しているユーザーさん達は125Hz一択なわけですしホストの方も考慮に入れる必要があります。

ぶっちゃけた話ポーリングレート変えてもそこまで大きな変化がないという説が・・・ここで言ったらおしまいですね。ヤバイヤバイ。
ちなみに自分はパフォーマンスは置いておいても、入力遅延が少なさそうなので1000Hzにしています。

レポートレートに関してはもう少し掘り下げられると良いのですが・・・・
USBに関しては素人なので、USBのHIDのドキュメントや関連書籍をもう少し読み込む必要がありそうです。
ハード関係はちょっと深くなると日本語文献がグッと減るのが最近の悩みだったりします。