Looking at the following piece of code from targets/nrf5x/bluetooth.c, line 518 - see below -which handles the IOEvent, it looks to me like the data is associated with the characteristic not the event, so that if the second IOEvent is processed before a callback occurs, the second set of data will be installed in the characteristic value attribute and the callbacks for both events will thus see the same data. This implementation - if my understanding is correct - will always mean that the client sees the latest value of the server data, however, it means intermediate values are lost. It is reasonable if the client simply needs to monitor the value of a changing server variable, however, it leads to the current problem with ANCS. Not sure the best way to fix this, however, rather than create another queue, it might be better to defer processing of the second Bluetooth IOEvent until the first callback has occurred.
case BLEP_NOTIFICATION: {
JsVar *handles = jsvObjectGetChild(execInfo.hiddenRoot, "bleHdl", 0);
if (handles) {
JsVar *characteristic = jsvGetArrayItem(handles, data/*the handle*/);
if (characteristic) {
// Set characteristic.value, and return {target:characteristic}
jsvObjectSetChildAndUnLock(characteristic, "value",
jsvNewDataViewWithData(bufferLen, (unsigned char*)buffer));
JsVar *evt = jsvNewObject();
if (evt) {
jsvObjectSetChild(evt, "target", characteristic);
jsiQueueObjectCallbacks(characteristic, JS_EVENT_PREFIX"characteristicvaluechanged", &evt, 1);
jshHadEvent();
jsvUnLock(evt);
}
}
jsvUnLock2(characteristic, handles);
}
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Looking at the following piece of code from
targets/nrf5x/bluetooth.c, line 518
- see below -which handles the IOEvent, it looks to me like the data is associated with the characteristic not the event, so that if the second IOEvent is processed before a callback occurs, the second set of data will be installed in the characteristic value attribute and the callbacks for both events will thus see the same data. This implementation - if my understanding is correct - will always mean that the client sees the latest value of the server data, however, it means intermediate values are lost. It is reasonable if the client simply needs to monitor the value of a changing server variable, however, it leads to the current problem with ANCS. Not sure the best way to fix this, however, rather than create another queue, it might be better to defer processing of the second Bluetooth IOEvent until the first callback has occurred.