I am using the WIN32 simulation which is provided with FreeRTOS.
If I am reading the code correctly it is triggering preemption every tick. And there is a tick for every ms.
Is this intended ? If you run a test application with 3 tasks with the same priority to test the preemption I see that the time an individual thread runs is not really equal like I anticipated them to be.
I can understand having a tick every ms, to keep track of time but not to trigger preemption and to schedule the next task.
Further is you debug this code, and set a break on vTaskSwitchContext, I notice this is triggerred indeed very much, but the tasks are not really switching. Even though I do see a different tcb being selected and the thread being enabled. I have the feeling the next tick comes already before the task got a chance to run.
Isnt it more likely to have preempion say every 100 ticks ?
and to have a tick of 1ms to be able to make timers ?
WIN32 Port
WIN32 Port
How do you mean the tasks are not really switching? How do you know. Remember this is just a simulator.
WIN32 Port
I am using following code :
static void vTestFunction1(void *pvParameters )
{
static int i=0;
for(;;){
i++;
printf(”vTestFunction1 %dn”,i);
//vTaskDelay(0);
}
}
static void vTestFunction2(void *pvParameters )
{
static int i=0;
for(;;){
i++;
printf(”vTestFunction2 %dn”,i);
//vTaskDelay(0);
}
}
xTaskCreate( vTestFunction1,”TST1″,100,NULL,0,NULL);
xTaskCreate( vTestFunction2,”TST2″,100,NULL,0,NULL);
vTaskStartScheduler(); then you can see visually that the tasks are switching but the switching rate seems erratic and not consistently switching say every 100ms but rather say every 10seconds or something. I can see this on the screen.
Even if the screen is slow that still does not mean that the times the switching occurs should not be a bit more predictable.
Then I also set a breakpoint on vTaskSwitchContext which is supposed to to the switch but does so every ms.
I am going to change the tick rate to 1s to see if that has any effect.
{
static int i=0;
for(;;){
i++;
printf(”vTestFunction1 %dn”,i);
//vTaskDelay(0);
}
}
static void vTestFunction2(void *pvParameters )
{
static int i=0;
for(;;){
i++;
printf(”vTestFunction2 %dn”,i);
//vTaskDelay(0);
}
}
xTaskCreate( vTestFunction1,”TST1″,100,NULL,0,NULL);
xTaskCreate( vTestFunction2,”TST2″,100,NULL,0,NULL);
vTaskStartScheduler(); then you can see visually that the tasks are switching but the switching rate seems erratic and not consistently switching say every 100ms but rather say every 10seconds or something. I can see this on the screen.
Even if the screen is slow that still does not mean that the times the switching occurs should not be a bit more predictable.
Then I also set a breakpoint on vTaskSwitchContext which is supposed to to the switch but does so every ms.
I am going to change the tick rate to 1s to see if that has any effect.
WIN32 Port
I suspect you are printing out faster than the console can cope with, and that you are using printf() without any sort of mutual exclusion (two threads trying to access the console at the same time).
Use some sort of mutual exclusion (scheduler lock maybe as PCs can do weird things with interrupts) or even a single task to write to the console with other tasks sending messages to the console task.
WIN32 Port
I added a semaphore to protect the printing itself, that seems to yield better results.
Still I don’t see why you would need to preempt every ms.
Still I don’t see why you would need to preempt every ms.
WIN32 Port
> Still I don’t see why you would need to preempt every ms.
You don’t, in most cases. Demos are provided with a 1ms pre-emption in part to test the port. The documentation pages for (nearly?) all state it is faster than necessary for most applications.
Regards.
WIN32 Port
I will also add, that once you have determined the needed tick rate for an application based on resolution needed for things like timeouts, there generally isn’t a reason you can’t do task switching at this rate. You already have done the context save entering the tick interrupt, and need to do a lot of the scheduler work to see if someone higher has woken up, so switch to the next in line is fairly additional cost. Also the sort of processors FreeRTOS is aimed out don’t tend to have things like caches or swap files that cause additional penalties for switching between tasks, which is one reason OSes on bigger machines use longer execution quanta for low priority tasks.