Take much time sd_app_evt_wait() function

[milav]

Hello,

I am using nrf51822 with sdk11.0.0.

i observe that in while loop sd_app_evt_wait() function take much time for next interrupt to be pick.

is there any alternate solution available for this situation? or can i use RTOS instead of this?

is there possible to decrease the time of this? or is this depend on the task?

please give me a information about.

Thank You

Milav Soni 

[Einar Thorsrud]

Hi Milav,

What do you mean by "much time"? And how have you measured it? The time from IDLE to CPU execute for the nRF51 is at max a few microseconds (typically t_1V2 = 2.3 μs if the 1.2 V regulator must be started, else close to 0).

I see no way using an RTOS would improve the time from an interrupt until the CPU starts processing it.

BR,

Einar

[milav]

Hello, Einar

thank you for your quick reply.

I measure it  1.96 sec.

actually, i explain you all the condition,

1) first 6144 byte data is receive from android phone and write to flash and than transmit "R" to the mobile phone as a ACK.

2) than wait for next 6144 byte and again do same things until 196608 bytes data to be received.

now i measure on oscilloscope as below.

     first time to 6144 bytes write to flash := 120ms
     time between first 6144 and second 6144 bytes write to flash = 1.96s

     so total time to write 196,608 bytes to flash = (120*32) + (1.96 * 31) = 3.84 + 60.76 = 64.60s

 

so i am confused. where time is wasted?

Thank You

Milav

[Einar Thorsrud]

I see. Then this question is not about wake up time from interrupt. There is not enough information to understand what is going on, as what you are describing is some "high level" measurements you have done with your application, which we know very little about. Please break down a bit more describing exactly what is going on and where time elapses where you say it should not.

What exactly does your application wait for after the first transfer of the 6144 bytes? That is something that depend on your application and/or central side.

[milav]

The application is like this....

==> From Android application i receive 1024x768 image file. and that raw data is store in external flash.

==> From memory point of view it is not store all data at a time. so we divided all raw data(196608) to 32 blocks (32*6144).

==> so we receive first 6144 bytes and store to flash and so on....at every 6144 bytes receive i send "R" to phone.

==> after receiving all bytes from phone, we updated that whole image to LCD. 

==> And than again ready to receive new image.

....

1) The time for updating the image is 33 sec.

2) The time for receiving the whole 196608 bytes is take 65 sec.

3) The time for write 6144 bytes to flash = 120ms

......

image update time is depend on LCD and parallel interface.

but receiving time of data is more. (too much)..

==> receiving time contain = BLE receive data + flash write data

........

here i have explained the whole process.

Thank You

Milav

[Einar Thorsrud]

Hi Milav,

You are describing a long chain of operations with massive amounts of data being exchanged. I do not think there are any on this forum that can understand in detail what is happening in your application and test setup.

I have some general advice:

1. Start by breaking down the operations and measure the time of each of the operations (toggling GPIOs or something else).
2. Find out where things are taking more time than expected.
3. Dig further into what is happening, narrowing down to the operation that is taking more time than expected.
4. If you cannot find the problem: narrowed down your findings to something which you can describe in general terms understandable to others (not having intimate knowledge about your application).