| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
skipped >= GATTService); GATTHandler owned by DBTDevice, always.
GATTService and childs might need access to their GATTHandler, not just DBTDevice.
This relationship always existed, but was skipped.
Also emphasize that GATTHandler is always owned by DBTDevice, hence has a weak back-reference to the same.
Fixed in ATTPDUTypes C++ Direct-BT API doc overview.
Further impact:
- GATTService has a weak back-reference to GATTHandler instead of DBTDevice,
DBTDevice reference will then be picked up from GATTHandler, the usual.
- GATTHandler::discoverPrimaryServices(..), discoverCompletePrimaryServices(..)
needs to receive GATTHandler's shared_ptr from owner and caller to build the back-reference in GATTService
|
| |
|
|
| |
init-list of ctor
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'connect' lifecycle
Further:
- L2CAPComm
-- disconnect(): Only lock mtw_write if connected and mark noexcept
-- Added '~L2CAPComm() noexcept' for RAII
-- Removed unsued accessors
- GATTHandler
-- Similar treatment as L2CAPComm
- DBTDevice
-- Remove mtx_gatt and its locks, they were not consistent.
Rely on mtx_connect (connectGATT/getGATTServices/disconnect)
and atomic local GATTHandler copy when using.
-- disconnect GATTHandler directly in disconnect, remove explicit method.
-- pingGATT uses local gattHandler copy to avoid parallel disconnect nullptr,
however, it will fail immediately due to disconnection.
|
| |
|
|
| |
The \example tag referring to the example code file must be added to the actual API (header) files.
|
| |
|
|
|
|
| |
depenencies, build, ..); Add \example tag in examples.
For unknown reason, examples are not visible in result.
|
| | |
|
| |
|
|
| |
declaration where needed; Fix source accordingly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
initialization; DBTManager: Validate enabled for non-user default adapter.
DBTAdapter: Have non-enabled adapter to be valid, use lazy HCI initialization
In a multi adapter setting, it is possible to have one adapter not being enabled,
i.e. blocked from operations (e.g. rfkill).
HCI communication is not possible in such cases and 'openHCI()' will fail.
We still need to treat such adapter as valid, as they are,
and distinguish the states: 'valid' and 'enabled'.
This allows 'delivery' of all adapters to a manager
and allows querying whether they are enabled.
Therefor, the native DBTAdapter will not issue an aggregated 'openHCI()'
at construction and initial validation, but treat the HCI instance as a singleton
to be lazily created via 'getHCI()' if not yet existing.
Here the required listener are also attached to the instance.
In the future, this shall also allow dynamically adding/removing
and enabling/disabling adapters.
Hence before using a chosen adapter, one should query its enabled state
via 'isEnabled()', which will also potentially initializing HCI.
+++
DBTManager: Validate enabled for non-user default adapter.
On the Java side, we can chose a default adapter via the property 'org.tinyb.default_adapter'.
If so chosen, it shall be the default adapter, regardless of its 'enabled' state.
Otherwise, the default adapter shall be the first enabled adapter in the list.
|
| |
|
|
|
|
|
|
|
|
| |
(C++/Java) and BluetoothDevice.java
To help tracking a device in user space and support more 'down to the metal' access,
the HCI connection handle has been exposed to the Java DBTDevice
and the AdapterStatusListener.
For the latter, especially disconnectDevice(..) is of interest,
since the disconnected handle is lost already when the callback gets invoked.
|
| |
|
|
|
|
|
| |
of just boolean, passing through potential HCI error detail
The HCIStatusCode on failed connect*/disconnect commands issued via direct_bt HCI,
could help applications making a better fail-recovery decision than just having the binary result.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Aligned all related C++ and Java API doc entries and made sure it matches implementation.
- Renaming SpecificGATTCharacteristicListener to AssociatedGATTCharacteristicListener,
as we refer to the associate GATTCharacteristic of a GATTCharacteristicListener
AssociatedGATTCharacteristicListener is a specialization knowing its
associated GATTCharacteristic to be used for match().
- Renamed 'configIndicationNotification(..)' to 'configNotificationIndication(..)',
matching order of arguments and the returned enabledState array.
- Exposed 'configNotificationIndication(..)' incl enabledState array to Java
- Clarified the 'add listener' and 'configNotificationIndication(..)' semantic in API doc
and implementation. Added new API entries to distinguish them.
- DBTGattCharacteristic.java skips adding its 'TinyB API compatibility' GATTCharacteristicListener
in case neither notify nor indicate property exist.
Also skip the native configNotificationIndication(..) in such case.
This reduces the overall listener load to GattHandler by factor 5!
- General: Add new method 'removeAllAssociatedCharacteristicListener(GATTCharacteristic)',
allowing removal of all GATTCharacteristic associated listener.
This is usefull to complete the GATTCharacteristic C++ dtor or Java close() operation.
- DBTDevice: Add GATTCharacteristicListener methods to align with Java API
and allow user not to deal with GATTHandler directly.
Convenience and validates the C++/Java API alignement.
- C++ JNICriticalArray: Added 2nd template typename for the java-array-type,
enabling it for other than jbyteArray. Here used for a jbooleanArray.
- The GATTCharacteristicListener Java to C++ native holding specialization JNICharacteristicListener
keeps a new global reference to the Java GATTCharacteristicListener
and the optional associated GATTCharacteristic.
This ensures the instances won't get garbage collected and hence ensures proper
object lifecycle even when passing 'throw away' listener object created just
for the add*Listener call.
- Removal and hence destruction of the listeners is always guaranteed at:
-- Device / GATTHandler disconnect
-- GattCharacteristic dtor or close
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
lifecycle)
Since HCIHandler is being used to track all connections (direct or whitelisted),
it is essential to have it running over the whole adapter lifecycle.
openHCI() is now being performed within validateDevInfo(),
hence also sets adapter's valid state.
Call newly added checkValid() in user API on most 'action' methods,
throws exception if adapter is in invalid state.
|
| |
|
|
| |
GATTHandler::State for L2CAPComm::State
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
(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.
|
| |
|
|
| |
DBTDevice::toString(..) defaults to not incl. services
|
| |
|
|
|
|
| |
ignore a failure as connect will happen
Investigating this situation a bit further.
|
| |
|
|
|
|
| |
min/max ce_len,filter params
Show device on connection failure.
|
| |
|
|
|
|
|
|
|
|
|
| |
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!
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
HCIComm directly
|
|
|
'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
|
