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.
it is setup to advertise for 10 seconds with a 500ms interval.
删除延迟修复这个问题nd the device advertises normally.
知道为什么这一切发生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.
Thanks, 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?
the other use case I have is the device is connected to a phone, it does 10ms of processing sends a packet to the phone and repeats the process.
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.
Thanks, 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.
Thanks, PM_Dialog