Too much time between xSemaphoreGiveFromISR and xSemaphoreTake()

sminder wrote on Monday, March 31, 2014:

Hello. I’ve got a problem when I use a task unfreezing through xSemaphoreTake() function. I have a task that waiting a semaphore which set in an appropriate interrupt. But a measurement of period of time between a moment of set the semaphore and a moment when the task release him makes me unhappy. It takes too much time (up to 1 ms) and this period is very unstable. The task has maximal priority. Semaphore is binary.
Can I minimize this period?

richard_damon wrote on Monday, March 31, 2014:

Does your ISR check the “wasWoken” flag and initiate a task reschedule? If not, the system will wait till the next timer tick.

How to do that is a bit port dependent.

sminder wrote on Tuesday, April 01, 2014:

Rescheduling was a good idea. Richard, thanks a lot!

sminder wrote on Tuesday, August 05, 2014:

I rejoiced too soon.
I use the xTimerResetFromISR() function in my interrupt subroutine for restarting my software timer. After a start of device it looks like good, but if I use this function again the time between call of the xTimerResetFromISR() and the first triggering of the software timer differ times from time.
I use the portEND_SWITCHING_ISR(false) function in the end of the interrupt subroutine.

rtel wrote on Tuesday, August 05, 2014:

Timer callbacks execute in the timer service task, which is scheduled just like any other task. Do you have the priority of the task set higher than the application tasks so it runs immediately?

richard_damon wrote on Wednesday, August 06, 2014:

portEND_SWITCHING_ISR(false) means that no task switch will be performed.

It should be portEND_SWITCHING_ISR(wasWoken)

sminder wrote on Friday, August 08, 2014:

Thanks a lot for all your advices. I decided it is impossible to use the RTOS software timer for hard period intervals so I decided to use hardware timer for this matter.

richard_damon wrote on Friday, August 08, 2014:

Timers in FreeRTOS have a precision of 1 timer tick, as that is what they are based on. A timer will always trigger a a particular tick of the timer, there is no way to use them to trigger an operation in the middle of a tick period. That says that with a 1 ms tick period (which is what the demos you, but is actually faster then I find I normally need), a “1 tick” timer may go off practically immediately if it is started just before the tick interrupt occurs, up to nearly a full ms if it is started just after the tick interrupt.

This sort of variability is inherent in a global tick based time system.

If you really need something to happen a precise time after something else (with mill-second or better accuracy), then yes, you need an independent hardware timer of some sort.

sminder wrote on Friday, August 15, 2014:

Thanks a lot for your explanation