4 Replies Latest reply on Aug 3, 2015 6:55 AM by user_257403943

    Puzzled by Server handling of write events in examples.

    user_257403943

      I've been studying the API documentation and the 100 projects as well as trying some experiments with my own custom service. I'm puzzled by the typical code for handling write events when a custom characteristic supports both read and write. Typically in the 100 projects it is something like:

         

      case CYBLE_EVT_GATTS_WRITE_REQ:
      case CYBLE_EVT_GATTS_WRITE_CMD_REQ:
        wrReqParam = (CYBLE_GATTS_WRITE_REQ_PARAM_T *) eventParam;
        if(wrReqParam->handleValPair.attrHandle == MY_HANDLE)
        {
           CYBLE_GATT_HANDLE_VALUE_PAIR_T hvp;
           uint8 theValue[2];
           theValue[0] = wrReqParam->handleValPair.value.val[0];
           theValue[1] = wrReqParam->handleValPair.value.val[1];

           hvp.attrHandle = MY_HANDLE;
           hvp.value.val = theValue;
           hvp.value.len = 2;
           /* Report data to BLE component for sending data when read by Central device */
           CyBle_GattsWriteAttributeValue(&hvp, 0, &cyBle_connHandle, CYBLE_GATT_DB_LOCALLY_INITIATED);
        }

         

      Three things puzzle me about this:

         
            
      1. Why is it necessary for application code to write the received value to the database? The API description (and common sense) implies that the stack should do this automatically subject to permission settings.
      2.     
      3. Why is it necessary to copy the handleValPair? Why not just specify '&(wrReqParam->handleValPair)' as the first parameter to ..WriteAttributeValue?
      4.     
      5. Why is the last parameter to ..WriteAttributeValue ..LOCALLY_INITIATED rather than ..PEER_INITIATED when we are responding to a peer write? As far as I can gather from the documentation this will bypass server permission settings.
      6.    
         

      Anyone have any insight into this as it is really baffling me!