タッチスライダープロトコル
English version here.Thankyou for translating.
・実機からロジアナでキャプチャした波形
slider-cap.zip
ZEROPULS LAP-C(16032)用。見るだけならアプリインストールすれば見れる。

bootup(power-on).alc：電源オン時の起動動作。
led(xxxx).alc：サービスモードのOUTPUT TESTでのLED全点灯時の動作。
    

・プロトコル詳細
TX/RXはNu基板基準。
プロトコルの基本パターンは送受信とも下記パケットとなる。
offset0123～n(可変長)n+1
内容ヘッダ(0xff固定値)コマンドコード実データ長実データsum
実データが0バイトの場合もあり。
sumの計算方法は、ヘッダ(0xff)～sumまでの合計値の下位8bitが0x00となる。
sumが0xfdとなる場合、0xfdに続いて0xfcも送信する。

実際の動作パターン(筐体電源ON～)
(1)TX:FF 10 00 F1
接続確認？
(2)RX:FF 10 00 F1
接続確認応答？
ただし、スライダー側がなんらかの要因(初期化中など？)だと、無応答もしくはFF EE 02 FD FE 01 11を返す場合がある。その場合は(1)を約0.1秒後に再送。
(3)TX:FF F0 00 11
ボード詳細要求
(4)RX:FF F0 12 31 35 32 37 35 20 20 20 a0 30 36 36 38 37 FD FE 90 00 64
ボード詳細情報。サービスメニューのGAME SYSTEM INFORMATIONで表示される内容
offset 3～10がBD NUMBERの837-の後ろ。837-15275。
offset 19がFIRMWARE。144
その他不明。
ここはチェックサムが1ずれているのが正解のようだ。
    
(5)RX:FD FC
不明。パケットの形からして違う。
(6)TX:FF 03 00 FE
スキャン開始指示。
(7)RX:FF 01 20 [32byte] [sum]
スライダースキャンデータ。先頭バイトが左側で、サービスメニューのINPUT TESTのTouchSlider 0に該当。
以降、約12ms周期で定期的に送信される。
各センサーの取り得る値は0～0xFE。0xFFが送信されることは無いらしい。
ちなみにチェックサムが0xFFになることもないらしい。おそらくはどこかのセンサーの値が適当に±1されている。
つまり、スライダーからの受信データで0xFFはパケット先頭以外あり得ない。
※スライダーはしばらくデータが何も無いと、エラーとしてスライダーが自己リセットする。
    
(8)TX:FF 09 02 00 00 F6
不明。
(9)RX/FF 09 00 F8
前パケットの応答。不明。
(10)TX:FF 0A 01 00 F6
不明。
(11)RX:FF 0A 00 F7
前パケットの応答。不明。
(12)TX:FF 02 61 3F [ ([blue] [red] [green]) x 32] [sum]
LED発光状態。
先頭バイトが左側。
サービスメニューでの点灯状態でのRGB値は0xFE。0xFFでも正常に発光するが仕様としては最大値は0xFEと思われる。
タッチスライダー側のFWで、0xFFを受信した段階で強制的にパケットスタートとして認識させていた経緯などがありそう。

以降 TX:FF 02 61～と、RX:FF 01 20～を定期的に送受信する。

・おまけ

スライダー基板の謎のDIPSWとCN3/4はこんな感じで繋がってるので、通常はI2CでPSoC間の通信をしていて、DIPSWを切り替えることで、PSoCのFWをISSP経由で強制書き換えできるようにする物と思われる。
戻る