summaryrefslogtreecommitdiffstats
path: root/examples
Commit message (Collapse)AuthorAgeFilesLines
* Support BDADDR_LE_RANDOM (p1): Add BLERandomAddressType, distinguish ↵Sven Gothel2020-07-022-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | HCIAddressType..., Move EUI48 into direct_bt namespace Add BLERandomAddressType Exposed in DBTDevice and BluetoothDevice C++ and Java. See "BT Core Spec v5.2: Vol 6 LE, Part B Link Layer Specification: 1.3.2 Random device Address" +++ Distinguish HCIAddressType -> HCILEPeerAddressType + HCILEOwnAddressType As used for HCIHandler::le_create_conn(..) See "BT Core Spec v5.2: Vol 4, Part E Host Controller Interface (HCI) Functionality: 7.8.12: LE Create Connection command" DBTDevice::connectLE(..) translates its own BDAddressType -> HCILEPeerAddressType using BLERandomAddressType (BDAddressType, address). Currently only HCILEPeerAddressType::STATIC_PUBLIC is allowed and passed through. +++ Move EUI48 into direct_bt namespace
* Resolve circular references (p3): Java: Ensure DBTDevice can be GC'ed (at ↵Sven Gothel2020-06-291-8/+3
| | | | | | | | | | | | | | | | | | | | | | | remove()) DBTDevice.close() - Also issue adapter.removeDiscoveredDevice(this); Without, the Java DBTDevice wouldn't get GC'ed - close(): super.close() -> delete() -> deleteImpl() -> DBTDevice::remove() DBTDevice.remove() - Simply calls close(), implying DBTDevice::remove() and complete reference cleanup. ScannerTinyB10: - argument '-debug' to enable DEBUG/VERBOSE DBTAdapter.cxx: - Just give more clarity on DBTDevice.java creation and delete local ref. DBTDevice.cxx:: getServices() JNI - No need to call device->connectGATT()
* Resolve circular references (p1): C++ GATTHandler, GATTService, pp are not ↵Sven Gothel2020-06-292-70/+115
| | | | | | | | | | | | | | | | | | | | owner of their resepctive backreference GATTHandler, GATTService, pp are not owner of their resepctive backreference, hence use std::weak_ptr for backreferences in general and validate on usage (nullptr, if destructed). No DBTDevice has been ever destructed after using GATTHandler and discovering all GATT services. In contrast to Java, C++ has no magic GC and hence shared_ptr use_count gets only increased when emplying circular backreferences - none gets destructed. Current ownership relationship is: DBTAdapter -> DBTDevice -> GATTHandler -> GATTService ... each contains a backreference, now using a weak_ptr. Result is that depending on the use-case, DBTDevice instances are destructed: - Using device->remove(): Immediately - No explicit device->remove(): Adapter keeps sharedDevices, destruction occurs at end.
* ScannerTinyB10: Allow waiting for multiple devices.Sven Gothel2020-06-282-14/+14
|
* Use HCIHandler *connect*/disconnect; Enhance native + java testSven Gothel2020-06-272-9/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Use HCIHandler *connect*/disconnect incl related events (Drop DBTManager in this regard) > Add CONNECT_FAILED HCI listener mgmtEvConnectFailedHCI -- Issuing a DISCONNECT event > DBTAdapter: mgmtEvDeviceConnectedHCI -- Always pass through, just issue WARNING if not a new_connect (TBD) > DBTAdapter: mgmtEvDeviceDisconnectedHCI + mgmtEvDeviceConnectedHCI -- removeConnectedDevice pre event issuing -- removeDiscoveredDevice post event issuing > DBTDevice: -- Add isConnectIssued to differentiate isConnected on event -- Only use HCIHandler's *connect*/disconnect -- disconnect(..) no more issues removeConnectedDevice, rely ion correct event issuing/handling, as performed in time @ mgmtEvDeviceDisconnectedHCI... -- remove() issues removeConnectedDevice and removeDiscoveredDevice pre releaseSharedInstance to ensure a clean tracking state. The whole purpose of this command. +++ Enhance native + java test After disconnect() wait (poll) until no more connected, before issuing remove(), this shall ensure proper workflow pre remove() - validation of disconnect command.
* test/example: dbt_scanner10 + ScannerTinyB10: Add options MULTI_MEASUREMENTS ↵Sven Gothel2020-06-262-22/+77
| | | | | | | | | | | and KEEP_CONNECTED Defaults: MULTI_MEASUREMENTS=true, KEEP_CONNECTED=true MULTI_MEASUREMENTS won't end application but continues and allows multiple 'measurements' KEEP_CONNECTED won't do a programmatic disconnect @ completed processing but issues device->pingGATT() until a disconnect is detected.
* ScannerTinyB01/02: Use TO_CONNECT and actually only wait 100ms in polling ↵Sven Gothel2020-06-182-7/+13
| | | | cycle, allowing TO detection
* Add debugging tool ScannerTinyB02; ScannerTinyB01 adds any device option.Sven Gothel2020-06-183-10/+448
|
* scanner example 10 (C++/Java): Add more detailed PERFormance numbersv2.1.4Sven Gothel2020-06-102-11/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Comparing native and java performance numbers: - similar results - java seems to be less responsive, esp for CONNECT - CONNECT performance in general seems to vary a lot and brings down overal performance Native: ========== dbt10-native-01.log:PERF: adapter-init -> FOUND__-0 292 ms dbt10-native-01.log:PERF: adapter-init -> CONNECTED-0 2489 ms dbt10-native-01.log:PERF: GATT primary-services completed dbt10-native-01.log:PERF: adapter-init to processing-start 2499 ms, dbt10-native-01.log:PERF: get-gatt-services 1117 ms, dbt10-native-01.log:PERF: discovered to gatt-complete 1127 ms (connect 10 ms), dbt10-native-01.log:PERF: adapter-init to gatt-complete 3616 ms dbt10-native-02.log:PERF: adapter-init -> FOUND__-0 317 ms dbt10-native-02.log:PERF: adapter-init -> CONNECTED-0 572 ms dbt10-native-02.log:PERF: GATT primary-services completed dbt10-native-02.log:PERF: adapter-init to processing-start 577 ms, dbt10-native-02.log:PERF: get-gatt-services 1108 ms, dbt10-native-02.log:PERF: discovered to gatt-complete 1113 ms (connect 5 ms), dbt10-native-02.log:PERF: adapter-init to gatt-complete 1685 ms dbt10-native-03.log:PERF: adapter-init -> CONNECTED-0 1865 ms dbt10-native-03.log:PERF: GATT primary-services completed dbt10-native-03.log:PERF: adapter-init to processing-start 1872 ms, dbt10-native-03.log:PERF: get-gatt-services 1502 ms, dbt10-native-03.log:PERF: discovered to gatt-complete 1510 ms (connect 8 ms), dbt10-native-03.log:PERF: adapter-init to gatt-complete 3374 ms dbt10-native-04.log:PERF: adapter-init -> FOUND__-0 459 ms dbt10-native-04.log:PERF: adapter-init -> CONNECTED-0 715 ms dbt10-native-04.log:PERF: GATT primary-services completed dbt10-native-04.log:PERF: adapter-init to processing-start 727 ms, dbt10-native-04.log:PERF: get-gatt-services 1108 ms, dbt10-native-04.log:PERF: discovered to gatt-complete 1120 ms (connect 12 ms), dbt10-native-04.log:PERF: adapter-init to gatt-complete 1835 ms Java: ========== dbt10-java-01.log:PERF: adapter-init -> FOUND__-0 1866 ms dbt10-java-01.log:PERF: adapter-init -> CONNECTED-0 2343 ms dbt10-java-01.log:PERF: GATT primary-services completed dbt10-java-01.log:PERF: adapter-init to processing-start 2352 ms, dbt10-java-01.log:PERF: get-gatt-services 1118 ms, dbt10-java-01.log:PERF: discovered to gatt-complete 1128 ms (connect 10 ms), dbt10-java-01.log:PERF: adapter-init to gatt-complete 3470 ms dbt10-java-02.log:PERF: adapter-init -> FOUND__-0 1046 ms dbt10-java-02.log:PERF: adapter-init -> CONNECTED-0 1299 ms dbt10-java-02.log:PERF: GATT primary-services completed dbt10-java-02.log:PERF: adapter-init to processing-start 1310 ms, dbt10-java-02.log:PERF: get-gatt-services 1119 ms, dbt10-java-02.log:PERF: discovered to gatt-complete 1135 ms (connect 16 ms), dbt10-java-02.log:PERF: adapter-init to gatt-complete 2429 ms dbt10-java-03.log:PERF: adapter-init -> FOUND__-0 1626 ms dbt10-java-03.log:PERF: adapter-init -> CONNECTED-0 1870 ms dbt10-java-03.log:PERF: GATT primary-services completed dbt10-java-03.log:PERF: adapter-init to processing-start 1883 ms, dbt10-java-03.log:PERF: get-gatt-services 1132 ms, dbt10-java-03.log:PERF: discovered to gatt-complete 1147 ms (connect 15 ms), dbt10-java-03.log:PERF: adapter-init to gatt-complete 3015 ms dbt10-java-04.log:PERF: adapter-init -> FOUND__-0 189 ms dbt10-java-04.log:PERF: adapter-init -> CONNECTED-0 441 ms dbt10-java-04.log:PERF: GATT primary-services completed dbt10-java-04.log:PERF: adapter-init to processing-start 454 ms, dbt10-java-04.log:PERF: get-gatt-services 1131 ms, dbt10-java-04.log:PERF: discovered to gatt-complete 1145 ms (connect 14 ms), dbt10-java-04.log:PERF: adapter-init to gatt-complete 1585 ms
* DBTDevice (C++/Java): Expose getLastDiscoveryTimestamp() and rename ↵Sven Gothel2020-06-092-4/+4
| | | | | | | lastUpdate: getLastUpdateTimestamp() For performance measurement discovery -> gatt complete, we need to use the last discovery timestamp, since the device could have been created earlier.
* Event driven C++/Java scanner 10 example: Issue stopDiscovery() @ ↵Sven Gothel2020-06-092-1/+3
| | | | | | | processConnectedDevice(), ensuring a pending connection command from a failed connect*(..) attempt will also have discovery disabled.
* Expose 'org.tinyb.verbose' and 'org.tinyb.debug' via BluetoothFactory ↵Sven Gothel2020-06-091-0/+1
| | | | VERBOSE and DEBUG. Use the latter in DBTManager.
* L2CAPComm/GATTHandler: User 'enum class' constants for type safety; Drop ↵Sven Gothel2020-06-093-4/+4
| | | | GATTHandler::State for L2CAPComm::State
* BasicTypes: Rename getUTF8String(..) -> decodeUTF8String(..): Adding API doc ↵v2.1.2Sven Gothel2020-06-044-4/+4
| | | | section with reference to used algo
* Rename HCIErrorCode -> HCIStatusCode for clarity and pleasing the eyesSven Gothel2020-06-045-10/+10
|
* Introduce HCITypes + HCIHandler: Providing C++ basics for full HCI support; ↵Sven Gothel2020-06-044-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Misc.. Introduce HCITypes + HCIHandler: Providing C++ basics for full HCI support ============================================================================ - HCITypes defines the HCI command and event data structures, similar to MgmtTypes and ATTPDUTypes. For more coding efficiency we use template command and event classes, allowing to reuse the HCIIoctl struct types being wrapped in the C++ classes for flow and lifecycle control. HCITypes further includes all essential 'enum class' command opcodes, event types etc, ensuring type safety. - HCIHandler defines the command/event workflow similar to GATTHandler and DBTManager. One HCIHandler per DBTAdapter is being used, each HCIHandler using its event reader thread and ringbuffer. Socket event filtering and manual le-meta filtering ensures reduced workload (DoS safety). Similar to HCITypes, we use template function to utilize the template command and event classes, reuising the HCIIoctl struct types... HCIHandler can be extended for more functionality as well as used to implement our own DBTManager, i.e. Reducing HCIEvents to MgmtEvents with callback support. At least this is a viable option now, if so desired (non-linux, etc). - HCIComm: Contains the core I/O functionality only, dropped all semantic HCI code. The latter resides in HCIHandler now. - DBTAdapter now uses HCIHander instead of HCIComm, renamed field to simply 'hci' Misc.. ======= - reduced all ringbuffer capacity to 128 from 256 - Moved Mgmt*EventCallback from DBTManager to MgmtTypes, as we might want to reuse the MgmtTypes incl callbacks for alternative DBTManager implementations. - Added 'enum class' to underlying number type conversion pattern: <NumberType> number('enum class type') Avoiding the many static_cast<NumberType>(..) directives. - align all Type -> String method names: 'get<Type>String(Type)' - BasicTypes: Add safe uint32_t bitfield mask helper
* dbt_scanner10.cpp: Add missing CRSven Gothel2020-06-011-1/+1
|
* AdapterStatusListener(C++/Java): Expose 'HCIErrorCode reason' on disconnect ↵Sven Gothel2020-05-315-41/+56
| | | | | | | (split deviceConnectionChanged up), align args of deviceUpdated The 'HCIErrorCode reason' gives us valuable information of the disconnect reason, hence we shall expose it to the user level on the C++ and Java side.
* C++/Java Scanner 10: Refine found/connect criteria: Also in EUI48_ANY_DEVICE ↵Sven Gothel2020-05-312-16/+15
| | | | case, skip devices-in-processing
* Aligned Java scanner 10 w/ native example (working error recovery); Tolerant ↵Sven Gothel2020-05-302-48/+38
| | | | | | | | | DBTAdapter.removeDevices(). DBTAdapter.removeDevices() must behave tolerant on inconsistent discovered device count in case of an error. Both scanner examples behave properly on a forced disconnect test during GATT processing using the thrown C++ exception (fwd to Java) and receiving the DISCONNECT event.
* Simplify dbt_scanner10.cpp: Only WHITELIST and !WHITELIST discovery mode, ...Sven Gothel2020-05-301-98/+52
| | | | | | | | - Only WHITELIST and !WHITELIST discovery mode, remove confusion of 'esotheric' use case 'keepDiscovery' - Use simple address lists for processed and processing devices - Catch exception while processing GATT and add device processed on success
* ScannerTinyB10: No need to explicitly remove Characteristic listener before ↵Sven Gothel2020-05-291-4/+1
| | | | disconnect
* C++/Java scanner test 10: task function renaming to a more suitable nameSven Gothel2020-05-292-19/+19
|
* Multi-device and -threading examples *10 (java and native): Only attempt ↵Sven Gothel2020-05-282-16/+6
| | | | | | | | | | | | | connection to BDADDR_LE_PUBLIC BDADDR_LE_RANDOM connection attempts to some foreign BLE devices 'floating around' causes the HCI sub-system to 'give up', i.e. no more connection will be possible after a number of failures. This is the use case w/o whitelist and without filtering for a specific MAC. It seems that the following configurations (use cases) are stable: - filter for a specific MAC and connect to these only - use autoconnect whitelist to specific MAC
* Java DBTDevice: Drop getGATTService() from connect* as it should be done ↵Sven Gothel2020-05-281-1/+3
| | | | | | | after connect callback @ device.getServices() This is due to a potential relaxed connect* handling, therefor we shall only go one step further with GATT services after determining a proper connection. WIP.
* AdapterStatusListener (C++): Add toString() for error handling purposes; ↵Sven Gothel2020-05-283-14/+26
| | | | DBTDevice::toString(..) defaults to not incl. services
* ScannerTinyB10: Multi-device and -threading Java example equivalent to C++ ↵Sven Gothel2020-05-281-287/+274
| | | | | | | | | | dbt_scanner10 Some issues still: - disconnect HCI command failure (same w/ native code, need to check) - Whitelist command OK but no connection at all. '-mac address' use-case is working
* dbt_scanner00/10, ScannerTinyB01: Use getUTF8String(..) for GATT ↵Sven Gothel2020-05-283-108/+59
| | | | Characteristic values, exposing human readable string portions
* HCI le_connect: COMMAND_DISALLOWED handled 'softer' / applications may ↵Sven Gothel2020-05-274-2/+4
| | | | | | ignore a failure as connect will happen Investigating this situation a bit further.
* DBTDevice.cpp: Use openHCI() instead of getHCI(), i.e. implicit open if ↵Sven Gothel2020-05-272-16/+0
| | | | required - soothing API usage and JNI binding as well
* dbt_scanner10.cpp: startDiscovery( keepAlive=true ) if connector thread ↵Sven Gothel2020-05-261-1/+1
| | | | failed in block_discovery mode
* GATTHandler/L2CAPHandler: Thread safety and interrupt hanging L2CAP ::connect()Sven Gothel2020-05-261-1/+3
| | | | | | | | | | | | | | | | | In both classes, certain fields must be handled atomic to avoid data race conditions. GATTHandler: Store pthread_id of l2capReaderThread at creation before detaching, since post detach the pthread_id native_handle() is null. L2CAP's ::connect() call must be interruptable by it's disconnect to avoid a long timeout hang. DBTDevice's notifyDisconnected() issues a disconnect() on GATTHandler and L2CAPComm. +++ This change set enables recovery of attempting to process a 'non GATT responding' device. The DISCONNECT event breaks up the connection attempt, as being sent for such devices by the adapter.
* dbt_scanner10.cpp: More verbose info message showing handled device in a ↵Sven Gothel2020-05-261-2/+2
| | | | multi-device-threading test
* DBTDevice/HCIComm: More 'snappy' connect method names and drop unused LE ↵Sven Gothel2020-05-253-4/+4
| | | | | | min/max ce_len,filter params Show device on connection failure.
* DBTDevice::getGATTServices(): Reuse GATTHandler's list result, retrieve ↵Sven Gothel2020-05-253-20/+39
| | | | | | | | | | | GenericAccess after GATT discovery and update data (name) As there is no need to discover the GATT services more than once, we shall reuse the already stored GATTService list in GATTHandler. For the auto-connect whitelist use case (dbt_scanner10) w/o _any_ HCI discovery, the connected LE device has no name set. Hence we retrieve the GATT GenericAccess data and update the DBTDevice's name and appearance. Eventually after getGATTServices(), the device name is set!
* Fix listener notice for discovering and connection (enabled and add connected)Sven Gothel2020-05-243-5/+5
|
* AdapterStatusListener (C++/Java): Add discoveringChanged(..), converge ↵Sven Gothel2020-05-246-46/+52
| | | | | | | | | | | | | | | | | | | | | deviceConnected/deviceDisconnected Add discoveringChanged(..), as it is of high interest to the user to adjust connect/disconnect and GATT operations. Hence add it to this central adapter listener, also being used to synthesize the old fashion TinyB 'discovering' callback. We also expose the 'keepAlive' flag in this callback to the user. Converge deviceConnected(..)/deviceDisconnected(..) -> deviceConnectionChanged(..) to be a bit more efficient. +++ DBTAdapter: keepAlive in startDiscovery defaults to false, aligned w/ TinyB. A new startDiscovery(..) method has been added to the Java API, also adding keepAlive. +++ Java TODO: Add the whitelist add/remove functionality
* Fix Whitelist to DBTManager/DBTAdapter and test (Result: Auto-connection but ↵Sven Gothel2020-05-241-23/+21
| | | | | | | | | | | | | | | | | | | | | | 1+ second slower) Essential for the whitelist autoconnect is the 'action' parameter, which is now declared as HCIWhitelistConnectType (BTTypes). BlueZ Linux kernel sources describe the semantics. We are now technically enabled to use the auto-connect and don't even required a discovery phase. However, the device name is not included in the connect EIR data. Further, performance lacks heavily similar to no connect and is more than 1s slower than our procedure below: - startDiscovery - device-found - stopDiscovery - connect - GATT operation ... - startDiscovery
* Add Whitelist to DBTManager/DBTAdapter and test (Result: No auto-connection)Sven Gothel2020-05-241-31/+64
| | | | | | | To avoid the hassle with HCI connect/disconnect while scanning, we should test the whitelist supposed to be stored on the adapter to auto-connect. Initial testing didn't show any connection.
* ScannerTinyB10.java needs to be aligned to dbt_scanner10.cpp for ↵Sven Gothel2020-05-241-0/+422
| | | | multithreading test
* dbt_scanner10 (multithread): Only halt discovery for hci-connect and ↵Sven Gothel2020-05-241-0/+24
| | | | | | | | | | | | | -disconnect, try all LE devices TODO: Incorporate the discovery halt in the API .. maybe + device->getAdapter().stopDiscovery(); + device->disconnect(); + device->getAdapter().startDiscovery(); However, a running discovery reduces GATT performance and should be adjusted with the application logic.
* C++ multithreading fixes and exampleSven Gothel2020-05-243-16/+393
| | | | | | | | | | | | | | | | | | | | | DBTAdapter: - Add HCI mutex - openHCI() returns already open HCIComm - Notify device on disconnected DBTDevice: - Add data mutex, covering race-condition on data update(..) and data usage - notifyDisconnected(): Clear hciConnHandle - getServices() -> getGATTServices() to differenciate from scan-result +++ Java/JNI DBTAdapter: - Remove open/openImpl() in favor of implicit openHCI() @ connect call. +++ Added multithreading example dbt_scanner10.cpp
* Examples: Set COMPILE_FLAGS "-Wall -Wextra -Werror"Sven Gothel2020-05-235-14/+35
|
* DBTAdapter: Remove explicit HCISession, migrate connectedDevice and use ↵Sven Gothel2020-05-234-11/+28
| | | | HCIComm directly
* Expose UUID strings in TinyB compatible fashion (unified uuid128_t) as an ↵Sven Gothel2020-05-181-21/+16
| | | | | | | | | | | | | option (default = true) Via DBTManager.setUnifyUUID128Bit(boolean): Enables or disables uuid128_t consolidation for native uuid16_t and uuid32_t values before string conversion. Default is {@code true}, as this represent compatibility with original TinyB D-Bus behavior. If desired, this value should be set once before the first call of {@link #getBluetoothManager()}!
* Working GATT Java Side; GATT Types made fully functional for user to avoid ↵Sven Gothel2020-05-175-112/+391
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'technical' GATTHandler GATT Types made fully functional for user to avoid 'technical' GATTHandler (C++) > GATTService, GATTCharacteristic, GATTDescriptor -- Reside in their own respective files -- Added semantic methods (readValue(), ..) implemented using DBTDevice -> GATTHandler -- GATTDescriptor owns its value -- GATTHandler setSendIndicationConfirmation(..) defaults to true -- Allow user to cirvumvent using GATTHandler manually completely, device 1--*> services 1--*> characteristics 1--*> descriptor -- C++ GATT types aligned 1:1 to TinyB (Java) > Merged GATTIndicationListener + GATTNotificationListener -> GATTCharacteristicListener -- Simplifying usage, unifying notification and indication -- Now using a list of shared_ptr<GATTCharacteristicListener> allowing multiple actors instead of just a one shot entry. Similar to AdapterStatusListener, we utilize this also on the Java side to implement the TinyB notifications. See dbt_scanner00.cpp: Simplified high-level usage. See dbt_scanner01.cpp: Lower-level technical usage w/ GATTHandler. +++ > Simplified more names > Removed redundancy in listener callbacks, -- don't pass adapter when device is already given. device <*--1> adapter -- don't pass GATT handle explicitly when characteristic is passed > Comparison of all GATT types are done by their respective unique handle Attribute handles are unique for each device (server) (BT Core Spec v5.2: Vol 3, Part F Protocol..: 3.2.2 Attribute Handle) > GATTHandler: Own L2CAPComm instance directly, instead of shared_ptr. > JNIMem: Added JNICriticalArray class for RAII style release ++++ ++++ Working GATT Java Side > All toString() methods return the C++ toString() via JNI for better representation. > DBTDevice.java/JNI: Resolved the odd 'adapter' reference issue: -- Was not passing the jobject of DBTAdapter, but its shared container refeference ;-) > All GATT types receive their GATT handler for equal test and identity @ ctor > GATT read/write Value update the cached value as well as issue the notifyValue on change, including GATTCharacteristic notification/indication listener
* GATT Cleanup of method + field names; GATT discoverDescriptors: Use more ↵Sven Gothel2020-05-151-2/+2
| | | | | | | | | | | | | | | | | | | | reasonable and efficient traversal... GATT Cleanup of method + field names - the service and characteristic uuid's specify types, hence name field *type* being of value-type uuid_t. - use short and clear names like 'Characteristic' and simply 'Descriptor' for 'Characteristic Descriptor'. - etc etc GATT discoverDescriptors: Use more reasonable and efficient traversal through Charactecteristics - Previous we traversed through all handle of services for Descriptors, only to find the matching Charactecteristic to attach to. The latter was done via another loop through all Charactecteristic and hence even reduced performance by one magnitude. Further, not all handles reflect Descriptors ;-) - Simply iterate through all Charactecteristic and find their Descriptors within their value handle range as per BT spec. Also read the Descriptor value right away.
* GATT Service and Characteristic Java <-> JNI binding (incomplete, TODO ↵Sven Gothel2020-05-141-3/+3
| | | | Descriptor)
* C++ GATT: Cleanup and complete Descriptor <*-1> Characteristic <*-1> ServiceSven Gothel2020-05-141-11/+12
| | | | | | | | | | | | Cleanup GATT type names aligned to TinyB. Remove unused types. Complete relationship: Descriptor <*-1> Characteristic <*-1> Service, read all Descriptor with value instead of only ClientCharacteristicConfig. Prepate for GATT Descriptor: Extended properties etc, TODO: parse! Add JavaUplink, preparing for JNI.
* Fixing multiple Java/C++ Lifecycle Issues (DBTDevice, add ShutdownHook, ..)Sven Gothel2020-05-121-6/+12
| | | | | | | | | | | | | | | | | | | | | | DBTDevice - don't native delete @ JNI deleteImpl, adapter holds share_ptr ownership - only create its java object 1st time @ deviceFound callback of JNI DBTAdapter DBTAdapter::mgmtEvDeviceFoundCB - in case of !discoveredDeviceList but sharedDeviceList, the device shall be updated first, then deviceFound callbacks issued, allowing listener to act and register, then deviceUpdate callbacks issued, allowing data update on existing actors DBTManager.java: - Add ShutdownHook calling custom hooks and shutdown() - shutdown() in depth shutdown: -- iterated through all adapter issueing adapter.close() -- Adapter.close() iterates through all discoveredDevices issuing close() DBTDevice.java: - adds adapter JNI proxy to removeStatusListener(..), same 'to be resolved' issue as with addStatusListener(..).
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-03 23:02:50 +0000