5

Bluetooth Core Spec V4.0 Vol . 3 パート G セクション 4.9.3は、応答を伴う特性値の書き込みには、属性プロトコル書き込み要求手順が使用されると述べています。

Bluetooth Core Spec V4.0 Vol 3 Part F Section 3.3.2には、

クライアントがサーバーに要求を送信すると、そのクライアントは、応答 PDU が受信されるまで、同じサーバーに他の要求を送信してはなりません。

CoreBluetooth を使った iOS アプリでレスポンス付きの複数の値を書きたいです。この仕様を自分で管理する必要がありますか? または、単に- writeValue:forCharacteristic:typeすべての値を一度に書き込むために使用できますか? iOS は、前のリクエストが処理された後にのみ各リクエストが送信されるように管理しますか?

Bluetooth Core Spec V4.0 Vol 3 Part F セクション 3.4.5.2によると、書き込み応答には書き込まれた特性へのリンクが含まれていないため、iOS がそれを管理すると思います。ただし、この- peripheral:didWriteValueForCharacteristic:error方法は、応答がどの特性にリンクされているかを iOS が何らかの方法で追跡していることを示唆しています。

誰かがこれを確認または否定できますか?

4

2 に答える 2

2

CBを扱う場合は、ATT/GATTをそれほど気にする必要はないと思います。その理由は、CB を使用している多くの人が Bluetooth Core 4.0 仕様にアクセスできず、それらを読むことも期待されていないためです。

CB が特性を関連付ける方法を知っている理由は、プロトコルが各コマンドと応答をペアにすることを指示しているためです。コマンドを送信すると、応答が返されます。

したがって、writeValue を複数回使用することができ、CB は呼び出しを適切にキューに入れます。つまり、次の書き込みの前に ATT 層での応答を待ちます。また、デリゲート コールバックは、書き込みが実行される順序と同じであることが保証されます。

于 2012-07-25T18:59:48.487 に答える
1

「応答付きの複数のリクエスト」を書くことができました。つまり

[自己周辺機器] writeValue:valueToWrite forCharacteristic:dataPointCharacteristic type:CBCharacteristicWriteWithResponse];

1 束にまとめて (実際には 14 通を送信しました)、遅れて全員から返信がありました。しかし、 - 書き込み応答には、特性に書き込まれたデータが含まれていませんでした。つまり、特性内の値のみが応答で無効でした。

「Bluetooth Core Spec V4.0 Vol 3 Part F セクション 3.4.5.2 によると、書き込み応答には、書き込まれた特性へのリンクが含まれていません」という注記に近いようですが、それは [characteristc 値] のみであるという 1 つの違いがあります。は正しくありませんが、ios が内部でシーケンス処理を行いました。そのため、書き込み応答 (つまり、BLE 確認応答) を使用してシーケンス ロジックを接続し、次に実行する一連のステップを処理することは現実的ではないようです。

要するに、BLE に「writeWithReponse」メッセージ「Do Task #1」をペリフェラルに送信すると、ペリフェラルからの BLE 応答は「OK!」になります。応答は、周辺機器が「Do Task #1」というメッセージを受信したことを示すのではなく、次のようなものです。はい、あなたの言っていることを理解しました。私はあなたが私に送った正確なコマンドを繰り返すのが面倒です:)

于 2014-09-04T15:59:10.443 に答える