Flick HATをobnizで使う

[nak435]

@Yuki-Sato さん

PRには少し時間をください。

タッチイベントとタップイベントの違いなど、反応の違いが判らない点があるので、
もう少し動作検証してAPIに反映したいと思います。

もしパーツ購入されるなら、事前に現時点でのjsをお渡しすることもできます。
個別にご連絡ください。また、(私が持っていない) 5v駆動できるFlick Largeがいいと思います。

[Yuki Sato]

@nak435 さん

かしこまりました。

購入して、届きましたらご連絡させていただきます！よろしくおねがいします。

[nak435]

@Yuki-Sato さん

完成しましたので、PRさせていただきました。PRコメントを参照してください。よろしくお願いします。

[Yuki Sato]

@nak435 ありがとうございます！！確認させていただきます。

[Yuki Sato]

@nak435 こんにちは！プルリクエストをmergeして確認していたのですが、
ジェスチャー検出がなかなかうまくいきません。なにか原因考えられますでしょうか。

Largeのvccに外部から3.3vを供給して動かしています。
それ以外は直接接続している状態です。

入れていただいたdemoの実行画面はこのようになっています。
polling #/seqはカウントアップされているので問題なくi2cで通信はできてそうです。

ここからなにか分かりますでしょうか。

[nak435]

@Yuki-Sato さん、何度実行しても同じでしょうか？　また、i2cエラーは出てないでしょうか？

ハードコピーから読み取れることとして、まず、
firmware versionに文字列が出ているので、デバイスから情報を読み取っているのは確かです。ただし、本来であれば1.3.14;p:HillstarV01;x: ;DSP:ID9000r2963;i:B;f:22500;nMsg;s:Rel_1_3_prer1784:NM;と出力されるはずですが、途中から文字化けしているので、受信データが途中から0xFFになっていると思われます。

次に、polling #/seqのところですが、正常であればnn / mmと2組の数字が出るはずですが、seqに当たるところの数字が空なので、polling()が受信データが無く空回りしているか、または受信データを無効と判断している可能性があります。こちらもデータが0xFFになっていると思われます。

PRするときのコメントにも書きましたが、なぜか受信データが途中から／先頭から0xFFとなる現象が出ています。そのため、0xFFのデータを無効とするロジックを入れてあります。具体的には、FlickHat.jsの下記の箇所です。

146      let data = await this.i2c.readWait(this.address, 132);
147      let size = data[0];
　　　中略
152      if (size != 0xff && size > 0) {

先頭データである受信データ長が0xFFはあり得ないため、それをチェックしています。
このif文の直前にconsole.log(size)を追加してもらえば切り分けできると思います。

170            if (
171              gesture[0] == 255 &&
172              gesture[1] == 255 &&
173              gesture[2] == 255 &&
174              gesture[3] == 255
175            )

また、4バイトのジェスチャー情報が0xFFもあり得ないため、それをチェックしています。
こちらは、デモhtmlの70行目の//flickhat.debugprint = true;のコメントを外してもらえれば、FlickHat.jsの154-156行目で受信データをコンソール出力しますので、これで切り分けできると思います。

---

こちらから逆にAPIの確認ですが、i2c.readWait()に指定するlengthは最大受信サイズのつもりで使用しています。つまり最大サイズであり「そのサイズ以下で受信する場合もある」想定ですが、必ずlength分だけ受信しようとする仕様であれば、実装を変える必要があります。（上述の通り現在は最大サイズ132を指定しているため）

以上、ご確認お願いします。

[Yuki Sato]

@nak435 ありがとうございます。
何度実行しても同じで、i2cエラーは出るときと出ないときがあります。（比較的出ることが多いです）

こちらから逆にAPIの確認ですが、i2c.readWait()に指定するlengthは最大受信サイズのつもりで使用しています。つまり最大サイズであり「そのサイズ以下で受信する場合もある」想定ですが、必ずlength分だけ受信しようとする仕様であれば、実装を変える必要があります。（上述の通り現在は最大サイズ132を指定しているため）

以上、ご確認お願いします。

こちら、必ずlength分だけ取得します。ドキュメントが分かりづらくてすいません。
obnizはi2cで相手に対してlength分のデータを共有し、受け取って送ります。length分にならない場合はエラーとなります。たとえば相手がi2cにおけるNAKという「それはうまくいきません」という主張をするとエラーとなります。

[nak435]

@Yuki-Sato さん、
そうであれば、実装を変えて再PRする必要がありますね。（度々i2cエラーが起きるのは、これが原因か？）

追加で確認ですが、
FlickHatから受信するデータは可変長であり、先頭1バイト目のデータが、全体データ長を示すため、
例えば、デバイスから60バイト受信する場合、それを4バイトと残り56バイトに分けて、二度のreadWait()で受信することは可能でしょうか？　コードのイメージだと以下のように。

//ヘッダーの4バイトを受信、先頭バイトが全体データ長
let header = await i2c.readWait(address, 4); 
//残りのデータを受信
let data = await i2c.readWait(address, header[0] - 4); 

以上、ご確認お願いします。

[Yuki Sato]

@nak435 なるほど。理解しました。
であれば、そちらのコードのようにヘッダを先に読んでいただいてreadしていただければ問題が解決する気がします。

よろしくお願い致します。

[nak435]

@Yuki-Sato さん、jsの対策版を週末目途にPRしたいと思います。少々お待ちください。

ただひとつ、reset後FlickHatから最初に受信するデータはfirmware 情報でデータ長は132バイト固定。これが(firmware versionの文字列が)必ず途中から文字化けするという点はちょっと解せないですが、js対策時に検証してみます。

[Yuki Sato]

@nak435 バージョンの文字列はいつも同じものではなく、違う値が出ることもありました。

かしこまりました。ありがとうございます。

[nak435]

@Yuki-Sato さん、2回に分けてi2c.readWait()を使ってデータを受信する方法はダメでした。

一見データを受信できているように振る舞いますが、実際読み込んだデータはすべて0x00になっていました。

そこで、i2c.readWait()のlengthを、reset直後は132バイト、バージョン情報受信後は26バイトとするように変更してPRしました。
よろしくお願いします。

[Yuki Sato]

@nak435 ありがとうございます！今週中に確認してリリース致します！

[Yuki Sato]

@nak435 こんにちは。

flick-demo.htmlを使って動作確認しています。
接続の確認なのですが、vccに3.3v、それ以外はobnizの1-5まで直接接続で合っていますでしょうか。

なかなかうまく通信できないでいます。
エラーが出ず何度かpollingできることもあるのですが、どこかのタイミングでエラーとなってしまいます。

最初の段階は比較的うまくいって、132バイトを受信できています。

[Log] Obniz: {"i2c0":{"mode":"master","address":66,"data":[132,0,0,131,170,99,128,230,19,100,21,32,49,46,51,46,49,52,59,112,58,72,105,108,108,115,116,97,114,86,48,49,59,120,58,32,32,32,32,32,32,32,32,59,68,83,80,58,73,68,57,48,48,48,114,50,57,54,51,59,105,58,66,59,102,58,50,50,53,48,48,59,110,77,115,103,59,115,58,82,101,108,95,49,95,51,95,112,114,101,114,49,55,56,52,58,78,77,59,0,0,0,0,0,0,0,0,0,0,0,0,0,0,14,0,0,85,170,144,101,32,32,128,15,255,255,255,255,225,242,0,0]}} (logger.min.js, line 1)

ただ、その後に以下のような書き込みを行うところで書き込めずエラーとなることが多いです。

[Log] Obniz: send: [{"i2c0":{"address":66,"data":[16,0,0,162,161,0,0,0,31,0,0,0,255,255,255,255]}}] (logger.min.js, line 1)

また、まれですが26バイトの読み取りに失敗することもあります。

接続方法が違うか、Flick Largeだと良くないのかなと思っています。
接続方法について、合っているか教えていただけますでしょうか。よろしくお願い致します。

[nak435]

@Yuki-Sato さん

vccに3.3v、それ以外はobnizの1-5まで直接接続で合っていますでしょうか。

その通りで合ってます。Flick Hatはいつもそれで動かしていますし、お借りしたLargeもその接続で動作しました。（その後、6-7も接続してLEDの確認もしましたが）

まったく動かない訳ではないようなので、接続の問題ではない気もしますが、前回のときより前進しているでしょうか？　同じでしょうか？
ただ、私の場合は、書き込み(i2c.write)がエラーになった記憶が無いです（忘れているだけ？）

3.3vは外から取っていると思いますが、外からのgndはどうしていますか？
私の場合は外からのgndを接続するとうまく動作しなかったので、外からは3.3vの1線だけ接続しています。（私の知識では、gndと対でなければ+3.3Vにならないと思うのですが、接続してしまうとなぜか動きませんでした。）

↑ここまでで佐藤さんと私でpin接続が同じであれば、FlickHat.jsのstart()内の2個所のi2c.writeを削除して試してもらえませんか？ このwriteは無くても動作しますので。もしくは下記2行が不要かも知れません。writeを残して、この2行を削除して試していただけますか。

73    await this.polling();
74    await this.obniz.wait(200);

追伸；

また、まれですが26バイトの読み取りに失敗することもあります。

これは同じでエラーになることがあります。どこかの制御に問題があるのでしょうか？

[nak435]

@Yuki-Sato さん、
まずは、ピン接続だけ確認してください。

i2cエラーは、私の方でもう少し調べてみます。

[Yuki Sato]

@nak435 ありがとうございます。
接続は3.3vのgnd以外同じでした。
エラーはそのせいかもしれませんが、しかし電気的にはgndを繋がない場合3.3vとしてうまく供給できないはずなのでそこが不思議です。

教えていただいたプログラムの部分を修正して試してみたいと思います。
また少し時間がかかりそうなのですが、早めに試したいと思います。

引き続きよろしくお願い致します。

[Yuki Sato]

@nak435 時間がかかってすいません、

なんとか3.3vをgndにつないでFlick Largeを動かしたかったのですが、うまく動かすことができなかったです。
3.3vをgndを繋がずに接続するというのはライブラリで推奨して伝えることは難しいと思ってます。

Flick LargeでなくFlick Hatの方で、外部の3.3vを使うとはいえ普通にvccやgndを供給して問題なくうごくのであれば、弊社での動作確認後Flick Hatのライブラリとして公開できればと思っているのですがいかがでしょう。

よろしくお願い致します。

[nak435]

@Yuki-Sato さん、

外部の3.3vを使うとはいえ普通にvccやgndを供給して問題なくうごくのであれば、弊社での動作確認後Flick Hatのライブラリとして公開できればと思っているのですがいかがでしょう。

今週末に確認しますので、お待ちください。

[Yuki Sato]

@nak435 かしこまりました。よろしくお願いします。