• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 381 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2640R2F: Multi_role example : send BLE acknowledgement AFTER data was processed in multi_role_processCharValueChangeEvt()

Damien Favre
Prodigy 190 points

Part Number: CC2640R2F

Hello,

In multi_role example, the data flow during a characteristic write is below :

- the stack first calls simpleProfile_WriteAttrCB()

- then, multi_role_charValueChangeCB() is called and enqueues the message with MR_CHAR_CHANGE_EVT event

- next multi_role_processAppMsg() listens for enqueued messages and calls multi_role_processCharValueChangeEvt() for this event.

- finally, my code is written in multi_role_processCharValueChangeEvt() function

My code can succeed or fail. Thus, I want to send a different BLE ACK value thanks to this result.

I think doing so is possible by modifying the return value of simpleProfile_WriteAttrCB(). However, this functions has returned a long time before my code was executed.

What could be a good way to do so ?

Thanks

Damien

  • 0
    TI__Mastermind 25810 points

    Hey Damien,

    Damien Favre said:
    Thus, I want to send a different BLE ACK value thanks to this result.

    I'm a bit confused on the flow of events after this point. Can you clarify what you mean in the statement above? Does this mean that you want to write a different value to the characteristic based on the result of your code? Or does this mean you want to send a different message to another device (peripheral and/or central) based on the result of your code? You mention acknowledgements, which makes me think the latter is true, but I am unsure.

    Damien Favre said:
    I think doing so is possible my modifying the return value of simpleProfile_WriteAttrCB(). However, this functions has returned a long time before my code was executed.

    How complex is the code being added? Typically I would recommend keeping callbacks as short as possible and posting an application event instead. You could solve this by putting your code (written in multi_role_processCharValueChangeEvt()) inside the WriteAttrCB()..

    However, I would not recommend modifying the WriteAttrCB() in my opinion. It would make things clearer to handle this in the application and trigger a new event based on the result of your code. That will then execute the intended functionality.

    If you can clarify what you are trying to do, I can offer more suggestions. These are my initial thoughts, I hope it helps.

  • 0 in reply to Ammar N
    Prodigy 190 points

    Hello and thank you for your answer.

    Maybe I didn't use the correct word "ACK".

    When the central writes a characteristic on my peripheral device, I can send it back a response (for example ATT_ERR_WRITE_NOT_PERMITTED or ATT_ERR_ATTR_NOT_FOUND).

    I want to send back the appropriate response according to the result of my code written in multi_role_processCharValueChangeEvt().

    In fact, the obvious way is to move my code to simpleProfile_WriteAttrCB() but as you said I'd rather keep the callback short. That's way I put it in multi_role_processCharValueChangeEvt().

    If I trigger then a new event based on my code's result, I won't be able to use it to respond to the original characteristic write.

    I hope I have made this sufficiently clear.

    Damien

  • +1 in reply to Damien Favre
    TI__Mastermind 25810 points

    Hey Damien,

    The spec defines the behavior and expected return codes for GATT Writes, so I would be cautious here and choose a correct ATT error code (perhaps 0x80: Application Error ATT_ERR_INVALID_VALUE would suffice here). As to the timing of this operation, I think it only makes sense to include this processing inside the writeAttrCB(). I would optimize your code in here and perhaps take some timing measurements of your code execution to ensure you're not blocking the stack for too long, resulting in a disconnection.

    Hope this helps.

  • 0 in reply to Ammar N
    Prodigy 190 points

    Thank you for your explanation, it helped.

  • 0 in reply to Damien Favre
    TI__Mastermind 25810 points

    Anytime. Feel free to ask more questions as you have them (please create a new thread though)!