条件を指定して絞り込む
現在1886件がヒットしています。check
Konashiを使ってUzukiのI2Cセンサにアクセスするときに注意しなければならないことについて説明します
Uzukiは３つのセンサが一つのI2Cバスに繋がっていて、KonashiはI2CのAPIコマンドでこれらのセンサにアクセスするのですが、UzukiはiPhoneとBLEを介して接続されているので、I2Cのアクセスも非同期で行われます。
たとえばUzukiの加速度センサの値を読み出す場合、こんな感じになります。
プログラムサンプルはこんな感じです。
①加速度センサリードリクエスト
82行目がリードリクエストのメソッドです。
このリードリクエストを発行して、I2Cからのイベント発火を待ちます。
⑥加速度センサリードコマンド
328行目がリードのメソッドです。
I2Cからのデータが受信されるとイベントが発火されるので、それを受けてこのリードメソッドを実行してデータを読み込みます。
ここで注意しなければならないのは、konashiのI2C関連のイベントは、
KonashiEventI2CReadCompleteNotificationで、I2Cからデータを受信した時に通知されるイベントですが、UzukiのようにI2Cバスに複数のデバイスが接続されている場合、このイベント通知は、どのデバイスから受信したデータなのかを識別できないんですね。するとどういうことが起きるか？？？
例えば３つのセンサデータ、①温度、②加速度、③照度をこの順番で間を置かずに読み出すプログラムを書いたとします。
① 温度のリードリクエスト
② 加速度のリードリクエスト
③ 照度のリードリクエスト
ところが温度センサと加速度センサのデータ変換時間を比べると温度センサのほうが時間が掛かります。すると、温度のリードリクエストを先に出したのに、データレディのイベント通知は加速度センサのほうから先にあがってきます。
これに気がつかないと、加速度データを温度データとして読みに行ってしまうことになり、その結果おかしなことになってしまいます。
このリードタイミングの入れ替わりを防ぐには、センサの変換時間を把握して、センサの読み出し順が前後しないようにリードリクエストからリードまでのWAIT時間を調整するしかなさそうです。
変換時間がダイナミックに変化するようなデバイスの場合にはさらに調整が難しそうです。変換時間の最大値に合わせるしかないですね。
