Jiacheng:
How are you measuring the latency? I presume you have a scope on a GPIO input
and maybe set a GPIO high when you are inside the ISR and measure the time
between them? Or are you measuring the timing using a task? There is certainly
some hard limitation on interrupt response time but I am not sure what that is
for the nrf52 specifically. If you tell me exactly how you are measuring the
timing, what tasks you have running and their respective priorities, I might be
able to hazard a guess as to why there are differences. I would also like to
know what interrupts are enabled and their priorities.
> On Jan 27, 2017, at 6:38 PM, WangJiacheng <jiacheng.w...@icloud.com> wrote:
>
> Hi,
>
> I have an interrupt triggered by GPIO input, and observed different
> interrupt latency from different CPU state. If all the tasks are sleep, the
> interrupt latency is about 20us-30us, if the CPU is in idle mode with simple
> calling “__WFI()”, the interrupt latency is about 10us-15us, and if the CPU
> is running, the interrupt latency can be within 8us.
>
> I do the test as following, create a low priority task with 3 case:
>
> 1), the task loop is like
> while (1){
> /* keep the task in sleep mode, the interrupt will be 20us-30us */
> os_time_delay(OS_TICKS_PER_SEC);
> }
>
> 2). the task loop is like
> while (1){
> /* put the CPU in idle mode by simple calling WFI, the interrupt will be
> 10us-150us */
> __WFI;
> }
>
> 3). the task loop is like
> while (1){
> /* keep the CPU always running, the interrupt will be within 8us */
> os_cputime_delay_usecs(1000000);
> }
>
> Any idea to reduce the interrupt latency from all tasks are in sleep mode? or
> there is a hard limitation of interrupt response time?
>
> Thanks,
>
> Jiacheng
