can i use vTaskDelay before starting schedular

ephobb wrote on Saturday, January 16, 2016:

Hi,
Can i use vTaskDelay before starting schedular. I need delay to initialize the LCD and it will come under initialization of hardware. So, this should be initialize before starting schedular.

rtel wrote on Saturday, January 16, 2016:

vTaskDelay() uses the services of the scheduler, and while one task is delaying (in the Blocked state) the scheduler will select another task to execute. This can only be done after the scheduler has been started - so no - you can’t call vTaskDelay() or any other function that might attempt to either enter the Blocked state or cause a context switch, until after the scheduler has been started.

It is common practice to create an initialisation task though. So main() will create an initialisation task, then start the scheduler. The initialisation task will perform the hardware and any other initialisation that is needed, and can use vTaskDelay() as the scheduler is running. Once the initialisation task has completed its responsibilities it creates all the other tasks necessary to run the application. The initialisation task can then either delete itself, or it can also start to execute application code.

Regards.

ephobb wrote on Saturday, January 16, 2016:

Thanks Lot.
Is it like following flow.

void main()
{
xTaskCreate(Init_Periphearls,"Init",128,NULL,0,NULL);
	vTaskStartScheduler();  
    }
    
    void Init_Periphearls()
    {
             Init_blabla();
             Init_blabla();
             Init_blabla();
             Init_blabla();
             xTaskCreate(Task1,"Init",128,NULL,0,NULL);
             xTaskCreate(Task2,"Init",128,NULL,0,NULL);
             xTaskCreate(Task3,"Init",128,NULL,0,NULL);
             xTaskCreate(Task4,"Init",128,NULL,0,NULL);
                      vTaskDelete( xHandle );
    }

Is it correct Way?

rtel wrote on Saturday, January 16, 2016:

Yes - that’s the right idea. The task can delete itself by calling vTaskDelete( NULL );

richard_damon wrote on Saturday, January 16, 2016:

I personally like to initilize as much as practical (but no more) before starting the scheduler. Before starting the scheduler, you have a simpler enviorment, since you don’t need to worry about inter-task interactions. Devices that require significant delays or waiting for interrupts do get initialized after the scheduler is started, at the begining of some appropriate task. I avoid a dedicate ‘initilization’ task, as normally I don’t use any dynamic memory after startup, so the memory used by the initilization task becomes lost memory.

For many devices, there will be a task dedicated to the device, so that task is the natural for doing the initilization. For output only devices like a disply, there may not be a task dedicated for it, so the initiliztion can either be done on first access in the driver interface, or some task is give the responsibility for calling the init function to do the initlization. (You do need then some flag to make sure no tasks try to use the device before the initilization is complete).

ephobb wrote on Saturday, January 23, 2016:

Thanks Richard.
I think, your idea is good. I should Initialize all the peripherial before starting task. It would better. So there will be no context switch no interrupt occurance.