Mutex use cases

Kernel
21

Hi @RAc ,
what about the below one, will it make any issue?
Why I am calling this means I need to initialize one sensor that works on UART protocol, I no need to initialize continuously from inside the task while(1) area, any other suggestions on this scenario?

void Task1(void *pvParameters)
{
send_char('A',0);
while (1)
{

    vTaskDelay(pdMS_TO_TICKS(500));
}
}
22

sorry, that does not make any sense whatsoever. Please rephrase in your native language and run through DeepL so I can understand what you want.

23

That will probably work. One thing it does appear to have a problem with is that it looks like you are using a “send_uart” function that needs to be very smart to work properly both under FreeRTOS and outside of it, that or it just wastes a lot of system resources spin-waiting while sending. The need to use a mutex around it tells me you don’t think it can handle thread safety, and thus probably isn’t actually the right thing to use for this case.

24

Hi @richard-damon ,
Thanks for the reply.
Can you suggest any alternate way to initialize the sensor that runs over UART?
But it needs to use mutes because 3 different tasks are calling this “send_uart” function.

25

What you really need is a serial driver designed to work in the RTOS environment, that will use interrupts and block task as needed rather than spin waiting for serial port ready as this code probably does. You may need to write this (and other) drivers yourself, if the CPU vendor doesn’t have suitable one itself.

To make that driver usable before the scheduler runs, it will need to check if the scheduler is running with xTaskGetSchedulerState(), and if so work as above, but if not, use the polling method.

26

Hi @richard-damon ,
Is there any example code available for this?

27

If you look in the demos, they have serial ports that work that way. If the port will be shared by different tasks, you many need to include a mutex wrapping the operations.

28

You can consider Daemon Task Startup Hook: Hook Functions - FreeRTOS™. You should share the code of send_char function too.

29

Hi @aggarg ,
If I am taking mutex from Daemon Task Startup Hook function, Is that Okay?
Or will it cause any issue?

30

In the startup hook, blocking should be ok. it will just delay when inital timer operations will start. If that is acceptable, that is ok. Since if the Timer Daemon is made the highest priority, this will be the first thing that starts to run, nothing else should have taken the mutex yet, you shouldn’t normally even have to worry about the blocking.

31

Hi @richard-damon ,
It is not high priority task in my case.

32

Then it just says that you may suffer a delay in the timers being started. But if you aren’t making the Daemon high priority, you must not be caring that much about timer callback accuracy.

33

I was suggesting for initialization. The timer task is usually the highest priority task, so it will run first. You can initialize your UART in the Daemon Task Startup Hook and then other tasks can use it when they need it.

34

Hi @aggarg ,
Thanks for the reply, I will implement this.