- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Solved! Go to Solution.
- Labels:
-
BLE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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;
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Pratt, thanks for the explaination, that seems logic !