2013-08-02 15 views
15

Pamiętam czytania w "Guide and Hint" -doc do Samsung BLE API (archived page):Czy natywna implementacja Androida BLE jest z natury synchroniczna?

Jednym z najważniejszych pojęć Samsung F/W i stos jest jego synchroniczny charakter. Oznacza to, że jeśli nazywamy na przykład writeCharacteristic dla konkretnej charakterystyki, jeśli zwraca true, następne wywołanie dowolnej BluetoothGatt lub BluetoothGattServer metody należy wykonać po otrzymaniu onCharacteristicRead zwrotna. Dzieje się tak, ponieważ stos jest zaprojektowany do obsługi i przetwarzania tylko jednego wywołania GATT na raz, a jeśli, na przykład, wywołasz writeCharacteristic lub readCharacteristic na dowolnej charakterystyce wkrótce po pierwszym, zostanie zignorowany.

  1. to ma również zastosowanie do realizacji Nativ z BLE wprowadzono w Androidzie 4.3?
  2. Samsung API obsługuje również tylko jedno podłączone urządzenie GATT naraz. Czy to się zmieniło w natywnym API?
+0

Jest ciągłym wątek związany z synchronicznym charakter API na trackerze emisyjnej Google: https://code.google.com/p/android/issues/detail?id=58381 –

+0

Właśnie wdrożył kolejka do wszystkich zapisów i wygląda na to, że działa dobrze. –

+1

@Ash Według dokumentów dostarczonych przez firmę SAMSUNG zachowanie nie jest ograniczone do operacji zapisu. Tak, używanie kolejki jest popularnym sposobem rozwiązania tego problemu. "działa dobrze do tej pory": Trudno jest przetestować i odtworzyć anulowanie polecenia przez inne. Często zdarza się, że napotkasz problemy, gdy kod BLE stanie się bardziej skomplikowany, ponieważ robisz więcej rzeczy na podstawie poprzednich połączeń.Wykonuję tylko następną operację BLE po tym, jak zakończyłem (otrzymałem odpowiedź) lub po tym, jak poprzednia nie zakończyła się w odpowiednim czasie. Przy okazji, twoje komentarze lepiej by pasowały jako odpowiedź na to pytanie. – OneWorld

Odpowiedz

17

Samsung opublikował niedawno „migracji” -document na tę samą stronę, którą podłączyłem w moim pytaniu. Dokładnie odpowiadają na moje pytanie podczas porównywania nowego natywnego API BLE z interfejsem API Samsung BLE:

Nie wpłynęło to na synchroniczny charakter stosu i F/W. Oznacza to, że jeśli nazywamy na przykład writeCharacteristic dla konkretnego charakterystycznym, jeśli zwróci true, następne wywołanie dowolnej BluetoothGatt lub BluetoothGattServer metody powinny być wykonane po otrzymaniu onCharacteristicRead zwrotna. Dzieje się tak dlatego, że stos jest zaprojektowany pod numer , aby obsługiwać i przetwarzać tylko jedno wywołanie GATT naraz, a jeśli dla przykładu wywołasz writeCharacteristic lub readCharacteristic dowolnego characteristic wkrótce po pierwszym, zostanie zignorowany.

+1

Naprawdę cieszę się, że znalazłem to pytanie. Google nie wychodzi z drogi, aby to wyjaśnić. Zwracanie wartości true, gdy żądanie odczytu/zapisu jest w rzeczywistości ignorowane, jest dość mylące. – svens

+2

Czy ktoś może potwierdzić, czy android.bluetooth.BluetoothGatt może obsłużyć tylko jedną oczekującą operację GATT ** NA URZĄDZENIE **, ** W PROCESIE ** lub ** OKRES ** (tj .: we wszystkich procesach). Zakładam, że jest to PER DEVICE, ale ten problem jest tak sfałszowany, że nie zdziwiłbym się, gdyby było inaczej. Jeśli ograniczenie dotyczy tylko urządzenia PER, to OS/urządzenie zdolne do obsługi wielu jednoczesnych operacji jest dowodem na palenie papierosów, że problem ten wynika wyłącznie ze słabej naiwnej implementacji w instancji BluetoothAdapter, że system OS przekazuje każdy proces (który, jak przypuszczałem, był singleton we wszystkich procesach). – swooby

+0

Jest to jedna oczekująca operacja dla każdego obiektu BluetoothGatt. – Emil

-1
  1. Nie. Większość wywołań funkcji jest asynchroniczna.
  2. Nie wiem. Oficjalne dokumenty nie wspominają o tym, ale nie mówią, że obsługuje ono tylko jedno urządzenie. Wierzę, że można to zrobić. Sprawdź ten artykuł: http://blog.lemberg.co.uk/getting-bottom-android-bluetooth-low-energy-api#.UfvK6ZK-1cY

on mówi (nie wiem jaki jest jego źródłem jest), że wiele urządzeń peryferyjnych można podłączyć do jednego urządzenia Android Central

+1

Samsung ble API jest również w pewien sposób asynchroniczny. Otrzymasz odpowiedź w callbacku (interfejs API jest bardzo podobny przy okazji). Jednak jeśli w krótkim czasie wystrzelisz 2 żądania, podczas gdy pierwsza nie jest w pełni rozwinięta, pierwsza może zostać anulowana. Pojawia się więc pytanie, czy natywny interfejs API również ma takie zachowanie. – OneWorld

+0

Ah ok, teraz rozumiem. Nie wiem, czy macierzyste interfejsy API śledzą to zachowanie. Chyba tak. Jeśli uruchomisz 2 scanBLE, poprzednia zostanie anulowana, ale nie jestem tego pewien. – edoardotognoni

Powiązane problemy