Hello,
Using port to windows i was wondered that vTaskDelay not work correctly, i.e. for example vTaskDelay(100) will delay task on 2000ms. Is it problem only for windows 7 and how solve that?
Thanks.

The Windows port is a FreeRTOS “Simulator”.  As it says on the documentation page for the port “The tick interrupt generation is simulated by a high priority Windows thread that will periodically pre-empt the low priority threads that are running tasks. The tick rate achievable is limited by the Windows system clock, which in normal FreeRTOS terms is very slow and has a very low precision. True real time behaviour cannot therefore be obtained.” While it is common to have ticks running at 100Hz or even 1KHz on a microcontroller, the Windows clock is in comparison extremely clunky.  The resolution is dependent on your hardware, but often in the 40ms range (with huge jitter too).  Therefore, attempting to use this clock to get near real time performance would prevent any tasks being able to accurately block for any time that was not a multiple of this 40 (ish) ms, and the average accuracy would be 40/2 ms – not very good. For those reasons, the port simulates a real time system by making time run slowly, where it pretends every ‘n’ ms is 1 ms.  Asking for a 100ms delay should always result in approximately the same delay being achieved, but it will be nothing like 100ms. The simulator is a convenient place to develop code, that can then be moved relatively easy onto a real target, it is not in itself intended to be a real time system. Regards.

Ok, i understood. Also i looked at freertos process cpu loading and it was always above 25%. In my mind all of this restrictions make no sense to using windows port. I supposed that windows port of freertos is just wrapper above winapi functions and not realize freertos algorithms. Earlier i wrote own wrappers for threads, seamphores etc (in windows it wrap winapi in device it wrap freertos api) but when i saw  freertos windows port i thought that can use just freertos api on both platforms without any wrappers.
Thanks anyway.

Read the documentation page for the project.

HI All, Actually windows can generate clock ticks of 1000 or more with no problems under windows. Windows does have special counters that can be used to generate these high tick clocks. For those interrested below is my version of the “prvSimulatedPeripheralTimer” routine which creates the clock ticks. Just substitute the current one in port.c and start ticking away.  In my PC the reported max frequency is of about 2mhz!!! I have not tested this on single core computers, but on twin core one core is used at 100% and the other is left free which gives the system good response. Regards, Alfredo //——————————————————————————————–
// Modification by: Alfredo Rainho Neves
// This is an updated version that will actually responde a few thousand times
// a second.
// The CPU load will show very high, but the routine actualy yield
// giving other tasks a chance. In a multicore CPU only one core will have
// a 100% CPU usage
static DWORD WINAPI prvSimulatedPeripheralTimer( LPVOID lpParameter )
{
LARGE_INTEGER lpFrequency;
LARGE_INTEGER startTime;
LARGE_INTEGER currentTime;
unsigned long  countPerTick;
unsigned long  elapsed; /* Just to prevent compiler warnings. */
( void ) lpParameter; // Get the performance counter frequency
QueryPerformanceFrequency(&lpFrequency); // Calculate the count per ticks
countPerTick = lpFrequency.LowPart / configTICK_RATE_HZ; while(1)  {
// Get the start time
QueryPerformanceCounter(&startTime); // Wait for time period to elapse
do {
// Yield to another task to make the system more responsive
Sleep(0); // Get the current time
QueryPerformanceCounter(&currentTime); // Calculate the elpased time
elapsed = currentTime.LowPart – startTime.LowPart; } while (elapsed < countPerTick); WaitForSingleObject( pvInterruptEventMutex, INFINITE ); /* The timer has expired, generate the simulated tick event. */
ulPendingInterrupts |= ( 1 << portINTERRUPT_TICK ); /* The interrupt is now pending – notify the simulated interrupt
handler thread. */
SetEvent( pvInterruptEvent ); /* Give back the mutex so the simulated interrupt handler unblocks
and can access the interrupt handler variables. */
ReleaseMutex( pvInterruptEventMutex );
} #ifdef __GNUC__
/* Should never reach here – MingW complains if you leave this line out,
MSVC complains if you put it in. */
return 0;
#endif
}