Hi Amel,
I don't remember the original example, maybe I just used the absolute address for the question simplicity. Here is a similar exam:
/**
* @brief Starts the TIM Base generation in interrupt mode.
* @param htim : TIM handle
* @retval HAL status
*/
HAL_StatusTypeDef HAL_TIM_Base_Start_IT(TIM_HandleTypeDef *htim)
{
/* Check the parameters */
assert_param(IS_TIM_INSTANCE(htim->Instance));
/* Enable the TIM Update interrupt */
__HAL_TIM_ENABLE_IT(htim, TIM_IT_UPDATE);
/* Enable the Peripheral */
__HAL_TIM_ENABLE(htim);
/* Return function status */
return HAL_OK;
}
Here __HAL_TIM_ENABLE_IT seems to me as not an atomic instruction that read/write from/to HW register and it is not protected.
HOWEVER, I changed my mind. I think now that HAL is not necessarily supposed to be Thread Safe. It should be a "Driver" that needs to speak with the HAL and provide HAL protection with various RTOS means, like, semaphore, mutex and etc., so this is how I justified this behavior.
On the other hand, in some other cases I do see an attempt to protect global registers from non-atomic access from concurrent threads/different contexts, e.g.
HAL_StatusTypeDef HAL_TIM_Base_Stop(TIM_HandleTypeDef *htim)
{
/* Check the parameters */
assert_param(IS_TIM_INSTANCE(htim->Instance));
/* Set the TIM state */
htim->State= HAL_TIM_STATE_BUSY;
/* Disable the Peripheral */
__HAL_TIM_DISABLE(htim);
/* Change the TIM state*/
htim->State= HAL_TIM_STATE_READY;
/* Return function status */
return HAL_OK;
}
Here __HAL_TIM_DISABLE(htim); is kind of "protected" by writing BUSY before the macro is called and then READY . So I don't understand why in my 1st example ST didn't use the same approach like in the 2nd one?
