Received packets processing and thread change Timing

[Josar]

I ping from an RPI to the jiminy and see that the timings are somehow getting bigger and then jumping back to smaller and again getting bigger.

Thus i added pin toggels to xtimer and to the transciever interrupts. What i can see is that the requested ping is only processed after a xtimer overflow. I would assume that the packet is proccessed as soon as possible.

The timings from received and transmitted can be seen at the right side of the second figure.

So my question would be why does the thread not change imidiatly after the packet is recieved?

Any Ideas?

[jnohlgard]

Does your problem still occur if you apply #8951?

[Josar]

I don't see any relation, nevertheless applying #8951 does not change anything.

[jnohlgard]

Jiminy is atmega based, right?
The problem you describe looks like a problem that occurs on Cortex-M platforms when you forget to add cortexm_isr_end at the end of an ISR.

[Josar]

Yes atmega based. Thanks for the hint, i will look into it.

[Josar]

@gebart could not find cortexm_isr_end , but you made me thinking in the right direction.
Compared the timer isr with my isr implementation and found missing information in sched.h

The interrupt has to call the scheduler to execute the thread change.

    if (sched_context_switch_request) {
        thread_yield();
    }

Now the ping time is at 20ms.
Thanks a lot.

[jnohlgard]

No problem 👍

[Josar]

As i see it in msp430_common this is included in __exit_isr as i would have expected it to be, in atmega_common it is not. Instead it is redundantly written in every isr.

[jnohlgard]

IMO the msp430 and cortex approach is preferable. This is something that was refactored for the Cortex-M platforms in #6171. Feel free to provide a similar PR for the atmega if you feel like you have the time to do it.