merging #BluetoothMesh into #SoftDevice ?

[vikrant8051]

I think instead of releasing separate SDK for #BluetoothMesh, Nordic Semiconductor should merge #BluetoothMesh into #SoftDevice. Is it possible ?

If yes, then we can even add support for all Models defined by Bluetooth_SIG in it.

Firmware app developer will only enable feature of MESH & required Models using preprocessor like

#define Bluetooth_Mesh  
#define GEN_ONOFF_SRV_MODEL  
#define GEN_ONOFF_CLI_MODEL  
#define GEN_LEVEL_SRV_MODEL ...etc....etc...  

Then internally all functions within every Model (which are part of #SoftDevice) will transfer control to one function let's say foo(model, ctx, buf, OPCODE).

With foo() Firmware app developer could do whatever he wants like ......

void foo(struct bt_mesh_model *model, struct bt_mesh_msg_ctx *ctx, struct net_buf_simple *buf, uint16_t opcode)
{
	switch(opcode)
	{

		case 0x8201:	//GEN_ONOFF_SRV_GET
  
                                       // firmware App's Logic

                                      break;

		case 0x8203:	//GEN_ONOFF_SRV_UNACK

                                      // firmware App's Logic
                        
                                      beak;
                  
                :
                :
     }
 }

Thank You !!

Note : my foo() is inspired from Zephyr OS implementation.

[ovrebekk]

Hi

We don't have any plans to merge the mesh library with the SoftDevice.

One problem with this, as endnode commented, is that it would increase the size of the SoftDevice. Since the SoftDevice is a pre-compiled and pre-linked library, you are not able to optimize out functionality that you don't use.

As it is today it is relatively little work to remove the link to the SoftDevice completely, so that you can use Bluetooth mesh and get away with a considerably lower flash requirement.

Another drawback of putting it into the SoftDevice is that the Bluetooth mesh would be held back by the SoftDevice release schedule. Today Bluetooth mesh is developed by a separate team, and can be updated independently of the SoftDevice.

In regards to putting models or services into the stack itself, this is not the way Bluetooth low energy is intended to work. The idea with BLE is that you can easily redefine or add new models/services in the application space, without having to wait for the stack provider to include new models/services.

Best regards
Torbjørn Øvrebekk

[leonwj]

(3/3) Ultimately, I'm not aware of Nordic charging for the use of their softdevice and simply provide it as a way to utilize their SoCs (which is their core business) which based upon your previous posts, you appear to be using. So as mesh developers, we get to choose whether we want to utilize Nordic's softdevice architecture or the open-source Zephyr stack (and/or a hybrid approach). From Nordic's perspective, I would imagine that as long as we're doing so on their SoCs, this means a win-win for the nRF5x ecosystem.