sd_ble_cfg_set(), parameter cfg_id

[natersoz]

This is somewhat of a continuation of this topic:

What does APP_BLE_CONN_CFG_TAG do?

Softdevice 132, header: ble.h:

SVCALL(SD_BLE_CFG_SET, uint32_t, sd_ble_cfg_set(uint32_t cfg_id, ble_cfg_t const * p_cfg, uint32_t app_ram_base));

1. I do not like the fact that the ability to set the GATT Service changed characteristic 0x2A05 is combined with setting the app_ram_base address.

I will merely register my complaint here: Poor separation of functionality. This is fundamentally a characteristic of 2 x 16 bits and an associated descriptor being associated with the entire softdevice start up declaration of RAM address. The call this function I have to go ask my start up code "how much memory did you allocate to the softdevice again?".

Can you imagine doing that when any other service/characteristic were being set?

2. There is this cfg_id parameter which seems suspiciously similar to the advertising parameter conn_cfg_tag.
SVCALL(SD_BLE_GAP_ADV_START, uint32_t, sd_ble_gap_adv_start(ble_gap_adv_params_t const *p_adv_params, uint8_t conn_cfg_tag));

Are they associated, these 2 tags?

If so, there some documentation that describes how these to items are tied together.

Apparently there is linkage, if not between the advertising tag but other tags based on the comments:

see @ref BLE_CONN_CFGS, @ref BLE_COMMON_CFGS, @ref BLE_GAP_CFGS or @ref BLE_GATTS_CFGS

That is a lot of linkage. Is there a document describing what is intended here?

OK, I just noticed this comment in the advertising function header (ble_gap.h):

conn_cfg_tag Tag identifying a configuration set by @ref sd_ble_cfg_set

Would someone please document these contextual tags, how they are intended to be used and the effects of their usage?

An application note would be helpful.

Thank you.

[tesc]

Hi,

1.

I do understand what you mean. Unfortunately this is kind of a "chicken and egg" situation, where the RAM requirement of the SoftDevice depends on configuration, and the configuration API needs to know where application RAM starts in order to avoid overshooting the available SoftDevice RAM region creating a mess overwriting application variables and possibly the stack. The current situation has emerged gradually, and I am sure there are other (better) ways to do this.

I have suggested for the SoftDevice team to take app_ram_base in sd_softdevice_enable() instead, so that it can be kept internally in the SoftDevice for subsequent calls to sd_ble_cfg_set() and sd_ble_enable(), but that the minimum requirement still gets returned from sd_ble_enable(). While that proposal might look good from the outside there may be other issues behind the hood so we must wait and see what the SoftDevice team decides to do. If you have any thoughts about that solution, or other suggestions, then please feel free to share them.

2.

Those two parameters are unrelated.

For sd_ble_cfg_set(), cfg_id is an identifier for what configuration item to set. See the Connection Configuration Message Sequence Chart for an example setting connection configurations.

For sd_ble_gap_adv_start(), conn_cfg_tag is what corresponds to the conn_cfg_tag provided within the p_cfg parameter that was previously passed to sd_ble_cfg_set(). (p_config->conn_cfg.conn_cfg_tag)

Regards,
Terje

[natersoz]

Thank you for both answers and for putting up with my rant.

Thanks again. The insight for both is helpful.

It is always nice to understand the motivation for why things are the way they are   :)

Thanks.