Using the nRF51822. I have a routine that should never be interrupted. What is the easiest way to disable all interrupts, and then re-enabling them?
Using the nRF51822. I have a routine that should never be interrupted. What is the easiest way to disable all interrupts, and then re-enabling them?
There is no way to disable all interrupts as long as the softdevice is enabled, since this will possibly make you lose the BLE connection.
You can however disable all application interrupts by using sd_nvic_critical_region_enter()/_exit() functions.
Edit: If however the softdevice is disabled, or it's ok for your application to risk getting asserts back from the softdevice, you can use the CMSIS functions __disable_irq() and __enable_irq() to achieve this. Be aware that if you do this while in a connection or while advertising, you will get asserts if you're unlucky with the timing. This problem can be reduced (and possibly avoided) by using the radio notification feature to control when exactly you do this, but this is anyway not something we recommend to do.
I think sd_nvic_critical_region_enter() _exit() will not be helpful. Sometimes the reason which we need to disable all interrupts, in the MCU world, is to make a very short clock in GPIO by software. And in the this all-interrupt-disabled period, the GPIO clocks can made almost constantly, say, for 1us. The problem is, if we do not have such the API's to disable all interrupts, then the GPIO clocks cannot be made in this platform. As we have known in 8051, the instruction is simply 'EA=0'. In the nRF51822 platform, I think it is still possible to do such the API by setting 'cspie' registers; but it is usually can be used in the privileged mode...
So is it possible that Nordic release which the 'disable-all-interrupts' API's for applications? We know it has potentials to make BLE disconnected; but if it is used properly, it will not be disconnected...
I've edited and extended my answer above somewhat, but beware that this is a very scary thing to do that can have bad consequences.
Would it be fair to say that whenever the BLE stack is enabled, it is impossible to run any kind of tiny OS for the application? It would appear that way, since most if not all OS require the use of critical sections (i.e. __disable_irq).
No, I don't think that's a correct assumption, since you should be able to use the critical regions to protect such code. As far as I've seen, RTOSes disable IRQs to protect against their own interrupts interfering with the data structures. However, in the case of the softdevice, it doesn't change any state or data in the application space, and as such, it shouldn't cause any problems for the RTOS if such an interrupt occurs, even when in a critical region.
You may also have interest in taking a look at this: https://devzone.nordicsemi.com/index.php/freertos