mutex updating characteristic value in application memory

RE: mutex updating characteristic value in application memory

ovrebekk — Wed, 09 May 2018 10:31:16 GMT

Hi Peter

You might be able to use timeslots to do what you want.

Request a timeslot long enough to do your data update procedure, and you will know that the SoftDevice is not doing anything for the duration of the timeslot.

I haven't tested it myself though, just a thought ;)

Best regards
Torbjørn

RE: mutex updating characteristic value in application memory

pabigot — Wed, 11 Apr 2018 04:02:24 GMT

Ah. OK, I can see that. So it gives me the protection, but not the features I was actually looking for (eliminated duplicate storage and overhead updating fast-changing values). Disappointing.

RE: mutex updating characteristic value in application memory

RK — Wed, 11 Apr 2018 03:41:53 GMT

it can also be used to update a value in USER RAM, it doesn't care where the value is, it just updates it. And it does it via a softdevice call which gives you the exact protection you're looking for.

RE: mutex updating characteristic value in application memory

pabigot — Mon, 09 Apr 2018 10:16:33 GMT

Isn't the purpose of sd_ble_gatts_value_set() primarily to update the a BLE_GATTS_VLOC_STACK value that's in the SD's RAM? It's also used when the length of a BLE_GATTS_VLOC_USER value is changed, but that might never happen.

As I understand it BLE_GATTS_VLOC_USER exists so the values stored in user space can be exposed as characteristics. Several cases where that might be wanted:

values that are needed in the application in the same form they're exposed as characteristics don't have to be duplicated both user and SD RAM (here I'm thinking large structures containing sensor data)
values that may be rarely read but are frequently updated (e.g. clocks) will always provide the current value without making the application constantly tell the SD "it changed again; it changed again; ..."
the combination: in my case, a collected set of sensor data where pieces get updated at different times by application code that is decoupled from any communication infrastructure, so can't easily inform the soft device of exactly which pieces were changed.

BLE_GATTS_VLOC_USER appears to have a lot of potential, but only if there's a way to ensure consistency when the soft device dips into the application memory to read the value.

RE: mutex updating characteristic value in application memory

Hung Bui — Mon, 09 Apr 2018 04:54:05 GMT

Hi Pabigot,

Sorry for late response. Wouldn't using sd_ble_gatts_value_set() is a better way of avoiding the value of the characteristic being accessed when partly updated ?