Using xSemaphoreTake without vTaskDelayUntil

dilirious wrote on Wednesday, May 08, 2013:

I am using FreeRTOS Ver 7.1.0.
Does xSemaphoreTake() allow other tasks to run if the task its being called from does not use vTaskDelayUntil()?
It doesnt appear to.  No other tasks will run.  I have a high priority task that needs to run and handle I2C traffic, this tasks needs to delay little as possible, < 2 msec.  There are other, lower priority threads that need to run as well.  I was hoping that these other threads would get a chance to run during xSemaphoreTake() but they dont unless I use vTaskDelayUntil().  
Thanks

davedoors wrote on Wednesday, May 08, 2013:

If you specify a block time in your call to xSemaphoreTake() and the semaphore is not available then the calling task will block and let lower priority tasks run just as if you had called vTaskDelayUntil(). If the semaphore is always there when you call xSemaphoreTake() then the the call to xSemaphoreTake() will always return immediately and the calling task will not block and starve lower priority tasks of CPU time.

dilirious wrote on Wednesday, May 08, 2013:

There must be something I am missing then.  I block indefinitely when I call xSemaphoreTake() with portMAX_DELAY.
I know there are 4 msec periods of time where other low priority tasks should run but they never get called unless I am using vTaskDelayUntil() in my high priority thread that calls xSemaphoreTake(). 
Right now I just have one other task that blinks an LED every 75 msec.  It is easy to see this thread never gets called.
Is there anything else I should be doing?
Thanks.

dilirious wrote on Wednesday, May 08, 2013:

Let me clarify.  There are times where xSemaphoreTake()  is called and there will not be an interrupt giving the semaphore back for 4 msec.  This is when I expect my LED blink task to run.

davedoors wrote on Wednesday, May 08, 2013:

If you are absolutely sure that the task taking the semaphore does block for up to 4ms at a time, then other tasks should run during those 4ms. You can verify that what you think is happening is actually happening by using the FreeRTOS+Trace tool. As a quick and dirty you can call xTaskGetTickCount() before calling xSemaphoreTake(), and then again after calling xSemaphoreTake(), and check that the difference between the two readings is sometimes greater than 1 (indicating that it was blocked for at least one tick period).

What is configTICK_RATE_HZ set to?
Are you sure your other tasks are running as you expect when the task that calls xSemaphoreTake() is not created?
Is the timing of your system about what would be expected for your configuration - so if you only create the LED blink task does the LED blink at the rate you specify?

dilirious wrote on Wednesday, May 08, 2013:

You are correct, xSemaphoreTake() would get the semaphore right away due the fact I was enabling the I2C interrupt right before this call and never clearing the interrupt so it would fire right away. 
Thanks for the help.