Handle correcty the "busy state" of the ble stack

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
DeTo_1826166
Level 3
Level 3
First like received First like given

Hello everyone,

   

I would like how to handle correcty the "busy state" of the ble stack.

   

I tried a basic test where  the same data is send constantly with notification :

   


void SendDataOverStatesNotification(uint8 StatesData, uint8 len)
{
/* 'StatesnotificationHandle' stores States notification data parameters */
CYBLE_GATTS_HANDLE_VALUE_NTF_T StatesnotificationHandle;
/* If stack is not busy, then send the notification */
    
/* Update notification handle with CapSense slider data*/
StatesnotificationHandle.attrHandle = CYBLE_SHUTBASSCV_STATES_CHAR_HANDLE;
StatesnotificationHandle.value.val = &StatesData;
StatesnotificationHandle.value.len = len;
    
/* Wait until stack is free to send data*/
    while(busyStatus  != CYBLE_STACK_STATE_FREE) { CyBle_ProcessEvents(); }
    
/* Send the updated handle as part of attribute for notifications */
CyBle_GattsNotification(connectionHandle,&StatesnotificationHandle);
}
 

   

 

   

If i put a  CyDelay(5); before this function this work fine (at least during 10 minutes).
Without the delay it's crashing after 5 sec.

   

I would like to have something which is not crashing no matter the connection interval. 
How i can just wait the BLE stack properly without a delay ?

   

Should i use : 

   

while(busyStatus  != CYBLE_STACK_STATE_FREE) { CyBle_ProcessEvents(); }

   

or

   

if(busyStatus  == CYBLE_STACK_STATE_FREE) {my function code}

   

I don't see why the stack is crashing if I wait unti it is not busy after each send..

   

 

   

Thanks for your answers

0 Likes
1 Solution
Anonymous
Not applicable

Hello Thyrion,

   

(Thanks for posting the variable assignment/reference)

   

Based on the way I've seen the BLE stack operate, I would suggest the second method you asked in your original post:

   

if(busyStatus  == CYBLE_STACK_STATE_FREE) {my function code}

   

This way, you can run it in "parallel" in the main loop while still allowing you to call CyBle_ProcessEvents(), and other asynchronous processing functions while waiting for the BLE stack to free up. (Keep in mind that the BLE stack can only send data out at certain intervals/timings for the BLE specification to be certified.)

   

This would also allow you to do other communications hardware, like SPI or I2C while waiting for the BLE stack to finish processing.

View solution in original post

0 Likes
4 Replies
Anonymous
Not applicable

What is the "busyStatus" variable? Is that something you have declared and are using? Are you setting that to CYBLE_STACK_STATE_FREE somewhere? Afaik, there is no variable like that to signal the BLE stack state unless you are implementing it yourself. Have you tried using the CyBle_ get state functions instead?

0 Likes
DeTo_1826166
Level 3
Level 3
First like received First like given

Oh yeah sorry, it's coming from this state : 

   

 

   


case CYBLE_EVT_STACK_BUSY_STATUS:
/* This event is generated when the internal stack buffer is full and no more data can be accepted or the stack has buffer available and can accept data.
This event is used by application to prevent pushing lot of data to stack. */
/* Extract the present stack status */
            busyStatus = * (uint8*)eventParam;
            break;
 

0 Likes
Anonymous
Not applicable

Hello Thyrion,

   

(Thanks for posting the variable assignment/reference)

   

Based on the way I've seen the BLE stack operate, I would suggest the second method you asked in your original post:

   

if(busyStatus  == CYBLE_STACK_STATE_FREE) {my function code}

   

This way, you can run it in "parallel" in the main loop while still allowing you to call CyBle_ProcessEvents(), and other asynchronous processing functions while waiting for the BLE stack to free up. (Keep in mind that the BLE stack can only send data out at certain intervals/timings for the BLE specification to be certified.)

   

This would also allow you to do other communications hardware, like SPI or I2C while waiting for the BLE stack to finish processing.

0 Likes

Hello Pratt, thanks for the explaination, that seems logic !

0 Likes