Hi,
Can I stop interrupts for 2ms in an orderly manner without crashing the S110?
Thanks,
Hi,
Can I stop interrupts for 2ms in an orderly manner without crashing the S110?
Thanks,
Hi Antonio
Unfortunately the SoftDevice was designed under the assumption that it would always have the highest interrupt priority, which means that critical SoftDevice events should never be interrupted.
I can tell you with 100% certainty that if the SoftDevice was interrupted for as much as 2ms it would break sooner or later..
Regards Torbjørn
Hi Torbjørn,
Thank you for your prompt response.
Maybe I would be twisting things by trying this out but, if it is a slave, could I quickly close the S110, or any other state that would be safe, and init it again after those 2ms? If this is posible, how long would this stop/start procedure take?
Thanks again,
Antonio.
Hi Antonio
Yes, you can close down the S110 stack and do some processing before enabling it again, but any running connection with the master will be disconnected. In other words you will have to reconnect after you wake up again.
How long it takes to enable the stack is a bit application specific (depending on how many services you configure and so forth), but we did some testing on the heart rate example showing the start up delay to be around 5ms.
The good news is that we are working on a new SoftDevice API that would allow you to request time slots in which you are guaranteed not to be interrupted by the stack. With this feature you could simply ask for a time slot from the stack, and the stack would find a free time slot in between any scheduled BLE events. Then you could run 2ms of blocking code without having to worry about issues, and without having to disable the stack and break existing connections.
Regards Torbjørn
Awesome, Torbjørn!!! :-)
Do you have a time frame for this new version? Do you have an alpha or beta that I could test?
btw, I have to do this because the Master SPI does not have DMA. Any plans in the future?
Thanks, Antonio.
Hi Antonio,
Have a look here: github.com/.../nrf51-neopixel and look for "ble_radio_notification_init" as we had the same type of issue driving the WS2812B LEDs with some timing critical software.
The solution in this case was to configure the BLE stack to notify the main loop every time it becomes not-active and then you've got several ms to quickly do your own processing before you need to hand processing time back to the BLE stack.
HTH
Alex Shepherd
