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?

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.

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

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 portENDSWITCHINGISR(false) function in the end of the interrupt subroutine.

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?

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

It should be portENDSWITCHINGISR(wasWoken)

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.

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.

Thanks a lot for your explanation