About the handler of "nRF52832"

RE: About the handler of "nRF52832"

ovrebekk — Mon, 21 Dec 2020 15:30:58 GMT

You welcome, I am happy to be of help.

I wish you the best of luck with your project 🙂

Best regards
Torbjørn

RE: About the handler of "nRF52832"

KURODA ELECTRIC — Mon, 21 Dec 2020 10:08:02 GMT

Dear Torbjørn

Thank you for your teaching.

Thank you very much for helping me!

RE: About the handler of "nRF52832"

ovrebekk — Thu, 17 Dec 2020 14:47:32 GMT

Thanks for the information, now the question is clear 🙂

It is true that if you want to access the same buffer from the main context and from the Bluetooth event handler, you need some way to control this.

1) Flag method: When the BLE event occurs you should not access the shared buffer directly, but set a flag that you can check in the main loop. Then you can check this flag in the main context and access the shared buffer safely.

2) An alternative method is to use the sd_nvic_critical_region_enter() and sd_nvic_critical_region_exit() functions whenever you access the shared buffer in the main context. This will ensure that no BLE events are executed within this region.

I would not recommend this method if the memory access in main takes a long time to execute, but small buffer copy operations should be fine.

Best regards
Torbjørn

RE: About the handler of "nRF52832"

KURODA ELECTRIC — Thu, 17 Dec 2020 05:08:11 GMT

Dear Torbjørn

Thank you for your reply below.

Regarding Question 3, after the processing of the first event is completed I understand that events that occur later will be processed.

Regarding questions 1 and 2, I am sorry that the question is difficult to understand.

We will change the question as follows.

Questions 1 and 2: Please refer to the attached typical case.

The buffer is shared between main () and the event handler, While manipulating the buffer with main () I don't want the event handler to manipulate the buffer.

In that case, add a function like Mutex in a multithreaded program, or I think it is necessary to temporarily stop the occurrence of the event handler. How should we achieve the above?

uint8_t g_pucBuffer1[256];
uint8_t g_pucBuffer2[256];

static void sample_handler(void * p_context);

int main(void)
{

// Initialization process omitted.

while (1)

{
  // I don't want the handler to rewrite the buffer until the following processing is completed.
  // I think we need an exclusion like Mutex in multithreading.
        memcpy(g_pucBuffer1, g_pucBuffer2, 256);

}
}

void sample_handler(void * p_context)
{
memset(g_pucBuffer2, 0xAA, 256);

Thank you for your cooperation.

RE: About the handler of "nRF52832"

ovrebekk — Wed, 16 Dec 2020 07:09:15 GMT

[quote user=""]As a basic operation, I understand that various handlers are registered in Nordic's SoftDevice and are called back when an event occurs.[/quote]

Correct. There is a system callback for handling system level events, such as flash write complete, and then there is a BLE callback for handling events related to the BLE stack.

[quote user=""]Is it necessary to exclusively control this callback on the normal processing side when using a buffer common to our normal processing?[/quote]

My apologies, but I am not quite sure what you mean by this question. Can you try to rephrase the question?

[quote user=""]

Question 3:

If another event occurs while processing the event handler, will the event handler that occurred later take precedence?

[/quote]

Internally in the SoftDevice all events are added to an event queue, and they will be processed one after the other in the order they were generated.

In other words, if you are busy processing one event while the next one happens, the last event will only be processed after you are done processing the first.

Because events are processed in an interrupt context it is not recommended to perform very heavy or slow processing inside the event handler. If you need to run a lot of code as a result of a SoftDevice event it is recommended to use a flag or a scheduler to execute the processing in the main context.

Best regards
Torbjørn