[En-Nut-Discussion] Scheduling out of Interrupt sometimes take a timertick NAP

[Uwe Bonnes]

>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:

    Harald> Hi Uwe, On 09.03.2015 12:35, Uwe Bonnes wrote:

    >> e.g.the STM32 Spi driver may be used DMA/interrupt driven. When
    >> transfer is finished, the interrupt routine signals the waiting
    >> thread via NutEventPostFromIrq(). The waiting thread then deasserts
    >> chipselect. This can be controlled good with a logic
    >> analyser. However I often see a gap of nearly exact 1 ms between the
    >> last sck toggle and the cs deassert.

    Harald> I'd say that this is the a problem of the driver code. There is
    Harald> no guaranteed time between NutEventPost... and the return from
    Harald> its associated NutEventWait.

I don't expect wonders.

    >> I never saw such a gap with NutEventPost().

    Harald> As long as other threads with same or higher priority are ready
    Harald> to run, the scheduler will _immediately_ switch the thread on
    Harald> any call to NutEventPost(). With NutEventPostFromIrq() this
    Harald> context switch is delayed until the currently running thread
    Harald> releases the CPU. Btw. in earlier releases this function was
    Harald> named NutEventPostAsync(), which IMHO better reflects its
    Harald> behavior. This function is not limited to interrupt routines.

But I expect the user thread to be serviced as soon as the processor is
idle. And in my case, I am quite sure there is no other thread waiting or at
least the other thread will not take _exactly_ one whole timeslice.

Or is the waiting user thread, signaled by NutEventPostFromIrq(), only
serviced on the next timeslice when some other thread is waiting with the
NutEventPostFromIrq() event?

    Harald> Anyway, depending on your thread layout, NutEventPost() may show
    Harald> a significant gap as well.

The probability of some other thread waiting for the NutEventPost() and the
NutEventPostFromIrq() case in my program should be the same. But I never saw
the 1 ms = one timeslice delay with NutEventPost().

Again, I know that there may be some other task between event posting and
the switch back to my user thread. But these switching to take exactly one
millisecond/timeslice sounds strange to me.

Bye
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------