Mutual exclusion for HAL using FreeRTOS

[Aaron Pica]

Posted on January 18, 2017 at 10:51

I'm going to use the different peripheral drivers (HAL) from ST with the FreeRTOS. The system will have different thread executions, and each one will use different peripherals.

The question is whether the HAL implements some kind of mutual exclusion to avoid collisions and inconsistencies. If two threads use the same peripheral (I2C1 for example) at the same time, can it be problematic? Can all the peripherals be used without any restriction from each thread?

I saw that the peripherals implement some type of LOCK mechanism, but I'm not sure if it is meant to work with multiple thread executions.

Thank you

#hal #freertos #thread #mutual-exclusion #standard-peripheral

[Sean Park]

Posted on January 19, 2017 at 12:23

I have two options for you.

First, you are likely to be solved simply by semaphore processing. However, there are many things to consider such as task priority. Second, it is a good idea to add a communication task. It is efficient to handle communication in one task. 

[Aaron Pica]

Posted on January 20, 2017 at 09:40

Thank you

Park.Sean

‌. Then I understand that the same peripheral can't be executed concurrently, right?

I'll check which of the two options is more suitable.

[Richard Lowe]

Posted on January 20, 2017 at 13:25

I have the same question. Within the HAL wrappers you find things like HAL_LOCK(). Does this mean that we inherently are using mutexes on all of the HAL functions? If so, could we safely eliminate mutexes on the peripheral function calls?

[Sean Park]

Posted on January 23, 2017 at 00:23

The HAL function is basically treated as a critical section. However, this is a simple process that is slightly different from RTOS. Removal of critical sections is not recommended. This is because an abnormal operation may occur when accessing HAL from several places.

[Sean Park]

Posted on January 23, 2017 at 00:27

Processing is possible in the task after initial HAL initialization. But that does not guarantee correct behavior. So it is usually correct to create a communication task and process it in one task. In conclusion, it is best to create a communication task and handle it through communication between tasks.