Hello, everyone:

I have a non-preemptive port and I need a vTaskDelay. Using tick ISR is not an option (as it's a non-preemptive one), and I'm looking for an approximate solution.

The best one I come up with so far is inserting as many taskYIELD() as possbile, and having the port of portYIELD():

<pre>
#define taskYIELD portYEILD

#define portYIELD do { \
vTaskIncrementTick(); \
here are same assembly to
switch context, and call
vTaskSwitchContext()
} while (0)
</pre>

The call to vTaskIncrementTick() is required because it moves the tasks in the delayed list to ready list. Without it, the task calling vTaskDelay() will be suspend forever.

Is there better solution?

You cannot increment the tick each time yield is called. This will loose all track of time.

Why cannot you use task delay in cooperative mode? The tick interrupt will increment the time, wake any unblocked tasks BUT WILL NOT switch context until another task calles yield or blocks.

Thanks for reminding me the lose of time track.

Unfortunately, using tick interrupt is not an
option because of buggy hardware implementation.

I get the impression that you are trying to use vTaskDelay() incorrectly.

If you just want to switch between multiple tasks, you can use taskYIELD() like you mentioned in your previous thread. However, the tasks must be at the same priority. Your problem with starving Task 1 was due to the fact that Task 2 was at a higher priority.

You will probably run into the same problem if you use vTaskDelay() and then call vTaskIncrementTick() within taskYIELD().

In other words, if you are running in cooperative mode and you are not tracking time and you want to switch between multiple tasks, you can make the priority of the tasks the same and use taskYIELD().

I have several tasks, and one of them does *audio-video synchronization* and needs trigger the hardware after a *cacluated delay* time (the parameter to vTaskDelay). It cannot just spin for the specified time, because the processor time will be wasted, and our application cannot afford it.

/* spin without yield */
int begin = tick();
while (1) {
if (tick() - begin > DELAY) break;
}


I know that in the cooperative mode the delay couldn't be accurate, so I am just look for an approximated solution.

A design assumption made in the FreeRTOS code is that a timer with an interrupt is available for keeping track of time. You are attempting to run FreeRTOS without this. I think you may still be able to get what you need, but it requires some creativity.

This is an "approximate" solution that does have some potential holes.

I assume your "buggy hardware implementation" at least provides you with a timer that you can poll. You can add a poll of the timer in the idle task and call vTaskIncrementTick() when the timer fires. This will work as long as the idle task gets sufficient execution time. You will miss ticks (causing your delays to increase) if the idle task is starved.