Does timeout in blocking system calls effect the idling?

Kernel
1

turboscrew wrote on Saturday, November 04, 2017:

Sorry for the vague title, but it’s hard to put the essential in the header…
Anyway, we are using STM32L4 family device with M4F-port of FreeRTOS 9.0.0.
We use the tickless idle to put the system into STOP2 for most of the time. The use of STOP2 causes some clock setting overhead, especially when we have a bit tricky oscillator for HSE.

A task uses a radio chip for sending a message, and waits for the “message sent” interrupt. The chip driver uses a semaphore for that.

The problem is that with 2 second time-out for xSemaforeTake, the system goes to the tickless idle and sleeps. The interrupt can’t take place, because the power is OFF. On the other hand, the clock setting overhead makes it impossible to handle sleep times less than 5 ticks, so the configEXPECTED_IDLE_TIME_BEFORE_SLEEP is set to 10.

Is the tickless idle still used, if the timeout is set to, say, 9 ticks? (This is fixing old code to be used with FreeRTOS.) Or is there more recommendable ways of handling this?

2

richard_damon wrote on Sunday, November 05, 2017:

If tickless idle blocks or delays too much an interrupt then you need to prevent the system from going into tickless idle when that interrupt might occur. One way, like you mention, is to keep the timeout below the threshold value, the second is that the tickless idle code has a call back just before entering the idle mode, which allows you to prevent going into tickless idle when you are expecting the interrupt.

3

turboscrew wrote on Sunday, November 05, 2017:

Which callback?
Oh, and lots of thanks.