This makes it possible to pass all IV Update tests without having to
build a custom configuration for some of the tests. We also disable
the feature in all sample configurations, but leave it on in the
tests.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Model publication was broken in a couple of ways:
- The Publish Retransmit State was not taken into account at all
- Health Server used a single publish state for all elements
To implement Publish Retransmit properly, one has to use a callback to
track when the message has been sent. The problem with the transport
layer sending APIs was that giving a callback would cause the
transport layer to assume that segmentation (with acks) is desired,
which is not the case for Model Publication (unless the message itself
is too large, of course). Because of this, the message sending context
receives a new send_rel ("Send Reliable") boolean member that an app
can use to force reliable sending.
Another challenge with the Publish Retransmit state is that a buffer
is needed for storing the AppKey-encrypted SDU once it has been sent
out for the first time.To solve this, a new new net_buf_simple member
is added to the model publication context. The separate 'msg' input
parameter of the bt_mesh_model_publish() API is removed, since the
application is now expected to pre-fill pub->msg instead.
To help with the publishing API change, the Health Server model gets a
new helper macro for initializing the publishing context with a
right-sized publishing message.
The API for creating Health Server instances is also redesigned since
it was so far using a single model publishing state, which would
result in erratic behavior in case of multiple elements with the
Health Server Model. Now, the application needs to provide a unique
publishing context for each Health Server instance.
The changes are heavily intertwined, so it's not easily possible to
split them into multiple patches, hence the large(ish) patch.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
It may be useful for the app to know what the initial NetKeyIndex that
it was given during provisioning is.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This is in anticipation of soon adding health client support, which
could then cause confusion due to the ambiguous API names.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Now that there's support for configuration client as well, rename cfg
to cfg_srv to avoid any confusion.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Add the ability to track the provisioning bearer through an extra
parameter to link_open/close. Also introduce new public functions to
enable/disable specific provisioning bearers. This also means that one
now needs to explicitly enable provisioning bearers after calling
bt_mesh_init().
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Avoid applications defining empty model arrays by themselves by
documenting the BT_MESH_MODEL_NONE helper macro (renamed to be more
intuitive) and using it in the mesh sample app.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Introducing CMake is an important step in a larger effort to make
Zephyr easy to use for application developers working on different
platforms with different development environment needs.
Simplified, this change retains Kconfig as-is, and replaces all
Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild
offers is replaced by a set of CMake extentions. These extentions have
either provided simple one-to-one translations of KBuild features or
introduced new concepts that replace KBuild concepts.
This is a breaking change for existing test infrastructure and build
scripts that are maintained out-of-tree. But for FW itself, no porting
should be necessary.
For users that just want to continue their work with minimal
disruption the following should suffice:
Install CMake 3.8.2+
Port any out-of-tree Makefiles to CMake.
Learn the absolute minimum about the new command line interface:
$ cd samples/hello_world
$ mkdir build && cd build
$ cmake -DBOARD=nrf52_pca10040 ..
$ cd build
$ make
PR: zephyrproject-rtos#4692
docs: http://docs.zephyrproject.org/getting_started/getting_started.html
Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
From section 3.4.5.3 in the Mesh Profile Specification 1.0:
"A node shall implement a Local Network Interface."
Removing the Kconfig option also helps clean up quite a lot of code.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Rename the BT_CONTROLLER prefix used in all of the Kconfig variables
related to the Bluetooth controller to BT_CTLR.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The API name space for Bluetooth is bt_* and BT_* so it makes sense to
align the Kconfig name space with this. The additional benefit is that
this also makes the names shorter. It is also in line with what Linux
uses for Bluetooth Kconfig entries.
Some Bluetooth-related Networking Kconfig defines are renamed as well
in order to be consistent, such as NET_L2_BLUETOOTH.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Count of 4 seems to cause deadlocks with some Android phones due to
other GATT activity in addition to Mesh related data.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
There's no need for debug logs by default in the mesh sample, and it
just contributes excessively to the ROM footprint.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Not easily done using RAM/ROM filters, configurations need to be adapted
to make this fit on more devices. Limit the target platforms now while
we figure out configurations.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add an initial implementation for the Bluetooth Mesh Profile
Specification. The main code resides in subsys/bluetooth/host/mesh and
the public API can be found in include/bluetooth/mesh.h. There are a
couple of samples provided as well under samples/bluetooth and
tests/bluetooth.
The implementation covers all layers of the Bluetooth Mesh stack and
most optional features as well. The following is a list of some of
these features and the c-files where the implementation can be found:
- GATT & Advertising bearers (proxy.c & adv.c)
- Network Layer (net.c)
- Lower and Upper Transport Layers (transport.c)
- Access Layer (access.c)
- Foundation Models, Server role (health.c & cfg.c)
- Both PB-ADV and PB-GATT based provisioning (prov.c)
- Low Power Node support (lpn.c)
- Relay support (net.c)
- GATT Proxy (proxy.c)
Notable features that are *not* part of the implementation:
- Friend support (initial bits are in place in friend.c)
- Provisioner support (low-value for typical Zephyr devices)
- GATT Client (low-value for typical Zephyr devices)
Jira: ZEP-2360
Change-Id: Ic773113dbfd84878ff8cee7fe2bb948f0ace19ed
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Anas Nashif