Reentrant event handling

[Alexander Schrab]

I am using esb in SDK 11 and my understanding is that the radio causes interrupts that are forcing and cannot be disabled. These in turn causes software interrupt 10 to be triggered and my callback is called. Am I right in this description?

To my question:

I am processing stuff in my main loop and in the event handler I need to read/write the same data structures. As far as I understand I run the risk of being interrupted in the middle of processing data in the main loop and causing reentrant problem when the callback affects the same data.

Can I disable software interrupts in the main loop? Will I then risk missing these are are they 'postponed' to when I enable the interrupts again?

Can I use the fifo.h implementation in this case? Is that implementation reentrant?

Are there any other usual ways of solving this problem that I should know about?

[Anders Strand]

Hello.

You are correct in your description of the event flow in the top of your post.

If you want to avoid race conditions when reading/writing to shared variables, you can use the critical region API. You will find this functions inside the header file "\nRF5_SDK_11\components\libraries\util\app_util_platform.h"

Alternatively, you can process the data inside the event handler. You will have to make sure that you are done before the next event though, or you might lose some events.

The app_scheduler api is made for taking events and processing them in main context. This will not let you write to the common data structure however. If you need to write to them from the main context, critical sections is the way to go. If not, you should probably go with the app scheduler.

[Alexander Schrab]

So, if I do everything (reading/writing of shared data) through events in the app scheduler that could be one way to solve this?

If I use critical region, do I risk missing the software interrupt or is simple delayed until I exit critical region in the main loop?