Hi, I have rather simple question which is probably due to my misunderstanding of basic RTOS scheduling. If 2 tasks like this: ~~~ void task1() { while(1) { xilprintf(“1”); vTaskDelay( pdMSTO_TICKS( 1000UL ) ); } } void task2() { while(1) { xil_printf(“2”); } } ~~~ are run with same priorites, I’ve noticed that task1 will never be executed due to delay. Once I remove delay, the processing time between tasks is divided as expected. Can anyone explain me this? Best regards, Nenad

Richard will probably provide a detailed explanation of what is going on. However, it looks to me that you are relying solely on the tick interrupt to share CPU time between the two tasks. This is rarely a good idea. If the printf function includes a mutex to prevent the output getting garbled, then most times the tick interrupt occurs, task2 will own that mutex so task1 can’t be scheduled. I would try one or both of the following to resolve the problem:

1. Increase the priority of task 1. It spends most of its time delaying, so you can do this without starving task 2 of CPU time.
2. Add a taskYIELD call at the bottom of the task2 loop, so that you are not relying solely on the tick interrupt to schedule CPU time between it and other tasks of equal priority.

As per David’s reply – a lot will depend on how the xilprintf() is implemented. Is it thread safe? If so, how is it made thread safe (see David’s reply). If it’s not thread safe, then what you are doing is dangerous as any state inside xilprintf() (like its access to whichever console you are writing to) could get corrupted – even if no data gets corrupted you could get strings interleaved at the output as you are printing from two tasks simultaneously. Does xil_printf() block (not return until all data has been output)? If so, then your application will be running extremely slowly. Etc. A good proportion of support requests that have a call to printf() in them are caused by the printf() call itself. You can serialise print output by having a logging task – when a task wants to print something it writes the message it wants to print to a queue and the logging task reads the data from the queue and writes it to the output port at a very low task priority.

Hi guys, thank you for your help. It seems indeed that this was the problem with xilprintf() after all. I made another quick test such as: ~~~ void task1() { while(1) { xilprintf(“1”); vTaskDelay( pdMSTOTICKS( 1000UL ) ); } } void task2() { int i = 0; while(1) { i++; } } ~~~ and both tasks were executing expected (I checked task2 in debug mode). Also, if there isn’t any call to xil_printf in task1 neither, than it also executes as expected. Best regards, Nenad