NRFSDK5/SoftDevice - Context switching when using multiple different peripherals

[snoopy20]

Hi,

For supporting multiple different peripherals is it possible to get something back from a SoC observer which indicates the peripheral type?

https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.0.2/page/group_nrf_sdh_ble.html#ga78e6ffbd2e9d9b3e6805c30f3936ac86

Since all observers just get the context that was supplied (see below), and there's no means to target an observer for its specific type (uuid, service_handler etc), I'm puzzled on how to proceed.

NRF_SDH_BLE_OBSERVER(_name ## _obs, BLE_CSCS_BLE_OBSERVER_PRIO, ble_cscs_on_ble_evt, &_name)

[snoopy20]

I'll take a look at the DDM. I also hoped something might be on the GAP event (&p_ble_evt->evt.gap_evt.params) but to no avail. For read/writes it is possible to reference by characteristic handle (ble_gatts_evt_write_t const *p_evt_write = &p_ble_evt->evt.gatts_evt.params.write;)

All the examples I've seen so far and I imagine the DDM will be the same are for when you have multiple connection instantances of the same perpherial. In this case it's just a case of keeping a list of the connection_handles and no differentiation in code is needed, since all perpherials are the same.

The problem starts when they are different because so far I've found no means to detect this.

I'm on v17.1.0 but was referencing an old folder for examples.

[snoopy20]

DDM not relevant. Let me try again...

I register an observer. Let's take the cscs module. BLE_CSCS_DEF(m_cscs);

When a connected event fires how do I determine that the event is for a cscs and not a different type of peripheral?

[snoopy20]

I think I know where I'm going wrong.

I was thinking that by setting up two services would be two connections, which it isn't. So something connects and it gets both services, ignoring what it isn't interested in.

The reason for my misunderstanding is generally for most examples the connection_handle is stored on the context (well config) struct for a given peripheral, which is fine for a single connection but still technically wrong.