I 'm testing the ble_app_sleep mode application, and I added a callback for theapp_on_system_powered
the call back just delays for 10ms to simulate processing and returns GOTO_SLEEP.
arch_main_loop_callback_ret_t user_app_system_powered(void)
{
delay_us(10000);
return GOTO_SLEEP;
}
when I press the button the device wakes up sends one advertisement packet and stops.
它设置为使用500ms间隔进行通告10秒。
删除延迟修复了问题，设备正常发布。
知道为什么这一切发生ening?
Thanks
Device:
Hi AnisM,
When using the app_on_system_powered you should not stay there for long. The 10ms delay that you have added into your user_app_system_powered() callback function is too long. If your procedure takes time to be completed, you can divide it into smaller procedures and return KEEP_POWERED in order to force again the schedule_while_ble_on() to re-run. With this way the scheduler will run any other BLE events that will occur and then the SDK will run the .app_on_system_powered. So, you should return KEEP_POWERED until your procedure will have finished, and then you should return GOTO_SLEEP.
谢谢，PM_DIALOG.
Hi,
based on the information in the user manual UM-B-006 my understanding is that asynchronous event processing has to be done in user_app_system_powered() to avoid spending a long time in the ISR.
1- so how much time can I spend in user_app_system_powered()?
let me explain my use case, my device sleeps until a button is pressed, then it wakes up does some processing for about 2 seconds then advertises once every 500ms for 10 seconds then goes back to sleep.
2- what's the best location to do the 2 seconds processing in this case?
我拥有的另一个用例是设备连接到手机，它可以处理10ms的处理向手机发送数据包并重复该过程。
3- where should I do the processing in this case?
Thanks
Hi AnisM,
There isn’t a standard delay that you can add into the user_app_system_powered(), but you should not stay there for long. You will have to make sure that the delay in the user_app_system_powered(), will let the scheduler to run all the events in the queue. In order to achieve that you will have to divide your procedure in smaller procedures that can be attached to the app_on_system_powered callback and return KEEP_POWERED as long as there is more procedure to perform. So, the device would execute the entire procedure piece by piece and without delaying the scheduler which schedules other events. You should do that in both of you applications.
谢谢，PM_DIALOG.
Hi PM_Dialog,
I've tried 1 ms and I'm having the same issue. given the 500ms adv interval I would expect that to be reasonable enough.
so having some guidelines on what the timing requirement are would be very helpful.
do you have any sample code that does anything similar to my use case?
in this case, wake up from button do the processing then start advertisement, I can spend as much time as I want in the interrupt when the device wakes up as opposed to what your app note UMB-006 is explaining.
Hi AnisM,
Yes, 1ms is a reasonable time delay, tested this on my side on the ble_app_sleepmode project with the default advertising interval and attached the delay function from the adc implementation fixed to 1ms, i can see the device advertising properly, so perhaps the delay isn't the cause for the fact that you aren't able to see the device advertising ? Having a fixed time that you can spend in this function is not possible since its not possible to determine the amount or if any events that might occur. Regarding an example, the DSPS reference design uses this callback for checking the ring buffer, so perhaps this will give you an idea. Regarding waking up from a button, run code and then start advertising, we dont have a similar example or reference design, but if you would like to do that, you can keep the processing (running your code as long as you would like, since there is no BLE interruption), all you have to do is disable sleep in order to keep the device awake or always return KEEP_POWERED, and as soon as the proccessing ends send an advertising command towards the stack in order to start the advertising events.
谢谢，PM_DIALOG.