受信とデコード

前回の続きではあるが、golangと関係ない話だ。

 

RC-S956は、PasoriのRC-S370に搭載されているチップで、RC-S620/Sも同じチップが載っている。
RC-S370とRC-S620/Sの違いは、インターフェースがUSBなのかUARTなのかだ(他にもあるが、使うだけならそれでいいだろう)。

 

RC-S956はNFC R/Wとして動作するチップだ。
詳しいことは知らんのだが、

1. インターフェースを通してコマンドをユーザが送信
2. コマンドのフォーマットが正しければチップがACKを送信
3. レスポンスがあればチップがレスポンスデータを送信

ということになっている。

ただ、ACKやレスポンスを送信するといっても、受信してほしいデータがありますよフラグがあるわけでもなく、そういう取り決めになっているだけだ。
ACKを返すのも設定次第だし(今回は必ずある)、レスポンスデータも固定長では無いので、なんか嫌な感じだ。

---

では、どう実装するのがよいだろうか。

まず、受信サイズはInEndpointのパケットサイズの逓倍にするのがよかろう。
gousbのサンプルも10パケット分ということで10倍した領域を用意していたし。

幸いなことに、RC-S956からの1回分のレスポンスはサイズの上限が決まっている。
そして、コマンドに対してレスポンスを返すだけで、勝手にレスポンスだけを返すことはなかったはず。
Target系のメッセージがちょっと自信ないのだが、今回は忘れよう。
1コマンド送信に対して、ACK受信(6byte)とレスポンス受信(最大256byte＝4パケット)。

ACKは、いい。
受信して最初のデータなので、受信データの先頭6byteをチェックすれば良い。

問題はレスポンスだ。
ACKと別USBパケットになると思うのだけど、100%の確信があるわけではない。
設定でACKを返さないようにできた気はするのだが、その設定をするまではACKが返ってくるので、あまりそこでがんばりたくない。

---

となると・・・USBの1パケット中にACKとレスポンスが混ざっていたとしてもデコードできるようにするし、ACKとレスポンスが別パケットになったとしても受信をそれぞれ行うようにする、というやり方しかないか。

文字にすると「当たり前やん」と言われそうなのだけど、そういうのが苦手なのだ。

 

コマンド送信後、まずUSB5パケット以上の受信を行う。
先頭の6byteをACKと比較する。
それ以上のデータがまだあればレスポンスとして比較し、残っていなければUSB4パケット以上を受信する。

おそらく、レスポンスが複数パケットになったとしても、1回の受信で全部取得できるだろう。
ACKと連続したパケットであろうとなかろうと、最初のパケットを読めばレスポンス長はわかるので、足りているかどうかはチェックできるのだけど・・・大丈夫じゃないの、と思ってしまうのよね・・・それがダメなのか・・・。