• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 358 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.

LAUNCHXL-CC26X2R1: Why using SimplePeripheral_enqueueMsg?

Hermann Menning
Expert 1305 points
Part Number: LAUNCHXL-CC26X2R1

Hello!

In the simple peripheral example that comes with the latest BLE5 SDK in the "user" task there is a calling sequence initiated by simple gatt profile callback which goes like this:

SimplePeripheral_charValueChangeCB -> SimplePeripheral_enqueueMsg --??--> SimplePeripheral_processAppMsg -> SimplePeripheral_processCharValueChangeEvt

There is something similar with the clock_handler:

SimplePeripheral_clockHandler -> SimplePeripheral_enqueueMsg --??--> SimplePeripheral_processAppMsg ->SimplePeripheral_performPeriodicTask

If you have alot of timers and service callbacks this bloats the code alot. Also this adds to energy/memory footprint (probably unsignificant). Is there any other reason besides leaving the swi context asap to follow that?

Imagine having the SimplePeripheral_processCharValueChangeEvt/SimplePeripheral_performPeriodicTask code directly in the handler/callback what is the risk? Are there any benifts for using SimplePeripheral_enqueueMsg?

Best Regards

  • 0
    TI__Mastermind 25810 points
    Hey Hermann,

    Excellent question. Ideally, you'll want to keep the callback functions as short as possible to avoid timing delays. Callbacks block the execution of code so the longer they are, the more likely you are to miss data (if sending a large packet for example), or in the BLE realm, trigger a disconnect because the device times out.

    For this reason, we use message queues to allow the application to handle the event after it has happened.

    There's more information here: dev.ti.com/.../the-application.html

    Let me know if that answers your question!
  • 0 in reply to Ammar N
    Expert 1305 points

    Ammar N said:
    Hey Hermann,

    Excellent question. Ideally, you'll want to keep the callback functions as short as possible to avoid timing delays. Callbacks block the execution of code so the longer they are, the more likely you are to miss data (if sending a large packet for example), or in the BLE realm, trigger a disconnect because the device times out.

    What is too long and what is short enough?

    Doesn't TI-RTOS nest hwis and swis with when they have higher priority?

  • 0 in reply to Hermann Menning
    TI__Mastermind 25810 points

    I can't say for sure what is too long, as that is application dependent. Ideally, you'd want it as short as possible (meaning a single call to post an event to be handled later). Theoretically, if you can handle the CB in one line of code, do so!

    I apologize for the confusion. You are correct. CBs don't "block" the execution of code when there is something of higher priority like you mentioned. You'll want to keep CBs short to maintain strict timing requirements required by our stack.

    Does that make sense?