obnizのフォーラムは新しいシステムに移行しております。
新しいフォーラムはこちらになりますFlick HATをobnizで使う
-
Flick HATをobnizにつなげるライブラリを作成しました。
デモムービーはこちら。
ムービーにはありませんが、タッチイベントにも対応しています。ライブラリはいずれ公開しようと思いますが、カテゴリーは
Movement Sensor
ですかね?追伸;
このデバイスは3.3v駆動のため、obnizで使うにはちょっと面倒です。
5vで使える姉妹商品がいいかも。
-
@nak435 こんな面白い部品があったんですね!知らなかったです。
動きいいですね、素晴らしいです。今のカテゴリ分けだとMovement Sensorになります。
プルリクエストいただければ導入致します(持っていないので、弊社でも購入して動かしてみたいと思います!)なるほど、3.3vだと電源の問題がありますね。
ライブラリには他にも3.3vの部品がありますし、それ自体は問題ありません。
-
@Yuki-Sato さん
PRには少し時間をください。
タッチイベントとタップイベントの違いなど、反応の違いが判らない点があるので、
もう少し動作検証してAPIに反映したいと思います。もしパーツ購入されるなら、事前に現時点でのjsをお渡しすることもできます。
個別にご連絡ください。また、(私が持っていない) 5v駆動できるFlick Largeがいいと思います。
-
-
@Yuki-Sato さん
完成しましたので、PRさせていただきました。PRコメントを参照してください。よろしくお願いします。
-
@nak435 ありがとうございます!!確認させていただきます。
-
@nak435 こんにちは!プルリクエストをmergeして確認していたのですが、
ジェスチャー検出がなかなかうまくいきません。なにか原因考えられますでしょうか。Largeのvccに外部から3.3vを供給して動かしています。
それ以外は直接接続している状態です。入れていただいたdemoの実行画面はこのようになっています。
polling #/seqはカウントアップされているので問題なくi2cで通信はできてそうです。ここからなにか分かりますでしょうか。
-
@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を指定しているため)以上、ご確認お願いします。
-
@nak435 ありがとうございます。
何度実行しても同じで、i2cエラーは出るときと出ないときがあります。(比較的出ることが多いです)こちらから逆にAPIの確認ですが、i2c.readWait()に指定するlengthは最大受信サイズのつもりで使用しています。つまり最大サイズであり「そのサイズ以下で受信する場合もある」想定ですが、必ずlength分だけ受信しようとする仕様であれば、実装を変える必要があります。(上述の通り現在は最大サイズ132を指定しているため)
以上、ご確認お願いします。
こちら、必ずlength分だけ取得します。ドキュメントが分かりづらくてすいません。
obnizはi2cで相手に対してlength分のデータを共有し、受け取って送ります。length分にならない場合はエラーとなります。たとえば相手がi2cにおけるNAKという「それはうまくいきません」という主張をするとエラーとなります。
-
@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);
以上、ご確認お願いします。
-
@nak435 なるほど。理解しました。
であれば、そちらのコードのようにヘッダを先に読んでいただいてreadしていただければ問題が解決する気がします。よろしくお願い致します。
-
@Yuki-Sato さん、jsの対策版を週末目途にPRしたいと思います。少々お待ちください。
ただひとつ、reset後FlickHatから最初に受信するデータはfirmware 情報でデータ長は132バイト固定。これが(firmware versionの文字列が)必ず途中から文字化けするという点はちょっと解せないですが、js対策時に検証してみます。
-
@nak435 バージョンの文字列はいつも同じものではなく、違う値が出ることもありました。
かしこまりました。ありがとうございます。
-
@Yuki-Sato さん、2回に分けてi2c.readWait()を使ってデータを受信する方法はダメでした。
一見データを受信できているように振る舞いますが、実際読み込んだデータはすべて0x00になっていました。
そこで、i2c.readWait()のlengthを、reset直後は132バイト、バージョン情報受信後は26バイトとするように変更してPRしました。
よろしくお願いします。
-
@nak435 ありがとうございます!今週中に確認してリリース致します!
-
@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だと良くないのかなと思っています。
接続方法について、合っているか教えていただけますでしょうか。よろしくお願い致します。
-
@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バイトの読み取りに失敗することもあります。
これは同じでエラーになることがあります。どこかの制御に問題があるのでしょうか?
-
@Yuki-Sato さん、
まずは、ピン接続だけ確認してください。i2cエラーは、私の方でもう少し調べてみます。
-
@nak435 ありがとうございます。
接続は3.3vのgnd以外同じでした。
エラーはそのせいかもしれませんが、しかし電気的にはgndを繋がない場合3.3vとしてうまく供給できないはずなのでそこが不思議です。教えていただいたプログラムの部分を修正して試してみたいと思います。
また少し時間がかかりそうなのですが、早めに試したいと思います。引き続きよろしくお願い致します。
-
@nak435 時間がかかってすいません、
なんとか3.3vをgndにつないでFlick Largeを動かしたかったのですが、うまく動かすことができなかったです。
3.3vをgndを繋がずに接続するというのはライブラリで推奨して伝えることは難しいと思ってます。Flick LargeでなくFlick Hatの方で、外部の3.3vを使うとはいえ普通にvccやgndを供給して問題なくうごくのであれば、弊社での動作確認後Flick Hatのライブラリとして公開できればと思っているのですがいかがでしょう。
よろしくお願い致します。