summaryrefslogtreecommitdiffstats
path: root/examples
Commit message (Collapse)AuthorAgeFilesLines
* 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(..).
* Catching device loop exception - need to shutdown device while VM running!Sven Gothel2020-05-111-83/+87
| | | | | | | | | | | | | | | | | | ****** Loop 3 Caught: Inconsistent discovered device count: Native 3, callback 1 java.lang.InternalError: Inconsistent discovered device count: Native 3, callback 1 at direct_bt.tinyb.DBTAdapter.removeDevices(DBTAdapter.java:280) at direct_bt.tinyb.DBTAdapter.startDiscovery(DBTAdapter.java:249) at ScannerTinyB01.main(ScannerTinyB01.java:194) ... Exception thrown due to discoveredDevices differences of native / java side. We may resolve this issue or allow such case. However, we need to properly shutdown the native direct_bt before the VM exits - otherwise we won't be able handle the lost Java references. TODO: Add a java shutdown hook!
* HCISession::disconnected: Don't throw exception, intentionally called at ↵Sven Gothel2020-05-112-1/+7
| | | | closing w/o being connected
* Resolving flushed discovered devices and shared device reference usage.Sven Gothel2020-05-111-0/+1
| | | | | | | | | | | | | | | | | | | | | Commit 09cd1183b3599357b05c426e2b59e8df813304c5 describes existed issue in a multi device and hence multi-device-discovery environment. (The change has been reverted) This changed resolves the shared device reference usage, by having adapter maintaining a 'sharedDevices' list in parallel to the 'discoveredDevices'. Adapter will add a newly found and created device to both lists, shared- and discovered devices. Device may remove itself from the sharedDevices list via remove() and its destructor. Adapter will also look in sharedDevices in connected and found callback to determine if a device is known and re-adds it to the discovered devices list for consistency. (Note: discoveredDevices may be flushed via a new startDiscovery)
* ScannerTinyB00/01: stopDiscovery() will not shut down everything using ↵Sven Gothel2020-05-112-4/+0
| | | | | | | | direct_bt, .. .. however, keeping discovery alive while GATT processing will [naturally] slow down performance. Therefor, discovery should be stopped before GATT processing if possible.
* Shape GATTServiceDecl + GATTCharacterisicsDecl into TinyB API conform data ↵Sven Gothel2020-05-111-5/+3
| | | | | | | | | | | | | | | | | | | | relationship GATTServiceDecl: Add DBTDevice reference and 'isPrimary' GATTCharacterisicsDecl: Add GATTServiceDecl reference and remove now obsolete copies of service_uuid and service_handle_end. +++ GattHandler only have ctor w/ DBTDevice reference hence and pass the GATTServiceDeclRef by reference itself (efficiency). +++ TODO: Add the JNI code and complete the GATT Java binding to access native GATTServiceDecl + GATTCharacterisicsDecl mapping and also support the read/write functionality via GATTHandler.
* GATT: GATTPrimaryService -> GATTServiceDecl (-> GATTTypes.hpp) ; Add ↵Sven Gothel2020-05-111-2/+2
| | | | JavaUplink base to GATTCharacterisicsDecl + GATTServiceDecl
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-01 20:47:36 +0000